254
edits
Platform/XML Rewrite: Difference between revisions
Jump to navigation
Jump to search
no edit summary
No edit summary |
|||
| Line 24: | Line 24: | ||
* Glue code that produces tree ops from what the portable core does (nsHtml5TreeBuilderCppSupplement) | * Glue code that produces tree ops from what the portable core does (nsHtml5TreeBuilderCppSupplement) | ||
* An executor for the tree ops (nsHtml5TreeOpExecutor) | * An executor for the tree ops (nsHtml5TreeOpExecutor) | ||
==Basics for Web content loading on the XML side== | ==Basics for Web content loading on the XML side== | ||
| Line 77: | Line 75: | ||
Since chrome: documents can be XHTML, it follows that mozilla::parser::xml::TreeOpGenerator needs to work on the main thread, too. This shouldn't be a big deal considering that tree op generation in the HTML case can run on either thread. | Since chrome: documents can be XHTML, it follows that mozilla::parser::xml::TreeOpGenerator needs to work on the main thread, too. This shouldn't be a big deal considering that tree op generation in the HTML case can run on either thread. | ||
==Parsing XML that's not Web content-like== | |||
We have various uses of expat that don't currently target nsXMLContentSink. XUL, XBL1, XSLT (transformation program compilation), RDF and SAX all have special sinks. It's probably not worthwhile to move these off the main thread or to otherwise make substantial changes here. I propose making these cases use mozilla::parser::xml::MainThreadStreamParser for feeding content to expat and to deCOMtaminate the special sinks so that they inherit from mozilla::parser::xml::AExpatHandler (presented above) and know how to set themselves directly as expat callback handlers. | |||
==Fragment parsing== | |||
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. | |||