Great discussion. Do we want to add a standardsMode attribute to Shindig now, or should we await more discussion?
What's the process for adding something like this to the gadgets specification? On Sat, Feb 09, 2008 at 05:50:29PM -0800, Kevin Brown wrote: > Great information, Bruno. Again, though -- there's nothing we can do about > this in Shindig. This needs to be brought up in the OpenSocial discussion > group. Not everyone involved in defining the specifications reads this list. > > ~Kevin > > 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";> > > 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]
pgpJ5DlDOynqM.pgp
Description: PGP signature
