[Bug 9352] Make unescaped & conforming in attribute values in some cases

http://www.w3.org/Bugs/Public/show_bug.cgi?id=9352





--- Comment #3 from Maciej Stachowiak <mjs@apple.com>  2010-04-02 07:03:14 ---
(In reply to comment #2)
> > However, for an author to be aware of this kind of error, they must be
> > regularly using a conformance checker (or equivalently, a tool that ensures
> > conformance at the output stage). Then the conformance checker can tell them if
> > they have used a construct that actually will be interpreted as an entity
> > reference, rather than merely one that might be, if edited.
> 
> This is incorrect. It is possible for an author to be aware of this error due
> to regular usage of a validator but to still write markup that is not tested by
> a validator. For instance, I am an example of such an author: I run the
> validator every time I edit the HTML5 spec, but I almost never use the
> validator otherwise. Making this an error means that authors are more likely to
> always use the right style, even on projects where they don't use the
> validator.

I think the average author is far less likely than you to learn in that way.
For the few that are, they are probably aware enough to think about what might
be a real entity. Giving an error that 99.99% of the time is not a real bug is
a very inefficient way to teach authors about the possible cases that are
potential bugs.

> Making the mistake with a real entity such as "amp" or "copy" can be really
> hard to track down, especially with long URLs with lots of query parameters.
> Unless we change how such strings are parsed, we are not doing authors any
> favours by hiding this problem. Good practices here are a huge aid to reducing
> problems in real work, and we should be encouraging those practices.

This supposedly good practice seems to be the most violated single HTML5
conformance requirement by orders of magnitude. It seems to me that: (a)
authors do not see the value of escaping & in cases where it makes no
difference, solely to train themselves; and (b) this makes validator output so
noisy that in many cases it is hard to see real errors. Thus, requiring this to
be an error even in cases where there is no harm makes the validator a *less*
useful tool rather than *more*. If the motive is to help authors, then I think
this particular form of help is misguided.

> (I'm not closing this yet; I'll revisit this once I've addressed bug 9351.)

Fair enough.


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Friday, 2 April 2010 07:03:16 UTC