Re: [whatwg] WebIDL vs HTML5 storage changes - delete behavior
On Sun, 18 May 2008, Maciej Stachowiak wrote: On May 18, 2008, at 3:18 PM, Brady Eidson wrote: While I'm on the topic, I'm also curious about that [XXX] placeholder. There's a bug in WebKit's bugzilla pointing out that the IE8 beta and Firefox 2 both support `delete storage.keyName` syntax as an alias for `storage.removeItem(keyName)` I'm taking a guess here and assuming supporting the `delete` syntax is the implied concept behind [XXX] WebKit's JavaScript engine doesn't currently have the ability to run custom code when a property is deleted. It would be a significant challenge to add this capability and possibly a performance regression; and no other DOM-related spec requires this, even when there is NameGetter or IndexGetter behavior. For example NodeLists and HTMLCollections do not let you delete by name to remove the item (I'm not sure what that would even mean). So I'd prefer not to have to introducethis concept just for this one case. On Sun, 18 May 2008, Brady Eidson wrote: WebKit has the ability to add custom property deletion on a per-class basis - therefore not slowing down the common case at all. That's how I fixed the bug to make us compatible with IE8 and Firefox for now as this debate gets underway... On Mon, 19 May 2008, Geoffrey Garen wrote: It is *very* weird, and therefore not a useful shorthand. In JavaScript, delete means remove this property / interface from this JavaScript object. I can't think of any context in which it means anything else. For example, delete node.parentNode attempts to remove the parentNode property from node. It does not remove parentNode from the document or anything like that. delete window attempts to remove the window property from the global object. It does not close the window or anything like that. In other words, you can be certain that delete is a simple operation with a consistent side-effect. As a JavaScript programmer, I would find it very difficult to reason about objects that might or might not change the behavior of the delete operator. One reason i would find it very difficult is that operator overloading does not exist in JavaScript at all, so to understand this one API, I would need to understand a vast corpus of programming language goobery that is not at all covered in any JavaScript manual. Another reason I would find it very difficult is that the overloaded meaning of delete here (remove persistent storage from disk) is far afield from the original meaning (remove interface from temporary object in memory). To give you an analogy, even in C++, where you're allowed to overload operator delete, if you overloaded operator delete to mean do not free this object's memory, but do delete the file it references from the file system, well, let's just say that your patch would not pass code review with any of your four reviewers :). I am not sure if any JS decoration or collection libraries depend on the canonical behavior of operator delete, but if they do, I would hate for them all to have to ship with the asterisk, BEWARE: do NOT use this decoration / collection library with that one weird DOM object that interprets 'delete' to mean 'remove important data from the user's disk'. Oy! On Mon, 19 May 2008, Brady Eidson wrote: I'm unsure if you have the proper background with the Storage interface that is in question here. I'm guessing that the reason that Firefox 2 and IE8 support the modified behavior of delete for Storage items is because the way of thinking about Storage items we're trying to get across meets most of the expectations of manipulating properties that you lay out below. On May 19, 2008, at 3:18 PM, Geoffrey Garen wrote: In JavaScript, delete means remove this property / interface from this JavaScript object. I can't think of any context in which it means anything else. The spec makes it clear that storage items and properties on the Storage object are interchangeable. `storage.foo = bar` happens to be equivalent to `storage.setItem(foo, bar)`, but is also no different from `someRandomObject.foo = bar` as far as keeping a collection of properties on an object. This also applies for enumeration, etc. Equivalently and more relevant to the discussion, `delete storage.foo` happens to be equivalent to `storage.removeItem(foo)`, but is also *little* different from `delete someRandomObject.foo` For example, delete node.parentNode attempts to remove the parentNode property from node. It does not remove parentNode from the document or anything like that. delete window attempts to remove the window property from the global object. It does not close the window or anything like that. In the SessionStorage case, this applies with zero caveats. In the LocalStorage case, it applies with the caveat that all of the properties you set on this object will still
Re: [whatwg] DOM Storage feedback
On Mon, 28 Apr 2008, Brady Eidson wrote: Anne was asserting that since the interface for setItem() specifies a DOMString as the input, anything you pass it will be stringified. Therefore passing it the null value would be stringified to null. This is what you currently see in all the major browsers with window.alert(null), for example, which is also specified as a DOMString input parameter. Therefore a call to setItem(foo, null); becomes, in effect, setItem(foo, null); Is this correct? If so, the spec is fine as-is, and removeItem() is the only way to remove an individual item. That is correct, at least currently. I am tempted to change this to [Null=Empty], though (i.e. make 'null' act like the empty string). However, I'm somewhat stuck on this as it depends on what happens with [Null] in WebIDL. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] getElementsByClassName case sensitivity
Anne van Kesteren ann...@opera.com wrote: On Mon, 12 Jan 2009 15:25:33 +0100, Stewart Brodie stewart.bro...@antplc.com wrote: Ian Hickson i...@hixie.ch wrote (on 25 July 2008): I've made [getElementsByClassName] consistent with how classes work in CSS (case-insensitive for quirks and case-sensitive otherwise). I was looking for some tests for this API and found some from Opera (found at http://tc.labs.opera.com/apis/getElementsByClassName/) but given the dates on them predate the latest spec changes (which causes some to fail now), I was wondering if up to date versions are now kept somewhere else instead? The tests already take this change into account. It was agreed upon way earlier prolly over IRC or so, but the specification hadn't catched up with reality yet. I'm not sure what other tests you might believe to be out of date (and why) and would be interested in knowing being the author and all :-) Specifically: test 14 - tests for case-sensitivity in a document that is in quirks mode. Are you saying that this change has now been reversed and the comparisons are always case-sensitive, thus reintroducing the discrepancy between CSS's handling of classes and this new method? -- Stewart Brodie Software Engineer ANT Software Limited
Re: [whatwg] getElementsByClassName case sensitivity
On Tue, 13 Jan 2009 11:08:56 +0100, Stewart Brodie stewart.bro...@antplc.com wrote: Specifically: test 14 - tests for case-sensitivity in a document that is in quirks mode. Are you saying that this change has now been reversed and the comparisons are always case-sensitive, thus reintroducing the discrepancy between CSS's handling of classes and this new method? Since my initial e-mail did not seem to have done it, could you please take a look at the source code of the respective test and tell me if you see a problem there? http://tc.labs.opera.com/apis/getElementsByClassName/014.htm To be perfectly clear, there is no discrepancy between CSS handling and the getElementsByClassName method and the test is testing that there is not. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] DOMStringMap named properties
On Thu, 18 Dec 2008, Cameron McCormack wrote:
[19:38] Hixie heycam: i'd much rather have the idl look like the js
object and have [IndexSetter] etc take arguments to provide names
for the other languages
But would you add those names? :)
Probably not. :-)
If you definitely don’t want to use [NoIndexingOperations]
I'd rather not. Say this was implemented in Perl, for instance. I'd want
to see this implemented as a tied hash, not as a hashref with methods. I
don't know that the current IDL would be enough, and I wouldn't know how
to write hte IDL today for that case either. Better, IMHO, to not specify
that yet, and if it comes up, we can write IDL for that language.
then the section should look like the following:
The DOMStringMap interface represents a set of name-value pairs. When
a DOMStringMap object is instantiated, it is associated with three
algorithms: one for getting the list of name-value pairs, one for
setting names to certain values, and one for deleting names.
[NameGetter, NameSetter, NameCreator, NameDeleter]
interface DOMStringMap {
};
The names of the supported named properties on a DOMStringMap object
are the names of each pair returned by the algorithm for getting the
list of name-value pairs.
When a DOMStringMap object is indexed to retrieve a named property
/name/, the following algorithm must be run:
1. Let /pairs/ be the list returned from the algorithm for getting
the list of name-value pairs.
2. Let /pair/ be the entry in /pairs/ whose name component is equal
to /name/.
3. Return the value component of /pair/.
When a DOMStringMap object is indexed to create or modify a named
property /name/ with value /value/, the algorithm for setting names to
certain values must be run, passing /name/ as the name and the
result of converting /value/ to a DOMString as the value.
When a DOMStringMap object is indexed to delete a named property named
/name/, the algorithm for deleting names must be run, passing /name/
as the name.
I haven't quite used your text, but I used something much more like it
than there was before. Please let me know if any of the discrepancies are
problems I missed.
If you go without [NoIndexingOperations], then I suggest specifying
somehow that HTMLElement::dataset only exist in language bindings that
support object indexing, or only in ECMAScript.
Added a note.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] getElementsByClassName case sensitivity
On Tue, 13 Jan 2009 11:17:08 +0100, Anne van Kesteren ann...@opera.com wrote: Since my initial e-mail did not seem to have done it, could you please take a look at the source code of the respective test and tell me if you see a problem there? http://tc.labs.opera.com/apis/getElementsByClassName/014.htm To be perfectly clear, there is no discrepancy between CSS handling and the getElementsByClassName method and the test is testing that there is not. Wow, epic fail. I missed it should match two elements. The test is indeed out of date. * updates the test now. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] DOM Storage feedback
On Tue, Jan 13, 2009 at 1:41 AM, Ian Hickson i...@hixie.ch wrote: On Mon, 28 Apr 2008, Brady Eidson wrote: Anne was asserting that since the interface for setItem() specifies a DOMString as the input, anything you pass it will be stringified. Therefore passing it the null value would be stringified to null. This is what you currently see in all the major browsers with window.alert(null), for example, which is also specified as a DOMString input parameter. Therefore a call to setItem(foo, null); becomes, in effect, setItem(foo, null); Is this correct? If so, the spec is fine as-is, and removeItem() is the only way to remove an individual item. That is correct, at least currently. I am tempted to change this to [Null=Empty], though (i.e. make 'null' act like the empty string). However, I'm somewhat stuck on this as it depends on what happens with [Null] in WebIDL. I talked with Cameron a while ago about what the default behavior should be for null. We couldn't find any functions that required that null be treated as null, but there are several examples of functions that require that null be treated as the empty string. So from a code purity point of view it would be nicer if we could make the default behavior be that null is treated as null as that would require fewer exceptions. The downside is that it would be a bigger change for more UAs than going the other way around. So there's more risk of compat problems. / Jonas
Re: [whatwg] Fuzzbot (Firefox RDFa semantics processor)
Martin Atkins wrote: One problem this can solve is that an agent can, given a URL that represents a person, extract some basic profile information such as the person's name along with references to other people that person knows. This can further be applied to allow a user who provides his own URL (for example, by signing in via OpenID) to bootstrap his account from existing published data rather than having to re-enter it. So, to distill that into a list of requirements: - Allow software agents to extract profile information for a person as often exposed on social networking sites from a page that represents that person. - Allow software agents to determine who a person lists as their friends given a page that represents that person. - Allow the above to be encoded without duplicating the data in both machine-readable and human-readable forms. Is this the sort of thing you're looking for, Ian? Much of the above section could be applied to any other RDF vocabulary with a bit of search and replace, but I'll leave that to others since FOAF is the only RDF vocabulary with which I have any experience. Why we must restrict the use case to a single vocabulary or analyze all the possibile vocabularies? I think it's be better to generalize the problem and find a unique solution for human/machine. I tried to expose this here... http://lists.w3.org/Archives/Public/public-html/2009Jan/0082.html ...where the fundamental problem is described in this way: - User agents must allow users to see that there are semantic-links (connections to semantically structured informations) in a HTML document/application. Consequently user agents must allow users to follow the semantic-link, (access/interact with the linked data, embedded or external) and this involves primarily the ability to: a) view the informations b) select the informations c) copy the informations in the clipboard d) drag and drop the informations e) send that informations to another web application (or to OS applications) selected by the user. -- Giovanni Gentili
Re: [whatwg] Fuzzbot (Firefox RDFa semantics processor)
Giovanni Gentili wrote: Why we must restrict the use case to a single vocabulary or analyze all the possibile vocabularies? I think it's be better to generalize the problem and find a unique solution for human/machine. The issue when trying to abstract problems is that you can end up doing architecture astronautics; you concentrate on making generic ways to build solutions to weakly constrained problems without any attention to the details of those problems that make them unique. The solutions that are so produced often have the theoretical capacity to solve broad classes of problem, but are often found to be poor at solving any specific individual problem. By looking at actual use cases we can hope to retain enough detail in the requirements that we satisfy at least some use cases well, rather than wasting out time building huge follies that serve no practical purpose to anyone.
Re: [whatwg] Fuzzbot (Firefox RDFa semantics processor)
James Graham: The issue when trying to abstract problems is that you can end up doing architecture astronautics; you concentrate on making generic ways to build solutions to weakly constrained problems without any attention to the details of those problems that make them unique. I think the right level, like in my proposal, is greatly under astronautics but no so low as single vocabularies. -- Giovanni Gentili
Re: [whatwg] Fuzzbot (Firefox RDFa semantics processor)
Giovanni Gentili wrote: James Graham: The issue when trying to abstract problems is that you can end up doing architecture astronautics; you concentrate on making generic ways to build solutions to weakly constrained problems without any attention to the details of those problems that make them unique. I think the right level, like in my proposal, is greatly under astronautics but no so low as single vocabularies. I rather disagree. How we interact with information depends fundamentally on the type of information. If the information is a set of geographical coordinates, for example, the set of useful interactions are rather different to those for a bibliographic entry. Trying to pretend that the two problems are just interchangeable instances of the same semantically structured information problem is likely to hide the important distinctions between the two problem domains.
Re: [whatwg] DOM Storage feedback
On Tue, Jan 13, 2009 at 4:48 AM, Anne van Kesteren ann...@opera.com wrote: On Tue, 13 Jan 2009 13:44:22 +0100, Jonas Sicking jo...@sicking.cc wrote: I talked with Cameron a while ago about what the default behavior should be for null. We couldn't find any functions that required that null be treated as null, but there are several examples of functions that require that null be treated as the empty string. alert() requires it. How so? I couldn't imagine how a site could depend on that. That said, this did make me think about document.write, where we do seem to display 'null' rather than empty string. So this might be an exception. Besides that I believe we (Opera) specifically did it for methods here and there to be more compatible with Internet Explorer and make sites work better. Do you know of any sites worked better because of the change? Or indeed that were affected at all by the change? / Jonas
Re: [whatwg] DOM Storage feedback
On Tue, 13 Jan 2009 19:32:16 +0100, Jonas Sicking jo...@sicking.cc wrote: On Tue, Jan 13, 2009 at 4:48 AM, Anne van Kesteren ann...@opera.com wrote: alert() requires it. How so? I couldn't imagine how a site could depend on that. Debugging, for one. You can't mean that you'd consider making alert(null) give a dialog that contains the empty string rather than null. Besides that I believe we (Opera) specifically did it for methods here and there to be more compatible with Internet Explorer and make sites work better. Do you know of any sites worked better because of the change? Or indeed that were affected at all by the change? No, sorry. I believe WebKit is doing it as well though for a number of methods/attributes, but it's been a while since I looked into this. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] DOM Storage feedback
On Jan 13, 2009, at 11:28 AM, Anne van Kesteren wrote: On Tue, 13 Jan 2009 19:32:16 +0100, Jonas Sicking jo...@sicking.cc wrote: On Tue, Jan 13, 2009 at 4:48 AM, Anne van Kesteren ann...@opera.com wrote: alert() requires it. How so? I couldn't imagine how a site could depend on that. Debugging, for one. You can't mean that you'd consider making alert(null) give a dialog that contains the empty string rather than null. Yeah, we definitely shouldn't change this for alert or document.write Besides that I believe we (Opera) specifically did it for methods here and there to be more compatible with Internet Explorer and make sites work better. Do you know of any sites worked better because of the change? Or indeed that were affected at all by the change? No, sorry. I believe WebKit is doing it as well though for a number of methods/attributes, but it's been a while since I looked into this. We have marked up some of the attributes and method parameters where the null value must be treated as instead of null with ConvertNullToNullString in our IDL. There are a number of method parameters that are not marked that way, but I'm not sure how many of these require the normal ECMAScript behavior and how many just haven't been changed. Regards, Maciej
Re: [whatwg] WebIDL vs HTML5 storage changes - delete behavior
Ian Hickson:
For DOMStringMap, my intention was to not provide methods at all, and
only provide the JS-native mechanisms.
Maciej Stachowiak:
A bold choice, but I would not recommend it as the sole available
mechanism.
Ian Hickson:
See above for UndoManager, but for DOMStringMap I don't want to add any
other mechanisms, because they introduce name clashes. Right now the IDL
for DOMStringMap is:
[NameCreator, NameDeleter, NameGetter, NameSetter]
interface DOMStringMap {};
It basically emulates a JS Object. It's intended only for JS. I don't see
why this is a bad idea.
At the moment, the interface is useful only for JS (and other languages
that support this kind of indexing). For other languages, a
DOMStringMap object would appear to be a completely opaque object
without any means of interacting with it. Given that this is basically
meant to be a shorthand for getting/setting attributes with particular
names, I would be happy with it not existing in other language bindings.
Web IDL doesn’t have a mechanism to state that an interface member or a
definition should only be included if the target language binding is a
particular one, though.
An alternative would be to put operations on the interface to act as the
getters/setters/etc., and use the [NoIndexingOperations] extended
attribute to indicate that these operations won’t correspond to
properties in language bindings such as ECMAScript. That would then at
least make the interface useful for other languages.
--
Cameron McCormack ≝ http://mcc.id.au/
Re: [whatwg] DOM Storage feedback
Jonas Sicking: I talked with Cameron a while ago about what the default behavior should be for null. We couldn't find any functions that required that null be treated as null, but there are several examples of functions that require that null be treated as the empty string. I began testing all attributes and operations with DOMString arguments from a selection of specs for their behaviour wrt null and undefined: http://mcc.id.au/2009/01/string-handling/string-handling Each pair of characters in the column for a browser is the behaviour for null and undefined, respectively. It’s nowhere near complete, though you can see that there are some operations arguments and attributes that stringify null to null (“S” in the column). -- Cameron McCormack ≝ http://mcc.id.au/
Re: [whatwg] DOM Storage feedback
On Tue, Jan 13, 2009 at 3:37 PM, Cameron McCormack c...@mcc.id.au wrote: Jonas Sicking: I talked with Cameron a while ago about what the default behavior should be for null. We couldn't find any functions that required that null be treated as null, but there are several examples of functions that require that null be treated as the empty string. I began testing all attributes and operations with DOMString arguments from a selection of specs for their behaviour wrt null and undefined: http://mcc.id.au/2009/01/string-handling/string-handling Each pair of characters in the column for a browser is the behaviour for null and undefined, respectively. It's nowhere near complete, though you can see that there are some operations arguments and attributes that stringify null to null (S in the column). So in the null column an S means that it's treated as null, an E as , but what does N mean? Yes, there are definitely a lot of Ss in the null column for non-firefox browsers. The question to me is if this is really needed for webcompat though. Looking though our bug database I see no indication of that, but that's not necessarily a proof. If we were able to use as the default behavior for null then we would be able to get away with much fewer exceptions (so far alert() and and possibly write() has been found). / Jonas
Re: [whatwg] DOM Storage feedback
Jonas Sicking: So in the null column an S means that it's treated as null, an E as , but what does N mean? N means that I was able to determine that null was treated as the actual null value, rather than converted to a string. Yes, there are definitely a lot of Ss in the null column for non-firefox browsers. The question to me is if this is really needed for webcompat though. Looking though our bug database I see no indication of that, but that's not necessarily a proof. If we were able to use as the default behavior for null then we would be able to get away with much fewer exceptions (so far alert() and and possibly write() has been found). OK. So what is more important for choosing the default: fewer exceptions (and thus fewer [Null=…] things polluting the IDL), consistency with the default stringification behaviour of ECMAScript, or avoiding the somewhat counterintuitive default behaviour of converting a valid value of the type to a different value of that type? -- Cameron McCormack ≝ http://mcc.id.au/
Re: [whatwg] DOM Storage feedback
On Tue, Jan 13, 2009 at 4:26 PM, Cameron McCormack c...@mcc.id.au wrote: Jonas Sicking: So in the null column an S means that it's treated as null, an E as , but what does N mean? N means that I was able to determine that null was treated as the actual null value, rather than converted to a string. So it behaves different from passing in an empty string? For some functions this surprises me, such as for the namespace parameter for getAttributeNS, I would think that we there treat the same as null. Yes, there are definitely a lot of Ss in the null column for non-firefox browsers. The question to me is if this is really needed for webcompat though. Looking though our bug database I see no indication of that, but that's not necessarily a proof. If we were able to use as the default behavior for null then we would be able to get away with much fewer exceptions (so far alert() and and possibly write() has been found). OK. So what is more important for choosing the default: fewer exceptions (and thus fewer [Null=…] things polluting the IDL), consistency with the default stringification behaviour of ECMAScript, or avoiding the somewhat counterintuitive default behaviour of converting a valid value of the type to a different value of that type? converting a valid value of the type to a different value of that type, which values exactly? I think another factor, that you haven't mentioned, that is very important is web compatibility. But beyond that I think I would rate fewer exceptions highest. / Jonas
Re: [whatwg] DOM Storage feedback
Jonas Sicking: So it behaves different from passing in an empty string? For some functions this surprises me, such as for the namespace parameter for getAttributeNS, I would think that we there treat the same as null. Not necessarily, but I agree that would be a better thing to report. I’ll rejig the tests to get that information. Cameron McCormack: OK. So what is more important for choosing the default: fewer exceptions (and thus fewer [Null=…] things polluting the IDL), consistency with the default stringification behaviour of ECMAScript, or avoiding the somewhat counterintuitive default behaviour of converting a valid value of the type to a different value of that type? converting a valid value of the type to a different value of that type, which values exactly? null. It feels slightly strange to me to treat null as a “second class value” by default. But I’ll get over it. :-) It may actually be indicative of a need for two distinct types: strings (i.e., possibly empty sequences of characters) and strings-or-null. But I don’t know if it’s worth rewriting everything in this way. I think another factor, that you haven't mentioned, that is very important is web compatibility. But beyond that I think I would rate fewer exceptions highest. Well, I assume that writers of specs that document already-implemented interfaces will choose the appropriate [Null] annotation (or lack of it) for web compatibility. Which to choose as the default is orthogonal, I think. -- Cameron McCormack ≝ http://mcc.id.au/
Re: [whatwg] WebIDL vs HTML5 storage changes - delete behavior
On Wed, 14 Jan 2009, Cameron McCormack wrote:
[NameCreator, NameDeleter, NameGetter, NameSetter]
interface DOMStringMap {};
At the moment, the interface is useful only for JS (and other languages
that support this kind of indexing). For other languages, a
DOMStringMap object would appear to be a completely opaque object
without any means of interacting with it. Given that this is basically
meant to be a shorthand for getting/setting attributes with particular
names, I would be happy with it not existing in other language bindings.
Web IDL doesn’t have a mechanism to state that an interface member or
a definition should only be included if the target language binding is a
particular one, though.
An alternative would be to put operations on the interface to act as the
getters/setters/etc., and use the [NoIndexingOperations] extended
attribute to indicate that these operations won’t correspond to
properties in language bindings such as ECMAScript. That would then at
least make the interface useful for other languages.
What I would like to be able to say is: This is how it works in JS. If
you are implementing this in another language binding, contact me and
we'll come up with a solution for that language.
I don't want this to only work in JS, I just haven't designed the API for
the other languages. And I don't want to introduce a suboptimal design --
e.g. the above IDL would be meaningless for Perl, where objects don't have
a concept of name getters, etc. But for Perl what we'd want is to expose a
tied hash, which is the equivalent of what this is in JS. But we don't yet
have WebIDL magic for Perl, so I can't say that yet.
Does that make sense?
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTML 5 : Misconceptions Documented
There were a number of e-mails on this thread regarding how Collections and other interfaces worked with respect to properties being exposed. I have now updated the HTML5 spec to take into account the new features in WebIDL that expose these properties. Please let me know if I missed one. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] WindowHTML Option() constructor
On Tue, 28 Oct 2008, Anne van Kesteren wrote: On Tue, 28 Oct 2008 02:52:36 -0700, Ian Hickson i...@hixie.ch wrote: On Sun, 5 Nov 2006, Anne van Kesteren wrote: The Option() constructor takes four arguments: 'Option(in DOMString name, in DOMString value, in boolean defaultSelected, in boolean selected)' is the complete version of it. Fixed. The IDL uses Constructor() but should use NamedConstructor=Option() instead. (See e.g. HTMLImageElement for how it should be done.) Apparently I fixed this at some point. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
