Custom elements stuck to unresolved pseudo class if registered late
Reported by
daniel.x...@googlemail.com,
Oct 25 2016
|
||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.71 Safari/537.36 Steps to reproduce the problem: 1. Define a CSS rule for the unresolved pseudo class. 2. Use a custom element in the document's body. 3. Define the custom element later (by timeout, user action, async call, ...). What is the expected behavior? The custom element should not be styled according to the CSS rule using the :unresolved selector after it has been defined. What went wrong? When the custom element gets connected content and style changes implemented in the connectedCallback are applied. However it is still selected by the :unresolved pseudo class. Custom elements that are defined immediately (before occuring in the body) work properly. Did this work before? N/A Does this work in other browsers? N/A Chrome version: 54.0.2840.71 Channel: stable OS Version: 6.2 (Windows 8) Flash Version:
,
Oct 26 2016
Tested in chrome stable #54.0.2840.71 and canary #56.0.2900.0 on Win 10.0 able to reproduce the issue. Below are the Bisect Details: Bisect Info: ============= Good Build: 54.0.2839.0(Revision- 414243) Bad Build: 54.0.2840.0(Revision- 414607) Bisect URL: =========== You are probably looking for a change made after 414394 (known good), but no later than 414395 (first known bad). CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/f56ab5d893d9c1ff735136d8df7d738b16634a7a..ed691cd596251a924dafddd9e7402f8259fe1167 From the CL above, assigning the issue to the concern owner @ kochi : ------------------ Could you please look into the issue, pardon me if it has nothing to do with your changes and if possible please assign it to concern owner. Review-Url: https://codereview.chromium.org/2274883004 Note : Able to reproduce the issue in linux ubuntu 14.04 and MAC 10.12.
,
Oct 27 2016
The change is about flipping the flag to enable Custom Elements v1, so the demo just started to work (windows.customElements.define). @daniel.x.ziegler In the v1 custom elements, ":defined" CSS pseudo class should be used. https://developers.google.com/web/fundamentals/getting-started/primers/customelements So for matching for unresolved (in v0 terminology) custom elements, you should use ":not(:defined)". Does it resolve your case?
,
Oct 27 2016
I think this is working as intended. :unresolved is part of the old draft of the custom elements spec and doesn't depend on what customElements.define does. Use :defined and :not(:defined) instead.
,
Oct 27 2016
Thank you for your hints regarding :defined and :not(:defined). Obviously I missed that change. You are right, if using v0 (:unresolved and document.registerElement) or v1 (:defined and window.customElements.define) consistently everything works as expected. However I wonder if people might be confused of the somehow inconsistend behaviour when mixing things up as long as v0 and v1 implementations are available in parallel. 2016-10-27 8:12 GMT+02:00 domin… via monorail < monorail+v2.1966858889@chromium.org>:
,
Oct 31 2016
Yes, I agree it is confusing. We could consider making :unresolved mean something similar to :not(:defined) although they don't line up perfectly. We would probably only pursue that if it helps people transition from document.registerElement to customElements.define. In the long run we plan to remove document.register and :unresolved, so in the end state there should be no confusion. |
||||
►
Sign in to add a comment |
||||
Comment 1 by ligim...@chromium.org
, Oct 25 2016