Re: XHTML 2.0 - <line> or <l>?

[Please, don't top post. That is, type the reply after quotation. FIXED]

Nigel Peck - MIS Web Design wrote:
 >Alexander Savenkov wrote:
 >>John Lewis wrote:
>>>Today we'd need to use br; l is a huge improvement because it's more
>>>[...]
>>>it doesn't matter; either way, it belongs in XHTML. Sub and sup are
>>>entirely presentational and yet still useful (and definitely not
>>>meaningless). If we toss the l, sub, and sup elements, we'd need to
>>>use span elements and classes instead--which do you think is worse?
>> 
>> As for me, I guess <sub> and <sup> are worse. Today no one marks up
>> "nd" in 2nd to be 'sup'. I guess French users (or whomever employs

It depends what you're trying to write. For example, if I were to write 
something that required meters squared I'd use markup like |His home 
wasn't big, it only had 37 m<sup>2</sup>.| There might be special 
characters for some exponents but you get the idea. Using MathML in 
cases like these sounds like an overkill for me.


>>>PS: I am completely behind the l element keeping its short name. So
>>>long as the spec is clear, and it is, there should be no confusion.
>>>Further, there are speed advantages for hand authors and size
>> 
>> Let's be logical. Speed advantages for hand authors make no sense
>> since there are editors that complete your elements after you typed a

I think things like these shouldn't be attacked with brute force. Simply 
because the problem could be worked around by using a sophisticated 
editor the issue doesn't go away. Look at MFC for an example... (IMO)

> I'd go for <l> because it's an element that I can see getting a lot of usage
> so best to keep it short. <section>, <blockquote> etc. won't get used as
> much so keep them long for readability.
> 
> I would suggest the principle should be:
> Keep high usage elements short and low usage elements long so they are
> self-explaining.
> 
> (Larry Wall quoted a very similar principle for the design of Perl but I
> can't remember where it originated from)

As you mentioned Perl, it came to my mind that Perl has aliases for the 
short forms. How about recommending the use of "l" element, but it would 
be equivalent with "line" element? Possible problems with this method 
are that (a) user agent and user default style sheets would need to 
specify same rendering for both element names (this one isn't a big 
problem really) and (b) structurally equivalent documents could look 
different with the same CSS applied if part of the CSS only had rules 
for "l" but no rules for "line" or the other way around.

-- 
Mikko

Received on Wednesday, 1 January 2003 16:33:14 UTC