Proposal: Add Feature to declare html-doc-type
Scott Seely
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:
html4-loose: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01
Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
html4-strict: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
html4-frameset: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//
EN" "http://www.w3.org/TR/html4/frameset.dtd">
xhtml-basic10: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
xhtml11-strict: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//
EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
xhtml11-transitional: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0
Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-
transitional.dtd">
xhtml11-frameset: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0
Frameset//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">
xhtml11-strict: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
Example usage:
<Require feature="html-doc-type">
<Param name="doc-type">xhtml11-strict</Param>
</Require>
Kevin Brown
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:
This was addressed in the proxied rendering proposal, in the 'modifications to processing' section:
http://wiki.opensocial.org/index.php?title=Proxied_Content#Processing_content
In short:
<Content type="html"><![CDATA[<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
...
]]></Content>
should work.
Kevin Marks
<!DOCTYPE html>That puts all browsers into standards mode.
Scott Seely
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).
Kevin Brown
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.
Scott Seely
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.
Louis Ryan
Can you refresh my memory about the death of CDATA? In the absence of CDATA the inline content would have to be valid XML as well as HTML which has its own problems in pretty much any mode of HTML. As for concatenated content blocks the developer should expect the same experience they would get if they put multiple DOCTYPEs into a regular HTML document, i.e something entirely unspecified. It seems natural to use the same mechanism for proxied content and inline content to specify the DOCTYPE and I believe it is a goal to be able to refer to vanilla HTML documents using the proxied content type and expect them to work?
-Louis
Scott Seely
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.
Adam Winer
Kevin Brown
Scott Seely
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.
Louis Ryan
As an aside I think we explicitly dont want to support DOCTYPE specific serialization modes.