- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Fri, 7 May 2010 15:05:25 -0700
- To: Lachlan Hunt <lachlan.hunt@lachy.id.au>
- Cc: HTML WG <public-html@w3.org>, public-i18n-core@w3.org, www-international@w3.org
On May 7, 2010, at 4:57 AM, Lachlan Hunt wrote: > The layer violation is in HTML4, where it pretends that an http-equiv attribute in the markup intended for the client, is to be used by servers. This has never been the case in practice. The http-equiv and content attributes are used exclusively for client side processing in all instances where they are used for anything at all. Why do I have to keep repeating this? You are wrong. It was used by WN. It is still used by hundreds (if not thousands) of tools for the sake of creating variance maps for content negotiation on servers like Apache httpd. It is even sometimes used to autogen mod_rewrite rules. The only reason it is used less now than it was before is because most CMS have migrated away from file-based artifacts and instead use storage that maintains metadata as properties alongside the data. That does not change the meaning of the existing content that already includes those metadata, nor does it change the meaning of the http-equiv attribute. The http-equiv attribute was specifically designed to be orthogonal to HTML. HTML5 cannot change its definition. HTML5 can deprecate the attribute entirely, if that is desired, or it can choose to perform backflips based on side-effects like the presence of some http-equiv field. Neither should result in a change to the definition of existing content that uses the http-equiv attribute for the sake in which it was originally defined. > This is the case with http-equiv values of Content-Type, Content-Language, Default-Style and Refresh. None of these values, when they occur in the meta element, are ever, nor should they ever be, used by server side processing. Clearly, you are not a server developer. ....Roy
Received on Friday, 7 May 2010 22:05:58 UTC