W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2014

Re: [whatwg] HTML spec incorrectly suggests that <br> can have its rendering changed with CSS

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 28 Jan 2014 07:55:16 -0800
Message-ID: <CAAWBYDC++Mv-uVsr5B_w4mHOtJRGVJkXtwCBQojZYO8oQLp1tg@mail.gmail.com>
To: Elliott Sprehn <esprehn@gmail.com>
Cc: Daniel Holbert <dholbert@mozilla.com>, WHATWG <whatwg@whatwg.org>
On Tue, Jan 28, 2014 at 1:04 AM, Elliott Sprehn <esprehn@gmail.com> wrote:
> On Thu, Jan 23, 2014 at 10:54 AM, Daniel Holbert <dholbert@mozilla.com>wrote:
>> 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
Received on Tuesday, 28 January 2014 15:56:03 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:15 UTC