- From: Eduard Pascual <herenvardo@gmail.com>
- Date: Thu, 23 Jul 2009 16:19:15 +0200
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 > >
Received on Thursday, 23 July 2009 07:19:15 UTC