Comments for Reforming the W3C TAG
I still think this isn't really about object-model reformation, and mostly just about other kinds of strangeness. It happens that you can't syntactically write myarray.7, and so Allen's proposal is enough to implement most of arrays (although length being a data property means you're still hosed). But the basic point is that Arrays are weird, and we need to be able to subclass them easily, and reimplement them possibly (which Proxies work for). So I still don't think OMR gets you what you want.
Regarding Dr. Tennison, I'll let her speak for herself if she's offended by my categorization. I will say, though, that in the sense I had intended it -- someone who works with front-end tech -- I don't think the label would stick. But if a correction is due ill make it.
1- Having read all four blog posts, at times it reads as, hey likes taken over this group to make them deal with our issues and ways of working. You may argue that isn't a bad thing, but babies and bath water spring to mind. A TAG that only considers current web developer issues may be little better than the current.
2- The TAG can look too academic, sure, but is not because they are looking at the web in 5 or more years time and discussing the issues, rather than the problems people face today. They are looking at building a combustion engine rather than the problems with the horse carriage (which isn't to liken web development to a horse carriage).
Linked Data, URIs and RDF may look like it has nothing to do with web development, but look at how much the web has changed in the last few years, key technologies now would seem irrelevant to those building web sites 10 years a go. Many applications are data rich. Imagine building a mapping site/app (hello Apple) but instead of pulling in data from various sources just magically pulled in data for places and locations from relevant sites on the net, and this was just a standard feature with no special API. A semantic and integrated web could offer applications and opportunities that at the moment can not be conceived. I'm not saying this is exactly what is in mind, but I think there is an argument that the TAG needs to look at both the short and long term, even if the latter may seem somewhat academic.
today’s TAG isn’t composed of web developers (Sir Tim excepted)
Tim isn't a web developer. He's not built a serious web site (by modern standards) ever. He's built a reasonably significant Web App (tabulator) but that was unlikely to generate any of the typical experiences that web developers face (no customers, purely for his own fun, no serious user base, etc.).
Tennison is, in fact, a web developer, albeit an XML centric one with Semantic Web leanings.
I've been vehement of by criticism of the TAG and would love to see some serious reform. But I like the details to be accurate!
Also, it's been great that you're coordinating with TC39 (and following the above rule :).
Alex, I still don't understand about subclassing, OMR, and Array. Are you just thinking of the length weirdness?
I wasn't at the previous TPAC where TC39 attended, but I'd hope for some sort of meeting where there would be a real agenda, the DOM folks in the room, and some pre-defined list of things to work through.
I'm all for DOM APIs not using the MOP. I honestly think that from now on, anything that appeals to Proxies to define a DOM API must have a legacy reason to do so or it should be considered bad style. Being idiomatic is about doing what user code can (usually) do. Some of that is about excavating power and handing to everyone. Some of it is about not using extraordinary power for ordinary things. I think we need more of both kinds of restraint.
Re: built-in subclassing and and OMR, think "how do I subclass Array?".
As far as TPAC goes, I don't remember if you were at the previous join TPAC/TC39 meeting, but it didn't seem like a particularly productive endeavor. Hopefully future joint meetings would be more useful.
I'm a little confused about the connection between builtin subclassing (which is definitely important) and object model reformation (which is a much bigger change). Can you clarify what you mean?
One more radical idea is that DOM APIs should just stop using the full power of the JS MOP to define their APIs, and only define things that can be expressed in JS. Obviously this can't work for NodeLists and things like that, but why should new APIs (eg URL) take liberties with the language that we wouldn't even take on TC39?
Note that it's actually the WHATWG that's designing MultiMaps in the guise of URLs. ^_^ It's the effort of me and Anne, one of the other people running for the TAG.
Anyway, I'm doing my best (and explicitly coordinating with tc39) to make sure that our API will be palatable to tc39 when they design MultiMaps.
In fact, the only two action points from your original blog post that I haven't seen action on are
1.) Add build flags to allow WebKit-based products to enable/disable vendor prefix support independently.
and 2.) Chrome/Safari sunset prefixes as soon as is practicable post-standardization.
Any word on what's going on? I honestly didn't expect anything to happen, but Webkit and Webkit vendors need to be called out on this stuff, and if the calling out can come from inside it has a lot more weight than when it comes from other browser vendors.
I see a couple of concrete routes: first, we need on the TC39 side to make subclassing of intrinsics a serious priority. It's something that DOM does thorough the back-door all the time because we haven't provided any other avenue. Allen's Object Model Reformation gets my vote as one of the highest-priority things we can do for ES7.
Next, I think we can simply go and meet W3C members where they are. I tried to get folks excited about going to TPAC this year, but no joy. Norbert, Rafael and I were the only ones there. If we plan a year in advance, I think there's hope we can pull it off. TPAC is long enough that we could co-locate the meetings and overlap by a day or two.
There's also a ton of room to import and to the "architectural archeology" process WRT DOM. I'm working on a DOM Promises proposal right now, and eventually I think we should have Promises in the JS std lib. Same for events. Truly common stuff in DOM should very often get imported into the JS API where they make sense. Right now DOM is to COM as JS is to C++, and a meaningful solution to everyone is to expand the language's API and semantics to fold in truly common needs over time. Else folks get left straddling the chasm, either as spec authors or as users.
I do think TC39 needs to coordinate with TAG or someone else at W3C on an "Idiomatic JS API Guide". We've gotten a couple of important things done -- notably moving DOM properties to prototypes in WebIDL -- but DOM and WebIDLs maintainers view it as the job of individual WGs to design sane APIs (punting on things like constructors to my great dismay. See: http://infrequently.org/2011/10/real-constructors-webidl-last-call/), so we should at least try to communicate what "good" looks like.
So that's my list. What do you think? What else would you like to see?
Yes, the .length weirdness is probably the worst of it, but it's related to using indexing operations. Should you, e.g., write into a slot beyond the current .length, you get the .length extended, meaning some sort of trap was handled based on the index operation.