Publication of specifications as HTML5

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
44 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Publication of specifications as HTML5

Aryeh Gregor-4
Today I was talking with a few people about the fact that W3C
specifications cannot be published as HTML5.  As far as I can tell,
the pubrules say:

"All normative representations must validate as one of the following:
HTML 4.x, some version of XHTML that is a W3C Recommendation, or RDFa
in XHTML. Team Contacts please see the Communications Team to propose
additional exceptions."

HTML5 has been under development in some form for over seven years, at
the W3C for about four years, and is unlikely to reach Recommendation
for a number of years yet.  It introduces many new semantic elements
that would be useful in specifications, such as <nav>, <header>,
<section>, etc.  According to Ian Hickson, HTML3.2, HTML4, HTML4.01,
XHTML1, and XHTML1.1 were all allowed to be published in their own
format even before they reached Recommendation.  Hixie also said that
he reformats the HTML5 specification from HTML5 to HTML4.01 with a
four-line Perl script, which implies that if any consumer actually
needs HTML4.01 instead of HTML5, converting it should not be a great
burden.

So it's a bit of a puzzle to me why specs can't just be published as
HTML5.  What are the practical problems it might cause that outweigh
the benefits?  Multiple people have told me that polyglot HTML5 might
be okay, but why is non-polyglot HTML5 any worse than HTML4.01 (which
is allowed)?  What would the procedure be for trying to get this
requirement changed?

Thanks to everyone for their time.

Reply | Threaded
Open this post in threaded view
|

Re: Publication of specifications as HTML5

Doug Schepers-3
Hey, folks-

On 8/18/11 3:59 PM, Aryeh Gregor wrote:
> Today I was talking with a few people about the fact that W3C
> specifications cannot be published as HTML5.  As far as I can tell,
> the pubrules say:
>
> "All normative representations must validate as one of the following:
> HTML 4.x, some version of XHTML that is a W3C Recommendation, or RDFa
> in XHTML. Team Contacts please see the Communications Team to propose
> additional exceptions."
...
> So it's a bit of a puzzle to me why specs can't just be published as
> HTML5.  What are the practical problems it might cause that outweigh
> the benefits?  Multiple people have told me that polyglot HTML5 might
> be okay, but why is non-polyglot HTML5 any worse than HTML4.01 (which
> is allowed)?  What would the procedure be for trying to get this
> requirement changed?
>
> Thanks to everyone for their time.

Speaking for myself, I would support using HTML5 in TR, whether polyglot
or not.

For those that use an XML toolchain, couldn't they simply convert
HTML5-based specs to their format of choice?

Regards-
-Doug

Reply | Threaded
Open this post in threaded view
|

Re: Publication of specifications as HTML5

Karl Dubost-3
In reply to this post by Aryeh Gregor-4

Le 18 août 2011 à 15:59, Aryeh Gregor a écrit :
> What are the practical problems

I'm interested by this part of the discussion specifically.
Could we outline the issues that would have to be solved if we were injecting an HTML5 specification in the current system?

Then from here, we could move on on helping Ian Jacobs (and current Webmaster) to adjust these tools so we could meet halfway.


--
Karl Dubost
Montréal, QC, Canada
http://www.la-grange.net/karl/


Reply | Threaded
Open this post in threaded view
|

Re: Publication of specifications as HTML5

Ian Jacobs-2

On 18 Aug 2011, at 3:25 PM, Karl Dubost wrote:

>
> Le 18 août 2011 à 15:59, Aryeh Gregor a écrit :
>> What are the practical problems
>
> I'm interested by this part of the discussion specifically.
> Could we outline the issues that would have to be solved if we were injecting an HTML5 specification in the current system?
>
> Then from here, we could move on on helping Ian Jacobs (and current Webmaster) to adjust these tools so we could meet halfway.
>

Historically we have waited until a spec is further along the standards track before adding it to pubrules. There has been a growing demand to use HTML5 for TRs.

The staff has been discussing this. Karl mentions tooling issues (specifically the pubrules checker) which is one of the topics we've been discussing. Another one has to do with polyglot support. We've not completed our discussions internally, but discussion on spec-prod is also welcome.

