Bug 76515 – Update HTML Parser so that <content> element should be treated transparently.

• Status: RESOLVED
• Resolution: LATER
• Component: DOM

[Hayato Ito]

Suppose we have <content> element and given the following HTML:

<table>
  <content>
    <td>hello</td>
  </content>
</table>


In the current HTML parser implementation, the result DOM tree would become:

<content>
</content>
<table>
 <tbody>
    <tr>
      <td>hello</td>
    </tr>
  </tbody>
</table>

Yeah, <content> elements would be put outside of <table> element.

The result should be something like this:
<table>
  <content>
        <td>hello</td>
  </content>
</table>

I am not sure whether we should add <tbody> or <tr> somewhere in this particular case.
At least, current implementation should be modified somehow.

[Hayato Ito]

I found the related spec here:

http://www.whatwg.org/specs/web-apps/current-work/multipage/parsing.html#insertion-mode

So we might modify this spec or add some description to shadow DOM spec.

[Adam Barth]

Changing the parser is a delicate matter.  Please coordinate any parser changes with Hixie.  We prefer to keep our implementation in close sync with the spec.

[Adam Barth]

Is there something I can read so I can understand what changes you'd like to make to the parser and what problem they solve?  (Maybe something in the Explainer is relevant here?)

[Hayato Ito]

Okay. Although I don't have clear explanations yet about what the problem is exactly and what we should solve it, let me explain use cases using some examples.
I might update later after I've read related specs carefully.

Suppose we have the following component: (See https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html for shadow DOM spec). 

<div> - component (shadow-host)
   <td>light children1</td>
   <td>light children2</td>
   [shadow-root] - template follows:
       <table>  
         <content select='xxxx'>
            <!- this is fallback elements -->
            <td>td1</td>
            <td>td2</td>
         </content>
         <td>td3</td>
       </table>


If <content> element is replaced with the light children, this component should be rendered as if the given html was given:
  <div>
    <table>
      <tdoby>
        <tr>
          <td>light children1</td>
          <td>light children2</td>
          <td>td3</td>
        </tr>
      <tdoby>
    </table>
  </div>


If <content> element is not replaced, this component should be rendered as if the given html was given:
  <div>
    <table>
      <tdoby>
        <tr>
          <td>td1</td>
          <td>td2</td>
          <td>td3</td>
        </tr>
      <tdoby>
    </table>
  </div>

To achieve it, what dom tree should HTML Parser generate when parsing the template?
According to the current spec, <content> element is *invalid* in "IN_TABLE" mode when parsing, so <content> element would be inserted outside of <table> element like this:  (See also http://www.whatwg.org/specs/web-apps/current-work/multipage/tree-construction.html#foster-parenting)

   <content select='xxxx'>
   </content>
   <table>  
     <tbody>
       <tr>
          <!- this is fallback elements -->
          <td>td1</td>
          <td>td2</td>
          <td>td3</td>
       </tr>
     </tdoby>
   </table>

This is undesirable result. We lost the position of <content> element. So we should treat <content> element specially in <table> or such elements.
* Note that <tdoby> and <tr> elements are inserted by parser.

So what DOM tree should the parser generate in this case? I've come up three rough ideas.

1). Insert <tbody> and <tr> inside of <content> element.

    <table>  
      <content select='xxxx'>
        <tdoby>
          <tr>
            <td>td1</td>
            <td>td2</td>
          </tr>
        </tbody>
       </content>
       <td>td3</td>
    </table>

This is apparently wrong in this case.


2). Insert <tbody> and <tr> outside of <content> element and its siblings.

    <table>  
      <tdoby>
        <tr>
          <content select='xxxx'>
            <td>td1</td>
            <td>td2</td>
          </content>
          <td>td3</td>
        </tr>
      </tbody>
    </table>

This looks good in this case.


3). Avoid such auto-inserting elements across <content> elements. Return DOM tree 'as is'.

    <table>  
      <content select='xxxx'>
          <td>td1</td>
          <td>td2</td>
       </content>
       <td>td3</td>
    </table>

This is ideal one? Can we achieve that?


Please correct or add anything if you find. I might miss something. I don't understand how such modification for the parser is tough.

[Adam Barth]

> I don't understand how such modification for the parser is tough.

It's not the modifications themselves that are tough, it's understanding all the consequences.  Have you considered how these documents will be handled by user agents that don't understand these new parsing rules?  What about other insertion modes besides InTable?

I'm very hesitant to make changes to the parser without those changes first appearing in the HTML living standard.  The cost of having our parser diverge from the standard and from all the other browsers (who now implement the standard) is much higher than in other areas, such as JavaScript APIs.

[Hayato Ito]

Hi Adam, thank you for the comment.

I totally agree your concerns. We have to consider all the consequences in addition to the spec change.
Let us continue to pursuit what should be done and use this bug for tracking the issue and updating the status.


(In reply to comment #5)
> > I don't understand how such modification for the parser is tough.
> 
> It's not the modifications themselves that are tough, it's understanding all the consequences.  Have you considered how these documents will be handled by user agents that don't understand these new parsing rules?  What about other insertion modes besides InTable?
> 
> I'm very hesitant to make changes to the parser without those changes first appearing in the HTML living standard.  The cost of having our parser diverge from the standard and from all the other browsers (who now implement the standard) is much higher than in other areas, such as JavaScript APIs.

[Dimitri Glazkov (Google)]

I think this is a bit of a cart-before-horse situation here. The spec as I wrote it doesn't -- yet -- specify any changes to the parser.

[Hayato Ito]

I know we are starting the discussion in other place,  
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-January/034410.html

but let me add one more note here because the example I used in the explanation might not be good example.
Focus on the shadow host itself, ignoring shadow tree:

 <div>
   <td>light children1</td>
   <td>light children2</td>
 </div>

This is totally invalid. If this host tree is parsed, <td> is gone because it do not appear in IN_TABLE mode. That becomes just a text node like:
 
 <div>
   light children1
   light children2
 </div>

So we can not use light children which are valid only when inserted into <content>.
I just want to let you notify this limitation and my example is not good one.

[Adam Barth]

Created attachment 123220 [details]
Sketch of possible changes (likely very broken)

[Dominic Cooney]

Per Comment 7, although the behavior is… interesting… it is per the spec. I’m closing this for now.