At MySpace, our developers are asking to use something other than
quirks mode to render a gadget. To handle all the modes a user might
want, we propose adding a new feature, html-doc-type, that allows a
user to declare how to render a gadget. Canonical names and the
resulting doc type are:
<!DOCTYPE html>That puts all browsers into standards mode.
I would love it if this were so, but the gadgets proposal clearly states “Standard HTML header, opening <html> tag and <body> tag. <head> information is optional. Gadgets run in browser quirks mode.” This states that one assumes that the opening and closing tags will be generated as needed—including the doctype item.
I do agree that the proxied content originating from outside the gadget XML does enjoy this benefit, but the spec is silent on what happens in the presence of inline HTML. This is true because proxied content does not allow for merging of views. Inline content can be merged, and figuring out where to put the appropriate doctype will get confusing for development (in theory, one could have a view that is a union of all views in the gadget.xml, but this seems silly).
Regarding HTML5, it appears that support for the full set of features is spotty at best (http://wiki.whatwg.org/wiki/Implementations_in_Web_browsers).
I would love it if this were so, but the gadgets proposal clearly states "Standard HTML header, opening <html> tag and <body> tag. <head> information is optional. Gadgets run in browser quirks mode." This states that one assumes that the opening and closing tags will be generated as needed—including the doctype item.
I do agree that the proxied content originating from outside the gadget XML does enjoy this benefit, but the spec is silent on what happens in the presence of inline HTML.
What does the rendering pipeline do in the presence of conflicting doctypes across merged content sections? First doctype wins? Or, do I have to declare this intent in EVERY <Content> item if I want to use a specific rendering mode?
Further, we (the OpenSocial folks on this DL) told people that CDATA is no longer required dead at the 1 year b-day event. The suggested proposal workaround requires CDATA, since DOCTYPE declarations have to occur as the first thing in a document. If the plan is still allows CDATA to die, I think that the proposed feature will still be required. I’m not too enthused about telling developers that they can go away from quirks mode IFF they either do only proxied content or they continue to put all their markup in CDATA.
Death of CDATA is an exaggeration (my fault). Slide 7 from http://docs.google.com/Presentation?docid=dg6csr2s_8m6nmz6dh&hl=en reads:
· No more CDATA blocks! (unless you really want them)
It would be more correct to say that it is no longer required. However, if one does go this route, then they have to use valid XML, so it’s not an issue (the developer makes this choice and has to handle the consequences).
The main reason to go with a special attribute for inline/gadget.xml is this: You would have to repeat the CDATA embed in every view scope and additionally the onus would be on the app developer to make sure it is placed in the top section since multiple views satisfying the current view condition are streamed together in order. And even that wouldn't work right because the container would need to parse the content blocks to see if a DOCTYPE directive is embedded therein, then move it to the top of the emitted code above all the container-specific code and markup. And all this is before we get into sub-views as being implemented as part of OSML.
Since the developer needs to declare their intent somewhere if they don’t want quirks mode, the proposal seems to be the cleanest, least effort solution to the problem. It is low effort for the developer. Given the issues outlined above, it is also simpler for the implementer.
Given the nature of inline gadget markup (Views with that have a common name are merged) plus the fact that we no longer will require CDATA blocks to hold markup, it seems that the html-doc-type feature is a good solution to the problem at hand when applying DOCTYPE to inline XML (this wouldn’t apply to proxied HTML—proxied content handles the doc type on its own). The jsp option, while workable, has issues in resolving precedence.