I was going to make the same point about inlining but John beat me to it ;-).
Inlining cajoled gadgets is going to force us to switch to standards mode. All the major OpenSocial partners use standards mode with the exception for Orkut (sorry guys). Complete list of container DOCTYPEs is at the end. If an author has to modify their gadget for caja, it makes sense to convert to standards mode too. This avoids hitting developers with repeated requests for changes or suffering the long term problems of adopting quirks mode. BACKWARDS COMPATIBILITY This was the problem that Kevin raised. A gadget should be able to elect to be rendered in standards mode. If a gadget doesn't request standards mode, then like a page without a DOCTYPE, it's shown in quirks mode - just the same as how gadgets are rendered at the moment. Mix and match of modes is possible since it's inside an iframe: http://brunobowden.dreamhosters.com/gadgets/examples/strict.html Inlined Caja would use the DOCTYPE of the container. If a container wants to do inlining, then I believe it MUST use standards mode. SYNTAX We should not let gadgets specify the full doctype due - that would be ok for iframes but it's impossible with inlining. Instead use a generic boolean: <Content standardsMode="true"> ... </Content> If standardsMode is specified, then the DOCTYPE as added. If the attribute is missing, then the container can do what it likes. This allows it to be opt-in at first but still gives the container flexibility to migrate later. If a gadget developer opts out by using standardsMode="false", then it's always rendered in an iframe with no DOCTYPE. We're discussing a similar syntax for Caja. QUESTIONS How constrained should containers on selecting a DOCTYPE? Obviously it should be standards mode but since gadget developers are going to have a hard time coding to different DOCTYPEs, it would be easier for the container to standardize. I'm not familiar enough with the differences between DOCTYPEs to evaluate this. For standards mode rewriting, should we be stricter again and specify XHTML too? I need to check whether the output from Caja will be XHTML compliant, it may be a requirement for the input too. CONTAINER DOCTYPES Wikipedia documents the browser support for all DOCTYPEs http://en.wikipedia.org/wiki/Quirks_mode. I'm glossing over the "almost standards" mode for IE. The "html" has been lowercased in all DOCTYPEs to make it easier to read. Complete list of DOCTYPEs by container: HTML: Plaxo Profile - Standards <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"> Friendster Profile: Standards <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" " http://www.w3.org/TR/1998/REC-html40-19980424/loose.dtd";> LinkedIn Profile: Standards <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" " http://www.w3.org/TR/html4/loose.dtd";> Orkut Profile: Quirks <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> Blogger blog: Standards <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" " http://www.w3.org/TR/html4/strict.dtd";> iGoogle: Standards <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" " http://www.w3.org/TR/html4/strict.dtd";> XHTML: Facebook Profile & Canvas chrome: Standards <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" " http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";> Hi5 Sandbox Profile: Standards <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" " http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";> MySpace Profile: Standards <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" " http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";> Salesforce.com: Standards <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" " http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";> Ning OpenSocialDemo: Standards <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" " http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd";> On Feb 9, 2008 3:10 PM, John Panzer <[EMAIL PROTECTED]> wrote: > If a container does inlined cajoled gadgets, they'll need to match the > doctype of the container, no? Blogspot in particular is interesting > here... > > -John > > On Feb 9, 2008, at 1:22 PM, Paul Lindner <[EMAIL PROTECTED]> wrote: > > > On Fri, Feb 08, 2008 at 07:36:57PM -0800, Kevin Brown wrote: > >> Unfortunately, Quirks mode is required by the spec. See Item 6 under > >> "Compliance" at http://code.google.com/apis/gadgets/docs/spec.html. > > > > That's really unfortunate. Right now you have a great opportunity to > > make a clean break towards standards mode. People are going to be > > rewriting their Apps for Caja, plus they'll be customizing UI etal for > > each new platform. > > > > > > > >> This issue has been brought up numerous times in the past, but > >> there hasn't > >> been a resolution on it yet. The only reason for this is that many > >> (if not > >> all) existing gadgets have to be updated to use standards mode > >> since the > >> original iGoogle site used quirks mode. > > > > Where are these discussions taking place? Internal to Google I > > assume? > > > > Has anyone actually tried, say the top 100 apps rendered in standards > > mode? I really doubt that it's that much of a problem. > > > >> Many people (myself included) have attempted to move it towards > >> standards mode, but so far nobody's come up with a viable solution > >> for backwards compatibility. > > > > How about this: > > > > * Always render iGoogle gadgets using legacy gmodules.com. > > * New widgets (those using opensocial or other new technologies) will > > be sent through a Shindig based server. > > * Mark quirks mode deprecated with a sunset of 1 year from now. > > > > Alternate solutions: > > > > 1. If Gadget XML contains proper xmlns namespace then use standards > > mode, other wise quirks mode > > > > <Module xmlns:gadget="http://shindig.apache.org/ns/0";> > > > > 2. Allow developer to specify rendering at the top of the Gadgets > > XML.. > > > > <?xml ... ?> > > ....declaration goes here .... > > > > > > We should really try to fix this problem if we can. > > > > -- > > Paul Lindner > > hi5 Architect > > [EMAIL PROTECTED] >
