[whatwg] Make quoted attributes a conformance criteria

[Eduard Pascual]

On Thu, Jul 23, 2009 at 3:32 PM, Kornel<kornel at geekhood.net> wrote:
> On 23 Jul 2009, at 13:35, Keryx Web wrote:
>
>> I'd say it is safe to say that using quotation marks for attribute values,
>> always, except perhaps for collapsed, boolean attributes, has been regarded
>> as best practice for a long time now. Speaking as an instructor for newbies,
>> enforcing quotation marks has proven its value countless of times for me and
>> my students.
>
> It's not a clear benefit. Unpaired quotation marks can also be a *source* of
> errors, which wouldn't happen without them:
>
> <a href="http://example.com class="test">
Sure, and unpaired angle brackets would also be a source of errors;
and that doesn't make angle brackets optional.
The point here is that making quotation marks optional for *some*
attributes doesn't prevent this kind of problem, because an author may
leave the marks unpaired on some of the attributes that require them.
However, the quotation marks being *sometimes* optional is quite
dangerous, since an author needs to exactly remember when they are
needed and when they aren't; and using always quotation marks does
avoid this problem.

>> I'd say that all of my colleagues in WaSP EduTF would agree on that.
>> Others share that sentiment too:
>> http://twitter.com/burningbird/status/2765482250
>
> I disagree about making it a conformace criterion. This is not required to
> get text/html documents parsed reliably and unambiguously.
With HTML5, no matter how much garbage you sent to the browser, it is
always well-defined how it must be parsed. The browser doesn't really
care about conformance: it just takes an input, parses it according to
the HTML5 parsing rules, and renders the resulting DOM. So, what is
actually required for reliable parsing, besides these parsing rules?
Of course, even if unquoted attributes were non-conformant, they'd
just get parsed as defined by the current draft; only validators would
care; and I think it is a good thing to have validators highlight such
details that can easily lead to so many issues.


> I wouldn't mind much if specification used more quotes in examples, however
> I'm afraid that taking this to the extreme could give false impression that
> unquoted attributes are an error, and spec would fail to illustrate when
> quotes are necessary and when they're perfectly safe to omit.
Again, the point is not that *sometimes* it is safe to omit the
quotes. The issue is with remembering when it is safe and when it is
unsafe. If an author messes up and omits quoting an attribute that
needs quotes, thinking they are optional, problems begin. If an author
thinks "always quote attributes", then this kind of errors have no
chance to happen (of course, it is possible to miss a quote, but this
is a typo rather than a conceptual error; and no language can do
anything to entirelly avoid typos).

In other words, it is safer to always quote attributes than to mistake
what's required and what not. Take this example:
<style>.foo { /* some declarations here */ }
.bar { /* and more declarations */ }</style>
...
<span class=foo>It was safe to omit the quotes!</span>

Now, someone who is maintaining that code may realize that the .bar
class also applies to that <span>. The chance for that person to put
out something like this is too high:
<span class=foo bar>It was safe to omit the quotes!</span>

Is "bar" a second class, or an unrecognized empty attribute? In
general, at any time changes on a document may make a previously
optional quotation to become needed; and such changes are too easy to
overlook. Furthermore, with the previous example, what'd happen if
HTML6 defines a new empty "bar" attribute that alters the rendering
and/or semantics of elements?

>> Add:
>> In order to avoid errors and increase readability, using quotes is highly
>> recommended for all non-omitted attribute values.
>
> To me min=0 is more readable than min="0". This is a matter of opinion, and
> IMHO spec should not enforce one's coding style.
The part on readability is indeed a matter of style; but the part of
avoiding errors is quite valid. Maybe a more to-the-point wording
would work better; how about something like this?:
"Quoting attribute values is always allowed, but only sometimes
required. In case of doubt, the safest choice is to quote the value."

> --
> regards, Kornel
>
>