Re: [w3c/webcomponents] observedStyles (#856)

> Not sure what you mean by "extremely compelling reason", in what other way can we design custom elements that responds to style changes? That by itself should be reason enough.

That’s not a use care. That presumes the need to define the orientation of a component in CSS. A use case would depict a concrete scenario like building a calendar widget which poses a problem, not a need for a particular solution.

For example, a concrete use case for a mode of transportation goes like: I’d like to live near a coast line but want to work in downtown, which is 20km away, and I’d like my commute to be less than 30 minutes. A particular solution to this problem might be laying out more public transportation, or have the person a buy a motorized vehicles; but the use case didn’t define or allude to any particular solution.

> There is already the possibility to observe changes in the style attribute via mutation observer and that is also quite slow, I would think that monitor just one or two styles by adding them like we do with observedAttributes() should be faster than that.

MutationObserver observes content attribute change to a DOM element, not its computed or used style; the letter is way more expensive to compute because we’d have to match & apply all rules that apply to any given element and its ancestors for inheritance. There is no way we can do this sync. Remembering what the obvious style of an element was is also quite expensive. We very carefully avoid having that kind of infrastructure in WebKit right now.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/856#issuecomment-557944095