W3C home > Mailing lists > Public > www-style@w3.org > February 2014

Re: ::Parts of cats and hats everywhere, slashed by shadow

From: Daniel Buchner <daniel@mozilla.com>
Date: Fri, 7 Feb 2014 13:42:16 -0800
Message-ID: <CAHZ6zJEy0uJkv9qkyb3k7GgTts-MtF-y8x3M5daCwGznBVuNoQ@mail.gmail.com>
To: Brian Kardell <bkardell@gmail.com>
Cc: Maciej Stachowiak <mjs@apple.com>, James Ross <james@james-ross.co.uk>, 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>
Brian: Tab talked about providing a /shadow and /shadow-all <-- I believe
this provides the functionality you seek, correct?

- Daniel


On Fri, Feb 7, 2014 at 1:35 PM, Brian Kardell <bkardell@gmail.com> wrote:

>
>
>
> On Fri, Feb 7, 2014 at 4:07 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>
>>
>> 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
>>
>>
> In what you propose, would /shadow would work at one level only, or "all
> the way down"?
> Also would /whatever's be exposed via their parents?
>
> In my document, I'd like to style the exposed x-bar across the site... can
> I? How?  I think somehow we need illustrations of tree constructions and
> selector use cases to explain what we think should be accomplishable.. I'm
> not entirely sure how to do that...
>
> In other words given some structure like below in which your document
> contains an <x-foo> which exposes an x-bar (I'm using a pipe to
> differentiate something exposed below and parens to indicate something
> hidden, because... how can you draw this in ascii):
>
> <div>
>     <x-foo>
>         |x-bar|
>             <x-foo>
>                  |x-bar|
>         (x-you-cant-see-me)
>              <x-foo>
>                  |x-bar|
>
>
> As an author of CSS, I'd like to style the exposed x-bar across the
> site... can I?
> Can you show some examples of /shadow && /whatever with some kind of
> tree-like explanation to show what they accomplish?
>
>
> --
> Brian Kardell :: @briankardell :: hitchjs.com
>
>
> PS - Sylvan, drink up.
>
Received on Friday, 7 February 2014 21:43:15 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:19 UTC