254
edits
Platform/XML Rewrite: Difference between revisions
→Fragment parsing
| Line 83: | Line 83: | ||
On the HTML side, nsHtml5Parser also supports fragment parsing, but that functionality doesn't really benefit from being in the class that's oriented towards full page loading, so I think even on the HTML side, the fragment parsing functionality should be separated from nsHtml5Parser. I think it's not worthwhile to avoid using the tree op executor mechanism, though, since avoiding it would lead to a lot of code duplication. I think both HTML and XML should have distinct fragment parsing entry points in separate classes but the code for generating tree ops and executing them should be shared with the Web content network stream parsing code paths. | On the HTML side, nsHtml5Parser also supports fragment parsing, but that functionality doesn't really benefit from being in the class that's oriented towards full page loading, so I think even on the HTML side, the fragment parsing functionality should be separated from nsHtml5Parser. I think it's not worthwhile to avoid using the tree op executor mechanism, though, since avoiding it would lead to a lot of code duplication. I think both HTML and XML should have distinct fragment parsing entry points in separate classes but the code for generating tree ops and executing them should be shared with the Web content network stream parsing code paths. | ||
==XSLT and XHR== | |||
The document that is given as input to an XSLT program and the document loaded via XHR are currently built by nsXMLContentSink. In the new world, they'd use the tree op mechanism instead like other things that currently use nsXMLContentSink. | |||