Re: window.event and Event.srcElement

> Basically, either UAs that currently implement window.event remove it or > it's clearly required for web compat and hence needs to be specified so > other UAs can implement it. I don't see any other sane options; do you? > > I'm okay with the first one. Is that a real option? I've never seen any

Re: window.event and Event.srcElement

What content depends on them, and why cater to such code? On Mon, Mar 25, 2013 at 6:44 AM, Anne van Kesteren wrote: > WebKit and IE both support these kinda disastrous APIs. Turns out more > and more content starts to rely on them as with every bug you keep > around for too long. Unless someone

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

On Thu, Mar 7, 2013 at 2:02 PM, Boris Zbarsky > But you want to continue linking to the version hosted on the Disqus > server instead of hosting it yourself and modifying as desired, presumably? > > Because if you're hosting yourself you can certainly just make a slight > modification to opt into

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

wrote: > As for the example: This isn't arbitrary 3rd party > scripts coming and crippling your DOM in unexpected ways. This is you as > the developer of the site saying the native experience is too limiting and > then opting in to a different UI. This is also not global, change the world > beha

Re: Beacon API

On Wed, Feb 13, 2013 at 11:45 AM, Tab Atkins Jr. > I started a thread last year in WHATWG about this subject, though from > a slightly different angle: > >. > A new simple API sounds like the best solution. Adding a suffi

Re: [selectors-api] Consider backporting find() behavior to querySelector()

> > > It should be noted that JQuery/sizzle does not use querySelector() at all, > AFAICS. It only uses querySelectorAll() and sometimes switches to > .getElementById() or document.body. > > I took a look at using querySelector as an optimization a while back but it did not seem to make a significa