W3C home > Mailing lists > Public > www-html@w3.org > November 2004

Re: Concerns about the "l" element name <l>

From: Thomas O'Connor <me@ocoth.id.au>
Date: Wed, 3 Nov 2004 20:59:18 +1100
Message-ID: <019401c4c18b$ca1adeb0$2c637acb@dellwin>
To: <www-html@w3.org>

> It's a bit off topic regarding the Subject line, but surely not for the
> list. An element that means 'line' is somewhat odd, since 'line' is a
> concept related to visual presentation rather than logical structure. What
> is a 'line' in speech, or in Braille rendering, or to an indexing robot?

As you mention later on, we need to apply a semantic meaning to it, thus ruling out visual presentation use.

> Yes, but as soon as generated content and counters really start working,
> you can use them even on HTML as currently defined - you can use e.g.
> the <div> element, or even make a sequence of lines a <ul> and strip off
> the list bullets in rendering.

Yes, but as you go on later to say, <l> should have a semantic meaning.  <div> in my mind has no semantic meaning, mainly used to
arbitrarily structure pages for mainly layout purposes, while <ul> is for a list of objects that have a common link, rather than
special* lines of text with a continual joining relationship.

* "special" as in with a reason for their separation, such as verse lines, address lines, computer code lines, etc. rather than the
lines formed by line length restrictions in this e-mail correspondence.

> The l element indicates a short fragment of text that constitutes a
> separate unit, which normally has no independent meaning but belongs
> to a wider context. It is typically much shorter than a paragraph.
>
> The l element can be used to indicate, for example,
> - a verse line in a poem
> - a major part of a postal address, such as street address
> - a mathematical or chemical formula
> - a fragment of text inside or after a paragraph, when the fragment
>   should be considered as separate from the normal flow of text
> - a line of computer code when line structure is significant in
>   the code language used.

I agree with those examples.

> The l element should not be used for a small fragment of text that
> has an independent role and meaning, such as a short copyright statement
> like "Copyright 2004 Jukka K. Korpela" or contact information such as
> "E-mail: jkorpela@cs.tut.fi".

Also agree.

> If contact information consists of separate
> units such as E-mail address and telephone number, then the units can be
> marked up as l elements to separate them from each other.

If they are separate units like you suggest, such as an e-mail address, telephone number, etc. then they probably would be better
marked up as a <dl>, like so.

<dl>
    <dt>Email address</dt>
    <dd>me@ocoth.id.au</dd>
    <dt>Telephone number</dt>
    <dd>+61 2 4900 0000</dd>
</dl>



Thomas O'Connor, me@ocoth.id.au, http://ocoth.id.au/
----- Original Message ----- 
From: "Jukka K. Korpela" <jkorpela@cs.tut.fi>
To: <www-html@w3.org>
Sent: Wednesday, November 03, 2004 8:28 PM
Subject: Re: Concerns about the "l" element name <l>


>
> On Tue, 2 Nov 2004, Thomas O'Connor wrote:
>
> > Going off topic a bit: I think the <l> element is a great idea.
>
> It's a bit off topic regarding the Subject line, but surely not for the
> list. An element that means 'line' is somewhat odd, since 'line' is a
> concept related to visual presentation rather than logical structure. What
> is a 'line' in speech, or in Braille rendering, or to an indexing robot?
>
> Moreover, there are control codes (control characters) for line breaks.
> One might say that the need for _markup_ for lines originates from the
> decision to treat line breaks in HTML source as whitespace that is
> indistinguishable from a space. If HTML were designed now, that decision
> might be reconsidered; but HTML is (at least for now) on the XML track
> that enforces the whitespace principle.
>
> Logically, <l> and </l> rather than <br /> corresponds to the Unicode
> approach to line structure, which promotes the use of record start and
> record end characters rather than line break characters. It also
> corresponds to the similar principle in SGML. But this also means that <l>
> and </l> are effectively control characters in disguise, rather than
> delimiters of a logical element.
>
> >  I'm now using <br/> less and less, in fact I don't think I used it
> > once in recent designs I made as it doesn't have much point.
> > <l> will allow for enhanced control via CSS of code, etc. especially
> > when say adding line numbers (generated counters).
>
> Yes, but as soon as generated content and counters really start working,
> you can use them even on HTML as currently defined - you can use e.g.
> the <div> element, or even make a sequence of lines a <ul> and strip off
> the list bullets in rendering.
>
> So much as a devil's advocate. On the positive side, the line concept is
> not necessarily just physical. After all, poetry is much older than any
> writing, and in poems we have "lines" (verse lines), which are reflected
> in recitation too, and primarily there. But does this really correspond to
> the intended semantics of the <l> element?
>
> Moreover, there's more in <l> than in <div>. (Note that you can use <div>
> in present HTML quite well for dividing text into lines, instead of using
> <br>.) Not only does <l> imply line breaks before and after; it also
> implies that the content should not be broken across lines - that is,
> white-space: nowrap, to say it in CSS.
>
> So if we are serious about <l>, instead of just throwing a new ingredient
> into the tag soup, a semantic definition is needed. The current draft
> says:
> "The l element represents a semantic line of text (e.g., a line of verse
> or a line of computer code)."
> This is mostly just a play with words. "Line of text" does not become a
> semantic concept just because you prefix it with the word "semantic". The
> examples help a bit, but an example is not a definition.
>
> Moreover,
> "Whether the line should wrap or not depends on styling properties of the
> element."
> gives too much freedom. It means that a browser may freely break lines
> without saying anything about it, at least when it decides to ignore
> author style sheets. That is, the line structure is broken in a misleading
> way.
>
> Here's a quickly souped up suggestion:
>
> The l element indicates a short fragment of text that constitutes a
> separate unit, which normally has no independent meaning but belongs
> to a wider context. It is typically much shorter than a paragraph.
>
> The l element can be used to indicate, for example,
> - a verse line in a poem
> - a major part of a postal address, such as street address
> - a mathematical or chemical formula
> - a fragment of text inside or after a paragraph, when the fragment
>   should be considered as separate from the normal flow of text
> - a line of computer code when line structure is significant in
>   the code language used.
>
> The l element should not be used for a small fragment of text that
> has an independent role and meaning, such as a short copyright statement
> like "Copyright 2004 Jukka K. Korpela" or contact information such as
> "E-mail: jkorpela@cs.tut.fi". If contact information consists of separate
> units such as E-mail address and telephone number, then the units can be
> marked up as l elements to separate them from each other.
>
> User agents must, by default, render documents so that the structure
> indicated by l elements is clearly expressed. In particular, a visual user
> agent must by default render each l element so that it appears on a line
> of its own. However a visual user agent may divide an l element into two
> or more lines, when necessary to make it fit into the available width,
> provided that it clearly indicates that continuation lines are present
> (e.g., by suitably indenting them). In speech presentation, intonation
> or short pauses or both should be used to indicate the structure.
> In rendering on a media that allows neither line breaks nor pauses,
> such a Braille, special symbols should be used to indicate the
> start and end of an l element.
>
> -- 
> Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/
>
>
>
>
Received on Wednesday, 3 November 2004 09:59:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 March 2012 18:16:01 GMT