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

[Jukka K. Korpela]

14.5.2011 10:41, Boris Zbarsky wrote:

> But why should this [wbr] override CSS that says "do not break at any break
> opportunities"?

I don't think HTML specs should say whether it does; they should just 
specify what <wbr> means, and in the case of rendering affected by CSS, 
it's up to CSS specs to define the effects of CSS rules. And as far as I 
can see, the current CSS specs don't make it crystal clear what the 
values of white-space mean in each case.

Originally, in CSS 1, white-space affected only whitespace. This was 
changed later, without changing the name of the property, overloading 
the property instead of defining additional properties. Part of the 
confusion has been caused by this. I'm not sure where this all will end, 
and I would prefer letting this be handled in CSS specs.

>> 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; }.
>
> Except that browsers don't support that, for the most part.

They mostly support white-space: nowrap well. The part that causes 
problems is that some new versions of browsers support it all too well, 
ignoring <wbr> markup.

> The problem you describe is one of breakpoint prioritization.

I don't think so. I think the primary issue is specifying allowed 
breakpoints. When I wish to say that characters like the hyphen "-" and 
the percent sign "%" are not to be treated as breakpoints, as browsers 
may treat them by default, what can I do? As the default treatment of 
characters varies by browser, and the characters in notations like URLs 
vary, there is need for being able to say "in this piece of text, 
suppress all breakpoints you might imply, and obey only explicit 
indications of line breaks or line break opportunities".

This is what <nobr> and <wbr> were created for, and they were found 
useful and they were widely supported by browsers. Then confusion was 
created, and now that these elements would finally make their way to 
HTML specs, the current wording says that <nobr> must not be used and 
CSS be used instead. I don't think that's a good idea, but it's 
apparently not a _working_ idea if there is no CSS counterpart.

 > I have no
> problem with <wbr> getting priority over breakpoints that the browser
> determines itself.

Neither do I, but that's not the point. The point is that <wbr> should 
be taken as allowed breakpoints even in texts where normal line breaking 
is suppressed.

>> 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 can be done by simply using "white-space: normal" and having UAs
> prioritize breaks at <wbr> over other linebreaks, no?

No, because browsers treat a large number of non-whitespace characters 
as allowing line breaks after them. Authors need something to prevent 
ridiculous and distorting line breaks in, say, "-1", "%5", and "f(1)".

>> This is needed for example in URLs, where browsers might otherwise
>> break after "-" or
>> "%" or some other special characters.
>
> For what it's worth, I don't see why this is a problem necessarily. I'll
> take you word that it is, but I would appreciate an explanation if
> you're willing to provide one.

Breaking a URL after "-" is particularly confusing and explicitly 
forbidden in many guidelines, including appendix C of RFC 3986 (STD 66). 
Breaking after "%" in a URL is absurd, as it breaks a %-encoding of a 
character. And problems like this are not limited to URLs.

>> CSS specs may define a setting that unconditionally prevents line
>> breaks somewhere
>
> Yes, that's what "text-wrap: none" means. Right now the HTML spec
> explicitly says that this setting should be ignore for <wbr>, which is
> what make no sense.

The statement is in section 13 Rendering, which in non-normative, 
containing "suggestions". (I think that's somewhat confusing, as the 
section is clearly meant to be at least semi-normative, and will 
probably be taken as normative.)

And it refers to white-space, not text-wrap. Whether white-space: nowrap 
implies something for text-wrap depends on the definition of CSS, which 
is mutable. I now notice that
http://www.whatwg.org/specs/web-apps/current-work/multipage/references.html#references
contains, under "[CSS]", a link named
"Cascading Style Sheets Level 2 Revision 1"
but actually pointing to
http://www.w3.org/TR/CSS/
which is titled
"Cascading Style Sheets (CSS) Snapshot 2010"
Weird. Anyway, "white-space" there links to CSS 2.1, and the document 
does not mention text-wrap at all.

>> The HTML specs cannot dictate what CSS specs do
>
> They're trying to, is my point.

That's unproductive, is my point.

 > As an implementor I then have to
> reconcile the conflict somehow.

Regarding the current status of CSS, line breaking behavior is 
incompletely defined and partly impractical. But this cannot be fixed 
from the HTML side. The best HTML can do is to be consistent, clear, and 
practical within its own scope, such as the semantics of markup. And 
there is obvious need for the _old_ <wbr> and <nobr> model, which should 
be available even when CSS is not used, as the line breaking permissions 
and prohibitions relate to the content as such, not to casual rendering 
issues.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/