Cameron McCormack wrote:
Boris Zbarsky:
I thought there had been at least some mention of this colliding with
existing string types in IDLs that are already in use? I know this will
make it much harder for Mozilla to use webidl IDL fragments "as is"...
Yes, but then Jonas replied saying that Mozilla wasn’t intending on
using them as is. But if you are, …
I don't know that we've made any decisions along these lines...
I can easily rename the type back to DOMString. I’d like to know if you
all think there is any problem in keeping the name as DOMString but
removing the null from its set of values, and requiring the use of the
nullable type ‘DOMString?’ to specify a string type that does allow
null. Because then it is different from the traditional DOMString as
defined in DOM Core.
Are we going to rewrite the existing DOM spec idl to the new syntax as
needed (e.g getElementsByTagNameNS)?
-Boris
