- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 17 Nov 2011 14:27:02 -0800
On Thu, Nov 17, 2011 at 2:22 PM, Rafael Weinstein <rafaelw at chromium.org> wrote: > On Thu, Nov 17, 2011 at 12:50 PM, Tab Atkins Jr. <jackalmage at gmail.com> wrote: >> On Thu, Nov 17, 2011 at 11:15 AM, Rafael Weinstein <rafaelw at chromium.org> wrote: >>> For parsing, the template element's contents are treated as HTML, but >>> aren't subjected to normalization or placement/lifting rules. >> >> For the placement/lifting rules, we can ride on the coattails of the >> innerHTML parsing discussion, which wants to add a "null context" >> parsing mode to the HTML parser. >> >> What's the reasoning for not doing attribute normalization? ?By that I >> assume you mean translating boolean attributes into having their name >> as their value? > > Many inert declarations will contain text in content attributes which > represent future replacement instructions. E.g. > > <input tabIndex="{{ foo.bar.tabIndex }}"> > > Note that I'm picking an arbitrary replacement syntax here. Different > template libraries or uses of inert DOM will have different syntax. > The key is that the inert DOM is parse-able as HTML, but that the > contents of attributes and text nodes are left alone while the > elements are in the inert state (kept verbatim in the attribute map) > > I think it's an expectable trade-off for all uses that their > replacement syntax can't interfere with HTML parsing, as what they get > from this is quite a bit of convenience and safety. Oh, I see what you mean now. Yes, agreed. ~TJ
Received on Thursday, 17 November 2011 14:27:02 UTC