W3C home > Mailing lists > Public > public-html@w3.org > July 2009

Re: Don't reopen active formatting elements for whitespace

From: Simon Pieters <simonp@opera.com>
Date: Wed, 29 Jul 2009 21:08:17 +0200
To: "Ian Hickson" <ian@hixie.ch>
Cc: "public-html@w3.org" <public-html@w3.org>
Message-ID: <op.uxuff3tjidj3kv@simon-pieterss-macbook.local>
On Wed, 29 Jul 2009 20:59:46 +0200, Ian Hickson <ian@hixie.ch> wrote:

> On Thu, 16 Jul 2009, Simon Pieters wrote:
>>
>> Consider the following markup (note missing </a>):
>>
>> <ul>
>> <li><a href="1">foo</li>
>> </ul>
>> <ul>
>> <li><a href="2">bar</a></li>
>> </ul>
>>
>> With an HTML5 parser this will result in 3 extra 'a' elements. Firefox  
>> 3.5
>> seems to not create them for line breaks, but does create them for tabs  
>> and
>> spaces (why?). Safari matches the spec. Recreating them screws up  
>> keyboard
>> navigation in Firefox. Safari seems to skip links that have 0 width or 0
>> height in the tab order.
>>
>> I think it would be better to not reopen formatting elements upon  
>> seeing a
>> character token that consists of just whitespace.
>>
>> Whether the leading whitespace in " x" in
>>
>> <div><a></div> x
>>
>> should be put inside the link or not I don't know. Firefox doesn't put  
>> it
>> inside the link (if it was a linebreak instead).
>
> I actually studied this quite carefully when originally writing the spec,
> and originally made whitespace not reopen formatting elements, but it
> turns out that this causes incompatibilities with IE in a number of cases
> that are quite hard to explicitly handle separately. I agree that it  
> leads
> to an unfortunate number of nodes near whitespace.

What are those cases? Do you know a page that breaks if we don't do this?

Clearly Firefox gets away with not reopening for LF characters.

-- 
Simon Pieters
Opera Software
Received on Wednesday, 29 July 2009 19:09:13 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:48 UTC