On Tue, May 9, 2017 at 1:19 AM, Steve Litt <slitt@...2357...> wrote:

> CSS selectors are powerful things these days (though still with some
> limitations), and a well crafted querySelector() can save a lot of DOM
> traversal in code.

How about browser support? What are the limitations you mention? These
CSS type queries certainly seem more intuitive to someone knowing CSS,
but before I switch to them I'd like to check for any downsides.

Support is excellent - all the way back to IE9 (and IE8, if you limit the choice of selectors).

http://caniuse.com/#search=querySelector

The limitations are purely those inherent in CSS selectors in general - e.g. that you can only select descendants of your chosen node, not its ancestors, and that there's no CSS selector for "the current node itself" ("this", if you will). None if this is likely to affect your use of them, and as a replacement for getElement(s)By... there are no real downsides.

> By putting a click handler on the group, and passing both "evt" and
> "this" you can get a reference to the object that was clicked
> ("evt.target") and the group itself ("this").

Other than demonstrating "this" and "if (e) e.stopPropagation();", is
there a benefit to putting "onclick=change_all_colours();" on the group
rather than on each losenge? I think the behavior would be identical,
it would have simplified change_fill(), and would have required only
one argument for change_fill().

No, it was purely demonstrative to show that you can put a handler on the <g> and use "this" to get a reference to the group.

Regards,

Mark