Ian Hickson wrote:
On Wed, 23 May 2007, Julian Reschke wrote:
and requiring content authors to send the proper mime types.
This is required by HTTP.
Yes, but by speccing that UAs will ignore it you weaken that
requirement. That's why I would like to see that happening somewhere
else.
Minimally, every time HTML5 requires recipients to ignore the content
type, it should also remind content authors that they should supply a
proper content type nevertheless.
That might work. I'll try to keep that in mind.
Great.
...
That may be the case, but you are e-mailing the WHATWG here, not the HTML
working group.
(In point of fact, however, I would imagine that if the HTML working group
didn't work on a spec that told the user agents what to do, the browser
vendors would be likely to leave the HTML working group. I personally am
only interested in editing the spec that says what the user agents must
do, as it's the only spec with relevance in the real world. If the spec
I'm working on isn't that spec, then I'll stop working on it, and return
to working on the spec with real-world relevance.)
But that's exactly the UA-centric nature of the WHATWG specs that I
don't like (and I don't think I'm alone). A spec that spends 75% of it's
space to specify error recovery for UAs is IMHO not the optimal place to
specify the semantics of HTML.
...
The entire point of specifications is to remove decisions like that from
the implementors. :-)
Sometimes, but I don't think it's the case here.
A MUST level requirement to ignore the content-type forces an
implementor to either break RFC2616 or HTML5. Am I the only one who
thinks that the "all-specification-decisions-belong-to-us" philosophy is
problematic, when it affects other parts of the protocol stack?
If you think that this is wrong, you'll have to try to change *that*
(I know you tried...), but just ignoring it in a W3C spec is
unlikely to be accepted.
Accepted by whom? The browser vendors are the main "clients" of this
spec. Why would they not accept something that described what they had
to do?
Accepted by the W3C.
I don't particularly care if the W3C accepts or doesn't accept the HTML5
spec. They're not the ones who have to implement the spec, or who will
decide how successful the specification is. It's the browser vendors who
have that role.
Yes, but I thought the "plan" was to take HTML5 and take it through the
W3C process? So, if you don't care, why did you volunteer to edit that spec?
The _TAG findings_ are what haven't been accepted.
If you want to proceed with this activity inside the W3C, I think you
really can't ignore what's been stated before. I don't see how HTML5 (as
a W3C spec) can be incompatible with that TAG finding -- one or both
will need to change.
I'm happy for the TAG finding to change. The HTML5 spec can't change,
since it is constrained by the large amount of existing content.
That discussion will take place on the W3C HTML mailing list then.
...
2) I recall one instance where a WHATWG member requested a change in a
mail to the former HTTP WG's mailing list, and as far as I can recall,
he/she failed to get support for that (was it Content-Location?).
Anyway, please provide a more precise pointer, or follow up on that
mailing list.
Content-Location is the prime example I was thinking of, yes.
The mailing list thread is at
<http://lists.w3.org/Archives/Public/ietf-http-wg/2006OctDec/thread.html#msg190>.
I don't think it was discussed to the end, but on the other hand I
also don't see any kind of consensus to make a change. Maybe you should
restart it then.
...
Best regards, Julian
