76515 2012-01-17 21:47:19 -0800 Update HTML Parser so that <content> element should be treated transparently. 2013-01-06 19:41:35 -0800 1 1 1 Unclassified WebKit DOM 528+ (Nightly build) Unspecified Unspecified RESOLVED LATER P2 Normal --- 76434 1 hayato webcomponents-bugzilla abarth dglazkov dominicc ian morrita rolandsteiner shinyak oldest_to_newest 537617 0 hayato 2012-01-17 21:47:19 -0800 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. 537623 1 hayato 2012-01-17 21:58:52 -0800 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. 537666 2 abarth 2012-01-17 23:46:17 -0800 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. 537668 3 abarth 2012-01-17 23:50:29 -0800 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?) 537699 4 hayato 2012-01-18 01:10:18 -0800 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. 537703 5 abarth 2012-01-18 01:19:54 -0800 > 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. 537737 6 hayato 2012-01-18 02:49:52 -0800 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. 537880 7 dglazkov 2012-01-18 08:08:46 -0800 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. 538398 8 hayato 2012-01-18 18:57:09 -0800 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. 539141 9 123220 abarth 2012-01-19 16:27:34 -0800 Created attachment 123220 Sketch of possible changes (likely very broken) 801137 10 dominicc 2013-01-06 19:41:35 -0800 Per Comment 7, although the behavior is… interesting… it is per the spec. I’m closing this for now. 123220 2012-01-19 16:27:34 -0800 2012-01-19 16:27:34 -0800 Sketch of possible changes (likely very broken) bug-76515-20120119162733.patch text/plain 2475 abarth SW5kZXg6IFNvdXJjZS9XZWJDb3JlL2h0bWwvcGFyc2VyL0hUTUxDb25zdHJ1Y3Rpb25TaXRlLmNw cAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09Ci0tLSBTb3VyY2UvV2ViQ29yZS9odG1sL3BhcnNlci9IVE1MQ29uc3RydWN0 aW9uU2l0ZS5jcHAJKHJldmlzaW9uIDEwNTQ1OCkKKysrIFNvdXJjZS9XZWJDb3JlL2h0bWwvcGFy c2VyL0hUTUxDb25zdHJ1Y3Rpb25TaXRlLmNwcAkod29ya2luZyBjb3B5KQpAQCAtNzcsNiArNzcs NyBAQCBib29sIGNhdXNlc0Zvc3RlclBhcmVudGluZyhjb25zdCBRdWFsaWZpCiAgICAgICAgIHx8 IHRhZ05hbWUgPT0gdGJvZHlUYWcKICAgICAgICAgfHwgdGFnTmFtZSA9PSB0Zm9vdFRhZwogICAg ICAgICB8fCB0YWdOYW1lID09IHRoZWFkVGFnCisgICAgICAgIHx8IHRhZ05hbWUgPT0gImNvbnRl bnQiCiAgICAgICAgIHx8IHRhZ05hbWUgPT0gdHJUYWc7CiB9CiAKSW5kZXg6IFNvdXJjZS9XZWJD b3JlL2h0bWwvcGFyc2VyL0hUTUxFbGVtZW50U3RhY2suY3BwCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFNvdXJj ZS9XZWJDb3JlL2h0bWwvcGFyc2VyL0hUTUxFbGVtZW50U3RhY2suY3BwCShyZXZpc2lvbiAxMDU0 NTgpCisrKyBTb3VyY2UvV2ViQ29yZS9odG1sL3BhcnNlci9IVE1MRWxlbWVudFN0YWNrLmNwcAko d29ya2luZyBjb3B5KQpAQCAtODgsMTIgKzg4LDE0IEBAIGlubGluZSBib29sIGlzTGlzdEl0ZW1T Y29wZU1hcmtlcihDb250YWkKIGlubGluZSBib29sIGlzVGFibGVTY29wZU1hcmtlcihDb250YWlu ZXJOb2RlKiBub2RlKQogewogICAgIHJldHVybiBub2RlLT5oYXNUYWdOYW1lKHRhYmxlVGFnKQor ICAgICAgICB8fCBub2RlLT5oYXNUYWdOYW1lKCJjb250ZW50IikKICAgICAgICAgfHwgaXNSb290 Tm9kZShub2RlKTsKIH0KIAogaW5saW5lIGJvb2wgaXNUYWJsZUJvZHlTY29wZU1hcmtlcihDb250 YWluZXJOb2RlKiBub2RlKQogewogICAgIHJldHVybiBub2RlLT5oYXNUYWdOYW1lKHRib2R5VGFn KQorICAgICAgICB8fCBub2RlLT5oYXNUYWdOYW1lKCJjb250ZW50IikKICAgICAgICAgfHwgbm9k ZS0+aGFzVGFnTmFtZSh0Zm9vdFRhZykKICAgICAgICAgfHwgbm9kZS0+aGFzVGFnTmFtZSh0aGVh ZFRhZykKICAgICAgICAgfHwgaXNSb290Tm9kZShub2RlKTsKSW5kZXg6IFNvdXJjZS9XZWJDb3Jl L2h0bWwvcGFyc2VyL0hUTUxUcmVlQnVpbGRlci5jcHAKPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gU291cmNlL1dl YkNvcmUvaHRtbC9wYXJzZXIvSFRNTFRyZWVCdWlsZGVyLmNwcAkocmV2aXNpb24gMTA1NDU4KQor KysgU291cmNlL1dlYkNvcmUvaHRtbC9wYXJzZXIvSFRNTFRyZWVCdWlsZGVyLmNwcAkod29ya2lu ZyBjb3B5KQpAQCAtMTA1LDYgKzEwNSwxMiBAQCBib29sIGlzVGFibGVDZWxsQ29udGV4dFRhZyhj b25zdCBBdG9taWNTCiBib29sIGlzVGFibGVCb2R5Q29udGV4dFRhZyhjb25zdCBBdG9taWNTdHJp bmcmIHRhZ05hbWUpCiB7CiAgICAgcmV0dXJuIHRhZ05hbWUgPT0gdGJvZHlUYWcKKyAgICAgICAg Ly8gVGhpcyBpcyBwcm9ibGVtYXRpYy4uLgorICAgICAgICAvLyBZb3Ugd2FudCBjb250ZW50IHRv IGJlIG9uIHRoaXMgbGlzdCBpbiBhIGJ1bmNoIG9mIHBsYWNlcywgYnV0IEkKKyAgICAgICAgLy8g dGhpbmsgdGhlcmUncyBzb21lIGNvZGUgcHJldmVudGluZyB0YWJsZSBib2R5IGNvbnRleHQgdGFn cyBmcm9tCisgICAgICAgIC8vIGJlaW5nIG5lc3RlZCBpbnNpZGUgZWFjaCBvdGhlciAod2hpY2gg eW91J2xsIG5lZWQgdG8gZ2V0IDx0Ym9keT4KKyAgICAgICAgLy8gaW5zaWRlIDxjb250ZW50Piku CisgICAgICAgIHx8IHRhZ05hbWUgPT0gImNvbnRlbnQiCiAgICAgICAgIHx8IHRhZ05hbWUgPT0g dGZvb3RUYWcKICAgICAgICAgfHwgdGFnTmFtZSA9PSB0aGVhZFRhZzsKIH0KQEAgLTEwOTIsNiAr MTA5OCwxMSBAQCB2b2lkIEhUTUxUcmVlQnVpbGRlcjo6cHJvY2Vzc1N0YXJ0VGFnRm9yCiAgICAg ICAgIHByb2Nlc3NTdGFydFRhZyh0b2tlbik7CiAgICAgICAgIHJldHVybjsKICAgICB9CisgICAg aWYgKHRva2VuLm5hbWUoKSA9PSAiY29udGVudCIpIHsKKyAgICAgICAgbV90cmVlLm9wZW5FbGVt ZW50cygpLT5wb3BVbnRpbFRhYmxlU2NvcGVNYXJrZXIoKTsKKyAgICAgICAgbV90cmVlLmluc2Vy dEhUTUxFbGVtZW50KHRva2VuKTsKKyAgICAgICAgcmV0dXJuOworICAgIH0KICAgICBpZiAoaXNU YWJsZUJvZHlDb250ZXh0VGFnKHRva2VuLm5hbWUoKSkpIHsKICAgICAgICAgbV90cmVlLm9wZW5F bGVtZW50cygpLT5wb3BVbnRpbFRhYmxlU2NvcGVNYXJrZXIoKTsKICAgICAgICAgbV90cmVlLmlu c2VydEhUTUxFbGVtZW50KHRva2VuKTsK