- From: Jonas Sicking <jonas@sicking.cc>
- Date: Fri, 21 Feb 2014 14:47:00 -0800
- To: Ian Hickson <ian@hixie.ch>
- Cc: Maciej Stachowiak <mjs@apple.com>, "Edward O'Connor" <eoconnor@apple.com>, Webapps WG <public-webapps@w3.org>
On Fri, Feb 21, 2014 at 2:28 PM, Ian Hickson <ian@hixie.ch> wrote: > On Fri, 21 Feb 2014, Maciej Stachowiak wrote: >> >> I'd guess most sophisticated webapps do not use attribute-based event >> handlers (as opposed to addEventListener), so they would not get this >> convenient scoping benefit. > > That's not clear to me. I mean, certainly today, with div soup, they > don't. But that's at least partly because there's no sane way to do it > when your markup isn't really declarative in any useful sense. > > When you have Web components that let you get the effect you want while > sticking to a terse markup language, it becomes much more feasible to > return to using inline event handlers. Also the fact that a lot of markup is generated on the server also makes it less interesting to stick the code in the markup. Code generating code is messy and error prone. Also, code in attributes tend to mainly be readable when the code is *really* short. In your example you end up calling out into an external process function. However it could well be less code to avoid the process() function entirely and just have all the processing inline. But that likely will require putting the whole thing outside of an attribute. Other reasons are that the scope chaining for code in attributes, and especially in attributes of form controls, makes the code more error prone. It means that your code risks breaking any time that we add new properties to elements. Finally increased interest in using CSP and preventing XSS has increased incentive to put code outside the markup. I'm certainly not opposed creating something with proxy-like syntax, at least if we check that that's something that developers are really asking for and that implementations are interested in implementing (this thread calls both into question). However I think .elements is still a bad API due to its live-ness and due to not including all form controls. And if we get rid of the liveness that makes it much more possible to use the type of API I drafted. We'd simply have getParticipants() return something that has proxy behavior. / Jonas
Received on Friday, 21 February 2014 22:47:58 UTC