Re: [whatwg] A New Way Forward for HTML5
Manu Sporny wrote: Tab Atkins Jr. wrote: "Problem: A Kitchen Sink Specification" Ian recently implemented a way to hide or highlight the UA guidelines that confuse so many more casual readers. Does this help? (I know it helps me. ^_^) If I knew it existed it might have helped a bit. Even now that I know it exists, I can't figure out how to activate it. How do I hide the "UA Requirements" for: http://www.whatwg.org/specs/web-apps/current-work/#the-progress-element It's just an alternate stylesheet, so you can select the "Author documentation only" style from your browser's menu. There is also a set of controls at the top of the specification that does that using JavaScript, and it also sets a cookie so the choice is remembered. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] A New Way Forward for HTML5
On Fri, 24 Jul 2009, Benjamin M. Schwartz wrote: > Ian Hickson wrote: > > On Fri, 24 Jul 2009, Benjamin M. Schwartz wrote: > >> That sounds to me like a good reason to declare a freeze at last > >> call, and release an immutable "beta 1" on which comments can be > >> made. Then close the comment period on beta 1, and (potentially) > >> release a beta 2, etc. > > > > Unfortunately that would just mean that most people commenting on beta > > 1 would be reporting the same issues that have already been fixed. > > We've already seen this happen with the W3C version of the draft > > Then you're not putting up a big enough deprecation notice at the top! > Also, comments should be disabled once the comment period has closed. I think we're better off finding a mechanism (such as the one Joseph mentioned) that don't depend on the document staying static. That way we sidestep all the problems I describe above, and we don't ever waste people's times on issues that are already resolved. Basically I don't think it would ever really be beneficial to have people reviewing a version of the spec that isn't the most recent one, if we can help it. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] A New Way Forward for HTML5
John Drinkwater wrote: > Just one comment on the Action: More Committers + Distributed Source > Control section, as it’s something I generally agree with. Good to know :) > Of course, you could do this today without anyones input, produce a > dvcs repo from svn, edit sections as you see fit, take changes from > other editors trees and provide diffs. Sure, we could do this today, but Subversion doesn't make it easy to manage this type of stuff. A DVCS, like git, allows this type of collaboration by design and without much need to do merge planning. Subversion is good - git (or Mercurial/Bazar) is better. It would be nice if WHAT WG would just switch over to git - what are the chances of that happening? I'd be happy to set it up and manage it if the community wants that functionality (git.whatwg.org). > The general problem is that these extra editors need to exist already > and furthermore not cause overhead for that main committer when they > do. I'd certainly use such a system, as I would hope that others on here would, if they knew their changes would be integrated. Tools would certainly be integrated, as would most examples, and tests -- changes to the spec would need to either go through Ian or one of the W3C editors. -- manu -- Manu Sporny (skype: msporny, twitter: manusporny) President/CEO - Digital Bazaar, Inc. blog: Bitmunk 3.1 Released - Browser-based P2P Commerce http://blog.digitalbazaar.com/2009/06/29/browser-based-p2p-commerce/
Re: [whatwg] A New Way Forward for HTML5
Ian Hickson wrote: > On Fri, 24 Jul 2009, Benjamin M. Schwartz wrote: >> That sounds to me like a good reason to declare a freeze at last call, >> and release an immutable "beta 1" on which comments can be made. Then >> close the comment period on beta 1, and (potentially) release a beta 2, >> etc. > > Unfortunately that would just mean that most people commenting on beta 1 > would be reporting the same issues that have already been fixed. We've > already seen this happen with the W3C version of the draft Then you're not putting up a big enough deprecation notice at the top! Also, comments should be disabled once the comment period has closed. --Ben signature.asc Description: OpenPGP digital signature
Re: [whatwg] A New Way Forward for HTML5
Tab Atkins Jr. wrote: >> http://html5.digitalbazaar.com/a-new-way-forward/ > > A few comments as I see them (these all happen to be disagreements, > but that's because it's easiest to get up the urge to write about > things that I disagree with): If all that is written about is what you disagree with, what you support and agree with will never be known. :) > "Problem: Disregarding Input from the Accessibility Community" > ARIA is *going* to be in HTML5. Ian has made this clear. He's just > waiting for them to resolve some unanswered Last Call comments so the > spec can proceed to the next stability level. How can this possibly > be construed as ignoring them? See John Foliot's comment further down this thread. He expresses the frustration with WHAT WG (from the Accessibility community's viewpoint) better than I ever could. I do not mean to present the problem as one-sided or easily summarized -- just highlighting that what is being asserted in WHAT WG is not how those outside of WHAT WG see the situation. I've outlined what I think could be done to resolve the issue. If there is no issue and we implement what I've outlined, then the Accessibility community and I have wasted our time. If there is an issue, the actions that I've outlined resolve that issue, then we've made progress. > "Problem: Partial Distributed Extensibility" > We had partial distributed extensibility. We called it "The Browser > Wars". Look at the title - "Problem: Partial Distributed Extensibility" -- I'm not advocating partial distributed extensibility. > For a mass-consumption medium like html, we need a centralized > authority *so changes take time before they spread*. It produces a > barrier to entry that weeds out all but the most desired additions to > the language. It also slows the rate of innovation and needlessly restricts the language - but hey, we're both talking in broad generalizations, so this method of argumentation isn't really going to get us anywhere. :) > If they become relatively established despite the > language not allowing them, that's the best argument possible for > allowing them in the next version. It's also sends the message that people should break the standard if they really want a new feature. Again - broad generalizations leading to permathreads. :) Did you read this? It was linked to in the set of proposals I wrote: http://intertwingly.net/blog/2009/04/08/HTML-Reunification It discusses the separation of concepts between language extensibility (which isn't always desirable), and data extensibility (which is very desirable). > "Problem: Specification Ambiguity" > Dropping an email to the list is *not* a difficult thing. It's > trivial. It is incredibly intimidating for those that have never done it before. Even more intimidating is getting a response from somebody you think is smarter than you are listing all of the reasons you are wrong. Writing a comment on a blog or web page is far less intimidating - we should make it as easy as possible for people to give feedback. This is currently not the case. > And with a halfway decent modern mail client those "600 to > 1,200 very technical e-mails a month" drop to a relatively small > number of grouped conversations that can be tracked or ignored at > will. I think you mis-judge how scary receiving 600-1,200 emails from a single mailing list is for most regular web developers and designers (read: people who don't live and breathe this stuff, like we do). > That being said, inline spec comments sound interesting. Can you > expand on this? Sure... all of the details aren't worked out yet, but the goal is to make submitting feedback on the specification as easy as submitting a comment on a YouTube video. Hopefully, we'll have better luck with the quality of the comments, instead of "OMG! I love !!1!". How does this sound? * We might want to have a message when somebody views the spec (hover-right?) that says that they can leave a comment by right-clicking on a section of the document and requesting a change. * The HTML5 spec would contain the SCM revision number/hash in the document somewhere. The change box would find the closest id="#whatever" and note the revision and id as a unique identifier. The person would fill the bug/request information out and click Ok. * The request would be stored to a public database, perhaps with different methods of notifications when issues come in. If it is somewhat successful, we might want to tie it into a more permanent bug tracker. We could use the same system to help people submit examples of how each element could/should be used (like the PHP UserNotes): http://www.php.net/manual/en/function.curl-getinfo.php#usernotes > Are these meant to be private and only shown to Ian? They should be public so that everyone can see the feedback, and perhaps respond to it. > Shown to everything who views the spec (optionally, of course)? That could certainly be a feature that is supported in the fut
Re: [whatwg] A New Way Forward for HTML5
On Fri, 24 Jul 2009, Joseph Pecoraro wrote: > > > > I think we need an approach that doesn't involve in-flow links... I'm > > just not sure what the right solution is. Maybe alt-double-clicking > > should show a menu with two options, "submit comment here" or "change > > section status"? > > Alt-Double Click doesn't sound very discoverable. Even if I knew that > shortcut I'd probably forget at some point. Maybe having something > position:fixed would be better because there is something visible and > reachable at all times. The problem then would be automatically > determining which section is being commented on. Its certainly not as > straight-forward as clicking on the section. Just some ideas. I'm very > interested in seeing a commenting system. Hmm... Maybe a position:fixed text field somewhere on the page, with a submit button to send that feedback as mail... that could work. It could give the ID of the most recently clicked area of the page, or something. On Fri, 24 Jul 2009, Benjamin M. Schwartz wrote: > > > > That's an interesting approach, but I don't think it would work well > > with the HTML5 spec -- we probably need a mechanism that feeds into > > the current system (i.e. sends an e-mail) rather than annotating the > > document itself, and the document is in too much flux to track where > > the annotations go > > That sounds to me like a good reason to declare a freeze at last call, > and release an immutable "beta 1" on which comments can be made. Then > close the comment period on beta 1, and (potentially) release a beta 2, > etc. Unfortunately that would just mean that most people commenting on beta 1 would be reporting the same issues that have already been fixed. We've already seen this happen with the W3C version of the draft -- each time we release a /TR/ page snapshot, people report the same issues with that version for months, despite them having been fixed sometimes before the W3C version has even made it through the publication pipeline. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] A New Way Forward for HTML5
Ian Hickson wrote: > On Thu, 23 Jul 2009, Justin Lebar wrote: That being said, inline spec comments sound interesting. >>> I'm not quite sure what the UI would look like, but if anyone has any >>> ideas, feel free to e-mail me directly and we can figure something >>> out. (This would be exceedingly useful once we're in last call in a >>> few months.) >> Other people have probably pointed this out, but the hg book has inline >> comments. http://hgbook.red-bean.com/read/preface.html > > That's an interesting approach, but I don't think it would work well with > the HTML5 spec -- we probably need a mechanism that feeds into the current > system (i.e. sends an e-mail) rather than annotating the document itself, > and the document is in too much flux to track where the annotations go That sounds to me like a good reason to declare a freeze at last call, and release an immutable "beta 1" on which comments can be made. Then close the comment period on beta 1, and (potentially) release a beta 2, etc. --Ben signature.asc Description: OpenPGP digital signature
Re: [whatwg] A New Way Forward for HTML5
I think we need an approach that doesn't involve in-flow links... I'm just not sure what the right solution is. Maybe alt-double-clicking should show a menu with two options, "submit comment here" or "change section status"? Alt-Double Click doesn't sound very discoverable. Even if I knew that shortcut I'd probably forget at some point. Maybe having something position:fixed would be better because there is something visible and reachable at all times. The problem then would be automatically determining which section is being commented on. Its certainly not as straight-forward as clicking on the section. Just some ideas. I'm very interested in seeing a commenting system. - Joe
Re: [whatwg] A New Way Forward for HTML5
On Thu, 23 Jul 2009, Justin Lebar wrote: > >> > >> That being said, inline spec comments sound interesting. > > > I'm not quite sure what the UI would look like, but if anyone has any > > ideas, feel free to e-mail me directly and we can figure something > > out. (This would be exceedingly useful once we're in last call in a > > few months.) > > Other people have probably pointed this out, but the hg book has inline > comments. http://hgbook.red-bean.com/read/preface.html That's an interesting approach, but I don't think it would work well with the HTML5 spec -- we probably need a mechanism that feeds into the current system (i.e. sends an e-mail) rather than annotating the document itself, and the document is in too much flux to track where the annotations go -- even the current annotation system (the boxes on the left) have been problematic in this regard, and they're generally only anchored to sections, which are more stable than paragraphs. Also, I fear what it would do to the spec to add a link to every paragraph! :-) I think we need an approach that doesn't involve in-flow links... I'm just not sure what the right solution is. Maybe alt-double-clicking should show a menu with two options, "submit comment here" or "change section status"? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] .tags on HTMLCollections
Anne van Kesteren wrote: From what I heard so far it is there because of document.all. If document.all does indeed need to return a separate object as HTML5 suggests we can probably remove it from HTMLCollection in due course. Given that the namedItem behavior of document.all is different from the namedItem behavior of HTMLCollection, I don't see how document.all could possibly be a general HTMLCollection -Boris
Re: [whatwg] A New Way Forward for HTML5
Aryeh Gregor wrote on 7/23/2009 8:42 PM: On Thu, Jul 23, 2009 at 6:12 PM, Peter Kasting wrote: For my part, I would be very unhappy to see the HTML5 process made more consensus-driven; I much prefer systems that approximate benevolent dictatorships, and I don't perceive the current leadership of the group to be insufficiently responsive to communication. I'll second this. A well-run dictatorship is much superior to consensus-based decision-making, and I've found absolutely nothing to object to in Ian's leadership. Did you catch that article in A List Apart about Crowd-Sourcing? Only works with specific types of data, though, so you have to be careful. I think that's the greatest reason for this list. It isn't a democratic process, but the wide range of experience can show details that individuals wouldn't have the breadth to notice. Rather than splitting the spec into a handful of clones and then battling them against each-other, I imagine it would be better to make repositories for each piece of spec (each speck of spec?) where everyone can add their two cents. A small group can go through the pile, merge identical statements, and then piece the larger picture together for each spec-piece. Then we'll be left with a specification that encompasses an extremely wide range of views and needs, and Hixie can go through that to decide what HTML5 would keep and what it would throw away. In that light, I submit that we have less "in my opinion..." debate and do more collecting of personal experiences and needs (rather than a majority of preferences and opinions).
Re: [whatwg] A New Way Forward for HTML5
>> That being said, inline spec comments sound interesting. > I'm not quite sure what the > UI would look like, but if anyone has any ideas, feel free to e-mail me > directly and we can figure something out. (This would be exceedingly > useful once we're in last call in a few months.) Ian, Other people have probably pointed this out, but the hg book has inline comments. http://hgbook.red-bean.com/read/preface.html Regards, -Justin
Re: [whatwg] A New Way Forward for HTML5
On Thu, Jul 23, 2009 at 10:00 PM, Bil Corry wrote: > Turns out it's the mindless collectives that make the best rational decisions: > > Mindless Collectives Better at Rational Decision-Making Than Brainy > Individuals > > http://www.scientificamerican.com/article.cfm?id=mindless-collectives-rational-decision-making\ > > :) If you ignore the typically sensationalist science-journalism headline, you'll find the article talks about ant colonies. In that light, I have a hard time seeing the relevance to HTML 5.
Re: [whatwg] A New Way Forward for HTML5
Aryeh Gregor wrote on 7/23/2009 8:42 PM: > On Thu, Jul 23, 2009 at 6:12 PM, Peter Kasting wrote: >> For my part, I would be very unhappy to see the HTML5 process made more >> consensus-driven; I much prefer systems that approximate benevolent >> dictatorships, and I don't perceive the current leadership of the group to >> be insufficiently responsive to communication. > > I'll second this. A well-run dictatorship is much superior to > consensus-based decision-making, and I've found absolutely nothing to > object to in Ian's leadership. Turns out it's the mindless collectives that make the best rational decisions: Mindless Collectives Better at Rational Decision-Making Than Brainy Individuals http://www.scientificamerican.com/article.cfm?id=mindless-collectives-rational-decision-making :) - Bil
Re: [whatwg] A New Way Forward for HTML5
Manu Sporny wrote: form consensus: fail (but that's what the W3C is for, right?) From what I've read, there's only one issue of major importance where consensus has failed to form, namely the Great Codecs Debate. And as representatives have decried the other's positions as complete non-starters (Mozilla and Opera will not license the H.264 codec, and Apple will not accept the Theora codec) for reasons beyond the scope of the WG, there's really nothing that can be done about it. Ian is really the only one that is actively allowed to produce anything of significance in WHAT WG. In general, if he doesn't agree with you, it doesn't go in. If you can't convince him, how would you convince the browsers whose implementations are ultimately important? Browser vendors have in the past shown a willingness to not implement part of the spec if it is untenable. To understand why this is viewed as an issue, we can look to the Microformats community, which has roughly 1,300 mailing list members. Everyone is able to contribute to the main product of that community: The Microformats wiki. Why isn't it the same in this community -- a community that prides itself on being open to everyone? Microformats (AIUI) is easy to implement on top of browser APIs, whereas much of HTML 5 has to be implemented by the browsers themselves. Since the cost of a feature in HTML 5 is much greater than the cost of a new feature in Microformats, why should we expect the two to accept as easily new features? To approach the issue from another angle, we have roughly 1,000 members on this mailing list and could have close to 1 billion people[1] that could be using some form of HTML by 2012, a number of those are web developers (read: a huge developer base). I think it is fairer to compare the number of people who actually come into contact with HTML: those who write it (or those who write tools to write it) and those who write tools to display it. It is probably a stretch to say that even 1 million of those people will use HTML to a sufficient degree to be impacted by the specification. Most of those 1 billion people would be at an utter loss to even name the format which is carrying their data. I can git clone the Linux kernel, mess around with it and submit a patch to any number of kernel maintainers. If that patch is rejected, I can still share the changes with others in the community. Using the same tools as everybody else, I can refine the patch until there is a large enough group of people that agree, and implementation feedback to back up the patch, where I may have another chance of resubmitting the patch for re-review. This mechanism is a fundamental part of the community. There is /the/ implementation to the Linux kernel, but there is no implementation of HTML that can be called /the/ implementation. HTML and Linux are incomparable; you'd be much better off comparing HTML and POSIX: they are both descriptions of requirements for implementations. -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
Re: [whatwg] A New Way Forward for HTML5
On Thu, Jul 23, 2009 at 6:12 PM, Peter Kasting wrote: > For my part, I would be very unhappy to see the HTML5 process made more > consensus-driven; I much prefer systems that approximate benevolent > dictatorships, and I don't perceive the current leadership of the group to > be insufficiently responsive to communication. I'll second this. A well-run dictatorship is much superior to consensus-based decision-making, and I've found absolutely nothing to object to in Ian's leadership.
Re: [whatwg] A New Way Forward for HTML5
On Thu, 23 Jul 2009, Tab Atkins Jr. wrote: > > That being said, inline spec comments sound interesting. Can you expand > on this? Are these meant to be private and only shown to Ian? Shown to > everything who views the spec (optionally, of course)? Sent to the > mailing list? If anybody would like to follow-up on this particular idea, I'm very interested in setting something up that makes it even easier to submit comments without having to worry about subscribing to the lists or registering with the W3C's Bugzilla instance. I'm not quite sure what the UI would look like, but if anyone has any ideas, feel free to e-mail me directly and we can figure something out. (This would be exceedingly useful once we're in last call in a few months.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] A New Way Forward for HTML5
On Thu, Jul 23, 2009 at 2:48 PM, Manu Sporny wrote: > > I can git clone the Linux kernel, mess around with it and submit a patch > to any number of kernel maintainers. If that patch is rejected, I can > still share the changes with others in the community. Using the same > tools as everybody else, I can refine the patch until there is a large > enough group of people that agree, and implementation feedback to back > up the patch, where I may have another chance of resubmitting the patch > for re-review. This mechanism is a fundamental part of the community. I think you have incorrectly characterized the kernel maintenance process. For one thing, Linus Torvalds is the gatekeeper. For another thing, there is no sense that some sort of consensus will get a patch accepted if LT finds it deficient. You may maintain a fork if you want, or apply patches if you want, but this doesn't translate into ratification of the fork or patches as an accepted part of "standard" Linux; many people and organizations use ReiserFS, which is not accepted but which many people think should be accepted, and many observers (excluding myself) feel that the chief barrier to ReiserFS acceptance was political. I think these inaccuracies, and characterization of the Linux kernel process as wide open, greatly degrade your argument.
Re: [whatwg] In AppCache web apps, images from unpredictable domains won't load
That sounds perfect, thanks. On Mon, Jul 20, 2009 at 3:20 PM, Ian Hickson wrote: > > I've made it so that you can specify "*" in the online whitelist section > to basically open it up to anything. > > -- > Ian Hickson U+1047E)\._.,--,'``.fL > http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' >
Re: [whatwg] A New Way Forward for HTML5
On Thu, Jul 23, 2009 at 2:48 PM, Manu Sporny wrote: > contribute ideas: great! > scrutinize them: wonderful! > form consensus: fail (but that's what the W3C is for, right?) > produce: fail (unless we don't want to scale the community) > > Ian is really the only one that is actively allowed to produce anything > of significance in WHAT WG. In general, if he doesn't agree with you, it > doesn't go in. It's already been stated explicitly multiple times in the past that the HTML5 process is not ultimately consensus-driven, so this shouldn't be news to anyone. I for one consider that a feature, not a bug. I think it's fair to say that one needs to have a pretty > significant chunk of time on their hands as well as technical chops to > make a contribution to the HTML5 specification. Incorrect. All sorts of people have made contributions of small corrections, opinions on issues, spec proposals, etc. Ian has publicly committed to reply to every email and so far I see him doing precisely that; frequently this results in spec changes. When people's opinions are ultimately rejected, it is not without due consideration first. To approach the issue from another angle, we have roughly 1,000 members > on this mailing list and could have close to 1 billion people[1] that > could be using some form of HTML by 2012, a number of those are web > developers (read: a huge developer base). > > The Linux kernel mailing lists have close to 30,000 members[2], and I > don't think it's a stretch to say that there are fewer kernel developers > in the world (read: small developer base) than there are web developers > and designers. So, I've been wondering about the 30:1 discrepancy. You're comparing non-analogous situations. LKML is inherently of interest to all kernel developers, pretty much by definition. The HTML spec creation process is not inherently interesting to all web developers. A closer analogy would be to the engineers working on HTML support in UAs. I suspect that this mailing list _is_ inherently of interest to that group. We don't give anybody the impression here that they could directly impact the specification if they so > desired. If people sending emails containing proposals, and having the editor directly respond to all of those emails, frequently by changing the spec, does not give you the impression you can impact the specification, I'm not sure what would. I can git clone the Linux kernel, mess around with it and submit a patch > to any number of kernel maintainers. If that patch is rejected, I can > still share the changes with others in the community. Similarly, nothing prevents UA authors from coding any feature they wish and hoping it will gain traction. Similarly, nothing in the HTML5 process prevents anyone from proposing a feature that has been rejected by HTML5, and attempting to convince UA authors to support it directly. To the degree that these don't happen, it is because practical considerations make success unlikely: it is much more difficult for a random web developer to convince a vendor to support his idea in a particular UA than for a random coder to post a patch online alongside a modified kernel build. (However, it is not impossible: at least Firefox and Google Chrome can be built, as non-branded versions, from source by any interested party; and in fact that capability has been used for precisely the above purposes: see e.g. Iceweasel.) Similarly, people > that are creating user agents tend to not care about examples (in > general) Speaking as one of those people, you are completely mistaken. Examples are highly useful to UA authors. And implementation details are occasionally useful to web developers, insofar as they document expected behaviors very precisely and thus are useful when trying to test how real-world UA behaviors differ. I think the only valid point here is that web developers trying to read the spec directly probably want the "implementation details" as a reference rather than inline. They should be able to edit /something/ lasting, publish it for review, > and rise or fall on the merits and accuracy of their specification > language. They are not being given the opportunity to do so. Anyone can post a proposal anywhere on the web, which they themselves edit. If they want the imprimatur of the WHATWG, then it seems reasonably to expect that that proposal would have to be accepted by the editor(s) of that group. I'm not sure why there is a perceived lack of clarity here. Rejected proposals are always given concrete rationale for rejection (IMO). it > was meant as a feeler document to see how this community would react to > the proposed changes. For my part, I would be very unhappy to see the HTML5 process made more consensus-driven; I much prefer systems that approximate benevolent dictatorships, and I don't perceive the current leadership of the group to be insufficiently responsive to communication. PK
[whatwg] More input element feedback
The description for what to do on setting valueAsNumber doesn't fully cover
error conditions. It's not clear to me, for instance, what's supposed if you
have an input type="date" or type="number" and try to set valueAsNumber to NaN.
The description there (for date) just says "... passing it a Date object whose
time value is the new value ..." but doesn't say what to do if the Date object
can't be created.
Also, editorial fix: in the same two paragraphs ("On getting" and "On setting"
for valueAsNumber), the link to valueAsDate is wrong; it just links back to
#dom-input-valueAsNumber instead of #dom-input-valueAsDate.
Cheers,
kats
Re: [whatwg] A New Way Forward for HTML5
L. David Baron wrote: > The above document says: > > # The single greatest complaint heard from the standards community > # concerning the development of HTML5 is that it has not allowed > # for the scientific process. > > I strongly disagree with this statement. A key part of a scientific > process is that the starting point is evidence. I think the > development process of HTML5 gives arguments based on evidence more > weight than any other W3C work I've been involved in, and has put > more effort into gathering relevant evidence than any other W3C work > I've been involved in. This is a good thing. Hrm, that paragraph is problematic, others have had the same reading as you have on it as well, which is not the message that I had intended. Granted, it's meant to be an introductory paragraph which I spend the rest of the document elaborating on, but perhaps it needs to be revised. It's not the 'gathering of evidence' that I find problematic - quite the contrary, I think that's a great way to deal with some these issues and it certainly has helped solve some rather hairy disagreements in this community. It's the unevenness in the ability to directly contribute to the specification that is the "walled garden" that I take issue with: """ Throughout history, the ability to openly contribute ideas, scrutinize them, and form consensus around those ideas has been shown to produce the most desirable outcomes. HTML5 is currently a walled garden that must be opened to the greater standards community in order to ensure a stable framework for the future of the Web. """ So, addressing those point-by-point related to how the WHAT WG operates: contribute ideas: great! scrutinize them: wonderful! form consensus: fail (but that's what the W3C is for, right?) produce: fail (unless we don't want to scale the community) Ian is really the only one that is actively allowed to produce anything of significance in WHAT WG. In general, if he doesn't agree with you, it doesn't go in. To put an HTML5+RDFa proposal together, I had to go outside of this community. I think it's fair to say that one needs to have a pretty significant chunk of time on their hands as well as technical chops to make a contribution to the HTML5 specification. To understand why this is viewed as an issue, we can look to the Microformats community, which has roughly 1,300 mailing list members. Everyone is able to contribute to the main product of that community: The Microformats wiki. Why isn't it the same in this community -- a community that prides itself on being open to everyone? To approach the issue from another angle, we have roughly 1,000 members on this mailing list and could have close to 1 billion people[1] that could be using some form of HTML by 2012, a number of those are web developers (read: a huge developer base). The Linux kernel mailing lists have close to 30,000 members[2], and I don't think it's a stretch to say that there are fewer kernel developers in the world (read: small developer base) than there are web developers and designers. So, I've been wondering about the 30:1 discrepancy. Sure, the WHAT WG has been more successful in getting members than HTML WG... but what's keeping more people from joining? I'm asserting that it has something to do with developers not feeling like they can make a difference. We don't give anybody the impression here that they could directly impact the specification if they so desired. Our "scientific process" isn't open for all to participate at every level of the community. I can git clone the Linux kernel, mess around with it and submit a patch to any number of kernel maintainers. If that patch is rejected, I can still share the changes with others in the community. Using the same tools as everybody else, I can refine the patch until there is a large enough group of people that agree, and implementation feedback to back up the patch, where I may have another chance of resubmitting the patch for re-review. This mechanism is a fundamental part of the community. I'm going to state that again, because that is the point I'm making here: The ability to directly affect change at all levels of this community by anybody that chooses to do so should be behavior that we should be supporting, not stifling. The process that we have favors a select few and forces the rest into being casual observers. > Regarding the section "Action: Splitting HTML5 into Logically > Targeted Documents", I agree that there is value in splitting the > specification. However, I see significant danger in the way you > propose to split it: separating the specification of what is > available to authors and what should be implemented means the > specification risks promising to authors what cannot be implemented, > or cannot be implemented at a cost proportionate to the benefit (as > HTML4 did in a number of places). I may have not done a good job of expressing the purpose of microsections. The purpose of microse
Re: [whatwg] Make quoted attributes a conformance criteria
On Thu, 23 Jul 2009 19:32:28 +0100, Eduard Pascual 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
Re: [whatwg] Make quoted attributes a conformance criteria
On Thu, Jul 23, 2009 at 7:35 PM, Aryeh Gregor 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, Jul 23, 2009 at 8:35 AM, Keryx Web 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: 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.
[whatwg] 4.10.4.3 - stepUp and stepDown
The algorithm for stepUp() and stepDown() doesn't seem to take into account the "n" parameter to those methods. The delta value used is the allowed step value; shouldn't delta actually be the allowed step value multiplied by n? Or am I missing something here? Cheers, kats
[whatwg] "Content model" vs. "Contexts in which this element may be used"
These sections have very different wordings given the fact that they directly correspond to each other. Maybe change "Contexts in which this element may be used" to "Content models in which this element may be used". -- "Whatever you do will be insignificant, but it is very important that you do it." - Mahatma Gandhi http://www.ChaosReigns.com Guns save lives.
Re: [whatwg] A New Way Forward for HTML5
Manu Sporny wrote: By halting the XHTML2 work and announcing more resources for the HTML5 project, the World Wide Web Consortium has sent a clear signal on the future markup language for the Web: it will be HTML5. Unfortunately, the decision comes at a time when many working with Web standards have taken issue with the way the HTML5 specification is being developed. The shut down of the XHTML2 Working Group has brought to a head a long-standing set of concerns related to how the new specification is being developed. The following page outlines the current state of development and suggests that there is a more harmonious way to move forward. By adopting some or all of the proposals outlined below, the standards community will ensure that the greatest features for the Web are integrated into HTML5. http://html5.digitalbazaar.com/a-new-way-forward/ -- manu Just one comment on the Action: More Committers + Distributed Source Control section, as it’s something I generally agree with. Of course, you could do this today without anyones input, produce a dvcs repo from svn, edit sections as you see fit, take changes from other editors trees and provide diffs. The general problem is that these extra editors need to exist already and furthermore not cause overhead for that main committer when they do. -- John ‘[Beta]’ Drinkwater| j...@nextraweb.com
Re: [whatwg] Make quoted attributes a conformance criteria
On Thu, Jul 23, 2009 at 5:28 PM, Rimantas Liubertas 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 (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
> 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] A New Way Forward for HTML5
On Thu, Jul 23, 2009 at 8:48 AM, Manu Sporny wrote: > By halting the XHTML2 work and announcing more resources for the HTML5 > project, the World Wide Web Consortium has sent a clear signal on the > future markup language for the Web: it will be HTML5. Unfortunately, the > decision comes at a time when many working with Web standards have taken > issue with the way the HTML5 specification is being developed. > > The shut down of the XHTML2 Working Group has brought to a head a > long-standing set of concerns related to how the new specification is > being developed. The following page outlines the current state of > development and suggests that there is a more harmonious way to move > forward. By adopting some or all of the proposals outlined below, the > standards community will ensure that the greatest features for the Web > are integrated into HTML5. > > http://html5.digitalbazaar.com/a-new-way-forward/ A few comments as I see them (these all happen to be disagreements, but that's because it's easiest to get up the urge to write about things that I disagree with): "Problem: Disregarding Input from the Accessibility Community" ARIA is *going* to be in HTML5. Ian has made this clear. He's just waiting for them to resolve some unanswered Last Call comments so the spec can proceed to the next stability level. How can this possibly be construed as ignoring them? As for other accessibility experts, they *have* influenced the spec, but unfortunately there is a vocal minority who believe that markup languages and specs have the magical ability to make people care, and/or believe in the equivalent of XML draconian error-handling for unmet accessibility issues. HTML5 goes out of its way to make accessibility as *automatic* as possible, so that no one has to spend effort on enabling others (or more properly, so the majority of authors who will *never* spend significant effort on accessibility still produce accessible content). Witness the wars over the @alt attribute on images. "Problem: Partial Distributed Extensibility" We had partial distributed extensibility. We called it "The Browser Wars". For a mass-consumption medium like html, we need a centralized authority *so changes take time before they spread*. It produces a barrier to entry that weeds out all but the most desired additions to the language. If they become relatively established despite the language not allowing them, that's the best argument possible for allowing them in the next version. "Problem: Specification Ambiguity" Dropping an email to the list is *not* a difficult thing. It's trivial. And with a halfway decent modern mail client those "600 to 1,200 very technical e-mails a month" drop to a relatively small number of grouped conversations that can be tracked or ignored at will. That being said, inline spec comments sound interesting. Can you expand on this? Are these meant to be private and only shown to Ian? Shown to everything who views the spec (optionally, of course)? Sent to the mailing list? "Problem: A Kitchen Sink Specification" Ian recently implemented a way to hide or highlight the UA guidelines that confuse so many more casual readers. Does this help? (I know it helps me. ^_^) ~TJ
Re: [whatwg] A New Way Forward for HTML5
On Thursday 2009-07-23 09:48 -0400, Manu Sporny wrote: > http://html5.digitalbazaar.com/a-new-way-forward/ I have a few thoughts on this document. The above document says: # The single greatest complaint heard from the standards community # concerning the development of HTML5 is that it has not allowed # for the scientific process. I strongly disagree with this statement. A key part of a scientific process is that the starting point is evidence. I think the development process of HTML5 gives arguments based on evidence more weight than any other W3C work I've been involved in, and has put more effort into gathering relevant evidence than any other W3C work I've been involved in. This is a good thing. Regarding the section "Action: Splitting HTML5 into Logically Targeted Documents", I agree that there is value in splitting the specification. However, I see significant danger in the way you propose to split it: separating the specification of what is available to authors and what should be implemented means the specification risks promising to authors what cannot be implemented, or cannot be implemented at a cost proportionate to the benefit (as HTML4 did in a number of places). I'm a little bit puzzled by the inclusion of the section "Problem: Partial Distributed Extensibility": it seems to be a technical issue (although a far-reaching one) in a document otherwise about process issues. I'm not sure it belongs in this discussion. Finally, regarding the section "Problem: Disregarding Input from the Accessibility Community". I think some of the input that has been ignored or has been felt to be ignored is input that is difficult to act on. Specification development ought to work from requirements to solutions rather than straight to solutions. This is done to make sure that the requirements are addressed, to make sure that the specification does not become more complicated than needed to address the requirements, and (most importantly in this case) to avoid unresolvable debates between parties that are emotionally attached to particular technical solutions. I think a number of the arguments that have been ignored (e.g., some of the arguments over @headers or @summary) have been arguments made *in the face of* evidence that the particular technical solutions do not work in practice, and without presenting the requirements that are not addressed by the HTML5 specification's replacements for those particular (non-functioning) solutions. I think such arguments ought to be ignored, ignoring them is not a problem, and giving those who make them and then complain that they are ignored the power to edit the specification would be a mistake. However, I think HTML5 specification reflects significant consideration for the needs of disabled users, and I strongly encourage more input regarding use cases for and requirements of disabled users that the specification fails to meet. -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
Re: [whatwg] Make quoted attributes a conformance criteria
On Thu, Jul 23, 2009 at 3:32 PM, Kornel 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:
>
> 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:
.foo { /* some declarations here */ }
.bar { /* and more declarations */ }
...
It was safe to omit the quotes!
Now, someone who is maintaining that code may realize that the .bar
class also applies to that . The chance for that person to put
out something like this is too high:
It was safe to omit the quotes!
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
>
>
Re: [whatwg] .tags on HTMLCollections
On Tue, 14 Jul 2009 11:58:30 +0200, Maciej Stachowiak wrote: > I don't know of a reason it's needed for collections other than > document.all. But it also doesn't seem harmful and I can't say > definitively whether it helps anything. I wouldn't object to removing it > from the spec, but we probably wouldn't remove it from WebKit short of > evidence that it's actually harmful. > > Perhaps Opera people can shed more light on the matter. >From what I heard so far it is there because of document.all. If document.all >does indeed need to return a separate object as HTML5 suggests we can probably >remove it from HTMLCollection in due course. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Make quoted attributes a conformance criterion
On 2009-07-23 15:32, Kornel 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: Having dealt with other peoples code a lot (being a teacher) I'd say that problem is exceptionally rare and very easy to spot, put in contrast with the ones arising from not using quotation marks. The proportion is like 100 to 1. Ergo: In real life the benefit is very clear. 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. Just like validation in HTML 4 in reality is more of a benefit to the developer than the browser, since 99% of all errors actually are benign, so conformance criteria in HTML 5 is supposed to primarily help web developers - and authoring tool developers. 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. -- Keryx Web (Lars Gunther) http://keryx.se/ http://twitter.com/itpastorn/ http://itpastorn.blogspot.com/
[whatwg] A New Way Forward for HTML5
By halting the XHTML2 work and announcing more resources for the HTML5 project, the World Wide Web Consortium has sent a clear signal on the future markup language for the Web: it will be HTML5. Unfortunately, the decision comes at a time when many working with Web standards have taken issue with the way the HTML5 specification is being developed. The shut down of the XHTML2 Working Group has brought to a head a long-standing set of concerns related to how the new specification is being developed. The following page outlines the current state of development and suggests that there is a more harmonious way to move forward. By adopting some or all of the proposals outlined below, the standards community will ensure that the greatest features for the Web are integrated into HTML5. http://html5.digitalbazaar.com/a-new-way-forward/ -- manu -- Manu Sporny (skype: msporny, twitter: manusporny) President/CEO - Digital Bazaar, Inc. blog: Bitmunk 3.1 Released - Browser-based P2P Commerce http://blog.digitalbazaar.com/2009/06/29/browser-based-p2p-commerce/
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
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: 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
[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. -The +The 4.6.9 Twice: -id=whatwg +id="whatwg" 4.6.12 - Radius: 12cm - Height: 2cm + Radius: 12cm + Height: 2cm - Radius: title="centimeters">12cm - Height: title="centimeters">2cm + Radius: title="centimeters">12cm + Height: title="centimeters">2cm 4.8.2.1.7 (Very inconsistent example!) -Rating: Rating: + 4.8.14.1 - - - - alt="Blue triangle."> - coords="450,25,435,60,400,75,435,90,450,125,465,90,500,75,465,60" -href="yellow.html" alt="Yellow star."> + + + + alt="Blue triangle."> + 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 - English speakers + English speakers 4.10.3 - Lost + Lost -Full name: Format: First Last -Age: -Post code: Format: AB12 3CD +Full name: Format: First Last +Age: +Post code: Format: AB12 3CD 4.10.14.6 - Name: - Essay: - - - + Name: + Essay: + + + 5.4.2.1 - + 5.4.3.1 - +href="manual-fr"> 6.12.3.7 - Topic: rel="help">(Help) + Topic: rel="help">(Help) 6.12.3.8 - - - - - - - - + + + + + + + + 7.6 - + 9.1.2.3 No suggested text, but a rewrite will be necessary if quotation marks becomes a conformance criterion. 9.2.8.4 - + -- Keryx Web (Lars Gunther) http://keryx.se/ http://twitter.com/itpastorn/ http://itpastorn.blogspot.com/
