You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Paul Lindner <pl...@hi5.com> on 2008/02/09 04:27:27 UTC
My opensocial unit test application + quirks mode patch
I've started to clean up my crude unit test application into something
much better. You can see it here:
http://www.inuus.com/os/unittest-os.xml
I've settled on the Scriptaculous Unit test framework. It's pretty
simple and straightforward. Here's a test stanza:
testPrefs: function () { with(this) {
var p = new gadgets.Prefs()
assertNotNull(p, "cannot get gadgets.Prefs()");
assertNotNull(p.getCountry());
assertNotEqual(p.getCountry(), 'all', 'country cannot be "all"');
testoutput("Found country: '" + p.getCountry() + "'");
assertNotNull(p.getLang());
assertNotEqual(p.getLang(), 'all', 'lang cannot be "all"');
testoutput("Found language: '" + p.getLang() + "'");
}}
Note that I had patch the gadget server to add a modern doctype (see
patch below). I recommend we commit this, since it also gets rid of
quirks mode in most browsers. (See http://en.wikipedia.org/wiki/Quirks_mode)
Index: java/gadgets/src/main/java/org/apache/shindig/gadgets/http/GadgetRenderingServlet.java
===================================================================
--- java/gadgets/src/main/java/org/apache/shindig/gadgets/http/GadgetRenderingServlet.java (revision 619978)
+++ java/gadgets/src/main/java/org/apache/shindig/gadgets/http/GadgetRenderingServlet.java (working copy)
@@ -158,7 +158,9 @@
resp.setContentType("text/html");
StringBuilder markup = new StringBuilder();
- markup.append("<html><head>");
+ markup.append("<!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML 1.0 Transitional//EN\"\n")
+ .append("\"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\">\n")
+ .append("<html xmlns=\"http://www.w3.org/1999/xhtml\"><head>");
// TODO: This is so wrong.
markup.append("<style type=\"text/css\">" +
"body,td,div,span,p{font-family:arial,sans-serif;}" +
--
Paul Lindner
hi5 Architect
plindner@hi5.com
Re: My opensocial unit test application + quirks mode patch
Posted by John Panzer <jp...@google.com>.
Yes, that's the 'interesting' part. But the default, new templates
are standards mode.
-John
On Feb 11, 2008, at 5:57 PM, "Kevin Brown" <et...@google.com> wrote:
> Is this universally true? I was under the impression that Blogger's
> templates could have different doctypes.
>
> On Feb 11, 2008 5:16 PM, John Panzer <jp...@google.com> wrote:
>
>> One more (future) container for the list...
>>
>> On Feb 9, 2008 5:44 PM, Bruno Bowden <br...@google.com> 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 <jp...@google.com> 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 <pl...@hi5.com> 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
>>>>> plindner@hi5.com
>>>>
>>>
>>
Re: My opensocial unit test application + quirks mode patch
Posted by Kevin Brown <et...@google.com>.
Is this universally true? I was under the impression that Blogger's
templates could have different doctypes.
On Feb 11, 2008 5:16 PM, John Panzer <jp...@google.com> wrote:
> One more (future) container for the list...
>
> On Feb 9, 2008 5:44 PM, Bruno Bowden <br...@google.com> 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 <jp...@google.com> 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 <pl...@hi5.com> 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
> > > > plindner@hi5.com
> > >
> >
>
Re: My opensocial unit test application + quirks mode patch
Posted by John Panzer <jp...@google.com>.
One more (future) container for the list...
On Feb 9, 2008 5:44 PM, Bruno Bowden <br...@google.com> 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 <jp...@google.com> 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 <pl...@hi5.com> 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
> > > plindner@hi5.com
> >
>
Re: My opensocial unit test application + quirks mode patch
Posted by Kevin Brown <et...@google.com>.
On Feb 11, 2008 5:09 PM, Paul Lindner <pl...@hi5.com> wrote:
> Great discussion.
>
> Do we want to add a standardsMode attribute to Shindig now, or
> should we await more discussion?
I'd say we should only trigger it manually (via a quirks=false query string
parameter) for the time being, so that container authors can at least
decide whether to use quirks or standards using a whitelist. This will
become automatic triggering when the spec discussion reaches
What's the process for adding something like this to the gadgets
> specification?
I don't know that there's a formal process yet; generally what happens is
that between container discussions (such as the one at six apart a few weeks
ago) and personal discussions a change gets made. Right now it's entirely
Google's responsibility to actually publish the results of those discussions
since the specs live on our infrastructure, but at some point I'm sure this
will become more transparent. For now the best bet is to start a thread on
the opensocial discussion group, and when a decision is reached it should be
reached there (and someone from google can update the published spec docs
appropriately).
~Kevin
Re: My opensocial unit test application + quirks mode patch
Posted by Paul Lindner <pl...@hi5.com>.
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 <br...@google.com> 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 <jp...@google.com> 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 <pl...@hi5.com> 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
plindner@hi5.com
Re: My opensocial unit test application + quirks mode patch
Posted by Kevin Brown <et...@google.com>.
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 <br...@google.com> 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 <jp...@google.com> 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 <pl...@hi5.com> 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
> > > plindner@hi5.com
> >
>
Re: My opensocial unit test application + quirks mode patch
Posted by Bruno Bowden <br...@google.com>.
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 <jp...@google.com> 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 <pl...@hi5.com> 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
> > plindner@hi5.com
>
Re: My opensocial unit test application + quirks mode patch
Posted by John Panzer <jp...@google.com>.
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 <pl...@hi5.com> 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
> plindner@hi5.com
Re: My opensocial unit test application + quirks mode patch
Posted by Kevin Brown <et...@google.com>.
On Feb 9, 2008 1:22 PM, Paul Lindner <pl...@hi5.com> 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.
Indeed -- I'm all for standards mode on Cajoled gadgets, but that ultimately
depends on whether we have a way to clearly identify that a gadget has been
marked safe for cajoling in the spec up front. This is something that needs
to be brought up at the next open social container meeting, I think.
> > 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?
Internal to Google, at container meetings and hackathons, and at individual
meetings between container implementations.
> Has anyone actually tried, say the top 100 apps rendered in standards
> mode? I really doubt that it's that much of a problem.
I've done the top 20 from the igoogle directory; of those about half
appeared to render exactly the same, and the rest had minor variations. I
didn't see any that broke horribly, but we could certainly see that for
gadgets that relied heavily on the IE quirks mode box model or float
behavior.
>
> > 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.
We can't require dependencies on google infrastructure -- especially not
since google itself is moving towards using shindig (we're already using it
for orkut today). iGoogle won't be any different from what works everywhere
else.
> * New widgets (those using opensocial or other new technologies) will
> be sent through a Shindig based server.
This is not possible to detect in the spec (we can detect usage of the
opensocial feature, but not all gadgets will use opensocial). Some
discussion has been kicked around about a new attribute to indicate whether
something has been verified safe for cajoling, and we could possibly use
that as an opportunity to work this change in as well. This requires spec
change, however we will most likely
> * Mark quirks mode deprecated with a sunset of 1 year from now.
We can't make this decision in Shindig -- we have to follow the spec. I'm
all for changing the spec, but we need a solution that all containers can
agree to. I'd recommend bringing this up on the open social spec discussion
group (http://groups.google.com/group/opensocial).
We can certainly add the code path to switch between quirks and standards
mode in Shindig, and then make the triggering happen whenever the spec gets
settled. I'd recommend something like passing a "quirks" query string
parameter to the iframe url for the time being. This will at least allow
existing containers to manually set standards vs. quirks mode for specific
gadgets that have been verified to need one or the other by hand.
Re: My opensocial unit test application + quirks mode patch
Posted by Paul Lindner <pl...@hi5.com>.
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
plindner@hi5.com
Re: My opensocial unit test application + quirks mode patch
Posted by Kevin Brown <et...@google.com>.
Unfortunately, Quirks mode is required by the spec. See Item 6 under
"Compliance" at http://code.google.com/apis/gadgets/docs/spec.html.
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. 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.
~Kevin
On Feb 8, 2008 7:27 PM, Paul Lindner <pl...@hi5.com> wrote:
> I've started to clean up my crude unit test application into something
> much better. You can see it here:
>
> http://www.inuus.com/os/unittest-os.xml
>
> I've settled on the Scriptaculous Unit test framework. It's pretty
> simple and straightforward. Here's a test stanza:
>
> testPrefs: function () { with(this) {
> var p = new gadgets.Prefs()
> assertNotNull(p, "cannot get gadgets.Prefs()");
>
> assertNotNull(p.getCountry());
> assertNotEqual(p.getCountry(), 'all', 'country cannot be
> "all"');
> testoutput("Found country: '" + p.getCountry() + "'");
>
> assertNotNull(p.getLang());
> assertNotEqual(p.getLang(), 'all', 'lang cannot be "all"');
> testoutput("Found language: '" + p.getLang() + "'");
> }}
>
>
> Note that I had patch the gadget server to add a modern doctype (see
> patch below). I recommend we commit this, since it also gets rid of
> quirks mode in most browsers. (See
> http://en.wikipedia.org/wiki/Quirks_mode)
>
>
> Index:
> java/gadgets/src/main/java/org/apache/shindig/gadgets/http/GadgetRenderingServlet.java
> ===================================================================
> ---
> java/gadgets/src/main/java/org/apache/shindig/gadgets/http/GadgetRenderingServlet.java
> (revision 619978)
> +++
> java/gadgets/src/main/java/org/apache/shindig/gadgets/http/GadgetRenderingServlet.java
> (working copy)
> @@ -158,7 +158,9 @@
> resp.setContentType("text/html");
>
> StringBuilder markup = new StringBuilder();
> - markup.append("<html><head>");
> + markup.append("<!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML 1.0Transitional//EN\"\n")
> + .append("\"
> http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\<http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd%5C>
> ">\n")
> + .append("<html xmlns=\"http://www.w3.org/1999/xhtml\<http://www.w3.org/1999/xhtml%5C>
> "><head>");
> // TODO: This is so wrong.
> markup.append("<style type=\"text/css\">" +
> "body,td,div,span,p{font-family:arial,sans-serif;}" +
>
>
>
>
> --
> Paul Lindner
> hi5 Architect
> plindner@hi5.com
>