Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Susy Debug Output and the Shadow Dom / Web Components #501

Open
kraftner opened this issue Jul 22, 2015 · 4 comments
Open

Susy Debug Output and the Shadow Dom / Web Components #501

kraftner opened this issue Jul 22, 2015 · 4 comments
Labels
syntax improvement v2

Comments

@kraftner
Copy link

I just noticed that the way the debug toggle works as a pseudo element of the <head> isn't working with the Shadow DOM.

I see multiple issues:

1.Toggle Trigger Missing

If Susy is used in a component the toggle trigger is created in the CSS inside the component and therefore doesn't get applied to the root DOMs <head> element. As there is no <head> element in the component the toggle trigger doesn't exist at all.

2. CSS from the root DOM doesn't pierce into the Shadow DOM

As intended the Shadow DOM is encapsulated and ignores outside styles. The problem is that even if we had the trigger on the <head> of the root element it wouldn't affect anything inside the components.

Thoughts

I see two approaches:

Either we add another trigger inside each component not attached to the <head> but to some other element. This keeps stuff encapsulated inside the component, but will create a lot of triggers at various places which is kind of messy.

The other approach is to somehow trigger even inside the Shadow DOM. As far as I know there is no way to affect the root DOM via CSS inside the component. This would also contradict the general flow of CSS where you can never select "up". So you need to manually create the trigger in the root document. So the usual CSS needs to be amended using the /deep/ (or >>> in the more recent not yet implemented draft) combinator roughly in this way:

head:hover ~ body /deep/ .in-shadow-dom {
  position: relative;
  &:before {
    @include grid-overlay-base;
    @include background-grid();
  }
}

Here is a link to a working example.

If this was incorporated in the overlay-grid mixin it would make things a bit easier, but I'm not sure if this should be a default as piercing in the Shadow DOM may be unexpected by a lot of people. Maybe just make it optional?

Finally I can also see how you might see all these issues as an edge case Susy shouldn't bother with at all. To show that I am not just theorizing here I just want to quickly talk about my real world use case:

I use the SC5 Styleguide Generator which encapsulates examples in Shadow DOM elements. I'd love to be able to see the grid in there, but unfortunately this doesn't work.

Looking forward to your thoughts. 😄
@mirisuzanne
Copy link
Member

I think this is a problem best solved outside of Susy. The real problem isn't that it's an edge case, but that we're getting too dependent on knowledge of the DOM. I'm already skeptical of the DOM antics needed for debug-overlay (your issue reinforces that skepticism), and I'm hesitant to take that even further. I'd rather give you the basics (in this case a grid background generator) and let you apply it to your situation (in this case the shadow dom) however you see fit.

For example, I'm never going to add JS to Susy, but you could probably solve your problem easily with a little bit of JS written specifically for your site. Inject a trigger anywhere you want, and tell it exactly what elements should have grid backgrounds applied. Make a class that shows the grid, and toggle that class wherever you want it. We'll never be able to write a universal sass-only mixin with that kind of flexibility.

@kraftner
Copy link
Author

First of all thanks for the fast reaction. I think you're spot on - this is probably nothing Susy should be solving all on its own. Especially not using JS. That isn't what I was trying to achieve here at all.

As I've shown with the linked CodePen it is already somehow solvable right now. So yes, the way to go probably is to just offer the tools to solve this on your own.

In this spirit I and if we're looking at the overlay option I was wondering if you may consider making the selectors that are currently hardcoded inside overlay-grid configurable. But while thinking about it we're probably already entering the aforementioned non-Susy-territory 😉

Another idea: in container you're automatically calling show-grid. Would it be possible to globally store all containers in a map at that point? One could then use this to create all debug grids in any way needed. Be it a trigger on hover, a special body class that is only added by a CMS for admins or by JS. This would be pretty flexible without baking any assumptions directly into Susy.

I'm just thinking loud here. It would be great to have your thoughts on this.

@mirisuzanne
Copy link
Member

Good thoughts! I'll have to dig into them a bit more — or look at pull requests if you want to make some suggestions. At the very least, making more things configurable is always a positive in my book. :)

@kraftner
Copy link
Author

Cool! I just wanted to see if you're generally interested before getting my hands dirty with PRs and stuff. I'll look into it on the weekend. Until then thanks for the feedback and Susy in general.

@mirisuzanne mirisuzanne added the v2 label Sep 2, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
syntax improvement v2
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@mirisuzanne @kraftner