[Webkit-unassigned] [Bug 76515] Update HTML Parser so that <content> element should be treated transparently.

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=76515





--- Comment #4 from Hayato Ito <hayato at chromium.org>  2012-01-18 01:10:18 PST ---
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.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.