Browser 26 \|	Timeout 27 \|	Fallback 28 \|	Swap 29 \|
Chrome 35+ 32 \|	3 seconds 33 \|	yes 34 \|	yes 35 \|
Opera 37 \|	3 seconds 38 \|	yes 39 \|	yes 40 \|
Firefox 42 \|	3 seconds 43 \|	yes 44 \|	yes 45 \|
Internet Explorer 47 \|	0 seconds 48 \|	yes 49 \|	yes 50 \|
Safari 52 \|	3 seconds 53 \|	yes 54 \|	yes 55 \|

296 | For example, the following nestings are valid: 297 | 298 |

299 | 		.foo {
300 | 			color: red;
301 | 			@nest & > .bar {
302 | 				color: blue;
303 | 			}
304 | 		}
305 | 		/* equivalent to
306 | 		   .foo { color: red; }
307 | 		   .foo > .bar { color: blue; }
308 | 		 */
309 | 
310 | 		.foo {
311 | 			color: red;
312 | 			@nest .parent & {
313 | 				color: blue;
314 | 			}
315 | 		}
316 | 		/* equivalent to
317 | 		   .foo { color: red; }
318 | 		   .parent .foo { color: blue; }
319 | 		 */
320 | 
321 | 		.foo {
322 | 			color: red;
323 | 			@nest :not(&) {
324 | 				color: blue;
325 | 			}
326 | 		}
327 | 		/* equivalent to
328 | 		   .foo { color: red; }
329 | 		   :not(.foo) { color: blue; }
330 | 		 */
331 |

332 | 333 | But the following are invalid: 334 | 335 |

336 | 		.foo {
337 | 			color: red;
338 | 			@nest .bar {
339 | 				color: blue;
340 | 			}
341 | 		}
342 | 		/* Invalid because there's no nesting selector */
343 | 
344 | 		.foo {
345 | 			color: red;
346 | 			@nest & .bar, .baz {
347 | 				color: blue;
348 | 			}
349 | 		}
350 | 		/* Invalid because not all selectors in the list
351 | 		   contain a nesting selector */
352 |