I'll keep an eye on this thread and will have more to contribute once the team discussions have wrapped up (slowed by vacations).

Ian

--
Ian Jacobs ([hidden email])    http://www.w3.org/People/Jacobs/
Tel:                                      +1 718 260 9447


Reply | Threaded
Open this post in threaded view
|

Re: Publication of specifications as HTML5

Karl Dubost-3

Le 18 août 2011 à 17:59, Ian Jacobs a écrit :
> Another one has to do with polyglot support.

* What would be the benefits in the context of spec publishing to have polyglot support?
* What do you define as polyglot support?
 

--
Karl Dubost
Montréal, QC, Canada
http://www.la-grange.net/karl/


Reply | Threaded
Open this post in threaded view
|

Re: Publication of specifications as HTML5

Ian Jacobs-2

On 18 Aug 2011, at 9:12 PM, Karl Dubost wrote:

>
> Le 18 août 2011 à 17:59, Ian Jacobs a écrit :
>> Another one has to do with polyglot support.
>
> * What would be the benefits in the context of spec publishing to have polyglot support?
> * What do you define as polyglot support?

I had understood "conforms to http://www.w3.org/TR/html-polyglot/"

For XML processors.

Ian

>
>
> --
> Karl Dubost
> Montréal, QC, Canada
> http://www.la-grange.net/karl/
>
>

--
Ian Jacobs ([hidden email])    http://www.w3.org/People/Jacobs/
Tel:                                      +1 718 260 9447


Reply | Threaded
Open this post in threaded view
|

Re: Publication of specifications as HTML5

Karl Dubost-3

Le 18 août 2011 à 23:20, Ian Jacobs a écrit :
> For XML processors.


If all the tags are closed and the attributes are quoted (aka "XML well-formed"), would it be enough for the XML pubrules tools?


--
Karl Dubost
Montréal, QC, Canada
http://www.la-grange.net/karl/


Reply | Threaded
Open this post in threaded view
|

Re: Publication of specifications as HTML5

Ian Jacobs-2

On 18 Aug 2011, at 10:28 PM, Karl Dubost wrote:

>
> Le 18 août 2011 à 23:20, Ian Jacobs a écrit :
>> For XML processors.
>
>
> If all the tags are closed and the attributes are quoted (aka "XML well-formed"), would it be enough for the XML pubrules tools?

The original goal was not to make the pubrules checker happy, but to have a version readily consumable by any xml consumer. It turns out that will help the existing pubrules checker, but that's not the main goal.

Ian

>
>
> --
> Karl Dubost
> Montréal, QC, Canada
> http://www.la-grange.net/karl/
>
>

--
Ian Jacobs ([hidden email])    http://www.w3.org/People/Jacobs/
Tel:                                      +1 718 260 9447


Reply | Threaded
Open this post in threaded view
|

Re: Publication of specifications as HTML5

Doug Schepers-3
Hey, folks-

On 8/18/11 11:34 PM, Ian Jacobs wrote:

>
> On 18 Aug 2011, at 10:28 PM, Karl Dubost wrote:
>
>> Le 18 août 2011 à 23:20, Ian Jacobs a écrit :
>>> For XML processors.
>>
>> If all the tags are closed and the attributes are quoted (aka "XML
>> well-formed"), would it be enough for the XML pubrules tools?
>
> The original goal was not to make the pubrules checker happy, but to
> have a version readily consumable by any xml consumer. It turns out
> that will help the existing pubrules checker, but that's not the main
> goal.

Arguably, people using the XML toolchain would be in a better position
to adapt the content to their needs than the average Web developer, who
may benefit more from the simpler syntax of HTML5.

Regards-
-Doug

Reply | Threaded
Open this post in threaded view
|

Re: Publication of specifications as HTML5

Karl Dubost-3
In reply to this post by Ian Jacobs-2

Le 18 août 2011 à 23:34, Ian Jacobs a écrit :
>> If all the tags are closed and the attributes are quoted (aka "XML well-formed"), would it be enough for the XML pubrules tools?
>
> The original goal was not to make the pubrules checker happy, but to have a version readily consumable by any xml consumer.

so the question remains :)
Will XML well formed be enough for any xml consumer. It would be a low hanging fruit easy to achieve and that could satisfy everyone.

