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
