One more (future) container for the list... On Feb 9, 2008 5:44 PM, Bruno Bowden <[EMAIL PROTECTED]> wrote:
> 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";> Blogger (Blogspot) pages: 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] > > >
