Implement Element.innerHTML setter

[jdm]

Needed for #841.

[jdm]

@jaeminMoon Just work on the getter to start with: http://mxr.mozilla.org/servo/source/src/components/script/dom/element.rs#364 . https://developer.mozilla.org/en-US/docs/Web/API/Element.innerHTML

[Ms2ger]

http://domparsing.spec.whatwg.org/#innerhtml

[jdm]

For the setter, we should make hubbub_html_parser::parse_html (http://mxr.mozilla.org/servo/source/src/components/script/html/hubbub_html_parser.rs#248) take a root node argument instead of creating an HTMLHtmlElement node by default.

[tetsuharuohzeki]

Does anyone start to work this?

[jdm]

Yes, @jaeminMoon is working on it.

[bzbarsky]

It's not just taking a root node argument. To get correct behavior you have to set up the parsing context based on the target node, then parse into a DocumentFragment, then replace the node's kids with the fragment.

In particular, parsing into the DocumentFragment can throw, and in that case the node's kids should not be affected, which is pretty hard to do if you're parsing directly into the node.

[jdm]

Is "parsing context" a spec concept I should be familiar with?

[jdm]

@Adenilson is working on this.

[Adenilson]

So the game plan: refactor parse_html() to be more modular and decoupled, targeting to reuse the code while receiving a DOMString in innerHTML. Restrictions: allow the code to be upgraded when the new HTML parser lands.

There are really 3 steps on it:
a) Move parser creation to its own function.
b) Do the same for the TreeHandler.
c) Use this in innerHTML (as a new exported API in element.rs/Element.webidl).

[jdm]

Further notes for the benefits of NCSU students who may be working on this (@Adenilson, please talk to me before continuing to work on this):

• make parse_html take a Node instead of Document; modify the code that requires a Document to use a dynamic cast (DocumentCast::to_ref)
• make the innerHTML setter create a new DocumentFragment
• prepend the setter value with <[tagName] id="___secret_servo_id___"> and append </tagName>
• call parse_html on the modified setter value with the new DocumentFragment
• remove all existing children of the current element
• find the element with the special id in the children of the DocumentFragment and adopt all child nodes into the containing element on which innerHTML was set
• use the result of parse_html to fetch any new JS scripts and execute them

(note, adapted from http://www.whatwg.org/specs/web-apps/current-work/multipage/syntax.html#html-fragment-parsing-algorithm)

[Ms2ger]

I'm not convinced this won't require a lot of rewriting when we land the new HTML parser.

[Adenilson]

@jdm Sure, when I resume work on this, I will be coordinating with you guys.

@Ms2ger yes and no... Let me explain it better. I didn't pursued this in part because I was hoping that the new parser would land soon. That being said, the new parser will need to support the user case i.e. receive a Node (as also a Document), and by having the interfaces available would be a matter of swapping the Hubbub based parser for the new one.

[kmcallister]

The new parser will land shortly after the next Rust upgrade. It's designed to handle fragment parsing, but there are a few pieces missing; see kmcallister/html5ever#16.

[jdm]

@eddyb Is this something you were seriously looking into? I know @cparis expressed interest in working on it, and it's quite high on our list of priorities right now.

[eddyb]

Well, I do have partial fragment parsing implemented right now, if you want me to publish that. Needs a few changes to html5ever though, so I would prefer to do it immediately after a rustup, unless someone wants to help me with backporting changes, or applying them directly to servo's branch.
The big thing missing is determining the initial insertion mode from the context, but if the context is made of only the outer element's tag, then it's likely just a couple more lines in html5ever.

Well, I've decided to push what I have so far (cc @cparis): html5ever and servo.

[kmcallister]

Needs a few changes to html5ever though, so I would prefer to do it immediately after a rustup, unless someone wants to help me with backporting changes

Ah, I see your changes to html5ever are quite small. You can go ahead and submit that as a PR against master. Then we'll reset branch servo to master, and revert rustup patches from master as necessary.

[kmcallister]

This is fixed by #4888 \o/