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

On Feb 7, 2014, at 9:43 AM, Daniel Buchner <daniel@mozilla.com> wrote:

> 
> Sure it's a tad long - but you're a champ, you'll deal.
> 
> Yesterday a group of folks from this thread convened for a face-to-face meeting. I'd like to summarize the discussion, review our options, and present why I believe the proposal we zeroed in on during our meeting is the correct one:

Is the set of individuals this is addressed to the set of people who met? I am not sure how they are "from this thread" as most of them have not posted about the recent shadow dom styling threads (unless by "this thread" you mean the one started by this email).


> 
> 2) Hats ^, and cats ^^, and bears - oh my!
> 
> Cat-hats are on the right track. This idea turns (correctly) toward a more open and permissive model. Moving to a known combinator allows component consumers to explicitly, with intention, style anything in the Shadow DOM. This means component consumers are no longer left to hope that authors provide the styling hooks they need. It also removes the need to litter CSS code with shadow element tokens. In addition, component consumers are still able to style shadowed elements in a more familiar way. Awesome, problem solved!...close, but no cigar. Here's what this option leaves to be desired:
> It introduces YAACs (Yet Another ASCII Character) - pretty soon we'll need a periodic table to remember them all
> YAACs are as good as klingon to novice developers - shouldn't we be more obvious if we can?
> Assessment: this proposal is pretty darn close - it allows the use of familiar looking selectors, it's predictable once you understand the combinator, and symmetrical to the JS DOM encapsulation paradigm.
> 
> Example: x-foo ^ div
> 
> 
> 3) /shadow games FTW!
> 
> An extensible combinator is the gift that keeps on giving. With an extensible combinator (ex: / + a token) we can define tokens like shadow, and shadow-all, to enable the styling of shadowed elements. The best part is we can introduce other tokens in the future without YAACing on our shoes. This proposal brings with it all the positives that hat-wearing cats deliver, without the downside of two new, non-obvious, ASCII combinators that are hard-bound to a specific DOM API. The only negative I can think of currently:
> /shadow is longer than ^
> Assessment: this proposal hits on all cylinders - it allows users to write familiar selectors without knowing one-off token names, provides a predictable flow for shadow element styling, and is symmetrical to the JS DOM encapsulation paradigm.
> 
> Example: x-foo /shadow div
> 
> -----
> 
> Tab is working on a draft for the extensible combinator proposal as we speak - in the meantime, any thoughts?

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?

2) It's not clear to me why one new construct counts as "familiar" but another does not. Can you explain?

3) All of these assessments assume that the JS DOM provides weak encapsulation as the only option. However, as far as I can tell, that is not a decision of the Web Apps WG, it is merely what the spec editors have chosen to do (in the face of contradictory feedback, and notwithstanding agreement by the editors to support both). Taking that as precedent for the conversation does not make sense to me.

Regards,
Maciej