RE: example spec text for longdesc

Ian Hickson wrote: 
> 
> Well, it reintroduces longdesc, a feature which is almost universally
> misused and will therefore do basically nothing but cause users pain,
> something which has been repeatedly explained.

s/explained/asserted 

You have continually stated this position with no proof of "harm" to back
up this statement. What kind of pain will this cause exactly? And to whom?
It seems there are 3 conditions that could exist:

1) author fails to provide @longdesc at all 

   Outcome: users who could benefit from longer textual descriptions,
primarily non-sighted users, are negatively impacted by the author's
failure to provide longer text. 
(This is an educational problem with authors)

2) author misuses @longdesc by writing [longdesc="This is my longer
description here..."] 

   Outcome: author effort is discarded by user-agents that DO support
@longdesc as they have incorrectly authored the attribute's content. Net
effect on the end-user is the equivalent to if/when author fails to
provide @longdesc values at all. However, pages authored as such continue
to render in browser screens (no draconian error) for sighted users. 
(This is an educational problem with authors; this could be partially
mitigated by evaluation tools/validators examining the value string for
@longdesc to ensure it is either a URI or IDREF)

3) author correctly uses @longdesc (based upon better spec text, examples,
etc. in the newer HTML5 specification)

   Outcome: users who require longer textual descriptions are accommodated
with their needs, while authors constrained by design restrictions etc.
have a mechanism designed to still provide this accommodation.


There are many who feel that reinstating @longdesc is a good thing, and
the work has gone into providing the use-cases which show where and why
@longdesc is the appropriate mechanism to solve the problem. Recognizing
that @longdesc was most likely under-specified in HTML 4, a number of us
have sought to correct that problem as well, resulting in the proposed
text submitted. 

If you continue to believe that the use-cases presented can be solved
using other methods, then please do feel free to work on an alternative
Change Proposal to the one submitted against Issue 30. It is anticipated
that the Chairs will be issuing a CfCP within the next few weeks.
Meanwhile, I personally have worked with engineers and developers who also
concur with our premise that @longdesc serves a useful need, and have
sought ways and proof-of-concept examples that browser developers could
adopt to improve the user-experience for a wider range of users than
simply those who are visually impaired - those examples are referenced in
the draft text.

Meanwhile as an assumed professional, impartial technical editor, your
editorial advice was sought against proposed text. It is too bad that you
continue to mix your personal bias into a role that should be neutral in
nature: this is not the Ian Hickson specification, it is the W3C
specification, and as such it represents both collaboration and consensus
of a larger group. I
believe it would best serve the entire group if you could recognize and
apply that to this work effort.

JF

Received on Tuesday, 22 March 2011 19:44:55 UTC