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
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] due consideration
On Jul 23, 2009, at 7:51 PM, Larry Masinter wrote: “When people's opinions are ultimately rejected, it is not without due consideration first.” The word “consider” is used inconsistently, and the result is confusion. I am willing to believe the confusion isn’t deliberate. In some circumstances, you could say something has been “considered” if a person has given thought to the subject. So, I have considered what I am saying, here, but that consideration is my personal thought. T On the other hand, in standards activities and other group decision making processes, a topic is “considered” if it has actually been raised, discussed, the sense of the participants assessed, before a group assessment and response is made. In HTML, so far, most comments have only been “considered” in the former sense. I believe, however, that most people expect their contributions, feedback and comments on a standard specification to be “considered” in the latter sense, and what “due consideration” requires in an open standards process. Ian gives more careful consideration and more thorough responses to comments than any other specification editor I have seen in action. I've commented on many W3C standards and many times I've seen comments raising serious technical issues dismissed without explanation, or just ignored. I have never seen that with HTML5. Personally, I don't think a nominally dictatorial process is right in principle. No one person should be trusted with that much power. In practice, I've seen Ian change the spec many times to achieve what I think is often a good compromise among factions that disagree. Many times the outcome of this process is better than what we would have gotten if we'd immediately greased the squeakiest wheels. And the quality of the technical output seems quite a bit better than many more wholeheartedly committee-based approaches. So in actual practice, I think the process ends up quite a bit more consensus-driven than Ian would claim. As a result, even though I think the HTML Working Group has the authority to override the editor by group decision, I haven't yet felt the need to demand a vote, even on issues where I disagreed. And yes, there are still parts of the spec that I strongly disagree with, such as the use of legend for figure captions. People probably see me as a WHATWG insider or whatever, but the fact is, while we broadly agree on big-picture design goals, I often disagree with Ian's initial take on many technical problems. What I have found is that if I make reasoned technical arguments based on evidence and use cases, then either I'll convince him to make a change(*), or if not, he will make a plausible case for the other side to the point that I can let the issue go. I think this is something anything can do, if they make the effort. Regards, Maciej * - For example, I think it was my technical arguments that largely convinced Ian to make summary= conforming, when months of shrill accusations of bad faith, rejections of evidence and appeals to authority failed to do so.
Re: [whatwg] A New Way Forward for HTML5
Ian Hickson wrote: 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.) I remember having some discussion about such a thing in IRC a few months ago. Indeed, the biggest problem seems to be what sort of UI we could use for it. My proposal, on the whole, would be to have some box appearing upon selecting text. Then, in that box, give space for both an email address and a comment, and send that along with the selected text to the list. -- Geoffrey Sneddon — Opera Software ASA http://gsnedders.com/ http://www.opera.com/
[whatwg] inline spec feedback (was: Re: A New Way Forward for HTML5)
On Fri, 24 Jul 2009 06:44:55 +0200, Ian Hickson i...@hixie.ch wrote: On Fri, 24 Jul 2009, Joseph Pecoraro wrote: 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. elementFromPoint()? -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] .tags on HTMLCollections
On Fri, 24 Jul 2009 04:56:15 +0200, Boris Zbarsky bzbar...@mit.edu wrote: 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 They are indeed distinct, but do share the same interface name in Opera the moment, as far as I can tell... In any case, my point was that we'd be ok with removing the tags member from HTMLCollection in due course. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] due consideration
On Fri, Jul 24, 2009 at 10:04 AM, Maciej Stachowiakm...@apple.com wrote: Ian gives more careful consideration and more thorough responses to comments than any other specification editor I have seen in action. I've commented on many W3C standards and many times I've seen comments raising serious technical issues dismissed without explanation, or just ignored. I have never seen that with HTML5. Is that really enough? example Let's take a long and well-known controversy as an example: Microdata. It is true that Ian has given the topic very careful consideration, and a lot of thought; but what is the result? There are already several existing solutions that HTML5 could have adopted, most prominently (and most argued for) RDFa, but also EASE, eRDF, and others. During the discussions, people who have been working on Web Semantics for *several years* contributed their knowledge, expertise on the topic, and ideas. By the end, Ian opted to create an entire new solution, disregarding years of previous work on the subject and the significative base of already existing RDFa authoring and consuming software. But that solution has an complexity that is roughly equivalent to that of RDFa, has no implementation nor existing content support so far, and can't even handle all the use cases that RDFa could handle. The only significative advantage of that proposal was that it used reversed domain names to identify vocabularies instead of namespace prefixes; however, there has been a lot of controversy about reversed domains actually being better than namespace prefixes. Even if we asume that reversed domains are slightly better (it's not likely that they are much better if there is so much division about the topic), is that worth the costs of: 1) Limiting the range of use cases that can be handled; 2) Requiring new tools to be developed from scratch; and 3) Requiring content to adapt to this new format? These are huge costs. Especially, when we put 2) and 3) together, content authors will be forced to keep supporting RDFa tools (as long as a significant part of the audience is still using RDFa-related tools), so they will need to duplicate metadata to support Microdata as well. Wasn't duplication one of the issues inline metadata was intended to prevent? /example aside Please, note that my intention is not to bring back this discussion. It is just an example of controversy that will be known by most participants on this list. Actually, I have no intention to step into that debate again for a while. /aside The point I do not doubt of Ian's good faith, nor of his huge effort in making HTML5 the best possible thing it might be. However, I doubt of the sanity of having an individual to have the final say about any topic, even above expert groups that have been researched and discussed the topic for years. Just because the fruit of so long work can't be properly sintetized in plain-text e-mails doesn't mean that there is not enough value on it. Going back to the example, there was a lot of people involved in RDF and RDFa since 1997. That's already twelve years of continuous work and research by several people. HTML5 replaces all this effort (RDF and RDFa) with that of a single person over few months (Microdata). Honestly, I can't say for sure which method would be best for HTML; but I'm still convinced that having a single gatekeeper with absolute power over the next web standard is, at least, insane. /The point Regards, Eduard Pascual
[whatwg] Microdata and Linked Data
Hi All, I've been taking a closer look at microdata. While I like the proposal in general, in particular the chance to unite microformat style annotations with some of the Semantic Web formalism (such as URIs for objects), there are still a number of points that I feel could be improved. So here are my proposals for discussion: #1 The use of a URI as the value of the id attribute. It seems to me there is actually nothing in the spec that would stop this: Identifiers are opaque strings. Particular meanings should not be derived from the value of the id attribute. This is great because in principle I could do something like: section id=http://john.example.com#hedral; item=org.example.animal.cat com.example.feline h1 itemprop=org.example.name com.example.fnHedral/h1 /section I assume you can achieve something similar with the about property but that would require me to write: section item=org.example.animal.cat com.example.feline h1 itemprop=org.example.name com.example.fnHedral/h1 a itemprop=about href=http://john.example.com#hedral/ /section This is longer by itself, and if I want an internal identifier as well, than I have to write: section id=hedral item=org.example.animal.cat com.example.feline h1 itemprop=org.example.name com.example.fnHedral/h1 a itemprop=about href=http://john.example.com#hedral/ /section #2 The other area that could be possibly improved is the connection of type identifiers with ontologies on the web. I would actually like the notion of reverse domain names if -- there would be an explicit agreement that they are of the form xxx.yyy.zzz.classname -- there would be a registry for mappings from xxx.yyy.zzz to URIs. For example, org.foaf-project.Person could be linked to http://xmlns.com/foaf/0.1/Person by having the mapping from org.foaf-project to http://xmlns.com/foaf/0.1/. It wouldn't be perfect, the FOAF ontology as you see is not at org.foaf-project but at com.xmlns. However, it would be a step in the right direction. #3 I would consider adding the sameAs property as part of the standard vocabulary. This is a term from the OWL vocabulary that is widely used in the Linked Data world for connecting entities that are deemed to be equivalent. Alternatively, we could add the entire RDFS and OWL vocabulary to the spec. #4 I don't expect that writing full URIs for property names will be appealing to users, but of course I'm not a big fan either of defining prefixes individually as done in RDFa with the CURIE mechanism. Still, prefixes would be useful, e.g. foaf:Person is much shorter to write than com.foaf-project.Person and also easier to remember. So would there be a way to reintroduce the notion of prefixes, with possibly pointing to a registry that defines the mapping from prefixes to namespaces? section id=hedral namespaces=http://www.w3c.org/registry/; item=animal:cat h1 itemprop=animal:nameHedral/h1 /section Here the registry would define a number of prefixes. However, the mechanism would be open in that other organizations or even individuals could maintain registries. Looking forward to your feedback, Peter
Re: [whatwg] due consideration
The point I do not doubt of Ian's good faith, nor of his huge effort in making HTML5 the best possible thing it might be. However, I doubt of the sanity of having an individual to have the final say about any topic, I don't doubt the sanity of it at all. even above expert groups that have been researched and discussed the topic for years. That's that happen when no one has a final say: years of discussions. Quite often—about the color of the bike shed. Just because the fruit of so long work can't be properly sintetized in plain-text e-mails doesn't mean that there is not enough value on it. Going back to the example, there was a lot of people involved in RDF and RDFa since 1997. That's already twelve years of continuous work and research by several people. HTML5 replaces all this effort (RDF and RDFa) with that of a single person over few months (Microdata). I doubt that discussions started in 1997 with HTML5 in mind. So I guess those interested can keep going for 12 more years if so inclined. Honestly, I can't say for sure which method would be best for HTML; but I'm still convinced that having a single gatekeeper with absolute power over the next web standard is, at least, insane. I'd say that's the one the best ways to get something practical done. To quote Frederick P. Brooks Jr.: Conceptual integrity in turn dictates that the design must proceed from one mind, or from a very small number of agreeing resonant minds — The Mythical Man Month, Chapter 4 Aristocracy, Democracy and System Design Regards, Rimantas -- http://rimantas.com/
Re: [whatwg] Microdata and Linked Data
On Fri, Jul 24, 2009 at 1:07 PM, Peter Mikapm...@yahoo-inc.com wrote: [...] #2 The other area that could be possibly improved is the connection of type identifiers with ontologies on the web. I would actually like the notion of reverse domain names if -- there would be an explicit agreement that they are of the form xxx.yyy.zzz.classname -- there would be a registry for mappings from xxx.yyy.zzz to URIs. For example, org.foaf-project.Person could be linked to http://xmlns.com/foaf/0.1/Person by having the mapping from org.foaf-project to http://xmlns.com/foaf/0.1/. It wouldn't be perfect, the FOAF ontology as you see is not at org.foaf-project but at com.xmlns. However, it would be a step in the right direction. [...] #4 I don't expect that writing full URIs for property names will be appealing to users, but of course I'm not a big fan either of defining prefixes individually as done in RDFa with the CURIE mechanism. Still, prefixes would be useful, e.g. foaf:Person is much shorter to write than com.foaf-project.Person and also easier to remember. So would there be a way to reintroduce the notion of prefixes, with possibly pointing to a registry that defines the mapping from prefixes to namespaces? section id=hedral namespaces=http://www.w3c.org/registry/; item=animal:cat h1 itemprop=animal:nameHedral/h1 /section Here the registry would define a number of prefixes. However, the mechanism would be open in that other organizations or even individuals could maintain registries. IMO, both of these proposals are quite related. However, you added substantial differences I can't really understand between them. For #2 you suggest to have a sort of centralized registry of mappings between the reversed domains and the vocabularies they refer to. What happens if next year I have to use an unusual vocabulary for my site that is not included on the registry? Would I have to get the vocabulary included on the registry before my pages' microdata can be mapped to the appropriate RDF graph? On the other hand, on #4, you are opening the gate to independent entities (be them organizations or individuals) to define the prefixes they would be using for their pages' metadata: why don't apply this to #2 as well? IMO, it would be more important for #2 than for #4; since #4 only provides syntax sugar while #2 enables something that would be undoable without it (mapping Microdata to arbitrary RDF). About #1, I'm not sure about what you are exacly proposing, so I can't provide much feedback on it. Maybe you could make it a bit clearer: are you proposing any specific change to the spec? If so, what would be the change? If now, what are you proposing then? Finally, about #3 I'm not familiar with the OWL vocabulary, so I can't say too much about it. But if your second proposal gets into the spec, then this would become just syntax sugar, since any property from any existing RDF vocabulary could be expressed; and if #4 also got in, the benefit of built-in properties would be minimal compared to using a reasonably short prefix (such as owl:). Just my two cents. Regards, Eduard Pascual
Re: [whatwg] Microdata and Linked Data
Yes, #2 and #4 are quite related in that they both concern the abbreviation mechanism for URIs and might be considered alternative proposals. On the other hand, on #4, you are opening the gate to independent entities (be them organizations or individuals) to define the prefixes they would be using for their pages' metadata: why don't apply this to #2 as well? IMO, it would be more important for #2 than for #4; since #4 only provides syntax sugar while #2 enables something that would be undoable without it (mapping Microdata to arbitrary RDF). Yes, the idea of distributing the registration could be applied to #2. About #1, I'm not sure about what you are exacly proposing, so I can't provide much feedback on it. Maybe you could make it a bit clearer: are you proposing any specific change to the spec? If so, what would be the change? If now, what are you proposing then? Removing the about property, showing how id can be used in this way, and changing the description of how you transform an HTML5 document to RDF. Finally, about #3 I'm not familiar with the OWL vocabulary, so I can't say too much about it. But if your second proposal gets into the spec, then this would become just syntax sugar, since any property from any existing RDF vocabulary could be expressed; and if #4 also got in, the benefit of built-in properties would be minimal compared to using a reasonably short prefix (such as owl:). I agree... I'm personally not so attached to reverse domain names, but I might have missed a lot of the previous discussions on why they are good to have. In any case, my intention was to get the discussion restarted around these issues: it seems to me there was a lot of discussion at the very beginning on microdata vs. RDFa when microdata was first proposed, but then the discussion died without necessarily finding the best solution (for my taste). Cheers, Peter
[whatwg] Type of PropertyNodeList.contents
PropertyNodeList.contents seems to be defined differently in the IDL and
the text related to it.
The IDL says:
typedef sequenceany PropertyValueArray;
interface PropertyNodeList : NodeList {
attribute PropertyValueArray contents;
};
The description says:
The contents DOM attribute on the PropertyNodeList object, on
getting, must return a newly constructed DOMStringArray whose values
are the values obtained from the content DOM property of each of the
elements represented by the object, in tree order.
DOMStringArray doesn't appear to be defined anywhere, however DOM 3 Core
has a DOMStringList which seems to have this purpose.
HTMLPropertyCollection.names returns a DOMStringList, so I think we
should be consistent and also return a DOMStringList for
PropertyNodeList.contents.
--
Andrew Oakley
Re: [whatwg] Microdata and Linked Data
Fair point. Just brainstorming here: how about making about an attribute? div item id=amanda about=http://;/div pName: span subject=amanda itemprop=nameAmanda/span/p We still have two identifiers, but at least giving the URI is simplified. Best, Peter Julian Reschke wrote: Peter Mika wrote: Hi All, I've been taking a closer look at microdata. While I like the proposal in general, in particular the chance to unite microformat style annotations with some of the Semantic Web formalism (such as URIs for objects), there are still a number of points that I feel could be improved. So here are my proposals for discussion: #1 The use of a URI as the value of the id attribute. It seems to me there is actually nothing in the spec that would stop this: ... IDs like that would be very hard to use as fragment identifier... ... BR, Julian
Re: [whatwg] Selectable category tree, nested optgroups?
2009/7/9 Oldřich Vetešník vetes...@mrmil.cz: Hi, Imagine you have a (for example) category tree like this: * Cars * Sporty * Limo * 18 wheeler * Bloody good * Big * Places to live in * Villa * Flat * Under bridge ... and you are to select one for your article of some sort. optgroup isn't capable of doing this at the moment as it cannot be nested and you cannot select Cars category (it's its label attribute). Currently this is done by intending with spaces and, in my humble opinion, it doesn't look too accessible - I wouldn't want to crawl through it with my screenreader if it was a longer list. I'm here to ask if there is/could be a better way than intending. This has been suggested before, and even made it into the spec at one point, but got removed because there didn't seem to be a way to do this in a backwards-compatible manner. There was also the suggestion of a new element to use for this case, but that appeared late enough that it's being pushed to v2 for the moment - html5 already makes a *ton* of changes and additions to forms. ^_^ ~TJ
Re: [whatwg] .tags on HTMLCollections
Anne van Kesteren wrote: They are indeed distinct, but do share the same interface name in Opera the moment, as far as I can tell... Oh, the _name_ is shared in Gecko too. Just not anything else. ;) In any case, my point was that we'd be ok with removing the tags member from HTMLCollection in due course. Indeed, and thank you for the response! -Boris
[whatwg] Section 3.3.3.2 Attribute value normalization and title attributes
A technical point that may perhaps have already been considered. Section 3.3.3.2 states If the title attribute's value contains U+000A LINE FEED (LF) characters, the content is split into multiple lines. Each U+000A LINE FEED (LF) character represents a line break. However this is incompatible with XML and the XHTML serialization. In XML as specified in http://www.w3.org/TR/REC-xml/#AVNormalize Before the value of an attribute is passed to the application or checked for validity, the XML processor must normalize the attribute value by applying the algorithm below, or by using some other method such that the value passed to the application is the same as that produced by the algorithm. All line breaks must have been normalized on input to #xA as described in 2.11 End-of-Line Handling, so the rest of this algorithm operates on text normalized in this way. Begin with a normalized value consisting of the empty string. For each character, entity reference, or character reference in the unnormalized attribute value, beginning with the first and continuing to the last, do the following: For a character reference, append the referenced character to the normalized value. For an entity reference, recursively apply step 3 of this algorithm to the replacement text of the entity. For a white space character (#x20, #xD, #xA, #x9), append a space character (#x20) to the normalized value. For another character, append the character to the normalized value. Thus, absent some fancy tricks with character references, linefeeds are not allowed in attribute values. Raw linefeeds are converted to spaces. I'm not sure what should be done about this. This is one of the weirder and more error-prone parts of XML. However, since HTML 5 is suspicious of linefeeds in title attributes anyway, we could either forbid them or adopt the XML interpretation. I first noticed this in the description of the title attribute, but the issue could be deeper. In particular, in the HTML 5 requirement that If a reflecting DOM attribute is a DOMString but doesn't fall into any of the above categories, then the getting and setting must be done in a transparent, case-preserving manner. it's not clear what transparent really means here, and whether it's compatible with XML's attribute value normalization. Apologies if this has been discussed before, but I couldn't find anything on point in the archives. -- Elliotte Rusty Harold elh...@ibiblio.org
[whatwg] Close events and workers
I noticed that Section 4.6 of the Web Workers spec still refers to the close event which has been removed: If the script gets aborted by the kill a worker#122aa363b1e6e893_kill-a-worker algorithm, then that same algorithm will cause there to only be a singletask in the event loop at the next step, namely the task for the close event. The terminate a worker #122aa363b1e6e893_terminate-a-worker algorithm removes all the events. Seems like we should update this language. -atw
[whatwg] Images whose contents are not known In such cases, the alt attribute's value may be omitted...
I object. -- The word 'politics' is derived from the word 'poly', meaning 'many', and the word 'ticks', meaning 'blood sucking parasites'. - Larry Hardiman http://www.ChaosReigns.com Guns save lives.
Re: [whatwg] Images whose contents are not known In such cases, the alt attribute's value may be omitted...
On Fri, Jul 24, 2009 at 12:07 PM, dar...@chaosreigns.com wrote: I object. For reference, Darxus is referring to http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-0.html#unknown-images. Now, care to clarify? A two-word objection is essentially useless for anyone, and serves only to spam the mailing list. What exactly do you have a problem with? Examples, clarifications, suggestions, etc? ~TJ
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
[whatwg] Submitting comments form within the spec itself
Based on recent discussions I've implemented a little text box that lets you file bugs straight from the spec itself. Comments submitted in this way are anonymous (well, your IP is logged publicly, but that's all). Please only use it for short issues like typos! Technical topics with any kind of complexity are still best off filed by e-mail. -- 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
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
