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

Re: Shadow DOM: Hat and Cat -- if that's your real name.

From: Sylvain Galineau <galineau@adobe.com>
Date: Thu, 6 Feb 2014 19:36:31 +0000
To: Tab Atkins Jr. <jackalmage@gmail.com>
CC: Edward O'Connor <eoconnor@apple.com>, "<www-style@w3.org>" <www-style@w3.org>
Message-ID: <C298A8E5-4B3A-475F-AB96-E6AE4C2C80B7@adobe.com>

On Feb 6, 2014, at 10:56 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> On Wed, Feb 5, 2014 at 9:50 PM, Sylvain Galineau <galineau@adobe.com> wrote:
>> On Feb 5, 2014, at 6:34 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>>> On Tue, Feb 4, 2014 at 8:08 PM, Sylvain Galineau <galineau@adobe.com> wrote:
>>>> The issue is that you're not getting in the way of anyone deliberately hacking into components. Is there data suggesting deliberate styling of custom widgets is scarce?
>>> It's not scarce, but neither is it super-common.  :host()/:ancestor()
>>> let components offer their own themes, which luckily removes a lot of
>>> the need, but there are a signfiicant number of "structural"
>>> components in Polymer, Brick, et al that are intended to be fully
>>> styled by the developer instead.
>>> This is slightly misleading, though.  The major use-case for ^^ is to
>>> style all components of a certain type in the page - you're using a
>>> bunch of Polymer, and you want all the <polymer-button>s to look a
>>> particular way, regardless of whether you put them in your page or
>>> they're embedded deep in some component's shadow.  This *does* happen
>>> a lot in practice, at least in the apps we've looked at, and it's
>>> something that is *not* solved by any other approach so far.
>> ĎA lotí sounds misleading for something that doesnít exist except as a polyfill the actual usage of which is rather uncertain. Some pointers to those apps to back up your claims would be helpful.
> I'll have to defer to one of the Polymer folks on that.  I don't track
> the repo closely enough to be able to rattle off examples.
>>>>> If we try to be more restrictive *first*, it's extremely likely that
>>>>> we'll get things wrong, and people will have to hack around our silly
>>>>> limitations to achieve what they want.  I'd rather base the
>>>>> restrictive models on data from actual usage than guesses about what's
>>>>> good enough.  (And internal feedback from the Polymer team on our
>>>>> previous attempts at more restrictive models shows that it's very easy
>>>>> to get it wrong.)
>>>> There is some gap between 'we may get it wrong' and 'nothing at all'. I agree there is significant risk in over-thinking it; we can see some of that on this very thread: "An attribute won't do, what if people want to expose most elements in their shadow tree?'. Well, maybe a lowly attribute is a fine escape hatch to start with before moving on to more elaborate solutions derived from real-world feedback?
>>> It's not enough of an escape-hatch, as we've discovered.
>>> A major problem is that ::part is an attractive nuisance.  It *looks*
>>> great; even if you find some problems, it seems like they can be
>>> patched.  However, it almost always only looks that way as long as
>>> you're looking at things a *single* shadow tree deep.  As soon as you
>>> start composing shadows, using components in the shadows of other
>>> components, ::part starts creaking.  Further, components aren't only
>>> used for the "big" things in your page - it can make sense to design
>>> small components that just refactor parts of other components, and are
>>> only ever used locally within that single component.  You quickly
>>> build up way more nested trees than people naively imagine, and
>>> dealing with ::part() and nested stuff and forwarding and all that
>>> other crap suddenly becomes a *major* issue.
>>> We tried it. It doesn't work.  We're not really interested in trying
>>> it again; at least, not as a blocker.  We'd like to get stuff out in
>>> the wild so we can see how people outside of the Polymer dev team
>>> really use components, and *then* design restricted versions based on
>>> that knowledge.
>> ĎAs *we*íve discoveredí, Ď*We* tried ití: in case you havenít picked up on it by now, your confidence in your own thing doesnít cut the mustard. Please share the actual evidence this confidence is based on so the rest of us can draw our own conclusions?
> How would you like this data?  Charts? Graphs? Video interviews from
> usability-study participants?
> We thought of this, we specced it, we *implemented* it, and then had
> Polymer crank on it.  They reported back that it was too weak, and it
> got in their way too often.  This is real-world experience, reported
> in person.
> I'm not sure what other kind of data I could provide.  I'm also not
> sure why this standard of data is apparently inadequate; we regularly
> make decisions based on less.  (Not saying that's great, just
> complaining that you seem to be imposing an unrealistically high
> standard here.)  In particular, any alternate suggestions in this
> thread are based not on any experience at all, but just a very short
> period of thought without much experience of the feature as a whole.
> (That doesn't make them necessarily worse, but it does mean that any
> data-measuring contests are already biased.)

First, you request to lock down some bit of syntax that isnít even specified yet.
Second, the former derives from your intent to ship a platform feature despite a public lack of consensus on a rather fundamental design decision.

In such a context I think it should be obvious that appealing to your own authority is somewhat suboptimal and unlikely to result in ĎOh, OK then, if you say soí.

