On 25.9.2012 11:09, Henri Sivonen wrote:
> This proposal removes traces of the hgroup element from the parsing
> algorithm. Even if the working group decided to remove or split into
> module the hgroup element, it would be entirely inappropriate to
> remove it from the parsing algorithm. Browsers have shipped with
> hgroup-sensitive parsers and the parsing algorithm is sensitive to
> potentially non-conforming elements that have existed at some point in
> HTML's history—e.g. plaintext and xmp.
So each feature that temporaly shown in HTML5 spec and got some more or
less experimental implementation will be forever minted in the parsing
algorithm? I see your point Henri, but there should be better approach
how to handle such situations. I understand that for legacy reasons we
need to handle plaintext, xmp, etc in the special way. But newly
proposed elements shouldn't create such legacy if possible.
Addition of hgroup was quite controversial from the start. And I don't
want to be hostage of browser vendors who at some time decided to
implement support for element without broad consensus. Of course early
implementations are important for getting feedback. But early
implementations should have impact on the HTML5 spec if feature turns
out to be useless.
What are the real practical consequences of instantiating element as
HTMLUnknownElement instead of HTMLElement? How can it break site? Are
there any sites which will get broken?
Jirka
--
------------------------------------------------------------------
Jirka Kosek e-mail: jirka@kosek.cz http://xmlguru.cz
------------------------------------------------------------------
Professional XML consulting and training services
DocBook customization, custom XSLT/XSL-FO document processing
------------------------------------------------------------------
OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 member
------------------------------------------------------------------
Received on Tuesday, 25 September 2012 09:39:58 UTC