quirks mode attribute for <Contents>
20 views
Skip to first unread message
Bruno Bowden
Feb 15, 2008, 6:50:48 PM2/15/08
to opensocial-an...@googlegroups.com
Currently the gadget spec requires that gadgets are developed in quirks mode. This is a legacy decision that would be desirable to change. I won't go into the differences between quirks and standards mode (see links below for more detail).
More Info: http://en.wikipedia.org/wiki/Quirks_mode
Gadget Spec: http://code.google.com/apis/gadgets/docs/spec.html
The driving force for this decision is when cajoled gadgets are inlined on a container page. In that case, the gadget will be rendered according to the DOCTYPE of the container page. Currently gadgets are rendered within an iframe with no DOCTYPE (quirks mode). The OpenSocial partners overwhelmingly use standards mode, the one exception being Orkut (see list below).
PROPOSAL
An attribute on <Contents> called "quirks" that can be set to true or false. This allow early opt-in for testing and opt-out if it's not compatible. If the attribute is not present then the default behaviour is up to Shindig. Once the attribute is introduced, the model is that it will default true initially (quirks mode) then switch to default false (standards mode) once gadget developers have had a chance to try it out.
<Contents> Developer doesn't state choice, up to Shindig
<Contents quirks="false"> Render using standards mode
<Contents quirks="true"> Always use quirks mode (would prevent inlining)
The attribute is named "quirks" as the meaning for something like "standardsmode" would not be so clear. This would add the following DOCTYPE (same as what is currently used for iGoogle and Blogger):
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
SIMPLICITY
The goal is most developers do not know about this attribute, they just use <Contents> by itself and it uses standards mode by default.
Reference list of container DOCTYPEs
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">
More Info: http://en.wikipedia.org/wiki/Quirks_mode
Gadget Spec: http://code.google.com/apis/gadgets/docs/spec.html
The driving force for this decision is when cajoled gadgets are inlined on a container page. In that case, the gadget will be rendered according to the DOCTYPE of the container page. Currently gadgets are rendered within an iframe with no DOCTYPE (quirks mode). The OpenSocial partners overwhelmingly use standards mode, the one exception being Orkut (see list below).
PROPOSAL
An attribute on <Contents> called "quirks" that can be set to true or false. This allow early opt-in for testing and opt-out if it's not compatible. If the attribute is not present then the default behaviour is up to Shindig. Once the attribute is introduced, the model is that it will default true initially (quirks mode) then switch to default false (standards mode) once gadget developers have had a chance to try it out.
<Contents> Developer doesn't state choice, up to Shindig
<Contents quirks="false"> Render using standards mode
<Contents quirks="true"> Always use quirks mode (would prevent inlining)
The attribute is named "quirks" as the meaning for something like "standardsmode" would not be so clear. This would add the following DOCTYPE (same as what is currently used for iGoogle and Blogger):
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
SIMPLICITY
The goal is most developers do not know about this attribute, they just use <Contents> by itself and it uses standards mode by default.
Reference list of container DOCTYPEs
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">
Kevin Brown
Mar 6, 2008, 4:51:41 AM3/6/08
to opensocial-an...@googlegroups.com
I think it's going to become very important to get this standardized soon, because it looks like IE8 is going to cause some havoc.
http://blogs.msdn.com/ie/archive/2008/03/05/internet-explorer-8-beta-1-for-developers-now-available.aspx
Specifically, IE now defaults to standards mode when no doctype is present. Falling back to quirks mode requires some other black magic.
Does anyone have a strong objection to Bruno's proposal? I think as long as we make the default value true compatibility will be preserved while allowing developers to decide how they'll be rendered. We've applied this in Shindig for the time being, and as such it's become an undocumented feature. We'd love to be able to document it.--
~Kevin
http://blogs.msdn.com/ie/archive/2008/03/05/internet-explorer-8-beta-1-for-developers-now-available.aspx
Specifically, IE now defaults to standards mode when no doctype is present. Falling back to quirks mode requires some other black magic.
Does anyone have a strong objection to Bruno's proposal? I think as long as we make the default value true compatibility will be preserved while allowing developers to decide how they'll be rendered. We've applied this in Shindig for the time being, and as such it's become an undocumented feature. We'd love to be able to document it.
~Kevin
Bruno Bowden
Mar 6, 2008, 6:54:24 PM3/6/08
to opensocial-an...@googlegroups.com
I wanted to gather other people's feedback about using 'strict' vs. 'transitional' for the doctype. It turns out the 1 in 4 gadgets use the <font> which is deprecated with HTML 4.01 strict. However, in practice browsers even if the strict doctype is used, browsers support the <font> tag anyway. Similar story for the <center> tag also.
My preference is to use the standards strict doctype, (as has been committed already):
<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.01//EN\" \"http://www.w3.org/TR/html4/strict.dtd\">
Philosophically only a 'strict' gadget could be inlined into both strict and transitional containers. Strict also encourages the most consistent page rendering. In practice though, since browsers don't enforce strictness, gadget developers will continue using old syntax like <font>.
Here's the list of doctypes by container:
HTML:
Plaxo Profile - Standards Strict
Friendster Profile: Standards Transitional
LinkedIn Profile: Standards Transitional
Orkut Profile: Quirks Transitional
Blogger blog: Standards Strict
iGoogle: Standards Strict
XHTML:
Facebook Profile & Canvas chrome: Standards Strict
Hi5 Sandbox Profile: Standards Transitional
MySpace Profile: Standards Transitional
Salesforce.com: Standards Transitional
Ning OpenSocialDemo: Standards Strict
My preference is to use the standards strict doctype, (as has been committed already):
<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.01//EN\" \"http://www.w3.org/TR/html4/strict.dtd\">
Philosophically only a 'strict' gadget could be inlined into both strict and transitional containers. Strict also encourages the most consistent page rendering. In practice though, since browsers don't enforce strictness, gadget developers will continue using old syntax like <font>.
Here's the list of doctypes by container:
HTML:
Plaxo Profile - Standards Strict
Friendster Profile: Standards Transitional
LinkedIn Profile: Standards Transitional
Orkut Profile: Quirks Transitional
Blogger blog: Standards Strict
iGoogle: Standards Strict
XHTML:
Facebook Profile & Canvas chrome: Standards Strict
Hi5 Sandbox Profile: Standards Transitional
MySpace Profile: Standards Transitional
Salesforce.com: Standards Transitional
Ning OpenSocialDemo: Standards Strict
Kevin Brown
Mar 6, 2008, 7:06:08 PM3/6/08
to opensocial-an...@googlegroups.com
I don't think this really matters one way or another. strict deprecates many elements and attributes, of html4, but they weren't removed. It's unlikely that any browser would actually drop support for these tags anytime in the next decade.--
~Kevin
~Kevin
Zhen Wang
Mar 6, 2008, 7:11:31 PM3/6/08
to opensocial-an...@googlegroups.com
I strongly prefer a strict doctype for the same reasons Bruno has elaborated.
Cassie
Mar 31, 2008, 1:48:21 PM3/31/08
to opensocial-an...@googlegroups.com
To summarize this thread it looks like we want to give gadgets the ability to render in standards mode. The corresponding spec change would be:
i. For type HTML gadgets, the order is as follows:
This means that for all containers that will default to standards mode, all current gadgets that are counting on quirks mode will need to either change or break. If this is acceptable for a 0.7 to 0.8 upgrade then this should be fine. Otherwise.. we'll need a better idea.
Votes/comments please!
- Cassie
i. For type HTML gadgets, the order is as follows:
- Standard HTML header, opening
<html>tag and<body>tag.<head>information is optional. Gadgets run the browser mode of the container's choice unless explicitly specified using the "quirks" attribute on the Contents element. If the quirks attribute is set to "true", gadgets will be rendered in quirks mode. If set to "false", they will be rendered in standards mode.
This means that for all containers that will default to standards mode, all current gadgets that are counting on quirks mode will need to either change or break. If this is acceptable for a 0.7 to 0.8 upgrade then this should be fine. Otherwise.. we'll need a better idea.
Votes/comments please!
- Cassie
Kevin Brown
Mar 31, 2008, 2:20:26 PM3/31/08
to opensocial-an...@googlegroups.com
On Mon, Mar 31, 2008 at 10:48 AM, Cassie <do...@google.com> wrote:
To summarize this thread it looks like we want to give gadgets the ability to render in standards mode. The corresponding spec change would be:
i. For type HTML gadgets, the order is as follows:
- Standard HTML header, opening
<html>tag and<body>tag.<head>information is optional. Gadgets run the browser mode of the container's choice unless explicitly specified using the "quirks" attribute on the Contents element. If the quirks attribute is set to "true", gadgets will be rendered in quirks mode. If set to "false", they will be rendered in standards mode.
This means that for all containers that will default to standards mode, all current gadgets that are counting on quirks mode will need to either change or break. If this is acceptable for a 0.7 to 0.8 upgrade then this should be fine. Otherwise.. we'll need a better idea.
I think we just leave the default as quirks being "true" so as to not break almost every existing gadget.
--
~Kevin
![Mike Austin [hi5.com]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjXOnDyd5wJ0-tuVvecz-hdSoFiCJzkxEj17bV8SAGcXfXCJevZK=s40-c)
Mike Austin [hi5.com]
Mar 31, 2008, 7:23:02 PM3/31/08
to OpenSocial and Gadgets Specification Discussion
Any new app would probably not use quirks mode - unless the developer
enjoys pain :), so it's a little odd to have as the default. What is
the true impact of changing the default to false? Would this only
affect applications if they specifically required opensocial-0.8?
Mike Austin
hi5.com
> Salesforce.com <http://salesforce.com/>: Standards
enjoys pain :), so it's a little odd to have as the default. What is
the true impact of changing the default to false? Would this only
affect applications if they specifically required opensocial-0.8?
Mike Austin
hi5.com
Kevin Brown
Mar 31, 2008, 7:30:44 PM3/31/08
to opensocial-an...@googlegroups.com
Any new app would probably not use quirks mode - unless the developer
enjoys pain :), so it's a little odd to have as the default. What is
the true impact of changing the default to false? Would this only
affect applications if they specifically required opensocial-0.8?
It would affect all existing gadgets -- currently the spec requires all gadgets to be rendered in quirks mode. There's no way to identify a "new" gadget yet -- although I'm completely in favor of a new xml schema that would allow for that.
--
~Kevin
Bruno Bowden
Mar 31, 2008, 10:15:49 PM3/31/08
to opensocial-an...@googlegroups.com
We could trigger standards mode by one of several things:
1) Calls to OpenSocial or gadgets.* apis
2) Use of certain features, e.g. OpenSocial
1) Calls to OpenSocial or gadgets.* apis
2) Use of certain features, e.g. OpenSocial
Kevin Brown
Mar 31, 2008, 10:38:38 PM3/31/08
to opensocial-an...@googlegroups.com
On Mon, Mar 31, 2008 at 7:15 PM, Bruno Bowden <br...@google.com> wrote:
We could trigger standards mode by one of several things:
1) Calls to OpenSocial or gadgets.* apis
2) Use of certain features, e.g. OpenSocial
You'd have to start with something arbitrary like opensocial-0.8, and then things just get confusing for developers. There are already lots of gadgets already running on myspace and orkut (and hi5?) that were built with the existing spec.
--
~Kevin
Cassie
Apr 24, 2008, 12:10:16 PM4/24/08
to opensocial-an...@googlegroups.com
Okay, do we think we want to move forward on a change here for the next spec version?
If so, let's get some +1s in. Otherwise, we can delay till a later spec if the need is not there.
- Cassie
If so, let's get some +1s in. Otherwise, we can delay till a later spec if the need is not there.
- Cassie
Zhen Wang
Apr 24, 2008, 2:18:10 PM4/24/08
to opensocial-an...@googlegroups.com
+1
Arne Roomann-Kurrik (Google)
Apr 24, 2008, 7:08:55 PM4/24/08
to OpenSocial and Gadgets Specification Discussion
+1 for the quirks attribute, default true
> On Thu, Apr 24, 2008 at 9:10 AM, Cassie <d...@google.com> wrote:
> > Okay, do we think we want to move forward on a change here for the next spec
> > version?
> > If so, let's get some +1s in. Otherwise, we can delay till a later spec if
> > the need is not there.
>
> > - Cassie
>
> > Okay, do we think we want to move forward on a change here for the next spec
> > version?
> > If so, let's get some +1s in. Otherwise, we can delay till a later spec if
> > the need is not there.
>
> > - Cassie
>
> > On Tue, Apr 1, 2008 at 4:38 AM, Kevin Brown <e...@google.com> wrote:
>
> > > On Mon, Mar 31, 2008 at 7:15 PM, Bruno Bowden <br...@google.com> wrote:
>
> > > > We could trigger standards mode by one of several things:
>
> > > > 1) Calls to OpenSocial or gadgets.* apis
> > > > 2) Use of certain features, e.g. OpenSocial
>
> > > You'd have to start with something arbitrary like opensocial-0.8, and then
> > things just get confusing for developers. There are already lots of gadgets
> > already running on myspace and orkut (and hi5?) that were built with the
> > existing spec.
>
>
> > > On Mon, Mar 31, 2008 at 7:15 PM, Bruno Bowden <br...@google.com> wrote:
>
> > > > We could trigger standards mode by one of several things:
>
> > > > 1) Calls to OpenSocial or gadgets.* apis
> > > > 2) Use of certain features, e.g. OpenSocial
>
> > > You'd have to start with something arbitrary like opensocial-0.8, and then
> > things just get confusing for developers. There are already lots of gadgets
> > already running on myspace and orkut (and hi5?) that were built with the
> > existing spec.
>
Kevin Brown
Apr 24, 2008, 10:43:27 PM4/24/08
to opensocial-an...@googlegroups.com
+1
John Panzer
Apr 25, 2008, 1:42:12 AM4/25/08
to opensocial-an...@googlegroups.com
+1 on change for next spec version.
Cassie
Apr 25, 2008, 8:12:14 AM4/25/08
to opensocial-an...@googlegroups.com, Mike Austin [hi5.com]
Okay, so are we all talking about a change like this then?
i. For type HTML gadgets, the order is as follows:
If so, then Mike I suppose the answer for you is that this way we are completely backwards compatible and it is extremely easy for a gadget to render in standards so it shouldn't be a problem for new developers. (It'll just seem like part of the standard template for them) Does this sound okay?
Thanks.
- Cassie
i. For type HTML gadgets, the order is as follows:
- Standard HTML header, opening
<html>tag and<body>tag.<head>information is optional. Gadgets are run in quirks mode unless the "quirks" attribute on the Contents element is set to "false". If the quirks attribute is set to "false", they will be rendered in standards mode.
If so, then Mike I suppose the answer for you is that this way we are completely backwards compatible and it is extremely easy for a gadget to render in standards so it shouldn't be a problem for new developers. (It'll just seem like part of the standard template for them) Does this sound okay?
Thanks.
- Cassie
Paul Lindner
Apr 25, 2008, 7:22:12 PM4/25/08
to opensocial-an...@googlegroups.com
+1 on this
it's already in the shindig code :)
On Fri, Apr 25, 2008 at 02:12:14PM +0200, Cassie wrote:
> Okay, so are we all talking about a change like this then?
>
> i. For type HTML gadgets, the order is as follows:
>
> 1. Standard HTML header, opening <html> tag and <body> tag.
> <head>information is optional.
> *Gadgets are run in quirks mode unless the "quirks" attribute on the
> Contents element is set to "false". If the quirks attribute is set to
> "false", they will be rendered in standards mode. *
> You received this message because you are subscribed to the Google Groups "OpenSocial and Gadgets Specification Discussion" group.
> To post to this group, send email to opensocial-an...@googlegroups.com
> To unsubscribe from this group, send email to opensocial-and-gadg...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
--
Paul Lindner ||||| | | | | | | | | |
lin...@inuus.com
Paul
Apr 25, 2008, 10:19:01 PM4/25/08
to OpenSocial and Gadgets Specification Discussion
-1
I would like to give developers the ability to simply give the doctype
they want rather than setting a boolean for quirks/standards mode.
There are differences in rendering between various xhtml doctypes.
~Paul
I would like to give developers the ability to simply give the doctype
they want rather than setting a boolean for quirks/standards mode.
There are differences in rendering between various xhtml doctypes.
~Paul
John Panzer
Apr 29, 2008, 7:01:42 PM4/29/08
to opensocial-an...@googlegroups.com
The problem with this is that in the bright, shiny future, when things are inlined with Caja, you cannot render two gadgets with two different doctypes on the same page. So we'd be encouraging people to add constraints that will have to be broken down the road.
Arne Roomann-Kurrik
Apr 29, 2008, 7:13:52 PM4/29/08
to opensocial-an...@googlegroups.com
Wouldn't this impact the quirks vs standards switch as well?
~Arne--
OpenSocial IRC - irc://irc.freenode.net/opensocial
~Arne
OpenSocial IRC - irc://irc.freenode.net/opensocial
Kevin Brown
Apr 29, 2008, 9:08:18 PM4/29/08
to opensocial-an...@googlegroups.com
On Tue, Apr 29, 2008 at 4:13 PM, Arne Roomann-Kurrik <kur...@google.com> wrote:
Wouldn't this impact the quirks vs standards switch as well?
No. If the container is quirks and the gadget requires standards (or vice versa), it can put the gadget into an iframe (on the same domain, of course). Using doctype would require all gadgets to be in iframes at all times.
Paul Walker
Apr 30, 2008, 7:11:50 PM4/30/08
to opensocial-an...@googlegroups.com
A quirks attribute is better than what we have right now, so I’ll take away my -1 on this one as well.
John Hjelmstad
Apr 30, 2008, 7:38:06 PM4/30/08
to opensocial-an...@googlegroups.com
I have two comments to this:
1. None of these proposals accounts for what happens when multiple <Content> blocks share the same "view" (http://code.google.com/p/opensocial-resources/wiki/MultipleContentSections) but have differing "quirks-related" values. This behavior is not officially specified in the spec itself (http://code.google.com/apis/opensocial/docs/releasenotes.html), but is widely deployed in virtue of having been implemented for some time in Shindig, making it a de facto standard.
At root this calls for a new proposal, on which this could be dependent, to officially standardize on the above behavior. Acknowledged, this isn't great for expedient closure of this issue :)
That said, we could do either of the following without concluding on this:
A) specify what happens *if* there are multiple <Content> sections appended together that comprise a given view but with different quirks attributes, or...
B) move the attribute to <ModulePrefs> instead, or I suppose <Module> - in either case, some top-level construct.
I vote (B).ModulePrefs.
2. I appreciate Paul Walker's -1-renege, but remain compelled by the fact that xhtml doctypes render differently. In the interest of future extensibility, I propose the following alternate syntax for the exact semantics already described, as a hedge:
<ModulePrefs rendering_mode="standards"/>
Notes:
A) Agreed, this is well-trod ground: "standards" isn't 100% clear. We could also use "-quirks" or "!quirks" or similar. Either way, we would define that this token precisely means standards as described in the existing proposal.
B) Probably obvious, but this helps avoid a future scenario in which there's some substantial difference between one doctype's rendering and another that would effectively break it.
C) If there's significant pushback to this idea, I'm OK with the existing "quirks='false'" syntax for the attribute.
John
1. None of these proposals accounts for what happens when multiple <Content> blocks share the same "view" (http://code.google.com/p/opensocial-resources/wiki/MultipleContentSections) but have differing "quirks-related" values. This behavior is not officially specified in the spec itself (http://code.google.com/apis/opensocial/docs/releasenotes.html), but is widely deployed in virtue of having been implemented for some time in Shindig, making it a de facto standard.
At root this calls for a new proposal, on which this could be dependent, to officially standardize on the above behavior. Acknowledged, this isn't great for expedient closure of this issue :)
That said, we could do either of the following without concluding on this:
A) specify what happens *if* there are multiple <Content> sections appended together that comprise a given view but with different quirks attributes, or...
B) move the attribute to <ModulePrefs> instead, or I suppose <Module> - in either case, some top-level construct.
I vote (B).ModulePrefs.
2. I appreciate Paul Walker's -1-renege, but remain compelled by the fact that xhtml doctypes render differently. In the interest of future extensibility, I propose the following alternate syntax for the exact semantics already described, as a hedge:
<ModulePrefs rendering_mode="standards"/>
Notes:
A) Agreed, this is well-trod ground: "standards" isn't 100% clear. We could also use "-quirks" or "!quirks" or similar. Either way, we would define that this token precisely means standards as described in the existing proposal.
B) Probably obvious, but this helps avoid a future scenario in which there's some substantial difference between one doctype's rendering and another that would effectively break it.
C) If there's significant pushback to this idea, I'm OK with the existing "quirks='false'" syntax for the attribute.
John
Cassie
May 1, 2008, 4:20:33 AM5/1/08
to opensocial-an...@googlegroups.com
Note to John: this conversation actually took place in another thread which was not resolved in time for 0.8.
If you wish to discuss: what to do when multiple content sections share the same view, what the default view means, whether we should have an all view, and whether we allow comma separated lists of views (or anything else related - its a big thread) then you want to look here:
http://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm/thread/1845cdb2f3d17777
- Cassie
If you wish to discuss: what to do when multiple content sections share the same view, what the default view means, whether we should have an all view, and whether we allow comma separated lists of views (or anything else related - its a big thread) then you want to look here:
http://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm/thread/1845cdb2f3d17777
- Cassie
Cassie
May 1, 2008, 6:24:17 AM5/1/08
to opensocial-an...@googlegroups.com
It looks like there is still more to discuss here so this issue is now deferred until 0.9
Thanks.
- Cassie
Thanks.
- Cassie
John Hjelmstad
May 1, 2008, 11:22:35 AM5/1/08
to opensocial-an...@googlegroups.com
My apologies, my searches missed this thread, which was promptly forwarded to me by multiple colleagues after sending my note. :)
John
John
Reply all
Reply to author
Forward
0 new messages