Re: [whatwg] Make quoted attributes a conformance criteria
On Tue, 4 Aug 2009, Henri Sivonen wrote: On Aug 3, 2009, at 05:45, Ian Hickson wrote: Instead of preventing anyone from not using quote marks, I would instead recommend asking your validator vendor to offer you an option to require quote marks and warn you when you have forgotten them. There's a usability cost and a QA cost to adding optional features to a validator, which is why I try to resist requests to add more configuration and optional features to Validator.nu. We need more validators, so that authors can pick the one they want. I'm not saying validator.nu should be the one to support this. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Make quoted attributes a conformance criteria
On Aug 3, 2009, at 05:45, Ian Hickson wrote: On Thu, 23 Jul 2009, Keryx Web wrote: No suggested text, but a rewrite will be necessary if quotation marks becomes a conformance criterion. Instead of preventing anyone from not using quote marks, I would instead recommend asking your validator vendor to offer you an option to require quote marks and warn you when you have forgotten them. There's a usability cost and a QA cost to adding optional features to a validator, which is why I try to resist requests to add more configuration and optional features to Validator.nu. I've gotten requests to add checks inspired by XHTML. These requests generally aren't about true polyglot checking (since few people know how long the actual polyglot checking corner case list is). Also, these requests aren't about code style in general. (Well, actually, Anne asked for indent style checking on Sam's blog comments and another commenter thought Anne was making fun of the quote issue...) Since the requests happen to be about the most prominent syntactic features of XML as opposed to being across the board about code style, I suspect part of the requests is about unease about letting go of extra requirements taught as part of XHTML-as-text/html evangelism. When adding optional warnings to Validator.nu, I'd like to tell apart actual problems from unease of letting go of XHTML-as-text/html before proceeding. (I expect actual problems to be with us always, but I expect the unease to pass with a little time.) The top 4 requests are: * Flagging unquoted attributes. * Flagging implied tags. * Flagging non-lowercase element and attribute names. * Flagging inconsistent use of / on void elements. I think the implied end tags are different from the rest, and I think an option to flag implied tags would be a useful feature to have. I want to implement it, but I have some higher-priority Gecko items on my plate first. Implied tags is different from the rest, because tag inference doesn't necessarily work like authors expect, so automatically generating the tags might not do the right thing. OTOH, the other cases can be safely fixed automatically. (Except some quoting issues; more on that later.) In fact, indent style is also something that could be made consistent automatically by an HTML-aware text editor. When issues are code style issues in nature and don't need human intervention to change to a particular style, I think it's more useful to have an editor that simply reformats code than to have a validator that flags failure to comply to code style without performing the reformatting. Consider Eclipse JDT: If you have bad indents, you don't get warning or error markers in the margin. Instead, you can ask Eclipse to reformat code according to a wide variety of settings. This creates a mild issue: If different people collaborate and have different code formatter settings, having another person's editor reformat code creates some source control issues. However, you don't get error messages, so you are still avoiding the problem that I raised earlier on public-html and the Maciej mentioned here about tool interop (so that you can swap tools without getting a huge bunch of errors). Also note that we can't really eliminate this source control re- indenting issue on the spec level. There's no way we could get everyone to agree on One True HTML indent style. And as long as there isn't One True indent style consistently applied everywhere, I think it doesn't matter much if other syntax is used consistently. Now, people are going to say that it's good to use / consistently, because it helps you see which elements are void elements. It doesn't work that way, though. Because / has no effect on HTML elements, you still need to *know* which elements are void elements, and pretending that / means something poisons the mental model people have and is actually bad for teaching. (People write div class=foo/ or script src=.../ having heard that / closes the element.) Unfortunately, we need to keep / conforming to make it easy to upgrade XHTML-as-text/ html-emitting systems to HTML5. I think it would be rather arbitrary to add a feature for checking the *consistent* use of br vs. br/. Why not br/ vs. br /? foo='bar' vs. foo=bar? Or indent style? As for lower-case names, I don't think people *really* want lower-case names. I think, as a matter of code style, they want *canonical-case* names, which aren't all lower-case for SVG-in-text/html and MathML-in- text/html (definitionURL). I think adding checking for this would have disproportionate ill impact on the parser code base compared to benefit. In a reasonable general-purpose HTML parser implementation, the case information is lost before it is decided if a tag belongs to an HTML, SVG or MathML element and maintaining a special-purpose parser for validation
Re: [whatwg] Make quoted attributes a conformance criteria
On Thu, 23 Jul 2009, 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. I'd say that all of my colleagues in WaSP EduTF would agree on that. [...] For the WHATWG, it doesn't matter how many people agree on something, as we base the spec's text on reasoned debate and research. :-) With this in mind I suggest that the spec would be improved in the (below) following ways, and that we open a discussion about requiring quotation marks for all non-boolean attributes as a conformance criterion. Suggested spec edits (some written in a diff-ish way, not all a true diff, though): Section 1.9 Keep: Attributes are placed inside the start tag, and consist of a name and a value, separated by an = character. The attribute value can be left unquoted if it doesn't contain any special characters. Otherwise, it has to be quoted using either single or double quotes. The value, along with the = character, can be omitted altogether if the value is the empty string. Add: In order to avoid errors and increase readability, using quotes is highly recommended for all non-omitted attribute values. [edit a lot of examples to include quotes] 9.1.2.3 No suggested text, but a rewrite will be necessary if quotation marks becomes a conformance criterion. Instead of preventing anyone from not using quote marks, I would instead recommend asking your validator vendor to offer you an option to require quote marks and warn you when you have forgotten them. This would address your use case, as far as I can tell, without preventing anyone who _likes_ omitting quote marks from doing so. In practice, parsing omitted quote marks is pretty reliably implemented, and it's been valid before and _widely_ used, so it's not an area we can really use to extend the language. Therefore the usual reasons we have to ban things don't really apply here, and I'd rather continue to allow quotes to be omitted. Omitting quotes would also make a large number of pages invalid for more or less stylistic reasons, which would make it harder for people to transition to HTML5, and may annoy them (Why do I have to add these quotes, they don't really add anything -- bah! I hate html5). On Thu, 23 Jul 2009, Kornel wrote: 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. The spec intentionally uses a variety of markup styles (including many I find quote ugly) in order to show that they are all valid, and to not mislead the reader into thinking there are unstated rules. On Thu, 23 Jul 2009, Keryx Web wrote: As for conformance criteria only being about unambiguous parsing: If that is the case we do not need them at all any more, since HTML 5 defines how to handle badly written markup. We also want to make things non-conforming if their parsing behaviour is highly non-intuitive, or if it might be a future extension point, or if there is some harm that might come from using the feature, etc. And speaking directly to Ian H, a few years ago you said on this list that you'd love for the spec to help teachers as much as possible (within the limits of being a spec). My suggested example markup changes is definitely such a help. Unfortunately such benefits have to be balanced against the costs on more experience authors, many of whom like the flexibility of omitting quotes. However, I do think that a conformance checker could support a stricter or teaching mode in which it requires that attributes be quoted and optional tags not be omitted. On Thu, 23 Jul 2009, Eduard Pascual wrote: [p class=foo bar] 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? If HTML6 is written like HTML5, then we wouldn't use bar if it was commonly subject to this mistake. 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. In the introduction section, it now says: # The attribute value can be left unquoted if it doesn't contain any # special characters. Otherwise, it has to be quoted using either single # or double quotes. --
Re: [whatwg] Make quoted attributes a conformance criteria
On Sat, 25 Jul 2009 12:08:23 +0200, Eduard Pascual herenva...@gmail.com wrote: On Fri, Jul 24, 2009 at 9:52 PM, Keryx Webwebmas...@keryx.se wrote: On 2009-07-23 20:32, Eduard Pascual wrote: While I don't consider a hard requirement would be appropriate, there is an audience sector this discussion seems to be ignoring: Authoring Tools' developers. IMO, it would be highly desirable to have some guidelines for these tools to determine when they*should* quote attribute values. There is one further rub. Code that initially has been made by authoring tools have a tendency to wind up in some front end developers lap, to be amended and/or fixed manually at a later stage. That is even more a reason for a strong recommendation about quotes. Furthermore, I doubt that most people on this list did read my blog post I included as an URL when starting this discussion.[1] I can't speak for others, but I did read your post. And still I am convinced that a hard requirement to quote all values is not the best solution. There are some values that MUST be quoted, some that SHOULD be quoted, and even some that SHOULD NOT be quoted. Those that must be quoted are already covered by the spec, and validators will yield the relevant error message when encountering such values unquoted. For those values that *should* be quoted (those that improve in readability when quoted, or those that could lead to errors when they are later changed if unquoted), a warning from the validator should be enough. Finally, there are some values that are better unquoted, such as those attributes that can only take a number (there is no risk of errors, and the quotes would normally hurt readability more than they help it). Actually boolean attributes are allowed to take the empty string as value, and it's not allowed to leave the empty string unquoted. However, boolean attributes aren't subject to the template/backend mismatch because you have to omit the attribute altogether for the false value, so the backend developer has to be responsible for writing out the whole attribute. Therefore, it should be safe to leave boolean attributes unquoted. It should be safe to leave any attribute in the minimized form, because it also isn't subject to the template/backend mismatch. Non-boolean attributes that are safe to leave unquoted: link hreflang meta http-equiv meta charset script charset article pubdate ol start li value a hreflang time datetime progress value max meter value min low high max optimum bdo dir ins datetime del datetime img width height iframe width height embed width height object width height video width height canvas width height area shape hreflang colgroup span col span td colspan rowspan th colspan rowspan scope form autocomplete enctype method input autocomplete formenctype formmethod height max maxlength min size step type width button formenctype formmethod select size textarea cols maxlength rows wrap keygen keytype command type bb type Global non-boolean attributes that are safe to leave unquoted: dir tabindex All other attributes can take one of the special characters [\s'] in the value, or the empty string as the value. -- Simon Pieters Opera Software
Re: [whatwg] Make quoted attributes a conformance criteria
On Fri, Jul 24, 2009 at 9:52 PM, Keryx Webwebmas...@keryx.se wrote: On 2009-07-23 20:32, Eduard Pascual wrote: While I don't consider a hard requirement would be appropriate, there is an audience sector this discussion seems to be ignoring: Authoring Tools' developers. IMO, it would be highly desirable to have some guidelines for these tools to determine when they*should* quote attribute values. There is one further rub. Code that initially has been made by authoring tools have a tendency to wind up in some front end developers lap, to be amended and/or fixed manually at a later stage. That is even more a reason for a strong recommendation about quotes. Furthermore, I doubt that most people on this list did read my blog post I included as an URL when starting this discussion.[1] I can't speak for others, but I did read your post. And still I am convinced that a hard requirement to quote all values is not the best solution. There are some values that MUST be quoted, some that SHOULD be quoted, and even some that SHOULD NOT be quoted. Those that must be quoted are already covered by the spec, and validators will yield the relevant error message when encountering such values unquoted. For those values that *should* be quoted (those that improve in readability when quoted, or those that could lead to errors when they are later changed if unquoted), a warning from the validator should be enough. Finally, there are some values that are better unquoted, such as those attributes that can only take a number (there is no risk of errors, and the quotes would normally hurt readability more than they help it). Even in the case of @type for input, quotes seem quite an overkill: AFAIK, there is no valid value for this attribute that will make them strictly needed; so there is no risk of the author changing the value into something that requires quotes and forget to add them (unless, of course, s/he changes it to something invalid, which will already bring problems of its own). Since input elements tend to be relatively short, and often given in a single line of source, adding boilerplate to them for no purpose doesn't seem to be a good idea. In that post I talked about a common scenario. One developer works on the business logic. It puts out attribute values. Another developer works on the presentation logic. He makes templates. Dev 2 omits the quotes and for a long time it might work, since the business logic in question only produces single word values. Then there might come a change, because dev 1 - or the users of the CMS - suddenly starts to produce longer values. Suddenly things break, and since nobody touched the presentation logic code, it might not be the first place where the developers look for an error. And believe me, lots of back end devs are absolutely clueless about front end issues! Yes, they might skip validation completely, but at least such a rule of thumb can be implemented more easily into their work flow. Again, once the pages are going through a validator, warnings are hints as good as errors to detect the source of the problem. I also note that no one who has spoken against my suggestion claims to have any teaching experience. Although I didn't mention it, because I didn't think it was relevant, I have some teaching experience (I won't claim to have worked my whole life as a teacher; but I have worked as a particular teacher for a few years). Do you really think this: Error: Attribute values must always be quoted would be more educative than this Warning: Values for attribute X should be quoted, or errors might arise if the value is later changed ? And these are just examples of messages. Of course, if you just say your students all the code you provide must validate warnings my go unnoticed. However, you may try something like this all the code you provide must validate; and warnings must be addressed or be properly reasoned. IMO, this kind of details marks the difference between training code-typing zombies or developers capable to solve problems. In summary: I considered your arguments from the teaching perspective; but I consider that the difference between errors and warnings has more didactic value than a totalitarian validator that just rejects safe code based on a seemingly arbitrary rule. I see 4 effects that my suggestions might have: 1. Dismiss completely. Unlikely. On the worst case, it is at least being discussed. 2. No new wording, but change the code examples. Better consistency would be appropriate for some of the examples. However, there are many values there that are better unquoted (especially numbers). 3. Add some words about best practice, but do not enforce quotes as a conformance criterion. 4. Go all the way and do just that. Again, there is a middle point between these: making validators issue warnings for potentially unsafe attributes is, IMO, the sanest approach here. Adding some comments about the fact that in case of doubt
Re: [whatwg] Make quoted attributes a conformance criteria
From: Eduard Pascual herenva...@gmail.com Sent: Saturday, July 25, 2009 5:08 AM To: Keryx Web webmas...@keryx.se; Bil Corry b...@corry.biz Cc: whatwg@lists.whatwg.org; Aryeh Gregor simetrical+...@gmail.com Subject: Re: [whatwg] Make quoted attributes a conformance criteria On Fri, Jul 24, 2009 at 9:52 PM, Keryx Webwebmas...@keryx.se wrote: Finally, there are some values that are better unquoted, such as those attributes that can only take a number (there is no risk of errors, and the quotes would normally hurt readability more than they help it). Values better unquoted are those that would make problems if they were quoted. I've never run into any value that couldn't be quoted; effectively, the cases you mention fall under don't need to be quoted. Your argument lies on the fact that quotes make things less readable. Any change from what you're used to will appear less readable, but I'm not convinced that quotes inherently make code less readable. (Though I'll grant that Boolean attributes don't need quotes, unless they're XHTML.) 3. Add some words about best practice, but do not enforce quotes as a conformance criterion. 4. Go all the way and do just that. Again, there is a middle point between these: making validators issue warnings for potentially unsafe attributes is, IMO, the sanest approach here. I see a disconnect here between the validator and the spec. The validator would base everything on the spec, and so the spec itself should recommend quotes for potentially unsafe attributes at the very least, and back up that view in all the code examples. This is HTML, not XHTML, so it's useless to even ask that we conform to a policy of All quotes all the time. At the same time, the spec really does need to be clear that quotes are the best policy, and to be very explicit about where the absence of quotes are very dangerous. Stopping before (4) above will force people like me to keep requiring false XHTML from my students. That's an all-or-nothing approach. There's no reason you can't teach students to quote everything except boolean attributes, with the added explanation that XHTML does require the boolean attributes to be lengthened and quoted.
Re: [whatwg] Make quoted attributes a conformance criteria
On 2009-07-23 20:32, Eduard Pascual wrote: While I don't consider a hard requirement would be appropriate, there is an audience sector this discussion seems to be ignoring: Authoring Tools' developers. IMO, it would be highly desirable to have some guidelines for these tools to determine when they*should* quote attribute values. There is one further rub. Code that initially has been made by authoring tools have a tendency to wind up in some front end developers lap, to be amended and/or fixed manually at a later stage. That is even more a reason for a strong recommendation about quotes. Furthermore, I doubt that most people on this list did read my blog post I included as an URL when starting this discussion.[1] In that post I talked about a common scenario. One developer works on the business logic. It puts out attribute values. Another developer works on the presentation logic. He makes templates. Dev 2 omits the quotes and for a long time it might work, since the business logic in question only produces single word values. Then there might come a change, because dev 1 - or the users of the CMS - suddenly starts to produce longer values. Suddenly things break, and since nobody touched the presentation logic code, it might not be the first place where the developers look for an error. And believe me, lots of back end devs are absolutely clueless about front end issues! Yes, they might skip validation completely, but at least such a rule of thumb can be implemented more easily into their work flow. I also note that no one who has spoken against my suggestion claims to have any teaching experience. I see 4 effects that my suggestions might have: 1. Dismiss completely. 2. No new wording, but change the code examples. 3. Add some words about best practice, but do not enforce quotes as a conformance criterion. 4. Go all the way and do just that. The scientific evidence in favor of my suggestion might be quite easy to pick up. Just ask any standards aware teacher how common it is that not using quotes messes up students code! Stopping before (4) above will force people like me to keep requiring false XHTML from my students. My main concern is that in HTML 5 we get lots of new boolean attributes, like required on inputs or maxlength on textareas, and having to write things like 'required=required' will make the code longer and messier, since a normal input element might span 2 or 3 lines. Of course this can be settled if we get a tool like JSLint, that can enforce a voluntary stricter check (Crockford's good parts), but please note that ES 5 introduces a concept of strict rules. This means that ES 5 will be in a similar position to HTML 5, having a lax rule set about what browsers must be able to do, and a strict conformance critera like rule set that authors are encouraged to follow. Perhaps this could be solved by simply adding an option to the validator: Do not allow unquoted non-boolean attribute values. Henri Sivonen, are you reading this? -- Keryx Web (Lars Gunther) http://keryx.se/ http://twitter.com/itpastorn/ http://itpastorn.blogspot.com/ 1. http://itpastorn.blogspot.com/2009/07/value-of-false-xhtml.html
Re: [whatwg] Make quoted attributes a conformance criteria
Keryx Web wrote on 7/24/2009 2:52 PM: In that post I talked about a common scenario. One developer works on the business logic. It puts out attribute values. Another developer works on the presentation logic. He makes templates. Dev 2 omits the quotes and for a long time it might work, since the business logic in question only produces single word values. Then there might come a change, because dev 1 - or the users of the CMS - suddenly starts to produce longer values. Suddenly things break, and since nobody touched the presentation logic code, it might not be the first place where the developers look for an error. That's a classic XSS vulnerability. The backend developer must know if there are quotes or not in the template, then encode/sanitize the value accordingly. - Bil
Re: [whatwg] Make quoted attributes a conformance criteria
On Fri, Jul 24, 2009 at 6:26 PM, Bil Corryb...@corry.biz wrote: That's a classic XSS vulnerability. The backend developer must know if there are quotes or not in the template, then encode/sanitize the value accordingly. It's not XSS if the values are statically provided by the first developer and aren't generated from user input.
Re: [whatwg] Make quoted attributes a conformance criteria
Aryeh Gregor wrote on 7/24/2009 5:44 PM: On Fri, Jul 24, 2009 at 6:26 PM, Bil Corryb...@corry.biz wrote: That's a classic XSS vulnerability. The backend developer must know if there are quotes or not in the template, then encode/sanitize the value accordingly. It's not XSS if the values are statically provided by the first developer and aren't generated from user input. Sure, but I was basing my reply on the provided example: Then there might come a change, because dev 1 - or the users of the CMS - suddenly starts to produce longer values. Even in the case where the developer is providing the values via a trusted source (say a database), it's still a best practice to encode/sanitize the value. - Bil
[whatwg] Make quoted attributes a conformance criteria
Hello! 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. 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 have in fact written elsewhere that this is actually one of my reasons to use false XHTML: http://itpastorn.blogspot.com/2009/07/value-of-false-xhtml.html) With this in mind I suggest that the spec would be improved in the (below) following ways, and that we open a discussion about requiring quotation marks for all non-boolean attributes as a conformance criterion. Suggested spec edits (some written in a diff-ish way, not all a true diff, though): Section 1.9 Keep: Attributes are placed inside the start tag, and consist of a name and a value, separated by an = character. The attribute value can be left unquoted if it doesn't contain any special characters. Otherwise, it has to be quoted using either single or double quotes. The value, along with the = character, can be omitted altogether if the value is the empty string. Add: In order to avoid errors and increase readability, using quotes is highly recommended for all non-omitted attribute values. 4.6.8 Second example, where the a-element has been added. -pThe dfn id=gdo +pThe dfn id=gdo 4.6.9 Twice: -id=whatwg +id=whatwg 4.6.12 - dtRadius: dd meter min=0 max=20 value=1212cm/meter - dtHeight: dd meter min=0 max=10 value=22cm/meter + dtRadius: dd meter min=0 max=20 value=1212cm/meter + dtHeight: dd meter min=0 max=10 value=22cm/meter - dtRadius: dd meter min=0 max=20 value=12 title=centimeters12cm/meter - dtHeight: dd meter min=0 max=10 value=2 title=centimeters2cm/meter + dtRadius: dd meter min=0 max=20 value=12 title=centimeters12cm/meter + dtHeight: dd meter min=0 max=10 value=2 title=centimeters2cm/meter 4.8.2.1.7 (Very inconsistent example!) -pRating: meter max=5 value=3img src=1 alt=3 out of 5 +pRating: meter max=5 value=3img src=1 alt=3 out of 5 4.8.2.1.9 -input type=text name=captcha/label +input type=text name=captcha/label 4.8.14.1 - area shape=rect coords=50,50,100,100 !-- the hole in the red box -- - area shape=rect coords=25,25,125,125 href=red.html alt=Red box. - area shape=circle coords=200,75,50 href=green.html alt=Green circle. - area shape=poly coords=325,25,262,125,388,125 href=blue.html alt=Blue triangle. - area shape=poly coords=450,25,435,60,400,75,435,90,450,125,465,90,500,75,465,60 -href=yellow.html alt=Yellow star. + area shape=rect coords=50,50,100,100 !-- the hole in the red box -- + area shape=rect coords=25,25,125,125 href=red.html alt=Red box. + area shape=circle coords=200,75,50 href=green.html alt=Green circle. + area shape=poly coords=325,25,262,125,388,125 href=blue.html alt=Blue triangle. + area shape=poly coords=450,25,435,60,400,75,435,90,450,125,465,90,500,75,465,60 +href=yellow.html alt=Yellow star. 4.9.11 - tr td th scope=rowgroup English speakers td td + tr td th scope=rowgroup English speakers td td 4.10.3 - labelinput type=checkbox name=lost Lost/label + labelinput type=checkbox name=lost Lost/label -plabelFull name: input name=fn smallFormat: First Last/small/label/p -plabelAge: input name=age type=number min=0/label/p -plabelPost code: input name=pc smallFormat: AB12 3CD/small/label/p +plabelFull name: input name=fn smallFormat: First Last/small/label/p +plabelAge: input name=age type=number min=0/label/p +plabelPost code: input name=pc smallFormat: AB12 3CD/small/label/p 4.10.14.6 - plabelName: input required name=fn/label/p - plabelEssay: textarea name=essay/textarea/label/p - pinput type=submit name=submit value=Submit essay/p - pinput type=submit formnovalidate name=save value=Save essay/p - pinput type=submit formnovalidate name=cancel value=Cancel/p + plabelName: input required name=fn/label/p + plabelEssay: textarea name=essay/textarea/label/p + pinput type=submit name=submit value=Submit essay/p + pinput type=submit formnovalidate name=save value=Save essay/p + pinput type=submit formnovalidate name=cancel value=Cancel/p 5.4.2.1 -address item=vcard +address item=vcard 5.4.3.1 -pinput type=button value=Add to Calendar +pinput type=button value=Add to Calendar 6.12.3.1 -link rel=alternate type=application/pdf hreflang=fr href=manual-fr +link rel=alternate type=application/pdf hreflang=fr href=manual-fr 6.12.3.7 - plabel Topic: input name=topic a href=help/topic.html rel=help(Help)/a/label/p + plabel Topic: input name=topic a href=help/topic.html rel=help(Help)/a/label/p 6.12.3.8 - link rel=icon href=favicon.png sizes=16x16 - link rel=icon href=windows.ico sizes=32x32 48x48 - link rel=icon href=mac.icns
Re: [whatwg] Make quoted attributes a conformance criteria
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 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. 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. 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. -- regards, Kornel
Re: [whatwg] Make quoted attributes a conformance criteria
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. This always rather seemed like a preference to me, one that gets supported by consistency considerations (as some values would require quotation marks). Not considering the unquoted attribute value syntax a problem I’d second consistent use in the spec but would object any further changes. (I know first-hand that omitting optional tags alone gives people the creeps, but both optional tags and unquoted attribute values are valid options for writing HTML.) Couldn’t but add these two cents, Jens. -- Jens Meiert http://meiert.com/en/
Re: [whatwg] Make quoted attributes a conformance criteria
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. If author does not remember he can always use quotes and avoid this problem. I like the idea of having option to omit quotes valid for those who remember. 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. I think you overestimate the danger. So my vote is against such a requirement. Regards, Rimantas -- http://rimantas.com/
Re: [whatwg] Make quoted attributes a conformance criteria
On Thu, Jul 23, 2009 at 5:28 PM, Rimantas Liubertasriman...@gmail.com wrote: 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. If author does not remember he can always use quotes and avoid this problem. I like the idea of having option to omit quotes valid for those who remember. And this is why I was suggesting to mention on the spec that, since quotes are always allowed, the safest choice in case of doubt is to use them; rather than making it a hard requirement. For validators, I think the best approach would be to produce some warning (not an error) for missing quotes, probably omitting the safest cases (such as numeric attributes, @type in input (which is always a single word), and so on); so authors that go through the hassle of validating their pages to detect issues can be made aware of the unquoted attributes that may bring troubles in the future (ie: when updating such attributes). 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. I think you overestimate the danger. So my vote is against such a requirement. And I think you understimate it. I have seen newbies do really horrendous things. Murphy is omnipresent on the web. Anyway, I don't think voting on this list makes any sense. HTML5 is not a democratic process, but a totalitarian one with the core of the WHATWG at the top (see http://wiki.whatwg.org/wiki/FAQ#How_does_the_WHATWG_work.3F) and Ian as their hand. So it's not a matter of voting; but of convincing Ian to change the spec, or to convince the WHATWG members to replace him with someone who will change the spec (the later is quite unlikely to happen anyway).
Re: [whatwg] Make quoted attributes a conformance criteria
On Thu, Jul 23, 2009 at 8:35 AM, Keryx Webwebmas...@keryx.se wrote: Hello! 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. 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 . . . With this in mind I suggest that the spec would be improved in the (below) following ways, and that we open a discussion about requiring quotation marks for all non-boolean attributes as a conformance criterion. IMO, this is a stylistic preference. Personally I prefer unquoted values. They're almost always allowed, and the cases where they aren't are obvious to me ([ '], right?). They're fewer bytes, and I think that makes a significant readability difference for short attribute values: a href=/ title=Back class=xyz a href=/ title=Back class=xyz It makes the amount of markup noticeably less in some cases, letting you more easily focus on the actual contents of the page. I can see the opposite arguments as well. But I don't think the merits of either side are clear enough to warrant a conformance criterion. Add: In order to avoid errors and increase readability, using quotes is highly recommended for all non-omitted attribute values. I don't think there's any value in having the spec take a stance like this. It's a matter of taste, IMO.
Re: [whatwg] Make quoted attributes a conformance criteria
On Thu, Jul 23, 2009 at 7:35 PM, Aryeh Gregorsimetrical+...@gmail.com wrote: Add: In order to avoid errors and increase readability, using quotes is highly recommended for all non-omitted attribute values. I don't think there's any value in having the spec take a stance like this. It's a matter of taste, IMO. While I don't consider a hard requirement would be appropriate, there is an audience sector this discussion seems to be ignoring: Authoring Tools' developers. IMO, it would be highly desirable to have some guidelines for these tools to determine when they *should* quote attribute values. On the manual authoring side, I'd like to insist on the idea of highlighting the safety of always quoting attributes versus the risk of mistaking a required quotation as optional. Finally, I think we might come up with some wording that worked for both cases. Regards, Eduard Pascual
Re: [whatwg] Make quoted attributes a conformance criteria
On Thu, 23 Jul 2009 19:32:28 +0100, Eduard Pascual herenva...@gmail.com wrote: I don't think there's any value in having the spec take a stance like this. It's a matter of taste, IMO. While I don't consider a hard requirement would be appropriate, there is an audience sector this discussion seems to be ignoring: Authoring Tools' developers. IMO, it would be highly desirable to have some guidelines for these tools to determine when they *should* quote attribute values. I think this requirement is even less relevant for authoring tools: * It's not a problem for tools to use unquoted attributes in a perfectly safe manner. * Not all code generated by tools is intended to be edited by humans, and in such cases shorter code is likely to be preferred over human-readable code. * Tools that offer editing of HTML source code may (and often do) have syntax highlighting and validation. -- regards, Kornel Lesinski
