W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2011

[whatwg] Interaction of <wbr> and CSS white-space

From: Jukka K. Korpela <jkorpela@cs.tut.fi>
Date: Sat, 14 May 2011 10:29:33 +0300
Message-ID: <4DCE2F5D.3010602@cs.tut.fi>
14.5.2011 6:49, Boris Zbarsky wrote:

 > "The wbr element is expected to override the 'white-space' property and
 > always provide a line-breaking opportunity."
 >
 > Why is this desirable?

It reflects the original and useful idea of <wbr>, which is supposed to 
introduce a specific rule in line breaking, making an exception to 
normal line breaking rules. This is conceptually simple and means that 
such a rule is included in the data itself.

For example, when mentioning URLs in the text of a document, you 
normally want to prevent line breaks in them by default and only allow 
line breaks at specific points, as in

http://www.whatwg.org/<wbr>specs/<wbr>web-apps/<wbr>current-work/<wbr>multipage/

Oops, my newsreader introduced a line break after a hyphen. And such 
behavior is common in web browsers as well. So it is natural to wrap 
urls in text in <span class="url">...</span> with CSS rule .url { 
white-space: nowrap; }. Or maybe use the nice <nobr>...</nobr>, which is 
declared obsolete (for reasons unknown to me).

Anyway, the idea is to disallow line breaks (that would otherwise be 
allowed by line breaking rules, whatever they might be in each 
situation) _except_ where explicitly allowed by <wbr>. This is needed 
for example in URLs, where browsers might otherwise break after "-" or 
"%" or some other special characters.

How are we expected to deal with such issues if white-space: nowrap 
kills <wbr>? We would need to split strings like urls into segments like 
<span class="nowrap">...</span> with <wbr> tags between them. Rather 
awkward.

 > It seems to contradict what CSS3 Text is trying to define

I think HTML specs need to specify the meaning of HTML markup, and style 
sheets will take it from that. It's up to HTML specs to say whether 
<wbr> specifies a line breaking opportunity. CSS specs may define a 
setting that unconditionally prevents line breaks somewhere, or a 
setting that prevents line breaks except those explicitly allowed in 
markup or by the use of line break control characters, or they may 
define both kinds of settings (obviously, that would be desirable).

 > In terms of compatibility, WebKit seems to do what the spec says right
 > now, while Trident (IE9), Presto (Opera 11), and Gecko (trunk) don't
 > break on <wbr> in "white-space: nowrap".

The <wbr> element had a simple idea and a natural origin, but browser 
developers have confused the issue, e.g. by removing or adding support. See
http://www.cs.tut.fi/~jkorpela/html/nobr.html#wbr
for some notes on the history. I haven't yet added the absurdity that IE 
9 apparently does not support <wbr> _at all_, except in the sense that 
<wbr> is recognized as an element and then you can say
.wbr:after { content: "\00200B"; }

So in the current situation, authors need to be cautious and use special 
tricks to make <wbr> work, but in the long term, <wbr> should be defined 
in a simple and straightforward manner, so that in the future, authors 
can use it as a simple and effective tool.

The HTML specs cannot dictate what CSS specs do, and the meaning of 
white-space (in detail) is unknown - is it to be understood as in the 
CSS 2 specification (which is effectively dead), or in CSS 2.1 (which is 
the de-facto standard but formally only a draft that must not be cited 
except as work in progress), or in CSS 3 (which is very much work in 
progress and may change at any moment)?

So maybe the best way to convey the message is to remove the reference 
to white-space and add a note on the _HTML_ element <nobr> (even if it 
is kept as obsolete - the spec should still specify its meaning):
"The wbr element specifies a line breaking opportunity even when used 
inside a nobr element."

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/
Received on Saturday, 14 May 2011 00:29:33 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:33 UTC