W3C home > Mailing lists > Public > public-html@w3.org > September 2012

Re: Extension spec for hgroup (Was: Re: Getting HTML5 to Recommendation in 2014)

From: Steve Faulkner <faulkner.steve@gmail.com>
Date: Tue, 25 Sep 2012 16:24:43 +0200
Message-ID: <CA+ri+VkkT_BzANK+J0ghqTBo9sSWkyhb2UTDgrPNCtb6UWxTuQ@mail.gmail.com>
To: Henri Sivonen <hsivonen@iki.fi>
Cc: public-html WG <public-html@w3.org>
hi Henri,

I could only find 1 mention of hgroup in the section "Parsing HTML
documents" and its subsections:

I have added back that mention to


On 25 September 2012 14:44, Henri Sivonen <hsivonen@iki.fi> wrote:
> On Tue, Sep 25, 2012 at 12:24 PM, Steve Faulkner
> <faulkner.steve@gmail.com> wrote:
>> Can you be a bit more specific? So I can add the appropriate bits back in.
> I mean all changes made to the section "Parsing HTML documents" and
> its subsections:
> http://www.html5accessibility.com/HTML5extensions/HTML5.html#parsing
> On Tue, Sep 25, 2012 at 12:37 PM, Jirka Kosek <jirka@kosek.cz> wrote:
>> What are the real practical consequences of instantiating element as
>> HTMLUnknownElement instead of HTMLElement?
> That's not what I mean. Interfaces are not part of the parsing algorithm.
>> How can it break site?
> The DOM will be a different on any site that relies on hgroup implying
> a paragraph close.
>> Are there any sites which will get broken?
> I am not willing to spend time to find out when we already have
> interop across all the major engines and the problem of finding out
> could be avoided by not changing the parsing algorithm.
> On Tue, Sep 25, 2012 at 2:37 PM, Sam Ruby <rubys@intertwingly.net> wrote:
>> If retaining more of the parsing gets us to Recommendation faster, then that
>> may be a win.
> Currently, Gecko, WebKit, Presto and Trident all behave the same way
> with this example:
> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1796
> In other words, on this point, we currently have interoperability
> across the board. Changing the spec here would move us further from
> interoperability and, therefore, further from exiting the CR.
> The same consideration applies to *any* change to the “Parsing HTML
> documents” section. If it was allowed to progress on the REC track as
> an individual item, we could declare REC on the parsing algorithm
> *today* with 4 independent interoperable browser implementations.
> Therefore, instead of raising these points repeatedly about various
> individual parser changes as side effects of other proposals, I’d like
> to ask the Chairs to pre-emptively exclude the parsing section from
> removals or additions of elements for the HTML5 snapshot.
> --
> Henri Sivonen
> hsivonen@iki.fi
> http://hsivonen.iki.fi/
Received on Tuesday, 25 September 2012 14:29:01 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:27 UTC