[Bug 28170] Reference to CSS element content in <br> and <wbr> rendering

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28170

--- Comment #11 from Tab Atkins Jr. <jackalmage@gmail.com> ---
(In reply to Andrea Rendine from comment #9)
> (In reply to Tab Atkins Jr. from comment #8)
> > in terms of properties that aren't implemented yet
> Nor present in official specifications, in this case.
> 
> > sufficiently expensive that browsers won't implement them in the existing terms
> On <span> elements it is possible to simulate <br> elements. Internet
> Explorer and Mozilla Firefox also simulate <wbr> the same way. Of course if
> other browsers implement a UA stylesheet they will also implement this
> rendering.
> 
> > That only works for <br>
> See above.

Ah, sorry, yeah, <wbr> is doable with 'content'.

> > it's possible today to have a "br::after {...}" rule in your page
> Chrome, IE (all modern versions), FF and Opera don't allow rendering for
> br::after{}. Due to the "magic" of the element, probably, it doesn't allow
> pseudo-elements, so I don't think anybody has used it, as it'd be useless.
> 
> > the use of 'content'/etc is actually rather slow and unoptimized
> Is it possible to predict that {display-outside} is implemented more
> efficiently? Only in that case this assumption is correct.

It's not just predictable, it's the explicit reason that browser vendors gave
for why they'd prefer a 'display' value.

The rendering of <br> is actually handled specially, in the text rendering
code, to make it fast.  Handling a U+000A character in a white-space:pre
element is slower.  Thus, implementing <br> in terms of the latter, instead of
with the special fast-path, would slow things down.

Implementing it with a special display value is slightly slower than just
looking at the tagname, but it's much simpler overall - it's a single keyword
on a non-inherited property that needs to be calculated early anyway.

Browsers could, with some difficulty, do more advanced detection, detect the
particular combination of properties that <br> has, and use that to do the
fast-path linebreak, but it's a lot of complexity for very little gain. Much
easier to just add a new display value.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 10 March 2015 01:37:11 UTC