Re: <wbr> rendering

A short note regarding a test I just made for the sake of completeness.
User agents involved: Internet Explorer: 9, 10, 11; Google Chrome, Mozilla
Firefox, Opera: Latest versions, on Windows 8.1.
Test elements: empty <span> elements used as string breakers, <wbr>
elements.
Native support for both elements has been observed.
Additionally, I tested <span> elements as:
 - line breaks (span::after {content:"\A"; white-space:pre;})
 - string break opportunity (span::after {content:"\200B";})
 - anchors for CSS-generated soft hyphen (span::after {content:"\00AD";})
Then I tested what happens when <wbr> is used in conjuction with soft
hyphen (wbr::after {content:"\00AD";})

Here the results:

   - As said before, only Google Chrome and Opera break lines on simple
   <span> elements, but line breaks incorrectly and it goes beyond the box
   constraints before breaking.
   - All the user agents tested treat correctly <span> elements used as
   <br> (span::after {content:"\A"; white-space:pre;}).
   - Internet Explorer and Mozilla Firefox treat correctly <span> elements
   used as <wbr> (span::after {content:"\200B";}) and break the line when
   necessary. Google Chrome and Opera don't break.
   - Strangely, all UAs tested present correct line breaks when <span> is
   used as placeholder for soft hyphen (span::after {content:"\200B";}).
   Chrome, FF and Opera break the lines, though without marks.
   - Even more strangely, IE goes beyond that and treats
   span::after{content:"\00AD";} prefectly, breaking the lines with
   hyphenation where necessary (all versions)
   - BUT the same Internet Explorer doesn't natively support <wbr> and the
   string doesn't break (only case; all versions)
   - BUT again, it breaks the lines with hyphenation in case of wbr::after
   {content:"\00AD";}

To me, this means that there's enough room at least to change the rendering
rule from element{content} to element::after{content}. This would align the
spec text with the current CSS rules, and in some cases would help authors
using <wbr> in different contexts if necessary.


2015-03-08 17:05 GMT+01:00 Andrea Rendine <master.skywalker.88@gmail.com>:

> >> In the spec, <wbr> is meant to be a line break opportunity.
> > That’s a good informal description, but rather unsatisfactory as a
> definition.
> It comes from the spec:
> http://www.w3.org/TR/html51/text-level-semantics.html#the-wbr-element .
>
> >Such a convention is far less universal than you might think
> Never meant it to be universal. I meant that it could help wherever it is
> needed.
>
> > It’s more like allowed break in a string.
> It should allow authors to break strings according to language and context
> typographical conventions.
>
> > The soft hyphen has been with us for many years ... though support to it
> has been surprisingly limited.
> I saw it doing its job in modern browsers. Do you mean older visual UAs?
>
> >  It is all OK for plain text to contain soft hyphens. If you paste text
> in an environment where e.g. soft hyphens or other invisible characters
> might cause problems, you just need to deal with it.
> Authors and users alike have to deal with several problems. I'm just
> asking why a feature which has become part of the standard (and not just
> "supported") cannot be used in such scenarios.
> I'm quite sure that there are other HTML elements meant to deal with old
> problems already solved. If something works, something else could still
> work better.
>
> >> an author could style such element so that its rendering fits to the
> purpose. For instance, <wbr> inside <code> could be rendered as zero width
> space, while <wbr> in paragraphs could become a soft hyphen.
> > I cannot see where you got that idea, but in any case, <wbr> is not
> meant to become a soft hyphen.
> http://www.w3.org/TR/html51/rendering.html#phrasing-content-0
> I thought that according to this section, <wbr> is meant to work as if a
> CSS rule placed a zero-width space as its content. According to this,
> there's nothing bad for an author to specify a CSS rule overriding this
> standard in order to make <wbr> fit other cases of "string break". Exactly
> as "a style sheet or user agent would be ... justified in causing line
> breaks to be rendered in a different manner, for instance as green dots, or
> as extra spacing" (this is the case for <br /> line break).
>
> > There are no specifications on such things either, and there has not
> been work on the issue for many years, as far as I can see.
> Then it's just a matter of misused words: I should have said "working
> drafts". Here's the last (though quite old) about "content" property
> applied to elements:
> http://www.w3.org/TR/css3-content/#inserting3
> Specs and documentation currently state that "content" is not to be used
> on elements. Which is what I saw, too. But then, why relying upon this in
> order to define the rendering for this element?
>
> >> It breaks words, right,
> > No, it just declares a permitted line breaking point in a string.
> This is definitely a matter of terms, then. It declares a permitted line
> break in a string. Which means that, if the string is a word and the line
> break occurrance condition occurs, it does break the word. Or, which is the
> same, as it declares points where a line break can occur in a string, it
> should allow authors to define how the string should be broken. I'm not
> going against the use cases, or the purpose of the element itself.
>
> >> empty span element would do the trick.
> > No, empty spans do not do such things; foo<span></span>bar acts as
> foobar as far as layout is considered
> foo<span></span> bar breaks in Google Chrome, old versions of Safari
> (can't test on newer). I think it was the same with the previous Opera
> engine, but I can't be sure.
>
> It's just my conclusion: now that <wbr> is part of the standard, its
> rendering whould not rely upon defining CSS "content" on the element itself
> It is theoretically a poor choice, as currently it can be applied only to
> pseudo-elements. And it prevents users to change its behavior, in case a
> string break can be represented differently. These are possible solutions:
> 1. define default rendering for <wbr> as wbr::after{content:'\200B';}
> 2. avoid mentioning it in rendering at all, and state that its working is
> unrelated with CSS (i.e. it relies on UA interpretation).
>