Re: Change Proposal for ISSUE-125

On Nov 17, 2010, at 2:34 AM, Anne van Kesteren wrote:

> On Wed, 17 Nov 2010 03:36:07 +0100, Roy T. Fielding <fielding@gbiv.com> wrote:
>> As mentioned before, there is no reason for any difference in syntax.
>> In fact, there is none in practice.  The only reason that this is an
>> issue at all is because the draft contains incorrect statements and
>> unimplemented algorithms, apparently based on bugs in a single browser.
>> The solution is to remove the contradiction from the spec by restoring
>> the original text that defined meta and http-equiv.
> 
> It is not true at all that browsers follow HTTP for <meta http-equiv>.

That is irrelevant.  http-equiv is not a requirement on browsers to *do*
anything.  It is metadata of a defined form, syntax, and semantics.
META exists in HTML because a lot of non-browser applications believe
that metadata should be managed within the document file instead of
in some external data store.  http-equiv exists because it provides
a standard namespace for metadata that lots of Web-related applications
care about, which was known to be valuable even back in the days before
scope could be defined via xmlns or profile attributes.

> E.g.
> 
>  <meta http-equiv=content-type content=text/xml>
> 
> will not be honored.
> 
> Not all HTTP headers supported at the HTTP layer are supported in <meta http-equiv> either. Only a couple. Furthermore, per HTML4 <meta http-equiv> was some preprocessing instruction for servers, that never got implemented. So restoring the original text -- assuming you are referring to HTML4 -- would not work either.

There was a description of how it *could* be used for server-side processing,
which actually was implemented directly by some servers (e.g., WN) and indirectly
via crontab by many others (e.g., to feed Apache var maps).  Regardless, the
syntax and semantics continues to be implemented by many authoring tools.
Restore the original HTML 2.0 text if you like.

We have gone over this before.  Browser behavior does not completely define
HTML as a markup language.  The fact that some browsers started using that
metadata as a backup (and, in some cases, a replacement) for HTTP metadata
when it was not present in an HTTP response does not imply that the new definition
of the mark-up language is reduced to what some subset of browsers do upon
seeing that metadata.  The only thing such behavior needs from the standard
is an additional paragraph or two that states when, where, and how such browser
behavior occurs.  The original definitions are still implemented and
relied upon by the vast majority of vendors that also depend on the HTML
standard, even though they are not implementing a browser.

....Roy

Received on Wednesday, 17 November 2010 20:12:28 UTC