Re: Proposal: Document.parse() [AKA: Implied Context Parsing]

On Mon, Jun 4, 2012 at 4:38 PM, Ian Hickson <ian@hixie.ch> wrote:
> On Mon, 4 Jun 2012, Rafael Weinstein wrote:
>>
>> Just to be clear: what you are objecting to is the addition of formal
>> API for this.
>>
>> You're generally supportive of adding a <template> element whose
>> contents would parse the way we're discussing here -- and given that, a
>> webdev could trivially polyfil Document.parse().
>
> Sure.
>
>
>> I.e. you're ok with the approach of the parser picking a context element
>> based on the contents of markup, but against giving webdevs the
>> impression that innerHTML is good practice, by adding more API in that
>> direction?
>
> Right.
>
>
>> Put another way, though you're not happy with adding the API, you
>> willing to set that aside and help spec the parser changes required for
>> both this and <template> element (assuming the remaining issues with
>> <template> can be agreed upon)?
>
> I think <template> is important. If implementing that happens to make it
> easier for a script to implement a bad practice, so be it.
>
> (See my e-mail on the <template> thread for comments on that subject.)
>
>
>> FWIW, I agree with Hixie in principle, but disagree in practice. I
>> think innerHTML is generally to be avoided, but I feel that adding
>> Document.parse() improves the situation by making some current uses
>> (which aren't likely to go away) less hacky.
>
> If we want to make things less hacky, let's actually make them less
> hacky, not introduce more APIs that suck.
>
>
>> Also, I'm not as worried with webdevs taking the wrong message from us
>> adding API. My feeling is that they just do what works best for them and
>> don't think much about what we are or are not encouraging.
>
> I strongly disagree on that. Whether consciously or not, we set the
> standard for what is good practice. I've defintely seen authors look at
> the standards community for leadership. Just look at how authors adopted
> XHTML's syntax, even in the absence of actually using XHTML. It was such a
> tidal wave that we ended up actually changing HTML's conformance criteria
> to ignore the extra characters rather than say they were invalid. Why?
> Because XHTML was what the W3C was working on, so it must have been good,
> even though objectively it really added no semantics (literally nothing,
> the language was defined by deferring to HTML4) and the syntax changes
> were a net negative.
>
>
>> Also, I'm highly supportive of the goal of allowing HTML literals in
>> script. I fully agree that better load ("compile") time feedback would
>> be beneficial to authors here.
>
> Let's do it! As far as I can tell, the impact on a JS parser would be
> pretty minimal.
>
>   http://www.hixie.ch/specs/e4h/strawman
>
> Who wants to be first to implement it?

Doesn't e4h have the same security problems as e4x?

Adam

Received on Tuesday, 5 June 2012 00:11:07 UTC