--
Karl Dubost
Montréal, QC, Canada
http://www.la-grange.net/karl/


Reply | Threaded
Open this post in threaded view
|

Re: Publication of specifications as HTML5

David Carlisle
On 19/08/2011 11:53, Karl Dubost wrote:
> Will XML well formed be enough for any xml consumer. It would be a
> low hanging fruit easy to achieve and that could satisfy everyone.

It depends why the "html4" requirement is there in the first place.

We've had the same problem with mathml forever, and I guess svg is the
same, in that we couldn't inline mathml examples into the normative
version of the spec. Which is sort of reasonable in early versions of
the spec: you shouldn't have to have a working zzz system before you can
read the spec to find out how to implement zzz.

Given that the "html5" syntax is largely defined to fall back gracefully
in legacy systems, I don't think there is really any need to restrict
the syntax (nor particularly to force the syntax to be xml. Yesterday
for example I experimented putting the full whatwg "complete" spec
through an xslt saxon pipeline to tex and thus to pdf and it only took
literally a few minutes to set up (using the validator.nu sax parser at
the front end) downloading the file took longer.

So I think the syntactic requirements to use an html4 or xhtml1 doctype
are not needed.

What may (or may not?) be needed are content model restrictions on using
or not using new "html5" structural features. Could a normative version
of the spec use canvas for example?

David

________________________________________________________________________
The Numerical Algorithms Group Ltd is a company registered in England
and Wales with company number 1249803. The registered office is:
Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.

This e-mail has been scanned for all viruses by Star. The service is
powered by MessageLabs.
________________________________________________________________________

Reply | Threaded
Open this post in threaded view
|

Re: Publication of specifications as HTML5

r12a
In reply to this post by Karl Dubost-3
Here are some things to consider:

[1] there are additional rules for polyglot documents to ensure that the
document works as XML and HTML (for example, no XML declaration allowed,
therefore encoding can only be utf-8 (or utf-16 but that was excluded
from polyglot)).  So it's not just xml well-formedness. Having said
that, I don't think there are many additional rules to worry about.
That's what the polyglot spec describes: http://www.w3.org/TR/html-polyglot/

[2] there are features of HTML5 that are not yet widely supported.  I
think that what's needed is a defined subset of HTML5 for editors to use
that reflects what is currently supported on major browsers.  That
subset should imo be revised as soon as new www.orfeatures become
supported by major browsers, eg. the dir=auto value will hopefully be
supported soon, but it isn't yet.  It also assumes a decision that we
are happy that people may struggle with 'non-major' browsers that may
not yet support html5 features, and may have to view with a different
browser.  It also requires defining what consitutes a 'major' browser.

[2a] for html5 support in IE you currently need javascript help. We need
to agree that it is acceptable that people who are not running
javascript on IE will struggle.


RI



PS: I have already started producing new or updated i18n articles in html5.


On 19/08/2011 11:53, Karl Dubost wrote:
>
> Le 18 août 2011 à 23:34, Ian Jacobs a écrit :
>>> If all the tags are closed and the attributes are quoted (aka "XML well-formed"), would it be enough for the XML pubrules tools?
>>
>> The original goal was not to make the pubrules checker happy, but to have a version readily consumable by any xml consumer.
>
> so the question remains :)
> Will XML well formed be enough for any xml consumer. It would be a low hanging fruit easy to achieve and that could satisfy everyone.
>

--
Richard Ishida
Internationalization Activity Lead
W3C (World Wide Web Consortium)

http://www.w3.org/International/
http://rishida.net/


Register for the W3C MultilingualWeb Workshop!
Limerick, 21-22 September 2011
http://multilingualweb.eu/register

Reply | Threaded
Open this post in threaded view
|

Re: Publication of specifications as HTML5

r12a
[resending because my client only did 'reply list' and i'm not sure
whether arhye and karl are on that list]

