-
Notifications
You must be signed in to change notification settings - Fork 49
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.
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
Alternative style encapsulation technique to iframe/shadow dom #149
Comments
+1 for the shadow DOM. Iframes are a thing of the past, imo. |
@mik01aj, it's just I'm a bit concerned about Shadow DOM stability and browser support. Need to investigate. |
Well, it is not directly supported in IE, Firefox and Safari, but it's polyfillable with Polymer's webcompoents.js. See also webcomponents.org for details. |
@mik01aj, unfortunately Shadow DOM polyfills are not covering CSS encapsulation. It's decided that we will start off with Shadow DOM plugin + scoped styles for Firefox as a fallback. And because of Safari and IE not supporting neither of mentioned standards, in v.0.7 I'm planning to use an alternative encapsulation path as a default solution. Using PostCSS processing and CSS |
First experimental Shadow DOM plugin version is now available https://github.com/sourcejs/sourcejs-shadow-dom. Until decent browser-support, we can't use Shadow DOM in core. |
I'll pitch in with an idea I have using iframe[srcdoc]. Sadly, this is not yet supported in IE or edge. Other modern browsers do: If you like this feature to come to Edge you can vote for the Edge development team to put it higher on their priority list status vote @mik01aj iframes may be a thing of the past, but they are the only way of encapsulating everything including media-queries. Though with encapsulation also comes challenges.. Expect an PR or new plugin to merge at some point in the near future. What's your thought on this @operatino : plugin or core? |
yup, I have to say I changed my mind about iframes. :) |
@ndelangen let's start with a plugin, since a question of sharing JS with iframe examples is still not solved. If the solution work smooth, we can think about adding it into a core, but IE11/Edge support still could be an issue preventing that. In Clarify, I parse all the |
@ndelangen here's a interesting UI idea for changing the sizes of tested component |
Spec pages with
source_example
sandboxes are built in such way that SourceJS engine scope should not touch interfere with global CSS and JS. With CSS it's achieved thanks to complex mixins, that resets all global CSS and re-apply local, without touching.source_example > *
, and JS will be totally hidden behind single JS object in 0.6.The best way to encapsulate components and SourceJS UI is to use iframes or shadow DOM (which we already planned to investigate #80), but I'm afraid this techniques could affect performance, since Shadow Dom could be done only client side, and iframes have various limitation.
I'm proposing an alternative way instead of complex LESS mixins for managing CSS - we can process all the simple tags on the server, adding custom classes like
.sourcejs_tag-p
. This will allow to remove a lot of hacks for styling SourceJS UI and help to reduce the complexity of custom theming.We still should investigate solution with Shadow DOM encapsulation, at least in experimental or plugin mode. But if it won't be stable enough, we should go for tag classes processing approach.
We're planning a redesign around v.0.7, and style encapsulation refactoring most likely will be the main feature of upcoming version.
The text was updated successfully, but these errors were encountered: