- From: Jukka K. Korpela <jkorpela@cs.tut.fi>
- Date: Sat, 3 Apr 2004 19:22:40 +0300 (EEST)
- To: www-html@w3.org
On Sat, 3 Apr 2004 olafBuddenhagen@web.de wrote: > I'm still in search of any example for either: > - A situation where something inside <code> (even in my broad defnition) > is definitely desirable to have normal line breaking rules appiled, or The word "normal" is questionable in the HTML context, due to Unicode breaking rules. The question only creates confusion. When I write, say, about the C language and mention a statement like a = b + c, I surely don't mean to prevent spaces from being replaced by line breaks, as you seem to postulate. There's no reason to prevent that, since in the C language itself, line breaks are permitted there. > - A situation where something outside <code> (i.e. natural language) > definitely shouldn't have normal line breaking rules applied You didn't notice the examples I gave? I don't think it pays off to list any new examples then. Besides, not everything outside <code> is natural language. For example, mathematical expressions aren't. You are making your own rules if say they belong inside <code> (and, besides, we don't want to prevent line breaks inside them, _and_ we don't want rules that allow line breaks after _any_ occurrence of a wide range of characters - for math, the same line breaking rules as for normal text should apply, unless specified otherwise, and this one reason why <nobr> is needed, and <wbr> too, despite its misleadign name). > (Definitely here means: It's important that it works even in a browser > not understanding possible style sheet overrides, for it would destroy > the meaning.) You are imposing arbitrary restrictions. In most cases, for example, removing paragraph structure would not change the fundamental meaning of text. Actually, it is difficult to construct a case where it would. Should we deduce that <p> elements are presentational only? -- Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/
Received on Saturday, 3 April 2004 11:22:42 UTC