Here are some things to consider:

[1] there are additional rules for polyglot documents to ensure that the
document works as XML and HTML (for example, no XML declaration allowed,
therefore encoding can only be utf-8 (or utf-16 but that was excluded
from polyglot)).  So it's not just xml well-formedness. Having said
that, I don't think there are many additional rules to worry about.
That's what the polyglot spec describes: http://www.w3.org/TR/html-polyglot/

[2] there are features of HTML5 that are not yet widely supported.  I
think that what's needed is a defined subset of HTML5 for editors to use
that reflects what is currently supported on major browsers.  That
subset should imo be revised as soon as new www.orfeatures become
supported by major browsers, eg. the dir=auto value will hopefully be
supported soon, but it isn't yet.  It also assumes a decision that we
are happy that people may struggle with 'non-major' browsers that may
not yet support html5 features, and may have to view with a different
browser.  It also requires defining what consitutes a 'major' browser.

[2a] for html5 support in IE you currently need javascript help. We need
to agree that it is acceptable that people who are not running
javascript on IE will struggle.


RI



PS: I have already started producing new or updated i18n articles in html5.


On 19/08/2011 11:53, Karl Dubost wrote:
 >
 > Le 18 août 2011 à 23:34, Ian Jacobs a écrit :
 >>> If all the tags are closed and the attributes are quoted (aka "XML
well-formed"), would it be enough for the XML pubrules tools?
 >>
 >> The original goal was not to make the pubrules checker happy, but to
have a version readily consumable by any xml consumer.
 >
 > so the question remains
 > Will XML well formed be enough for any xml consumer. It would be a
low hanging fruit easy to achieve and that could satisfy everyone.
 >

--
Richard Ishida
Internationalization Activity Lead
W3C (World Wide Web Consortium)

http://www.w3.org/International/
http://rishida.net/


Register for the W3C MultilingualWeb Workshop!
Limerick, 21-22 September 2011
http://multilingualweb.eu/register



Reply | Threaded
Open this post in threaded view
|

Re: Publication of specifications as HTML5

Ian Jacobs-2
In reply to this post by Doug Schepers-3

On 18 Aug 2011, at 11:59 PM, Doug Schepers wrote:

> Hey, folks-
>
> On 8/18/11 11:34 PM, Ian Jacobs wrote:
>>
>> On 18 Aug 2011, at 10:28 PM, Karl Dubost wrote:
>>
>>> Le 18 août 2011 à 23:20, Ian Jacobs a écrit :
>>>> For XML processors.
>>>
>>> If all the tags are closed and the attributes are quoted (aka "XML
>>> well-formed"), would it be enough for the XML pubrules tools?
>>
>> The original goal was not to make the pubrules checker happy, but to
>> have a version readily consumable by any xml consumer. It turns out
>> that will help the existing pubrules checker, but that's not the main
>> goal.
>
> Arguably, people using the XML toolchain would be in a better position to adapt the content to their needs than the average Web developer, who may benefit more from the simpler syntax of HTML5.

One idea was not to require a particular syntax, but to provide a translation service.

Ian

>
> Regards-
> -Doug
>

--
Ian Jacobs ([hidden email])    http://www.w3.org/People/Jacobs/
Tel:                                      +1 718 260 9447


Reply | Threaded
Open this post in threaded view
|

Re: Publication of specifications as HTML5

Karl Dubost-3
In reply to this post by r12a

Le 19 août 2011 à 07:29, Richard Ishida a écrit :
> [1] there are additional rules for polyglot documents to ensure that the document works as XML and HTML (for example, no XML declaration allowed, therefore encoding can only be utf-8 (or utf-16 but that was excluded from polyglot)).  So it's not just xml well-formedness. Having said that, I don't think there are many additional rules to worry about. That's what the polyglot spec describes: http://www.w3.org/TR/html-polyglot/

I know what polyglot prescribes. :) It is not what we are discussing here.
What I was aiming at are along these:

1. Finding a ground where
        - a group could publish its documents in HTML5
        - the tools using W3C specifications pre/post publishing would not be disturbed.
2. To not worry about formalism but being practical about what we want to achieve.


> what's needed is a defined subset of HTML5 for editors to use that reflects what is currently supported on major browsers.


This seems to be a good goal to pursue. It is why I was thinking of an HTML file which could be "seen as xml"
http://caniuse.com will help here

What I have not seen on the discussion thread yet (and that I would like to see) is
What are the current *tools* requirements for processing/hosting a document on W3C space?
With these requirements, *we* (the community altogether) can decide what is usable or not.

--
Karl Dubost
Montréal, QC, Canada
http://www.la-grange.net/karl/


Reply | Threaded
Open this post in threaded view
|

Re: Publication of specifications as HTML5

Leif Halvard Silli-4
In reply to this post by David Carlisle
David Carlisle, Fri, 19 Aug 2011 12:09:41 +0100:
> On 19/08/2011 11:53, Karl Dubost wrote:
>> Will XML well formed be enough for any xml consumer. It would be a
>> low hanging fruit easy to achieve and that could satisfy everyone.
>
> It depends why the "html4" requirement is there in the first place.
>
> We've had the same problem with mathml forever, and I guess svg is the
> same, in that we couldn't inline mathml examples into the normative
> version of the spec.
  [...]
> What may (or may not?) be needed are content model restrictions on using
> or not using new "html5" structural features. Could a normative version
> of the spec use canvas for example?

Regarding 'inline': Perhaps I don't understand the problem fully, but
the promise of Polyglot Markup is that the document can be consumed as
XML. Thus, with Polyglot Markup you *could* use inline mathml and svg.
(Another way to, at least keep the SVG/MathML in the same docuent, is
to embed the foreign content as data: uris.)

Of course, in legacy browsers, inline foreign content when consumed as
HTML may not work, unless there is a script or some fallback. So,
w.r.t. content model restrictions, then fallback requirments also seems
relevant to include. Proper fallback requirements could perhaps permit
canvas - and other XML-less features - to be used.
--
Leif Halvard Silli

Reply | Threaded
Open this post in threaded view
|

Re: Publication of specifications as HTML5

David Carlisle
On 19/08/2011 15:09, Leif Halvard Silli wrote:
> Thus, with Polyglot Markup you*could*  use inline mathml and svg.

My point is that the syntactic variation between xml and html4 and html5
are not really so interesting/important here, (so polyglot or not isn't
so important either). The point (As Richard Ishida made using some other
examples) is what structural elements do we want to allow and, related,
what browsers do we want to support.

If there is a requirement to support browsers that don't do mathml or
svg or canvas or dir=auto or.... then we need to omit those features (or
specify exactly how fallback is supposed to work) for normative
documents. The question about whether to use xml or html5 syntax for the
features that are allowed may come up, but it is less important as it's
fairly trivial for anyone processing a document to serialise an html
document as xml or an xml document as html, but if examples are in
mathml or canvas or assume full bidi processing, then the document is
pretty hard to read using a browser without those features.

David

________________________________________________________________________
The Numerical Algorithms Group Ltd is a company registered in England
and Wales with company number 1249803. The registered office is:
Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.

This e-mail has been scanned for all viruses by Star. The service is
powered by MessageLabs.
________________________________________________________________________

Reply | Threaded
Open this post in threaded view
|

Re: Publication of specifications as HTML5

Aryeh Gregor-4
In reply to this post by Ian Jacobs-2
On Thu, Aug 18, 2011 at 11:20 PM, Ian Jacobs <[hidden email]> wrote:
> I had understood "conforms to http://www.w3.org/TR/html-polyglot/"
>
> For XML processors.

Polyglot is not targeted at XML processors.  The idea of a polyglot
document is that the same file should work the same in a *browser*
whether it's served as text/html or an XML MIME type.  In practice,
however, this isn't useful, because all browsers support text/html, so
there's no need to serve with two MIME types.

If we're concerned about non-browser XML processors, we shouldn't need
polyglot.  All we should need is to make an XML serialization of the
spec available, or just make a text/html-to-XML converter available.
Then existing XML toolchains could process the document by just adding
one extra conversion step.  If you have html5lib installed, a
text/html-to-XML converter should take <10 lines to write and take a
negligible amount of time to run, less than fetching the file from the
network.

The key difference here is that a polyglot document tries to be
equivalent text/html and XML the the *same file*, *and* they try to
produce the same DOM (or almost) when parsed either way.  This is
actually very nontrivial, and it's not necessary if we only want to
support XML processing.

On Fri, Aug 19, 2011 at 7:09 AM, David Carlisle <[hidden email]> wrote:
> What may (or may not?) be needed are content model restrictions on using
> or not using new "html5" structural features. Could a normative version
> of the spec use canvas for example?

This question is not specific to the HTML markup.  A spec could also
conceivably use CSS or JavaScript that's not supported by all
browsers, like localStorage or such.  It could even use features that
are in RECs but aren't universally supported.  For instance, you could
write a page that works perfectly in any browser that supports HTML
4.01 and CSS 2.1, but which is totally unreadable in IE6 and 7.
That's about 13% of browsers by market share that can't read the page
(using Wikimedia's statistics).  Likewise, HTML5 uses some Unicode
characters that display as boxes on my computer -- that doesn't break
any standard, but it's arguably a bad idea anyway, and certainly would
be if it were confusing.

I think we have to be pragmatic here and judge on a case-by-case
basis, based on real-world UA behavior rather than nominal maturity
levels.  The goal of a specification is to be read and understood,
after all.  As long as the markup used is such that it will be clearly
and accurately understood by pretty much any CSS-supporting browser
people are going to use -- say without JavaScript or plugins -- that
should be okay.

So if the spec author wants to include an example, which is clearly
marked as an example, which uses <canvas> and says "If your browser
supports <canvas>, you'll see a smiley face here:", such that if the
browser doesn't support <canvas> it instead displays fallback text
like "Your browser does not support canvas :(", then I think that's
not a problem.  Depending on <canvas> (or any other JS) for normative
text is obviously a non-starter, and also a bad idea if it's not
really clear what's happening in non-supporting browsers.

But all this is only realistically decidable on a case-by-case basis.
It should just be a corollary of "specifications have to be clearly
written".  I think it's quite a separate question from what formats we
should allow to begin with.  Obviously W3C specs should be published
in HTML+CSS+JS, not PDF or Flash or anything, nor using nonstandard
extensions.  But I don't see a reason to restrict the exact versions
used, provided they're standard or being standardized and the features
work in practice.

On Fri, Aug 19, 2011 at 7:25 AM, Richard Ishida <[hidden email]> wrote:
> [1] there are additional rules for polyglot documents to ensure that the
> document works as XML and HTML (for example, no XML declaration allowed,
> therefore encoding can only be utf-8 (or utf-16 but that was excluded from
> polyglot)).  So it's not just xml well-formedness. Having said that, I don't
> think there are many additional rules to worry about. That's what the
> polyglot spec describes: http://www.w3.org/TR/html-polyglot/

It's actually very hard to produce real polyglot documents
automatically.  For instance, there is no markup that will produce a
script tag with a single Text child that contains < or & that will
work in both text/html and XML.  <script><</script> works in
text/html, but is not XML.  <script>&lt;</script> works in XML, but
produces a different DOM as text/html ("&lt;" is treated as four
literal characters instead of one entity).  In practice you have to
use hacks like <script>/*<![CDATA[*/</*]]>*/</script> that more or
less work the same but don't actually produce the same DOM.  So we
should not be talking about polyglot unless we *really* mean polyglot,
rather than just "let's make a text/html-to-XML converter available".

> [2] there are features of HTML5 that are not yet widely supported.  I think
> that what's needed is a defined subset of HTML5 for editors to use that
> reflects what is currently supported on major browsers.  That subset should
> imo be revised as soon as new www.orfeatures become supported by major
> browsers, eg. the dir=auto value will hopefully be supported soon, but it
> isn't yet.  It also assumes a decision that we are happy that people may
> struggle with 'non-major' browsers that may not yet support html5 features,
> and may have to view with a different browser.  It also requires defining
> what consitutes a 'major' browser.

As noted, this is not specific to HTML5 -- it even applies to things
that are in CSS2.1 and haven't changed since CSS2.  I don't think we
can make a precise list, it should be more like guidelines whose
interpretation can change over time.

Reply | Threaded
Open this post in threaded view
|

Re: Publication of specifications as HTML5

Leif Halvard Silli-4
In reply to this post by David Carlisle
David Carlisle, Fri, 19 Aug 2011 15:41:55 +0100:
> On 19/08/2011 15:09, Leif Halvard Silli wrote:
>> Thus, with Polyglot Markup you*could*  use inline mathml and svg.

> If there is a requirement to support browsers that don't do mathml or
> svg or canvas or dir=auto or.... then we need to omit those features (or
> specify exactly how fallback is supposed to work) for normative
> documents.
>
> The question about whether to use xml or html5 syntax for the
> features that are allowed may come up, but it is less important

You say "syntax". Do you really mean MIME type?

IMO, the question of whether to serve as application/xhtml+xml and/or
text/html should be seen as an integral part of the question about
which legacy browser - and whether - to support legacy browsers.

Because, legacy IE is not the only legacy browser for which support
should be considered: Firefox before version 4 (?) has problems with
unknown HTML elements - as mentioned in the WHATwg blog once, the
problem is solved by serving as XML. Likewise, when it comes to SVG,
then legacy support is old, as long as the page is served as XML.

So: Just as legacy version of IE needs - as Rich pointed out -
JavaScript to support HTML5, other legacy browsers needs
application/xhtml+xml in order to support the features you had in mind
- SVG and MathML - and even HTML5 itself.

One should define:

  1. A feature level (taking into account the possibilities,
     including application/xhtml+xml)
  2. Which strategies are REQUIRED to follow to make as many
     browsers as possible support that feature level
  3. Optional strategies, to support even more browsers.

> as it's
> fairly trivial for anyone processing a document to serialise an html
> document as xml or an xml document as html, but if examples are in
> mathml or canvas or assume full bidi processing, then the document is
> pretty hard to read using a browser without those features.

Well, what the browser supports, partly depends on how the document is
delivered. So I can't see that serialization can be separated from the
feature question.
--
Leif H Silli

Reply | Threaded
Open this post in threaded view
|

Re: Publication of specifications as HTML5

Leif Halvard Silli-4
In reply to this post by Karl Dubost-3
Karl Dubost, Fri, 19 Aug 2011 09:21:27 -0400:
> Le 19 août 2011 à 07:29, Richard Ishida a écrit :

>> http://www.w3.org/TR/html-polyglot/
>
> I know what polyglot prescribes. :) It is not what we are discussing here.
> What I was aiming at are along these:
>
> 1. Finding a ground where
> - a group could publish its documents in HTML5
> - the tools using W3C specifications pre/post publishing would not
> be disturbed.
> 2. To not worry about formalism but being practical about what we
> want to achieve.

We are not discussing what polyglots require - for that we have
Bugzilla. But the argument that polyglots fits well - for instance it
should fulfill your 1st point, no? As for your second point: If there
are requirements in Polyglot Markup that you consider formalism, only,
then please file a bug.

>> what's needed is a defined subset of HTML5 for editors to use that
>> reflects what is currently supported on major browsers.
>
> This seems to be a good goal to pursue. It is why I was thinking of
> an HTML file which could be "seen as xml"
> http://caniuse.com will help here

To ensure that XML can be seen as HTML - and HTML as XML - is the
purpose for which Polyglot Markup has been defined.

For instance, caniuse.com shows that IE below version 9 does not
support application/xhtml+xml. However, if the file is served with the
.html suffix, then IE will sniff it as HTML anyhow.

> What I have not seen on the discussion thread yet (and that I would
> like to see) is
> What are the current *tools* requirements for processing/hosting a
> document on W3C space?
> With these requirements, *we* (the community altogether) can decide
> what is usable or not.

+1
--
Leif H Silli
123