[whatwg] Augmenting HTML parser to recognize new elements

On Fri, Jan 20, 2012 at 7:03 AM, Henri Sivonen <hsivonen at iki.fi> wrote:
> On Wed, Jan 18, 2012 at 8:19 PM, Dimitri Glazkov <dglazkov at chromium.org> wrote:
>> A typical example would be specifying an insertion point (that's
>> <content> element) as child of a <table>:
>>
>> <table>
>> ? ?<content>
>> ? ? ? ?<tr>
>> ? ? ? ? ? ?...
>> ? ? ? ?</tr>
>> ? ?</content>
>> </table>
>>
>> Both <shadow> and <template> elements have similar use cases.
>
> This doesn't comply with the Degrade Gracefully design principle. Is
> this feature so important that it's reasonable to change table parsing
> (one of the annoying parts of the parsing algorithm) in a way that'd
> make the modified algorithm yield significantly different results than
> existing browsers?

This is a good question. It is not strictly necessary to change the
parsing, since one could always construct the desired tree
imperatively as a workaround. However, this does lead to unpleasant
surprises for those attempting to use shadow DOM insertion points
declaratively.

There are use cases that will require dealing with tables and other
tags that have special insertion modes. A while back, Boris had
mentioned replacing tables with charts
(http://www.w3.org/2008/webapps/wiki/Component_Model_Use_Cases#Table-based_Charts).
Should the developer decide to still include table data somewhere in
the chart, they may wish to put something like this in their shadow
DOM subtree:

...
<table>
   <content>
      <tr><td>No data</td></tr>
   </content>
</table>
...

Without parser modifications, they would need to build this structure
using JS+DOM methods.

> Have designs that don't require changes to table
> parsing been explored?

At one point, we considered using collapsed DOM ranges to represent
insertion points. However, this sidesteps possibilities of declarative
syntax and thus didn't seem viable.

As the next step, I will gather some developer feedback on the degree
of unpleasantness arising from parsing behavior, and document it to
better understand possible opportunities for improvement. Sounds good?

>
>> What would be the sane way to document such changes to the HTML parser
>> behavior?
>
> A change to the HTML spec proper *if* we decide that changes are a good idea.
>
> --
> Henri Sivonen
> hsivonen at iki.fi
> http://hsivonen.iki.fi/

Received on Friday, 20 January 2012 10:22:15 UTC