You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on May 29, 2019. It is now read-only.
Copy file name to clipboardExpand all lines: docs/polymer/styling.md
+23-30
Original file line number
Diff line number
Diff line change
@@ -92,44 +92,37 @@ CSS selectors to give you more control on how style rules are shimmed.
92
92
### polyfill-next-selector {#at-polyfill}
93
93
94
94
The `polyfill-next-selector` selector is used to replace a native CSS selector with one that
95
-
will work under the polyfill. For example, targeting distributed nodes using `::content` only works under native Shadow DOM. Instead, you can tell {{site.project_title}} to replace said
96
-
rules with ones compatible with the polyfill.
95
+
will work under the polyfill.
97
96
98
97
To replace native CSS style rules, place `polyfill-next-selector {}` above the
99
98
selector you need to polyfill. Inside of `polyfill-next-selector`, add a
100
-
`content` property. Its value should be a CSS selector that is roughly equivalent
101
-
the native rule. {{site.project_title}} will use this value to shim the native selector. For example:
99
+
`content` property. Its value should be a CSS selector that is roughly equivalent to
100
+
the native rule. {{site.project_title}} will use this value to shim the native selector.
For example, in earlier versions of {{site.project_title}} targeting distributed nodes using `::content` only worked under the native Shadow DOM. This is no longer the case and in polyfilled browsers the `::content` elements will be removed. Under the polyfill, the following selector:
Under native Shadow DOM nothing changes. Under the polyfill, the native selector
119
-
is replaced with the one defined in its `polyfill-next-selector` predecessor. The previous
120
-
examples would be shimmed into:
108
+
Becomes:
121
109
122
-
x-foo .bar {
110
+
.foo .bar {
123
111
color: red;
124
112
}
125
-
126
-
x-foo > .bar {
127
-
color: blue;
128
-
}
129
113
130
-
x-foo .container > * {
131
-
border: 1px solid black;
132
-
}
114
+
This means you only need `polyfill-next selector` when doing something that would not work if `::content` were removed.
115
+
116
+
For example: `::content > *` will not work in a polyfilled browser because `> *` is not a valid selector. This selector could be rewritten as follows:
117
+
118
+
::content > * { }
119
+
120
+
or as:
121
+
122
+
polyfill-next-selector { content: '> *' }
123
+
::content > * { }
124
+
125
+
Under native Shadow DOM nothing changes. Under the polyfill, the native selector is replaced with the one defined in its `polyfill-next-selector` predecessor.
133
126
134
127
### polyfill-rule {#at-polyfill-rule}
135
128
@@ -154,7 +147,7 @@ The previous examples become:
154
147
x-foo .bar {
155
148
background: red;
156
149
}
157
-
150
+
158
151
x-foo.foo .bar {
159
152
background: blue;
160
153
}
@@ -181,7 +174,7 @@ You should only need `polyfill-unscoped-rule` in rare cases. {{site.project_titl
181
174
182
175
According to CSS spec, certain @-rules like `@keyframe` and `@font-face`
183
176
cannot be defined in a `<style scoped>`. Therefore, they will not work in Shadow DOM.
184
-
Instead, you'll need to declare their definitions outside the element.
177
+
Instead, you'll need to declare their definitions outside the element.
185
178
186
179
Stylesheets and `<style>` elements in an HTML import are included in the main document automatically:
187
180
@@ -287,7 +280,7 @@ of the scoping behavior.
287
280
Because polyfilling the styling behaviors of Shadow DOM is difficult, {{site.project_title}}
288
281
has opted to favor practicality and performance over correctness. For example,
289
282
the polyfill's do not protect Shadow DOM elements against document level CSS.
290
-
283
+
291
284
When {{site.project_title}} processes element definitions, it looks for `<style>` elements
292
285
and stylesheets. It removes these from the custom element's Shadow DOM `<template>`, rejiggers them according to the rules below, and appends a `<style>` element to the main document with the reformulated rules.
0 commit comments