Skip to content

Commit 9e96e70

Browse files
committed
[css-easing-2] Rewrite serialization for linear() to be simpler. Make the linear/linear() grouping the same as the other keywords+functions.
1 parent 1ae4e3c commit 9e96e70

File tree

2 files changed

+95
-47
lines changed

2 files changed

+95
-47
lines changed

css-easing-2/Overview.bs

+59-42
Original file line numberDiff line numberDiff line change
@@ -124,7 +124,6 @@ follow.
124124
The syntax for specifying an [=easing function=] is as follows:
125125

126126
<div class="prod"><dfn type>&lt;easing-function&gt;</dfn> =
127-
''linear'' |
128127
<<linear-easing-function>> |
129128
<<cubic-bezier-easing-function>> |
130129
<<step-easing-function>></div>
@@ -135,7 +134,7 @@ The syntax for specifying an [=easing function=] is as follows:
135134
timing-functions-syntax-valid.html
136135
</wpt>
137136

138-
## The linear easing function: ''linear()'' ## {#the-linear-easing-function}
137+
## Linear Easing Functions: ''linear'', ''linear()'' ## {#the-linear-easing-function}
139138

140139
A <dfn export>linear easing function</dfn>
141140
is an [=easing function=]
@@ -152,24 +151,32 @@ to an [=output progress value=].
152151
A [=linear easing function=] has the following syntax:
153152