353 | 354 | Mixing Nesting Rules and Declarations {#mixing} 355 | ----------------------------------------------- 356 | 357 | A style rule can have any number of nested style rules inside of it, 358 | of either type, 359 | intermixed with any number of declarations, 360 | in any order. 361 | 362 | The relative ordering of nested style rules and other declarations is important; 363 | it's possible for a given style rule and a nested style rule within it to match the same element, 364 | and if the specificity of the two rules is otherwise equivalent, 365 | the relative order in the stylesheet of the applicable declarations 366 | determines which declaration "wins" the cascade. 367 | 368 | 369 | CSS Object Model Modifications {#cssom} 370 | ======================================= 371 | 372 |

373 | 1. Add an interface for the @nest rule. 374 | 2. Tie into the general work needed to let rules be nested into style rules. 375 |

376 | -------------------------------------------------------------------------------- /css-shadow-parts/index.bs: -------------------------------------------------------------------------------- 1 |

  2 | Title: CSS Shadow Parts
  3 | Shortname: css-shadow-parts
  4 | Level: 1
  5 | Group: CSSWG
  6 | Status: UD
  7 | Work Status: exploring
  8 | URL: http://tabatkins.github.io/specs/css-shadow-parts/
  9 | Editor: Tab Atkins-Bittner, Google, http://xanthir.com/contact/
 10 | Abstract: This specification defines the ''::part()'' and ''::theme()'' pseudo-elements on shadow hosts, allowing shadow hosts to selectively expose chosen elements from their shadow tree to the outside page for styling purposes.
 11 | Warning: replaced by https://drafts.csswg.org/css-shadow-parts/
 12 |

13 | 14 |

 15 | spec:selectors-4;
 16 |     type:selector; text::hover
 17 |     type:dfn; text:live profile
 18 |     type:dfn; text:structural pseudo-class
 19 | spec:dom; type:dfn; for:/; text:shadow root
 20 |

21 | 22 | Introduction {#intro} 23 | ===================== 24 | 25 | Issue: This spec is intentionally a rough sketch at the moment. 26 | It should contain all the details necessary to evaluate the proposal, 27 | but is intentionally avoiding precise algorithms at the moment, 28 | to aid in easy comprehension 29 | and to, hopefully, discourage implementation from this sketch. 30 | 31 | Shadow DOM allows authors to separate their page into "components", 32 | subtrees of markup whose details are only relevant to the component itself, 33 | not the outside page. 34 | This reduces the chance of a style meant for one part of the page 35 | accidentally over-applying and making a different part of the page look wrong. 36 | However, this styling barrier also makes it harder for a page to interact with its components 37 | when it actually wants to do so. 38 | 39 | This specification defines the ''::part()'' and ''::theme()'' pseudo-elements, 40 | which allow an author to style specific, purposely exposed elements in a shadow tree 41 | from the outside page's context. 42 | In combination with custom properties, 43 | which let the outside page pass particular values 44 | (such as theme colors) 45 | into the component for it to do with as it will, 46 | these pseudo-elements allow components and the outside page 47 | to interact in safe, powerful ways, 48 | maintaining encapsulation 49 | without surrending all control. 50 | 51 | Motivation {#motivation} 52 | ------------------------ 53 | 54 | For obvious reasons, 55 | it's valuable to let the outside page style the internals of a shadow tree, 56 | at least in some limited ways. 57 | (The ubiquity of UA-specific pseudo-elements for the various input elements shows this.) 58 | 59 | The previous proposed method for doing so, 60 | the >>> combinator, 61 | turned out to be too powerful for its own good; 62 | it exposed too much of a component's internal structure to scrutiny, 63 | defeating some of the encapsulation benefits that using Shadow DOM brings. 64 | For this, 65 | and other performance-related reasons, 66 | the >>> combinator was eventually removed from the live profile. 67 | 68 | This left us with using custom properties as the only way to style into a shadow tree: 69 | the component would advertise that it uses certain custom properties to style its internals, 70 | and the outer page could then set those properties as it wished on the shadow host, 71 | letting inheritance push the values down to where they were needed. 72 | This works very well for many simple theming use-cases. 73 | 74 | However, there are some cases where this falls down. 75 | If a component wishes to allow arbitrary styling of something in its shadow tree, 76 | the only way to do so is to define hundreds of custom properties 77 | (one per CSS property they wish to allow control of), 78 | which is obviously ridiculous 79 | for both usability and performance reasons. 80 | The situation is compounded if authors wish to style the component differently 81 | based on pseudo-classes like '':hover''; 82 | the component needs to duplicate the custom properties used 83 | for each pseudo-class 84 | (and each combination, 85 | like '':hover:focus'', 86 | resulting in a combinatorial explosion). 87 | This makes the usability and performance problems even worse. 88 | 89 | We introduce ''::part()'' to handle this case much more elegantly and performantly. 90 | Rather than bundling everything into custom property names, 91 | the functionality lives in selectors and style rule syntax, 92 | like it's meant to. 93 | This is far more usable for both component authors 94 | and component users, 95 | should have much better performance, 96 | and allows for better encapsulation/API surface. 97 | 98 | Another interesting facet of using custom properties, 99 | however, 100 | is that inheritance doesn't stop at the first shadow tree. 101 | Unless explicitly blocked, 102 | a custom property inherits down thru nested trees, 103 | allowing authors to style deeply nested components 104 | as easily as they style directly-visible ones. 105 | The same considerations apply to this case, 106 | so we introduce ''::theme()'' to handle this. 107 | 108 | It's important to note that ''::part()'' and ''::theme()'' 109 | offer absolutely zero new theoretical power. 110 | They are not a rehash of the ''>>>'' combinator, 111 | they're simply a more convenient and consistent syntax 112 | for something authors can already do with custom properties. 113 | By separating out the explicitly "published" parts of an element 114 | (the shadow part map 115 | from the sub-parts that it merely happens to contain 116 | (the shadow theme map, 117 | it also helps with encapsulation, 118 | as authors can use ''::part()'' without fear of accidental over-styling. 119 | 120 | 121 | Exposing a Shadow Element: the <{html-global/part}> attribute {#part-attr} 122 | ============================================================= 123 | 124 | Any element in a shadow tree can have a part attribute. 125 | This is used to expose the element outside the shadow tree, 126 | and to "forward" sub-parts of the element 127 | (if it has its own shadow tree) 128 | to outside the shadow tree. 129 | 130 | The part attribute is parsed as a comma-separated list of part mappings. 131 | Each part mapping is one of: 132 | 133 |

134 | : ident 135 | :: Adds «[ ident → el ]» to the shadow root's shadow part map. 136 | 137 | : ident1 => ident2 138 | :: If el is a shadow host, 139 | and it's shadow root's shadow part map |partMap| [=map/contains=] ident1, 140 | then this adds «[ ident2 → |partMap|[ident1] ]» to the shadow root's shadow part map. 141 | 142 | : * => prefix* 143 | :: If el is a shadow host, 144 | then [=map/for each=] |ident| → |subEl| in el's shadow root's shadow part map, 145 | «[ prefix + |ident| → |subEl| ]» is added to the shadow root's shadow part map. 146 | 147 | : anything else 148 | :: Ignored for error-recovery / future compat. 149 | 150 | 151 | Note: It's okay to give a part multiple names, 152 | or map a sub-part to several names. 153 | The "part name" should be considered similar to a class, 154 | not an id or tagname. 155 | 156 | Each shadow root has a shadow part map 157 | and a shadow theme map, 158 | both of which are ordered maps. 159 | 160 | The shadow part map contains all the entries described by the elements in its shadow tree, 161 | as described above. 162 | 163 | If the shadow root's {{ShadowRoot/mode}} is {{ShadowRootMode/"closed"}}, 164 | the shadow theme map is identical to the shadow part map. 165 | Otherwise, 166 | it's the concatenation of the shadow part map 167 | with the shadow theme maps of every shadow host's shadow root in its shadow tree. 168 | 169 | Issue: TODO: Define a syntax or new attribute 170 | to prevent an element from adding things to its shadow root's shadow theme map. 171 | 172 | Selecting a Shadow Element: the ''::part()'' and ''::theme()'' pseudo-elements {#part-theme} 173 | ============================================================================================ 174 | 175 | The ::part() and ::theme() pseudo-elements 176 | (collectively, the shadow-part pseudo-elements) 177 | allow you to select elements that have been exposed via a <{html-global/part}> attribute. 178 | The syntaxes of them are: 179 | 180 |

181 |     ::part() = ::part( <> )
182 |     ::theme() = ::theme( <> )
183 |

244 | -------------------------------------------------------------------------------- /css-stacking-context-1/index.bs: -------------------------------------------------------------------------------- 1 |

  2 | Title: CSS Stacking Context Module Level 1
  3 | Shortname: css-stacking-context
  4 | Level: 1
  5 | Status: UD
  6 | Group: csswg
  7 | ED: https://drafts.csswg.org/css-stacking-context/
  8 | Work Status: exploring
  9 | Editor: Tab Atkins-Bittner, Google, http://xanthir.com/contact/, w3cid 42199
 10 | Abstract: This module defines the painting model for CSS.
 11 |

12 | 13 | 30 | 31 |

 32 | spec: css-backgrounds-3; type:dfn;
 33 | 	text: background painting area
 34 | 	text: background positioning area
 35 | spec:css-break-4; type:dfn; text:fragment
 36 |

37 | 38 | Introduction {#intro} 39 | ===================== 40 | 41 | This section is not normative. 42 | 43 | Elements on a page can have many overlapping parts. 44 | This specification defines the precise order 45 | that every part of an element 46 | and the surrounding page 47 | is painted, 48 | so that things render above (or below) other things 49 | in a well-defined way. 50 | 51 | Painting Order {#order} 52 | ======================= 53 | 54 | The rendering structure of a document consists of 55 | a [=root canvas=], 56 | a [=document layer=] 57 | and any number of additional [=rendering layers=], 58 | and within each layer, 59 | a [=/list=] of one or more [=trees=] of [=CSS/boxes=] generated by [=CSS/elements=]. 60 | 61 | A canvas is a theoretically-infinite 2D field of color. 62 | The root canvas is the [=CSS/canvas=] 63 | upon which all of the document's content is rendered. 64 | Layers, and elements that generate stacking contexts, 65 | first render onto temporary [=CSS/canvases=] 66 | before being composited onto an ancestor canvas 67 | (ending with the [=root canvas=] for the document). 68 | 69 | A rendering layer 70 | is an ordered list of [=boxes=], 71 | where each layer is rendered fully atop all previous layers, 72 | and fully below all following layers. 73 | Within the layer, 74 | [=boxes=] and their descendants 75 | can potentially interweave their rendering with each other. 76 | The document layer is the layer 77 | containing the principal box of the document's root element; 78 | it is below all other [=rendering layers=]. 79 | 80 | In the following algorithms, 81 | a given box or fragment is only painted once, 82 | by whatever step attempts to paint it first. 83 | (This allows the algorithm to be written much simply, 84 | without elaborate guards to check against double-painting.) 85 | 86 | Issue: This is meant to be a reproduction and elaboration 87 | of the CSS2 "Elaborate Description of Stacking Contexts" algorithm, 88 | modified to account for where filter/clipping/compositing can happen, 89 | the existence of top layers, 90 | and the newer element/box/fragment hierarchy. 91 | Non-editorial changes beyond the above 92 | are unintentional and probably bugs. 93 | 94 | 95 |

96 | To paint a document: 97 | 98 | 1. If the document is being painted as part of another document 99 | (such as an <{iframe}>'s document), 100 | then the [=root canvas=] is initially [=transparent black=] everywhere. 101 | 102 | Otherwise, the [=root canvas=] is a UA-defined color everywhere. 103 | This can be affected by things such as, but not limited to, 104 | the 'color-scheme' property. 105 | 106 | Other specifications can define that the [=root canvas=] 107 | begins as another color in certain circumstances. 108 | 109 | 2. [=paint a layer|Paint the document layer=] onto the [=root canvas=]. 110 | 111 | 3. For each additional [=rendering layer=], in order from bottom to top, 112 | [=paint the layer=] onto the [=root canvas=]. 113 |

114 | 115 |

148 | 149 |

150 | To paint a stacking context with a [=box=] |box| onto a [=CSS/canvas=] |root canvas|: 151 | 152 | 1. Let |canvas| be a fresh [=CSS/canvas=], 153 | initially [=transparent black=] everywhere. 154 | 155 | 2. 156 |

157 | : If |box| is a [=block-level=] box other than a [=table wrapper box=] 158 | :: 159 | If |box| did not [=propagate its background=], 160 | paint |box|’s background color onto |canvas|, 161 | then background image. 162 | 163 | In all cases, 164 | then paint |box|’s border onto |canvas|. 165 | 166 | : If |box| if a [=block-level=] [=table wrapper box=]: 167 | :: Paint the following onto |canvas|, in order: 168 | 169 | 1. If |box| did not [=propagate its background=], 170 | paint |box|’s backgrounds 171 | (color, then image) 172 | onto |canvas|. 173 | 174 | 2. Paint |box|’s column group’s backgrounds 175 | (color, then image) 176 | onto |canvas|. 177 | 178 | 3. Paint |box|’s column’s backgrounds 179 | (color, then image) 180 | onto |canvas|. 181 | 182 | 4. Paint |box|’s row group’s backgrounds 183 | (color, then image) 184 | onto |canvas|. 185 | 186 | 5. Paint |box|’s row’s backgrounds 187 | (color, then image) 188 | onto |canvas|. 189 | 190 | 6. Paint |box|’s cell’s backgrounds 191 | (color, then image) 192 | onto |canvas|. 193 | 194 | 7. Paint all of |box|’s table borders 195 | (in tree order, for separated borders) 196 | onto |canvas|. 197 | 198 | Issue: I think this needs more detail, 199 | and I think [[CSS-TABLES-3]] provides it. 200 | 201 | 202 | 3. For each [=stacking context=] descendant of |box| 203 | with strictly negative z-indexes, 204 | in z-index order 205 | (most negative first), 206 | then tree order, 207 | [=paint a stacking context=] for the descendant 208 | onto |canvas|. 209 | 210 | 4. For each in-flow, 211 | non-[=positioned=], 212 | [=block-level=] 213 | descendant of |box|, 214 | in tree order: 215 | 216 |

217 | : If the descendant is not a [=table wrapper box=] 218 | :: Paint its background color, 219 | then background image, 220 | then border 221 | onto |canvas|. 222 | 223 | : If the descendant is a [=table wrapper box=] 224 | :: 225 | 1. Paint its backgrounds 226 | (color, then image) 227 | onto |canvas|. 228 | 229 | 2. Paint its column group’s backgrounds 230 | (color, then image) 231 | onto |canvas|. 232 | 233 | 3. Paint its column’s backgrounds 234 | (color, then image) 235 | onto |canvas|. 236 | 237 | 4. Paint its row group’s backgrounds 238 | (color, then image) 239 | onto |canvas|. 240 | 241 | 5. Paint its row’s backgrounds 242 | (color, then image) 243 | onto |canvas|. 244 | 245 | 6. Paint its cell’s backgrounds 246 | (color, then image) 247 | onto |canvas|. 248 | 249 | 7. Paint all of |box|’s table borders 250 | (in tree order, for separated borders) 251 | onto |canvas|. 252 | 253 | 254 | 5. For each non-[=positioned=], 255 | [=floating=] 256 | descendant |d| of |box|, 257 | in tree order, 258 | [=paint a stacking context=] from |d| onto |canvas|, 259 | skipping any positioned descendants of |d| 260 | and any descendants of |d| 261 | that actually create new stacking contexts. 262 | (They are, instead, painted 263 | as part of |box| in other steps.) 264 | 265 | 6. If |box| is [=inline-level=] 266 | and generates a [=stacking context=], 267 | then for each [=line box=] that |box| is in, 268 | [=paint an inline run=] from |box|’s [=fragments=] in that [=line box=] 269 | onto |canvas|. 270 | 271 | 7. Otherwise 272 | (if it did not match Step 6's condition), 273 | then first for |box|, 274 | then for all its [=in-flow=], 275 | non-[=positioned=], 276 | [=block-level=] descendants |d|, 277 | in tree order: 278 | 279 | 1. If |d| is a [=block-level=] [=replaced=] element, 280 | paint the replaced content onto |canvas|, 281 | atomically. 282 | 283 | 2. Otherwise, for each [=line box=] of |d|, 284 | for each [=box=] child of |d| that generates [=fragments=] 285 | in that [=line box=], 286 | [=paint an inline run=] from those [=fragments=] 287 | onto |canvas|. 288 | 289 | 3. Optionally, if |d| is [=block-level=], 290 | paint the outline of |d| onto |canvas|. 291 | 292 | 8. For each [=positioned=] descendant |d| of |box| 293 | with zero or ''z-index/auto'' z-index, 294 | in tree order, 295 | [=paint a stacking context=] for |d| 296 | onto |canvas|. 297 | If |d| is ''z-index: auto'', 298 | skip any positioned descendants of |d| 299 | and any descendants of |d| 300 | that actually create new stacking contexts. 301 | (They are, instead, painted 302 | as part of |box|.) 303 | 304 | 9. For each [=stacking context=] descendant of |box| 305 | with strictly positive z-indexes, 306 | in z-index order 307 | (least positive first), 308 | then tree order, 309 | [=paint a stacking context=] for the descendant 310 | onto |canvas|. 311 | 312 | 10. Filter/clip/etc here 313 | 314 | 11. Composite |canvas| onto |root canvas|. 315 |

316 | 317 |

318 | To paint an inline run 319 | of a list of [=fragments=] |frags| 320 | that are all in the same [=line box=], 321 | onto a [=CSS/canvas=] |canvas|: 322 | 323 | 1. For each [=fragment=] |frag| of |frags|: 324 | 325 | 1. Paint the background color, 326 | then background image, 327 | then border of |frag| 328 | onto |canvas|. 329 | 330 | 2.

402 | 403 | -------------------------------------------------------------------------------- /css-sticky-scrollbars/index.bs: -------------------------------------------------------------------------------- 1 |

 2 | Title: CSS Sticky Scrollbars
 3 | Shortname: css-sticky-scrollbars
 4 | Level: 1
 5 | Status: UD
 6 | Group: CSSWG
 7 | Work Status: abandoned
 8 | ED: http://tabatkins.github.io/css-sticky-scrollbars/
 9 | Editor: Tab Atkins, Google, http://xanthir.com/contact
10 | Abstract: Scrollbars that "stick" to an edge!
11 | Warning: replaced by https://drafts.csswg.org/css-scroll-snap/
12 |

13 | 14 |

15 | spec: css-scroll-snap; type: dfn;
16 | 	text: scroll snap area
17 | 	text: snap
18 |

19 | 20 | This Spec Has Been Superseded {#intro} 21 | ====================================== 22 | 23 | This spec has been superseded by other CSS technology. 24 | In particular, to implement a chatroom 25 | that "sticks" the scrollbar to the bottom of the scroller when you're near the bottom, 26 | staying there if you add new messages to the bottom, 27 | but not messing with your scroll position when you're scrolled elsewhere in the history, 28 | just use [[css-scroll-snap-1]]: 29 | 30 |

31 | .message-container {
32 |   scroll-snap-type: proximity;
33 | }
34 | .message-container::after {
35 |   content: "";
36 |   height: 0;
37 |   overflow: hidden;
38 |   display: block;
39 |   scroll-snap-align: end;
40 | }
41 |

42 | 43 | This creates a single scroll snap area in the message container, 44 | aligned with the very bottom of the container. 45 | If you scroll "near" the bottom, you'll snap to it; 46 | if you add more content to the message container 47 | (thus pushing the ::after further down), 48 | it'll automatically re-snap to it 49 | (because scroll containers have to re-snap to the same scroll snap area if it still exists); 50 | if you are scrolled somewhere else in the history, 51 | it won't do anything at all. 52 | 53 | The use-case of "stable scrolling", 54 | where you want "whatever you're currently looking at" to stay on the screen 55 | when things are added/removed/resized higher up in the scroll container, 56 | is handled by the Scroll Anchoring proposal 57 | currently making its way thru the standards process. 58 | -------------------------------------------------------------------------------- /css-toggle-states/index.bs: -------------------------------------------------------------------------------- 1 |

  2 | Title: CSS Toggle States
  3 | Group: CSSWG
  4 | Status: UD
  5 | Work Status: exploring
  6 | ED: http://tabatkins.github.io/specs/css-toggle-states/Overview.html
  7 | Shortname: css-toggle-states
  8 | Level: 1
  9 | Editor: Tab Atkins Jr., Google, http://xanthir.com/contact
 10 | Abstract: This specification defines a way to associate a toggleable state with an element which can be used in Selectors to select an element, and declarative ways to set and modify the state on the element.
 11 | Ignored Terms: , , 
 12 | Warning: replaced by http://tabatkins.github.io/css-toggle/
 13 |

14 | 15 |

 16 | spec:selectors-4; type:selector;
 17 | 	text::checked
 18 | 	text::active
 19 | 	text::hover
 20 |

21 | 22 |

23 | Introduction

24 | 25 | This section is not normative. 26 | 27 | Some user-interface languages define elements which can have "toggleable state", 28 | which can be modified by user interaction and selected using CSS Selectors. 29 | For example, in HTML, the <input type=checkbox> has a "checked" state 30 | which toggles between true and false when the user activates the element, 31 | and which is selected by the '':checked'' pseudoclass. 32 | 33 |

34 | The following markup example shows how to lightly abuse HTML semantics to declaratively use toggleable state: 35 | 36 |

 37 | 			<ul class='ingredients'>
 38 | 			  <li><label><input type=checkbox><span>1 banana</span></label>
 39 | 			  <li><label><input type=checkbox><span>1 cup blueberries</span></label>
 40 | 			  ...
 41 | 			</ul>
 42 | 			<style>
 43 | 			input[type='checkbox'] {
 44 | 			  display: none;
 45 | 			}
 46 | 			input[type='checkbox']:checked + span {
 47 | 			  color: silver;
 48 | 			  text-decoration: line-through;
 49 | 			}
 50 | 			</style>
 51 |

68 | Creating a Toggleable Element: the 'toggle-states' and 'toggle-initial' property

69 | 70 |

 71 | 	Name: toggle-states
 72 | 	Value: none | <> [cycle | sticky]?
 73 | 	Initial: none
 74 | 	Applies to: all elements
 75 | 	Inherited: no
 76 | 	Percentages: n/a
 77 | 	Media: interactive
 78 | 	Computed value: as specified
 79 | 	Animatable: no
 80 |

81 | 82 |

 83 | 	Name: toggle-initial
 84 | 	Value: <>
 85 | 	Initial: 0
 86 | 	Applies to: all elements
 87 | 	Inherited: no
 88 | 	Percentages: n/a
 89 | 	Media: interactive
 90 | 	Computed value: as specified
 91 | 	Animatable: no
 92 |

93 | 94 | The 'toggle-states' property controls whether an element has toggleable state or not. 95 | 96 |

none 98 |: 99 | Indicates that the element does not have toggleable state. 100 | 101 |
<> [cycle | sticky]? 102 |: 103 | Indicates that the element is toggleable. 104 | The <> gives the number of states; 105 | it must be 2 or greater, or else the property is invalid. 106 | The following optional keyword defines the behavior 107 | when the element is already at its last state, 108 | and is toggled again: 109 | cycle defines that it should cycle back around to the first state, 110 | while sticky defines that it should stay at the last state. 111 |

123 | Revisiting the example in the Introduction, 124 | the same ingredient list can be specified in simple HTML and CSS: 125 | 126 |

127 | 			<ul class='ingredients'>
128 | 			  <li>1 banana
129 | 			  <li>1 cup blueberries
130 | 			  ...
131 | 			</ul>
132 | 			<style>
133 | 			li {
134 | 			  toggle-states: 2;
135 | 			}
136 | 			li:checked {
137 | 			  color: silver;
138 | 			  text-decoration: line-through;
139 | 			}
140 | 			</style>
141 |

142 | 143 | The effect is identical to what was specified in the Introduction example, 144 | except the markup is much simpler and more semantic. 145 |

146 | 147 | The 'toggle-initial' property sets the initial toggle state of the element. 148 | Its value must be a non-negative integer, 149 | or else the property is invalid. 150 | If the value is equal to or greater than the number of states defined by 'toggle-states', 151 | it computes to the greatest toggle state. 152 | 153 | 154 |

155 | Linking Toggle States: the 'toggle-group' property

156 | 157 |

158 | 	Name: toggle-group
159 | 	Value: none | <>
160 | 	Initial: none
161 | 	Applies to: all elements
162 | 	Inherited: no
163 | 	Percentages: n/a
164 | 	Media: interactive
165 | 	Computed value: as specified
166 | 	Animatable: no
167 |

168 | 169 | By default, each toggleable element's toggle state is independent; 170 | incrementing one has no effect an any other. 171 | The 'toggle-group' property allows elements to link their toggle states together 172 | by declaring them to be part of a named toggle group, 173 | such that only one can have a non-zero toggle state at a time, 174 | similar to HTML's <input type=radio> element. 175 | Each [=toggle group=] on a page is identified by a unique <>. 176 | 177 |

none 179 |: 180 | The element is not in a toggle group. 181 | It's toggle state is independent of any other elements'. 182 | 183 |
<> 184 |: 185 | The element is in the toggle group named by the <>. 186 | Any time an element in the given toggle group has its toggle state incremented, 187 | the toggle state of every other element in the same toggle group is set to 0. 188 | 189 | The keyword none is excluded from this <>. 190 |

191 | 192 |

193 | For example, 'toggle-group' can be used to control a tabbed display, 194 | so that only one panel is displayed at a time: 195 | 196 |

197 | 			.tab {
198 | 			  toggle-states: 2 sticky;
199 | 			  toggle-group: "tabs";
200 | 			  toggle-share: select(attr(for idref));
201 | 			}
202 | 			.panel {
203 | 			  toggle-states: 2 sticky;
204 | 			  toggle-group: "panels";
205 | 			}
206 | 			.tab:checked {
207 | 			  /* styling for the active tab */
208 | 			}
209 | 			.panel:not(:checked) {
210 | 			  display: none;
211 | 			}
212 |

213 | 214 | Clicking on any tab will increment its toggle state from 0 to 1 215 | (and the ''sticky'' keyword will keep it at 1 if activated multiple times), 216 | while resetting the rest of the tabs' toggle states to 0. 217 | The same happens to the panels, 218 | using the 'toggle-share' property defined in a later section. 219 | The active tab and panel are styled and shown differently than the other tabs and panels. 220 |

221 | 222 |

223 | The name is global to the page. 224 | Should we have a way to specify more implicit groups? 225 | Maybe a ''parent'' keyword, 226 | or a way to scope names to a subtree? 227 | 228 | 229 |

231 | 232 |

233 | 	Name: toggle-share
234 | 	Value: none | <>
235 | 	Initial: none
236 | 	Applies to: all elements
237 | 	Inherited: no
238 | 	Percentages: n/a
239 | 	Media: interactive
240 | 	Computed value: as specified
241 | 	Animatable: no
242 |

243 | 244 | By default, activating an element only increments its own toggle state. 245 | The 'toggle-share' property allows an element to additionally increment the toggle state of another element. 246 | 247 |

none 249 |: 250 | Activating the element only increments its own toggle state 251 | (assuming the element is toggleable). 252 | 253 |
<> 254 |: 255 | Activating the element increments the toggle state 256 | of both itself and all the elements matched by the given selector 257 | (assuming the elements are toggleable). 258 | 259 | If the set of elements sharing the activation includes elements that share a toggle group, 260 | only the last such element (in document order) per group has its toggle state incremented. 261 |

262 | 263 |

264 | The preceding section for 'toggle-group' contained an example showing off 'toggle-share'. 265 | When the user activates a tab, 266 | the activation is shared with the associated panel. 267 |

279 | Selecting Elements Based on Toggle State: the '':checked'' and '':checked()'' pseudo-class

290 | Problems with Combining '':checked'' and 'toggle-*' Properties

291 | 292 | Naively combining '':checked'' and the 'toggle-*' properties causes circularity issues. 293 | 294 |

302 | 			#foo {
303 | 				toggle-states: 2;
304 | 				toggle-initial: 1;
305 | 			}
306 | 			#foo:checked {
307 | 				toggle-states: none;
308 | 			}
309 |

310 |

311 | 312 | To avoid this, 313 | the 'toggle-states' and 'toggle-initial' are defined as selector-affecting properties, 314 | and the '':checked'' and '':checked()'' pseudo-classes are defined as property-affected selectors. 315 | In any style rule whose selector includes a property-affected selector, 316 | any selector-affecting properties are invalid. 317 | 318 | Issue: I'm not sure this is sufficient. 319 | For example, you could set the property in an animation, 320 | which is triggered by an affected selector. 321 | Is there a better way to define this so that it's reliable? 322 | -------------------------------------------------------------------------------- /css-when-else/index.bs: -------------------------------------------------------------------------------- 1 |

  2 | Title: CSS When/Else Rules
  3 | Shortname: css-when-else
  4 | Level: 1
  5 | Status: UD
  6 | Group: CSSWG
  7 | Work Status: exploring
  8 | URL: https://tabatkins.github.io/specs/css-when-else/
  9 | Editor: Tab Atkins-Bittner
 10 | Abstract: A proposal to extend the concept of CSS conditional rules to arbitrary when/else chains, and supporing this, a proposal to unify the disparate conditional rules into a single grammar.
 11 | Ignored Terms: 
 12 |

13 | 14 |

 15 | spec: css-conditional-3
 16 | 	type: dfn; text: conditional group rule
 17 |

18 | 19 | Introduction {#intro} 20 | ===================== 21 | 22 | Writing complex media queries or supports queries is difficult, 23 | particularly when you want to do Thing A in one circumstance, 24 | Thing B in another circumstance, 25 | and Thing C otherwise. 26 | This requires carefully crafting your conditional rules to exclude anything matching the other rules, 27 | while also making sure you're not accidentally over-excluding things and leaving some situations unmatched. 28 | 29 | This spec proposes two things to fix this problem. 30 | First, it proposes an ''@when'' rule, 31 | which generalizes the concept of a conditional rule. 32 | Anything you can express in an existing conditional rule 33 | can be expressed in ''@when'', 34 | it just has to be wrapped in an appropriate function 35 | to declare what kind of condition it is. 36 | This allow authors to easily combine multiple types of queries, 37 | such as media queries and supports queries, 38 | in a single boolean expression. 39 | Without this, 40 | authors must rely on nesting separate conditional rules, 41 | which is harder to read and write, 42 | presupposes the conditions are to be conjoined with the "and" boolean relation 43 | (with no easy way to indicate anything else), 44 | and restricts their utility in the proposed conditional rule chains. 45 | 46 | Second, it proposes the introduction of ''@else'' rules, 47 | which follow conditional rules 48 | and automatically qualify their conditions as you'd expect, 49 | such that at most one rule in an conditional rule chain is chosen as active. 50 | 51 | Generalized Conditional Rules: the ''@when'' rule {#when-rule} 52 | ========================================================== 53 | 54 | The @when at-rule is a conditional group rule 55 | that generalizes the individual conditional group rules 56 | such as ''@media'' and ''@supports''. 57 | It is defined as: 58 | 59 |

 60 | @when <> {
 61 | 	<>
 62 | }
 63 |

64 | 65 | Where <> is a boolean algebra a la [[mediaqueries-4#mq-syntax]], 66 | but with ''media()'' and ''supports()'' functions as leaves. 67 | 68 | Issue: Define "boolean algebra, with X as leaves" in a generic way in Conditional, 69 | so all the conditional rules can reference it directly, 70 | rather than having to redefine boolean algebra on their own. 71 | 72 | The ''media()'' and ''supports()'' functions are defined as: 73 | 74 |

 75 | media() = media( [ <> | <> | <> ] )
 76 | supports() = supports( <> )
 77 |

78 | 79 | A ''media()'' or ''supports()'' function is associated the boolean result 80 | that its contained condition is associated with. 81 | 82 | Chained Conditionals: the ''@else'' rule {#else-rule} 83 | ===================================================== 84 | 85 | Usually, conditional group rules are independent; 86 | each one has a separate condition 87 | evaluated without direct reference to any other rule, 88 | and decides whether or not to apply its contained rules 89 | based solely on its condition. 90 | 91 | This is fine for simple conditions, 92 | but makes it difficult to write a collection of conditionals that are meant to be mutually exclusive; 93 | authors have to very carefully craft their conditions to not activate when the other rules are meant to, 94 | and make sure the collection of conditionals don't accidentally all exclude some situation 95 | which is then left unstyled. 96 | 97 | The @else rule is a conditional group rule 98 | used to form conditional rule chains, 99 | which allow multiple conditional rules to be provided 100 | and guarantee that at most one of them will evaluate their condition as true. 101 | It is defined as: 102 | 103 |

104 | @else <>? {
105 | 	<>
106 | }
107 |

108 | 109 | ''@else'' is interpreted identically to ''@when''. 110 | If its <> is omitted, 111 | it's treated as having a condition that's always true. 112 | 113 | A conditional rule chain is a series of consecutive conditional group rules, 114 | starting with a conditional group rule other than ''@else'', 115 | followed by zero or more ''@else'' rules. 116 | There cannot be anything between the successive conditional group rules 117 | other than whitespace and/or comments; 118 | any other token "breaks" the chain. 119 | 120 | Issue: Should we require that only the last ''@else'' in a chain can have an omitted condition? 121 | It's not uncommon for me, when debugging code, 122 | to short-circuit an if-else chain by setting one of them to "true"; 123 | I presume that would be similarly useful in CSS? 124 | It's still pretty easy to see you've done something wrong if you omit the condition accidentally. 125 | 126 | Within a conditional rule chain, 127 | the conditions of each conditional group rule are evaluated in order. 128 | If one of them is true, 129 | the conditions of all following conditional group rules in the chain must evaluate to false, 130 | regardless of what they contain. 131 | 132 | An ''@else'' rule that is not part of a conditional rule chain is invalid and must be ignored. 133 | 134 |

135 | For example, here's a (somewhat silly) conditional chain: 136 | 137 |

138 | 		@when media(width >= 400px) and media(pointer: fine) and supports(display: flex) {
139 | 			/* A */
140 | 		} @else supports(caret-color: pink) and supports(background: double-rainbow()) {
141 | 			/* B */
142 | 		} @else {
143 | 			/* C */
144 | 		}
145 |

157 | 		@media (width >= 400px) and (pointer: fine) {
158 | 			@supports (display: flex) {
159 | 				/* A */
160 | 			}
161 | 			@supports not (display: flex) {
162 | 				@supports (caret-color: pink) and (background: double-rainbow()) {
163 | 					/* B */
164 | 				}
165 | 				@supports not ((caret-color: pink) and (background: double-rainbow())) {
166 | 					/* C */
167 | 				}
168 | 			}
169 | 		}
170 | 		@media not ((width >= 400px) and (pointer: fine)) {
171 | 			@supports (caret-color: pink) and (background: double-rainbow()) {
172 | 				/* B */
173 | 			}
174 | 			@supports not ((caret-color: pink) and (background: double-rainbow())) {
175 | 				/* C */
176 | 			}
177 | 		}
178 |

179 | 180 | This is simultaneously impossible to read, 181 | requires significant duplication of both conditions and contents, 182 | and is very difficult to write correctly 183 | (I wrote it wrong twice while producing this example). 184 | If the conditions got any more complicated 185 | (which is not unusual in real-world content), 186 | the example would get significantly worse. 187 |

188 | -------------------------------------------------------------------------------- /css-will-change/index.bs: -------------------------------------------------------------------------------- 1 |

  2 | Title: CSS Will Change Module Level 1
  3 | Shortname: css-will-change
  4 | Level: 1
  5 | Status: ED
  6 | Group: CSSWG
  7 | Work Status: exploring
  8 | ED: http://tabatkins.github.io/specs/css-will-change/
  9 | Abstract: This document defines the 'will-change' property, which allows an author to inform the UA ahead of time of what kinds of changes they are likely to make to an element.  This allows the UA to optimize how they handle the element ahead of time, performing potentially-expensive work preparing for an animation before the animation actually begins.
 10 | Editor: Tab Atkins Jr., Google Inc., http://xanthir.com/contact/
 11 | Warning: replaced by http://dev.w3.org/csswg/css-will-change/
 12 |

13 | 14 |

15 | Introduction

16 | 17 | Modern CSS renderers perform a number of complex optimizations in order to render webpages quickly and efficiently. 18 | Unfortunately, employing these optimizations often has a non-trivial start-up cost, 19 | which can have a negative impact on the responsiveness of a page. 20 | 21 |

22 | For example, when using CSS 3D Transforms to move an element around the screen, 23 | the element and its contents might be promoted to a “layer”, 24 | where they can render independently from the rest of the page and be composited in later. 25 | This isolates the rendering of the content so that the rest of the page doesn't have to be rerendered 26 | if the element’s transform is the only thing that changes between frames, 27 | and often provides significant speed benefits. 28 | 29 | However, setting up the element in a fresh layer is a relatively expensive operation, 30 | which can delay the start of a 'transform' animation by a noticeable fraction of a second. 31 |

32 | 33 | The 'will-change' property defined in this specification allows an author to declare ahead-of-time what properties are likely to change in the future, 34 | so the UA can set up the appropriate optimizations some time before they're needed. 35 | This way, when the actual change happens, 36 | the page updates in a snappy manner. 37 | 38 |

39 | Hinting at Future Behavior: the 'will-change' property

40 | 41 |

 42 | 	Name: will-change
 43 | 	Value: auto | <>#
 44 | 	Initial: auto
 45 | 	Applies to: all elements
 46 | 	Inherited: no
 47 | 	Percentages: n/a
 48 | 	Media: all
 49 | 	Computed value: specified value
 50 |

51 | 52 |

<animateable-feature> = scroll-position | contents | <>

53 | 54 | The 'will-change' property provides a rendering hint to the user agent, 55 | stating what kinds of changes the author expects to perform on the element. 56 | This allows the user agent to perform ahead-of-time any optimizations necessary for rendering those changes smoothly, 57 | avoiding “jank” when the author does begin changing or animating that feature. 58 | 59 | Values have the following meanings: 60 | 61 |

auto 63 |: 64 | Expresses no particular intent. 65 | 66 |
scroll-position 67 |: 68 | Indicates that the author expects to animate or change the scroll position of the element in the near future. 69 | 70 |
contents 71 |: 72 | Indicates that the author expects to animate or change something about the element's contents in the near future. 73 | 74 |
<> 75 |: 76 | Indicates that the author expects to animate or change the property with the given name on the element in the near future. 77 | 78 | The <> production used here excludes the keywords will-change, none, all, auto, scroll-position, and contents, 79 | in addition to the keywords normally excluded from <>. 80 | 81 | Note: Note that most properties will have no effect when specified, 82 | as the user agent doesn't perform any special optimizations for changes in most properties. 83 | It is still safe to specify them, though; 84 | it'll simply have no effect. 85 | 86 | If any non-initial value of a property would create a stacking context on the element, 87 | specifying that property in 'will-change' must create a stacking context on the element. 88 | 89 | If any non-initial value of a property would cause the element to generate a containing block for fixed-position elements, 90 | specifying that property in 'will-change' must cause the element to generate a containing block for fixed-position elements. 91 | 92 | If a non-initial value of a property would cause rendering differences on the element 93 | (such as using a different anti-aliasing strategy for text), 94 | the user agent should use that alternate rendering when the property is specified in 'will-change', 95 | to avoid sudden rendering differences when the property is eventually changed. 96 |

97 | 98 | 99 |

100 | For example, setting 'opacity' to any value other than 1 creates a stacking context on the element. 101 | Thus, setting ''will-change: opacity'' also creates a stacking context, 102 | even if 'opacity' is currently still equal to 1. 103 |

104 | 105 | The 'will-change' property has no direct effect on the element it is specified on, 106 | beyond the creation of stacking contexts and containing blocks as specified above. 107 | It is solely a rendering hint to the user agent, 108 | allowing it set up potentially-expensive optimizations for certain types of changes 109 | before the changes actually start occurring. 110 | -------------------------------------------------------------------------------- /index.html: -------------------------------------------------------------------------------- 1 | 2 | Look at the README 3 |

Look at the README

4 |

5 | I don't feel like duplicating this information between the README and the index page, 6 | so if you want to know the list of specs in this repository, 7 | look at the README. 8 |

9 | xoxo, Tab 10 | -------------------------------------------------------------------------------- /layout-transitions/index.bs: -------------------------------------------------------------------------------- 1 |

  2 | Title: Layout Transition Primitives
  3 | Status: UD
  4 | Group: CSSWG
  5 | Work Status: exploring
  6 | ED: http://tabatkins.github.io/specs/layout-transitions/
  7 | Shortname: layout-transitions
  8 | Level: 1
  9 | Editor: Shane Stephens, Google, shanestephens@google.com
 10 | Editor: Tab Atkins Jr., Google, http://xanthir.com/contact/
 11 | Abstract: Primitive JavaScript operations to enable layout transition effects.
 12 | Default Highlight: javascript
 13 | Ignored Terms: absolutely positioned
 14 | Warning: replaced by https://tabatkins.github.io/specs/css-shared-element-transitions
 15 |

16 | 17 |

 18 | spec:css-images-4; type:function; text:element()
 19 |

20 | 21 |

22 | Introduction

23 | 24 | [[CSS3-TRANSITIONS]] provide web authors with the ability to generate smooth transitioning effects 25 | when mutating the CSS of their web pages. 26 | However, the transitions that can be generated in this manner are limited in important ways, 27 | which make it difficult or impossible to use them in some cases. 28 | 29 | In particular, 30 | CSS Transitions only operate on computed style values, 31 | such as between ''100px'' and ''200px''; 32 | values that rely on layout, 33 | such as ''width: auto'', 34 | can't be used as the start or end of a transition. 35 | 36 | Furthermore, CSS Transitions only work over actual CSS property values, 37 | but some of aspects of an element one might wish to transition are derived from other properties 38 | rather than being directly specified. 39 | For example, the position and size of an element positioned with Grid Layout 40 | is derived from its [=grid-placement properties=], 41 | rather than being directly specified. 42 | An author can transition the [=grid-placement properties=], 43 | but that will merely cause the element to "skip" from cell to cell 44 | as its 'grid-row-start' and similar properties transition as integers; 45 | it won't have the desired effect of making the element smoothly move between its start and end position. 46 | Relatedly, there is no reasonable way to express a transition when an element enters or leaves the document. 47 | 48 | These shortcomings make [[CSS3-TRANSITIONS]] unsuitable for specifying transitions between laid out states of a web page. 49 | This specification provides a set of primitive JavaScript methods 50 | to enable transition-like graphical effects for complex layout changes. 51 | 52 |

53 | Motivating Examples

54 | 55 | Layout transition primitives can be used to programmatically control transitions between layout states. 56 | For example: 57 | 58 |

59 | To transition element myDiv from an initial laid out position to a new position: 60 | 61 |

 62 | 			myDiv.suspendPainting();
 63 | 			CSS.elementSources.myDivSnapshot = myDiv.snapshot();
 64 | 			var div = document.createElement('div');
 65 | 			div.style.position = 'absolute';
 66 | 			div.style.left = myDiv.offsetLeft + 'px';
 67 | 			// ...
 68 | 			div.style.backgroundImage = 'element(myDivSnapshot)';
 69 | 			document.body.appendChild(div);
 70 | 			// perform layout
 71 | 			div.animate({left: myDiv.offsetLeft, ... }, 1).source.onEnd(function() {
 72 | 				myDiv.resumePainting();
 73 | 				div.remove();
 74 | 			});
 75 |

76 |

77 | 78 | 79 |

80 | Layout transition primitives also allow element insertions and removals to be smoothed. 81 | 82 | In this example, afterDiv is the last div in a list. 83 | We wish to grow newDiv in-place before afterDiv, 84 | smoothly moving afterDiv down as we do so. 85 | 86 |

 87 | 			container.suspendPainting();
 88 | 			CSS.elementSources.afterDivSnapshot = afterDiv.snapshot();
 89 | 			// .. create and insert snapshot element (see previous example)
 90 | 			container.appendBefore(afterDiv, newDiv);
 91 | 			var bounds = newDiv.recastElement();
 92 | 			new ParGroup([
 93 | 				bounds.animate([{height: 0}, {height: bounds.height}], 1),
 94 | 				div.animate({top: afterDiv.top}, 1)
 95 | 			]).source.onEnd(function() {
 96 | 				myDiv.resumePainting();
 97 | 				div.remove();
 98 | 			});
 99 |

100 |

101 | 102 | 103 |

109 | 			myDiv.suspendPainting();
110 | 			CSS.elementSources.before = myDiv.snapshot();
111 | 			// .. create and insert snapshot element (see previous example)
112 | 			// perform layout
113 | 			CSS.elementSources.after = myDiv.snapshot();
114 | 			div.style.transition = 'background-image 1s';
115 | 			div.style.backgroundImage = 'element(after)';
116 | 			setTimeout(function() {
117 | 				myDiv.resumePainting();
118 | 				div.remove();
119 | 			}, 1000);
120 |

121 |

122 | 123 |

124 | IDL

125 | 126 | 127 | partial interface Element { 128 | void suspendPainting(); 129 | void resumePainting(); 130 | Promise<OpaqueImageSnapshot> snapshot(); 131 | ElementBounds recastElement(); 132 | void cancelRecast(); 133 | }; 134 | 135 | interface OpaqueImageSnapshot { 136 | }; 137 | 138 | interface ElementBounds { 139 | attribute DOMString left; 140 | attribute DOMString top; 141 | attribute DOMString width; 142 | attribute DOMString height; 143 | attribute DOMString transform; 144 | attribute DOMString transformOrigin; 145 | attribute DOMString opacity; 146 | attribute DOMString overflow; 147 | }; 148 | 149 | 150 | Issue: Ensure that ElementBounds implements Animatable, 151 | assuming that this idea makes it into the Web Animations specification. 152 | 153 |

154 | Suspending Painting - the suspendPainting() and resumePainting() methods

155 | 156 | The {{suspendPainting()}} and {{resumePainting()}} methods on elements 157 | allow an author to control whether an element "paints", 158 | or is displayed on the screen. 159 | This is similar to using the 'visibility' property, 160 | but more explicit and slightly more powerful. 161 | Like 'visibility' and unlike other properties such as 'display', 162 | the element is still laid out and takes up space on the page as normal 163 | even if it's not being painted. 164 | 165 | Note: Suspending the painting of an element is commonly used with the other methods in this specification, 166 | to get the original element "out of the way" while script is simulating a transition of the element with snapshots and recastings. 167 | 168 | When {{suspendPainting()}} is called on an element, 169 | the element's painting suspended flag must be set. 170 | When {{resumePainting()}} is called on an element, 171 | the element's [=painting suspended flag=] must be unset. 172 | 173 | When an element's [=painting suspended flag=] is toggled from unset to set, 174 | its subtree must be repainted. 175 | 176 | Issue: This is actually trying to introduce the notion that {{suspendPainting()}} is an entry in the style updates queue. 177 | How should this be worded? 178 | 179 | An element is suspended if its [=painting suspended flag=] is set, 180 | or if it has a parent element and that parent element is [=suspended=]. 181 | 182 | Whether the [=painting suspended flag=] is set or unset must not change if the element is added or removed from the document. 183 | 184 | When an element is [=suspended=], 185 | its generated box is invisible 186 | (fully transparent, nothing is drawn), 187 | but still affects layout. 188 | This is similar to the effects of ''visibility: hidden'' 189 | 190 | Note: Calling {{resumePainting()}} on an element which is [=suspended=] 191 | due to an ancestor having its [=painting suspended flag=] set will do nothing; 192 | the element's [=painting suspended flag=] is already unset. 193 | 194 |

195 | Snapshotting Elements - The snapshot() method

196 | 197 | The {{snapshot()}} method takes a "snapshot" of an element, 198 | returning an image of the element at that time 199 | (even if the element is currently [=suspended=]) 200 | which is useful in implementing layout transitions, 201 | as described in the Examples section of this document. 202 | 203 | When {{snapshot()}} is called on an element el, 204 | the user agent must perform the following steps: 205 | 206 |

208 | Let snapshot be a newly-created {{OpaqueImageSnapshot}} object. 209 | Return snapshot, 210 | and complete the rest of these steps asynchronously. 211 | 212 |
213 | Create a new [=style-dependent action=] action 214 | which, when executed, 215 | captures the current rendering of el, 216 | associates the rendering with snapshot, 217 | and resolves snapshot's ready promise with undefined. 218 | 219 |
220 | Push action onto el's [=style updates queue=]. 221 |

222 | 223 | Issue: Rewrite this to return a promise for a snapshot, 224 | rather than sync-returning a snapshot that then has a ready promise. 225 | 226 | When asked to capture the current rendering of an element el, 227 | the user agent must produce 228 | the image that would be represented by an ''element()'' function referencing el at that moment, 229 | with the image having the same width and height as el does at that moment. 230 | If el is currently [=suspended=], 231 | for the purposes of generating this image it is treated as being not [=suspended=]. 232 | 233 | Note: Only the current element's [=suspended=] state is altered 234 | for the purposes of generating a snapshot image. 235 | If descendant elements are also marked as [=suspended=], 236 | then those elements will remain transparent in the snapshot. 237 | 238 | Note: The image does not necessarily have to be a raster bitmap, 239 | as the actual image data is never directly exposed to the page. 240 | For example, some user agents use an intermediate vector-like representation of an element 241 | before the rasterization step; 242 | this alternative representation may be produced instead, 243 | so that the image can be rendered accurately at any target size 244 | without scaling artifacts. 245 | 246 | Note: Due to the way the [=style updates queue=] works, 247 | if an author generates a snapshot 248 | before creating a new element and assigning the snapshot as a background image, 249 | it's guaranteed that there will be no FOUC (flash of unstyled content). 250 | Any other order might generate a FOUC, 251 | depending on timing and user-agent-specific behavior. 252 | 253 | Note: Snapshots never "expire" or otherwise become unusable, 254 | even if the element they are snapshotting is removed or deleted. 255 | 256 | 257 |

258 | Snapshots: the `OpaqueImageSnapshot` object

259 | 260 | {{OpaqueImageSnapshot}} objects are returned by the {{snapshot()}} method, 261 | and represent the rendering of an element at the time that {{snapshot()}} is called. 262 | 263 | For security reasons, 264 | the image data represented by an {{OpaqueImageSnapshot}} object is not obtainable by any means; 265 | the image can only be displayed indirectly, 266 | by using the {{OpaqueImageSnapshot}} object 267 | in conjunction with CSS's ''element()'' function 268 | and the {{elementSources}} map. 269 | 270 | An {{OpaqueImageSnapshot}} object might represent an image. 271 | If it does, it provides a [=paint source=], 272 | with the width, height, and appearance of the image it represents. 273 | 274 | When the {{ready()}} method of an {{OpaqueImageSnapshot}} snapshot is called, 275 | user agents must perform the following steps: 276 | 277 |

279 | Let ready promise be a newly-created Promise. 280 | Return it, 281 | and perform the rest of these steps asynchronously. 282 | 283 |
284 | When snapshot represents an image, 285 | resolve ready promise with undefined. 286 |

287 | 288 |

289 | Is there any way for a snapshot to fail? 290 | Deleting the element before it's rendered? 291 | 292 |

293 | Recasting Painting - The recastElement() and cancelRecast() methods

294 | 295 | While snapshotting elements into static images 296 | is appropriate for many layout transitions, 297 | sometimes it is necessary to continuously lay out the element and its contents 298 | as it changes size and shape. 299 | However, the actual element can't be used for this purpose, 300 | as it's busy occupying space in the layout. 301 | Instead, a [=suspended=] element can have its painting recasted, 302 | rendering it at an explicitly-set size and position 303 | without moving it in the layout as far as the outer page is concerned. 304 | 305 | When the {{recastElement()}} method is called on an element el, 306 | the user agent must perform the following steps: 307 | 308 |

310 | If the element is not currently [=suspended=], 311 | throw a ??? error 312 | and exit this algorithm. 313 | 314 |
315 | If the element already has an associated {{ElementBounds}} object, 316 | return that object 317 | and exit this algorithm. 318 | 319 |
320 | Create a new {{ElementBounds}} object bounds 321 | associated with el. 322 | [=Initialize the element bounds=]. 323 | Return bounds. 324 |

325 | 326 | While an element has an associated {{ElementBounds}} object, 327 | it is recast. 328 | 329 | If an element is [=recast=], 330 | and stops being [=suspended=] for any reason, 331 | it must cancel recast, 332 | which causes its associated {{ElementBounds}} object to no longer be associated with it. 333 | 334 | While an element is [=recast=], 335 | it must be laid out twice. 336 | The first is as normal for a [=suspended=] element, 337 | to establish the space that the element takes up in the page. 338 | 339 | The second treats the element as [=absolutely positioned=] 340 | with the [=initial containing block=] as its containing block, 341 | and the element's 'width', 'height', 'left', 'top', 'opacity', and 'transform' properties 342 | set to the corresponding values from the element's associated {{ElementBounds}} object 343 | rather than the values obtained from the cascade. 344 | Additionally, the element's 'right' and 'bottom' properties must be treated as ''right/auto'' for this layout. 345 | The element must then render as normal based on the results of this layout. 346 | 347 | Modifying the element's associated {{ElementBounds}} object 348 | must cause the element to perform its second layout with the new values, 349 | as if this were an ordinary style change. 350 | 351 | Querying the style of any properties on the element 352 | must return the results of the first layout, 353 | not the second. 354 | 355 | Note: Note that while an element is [=recast=], 356 | any additional calls to {{recastElement()}} will return the same {{ElementBounds}} object. 357 | 358 | When the {{cancelRecast()}} method is called on an element, 359 | the user agent must [=cancel recast=] on it. 360 | 361 | Removing a [=recast=] element from the document 362 | causes that element to [=cancel recast=]. 363 | However, atomic moves within the same document do not [=cancel recast=]. 364 | 365 | Note: recasting an element does not alter the suspended state of 366 | descendents of that element. 367 | 368 |

369 | The `ElementBounds` Object

370 | 371 | The {{ElementBounds}} object controls the position and size of a [=recast=] element's rendering. 372 | It is returned by calling {{recastElement()}} on an element. 373 | 374 | When asked to initialize the element bounds for an element el 375 | and an {{ElementBounds}} object eb, 376 | user agents must perform the following steps: 377 | 378 |

380 | Lay out the element as normal. 381 | 382 |
383 | Set the {{ElementBounds/width}}, 384 | {{ElementBounds/height}}, 385 | {{ElementBounds/opacity}}, 386 | and {{ElementBounds/transform}} attributes of eb 387 | to the used values of the corresponding properties from el. 388 | 389 |
390 | Set the {{ElementBounds/left}} and {{ElementBounds/top}} attributes of eb 391 | to the offsets of el's left and top edges, respectively, 392 | relative to the top left corner of the initial containing block. 393 |

394 | 395 |

396 | Appendix A: The Style Updates Queue

397 | 398 | Note: This section probably isn't best placed here, 399 | but I need some terms defined that aren't currently defined. 400 | 401 | Each element in a document is associated with a style updates queue, 402 | containing [=style updates=] and [=style-dependent actions=]. 403 | A style update is a pending currently-unapplied change made to the style of an element on the page 404 | which might have an effect on the style, layout, or rendering of the element. 405 | A style-dependent action is an operation which relies on the element's style, layout, and/or rendering 406 | being fully up-to-date. 407 | 408 | Whenever a change is made to the page's style that may affect an element, 409 | a [=style update=] must be pushed onto the element's [=style updates queue=]. 410 | The element's style, layout, and/or rendering must not be updated 411 | unless a corresponding [=style update=] is at the front of the [=style updates queue=]. 412 | When a [=style update=] is applied, 413 | it must be popped from the queue. 414 | 415 | Similarly, [=style-dependent actions=] must not be executed 416 | unless they are at the front of the [=style updates queue=]. 417 | When they are executed, 418 | they must be popped from the queue. 419 | 420 | User agents may delay applying [=style updates=] as long as they consider reasonable 421 | so as to batch any work caused by updating styles, layout, and rendering. 422 | User agents should prioritize applying [=style updates=] 423 | that precede a [=style-dependent action=] 424 | when a [=style-dependent action=] is in the queue. 425 | -------------------------------------------------------------------------------- /qrcode/index.bs: -------------------------------------------------------------------------------- 1 |

  2 | Title: The QRCODE Image Format
  3 | Shortname: qrcode
  4 | Level: 1
  5 | Status: DREAM
  6 | Repository: tabatkins/specs
  7 | URL: https://tabatkins.github.io/specs/qrcode/
  8 | Editor: Tab Atkins-Bittner, https://xanthir.com
  9 | Abstract: The "QR Code", invented in the 1990s, has emerged in recent years as the clear winner of the "encode small but complex data, especially URLs, for phones to read" format wars. All phone OSes have built-in ways to read them, and to generate them, but that generation capability isn't exposed to websites.
 10 | Abstract:
 11 | Abstract: This specification defines a new image type, `image/qrcode`, which represents the data in a QR code in a declarative, compact manner which is easily readable and hand-writable. Browser and other rendering agents that understand this format are expected to automatically generate a QR code image representing the data in the resource.
 12 | Complain About: accidental-2119 yes, missing-example-ids yes
 13 | Markup Shorthands: markdown yes, css no
 14 |

15 | 16 | Introduction {#intro} 17 | ===================== 18 | 19 | Representing relatively small amounts of data in a machine-readable format 20 | has been important for decades. 21 | The humble UPC barcode format, 22 | for instance, 23 | allows storing numeric values 24 | up to ten decimal digits. 25 | 26 | As time has passed, tho, we've required larger amounts of data to be represented 27 | (even if the amounts are still modest; a few kilobytes at most), 28 | and better error correction 29 | (UPC barcodes can correct for *one* wrong digit, but no more). 30 | Many approaches have been proposed and even adopted in various industries, 31 | but the QR Code, 32 | first invented in Japan in the 90s for labeling parts in semi-automated factories, 33 | has emerged as the clear leader in overall usage across the world in recent years. 34 | 35 | While QR Code images are very usable in practice, 36 | they're difficult to *create*; 37 | beyond the ordinary difficulties of creating any image file programmatically, 38 | the QR format is non-trivial to follow, 39 | and the error-correction parts of the format are complex. 40 | However, all the devices a user can expect to *see* a QR Code 41 | have access to libraries for creating them. 42 | 43 | This specification defines a new QRCODE image format, 44 | and its associated MIME type `image/qrcode`, 45 | which represents the content of a QR code 46 | in a simple, human-readable, hand-authorable format. 47 | User agents, such as browsers, that recieve QRCODE images 48 | are expected to render them as QR codes. 49 | 50 | Notes {#notes} 51 | =============== 52 | 53 | Parameters of a QR code: 54 | * "version": a number between 1 and 40, dictating the overall size in pixels/"modules". The eventual size of the QR code is version * 4 + 17 modules, plus additional margin space around the code (typically, at least one module in width). 55 | * error-correction level: what level of error correction is applied to the payload, dictating how much of the code can be lost/obscured/misread without corrupting the code itself. Four values, corresponding to "low" (7% recoverable loss), "medium" (14%), "quartile" (25%), or "high" (30%). 56 | * mask type: to help avoid large black or white "fields" in the code that make it harder to read or recognize, some of the data pixels can be inverted. There are 8 mask types, dictating which pixels are inverted and should be read as their opposite value. 57 | * encoding type: how to interpret the bits in the payload. Three commonly-used value: "numeric", "alphanumeric", and "bytes". 58 | * Numeric is the digits 0-9. 59 | * Alphanumeric is 0-9, A-Z (uppercase only), and some punctuation. Aka a subset of ASCII. 60 | * Bytes has been defined by specs as two different byte-based character encodings. In practice, treating it as UTF-8 seems to be modern practice and is widely recognized by scanners (possibly heuristically). 61 | 62 | Additional params I need to introduce: 63 | 64 | * module size: a number of CSS pixels dictating the side length of a module. 65 | * image size: a number of CSS pixels dictating the overall image size (which dictates the module size). 66 | * using both module and image size would just ignore one of them, I guess. Maybe use the larger one. 67 | * margin?: a CSS pixel size for the safe area around the code 68 | 69 | Image Format {#format} 70 | ============ 71 | 72 | Every QRCODE image must begin with the bytes 73 | `51 52 43 4f 44 45 7b` 74 | (spelling "`QRCODE{`" in ASCII). 75 | Following that are zero or more non-`7d` bytes 76 | (the parameter bytes), 77 | followed by a `7d` byte ("}" in ASCII), 78 | optionally followed by `0d 0a` bytes (CR and NL in ASCII), 79 | followed by zero or more bytes with any value 80 | (the payload bytes). 81 | 82 | A QRCODE image that does not follow this byte format is [=invalid=]. 83 | 84 |

85 | Thus, a valid QRCODE file might be 86 | QRCODE{}https://example.com, 87 | which will be rendered as QR Code image 88 | containing a link to example.com. 89 | 90 | Alternately, the link could be rendered on a separate line for readability, 91 | like: 92 | 93 |

 94 | 		QRCODE{}
 95 | 		https://example.com
 96 |

97 | 98 | This is particular useful if several parameters are provided, 99 | like: 100 | 101 |

102 | 		QRCODE{version=5;error=low;mask=3;modulesize=5;margin=2}
103 | 		https://example.com
104 |

105 |

106 | 107 | Parameters {#parameters} 108 | ---------- 109 | 110 | The [=parameter bytes=] are interpreted into the [=QR code parameters=], 111 | which affect how the QR code image is generated. 112 | The format is intentionally identical to how MIME-type parameters are interpreted. 113 | 114 |

115 | To parse parameter bytes |bytes| 116 | execute the following steps. 117 | It returns either [=QR code parameters=], 118 | or failure. 119 | 120 | 1. Let |str| be the result of [=isomorphic decoding=] |bytes|. 121 | Let |parameters| be an empty [=QR code parameters=]. 122 | 123 | 2. [=string/Strictly split=] |str| on the delimiter U+003B SEMICOLON (;), 124 | and let |param strings| be the result. 125 | 126 | 3. [=list/For each=] |param string| of |param strings|: 127 | 1. 128 |

-------------------------------------------------------------------------------- /respimg/images/difimages.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tabatkins/specs/c492931b1458ff5dc84a814805093763fcf3e3bd/respimg/images/difimages.jpg -------------------------------------------------------------------------------- /respimg/images/viewport_selection_mob_first.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tabatkins/specs/c492931b1458ff5dc84a814805093763fcf3e3bd/respimg/images/viewport_selection_mob_first.jpg -------------------------------------------------------------------------------- /svg-params/index.bs: -------------------------------------------------------------------------------- 1 |

  2 | Title: SVG Parameters
  3 | Shortname: svg-params
  4 | Level: 1
  5 | Status: UD
  6 | Group: CSSWG
  7 | Work Status: exploring
  8 | URL: https://tabatkins.github.io/specs/svg-parameters/
  9 | Editor: Tab Atkins-Bittner, Google, http://xanthir.com/contact/
 10 | Abstract: This introduces "parameters" to SVG, which are a method of setting CSS custom properties in an external SVG document via the fragment on the referencing URL.  This allows easy reuse of "templated" SVG images, which can be adapted to a site's theme color, etc. easily, without having to modify the source SVG.
 11 | Ignored Terms: css value definition syntax
 12 |

13 | 14 |

 15 | spec:selectors-4; type:selector; text::hover
 16 | spec:html; type:element
 17 | 	text: iframe
 18 | 	text: a
 19 | spec:fill-stroke-3; type:property; text:fill
 20 |

21 | 22 | Introduction {#intro} 23 | ===================== 24 | 25 | SVG is stylable with CSS, 26 | and when used inline in HTML, 27 | this capability can be very useful. 28 | For example, an SVG icon can take on a different color based on whether the user is hovering it or not, 29 | just by appling a '':hover'' rule to it that changes the 'fill' property. 30 | 31 | When the SVG is referenced in a way that doesn't allow selectors or CSS inheritance from the outer page to apply to it 32 | (such as embedding it via <{img}> or <{iframe}> in HTML), 33 | though, this functionality is lost. 34 | The only way to change the display of such "external" SVG images 35 | is to produce several of them, 36 | and change which image you're referencing. 37 | This incurs delay on the page as a new resource is downloaded, 38 | and disallows dynamic effects like CSS Transitions. 39 | 40 | SVG Parameters are a way to set CSS custom properties on an "external" SVG image, 41 | by passing them through a special fragment scheme on the URL. 42 | This gives a limited, but powerful, subset of the customizability that "inline" SVG images have 43 | to "external" SVG images. 44 | 45 | Setting an SVG Parameter {#setting} 46 | =================================== 47 | 48 | To "set" an SVG Parameter, 49 | a special "fragment identifier" must be used in the fragment of the URL used to reference. 50 | Several examples of existing "fragment identifiers" for SVG documents can be found in the SVG 1.1 specification. 51 | 52 | The syntax of an SVG parameter fragment identifier is: 53 | 54 |

param( <> <> )

55 | 56 | (using the CSS value definition syntax). 57 | 58 |

59 | For example, to set the "--text-color" custom property of an SVG image to ''blue'', 60 | one can reference the image with a url like “http://example.com/image.svg#param(--text-color%20blue)”. 61 |

62 | 63 | If passing multiple parameters to an image, 64 | additional param() functions must be appended to the URL. 65 | If multiple param() functions specify the same <>, 66 | the custom property is set to the value of the last one. 67 | 68 |

69 | For example, if the image from the previous example also used a "--bg-color" custom property, 70 | it could be referenced with a url like “http://example.com/image.svg#param(--text-color%20blue)param(--bg-color%20white)”. 71 |

72 | 73 | Note: Spaces, and some other characters that might be valid in CSS syntax, 74 | are not technically valid in URLs. 75 | In some contexts, 76 | you might need to escape those characters to form a valid URL. 77 | In most cases, though, 78 | such as HTML's <{a}> element or CSS's ''url()'' function, 79 | spaces are accepted and do not need to be escaped. 80 | 81 | When a valid param() function is encountered in the fragment referencing an SVG document, 82 | it sets the initial value of the given custom property to the given <>. 83 | (By default, the initial value of a custom property is an invalid value.) 84 | 85 | Setting via the CSS ''url()'' Function {#setting-url} 86 | ----------------------------------------------------- 87 | 88 | When referencing an SVG image via CSS, 89 | the param() function can be used in the ''url()'' function. 90 | But a common use-case is passing in values of the page's own custom properties; 91 | for example, a page might use a ''--primary-color'' custom property, 92 | and want to make an SVG image match. 93 | There's no way, however, to integrate the value of a custom property in CSS into the URL passed to the ''url()'' function. 94 | 95 | To accomodate this, 96 | this specification defines a new <>, 97 | the ''param()'' function: 98 | 99 |

param() = param( <> <> )

117 | 		.foo {
118 | 			background-image: url("http://example.com/image.svg" param(--color var(--primary-color)));
119 | 		}
120 |

121 |

122 | 123 | Using SVG Parameters {#using} 124 | ============================= 125 | 126 | Within an SVG image, 127 | any SVG parameters set the initial value of the corresponding custom properties. 128 | They can then be used directly in any CSS property 129 | via the CSS ''var()'' function. 130 | 131 |

132 | For example, if an SVG image wanted to expose a ''--color'' parameter, 133 | it could use it like: 134 | 135 |

136 | 		<svg>
137 | 			<g style="fill: var(--color);">
138 | 				<path d="..." />
139 | 			</g>
140 | 		</svg>
141 |

142 |

143 | 144 | Issue: Can it be used in presentation attributes? 145 | 146 |

147 | It's usually a good idea to make your SVG image usable even if no parameters are given, 148 | by providing "default values" for each of the custom properties. 149 | There are several ways to do this. 150 | 151 | 1. On each ''var()'' function, provide a fallback value, like ''fill: var(--color, blue)''. 152 | 2. If the custom property is going to be used a lot, 153 | such that providing a fallback for each individual ''var()'' is troublesome, 154 | store the custom property in a different name while invoking the default, 155 | like: 156 | 157 |

158 | 			:root {
159 | 				--color2: var(--color, blue);
160 | 			}
161 |

162 | 163 | In this example, if ''--color'' is provided via an SVG parameter, 164 | ''--color2'' will receive its value. 165 | If not, it will recieve the default ''blue'' value. 166 | In either case, ''--color2'' can be used in the SVG image's stylesheet unconditionally, 167 | secure in the knowledge that it will always have a value. 168 | 3. In a future level of the Custom Properties specification [[CSS-VARIABLES]], 169 | some "parent's value" functionality will be available to make the previous suggestion more usable: 170 | 171 |

172 | 			:root {
173 | 				--color: var(parent --color, blue);
174 | 			}
175 |

176 | 177 | (This is an example syntax, and is not yet final.) 178 | 179 | By invoking the value of the --color property on the parent 180 | (which, on the root element, refers to the initial value), 181 | an author can avoid self-reference loops while retaining the same custom property name. 182 |

183 | -------------------------------------------------------------------------------- /unit-problems/index.bs: -------------------------------------------------------------------------------- 1 |

  2 | Title: Unit Problems
  3 | Shortname: unit-problems
  4 | Status: LS
  5 | URL: https://tabatkins.github.com/specs/unit-problems/
  6 | Editor: Tab Atkins-Bittner
  7 | Abstract: An exploration of the problem with Houdini's Typed OM unit treatment, and a solution therein.
  8 | Markup Shorthands: markdown yes
  9 |

10 | 11 | Introduction {#intro} 12 | ===================== 13 | 14 | The current [[css-typed-om-1]] approach to unitted valued is incoherent and inextensible. 15 | There are three distinct object "shapes" employed right now, 16 | and we're only handling two "types" of units - lengths and angles. 17 | The inconsistency makes it difficult for authors to predict how to interact with unitted values, 18 | and limits our ability to innovate in the future. 19 | The overall approach means we have to invent a large number of different interfaces 20 | to handle all the different types of unitted values CSS has, 21 | and completely fails to handle the planned addition 22 | of custom unit types. 23 | 24 | Inconsistency {#inconsistency} 25 | ------------------------------ 26 | 27 | We're currently using three different "shapes" for unitted value objects: 28 | 29 | 1. "Simple" lengths (corresponding to values like `5px` or `2em`) 30 | have a {value, unit} structure. 31 | 32 | 2. "Complex" lengths (corresponding to a `calc()` expressions) 33 | have a {px, pc, in, em, vw, ...} structure, 34 | where each field is an independent entry in the sum-of-values 35 | that makes up the calc(). 36 | 37 | 3. "Simple" angles have a {deg, rad, grad, turn} structure, 38 | where each field is linked; 39 | they all reflect a hidden internal value, 40 | so you can write to any field 41 | and then read the equivalent value in a different unit 42 | from another field. 43 | (Such as `x.deg = 180; print(x.turn) // .5`.) 44 | 45 | 46 | Explosion of Types {#type-explosion} 47 | ------------------------------------ 48 | 49 | While <> has two types-- 50 | simple and `calc()`-- 51 | <> only has one, 52 | because all <>-related `calc()`s can be resolved into a "simple" angle currently. 53 | 54 | This ignores the possibility of a future property using <> and <> together 55 | in a way that isn't immediately resolvable 56 | (for example, audio properties 57 | that use % to convey left-to-right progress along the audio stage, 58 | which has an unknown width), 59 | or the addition of an <> unit that doesn't have a fixed conversion ratio 60 | (like ''em'' or ''vw'' has for <>). 61 | 62 | The spec also currently ignores all the *other* types of units, 63 | which will need to be represented in the Typed OM at some point. 64 | They'll result in a number of additional interfaces when we support them. 65 | These interfaces will all need to decide whether they look like {{CSSSimpleLength}} or {{CSSAngleValue}}, 66 | sometimes without any information about the type family 67 | (for example, the <> type has only a single unit in it; 68 | which variant should we choose?). 69 | 70 | 71 | No User Extensibility {#no-extensibility} 72 | ----------------------------------------- 73 | 74 | One of the recorded plans for a future Houdini API 75 | is to allow authors to define custom units for themselves. 76 | For example, 77 | there's still a mess of length units 78 | used by publishers 79 | which we don't particularly want to add to core CSS 80 | (we've already added several, like `pc` and `q`), 81 | but which would be useful for authors using CSS for publishing. 82 | 83 | The {{CSSSimpleLength}} interface is compatible with custom units-- 84 | you just express the custom unit in the `.type`. 85 | (We'll have to relax the attribute into a DOMString, 86 | and the constructor into `(LengthType or DOMString)`, 87 | but that's easy.) 88 | 89 | The {{CSSCalcLength}} interface is also able to be extended to handle custom units; 90 | we'll have to extend it to handle *complex* units already 91 | (when we allow unit algebra), 92 | and a similar approach will allow arbitrary unit extensions 93 | (a Map hanging off the side which contains arbitrary additional entries). 94 | 95 | But the {{CSSAngleValue}} interface doesn't work at all, 96 | at least not without some severe awkwardness. 97 | If you hang a map off the side, 98 | you need to have magical updating going on whenever you set a value, 99 | which is difficult to spec right now 100 | (because Maps don't have a natural way to observe them). 101 | 102 | And this doesn't cover brand new units, 103 | which don't map to any of the existing types, 104 | at all. 105 | They don't have a corresponding OM class to live under. 106 | 107 | 108 | Proposal {#proposal} 109 | ==================== 110 | 111 |

112 | interface CSSDimension {
113 | 	CSSDimension add(CSSDimension value);
114 | 	CSSDimension subtract(CSSDimension value);
115 | 	CSSDimension multiply(double value);
116 | 	CSSDimension divide(double value);
117 | 	static CSSDimension from(DOMString cssText);
118 | 	static CSSDimension from(double value, DOMString type);
119 | 	CSSDimension to(DOMString type);
120 | };
121 | 
122 | interface CSSSimpleDimension : CSSDimension {
123 | 	attribute double value;
124 | 	attribute DOMString type;
125 | };
126 | 
127 | interface CSSCalcLength : CSSDimension {
128 | 	attribute double? px;
129 | 	attribute double? percent;
130 | 	// ...
131 | 	static CSSDimension from(optional CSSCalcLengthDictionary dictionary);
132 | };
133 | 
134 | interface CSSCalcAngle : CSSDimension {
135 | 	attribute double deg;
136 | 	attribute double rad;
137 | 	attribute double grad;
138 | 	attribute double turn;
139 | 	static CSSDimension from(optional CSSCalcAngleDictionary dictionary);
140 | };
141 | 
142 | // same for <time> and <frequency>,
143 | // the only other types allowed in calc() currently
144 |

145 | 146 | *All* unitted values share the {{CSSSimpleDimension}} interface. 147 | 148 | Arithmetic on {{CSSDimension}} values 149 | throws if the value types aren't compatible 150 | (just like, today, they'd throw if you passed a {{CSSAngleValue}} 151 | to {{CSSLengthValue/add()}}). 152 | Otherwise, it returns the appropriate {{CSSCalc*}} subclass. 153 | 154 | The new {{CSSDimension/to()}} method converts from one unit to another. 155 | It throws if the types aren't convertible 156 | (such as `px` to `deg`, but also `px` to `em`), 157 | or if the object is a {{CSSCalc*}} 158 | and some of its non-zero specified values aren't convertible 159 | (so `CSSCalcLength({px:5, in:1}).to("px")` is fine, 160 | but `CSSCalcLength({px:5, em:1}).to("px")` throws). 161 | Otherwise, 162 | it returns a new {{CSSSimpleDimension}} with the specified unit. 163 | 164 | Consistency {#consistency} 165 | -------------------------- 166 | 167 | All unitted values now use the same interface structure. 168 | You don't need to remember whether something is a <> or <> 169 | to know how to get its value out, 170 | or just guess at less-used unit types; 171 | they're all `.value`. 172 | 173 | All types that are allowed in ''calc()'' 174 | now have corresponding interfaces, 175 | again all with the same structure. 176 | As we expand ''calc()'' to allow new types, 177 | we'll add new classes. 178 | 179 | All types that can be converted 180 | do so with a standard mechanism 181 | (the {{to()}} method), 182 | which is short and easy to use. 183 | 184 | 185 | Minimal Types {#minimal-types} 186 | ------------------------------ 187 | 188 | Rather than needing separate classes for every new kind of unit 189 | (and who knows about user-defined units), 190 | we have a single class for all "simple" unitted values, 191 | and one class per variety of type allowed in calc(), 192 | which is a small group that grows slowly. 193 | 194 | 195 | User Extensibility {#extensibility} 196 | ----------------------------------- 197 | 198 | When user-defined units arrive, 199 | they'll be handled with the exact same mechanism as any other unit-- 200 | the author will just create a CSSSimpleDimension for them. 201 | 202 | For calc()-allowed types, 203 | all {{CSSCalc*}} classes will use the same mechanism 204 | to represent user-defined units 205 | (a Map hanging off the side). 206 | 207 | Cons {#cons} 208 | ------------ 209 | 210 | * Converting between the types of angles is somewhat more difficult. 211 | Before you just read the attribute you want, like `x.rad`, 212 | now you have to do `x.to("rad").value`. 213 | (On the plus side, you can now convert between all the absolute length units, 214 | which wasn't previously possible.) 215 | 216 | * You could previously tell by standard JS type-testing 217 | whether a given unitted value was a length or angle. 218 | That's no longer possible unless it's a calc() value; 219 | you have to be able to infer that from the unit now. 220 | 221 | 222 | 223 | Alternatives {#alternatives} 224 | ============================ 225 | 226 | Instead of the calc() interfaces having explicit attributes for their known units, 227 | with extra Maps eventually hanging off of them 228 | for user-defined units 229 | and complex units, 230 | we could instead just make them Maplike. 231 | *All* units would then be treated identically; 232 | you `.get()` and `.set()` them, 233 | and can iterate over it to get the values. 234 | 235 | This also lets us avoid any name collisions between CSS units 236 | and future attributes or methods on the objects; 237 | for example, in the current design we wouldn't be able to ever create a `to` unit, 238 | as it would clash with the {{to()}} method on the prototype. 239 | --------------------------------------------------------------------------------

Browser 26 \|	Timeout 27 \|	Fallback 28 \|	Swap 29 \|
Chrome 35+ 32 \|	3 seconds 33 \|	yes 34 \|	yes 35 \|
Opera 37 \|	3 seconds 38 \|	yes 39 \|	yes 40 \|
Firefox 42 \|	3 seconds 43 \|	yes 44 \|	yes 45 \|
Internet Explorer 47 \|	0 seconds 48 \|	yes 49 \|	yes 50 \|
Safari 52 \|	3 seconds 53 \|	yes 54 \|	yes 55 \|

CSS Extensions

18 | Introduction

39 | Extension Names

50 | Custom Selectors

73 | Script-based Custom Selectors

110 | CSSOM

116 | Custom Functions

163 | Custom Selector Combinators

229 | Custom At-Rules

CSS Nesting Module Level 3

14 | Introduction

24 | Module Interactions

30 | Values

35 | Motivation

23 | Introduction

68 | Creating a Toggleable Element: the 'toggle-states' and 'toggle-initial' property

155 | Linking Toggle States: the 'toggle-group' property

279 | Selecting Elements Based on Toggle State: the '':checked'' and '':checked()'' pseudo-class

290 | Problems with Combining '':checked'' and 'toggle-*' Properties

15 | Introduction

39 | Hinting at Future Behavior: the 'will-change' property

Look at the README

22 | Introduction

53 | Motivating Examples

124 | IDL

154 | Suspending Painting - the suspendPainting() and resumePainting() methods

195 | Snapshotting Elements - The snapshot() method

258 | Snapshots: the `OpaqueImageSnapshot` object

293 | Recasting Painting - The recastElement() and cancelRecast() methods

369 | The `ElementBounds` Object

396 | Appendix A: The Style Updates Queue

CSS Extensions

18 | Introduction

39 | Extension Names

50 | Custom Selectors

73 | Script-based Custom Selectors

110 | CSSOM

116 | Custom Functions

163 | Custom Selector Combinators

229 | Custom At-Rules

CSS Nesting Module Level 3

14 | Introduction

24 | Module Interactions

30 | Values

35 | Motivation

23 | Introduction

68 | Creating a Toggleable Element: the 'toggle-states' and 'toggle-initial' property

155 | Linking Toggle States: the 'toggle-group' property

230 | Sharing Toggle Activations: the 'toggle-share' property

279 | Selecting Elements Based on Toggle State: the '':checked'' and '':checked()'' pseudo-class

290 | Problems with Combining '':checked'' and 'toggle-*' Properties

15 | Introduction

39 | Hinting at Future Behavior: the 'will-change' property

Look at the README

22 | Introduction

53 | Motivating Examples

124 | IDL

154 | Suspending Painting - the suspendPainting() and resumePainting() methods

195 | Snapshotting Elements - The snapshot() method

258 | Snapshots: the OpaqueImageSnapshot object

293 | Recasting Painting - The recastElement() and cancelRecast() methods

369 | The ElementBounds Object

396 | Appendix A: The Style Updates Queue

258 | Snapshots: the `OpaqueImageSnapshot` object

369 | The `ElementBounds` Object