Re: [whatwg] HTML spec incorrectly suggests that br can have its rendering changed with CSS
[ resending this message, originally dated Date: Tue, 29 Apr 2014
11:42:10 -0700, since I just noticed it didn't make it through to
the list due to the list's content-type filters rejecting signed
messages ]
On Tuesday 2014-04-29 17:55 +, Ian Hickson wrote:
On Wed, 29 Jan 2014, Tab Atkins Jr. wrote:
We talked this over in the CSSWG meeting, and came up with a proposal
for non-magical styling that is still very close to current behavior in
all browsers:
br {
display-box: contents;
content: \A;
white-space: pre;
}
I've filed a bug to track this. It would be useful if browser vendors
could indicate whether they think Tab's proposal is satisfactory (in
particular, is 'display-box' something that browsers will implement?
Apparently Gecko is doing it, anyone else?).
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25503
I might not want to implement br this way, since display-box:
contents involves a bit of complexity that I wouldn't want to impose
on such a common element. Then again, we could perhaps special-case
br inside the implementation of display-box: contents. But it's
not just a trivial matter of removing the existing br
implementation and replacing it with the above.
-David
--
턞 L. David Baron http://dbaron.org/ 턂
턢 Mozilla https://www.mozilla.org/ 턂
Before I built a wall I'd ask to know
What I was walling in or walling out,
And to whom I was like to give offense.
- Robert Frost, Mending Wall (1914)
Re: [whatwg] HTML spec incorrectly suggests that br can have its rendering changed with CSS
This discussion focused around the various behaviours that browsers have
around the rendering of br.
On Thu, 23 Jan 2014, Boris Zbarsky wrote:
What Gecko does with br is basically to treat it like a special box
type that has special sizing/painting/linebreak behavior. But we do
still allow that box to be positioned/floated, just like an img...
On Tue, 28 Jan 2014, Elliott Sprehn wrote:
Blink treats br (conceptually) like a subclass of Text, there's
nothing to style because it's just a run of text with a forced break.
On Wed, 29 Jan 2014, Tab Atkins Jr. wrote:
We talked this over in the CSSWG meeting, and came up with a proposal
for non-magical styling that is still very close to current behavior in
all browsers:
br {
display-box: contents;
content: \A;
white-space: pre;
}
I've filed a bug to track this. It would be useful if browser vendors
could indicate whether they think Tab's proposal is satisfactory (in
particular, is 'display-box' something that browsers will implement?
Apparently Gecko is doing it, anyone else?).
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25503
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTML spec incorrectly suggests that br can have its rendering changed with CSS
On Wed, Jan 22, 2014 at 1:51 PM, Daniel Holbert dholb...@mozilla.com wrote:
Hi folks,
Boris Zbarsky and I ran across a not reflecting reality issue in the
WHATWG HTML spec.
The spec currently defines the rendering of the br element as follows:
# br { content: '\A'; white-space: pre; }
Source:
http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#phrasing-content-1
This CSS implies that br's rendering could be customized by CSS, which
in practice (in the browsers that I tested[1]) is not actually the case.
We talked this over in the CSSWG meeting, and came up with a proposal
for non-magical styling that is still very close to current behavior
in all browsers:
br {
display-box: contents;
content: \A;
white-space: pre;
}
This lets you adjust the size of the br with text-styling
properties, and use display:none to hide it entirely. Any/all of
these can be set to !important if necessary for compat.
~TJ
Re: [whatwg] HTML spec incorrectly suggests that br can have its rendering changed with CSS
On Thu, Jan 23, 2014 at 10:54 AM, Daniel Holbert dholb...@mozilla.comwrote: On 01/23/2014 03:16 AM, Stewart Brodie wrote: [2] I only noticed one rendering difference -- IE11 honors border on br, unlike the other browsers that I tested. (It still doesn't honor e.g. display/width/height, though.) I get different results on your test case for the bottom two tests. In Chrome 33 and Opera 12.16 (Linux), there is a line break; in Firefox 26 there isn't. Yeah -- sorry, I thought up those last two testcases (applying float and position:absolute to br) a bit later, after I sent my initial email. (which is why I didn't mention them as a rendering difference) So, the position float properties do represent a little bit of style that Gecko honors on br (but not Blink/Presto; not sure about IE). Blink treats br (conceptually) like a subclass of Text, there's nothing to style because it's just a run of text with a forced break. - E
Re: [whatwg] HTML spec incorrectly suggests that br can have its rendering changed with CSS
On Tue, Jan 28, 2014 at 1:04 AM, Elliott Sprehn espr...@gmail.com wrote: On Thu, Jan 23, 2014 at 10:54 AM, Daniel Holbert dholb...@mozilla.comwrote: On 01/23/2014 03:16 AM, Stewart Brodie wrote: [2] I only noticed one rendering difference -- IE11 honors border on br, unlike the other browsers that I tested. (It still doesn't honor e.g. display/width/height, though.) I get different results on your test case for the bottom two tests. In Chrome 33 and Opera 12.16 (Linux), there is a line break; in Firefox 26 there isn't. Yeah -- sorry, I thought up those last two testcases (applying float and position:absolute to br) a bit later, after I sent my initial email. (which is why I didn't mention them as a rendering difference) So, the position float properties do represent a little bit of style that Gecko honors on br (but not Blink/Presto; not sure about IE). Blink treats br (conceptually) like a subclass of Text, there's nothing to style because it's just a run of text with a forced break. Okay, so FF treats it as an element with a magical 'display' type, and Chrome treats it as equivalent to text. These are observably different. Are either of you willing to switch to the other's behavior? That would make my life way easier, thanks. ~TJ
Re: [whatwg] HTML spec incorrectly suggests that br can have its rendering changed with CSS
On 1/28/14 1:04 AM, Elliott Sprehn espr...@gmail.com wrote:
Blink treats br (conceptually) like a subclass of Text, there's nothing
to style because it's just a run of text with a forced break.
I'd just like to note that 'inline' styling for br should be allowed.
I have been using it for a long time as spacing adjustment, and
sometimes for addressing extra unwanted space with double br entries
from wysiwyg, with the following rule:
style
br { font-size: 8px; line-height: 8px; }
/style
To my recollection such styling was/is applied in all browsers.
Not sure if line-height is considered 'styling' in those terms, but just
want to mention that historical use case of applied styling on br.
Re: [whatwg] HTML spec incorrectly suggests that br can have its rendering changed with CSS
Daniel Holbert dholb...@mozilla.com wrote:
So: to reflect reality, it might be better to specify br in a way that
doesn't suggest it's as customizable with CSS. (for the white-space
property in particular, but probably others as well)
For reference, here's a page with a few testcases:
http://people.mozilla.org/~dholbert/tests/br-tests.html
The browsers that I tested[1] all agree on the rendering (basically, not
honoring any of the br styling), with one minor exception[2].
Thanks,
~Daniel
[1] I tested the following browsers:
Firefox 26
Opera 12.16
Chrome 34.0.1788.0 dev
IE 11
[2] I only noticed one rendering difference -- IE11 honors border on
br, unlike the other browsers that I tested. (It still doesn't honor
e.g. display/width/height, though.)
I get different results on your test case for the bottom two tests. In
Chrome 33 and Opera 12.16 (Linux), there is a line break; in Firefox 26
there isn't.
This matches a fault report that we had from a customer a few years about a
page that didn't lay out properly in our browser (but did in Opera) that I
tracked down to being that we permitted br elements to be styled, just like
Firefox (26.0) does. I've put a suitably anonymised version of the test
case on my own website:
http://www.metahusky.net/~stewart/css/br/br-rendering.html
And yes, the real page really did have the first line of its stylesheet as:
* { position: absolute; margin: 0px; float: left }
--
Stewart Brodie
Team Leader - ANT Galio Browser
ANT Software Limited
Re: [whatwg] HTML spec incorrectly suggests that br can have its rendering changed with CSS
On 1/23/14 6:16 AM, Stewart Brodie wrote: I get different results on your test case for the bottom two tests. In Chrome 33 and Opera 12.16 (Linux), there is a line break; in Firefox 26 there isn't. Indeed. What Gecko does with br is basically to treat it like a special box type that has special sizing/painting/linebreak behavior. But we do still allow that box to be positioned/floated, just like an img... -Boris
Re: [whatwg] HTML spec incorrectly suggests that br can have its rendering changed with CSS
On 01/23/2014 03:16 AM, Stewart Brodie wrote: [2] I only noticed one rendering difference -- IE11 honors border on br, unlike the other browsers that I tested. (It still doesn't honor e.g. display/width/height, though.) I get different results on your test case for the bottom two tests. In Chrome 33 and Opera 12.16 (Linux), there is a line break; in Firefox 26 there isn't. Yeah -- sorry, I thought up those last two testcases (applying float and position:absolute to br) a bit later, after I sent my initial email. (which is why I didn't mention them as a rendering difference) So, the position float properties do represent a little bit of style that Gecko honors on br (but not Blink/Presto; not sure about IE). ~Daniel
Re: [whatwg] HTML spec incorrectly suggests that br can have its rendering changed with CSS
On 1/23/14 1:54 PM, Daniel Holbert wrote: So, the position float properties do represent a little bit of style that Gecko honors on br (but not Blink/Presto; not sure about IE). IE11 shows linebreaks on your last two testcases there. -Boris
[whatwg] HTML spec incorrectly suggests that br can have its rendering changed with CSS
Hi folks,
Boris Zbarsky and I ran across a not reflecting reality issue in the
WHATWG HTML spec.
The spec currently defines the rendering of the br element as follows:
# br { content: '\A'; white-space: pre; }
Source:
http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#phrasing-content-1
This CSS implies that br's rendering could be customized by CSS, which
in practice (in the browsers that I tested[1]) is not actually the case.
In particular: given the spec's CSS quoted above, you might expect that
perhaps an author could set...
white-space: nowrap
... on a br element, to neuter the linebreak. That doesn't work,
though -- the br still triggers a linebreak. Similarly, you might also
expect to be able to customize the 'display' or 'height'/'width' or
'background' properties, but in practice, none of those have any effect
on br in modern browsers.
So: to reflect reality, it might be better to specify br in a way that
doesn't suggest it's as customizable with CSS. (for the white-space
property in particular, but probably others as well)
For reference, here's a page with a few testcases:
http://people.mozilla.org/~dholbert/tests/br-tests.html
The browsers that I tested[1] all agree on the rendering (basically, not
honoring any of the br styling), with one minor exception[2].
Thanks,
~Daniel
[1] I tested the following browsers:
Firefox 26
Opera 12.16
Chrome 34.0.1788.0 dev
IE 11
[2] I only noticed one rendering difference -- IE11 honors border on
br, unlike the other browsers that I tested. (It still doesn't honor
e.g. display/width/height, though.)
Re: [whatwg] HTML spec incorrectly suggests that br can have its rendering changed with CSS
Note: part of the motivation for this concern is that the CSS Flexbox
spec likely needs a bit of tweaking to indicate how br elements in
runs of raw text should be handled, as I noted in this post to www-style:
http://lists.w3.org/Archives/Public/www-style/2014Jan/0317.html
...and the new spec text there may likely be impacted by how br itself
is specced.
~Daniel
On 01/22/2014 01:51 PM, Daniel Holbert wrote:
Hi folks,
Boris Zbarsky and I ran across a not reflecting reality issue in the
WHATWG HTML spec.
The spec currently defines the rendering of the br element as follows:
# br { content: '\A'; white-space: pre; }
Source:
http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#phrasing-content-1
This CSS implies that br's rendering could be customized by CSS, which
in practice (in the browsers that I tested[1]) is not actually the case.
In particular: given the spec's CSS quoted above, you might expect that
perhaps an author could set...
white-space: nowrap
... on a br element, to neuter the linebreak. That doesn't work,
though -- the br still triggers a linebreak. Similarly, you might also
expect to be able to customize the 'display' or 'height'/'width' or
'background' properties, but in practice, none of those have any effect
on br in modern browsers.
So: to reflect reality, it might be better to specify br in a way that
doesn't suggest it's as customizable with CSS. (for the white-space
property in particular, but probably others as well)
For reference, here's a page with a few testcases:
http://people.mozilla.org/~dholbert/tests/br-tests.html
The browsers that I tested[1] all agree on the rendering (basically, not
honoring any of the br styling), with one minor exception[2].
Thanks,
~Daniel
[1] I tested the following browsers:
Firefox 26
Opera 12.16
Chrome 34.0.1788.0 dev
IE 11
[2] I only noticed one rendering difference -- IE11 honors border on
br, unlike the other browsers that I tested. (It still doesn't honor
e.g. display/width/height, though.)
Re: [whatwg] HTML spec incorrectly suggests that br can have its rendering changed with CSS
On Wed, 22 Jan 2014, Daniel Holbert wrote:
Boris Zbarsky and I ran across a not reflecting reality issue in the
WHATWG HTML spec.
The spec currently defines the rendering of the br element as follows:
# br { content: '\A'; white-space: pre; }
Source:
http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#phrasing-content-1
This CSS implies that br's rendering could be customized by CSS, which
in practice (in the browsers that I tested[1]) is not actually the case.
Yeah, this is intentional. The spec is trying to point the way for
browsers to go in. :-)
Right now, 'content' isn't even defined as applying to elements; the HTML
spec is relying on somewhat well-established theory for future expansion
of the 'content' property. The idea is that, on the long term, we can
explain br in terms of regular CSS. (I similarly hope we can do this
with form controls, but form controls right now have behaviours that can't
even be explained by theoretical CSS, as far as I can tell.)
In particular: given the spec's CSS quoted above, you might expect that
perhaps an author could set...
white-space: nowrap
... on a br element, to neuter the linebreak. That doesn't work,
though -- the br still triggers a linebreak.
Right. If allowing this isn't Web compatible, then I guess we'll have to
change.
Similarly, you might also
expect to be able to customize the 'display' or 'height'/'width' or
'background' properties, but in practice, none of those have any effect
on br in modern browsers.
In isolation, 'height' and 'width' would have no effect (they don't apply
to display:inline elements) and 'background' would not have a visible
effect (the element has no effective width). 'display', though, in theory,
should have an effect. If allowing this isn't Web compatible, then I guess
we'll have to change.
My hope is that we can limit what needs to have no effect, so that on the
long term br becomes less and less magical. But naturally this depends
on what is Web compatible.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
