/deep/ and ::shadow becoming deprecated?


#1

(not sure which category this belongs in)

I was using chrome’s canary, when I started seeing a deprecation warning in the console for ‘/deep/’.

I followed the link to:
https://www.chromestatus.com/features/6750456638341120

and then I left a comment on:
https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/68qSZM5QMRQ/pT2YCqZSomAJ

Is this currently being addressed? I think maybe if we make enough fuss we can stop this from being unsupported.

It seems absolutely critical for Atom dev, particularly package dev. The whole beauty of Shadow dom IMO was that you it would prevent accidental collisions, but not prevent intentional ones. The shadow dom 101, 201, 301 article (forgot which one) stated clearly, it’s not in place for security, and to limit what you can do.

Am I misunderstanding this? It really sounds like they just want to get rid of the selector altogether?


#2

Other than styling TextEditor elements from the styles.less, I don’t think this is a issue … if I’m understanding things correctly.

  1. There are already issues with some style support from the styles.less, aside from the selectors you mention. See: https://github.com/atom/atom/issues/4590. The solution is to extend #2 below to styles.less.
  2. Packages already support *.atom-text-editor.less for loading style sheets inside the shadow DOM, obviating the need for the selectors. See the documentation for context-targeted stylesheets.

So, there is already a recommended approach … with the one caveat that styles.less needs to be extended to support it.


#3

Yeah, I guess they’re not critical. I already went through the exercise using the new conventions to get rid of the selectors.

Hmm, I guess we don’t need them. But how will nested (composed) custom elements (or I should say shadow doms) work?


#4

I’m not sure what you mean by nested shadow DOMs. Are you worried that some design at some point will have shadow DOMs inside shadow DOMs?


#5

That’s definitely going to happen. Using a component inside a component is needed for proper component architecture. I’m using components with VueJS in a project now and I have components nested four deep so far.


#6

According to the documentation, you can name something *.foo-element.less and it will get loaded inside foo-element tags. I haven’t tried it out, but that’s the intention.


#7

A little confused. Let’s say p1 and p2 are packages. A and B are child parent shadow doms.

Atom ->
   p1a ->
      p1b
   p2

Can package 2 access p1b?

I really think it should be able to. Originally in the shadow dom 101,201,301 articles they made it sound like, it’s not there for security, but to prevent accidental changes. We should be able to cut through for cross cutting concerns IMO. For accessibility / styling, data grabbing, lots of reasons.

Apparently a lot of the new Polymer stuff for example has some ways to do this. I have to catch up, but in some of the related threads, I saw things like “users are creating their own recursive crawlers” That would not be fun. I’d prefer native selectors for either or both css and javascript’s querySelector(). Having to do p1a.shadowRoot.querySelector(‘p1b’).shadowRoot is no fun.

I think there are new techniques I’m just not aware of though.


#8

I think it’s kind of important to remember, that one of the awesome parts of web / browser tech, is that javascript can run at the end, and get everything (pretty much) because it’s all DOM. That was the main appeal of Atom for me originally.

As long as an a package author knows DOM manipulation, they should be good.

(I get it we use models that have views (now custom elements), and there’s a lot more domain specific knowledge to the editor, editors in general…)

Ok but, ultimately it’s still important to make sure everything is customizable / accessible (at least through code, not talking feature creep here). I guess I’m drawing a parallel to the the same domain access paradigm that exists in the web. Now we have some custom elements which kind of throw in a wrench, but up until now we had ways to pierce through as long as we were granted access as the owners.

As for Atom, is there talk of providing security boundaries between packages? For most purposes I’d imagine the running Atom should employ a similar paradigm of trust between the user installed extensions. I could see some cases for lock down, or preventing writes, but preventing reads on anything in the editor be it another package or native Atom custom element would be a show stopper right? I’m not saying we have this problem today at all, just kind of curious the thoughts.

For example I have never tried to say watch for and modify another author’s package, just Atom built ins. I do think I should be able to though.


#9

Discussion about Atom’s security model:

And here:


#10

I talked with one of the Chromium developers (just now) at CodeConf about this and have asked him to come talk about what is happening and why. I hope this will help everyone understand what’s going on.


#11

That sounds awesome.