Re: [PrototypeRoot]
Ian Hickson: I don't really mind exactly what the solution is; my only concern here would be that I'd be throwing [PrototypeRoot] around a lot. Acknowledged. If you can propose a way of defining this without needing to use [PrototypeRoot] a lot, that’d help. (I assume with PrototypeRoot that the most-derived interface that inherits from such an interface is automatically promoted to being the [[Class]]?) That’s right. -- Cameron McCormack ≝ http://mcc.id.au/
Re: [PrototypeRoot]
On 6/20/09, Cameron McCormack c...@mcc.id.au wrote: Ian Hickson: I don't really mind exactly what the solution is; my only concern here would be that I'd be throwing [PrototypeRoot] around a lot. Acknowledged. If you can propose a way of defining this without needing to use [PrototypeRoot] a lot, that’d help. (I assume with PrototypeRoot that the most-derived interface that inherits from such an interface is automatically promoted to being the [[Class]]?) That’s right. I still want to know: Why would a program want to know the object's [[Class]]? Even if a program could know the [[Class]], what's to say it won't change in the future? Given a particular object, can that object's [[Class]] property change in the future? If it there is an object that exists, say, some sort of HTMLCollection, and it becomes desirable to make more specific behavior, say HTMLFormControlsCollection, what would the code that expects the object's class to be HTMLCollection need to do to continue working in multiple versions of multiple browsers? Microsoft has had vendor extensions in IE prior to the w3c dom level 1. Such vendor extensions don't fall nicely into type heirarchies, but are well-suited towards mixin style design, which is possible with interfaces. Also, there will always be more browsers that implement an interface, but don't give that object the [[Class]] property that is specified in web IDL. Given all these reasons, it would still seem like a bad idea to program to an object's [[Class]]. Instead, the interface should be programmed to using feature detection. Even the [[Class]] were widespread-adopted, it would be a bad idea to do that. I don't know what I am missing, but it doesn't seem to have been explained on this thread. Why do you want that? Garrett -- Cameron McCormack ≝ http://mcc.id.au/
Re: [PrototypeRoot]
On Sat, 20 Jun 2009, Cameron McCormack wrote: Ian Hickson: I don't really mind exactly what the solution is; my only concern here would be that I'd be throwing [PrototypeRoot] around a lot. Acknowledged. If you can propose a way of defining this without needing to use [PrototypeRoot] a lot, that’d help. Given an object and a list of interface that it implements, remove interfaces from the list that match any of the following conditions: - the interface was on the right hand side of an 'implements' clause the left hand side of which lists an interface that the object implements - the interface is inherited from another interface the object implements - the interface has [NoInterfaceObject] ...you should be lift with one interface. Use its name as the [[Class]]. Are there any objects where that leaves an ambiguity? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [PrototypeRoot]
On Sat, 20 Jun 2009, Garrett Smith wrote: I still want to know: Why would a program want to know the object's [[Class]]? It shouldn't, but [[Class]]es are exposed by ECMAScript objects in their toString() method and thus if we want to ensure universally consistent behaviour we have to define this. Even if a program could know the [[Class]], what's to say it won't change in the future? The specs we write. Given a particular object, can that object's [[Class]] property change in the future? If it there is an object that exists, say, some sort of HTMLCollection, and it becomes desirable to make more specific behavior, say HTMLFormControlsCollection, what would the code that expects the object's class to be HTMLCollection need to do to continue working in multiple versions of multiple browsers? We would have to test to see if any pages rely on it; if they do, we'd have to make sure we don't change the [[Class]] somehow. Given all these reasons, it would still seem like a bad idea to program to an object's [[Class]]. Instead, the interface should be programmed to using feature detection. Yup. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [selectors-api] Transitioning to CR
On Fri, 19 Jun 2009 19:12:35 +0200, Ian Hickson i...@hixie.ch wrote: On Fri, 19 Jun 2009, Robin Berjon wrote: On Jun 19, 2009, at 17:14 , Lachlan Hunt wrote: Robin Berjon wrote: Out of curiosity, why not make it two interoperable implementations of *all* the tests, except those stemming from a lack of support for CSS? I was advised to set the requirements low so that it would be easier to proceed past CR. With these requirements, we can get past CR relatively quickly. If we need to wait for at least 2 implementations that both get 100%, that will just delay the spec by 6 to 12 months awaiting the browser vendors' next release cycle. I don't have a strong opinion either way, but I am unaware of any external time pressure on this specification. If there aren't any, why not delay it so we can do the hard (and right) thing of only shipping when we have fully demonstrated interoperability? That seems wiser to me too. The rush is to get interoperable implementations, not to get RECs. That's true. THe question is whether a REC makes it easier to get a new interoperable implementation. And it's open, as far as I can see. Assuming we have implementation of everything, twice, and that for everything we have at least two implementations that interoperate, and that we have a very high level (95% or more) of interoperability of at least 3 implementations, and that we have one complete implementation, and that we are confident that the barriers to completion are now just bugs *that will be fixed* (as opposed to bugs that will live forever), the question becomes relevant. In the meantime, we still don't have any consensus that our test suite is ok, so the rest of the question is a bit academic... ... but assuming we get that, and because it seems that we are at least very near the above set of assumptions, let's decide whether to go the fast or hard way to REC, too. Which means more feedback on this question is welcome. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: Input events, checkboxes and radio buttons
On Fri, 19 Jun 2009 19:57:20 +0200, Erik Arvidsson erik.arvids...@gmail.com wrote: The HTML5 spec says to fire the input event when the user changes a radio button or a checkbox. However, the spec says When the input event applies, any time the user causes the element's *value* to change. For input[type=radio] and input[type=checkbox] the input event should be fired any time the user causes the element's *checked* property to change. The input event does not apply to radio/checkbox. (This is stated in the radio/checkbox sectons.) (This also seems like the wrong list for HTML5 comments, by the way, though I suppose it does not matter much :-)) -- Anne van Kesteren http://annevankesteren.nl/
Re: Input events, checkboxes and radio buttons
On Sat, 20 Jun 2009 12:35:16 +0200, Anne van Kesteren ann...@opera.com wrote: The input event does not apply to radio/checkbox. (This is stated in the radio/checkbox sectons.) Having said that, the change event does apply and it is not stated there that it is also dispatched when the checkedness flag changes. (This also seems like the wrong list for HTML5 comments, by the way, though I suppose it does not matter much :-)) -- Anne van Kesteren http://annevankesteren.nl/
Re: [NameCreator] definition buggy
Ian Hickson: [[Put]] in WebIDL is buggy. It never invokes NameCreator or IndexCreator. I'd like IndexCreator to be invoked if present if the property name is numeric (as per Array's definition -- ToString(ToUint32(P)) == P ToUint32(P) 2**23-1) and otherwise NameCreator to be invoked if present. It is fixed now, and prefers indexed properties over name properties as requested: http://dev.w3.org/2006/webapi/WebIDL/#put Note that I’ve also provided explicit hooks for defining the name/ indexed property algorithms now, which you might like to reference: http://dev.w3.org/2006/webapi/WebIDL/#dfn-determine-the-value-of-a-named-property and others, in http://dev.w3.org/2006/webapi/WebIDL/#indexed-property-xattrs and http://dev.w3.org/2006/webapi/WebIDL/#named-property-xattrs Thanks, Cameron -- Cameron McCormack ≝ http://mcc.id.au/
Re: [selectors-api] Transitioning to CR
On Jun 20, 2009, at 1:39 AM, Charles McCathieNevile wrote: That's true. THe question is whether a REC makes it easier to get a new interoperable implementation. And it's open, as far as I can see. Assuming we have implementation of everything, twice, and that for everything we have at least two implementations that interoperate, and that we have a very high level (95% or more) of interoperability of at least 3 implementations, and that we have one complete implementation, and that we are confident that the barriers to completion are now just bugs *that will be fixed* (as opposed to bugs that will live forever), the question becomes relevant. In the meantime, we still don't have any consensus that our test suite is ok, so the rest of the question is a bit academic... ... but assuming we get that, and because it seems that we are at least very near the above set of assumptions, let's decide whether to go the fast or hard way to REC, too. Which means more feedback on this question is welcome. I'd suggest the CR exist criteria should be two implementations that 100% pass the test suite, i.e. they are individually interoperable on every feature, plus agreement from the WG that the test suite is correct and thorough. From observed behavior, almost no implementors consider the CR level of maturity to be a barrier to adoption, so let's do our best to flush out all potential flaws in the spec before we go to the essentially frozen state of REC. Regards, Maciej
Re: Do we need to rename the Origin header?
Ian Hickson wrote on 6/2/2009 8:11 PM: On Thu, 2 Apr 2009, Bil Corry wrote: Related, HTML5 currently prohibits sending the XXX-Origin header for GET requests. This is to prevent intranet applications leaking their internal hostnames to external sites (are there other reasons?). However, there is value in a site being able to determine that a request originated from itself, so to that end, I'd like to request that HTML5 specify that the XXX-Origin header should be sent for any same-origin GET requests. This would still avoid leaking intranet hostnames while allowing a site to verify that a request came from itself. That's an interesting idea; Adam, what do you think? I'm a bit wary of adding too many features at once here, and it's difficult to define exactly what consists a same-origin request sometimes, so this might not be that easy to do. I've lost track, is this still something being considered? - Bil
Re: Progress Events normative text
On Thu, 18 Jun 2009 19:28:48 +0200, Jonas Sicking jo...@sicking.cc wrote: On Wed, Jun 17, 2009 at 5:49 AM, Anne van Kesterenann...@opera.com wrote: On Mon, 15 Jun 2009 17:00:46 +0200, Charles McCathieNevile cha...@opera.com wrote: On Sat, 13 Jun 2009 13:54:10 +0200, Anne van Kesteren ann...@opera.com wrote: That definitely makes sense, though please take into consideration that for cross-origin loads exposing the file size cannot be done until all HTTP headers have been received and the requested resource has opted in with CORS. OK. One of the things I intended to keep leaving to the host spec was definining what the size actually refers to. I'd think we would like this to consistently refer to the entity body for all usage of progress events as to not confuse people using the API. It seems odd to take great care in order and naming but not in consistent implementation of the event objects. At the very least we can define that for HTTP request, headers are not used. For things like WebSocket and FutureAwesomeMegaAlienProtocol it might make sense to do something different, perhaps. Right. This is ISSUE-4 which was resolved to do it the way the spec does it now (after having it defined in the spec when it was Web API issue 108). While it makes sense to describe what most things do, this seems a case where it might be reasonable to leave it to the spec. Although I am open to defining it (like other stuff) with a default of not counting transaction metadata/overhead, saying that specs can choose to override that specifically if they need to. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: Do we need to rename the Origin header?
On Sat, Jun 20, 2009 at 12:57 PM, Bil Corryb...@corry.biz wrote: I've lost track, is this still something being considered? I should have an updated draft posted soon. Adam
Re: Input events, checkboxes and radio buttons
On Sat, 20 Jun 2009 06:35:16 -0400, Anne van Kesteren ann...@opera.com wrote: On Fri, 19 Jun 2009 19:57:20 +0200, Erik Arvidsson erik.arvids...@gmail.com wrote: The HTML5 spec says to fire the input event when the user changes a radio button or a checkbox. However, the spec says When the input event applies, any time the user causes the element's *value* to change. For input[type=radio] and input[type=checkbox] the input event should be fired any time the user causes the element's *checked* property to change. The input event does not apply to radio/checkbox. (This is stated in the radio/checkbox sectons.) Are you sure? The table under http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#the-input-element (scroll down a bit) shows yes for the input event under the radio/checkbox column. -- Michael
Re: [selectors-api] Return value of lookupNamespaceURI
Boris Zbarsky: If the return value of lookupNamespaceURI is |undefined|, should that stringify to or undefined? Same question for |null|. Note that I'm not sure there's an obvious way to annotate this in web idl yet. Cameron McCormack: Yeah, there’s no way to specify this at the moment. We could have the same [Null] and [Undefined] extended attributes on the operation, and then change the steps in “Native objects implementing interfaces” to take these into account. I’ve added wording to this effect, so that functions on native objects that implement interfaces have their return values handled in the same way as when passing JS values to DOMString operation arguments or attributes. http://dev.w3.org/2006/webapi/WebIDL/#Null http://dev.w3.org/2006/webapi/WebIDL/#Undefined http://dev.w3.org/2006/webapi/WebIDL/#es-DOMString -- Cameron McCormack ≝ http://mcc.id.au/
