- From: Maciej Stachowiak <mjs@apple.com>
- Date: Fri, 07 Feb 2014 13:07:03 -0800
- To: James Ross <james@james-ross.co.uk>
- Cc: Daniel Buchner <daniel@mozilla.com>, www-style list <www-style@w3.org>, Tab Atkins <tabatkins@google.com>, Dimitri Glazkov <dglazkov@google.com>, Alex Russell <slightlyoff@google.com>, David Baron <dbaron@mozilla.com>, Potch <potch@mozilla.com>, Angelina Fabbro <angelina@mozilla.com>, Scott Miles <sjmiles@google.com>
On Feb 7, 2014, at 12:52 PM, James Ross <james@james-ross.co.uk> wrote: > From: mjs@apple.com > Date: Fri, 7 Feb 2014 12:16:23 -0800 > >> 1) You did not address one of the biggest negatives of both 2 and 3: it locks in the shadow DOM structure of a component as part of the component's API contract, making it impossible to ever change it without breaking compatibility once a component is published. If a component consumer can use arbitrary selector paths into the component, and this is in fact the only API for styling parts of the component that is offered, then it is impossible for even a conscientious component consumer to avoid depending on details of the shadow DOM structure. Can you address this? Are we ok with components being locked into their exact shadow DOM structure forever? > > How about recommending that component authors provide classes on parts/elements they expect (or find from experience) to most commonly need external styling? As far as I can see, it needs nothing beyond the shadow-piercing combinator, and you could do something like: > > super-control ^ .text-label > > To select a specific part of a component. That would be an improvement over no convention. This is using "^ ." as a rough equivalent to a "::"-based part syntax. However, it still has some disadvantages: - Components may want some elements to have classes for purely internal use of the component. With this approach, you mix your chosen styling hooks with internal-use classes in the same namespace. - It's not design-wise compatible with some components closing down their shadow DOM and exposing *only* named parts. - It's not clear what selectors you can use besides just the named classes, so it's very easy to depend unintentionally on other parts of the structure. However, this brings up another possibility. What if we designated "/token" to be a named part combinator (where "token") can be any string? Then we could have the following: - "/shadow" or "/root" could provide styling access to the full shadow DOM for open components (allowing the possibility that it does not match anything for closed components, once those are supported). - "/whatever" could access a component's named part called "/whatever". We can use one of the many alternatives discussed for exposing an element or subtree of a component as a named part. - Built-in elements with styleable sub-parts could also expose named parts instead of pseudo-elements, thus making them consistent with components and allowing shadow DOM to explain the styleable sub-part aspect of many built-in form controls (currently not standardized but de facto present in most/all browser engines). Regards, Maciej
Received on Friday, 7 February 2014 21:07:34 UTC