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

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?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 4 June 2012 23:39:02 UTC