- From: Tab Atkins Jr. <notifications@github.com>
- Date: Mon, 28 Aug 2017 17:27:13 +0000 (UTC)
- To: whatwg/dom <dom@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/dom/issues/463/325419483@github.com>
There is a strong reason to make the querySelector API work the same - if the browser can run the selector in a stylesheet, there's no good reason to disallow giving authors access to the same matching capability in JS. Seemingly-arbitrary restrictions make APIs more complicated for authors, harder to learn and confusing to use. I guarantee you that if an author asks "Why can't I match an element with one of these selectors? The browser can!" there's no satisfying answer you can give them. "Rewrite your code to split the selector into two, with the tree-crossing done manually in JS between them" is a terrible answer that will just make them angry, and rightfully so. That said, if we really do think it's a necessity to impose a "must stay in starting tree" restriction, I won't oppose it if we couple it with an issue tracking adding a flag or new method that actually evaluates selectors properly, the same as the browser does. Before we impose this restriction in the spec I'd like to figure out what the new API will look like; I dont' want a `querySelector2(...)` sort of thing, or some huge unwieldy name that people won't want to type. --- > Note that step (3) doesn't necessarily invoke the author explicitly giving a selector that crosses shadow boundaries to the generic code (1). The generic code (1) itself could be traversing through selectors in every stylesheet in the node tree and automatically processing them to polyfill missing CSS features, etc... I read this as an argument for the exact opposite case. CSS polyfill code wants to faithfully polyfill CSS, which includes correctly evaluating selectors that people would use in CSS. I suspect this restriction would break as many cases as it fixes. I understand that we sometimes need to impose seemingly-arbitrary restrictions for implementation reasons, but let's defend it on those grounds, not pretend we're doing authors a favor here. Carving out pieces of the platform that UAs can use but authors can't isn't helpful to them. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/whatwg/dom/issues/463#issuecomment-325419483
Received on Monday, 28 August 2017 17:27:36 UTC