Empty span element

Your validator is too sensitive.. I have my site validated as XHTML 1.0 strict by w3.org with that empty span element.. Can you please tell me which strange validator is so picky?

João

Your site would validate perfectly if you use HTML validator's SGML parser option, which uses the only validator that matters. It's not an error that a span is empty.. It's only a waste of bytes in the page.

The reason why there's an empty element is to serve as a container for CSS styling of the content corner link options. The core module adds the empty span and each module which has that option configured inserts the link inside that span. Since the printer-friendly pages (core) module, by design, doesn't know about the configuration of the PDF and e-mail modules, there's no way to remove that empty span when it isn't being used.

João

Since the printer-friendly pages (core) module, by design, doesn't know about the configuration of the PDF and e-mail modules, there's no way to remove that empty span when it isn't being used.

No.

The empty div can still cause layout issues.

Does the container span have to be added by the core module?
Could the pdf and email modules not simply check to see if their container is present and add it if required?

Please show me an example where an empty span (not a div, a SPAN) can cause layout issues, and I will show you a bad rendering engine.

As to your questions:

1. Yes.
2. In theory, yes.. In practice, it would add duplicated code and cause a performance hit for something which I haven't seen the need to do.

Sorry about the div typo.

I think the problem here was caused in IE6 by styling the element as an inline-block. There are the normal workarounds but its just another thing to do.

When IE 6 goes off a cliff - end of issue.

Hello,

This is also causing some issues with drupal for facebook, #187868: Facebook not using fbml theme, because it is calling the theme functin in vain, that is, to output the empty span div...

jcnventura, why the attitude? This is a really simple fix, and yes, it does mess up layouts by adding an extra inline elenment where their shouldn't be one. Please see attached for a patch that fixes it. I also fail to see where a performance issue could arise here - in fact, my patch might nominally improve performance by eliminating an unnecessary preg_replace(). It also fixes a code format issue in the same section (a nested if statement wasn't indented).

If only it were this simple, of course I would have changed it... The problem is that this span is used to maintain a placeholder area that will be filled in by other modules (currently print_pdf and print_mail), but the option is there for other unknown modules to add the links there (such as a print_kindle or whatever).

As such, I can't remove the span even if it is empty by the print module, because it may be used by other modules, and I can't fill it all in this module even because that would break the placeholder for unknown modules.

This will get solved eventually by a re-factoring of the module I am planning after Drupal 7 gets released. The idea is to remove all the link-building stuff into a print_ui module which will provide hooks for other modules to add their links and will avoid the code triplication that can be seen in the current code. However, that's for the future, so the current bad code needs to be there.

It's an empty span. Any sane browser will simply ignore it, unless the CSS is configured to make something out of it. If that's the case, fix it in CSS. The w3.org validator has no problems with it, so I don't have any either. Show me why I am mistaken and I may bother to mess up the code a bit more, until then I see no reason to change it.

João

Chrome and Firefox don't ignore it and neither does Facebook (it's not valid FBML). Your own CSS appears to be part of the problem, at least as far as the visual issue is concerned - from printlinks.css (line 3):

.print-link {display:block; padding-bottom:0.5em; text-align:right;}

That causes extra space in my theme that I have to specifically override.

I would like to add that I use empty div's and spans ALL the time - - either as image "wrapper" with a BG referenced to an element in a sprite or as a destination for a jQuery-based insertion. I have never had a problem and have never failed w3.org validation (at least for this reason). In the former case, the use of css sprites is often predicated on having an empty element and this practice is more or less the state-of-the-art for graphically rich sites; in the latter case, it greatly simplifies the jQuery structure in that you do not have to dynamically create this target element.

I have tried many validators and the only one - - IMHO - - that is "valid" is that provided by w3.org - - which, as the maintainer says, very properly does not flag empty elements. My experience is that using FF plugins for this sort of thing is a great way to waste time. As an aside, I use the "rel" attribute quite liberally to aid in jQuery operations and this does not validate an otherwise valid markup, so a case can be made that, in some contexts, markup validation is not always a benchmark of well-constructed markup.

Finally, it seems to me - - and this has been my experience with Drupal modules as well as with jQuery UI elements - - that it is the rare case where you do not have to override the "pre-canned" css with your own. In the zen theme, for example, all form elements have either padding or margin (or both) - - which I override 100% of the time with simple css statements since the default is never what I need.

As a specific case in point, I completely override (and augment) the print-link element css when using this module.

So, it is my view that our maintainer (who assiduously answers questions and helps us solve issues) is not exhibiting attitude here but is rightly pointing out that if the css that comes with this module causes you problems - - just override it.

And BTW, Chrome and FF do indeed ignore empty div's (as does Safari) - - they simply obey the css for those elements. If facebook does not like it, then they may have "IE-itis" and may not being implementing the rendering standards. I suspect, however, that they are simply implementing the css.

In short, I do not think it is worthy to take up the time of a volunteer module maintainer with this issue. Simply find the element that has css you do not like and override it with your own.

Thank you for the patch it works beautifully and not to beat a dead horse would love to see it added to the release version.

Thanks for the patch in #10, fixed the issue for us.

kingandy provided a patch in #835814: Markup is in #value, should be in #prefix/#suffix that fixes this in a proper way.. So we can all say goodbye to the empty span in the near future. Rejoice! :)