Re: <NOBR> - Returning to the question....

Orion Adrian / 2004-04-04 19:25:
> [Jukka  K. Korpela wrote:]
>>That's a general property of logical text-level markup, is it not?
>>In this case, it's a matter of a special kind of being a single unit.
>>For example, the text in a link (<a href="...">...</a>) should
>>preferably be kept on one line, partly to avoid confusion (does the blue
>>underlined text at the end of a line and at the start of a new line
>>constitute one link, or two links?). But <nobr> would say that
>>unconditionally.
> 
> But <symbol> would be a much nicer container. Syntactic unit would also work 

I think Jukka is asking for a more generic element. <symbol> would 
be a cool name for some things, but I think it would be quite a 
stretch to say that a password is a "symbol". However, not having 
linebreaks inside a password is significant, because some system 
might be able to have line break character in the password[1]. 
Passwords can also contain normal space characters. The <pre> 
element wouldn't apply here either because I'm interested in marking 
up inline content. The <code> element might be arguably a logical 
choice for such content, but HTML 4.01 defines it as "Designates a 
fragment of computer code" 
<URL:http://www.w3.org/TR/html4/struct/text.html#edef-CODE>.

I think that <code> element should be refined to *practically* mean 
<nobr> in inline context and <pre> in block context. That should 
usually match the content one thinks when marking something as 
"code". Jukka would probably favor <nobr> and <pre> because that's 
what already existing browsers already support. I don't like <wbr> 
because I think such things should be handled on character level. 
The behavior of <nobr> (or equivalent) should just be defined so 
that the special character would just work.


[1] This raises a question if there should be an equivalent of <pre> 
for inline content which says that linebreaks are meaningful but the 
content should be otherwise considered inline. (The actual 
definition should use something other than "inline" or "block" but I 
cannot describe my thoughts that way ;-) Again, I'd prefer using 
<pre> for both and have the context define if the <pre> should 
behave like block or inline content. Obviously this wouldn't be 
backwards compatible...

-- 
Mikko

Received on Monday, 5 April 2004 13:24:54 UTC