Re: ISSUE-34 (commonality): Can we get access to tools that determine how often markup is used on the web?

Before I respond, I'd like to offer two apologies: first, for the hasty assumption on my part that this issue is aimed at removing unused/under-used elements and attributes. Boris made a good point that nobody had stated that as a goal in this exercise and I had just assumed so.

Second, I apologize for the "top-post".  I think James' excellent response below should be retained in whole so I'm responding above it.

Along the lines of the response offered by Boris, the goal of any modification (including, I suppose, deletions) would be to make HTML simpler and easier to use for the developer in such a way that he/ she would be more likely to apply it properly - the end result being a better experience for all.

At the same time, what concerns me is the appearance that the current path for HTML 5 contains some changes which appear to be born merely from the notion that "well, nobody is using it" or "no browser supports it".  Most notably are the removal of the acronym element, and the longdesc, headers, and axis attributes. I believe the disagreements surrounding some of these items are well documented, so I won't bother rehashing them.  In light of this history, the concept of performing an audit concerning the amount of use certain elements & attributes have *seems* aimed at validating the usefulness of certain features based solely on their rate of use, rather than their usefulness for the end user. 

Karl



----- Original Message -----
From: "James Graham" <jg307@cam.ac.uk>
To: "Karl Groves" <karl.groves@ssbbartgroup.com>
Cc: "HTML Issue Tracking WG" <public-html@w3.org>
Sent: Friday, February 15, 2008 7:47:13 PM (GMT-0500) America/New_York
Subject: Re: ISSUE-34 (commonality): Can we get access to tools that  determine  how often markup is used on the web?


Karl Groves wrote:
> Naturally, the context we're applying these checks are geared toward finding accessibility issues, but it illustrates the point that if we were to guide our decisions of whether to keep/ delete an element or attribute solely on what web authors are doing, we'd be taking the wrong approach which may also have negative effects upon some specific populations of users.
>   
Indeed, we do not want to make changes which make an overall negative 
impact. However knowing exactly which changes will have a detrimental 
effect is not always a-priori obvious, and, in particular, cannot be 
determined merely from looking at the stated goal of the feature being 
considered. Consider the examples discussed in [1]. These are all laws 
which were designed to help some specific population, but have had some 
unexpected negative consequences for the very people they were supposed 
to aid. This illustrates the fact that, even when solutions to problems 
are designed by the leading experts with the best intentions, there 
needs to be a feedback loop to ensure that the original problem actually 
gets solved. Specifically the feedback too has to look like:

1) Design and implement the best solution you can
2) Assess the impact that your solution actually has on the problem you 
were trying to solve through observations/experiment
3) Go to step 1) taking into account what you have learned

Without steps 2) and 3) it is unlikely that you will ever make any 
progress in addressing the issue you originally cared about. For 
developing HTML analysis of existing usage is an essential component of 
step 2).
> I agree with you that "An element that is never used in the correct way has no value to the user", but I disagree that this should necessitate modifying the spec to merely do away with items which have real value.  Improper markup is the developer's fault, not HTML's. At some point, the developer needs to take responsibility for his own shortcomings.
>   
Assigning blame isn't really very interesting unless you are a lawyer 
looking for someone to sue. Nor is it often very helpful; in each of the 
examples in the article one can find a group other than the lawmakers to 
blame for the unintended consequences. However in each case that group 
is acting in it's own economic self interest something which it's 
generally very difficult to prevent people from doing on a large scale. 
Merely suggesting that they take responsibility is unlikely to be 
successful in effecting change.

Applying the feedback loop above to the underlying problem and existing 
solutions is much more likely to work and actually address the issues. 
In the case of HTML accessibility problems, one of the ways to do that 
is to look at what people are already doing and see how we can design 
features to work with that (this has been done somewhat with table 
headers, for example). Another way is to look at where people aren't 
using existing mechanisms to try and work out why. This requires people 
to actively investigate how markup is being used and to be open minded 
enough to accept that there may be a disconnect between the stated 
purpose of something and the effect that it actually has in practice.

[1] 
http://www.nytimes.com/2008/01/20/magazine/20wwln-freak-t.html?_r=1&ex=1358485200&en=0d05099c03c97375&ei=5090&partner=rssuserland&emc=rss&pagewanted=all&oref=slogin

Received on Wednesday, 20 February 2008 20:40:51 UTC