W3C home > Mailing lists > Public > public-html@w3.org > February 2009

head@profile: another dropped attribute

From: Larry Masinter <masinter@adobe.com>
Date: Wed, 4 Feb 2009 16:20:09 -0800
To: HTML WG <public-html@w3.org>
Message-ID: <8B62A039C620904E92F1233570534C9B0118C8515E01@nambx04.corp.adobe.com>
In a fit of enthusiasm, I volunteered to take a fresh look at Issue-55 http://www.w3.org/html/wg/tracker/issues/55

                    headhead/@profile missing, but used in other specifications/formats

in Action-99  http://www.w3.org/html/wg/tracker/actions/99.

This is apparently another open issue long discussed with no resolution.

I think there are shared considerations with Issue-32 table@summary as an attribute dropped from HTML 5 : a feature dropped because a survey showing that it wasn't commonly used (or used properly) "In the wild".

I think the two issues depend to some extent on the following general policy questions:


 *   whether HTML 5 should recommend *any* practice that doesn't correspond to content that is commonly found "in the wild", and if so, what qualifies for inclusion and what doesn't.
 *   In particular, whether attributes and features that are present in HTML4, widely documented and references, should have a higher bar against removal, even if they are not widely used, as long as they are not harmful.

If we had agreement on these policy issues, we might have better luck than trying to battle this attribute-by-attribute.

While the two issues share the basic policy questions, with head@profile, unlike table@summary,  I haven't been able to track down uses in authoring software or web sites, although its use in several other specifications has been noted and documented, so the argument about backward compatibility isn't quite as strong.

For the record, I am strongly in favor, in general, of NOT DROPPING features from HTML4 from the specification in a way that would make valid HTML content and authoring tools invalid.

Rather, it seems preferable from a tool and validity point of view to leaving them in the specification as conforming, but marking them  as deprecated; "deprecated" in the sense of "could be dropped in the future", possibly designating them as SHOULD NOT be used in content, SHOULD BE ignored by browsers.

If there were thousands of dropped attributes, this might be a problem, but it looks like there are a relatively small number, and taking this approach would serve the needs of the  broader HTML community that focuses on applications of HTML on the web that are beyond the needs of the "four popular browsers".

Larry
--
http://larry.masinter.net
Received on Thursday, 5 February 2009 00:20:59 UTC

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