W3C home > Mailing lists > Public > public-html@w3.org > January 2010

Re: XHTML Syntax Served as text/html (Was: Decentralized poetry markup (language))

From: Smylers <Smylers@stripey.com>
Date: Wed, 20 Jan 2010 18:04:09 +0000
To: public-html@w3.org
Message-ID: <20100120180409.GC10027@stripey.com>
Leif Halvard Silli writes:

> Smylers, Wed, 20 Jan 2010 16:14:59 +0000:
> 
> > Leif Halvard Silli writes:
> > 
> > > Tab Atkins Jr., Tue, 19 Jan 2010 12:36:42 -0600:
> > > 
> > > > On Tue, Jan 19, 2010 at 12:23 PM, Leif Halvard Silli:
> > > > 
> > > > > So, with HTML5 we get two kinds of text/HTML: "real" text/HTML
> > > > > and XHTML text/HTML. The latter gives us much more freedom
> > > > > than HTML5.
> > > > 
> > > > The latter does not exist.  If a file is served with the
> > > > text/html mimetype, it is an HTML document, and is processed
> > > > according to HTML rules.  ... There is no longer any such thing
> > > > as "XHTML served as text/html".
> > > 
> > > The W3 validator allows me to validate a XHTML document served as
> > > text/HTML.
> > 
> > The validator isn't the canonical source of what is permitted; where
> > the validator and a spec differ at least one of them is buggy.
> 
> If we are permitted to serve XHTML as text/HTML, then it makes sense
> be able to validate such documents as well.

Sure.  But we aren't, in general, permitted to serve such documents.

Or at least such documents will be interpreted by user-agents as
text/html.  So it only makes sense to check them against the rules for
valid text/html.

> > When content is being served in a way which will cause all
> > conforming user-agents to treat it as one thing, how is it useful to
> > check its validation as something else?
> 
> Quite. Because, as you know, XHTML and HTML are quite close to each
> others.

Close, but not identical.  And where there are differences, serving as
text/html will cause the document to be interpreted using the HTML
rules.  That it happens to conform to a different (though similar)
language in which a portion has a valid meaning doesn't affect that: it
still either conforms to HTML or it doesn't.

> > Regardless, a change in W3C Validator behaviour cannot affect what
> > is permitted in HTML5.
> 
> My point was merely that if HTML5 refuses to become more relaxed about
> extensions,

HTML5 is very relaxed about extensions: if a community agrees that a
particular extension is relevant to them, then it's permitted.  (Though
admittedly that's more a description of how things are the real world
than any policy by HTML5; it couldn't really be otherwise.)

So if a knitting community come up with a mark-up language for embedding
knitting patterns in webpages, and that community have HTML user-agents
which interpret that language (maybe through a browser plug-in), then
it's valid for other members of that community to serve pages which
makes use of it.

> then there exist another, parallel technology - namely XHTML served as
> text/HTML.

But there isn't.  In doing so you are explicitly instructing user-agents
that the content is HTML and should be interpreted as such.  What they
do with your content is defined by HTML (and any extensions they choose
to recognize).

If you choose an extension which your user-agent isn't aware of, but the
extension may safely be ignored, then the page will still be interpreted
correctly.  And it will be valid HTML5+your extension.  That's probably
all that matters.

Of course it won't be valid HTML5.  But that isn't particularly relevant
to what you're serving.  If it happens to be valid XHTML5 (or Befunge,
or whatever), it _still_ won't be HTML5.

Smylers
Received on Wednesday, 20 January 2010 17:51:37 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:12 UTC