- From: Ryosuke Niwa via GitHub <sysbot+gh@w3.org>
- Date: Sun, 03 Feb 2019 02:56:29 +0000
- To: public-css-archive@w3.org
> But *updating* that DOM state from JavaScript would slow things down for interactive pseudoclasses that change a lot Hardly. What would be way more expensive is the updating of the relevant style, layout, & paint. What's really expensive is having to track the dependency between elements, and figure out if hovering an element can in turn affect other element's `:state` state. That can quickly lead to O(n^2) or even exponential algorithms if implemented naively. Note that we **DO** need JS-based solution regardless because elements can have states other than the ones natively supported by the browser. e.g. custom checkbox implementation may supported, in addition to `:checked` and `:disabled`, `:state(implicitly-checked)` which indicates that the checkbox is marked due to other options made by the user. An editable list may have a state such as `:state(mutating)` during which the list item is actively being mutated by the user. Once we accepted that we do need a mechanism for JS to set a custom state on an element, then it's only natural to let the script update all the states instead of inventing separate / independent mechanism to do the same. Otherwise, we'd have to figure out how selector based approach & JS API interact, etc... -- GitHub Notification of comment by rniwa Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3431#issuecomment-460018469 using your GitHub account
Received on Sunday, 3 February 2019 02:56:31 UTC