Proposal: Add Feature to declare html-doc-type

42 views
Skip to first unread message

Scott Seely

unread,
Jan 14, 2009, 5:04:29 PM1/14/09
to OpenSocial - OpenSocial and Gadgets Specification Discussion
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:

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

unread,
Jan 14, 2009, 6:02:07 PM1/14/09
to opensocial-an...@googlegroups.com
On Wed, Jan 14, 2009 at 2:04 PM, Scott Seely <sse...@myspace.com> wrote:

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

unread,
Jan 14, 2009, 6:08:28 PM1/14/09
to opensocial-an...@googlegroups.com
How about the HTML5 doctype by default:

<!DOCTYPE html>
That puts all browsers into standards mode.


On Wed, Jan 14, 2009 at 2:04 PM, Scott Seely <sse...@myspace.com> wrote:

Scott Seely

unread,
Jan 14, 2009, 6:24:14 PM1/14/09
to opensocial-an...@googlegroups.com

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

unread,
Jan 14, 2009, 6:28:39 PM1/14/09
to opensocial-an...@googlegroups.com
On Wed, Jan 14, 2009 at 3:24 PM, Scott Seely <sSe...@myspace.com> wrote:

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.

The proposal included modification of the rendering pipeline to accommodate this. Without the modification, it would be hard to pull off the rest. The prototype implementation that I emailed to this list a few weeks ago handles this in a backwards compatible way without issue.
 

Scott Seely

unread,
Jan 14, 2009, 7:22:18 PM1/14/09
to opensocial-an...@googlegroups.com

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

unread,
Jan 20, 2009, 2:38:33 PM1/20/09
to opensocial-an...@googlegroups.com
Scott

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

unread,
Jan 20, 2009, 3:29:04 PM1/20/09
to opensocial-an...@googlegroups.com

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

unread,
Jan 21, 2009, 4:48:44 PM1/21/09
to opensocial-an...@googlegroups.com
As a data point:  JSPs needed to solve the same problem for their XML document type.  The solution was doctype-root-element, doctype-system, and doctype-public properties on a <jsp:output> element.  I'm personally agnostic on this issue.

Kevin Brown

unread,
Feb 11, 2009, 2:15:00 PM2/11/09
to opensocial-an...@googlegroups.com
This is something that we need to resolve for 0.9.

Scott Seely

unread,
Feb 11, 2009, 3:02:34 PM2/11/09
to opensocial-an...@googlegroups.com

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

unread,
Feb 12, 2009, 1:06:30 AM2/12/09
to opensocial-an...@googlegroups.com
I would be OK with adding the feature and allowing <DOCTYPE to work in CDATA sections as it would with proxied content. Concatenation ordering I dont't believe is a significant block to this. While non-CDATA block gadgets may be a desirable goal I havent seent it in practice.

As an aside I think we explicitly dont want to support DOCTYPE specific serialization modes.
Reply all
Reply to author
Forward
0 new messages