[whatwg] HTML spec incorrectly suggests that <br> can have its rendering changed with CSS
Tab Atkins Jr.
jackalmage at gmail.com
Tue Jan 28 07:55:16 PST 2014
On Tue, Jan 28, 2014 at 1:04 AM, Elliott Sprehn <esprehn at gmail.com> wrote:
> On Thu, Jan 23, 2014 at 10:54 AM, Daniel Holbert <dholbert at mozilla.com>wrote:
>> On 01/23/2014 03:16 AM, Stewart Brodie wrote:
>> >>  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.
More information about the whatwg