154153
<pre class="prod">
154+
<dfn>&lt;linear-easing-function></dfn> = linear | <<linear()>>
155155
<dfn>linear()</dfn> = linear( [ <<number>> && <<percentage>>{0,2} ]# )
156156
</pre>
157157

158158
<wpt>
159159
linear-timing-functions-syntax.html
160160
</wpt>
161161

162-
Each comma-separated argument defines one or two [=control points=],
163-
with an [=input progress value=] equal to the specified <<percentage>>
164-
(converted to a <<number>> between 0 and 1),
165-
and an [=output progress value=] equal to the specified <<number>>.
166-
When the argument has two <<percentages>>,
167-
it defines two [=control points=] in the specified order,
168-
one per <<percentage>>.
162+
: ''linear''
163+
:: Equivalent to ''linear(0, 1)''
169164

170-
If an argument lacks a <<percentage>>,
171-
its [=input progress value=] is initially empty,
172-
but that is immediately corrected by [=linear() canonicalization=] after parsing.
165+
: ''linear()''
166+
::
167+
Specifies a [=linear easing function=].
168+
169+
Each comma-separated argument specifies one or two [=control points=],
170+
with an [=input progress value=] equal to the specified <<percentage>>
171+
(converted to a <<number>> between 0 and 1),
172+
and an [=output progress value=] equal to the specified <<number>>.
173+
When the argument has two <<percentage>>s,
174+
it defines two [=control points=] in the specified order,
175+
one per <<percentage>>.
176+
177+
If an argument lacks a <<percentage>>,
178+
its [=input progress value=] is initially empty,
179+
but that is immediately corrected by [=linear() canonicalization=] after parsing.
173180

174181
<div algorithm>
175182
To <dfn export lt="linear() canonicalization|canonicalize a linear()">canonicalize a linear()</dfn> function's [=control points=],
@@ -197,50 +204,60 @@ but that is immediately corrected by [=linear() canonicalization=] after parsing
197204
every [=control point=] has an [=input progress value=],
198205
and the [=input progress values=] are monotonically non-decreasing
199206
along the list.
207+
208+
Note: Serialization relies on whether or not an [=input progress value=]
209+
was originally supplied,
210+
so that information should be retained
211+
in the [=CSS/internal representation=].
212+
It does not rely on whether a pair of [=control points=]
213+
were specified as two percentages on a single argument
214+
or as separate arguments.
200215
</div>
201216

202217

203218
### Serializing ### {#linear-easing-function-serializing}
204219

205-
<div class=note>
206-
The serialization of ''linear()'' includes input values for each point,
207-
and input values are never less than the input of the previous point.
208-
209-
For example:
210-
211-
- ''linear(0, 0.25, 1)'' serializes as ''linear(0 0%, 0.25 50%, 1 100%)''
212-
- ''linear(0 20%, 0.5 10%, 1)'' serializes as ''linear(0 20%, 0.5 20%, 1 100%)''
213-
- ''linear(0, 0.25 25% 75%, 1)'' serializes as ''linear(0 0%, 0.25 25%, 0.25 75%, 1 100%)''
220+
<div algorithm>
221+
To <dfn export>serialize a linear() function</dfn>:
222+
223+
1. Let |s| be the string "linear(".
224+
2. [=serialize a linear() control point|Serialize each control point=] of the function,
225+
[=string/concatenate=] the results using the separator ", ",
226+
and append the result to |s|.
227+
3. Append ")" to |s|,
228+
and return it.
214229
</div>
215230

216-
<section algorithm="linear easing function">
217-
218-
To get a [=linear easing function=]'s (|linearEasingFunction|) <dfn for="linear easing function" export>serialized computed value</dfn>,
219-
perform the following.
220-
It returns a [=string=].
221-
222-
1. Let |output| be "`linear(`".
223-
224-
1. [=list/For each=] |point| in |linearEasingFunction|'s [=linear easing function/points=]:
231+
<div algorithm>
232+
To <dfn export>serialize a linear() control point</dfn>:
225233

226-
1. If |point| is not the first [=list/item=] of |linearEasingFunction|'s [=linear easing function/points=],
227-
append "<code>, </code>" to |output|.
234+
1. Let |s| be the serialization,
235+
as a <<number>>,
236+
of the [=control point's=] [=output progress value=].
228237

229-
1. Append the computed value of |point|'s [=linear easing point/output=],
230-
as a <<number>>,
231-
to |output|.
238+
2. If the [=control point=] originally lacked an [=input progress value=],
239+
return |s|.
232240

233-
1. Append "<code> </code>" to |output|.
241+
3. Otherwise, append " " (U+0020 SPACE) to |s|,
242+
then serialize the [=control point's=] [=output progress value=]
243+
as a <<percentage>>
244+
and append it to |s|.
234245

235-
1. Append the computed value of |point|'s [=linear easing point/input=],
236-
as a <<percentage>>,
237-
to |output|.
246+
4. Return |s|.
247+
</div>
238248

239-
1. Append "`)`" to |output|.
249+
<div class=example>
250+
When serialized,
251+
[=control points=] originally specified with two [=input progress values=]
252+
are turned into two separate [=control points=],
253+
and the [=input progress values=] are in strictly ascending order.
254+
For example:
240255

241-
1. Return |output|.
256+
- ''linear(0, 0.25, 1)'' serializes as ''linear(0, 0.25, 1)''
257+
- ''linear(0 20%, 0.5 10%, 1)'' serializes as ''linear(0 20%, 0.5 20%, 1)''
258+
- ''linear(0, 0.25 25% 75%, 1)'' serializes as ''linear(0, 0.25 25%, 0.25 75%, 1)''
259+
</div>
242260

243-
</section>
244261

245262
### Output of a linear easing function ### {#linear-easing-function-output}
246263

css-grid-3/Overview.bs

+36-5
Original file line numberDiff line numberDiff line change
@@ -14,9 +14,22 @@ Editor: Brandon Stewart, Apple, https://brandonstewart.net
1414
Abstract: This module introduces masonry layout as an additional layout mode for <a href="https://www.w3.org/TR/css-grid-2/">CSS Grid</a> containers.
1515
WPT Path Prefix: css/css-grid/masonry/tentative/
1616
Markup Shorthands: css yes
17-
Status Text: <strong>This specification represents two variations on the proposal for masonry layout. Feedback on the alternatives is welcome.
17+
Status Text: <strong>This specification represents two variations on the proposal for masonry layout. Feedback on the alternatives is welcome.</strong>
1818
</pre>
1919

20+
<pre class=link-defaults>
21+
spec: css-align-3;
22+
type: value; for: align-content;
23+
text: center;
24+
text: stretch;
25+
type: dfn; text: alignment baseline;
26+
spec: css-grid-2; type: dfn;
27+
text: auto-placement algorithm
28+
text: computed track list
29+
text: collapsed track
30+
</pre>
31+
32+
2033
<style>
2134
:is(section, p).option {
2235
border-right: 1em double;
@@ -127,12 +140,12 @@ Alternative Syntax Proposals</h3>
127140
to promote debate and discussion of these two alternatives.
128141

129142
<dl>
130-
<dt><dfn><span class="option grid">Grid-integrated Option</span></dfn>
143+
<dt><dfn noexport><span class="option grid">Grid-integrated Option</span></dfn>
131144
<dd>
132145
In this syntax model, [=masonry layout=] is integrated into the [=grid layout=] model,
133146
re-using all of the 'grid-*' properties.
134147

135-
<dt><dfn><span class="option masonry">Grid-independent Option</span></dfn>
148+
<dt><dfn noexport><span class="option masonry">Grid-independent Option</span></dfn>
136149
<dd>
137150
In this syntax model, [=masonry layout=] is its own 'display' type,
138151
and has its own parallel set of 'masonry-*' properties.
@@ -168,9 +181,13 @@ Masonry Layout Model</h2>
168181
[=Grid items=] are formed and [=blockified=]
169182
exactly the same as in a regular [=grid container=].
170183

184+
(For clarity, [=grid items=] and [=grid tracks=] of a [=masonry container=]
185+
can be referred to as <dfn export lt="masonry item">masonry items</dfn>
186+
and <dfn export lt="masonry track">masonry tracks</dfn>.)
187+
171188
All CSS properties work the same as in a regular [=grid container=]
172189
unless otherwise specified by this specification.
173-
For example, ''order'' can be used to specify a different layout order for the items.
190+
For example, 'order' can be used to specify a different layout order for the items.
174191

175192
Note: Subgrid items are supported,
176193
but subgridding only occurs in the [=grid axis=];
@@ -362,7 +379,7 @@ Auto Flow Directions: the 'grid-auto-flow' property</h4>
362379
<dfn value>column-reverse</dfn>,
363380
and
364381
<dfn value>wrap-reverse</dfn>,
365-
which reverse the directions of the [=auto-placement algorithm=].
382+
which reverse the directions of the [=grid item placement algorithm=].
366383

367384
In [=masonry layout=], the flow axis specified by ''grid-auto-flow'' is ignored:
368385
items are always placed by filling across the [=grid axis=].
@@ -1306,4 +1323,18 @@ Acknowledgements</h2>
13061323
(from which I lifted the Background chapter) and presented it to the CSSWG.
13071324
Thanks also to everyone who provided feedback on the <a href="https://github.com/w3c/csswg-drafts/issues/4650">initial proposal</a> for this feature.
13081325

1326+
<h2 id=security>
1327+
Security Considerations</h2>
1328+
1329+
As a layout specification,
1330+
this spec introduces no new security considerations
1331+
beyond taht exposed by CSS layout in general.
1332+
1333+
<h2 id=privacy>
1334+
Privacy Considerations</h2>
1335+
1336+
As a layout specification,
1337+
this spec introduces no new privacy considerations
1338+
beyond that exposed by CSS layout in general.
1339+
13091340
<wpt-rest></wpt-rest>

0 commit comments

Comments
 (0)