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" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:
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]
