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

[Boris Zbarsky]

On 5/14/11 2:06 PM, Jukka K. Korpela wrote:
> 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.

OK, good, we agree.

> 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.

CSS 3 Text is pretty clear as far as I can tell.  Granted, it's still a 
draft.


>> Except that browsers don't support that, for the most part.
>
> They mostly support white-space: nowrap well.

Yes.

> The part that causes problems is that some new versions of browsers support it all too well,
> ignoring <wbr> markup.

Again, imo <wbr> should NOT cause line-breaks inside "white-space: 
nowrap".  That's the wrong solution to the problem you're trying to solve.

>> The problem you describe is one of breakpoint prioritization.
>
> I don't think so. I think the primary issue is specifying allowed
> breakpoints.

So what you really want is a way to say "the only breakpoints are ones I 
allow".  That's not the same thing as "white-space: nowrap" which means 
"no breakpoints").

fantasai posted one possible solution here; another would be adding a 
new text-wrap value that means exactly that, leaving it up to the markup 
language to identify the allowed breakpoints.  Note that such an 
implementation would be web-page-observable: setting "wbr { 
whites-space: nowrap}" would prevent breaks at <wbr>.  Would that be 
reasonable?

A thought experiment, by the way: should ­ be treated the same way 
as <wbr>?  Why or why not?  It's an explicitly inserted break 
opportunity....

> 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?

Nothing at the moment, but that seems like something to specify via CSS 
text-wrap, not via markup.


> 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".

Right.  I'd be fine with that.  But again, would ­ be considered 
such an explicit indication?

> This is what <nobr> and <wbr> were created for

It sounds like half the problem here is that <nobr> is defined as just 
mapping to white-space:nowrap, right?  And the other half is that <wbr> 
is then not defined usefully at all.

Snipped the history since I'm honestly not interested in that.  I'm 
intested in what the goals are (which is only tangentially related to 
what they were 12 years ago) and how we get there.

>> 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)".

OK.  I think that something belongs in CSS (or, going out on a limb, 
should just be considered a quality-of-implementation issue).  This is 
not an HTML-specific problem.

> Breaking a URL after "-" is particularly confusing

Why?  It seems no more confusing than breaking after '/' unless the 
implication is that people will think the '-' is inserted by a 
hyphenation algorithm and isn't part of the url.

Note that RFC 3986 Appendix C is NOT relevant here.  That talks about 
line-breaking URLs by inserting whitespace (like actual newline 
characters) into the URL string.  We're talking about purely visual 
line-breaking that does not modify the content in any way; if you select 
and copy the url there will NOT be a newline in the result.  The 
situation is fundamentally different from plaintext wrapping as talked 
about in RFC 3986 Appendix C.

> Breaking after "%" in a URL is absurd, as it breaks a %-encoding of a
> character.

Uh... how does it break it?  Am I just missing something?

Is this the same confusion as above for '-', where you think there's 
whitespace being introduced after the '%' or something?

>> 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,

Then why is it present at all?  I think it should just be removed.

> And it refers to white-space, not text-wrap. Whether white-space: nowrap
> implies something for text-wrap depends on the definition of CSS

I think talking about anything other than CSS3 Text is pointless here; 
by the time this part of HTML5 reaches anything resembling stability 
CSS3 Text will have too.  Furthermore, CSS2.1 and earlier don't really 
define how breaking happens (past saying that "white-space: nowrap" 
prevents it).

> Weird. Anyway, "white-space" there links to CSS 2.1, and the document
> does not mention text-wrap at all.

Yes.  I don't think it's worth worrying about what CSS 2.1 says here.

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

Hey, we agree on the important things.  I'll go ahead and wontfix the 
Gecko bug on this.

Another thing to ponder: I accept that <wbr> inside <nobr> should allow 
breaking.  Should <wbr> inside <pre> allow breaking?

-Boris