Webmaster Forum / HTML, CSS, Scripts / CSS / August 2006

Darin McGrew schrieb:

<http://www.w3.org/TR/xhtml2/mod-text.html#edef_text_l>

Assuming you'd want to retain validity and the semantics of the
<address> element, then using <div> inside the element is not an option.
(For the sake of not drifting to far off of what is being discussed I'm
ignoring the ambivalence of the element's semantics)

I'd agree that there is a need for an HTML element that could for
example be used for marking up lines of poetry or a lyric, or indeed the
lines inside an <address> element. For the latter case the <address>
element would have to be changed to allow block level child elements,
assuming that the new element would be of type "block".

Using <div>s to mark up things like lines of poetry is something of an
anomaly, semantically

<div>Roses are red</div>
<div>Violets are blue</div>

equates to "Rose are red Violets are blue", which obviously is a problem
in certain rendering situations.

Ed Jay <edMbj@aes-intl.com> scripsit:

Do the statements constitute something that can reasonably be called a
paragraph, even if it is a short one? Then use <p>. Otherwise, consider
using <div> (typically with class="..."). Or if the statements logically
belong together, maybe they should be grouped, without forced line breaks.
It is not normal to break a line after every statement.

I don't see the relevance. If you use <br> effectively to separate blocks of
text, then you won't get any margins and cannot specify any margins - there
is no element to attach styles to. If you use <br><br> to create vertical
spacing, that's abuse.

Line break good, line separator bad.

You'll find it _easier_ with <p>, especially if you learn to use
collapsing vertical margins effectively.

I started writing a reply trying to argue against this point of view, but  
I managed to confuse myself in the process. The following is a train of  
thoughts, without a clear conclusion...

First idea:
Yes, punctuation does constitute a (perhaps primitive) form of markup. A  
text can be parsed based on punctuation. But the parsing mechanism is  
language-dependent. IMHO, it makes more sense to see punctuation as an  
integral part of grammar, because markup should be language-independent.

Pro punctuation = markup:
On a very abstract level, you could do something like:

<question lang="es">Cómo se va</question>
<question lang="en">How do you do</question>
<question lang="el">Τι κάνετε</question>

which is completely equivalent to:

<span lang="es">¿Cómo se va?</span>
<span lang="en">How do you do?</span>
<span lang="el">Τι κάνετε;</span>

A parser can always transform the punctuated form to the markup form,  
provided that it knows what language the phrase is, and that it knows the  
grammar of that language. A smart enough text-to-speech engine should be  
able to render the punctuated form correctly. It can also transform the  
markup form to the punctuated form, under the same conditions.

Contra punctuation = markup:
If the markup form is presented as text without any styling applied, it  
will look like

Cómo se va
How do you do
Τι κάνετε

and when this is copy-pasted to a plain text document, meaning is lost.

Rebuttal: One could argue that a rendering engine must always put the  
appropriate question marks around a phrase, and that these question marks  
can be copy-pasted along with the rest of the text.

Another contra argument:
On second thought, language alone is not enough to determine the  
punctuation. In English, one can use single or double quotation marks, and  
even within British English, different styles are possible. Still, one  
could argue that this is only a matter of style, not of content. Another  
example is a language that can be written in different scripts, such as  
Kurdish, which can be written in Latin, Cyrillic or Arabic. I don't know  
enough about that language to give a good example, but I'm sure that  
<question lang="ku">...</question> must be rendered differently if the  
enclosed text is in Arabic script than when it is in Latin or Cyrillic  
script. So the correspondence between markup and presentation is not  
entirely one-to-one.

Possible rebuttal:
Along with the language, the script could be specified. RFC 1766 (Tags for  
the Identification of Languages, http://www.ietf.org/rfc/rfc1766.txt) says  
about the language subtag: "The information in the subtag may for instance  
be: [...] Script variations, such as az-arabic and az-cyrillic".

Rebuttal of the rebuttal:
But whereas the main tag must be an ISO 639 code, and country information  
must also be given as described in ISO 639, no fixed format is given for  
the script information. Would ISO 15924 do? Does it cover all existing  
scripts? How does a parser know if the subtag gives country information,  
script information, or something else? In short, I don't think a reliable  
way exists to indicate the script unambiguously.

But then again:
If the script cannot be determined unambiguously, a parser cannot  
interpret the punctuated form any more than it can transform. For a  
text-to-speech engine, it is therefore better to have markup than to have  
simple punctuation.

Yet another contra argument:
Apart from the details noted above, it is not unreasonable to see (in  
English) "xxx!" as equivalent to "<excl>xxx</excl>", "xxx?" as equivalent  
to "<question>xxx</question>" and "xxx." as equivalent to  
"<sentence>xxx</sentence>". For quotation marks, an equivalent  
"<q>xxx</q>" already exists. But what about other punctuation marks, such  
as commas and colons?

You are right, <br> can be eliminated completely using <div>. For example:

<address>
<div>John Doe</div>
<div>123, Foobar Street</div>
<div>Bazville</div>
</address>

<poem>
<stanza>
<verse>Roses are red,</verse>
<verse>Violets are blue,</verse>
<verse>This poem is boring,</verse>
<verse>And quite silly, too.</verse>
</stanza>
</poem>

IIRC, Dr. Alzheimer, I already noted that <br> is the markup equivalent
for Unicode character U+2028 "line separator".

You're still interesting, even when you're wrong, sweetie.   8-)

Surely the proper solution would be to hold the semantic content
<dancing creatures> in the HTML and to suggest the type of animal via
the stylesheet?

Nik

Surely we're not discussing legislation, nor what might or might not be
"impossible"; the matter at hand seems to be what features ought to be
included in a specification. I would have thought that obscure and
annoying features would be excellent candidates for exclusion from such
a spec.

Advocates of annoying and obscure features ought to be permitted to
write their own specs; I wouldn't want that kind of behaviour to be
illegal, as long as my browser and I are permitted to ignore any
resulting 'recommendation'.

Why not? I say shoot anyone who even contemplates using ugly design
features on their web pages. Line 'em up against the wall, along with
people who create splash pages for their home pages, people who fix font
sizes, people who pick their noses in public and ... sorry, I seem to be
getting carried away!!

Good idea ;-) Flares should be an illegal offence, punishable by public
flogging.

See, the hard-line right-wing militant approach isn't dead, just
relegated to the ranks of the terminally insane!!

Ta ra