So assuming that:
1. You and your team have more experience in this area than everyone else,
2. The confidence of other vendors that Shadow DOM is ready to ship is significantly lower than you own,
3. You want to fix #2

Öthen resolving the issue is going to take substantially more than a variation on ítake my word for ití. There is a huge difference between making decisions with *some* data and making them with *no* data. Another way of saying it is that Iím not saying your conclusion is invalid, just that your data is invisible to me.

As for the form it can take, a good starting point would be a couple of realistic use-cases where a shadow tree that was closed down by default made things substantially harder. You get to pick Ďem so youíre welcome to pick the more spectacular one to make your case if that helps. Iíd rather get some biased data than none at all.

>>> Remember that the status quo is everything mixed together.  We're
>>> already winning a *ton* by setting up the shadow boundaries as they
>>> currently exist.
>>> Remember also that, while the status quo is terrible, it *also* kinda
>>> works.  Not well - we can make the world much better - but it's not a
>>> giant pit of failure either.  You can poke at everything in a jQuery
>>> component, but they still get updated/etc without too much pain.  When
>>> people break, they can choose to deal with it or just use an older
>>> version of the component.  The same applies to Web Components, except
>>> the *accidental* breakage should be effectively nil.
>> I agree with that; it does kind of work today. But this sort of cuts both ways. If jQuery plug-ins manage to update with little pain, this suggests hacking into custom widgets may be a limited-enough thing to allow us to lock things down and open up later.
> I don't see how it suggests that at all. You're jumping straight from
> "jQuery widgets can update okay" to "nobody ever pokes at the
> internals of a jQuery widget".  You're skipping at least three
> alternate explanations:
> 1. People poke at internals, but most of the time they do so in minor
> ways that doesn't cause breakage on upgrade.
> 2. People poke at internals enough to break things, but they fix their
> code when they update.
> 3. People poke at internals enough to break things, and then just stop
> updating when the breakage happens.
> (The last, in particular, is probably true by default in most cases,
> since the standard practice for using widgets is to download the
> scripts to your own server.  Updating is a manual process, which is a
> synonym for "basically never happens".)
> None of these three explanations imply that it should be okay to
> completely prevent poking around.

Yes, Iíll accept that. It sounds like we donít really know for sure and Shadow DOM has no impact on existing widgets anyhow.

>>>> So while I sympathize with your concern, my fear of picking a default we'll sorely regret later overrides it. I'd rather go the other way and start with full encapsulation; then validate various options to relax the model based on the real-world experience.
>>> We know for a fact that full encapsulation is far too limiting in
>>> practice already.  We tried it for months, then we relaxed it with a
>>> few variants of ::part(), then we relaxed it further with ^ and ^^,
>>> and that was finally enough to do useful work with.
>> Since I have no context on what was tried for months, by whom, how many times, and for what, Ďwe know for a factí is not something Iím able to agree or disagree with in any way. Data, please.
> I'm sorry that you feel the need to doubt me in this particular
> instance, when we're nearly always willing to trust WG members when
> they give implementation feedback.  I'm not sure what I did to provoke
> this level of distrust, but there's not much I can do about it.

Not only am I willing to believe you, when it comes to Shadow DOM I *want* to. For all the silly memes Iíve committed I actually believe in the damn thing and, if you go back, did so from day one. But I also believe this is a fundamental enough change for the platform that some level of cross-browser consensus is far more important to success than it is for, say, will-change. I also believe the bar I and the rest of the WG should set for agreeing on making encapsulation loose by default should be far higher than itíd be for us to agree to your saying Ďwe tried a number of formulas for this new type of gradient and the best looking was this oneí. Does that make sense?

So yes, weíve agreed to make decisions with little data in the past. Itís just that some decisions deserve far more scrutiny than others.

>>> Many cases don't need all that power, and could be served by a less
>>> powerful piercing mechanism.  But *enough* cases need the full power
>>> that it would be harmful to the feature, I believe, to prevent them
>>> from getting it.  Let's do the least magical thing now, and focus on
>>> figuring out more carefully constructed things when we have data.
>> Then please elaborate on those cases that need it; all Iím reading here are conclusions without any of the actual evidence that led to them. Itís quite likely theyíre sound conclusions. But since youíve working in the open it should be easy to reach their source. Any pointers?
> I did elaborate, at the beginning of my previous email.  You responded
> that my statements seemed misleading, and that you don't trust my
> conclusions.

Yes, itís safe to say the general context of this thread has somewhat eroded trust, though the tone of my comments probably suggested a lot more distrust than I intended. But even if this entire exchange hadnít occurred, we have at least one major browser vendor questioning this specific design decision; as such I think it is entirely reasonable to expect you to back up your conclusions with some supporting evidence. Again, I am absolutely not asking for a white paper or a legal discovery of all the Polymer teamís email. But I would want you to provide the detailed use-cases that you believe best support what you have agreed to be a fundamental design choice.

I also suggest starting another threadÖThanks.
Received on Thursday, 6 February 2014 19:37:21 UTC

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