Re: empty <div> and <span> elements (was: Re: XHTML user agent behavior...)
"Jukka K. Korpela" in litteris
<Xns93EAABEF181 Ejkorpelacstutf i@193.229.0.31> scripsit:[color=blue]
> The meaning of the clear property is to stop floating, so I cannot see why
> you could not use it the way I suggested. It seems to be that you are
> imitating <br clear="..."> in CSS, rather than making full use of CSS
> possibilities. I don't see how you would "clear the border"; a border
> property affects the element that it is assigned to, and you can assign a
> height property to the element if you wish to make it taller than its
> content needs.[/color]
The clear attribute is deprecated in HTML4 or XHTML. Certainly <br
style="clear: both" /> does the trick, but I fail to see in what way
it is any better than <div style="clear: both"></div>. The HTML4 spec
says that "The BR element forcibly breaks (ends) the current line of
text", and that's not what it's being used for: I'd say that using
<br/> except within a <p> (or somesuch) with text immediately
preceding and following is far worse style than using an empty <div>.
Restate that with an example: I believe that
<URL: http://www.eleves.ens.fr:8080/home/m...st/float1.html >
is better HTML style than
<URL: http://www.eleves.ens.fr:8080/home/m...st/float3.html >
(and the two should be rendered more or less identically).
(Note: I use the style attribute in my examples merely so they can be
written more concisely, but it doesn't have to be so; the class
attribute and an appropriate stylesheet would to just as well, of
course.)
[color=blue]
> You're referring to content generated by server- or client-side scripting
> or preprocessing, right?[/color]
Yes, sorry, my wording was confusing.
[color=blue]
> In any case, the tools you use for
> generating content e.g. server-side should be selected to match the needs,
> not vice versa.[/color]
That's very well in theory, but in practice we have to do with the
tools we have. Unless you were to give a *compelling* reason for not
using empty <div> and <span> elements, which you failed to do.
Altering an entire production chain merely to avoid empty <div> and
<span> elements is hardly a serious suggestion.
[color=blue]
> Well, they did in a sense - but browsers have not implemented the SGML way
> of using entities (except in the trivial sense of supporting a predefined
> set of entity references that expand to character references).[/color]
Precisely.
[color=blue]
> I agree with the idea that a simple markup system like HTML should have
> had a simple include feature. But CSS is _not_ the solution to that. There
> are several better approaches, as describe in the c.i.w.a.h. FAQ.[/color]
If you refer to question 5.1 in the FAQ (at <URL:
http://www.faqs.org/faqs/www/authoring-faq/ >), well, server-side
includes are not an option for me for reasons that I won't go into.
I'm willing to hear about any other proposal (or any other bit of the
FAQ that I might have missed).
[color=blue][color=green]
>> <p>Stylesheet name (if applicable): [<span
>> id="insert-stylesheet-name-here"><!-- EMPTY --></span>]</p>[/color]
>
> I fail to see what this relates to. Why would a document contain style
> sheet names that way?[/color]
Because we can have alternate stylesheets, and a well-designed
browser, or a little bit of ECMAscript magic, lets the user choose
among them. It might be nice to let the stylesheet name appear
somewhere within the content.
[color=blue][color=green]
>> Yes, and so? There's nothing wrong with browser-specific inventions
>> if they're useful and are employed in a way that gracefully degrades
>> on other browsers.[/color]
>
> The point is that you make arguments in favor of hacks, on the grounds
> that some hacks need them.[/color]
And so what? Hacks won't go away merely because we call them "hacks".
Sometimes, regretfully, they are needed, because existing tools don't
do the job.
[color=blue][color=green]
>> It seems that in every case I've given (except the first, where I
>> still see no workaround) you've told me "this isn't absolutely
>> necessary" and I've answered "yes, but it's convenient".[/color]
>
> I think for that for every case, including the first, I have shown that
> there is no need for using a <div> or <span> with empty content.[/color]
You have shown that there is no logical necessity to use them, indeed,
but you have not shown that they are not useful or that they are
harmful.
[color=blue][color=green]
>> On the other hand, if you have an important practical reason for not
>> using empty <div> and <span> tags[/color]
>
> First, there is no practical need for <div> and <span> elements with empty
> content (to use the proper terms).[/color]
There is no practical need, but I maintain that there is practical
usefulness.
[color=blue]
> Second, we have the precedent of <p></p>, which has caused much confusion
> - it has been used for layout, and the HTML specification explicitly says
> that it should not be used, and that browsers should ignore such elements.
> And browsers do not generally do that, so we really have a confusion.[/color]
But an empty paragraph is certainly an absurdity: a paragraph, by
definition, cannot be empty. But what is a <div> or a <span>, anyway?
The HTML specification does not enlighten us.
And saying that "it will cause confusion" is handwaving. What
practical problems do you expect should turn up?
[color=blue]
> Third, to take a simple example, such elements mess up the document
> appearance when a user style sheet is used in order to make all <div>
> elements bordered, so that the structure can be seen.[/color]
That's hardly convincing. First, we'll either get empty borders, or
horizontal rules, or simply nothing at all, and in either case, it
accurately reflects the document's structure (there *is* a <div>
there, and it's empty - knowing whether it should be shown or not is
as pointless as knowing how many angels can stand on the head of a
pin).
[color=blue]
> Followups trimmed - I think we are now so far from general XML that this
> belongs to the HTML group only.[/color]
Seems appropriate. I suggest that we drop this discussion, anyway,
since it is getting us nowhere and I think that each of us understands
the other's arguments: do we agree to disagree? Other people can make
their own mind as to whether empty <div> and <span> elements are, or
not, needed / useful / harmful / dangerous.
I would be interested, however, in any suggestions on how to include
foreign inline-level content in HTML without using the CSS content
property or the Mozilla-invented XBL language, given that server-side
includes are ruled out.
Cheers,
--
David A. Madore
(david.madore@e ns.fr,
http://www.eleves.ens.fr:8080/home/madore/ )
"Jukka K. Korpela" in litteris
<Xns93EAABEF181 Ejkorpelacstutf i@193.229.0.31> scripsit:[color=blue]
> The meaning of the clear property is to stop floating, so I cannot see why
> you could not use it the way I suggested. It seems to be that you are
> imitating <br clear="..."> in CSS, rather than making full use of CSS
> possibilities. I don't see how you would "clear the border"; a border
> property affects the element that it is assigned to, and you can assign a
> height property to the element if you wish to make it taller than its
> content needs.[/color]
The clear attribute is deprecated in HTML4 or XHTML. Certainly <br
style="clear: both" /> does the trick, but I fail to see in what way
it is any better than <div style="clear: both"></div>. The HTML4 spec
says that "The BR element forcibly breaks (ends) the current line of
text", and that's not what it's being used for: I'd say that using
<br/> except within a <p> (or somesuch) with text immediately
preceding and following is far worse style than using an empty <div>.
Restate that with an example: I believe that
<URL: http://www.eleves.ens.fr:8080/home/m...st/float1.html >
is better HTML style than
<URL: http://www.eleves.ens.fr:8080/home/m...st/float3.html >
(and the two should be rendered more or less identically).
(Note: I use the style attribute in my examples merely so they can be
written more concisely, but it doesn't have to be so; the class
attribute and an appropriate stylesheet would to just as well, of
course.)
[color=blue]
> You're referring to content generated by server- or client-side scripting
> or preprocessing, right?[/color]
Yes, sorry, my wording was confusing.
[color=blue]
> In any case, the tools you use for
> generating content e.g. server-side should be selected to match the needs,
> not vice versa.[/color]
That's very well in theory, but in practice we have to do with the
tools we have. Unless you were to give a *compelling* reason for not
using empty <div> and <span> elements, which you failed to do.
Altering an entire production chain merely to avoid empty <div> and
<span> elements is hardly a serious suggestion.
[color=blue]
> Well, they did in a sense - but browsers have not implemented the SGML way
> of using entities (except in the trivial sense of supporting a predefined
> set of entity references that expand to character references).[/color]
Precisely.
[color=blue]
> I agree with the idea that a simple markup system like HTML should have
> had a simple include feature. But CSS is _not_ the solution to that. There
> are several better approaches, as describe in the c.i.w.a.h. FAQ.[/color]
If you refer to question 5.1 in the FAQ (at <URL:
http://www.faqs.org/faqs/www/authoring-faq/ >), well, server-side
includes are not an option for me for reasons that I won't go into.
I'm willing to hear about any other proposal (or any other bit of the
FAQ that I might have missed).
[color=blue][color=green]
>> <p>Stylesheet name (if applicable): [<span
>> id="insert-stylesheet-name-here"><!-- EMPTY --></span>]</p>[/color]
>
> I fail to see what this relates to. Why would a document contain style
> sheet names that way?[/color]
Because we can have alternate stylesheets, and a well-designed
browser, or a little bit of ECMAscript magic, lets the user choose
among them. It might be nice to let the stylesheet name appear
somewhere within the content.
[color=blue][color=green]
>> Yes, and so? There's nothing wrong with browser-specific inventions
>> if they're useful and are employed in a way that gracefully degrades
>> on other browsers.[/color]
>
> The point is that you make arguments in favor of hacks, on the grounds
> that some hacks need them.[/color]
And so what? Hacks won't go away merely because we call them "hacks".
Sometimes, regretfully, they are needed, because existing tools don't
do the job.
[color=blue][color=green]
>> It seems that in every case I've given (except the first, where I
>> still see no workaround) you've told me "this isn't absolutely
>> necessary" and I've answered "yes, but it's convenient".[/color]
>
> I think for that for every case, including the first, I have shown that
> there is no need for using a <div> or <span> with empty content.[/color]
You have shown that there is no logical necessity to use them, indeed,
but you have not shown that they are not useful or that they are
harmful.
[color=blue][color=green]
>> On the other hand, if you have an important practical reason for not
>> using empty <div> and <span> tags[/color]
>
> First, there is no practical need for <div> and <span> elements with empty
> content (to use the proper terms).[/color]
There is no practical need, but I maintain that there is practical
usefulness.
[color=blue]
> Second, we have the precedent of <p></p>, which has caused much confusion
> - it has been used for layout, and the HTML specification explicitly says
> that it should not be used, and that browsers should ignore such elements.
> And browsers do not generally do that, so we really have a confusion.[/color]
But an empty paragraph is certainly an absurdity: a paragraph, by
definition, cannot be empty. But what is a <div> or a <span>, anyway?
The HTML specification does not enlighten us.
And saying that "it will cause confusion" is handwaving. What
practical problems do you expect should turn up?
[color=blue]
> Third, to take a simple example, such elements mess up the document
> appearance when a user style sheet is used in order to make all <div>
> elements bordered, so that the structure can be seen.[/color]
That's hardly convincing. First, we'll either get empty borders, or
horizontal rules, or simply nothing at all, and in either case, it
accurately reflects the document's structure (there *is* a <div>
there, and it's empty - knowing whether it should be shown or not is
as pointless as knowing how many angels can stand on the head of a
pin).
[color=blue]
> Followups trimmed - I think we are now so far from general XML that this
> belongs to the HTML group only.[/color]
Seems appropriate. I suggest that we drop this discussion, anyway,
since it is getting us nowhere and I think that each of us understands
the other's arguments: do we agree to disagree? Other people can make
their own mind as to whether empty <div> and <span> elements are, or
not, needed / useful / harmful / dangerous.
I would be interested, however, in any suggestions on how to include
foreign inline-level content in HTML without using the CSS content
property or the Mozilla-invented XBL language, given that server-side
includes are ruled out.
Cheers,
--
David A. Madore
(david.madore@e ns.fr,
http://www.eleves.ens.fr:8080/home/madore/ )
Comment