- From: Dael Jackson <daelcss@gmail.com>
- Date: Sun, 27 Aug 2017 14:56:01 -0400
- To: www-style@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
CSS Timing
----------
- RESOLVED: Rename CSS Timing Functions to CSS Easing Functions,
shortname: css-easing, to accommodate future use outside
animations (e.g. for color transitions in gradients)
- RESOLVED: Renames frames() to steps(), argument names TBD.
- The options names will be decided later in the F2F.
Current suggestions include:
1) distribute and justify
2) distribute and stretch
3) space-evenly, space-between
4) center, stretch
5) both, neither
6) trim-start, trim-end, trim-both, no-trim*
7) short, long
8) include, exclude
CSS Counter Style
-----------------
- RESOLVED: Wrt request to compute missing counter styles
to 'decimal', no change to CR; revert the change
to the Editor's draft. (This is because it would
require recomputing styles if a new @counter-style
rule is appended.)
- RESOLVED: The language of a counter is computed based on the
language of the element that the counter applies to at
the point of retrieval.
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/paris-2017#topics
Present:
Rachel Andrew, Invited Expert
Rossen Atanassov, Microsoft
Tab Atkins, Google
Amelia Bellamy-Royds, Invited Expert (Phone Only)
Brian Birtles, Mozilla
Bert Bos, W3C
Tantek Çelik, Mozilla
Dave Cramer, Hachette Livre
Emil A Eklund, Google
Elika Etemad, Invited Expert
Rob Flack, Google
Daniel Glazman, Disruptive Innovations
Koji Ishii, Google
Dean Jackson, Apple
Ian Kilpatrick, Google
Peter Linss, Invited Expert
Myles C. Maxfield, Apple
Jack Moffitt, Mozilla
Francois REMY, Microsoft
Melanie Richards, Microsoft
Florian Rivoal, Vivliostyle
Simon Sapin, Mozilla
Till Schneidereit, Mozilla
Geoffrey Sneddon, Invited Expert
Alan Stearns, Adobe
Surma, Google
Jet Villegas, Mozilla
Greg Whitworth, Microsoft
Regrets:
Jihye Hong, LG Electronics
Dael Jackson, Invited Expert
Chris Lilley, W3C
Simon Pieters, Opera
Hiroshi Sakakibara, Beyond Perspective Solutions
Lea Verou, Invited Expert
Scribe: iank
CSS Timing
==========
Rossen: So lets start with css timing.
astearns: Lea might call in later.
Rossen: Brian can you cover those.
Shortname
---------
birtles: The first issue should be easy, spec - css timing
functions, there is interest in using those functions in
other specs, e.g. gradient stops
birtles: css-easing-functions, shortname: css-easing
birtles: Does anyone have any other suggestions for the name for
renaming the spec?
Rossen: Everyone one happy with those names?
<tantek> not happy with the name but not going to object to any
bikeshedding. name feels awkward and no idea what it
means.
birtles: shortname should be css-easing
dauwhe: Easing doesn't seem obvious to see, an animation term?
birtles: I think it still makes sense in gradient stops.
glazou: I think that only English speakers would get it.
<tantek> I don't think even native English speakers will get it
either
<tantek> feels like a very "insidery" term
<tantek> but I have no alternatives to suggest :(
Florian: If you use powerpoint, etc, you've probably used ease-in/
out and from there you can work it out?
<jet> http://easings.net/ shows some examples
<tantek> is there a github issue for this?
<astearns> https://github.com/w3c/csswg-drafts/issues/1577
birtles: In web animations the property that uses that function is
called easing.
Rossen: Parametric functions.
birtles: Just the short name is css-easing
fantasai: css-interpolates?
birtles: interpolates has a very different meaning in animations.
fantasai: "CSS Transition Functions" seems the most easy to
understand
Myles: What these functions are used for today?
fantasai: Animations.
Rossen: Transition functions sounds pretty easy
<tantek> I agree with
https://github.com/w3c/csswg-drafts/issues/1577#issuecomment-314214840
tantek: quoting lea - Progression is an everyday word, but easing
is specific to animation
birtles: progression doesn't suggest an easing function, fwds vs.
bwds.
dino: Easing is the industry term...
fantasai: I think css-progress is reasonably straightforward
dino: That seems too generic.
* fantasai thinks its fine.
dino: I think understanding terms, is least of worry.
Florian: If this is a confusing term, which would make you believe
something else, it would be a problem, but merely
unfamiliar is OK.
Rossen: Can everyone live with easing functions?
<silence>
<tantek> -0
* fantasai prefers css-progress to css-easing, doesn't mind what
the title is tho
RESOLVED: Rename css-timing-functions to css-easing-functions,
shortname: css-easing
Name for frames() function
--------------------------
Github: https://github.com/w3c/csswg-drafts/issues/1301
birtles: So we specified a frames() timing function, makes sense
for a usecase, animation that has discrete frames, and
the start and end of the animation doesn't match, and the
animation repeats.
birtles: And for that use-case, frames() is a very good way of
describing the timing, very obvious name, the counting,
the number that you put in that function is the number of
frames, unlike steps() where you count the number of
jumps.
birtles: My concerns with frames, is
birtles: 1) very good in that context, not suitable in other
contexts, e.g. not a good name for gradients.
birtles: 2) Having a different function name for something very
similar can be confusing, e.g. frames() to a css
transition, has almost identical result to steps()
timing function.
birtles: Likewise there has been a proposal for a 4th type of
timing function where ... jumps happen at both ends of
the interval.
birtles: If we introduce that (seems likely) we'd do it as an
extension to steps.
<fantasai> Illustration of the 4 options:
https://github.com/w3c/csswg-drafts/issues/1301#issuecomment-310571203
birtles: Means we'd have 4 timing functions, 3 named steps, one
frames(), seems inconsistent.
birtles: Also frames() has bad discoverability, within devtools,
(autocomplete)
birtles: if you have a steps() timing function, and doesn't quite
look right, you'd just try and change arguments in that
function, not easy to "find" the frames() TF instead.
birtles: Concerned that they wouldn't discover frames();
birtles: and then would have to use a different way of counting.
birtles: My preferred way of doing this would be to extend steps.
birtles: Even though we know that way of counting isn't ideal
for the particular use case of a repeating frame-based
animation that doesn't go back to where it starts.
Rossen: So looking at the community twitter that Rachael did,
frames() was solidly a preference from designers.
fantasai: They are only concerned with what they do in isolation,
not considering the need for consistency with the rest
of CSS.
fantasai: I agree with birtles points, agree that its easier to
learn the set if its an extension to steps() instead of
a new function, (frames())
<fantasai> Was pointing out that polling people for their
preferred syntax for that particular use case isn't
going to take into consideration the interaction with
the rest of the system, which is our job here in the WG.
<fantasai> For people who want a function to do the one thing that
they're trying to do, yeah, frames() might be nicer.
But in general people have to learn more than just the
one case
<fantasai> and then for almost the same but not quite cases, they
have to switch to steps()
<fantasai> which doesn't seem very helpful
birtles: If you are animating a spinner, and its rotating, you'd
want a steps TF, if you use frames() it'll double the
length of the other points.
Rossen: So the current name in the spec is steps()?
birtles: No frames()
Rossen: Any other opinions? otherwise can resolve and move on....
Rossen: No?
Rossen: Any objections to renaming frames() to steps()?
birtles: We'd still need to work out the name of the argument.
birtles: Some of the proposals have been distribute.
astearns: We could resolve on using steps, instead of frames, and
work out param names separately.
fantasai: <showing examples on github issue>
fantasai: <https://github.com/w3c/csswg-drafts/issues/1301#issuecomment-310571203>
fantasai: These are the four options under consideration for this
set of timing functions. The first two exist already,
the second two are proposed.
Rossen: Are there any objections to renaming frames() to steps()?
fantasai: In favour.
<astearns> +1
RESOLVED: Renames frames() to steps(), argument name TBD.
fantasai: The next thing is that we have the 'start', 'end'... we
need two more keywords.
fantasai: We need to be clear of the distinction between the two
new keywords.
fantasai: Proposal to use the space keywords, which we use for
distributing space, e.g. 'space-between', 'space-evenly'
fantasai: Could also use 'space-around'
<astearns> inside/outside, inclusive/exclusive also mentioned
fremy: space-around only has half of the space....
fantasai: We could space-* keywords, could use another word other
than space?
birtles: Could drop the space- prefix, e.g. between, evenly, etc.
dino: I'd prefer that anyway, we are going to have to look this up
anyway.
fantasai: At least you've learned alignment, then we can transfer
the knowledge to different area.
<tantek> I've read the entire github issue and I'm still not sure
about which of the options are better.
astearns: There is the option using the start, end syntax, to
start, end, both, none.
dbaron: start, end made the most sense for 1 step keywords;
not as helpful for multi-step cases
<Bert> ('center' seems nice and short, transition in the middle
rather than at the start or end...)
<general talking about arg names>
Rossen: We can always continue this in the discussion.
Rossen: We are already going against Tab's strong pushback, it
also doesn't sound like we have clear winners on arg names.
birtles: Could we at least list the current candidates?
birtles: 1) distribute and justify naming.
Florian: 2) distribute and stretch
birtles: 3) space-evenly, space-between
dbaron: 4) center, stretch
birtles: 5) both, neither
Rossen: 6) trim-start, trim-end, trim-both, no-trim*
Bert: 7) short, long.
astearns: 8) include, exclude
fantasai: Problem with distribute and justify is that they are two
words that mean almost the same, and aren't used to make
a distinction anywhere else in CSS.
fantasai: (We also have text-justify: distribute as a legacy
thing, which is really not helping here)
fantasai: Problem with using center is that both space-around and
space-evenly are centering methods, but they are
different. It's not clear which one this is.
<fantasai> I really don't like 1/2/4/7.
birtles: Don't like the trim names b/c when you use them you
typically don't drop the endpoints, you see the endpoints.
Rossen: If folks are passionate about this, they can take this
offline, and come back to the group, I really want to
include TabAtkins, unfortunate to re-resolve this later.
<fremy> My pref would be 3 or 4
Rossen: Let's close this, if we have a clear set of keywords by the
end of the F2F, we can resolve on a later day.
CSS Counter style issues
========================
Compute missing counter styles to 'decimal'
-------------------------------------------
<astearns> https://drafts.csswg.org/css-counter-styles-3/issues-cr-20150611
<fantasai> https://drafts.csswg.org/css-counter-styles-3/issues-cr-20150611#issue-7
<fantasai> https://lists.w3.org/Archives/Public/www-style/2016May/0076.html
fantasai: This is about using a counter style which hasn't been
created, its kept around and defaulted to decimal.
fantasai: Proposal was to compute it to decimal, not keeping
around the name.
astearns: Seems fine.
fremy: Why would you want to do that in the first place
Rossen: Simplifies code, xidorn also said this wasn't a big issue.
fremy: It would for use require a lot of code.
fremy: Need some code which would replace the computed style.
fantasai: Computed style isn't just used in the om, also has to
inherit.
fantasai: I'm not sure why it would be harder to switch unknown
values to decimal.
fremy: In edge you don't need to store a computed value, if you
have a specified value.
fremy: When the style is being defined you need to it is going to
change the computed style a bunch, you need to invalidate
all the styles on the page.
<fantasai> Basically what François is saying is that if you use an
undefined counter style, and the UA computes it to
decimal, and then we append an @counter-style rule
defining the counter style, this invalidates the
computed styles
Rossen: Going back to the issue,
Rossen: xidorn didn't sound too insistent on it, TabAtkins said
whatever, which ever way is more consistent.
Rossen: At least 1 impl, which will require more cycles to support
this, can we live without the simplification?
Rossen: I'm mostly interested in mozilla folks.
fantasai: You need to hear from mozilla, and anyone else who is
going to impl this.
Bert: Is it possible for an unresolved name to define later in the
tree.
fantasai: No its global scope.
Rossen: Since fantasai is looking for resolution, can we resolve
to not simplify? Anyone objecting?
dbaron: Would be good to hear for xidorn ....
Rossen: He didn't think it would be a big deal....
RESOLVED: No change to CR; revert the change to the Editor's draft.
ACTION TabAtkins revert change in ED
<trackbot> Created ACTION-853
DOC “in the document language” imprecise
----------------------------------------
fantasai: Issue is - The language which counter is read out ...
fantasai: It currently says the document language, but you probably
want the language of the element instead, since in a
multi-lingual document you would end up randomly picking
one of them.
fantasai: Another option, is the user-agent language...
fantasai: 1) Element language.
fantasai: 2) User-agent language.
Rossen: 3) Use the Root of the scope of the counter style language.
<dbaron> So we're discussing
https://drafts.csswg.org/css-counter-styles-3/issues-cr-20150611#issue-4
,
right?
Rossen: If you have a list which is in English, in the middle you
have bullet points in French, since the scope is in
English, all of the counter styles will be based on the
root (English).
Rossen: The local elements language makes a lot less sense that
the other two options.
fantasai: Which options?
Rossen: Document, or root of scope
fantasai: More likely to have a problem with the document language.
fantasai: A document language is freq. English as someone uses
that at the top level, when you have multiple languages
in the document,
fantasai: Either that language is untagged,
fantasai: Or the surrounding context, is in the language of the
list themselves.
fantasai: The chances that you tag it on the <li>, more likely
that you tag it on the <span> inside.
fantasai: Document language is a bad option for this.
Rossen: Doing something special for the counter styles, e.g. using
the user-agent, doesn't make any sense.
Rossen: I gravitate to using the scope of the list.
Rossen: Rather than using the document.
Rossen: If we base it on the element, .... I cannot predict if
thats going to be awkward or not.
Rossen: The list makes the most sense.
fantasai: Element would be easiest, as you don't need to carry the
language through the tree.
fantasai: If you have a counter which you don't set the scope on,
its global ....
fantasai: Right now counters are just numbers: the counter style is
attached at the time you read out the counter, it's not
associated with the counter itself.
Rossen: The current algorithm requires a lot of walking around the
dom tree....
Rossen: Figuring out the language is one of those steps, if we add
a little for counter styles, its not going to add a lot to
the existing algorithm.
Rossen: The element would be simplest for sure....
Rossen: Unfortunately the a11y folks don't care if that alg is
complex...
fantasai: Other problem is what is the scope of the page counter?
fantasai: Is it the document itself?
fantasai: Best solution is the local element scope, as simplest to
implement.
fantasai: Easier to figure out the scope of the list.
fantasai: Gives authors the most control as can set the language
of the element itself
fantasai: and also the scope of a counter, in general, is not
particularly straightforward to understand.
Rossen: We can do the simplest and see what the pushback for the
a11y, i18n wgs are.
Rossen: I wouldn't dismiss the fact that there will be mixed
content inside of lists.... might not be an edge case.
<fantasai> Rossen's example was code listings with line numbers,
and comments in Chinese
Rossen: We can live with this decision....
Florian: Would make sense for counters to follow before afters,
just tied to the element.
Rossen: Proposed language, the language of a counter is computed
based on the language of the element that the counter
applies to.
fantasai: ... at the point of retrieval...
fantasai: e.g. target-counter() takes a counter from another
element and displays it as text on this element
fantasai: We don't bind counters with styles at the moment, you
need to specify the counter-style where you are
displaying the counter
fantasai: Did you (Rossen) mean that we would use the language of
the counter's element here or the language of the
displaying element here?
Rossen: The displaying element
fantasai: OK, just want to make that clear.
<dauwhe> what element does a page counter apply to?
<astearns> the element that establishes the page fragmentation
context?
<Rossen> dauwhe, <page>
Florian: Good when you have elements, but page counter, inside of
a page, you don't have an element.
Rossen: What are you computing the description of?
fantasai: Language that you read other content in the margin box
in.
Rossen: How is this going to be selection be an a11y tool? In
order to make the selection you need something selectable.
Florian: But what's that.
fantasai: Probably the document language, but I don't think it's
defined...
Rossen: Whatever this is in the DOM, whatever it is in the DOM.
koji: Selection is defined as DOM range.
Florian: There is no rule that an AT will just read the page
numbers when it flips through the page.
Rossen: However you choose to select it, use that language.
Florian: The answer is obvious then, it should be use the language
of the root element.
Rossen: If this is part of the UAs UI, then the UA should figure
out how to do it...
RESOLVED: The language of a counter is computed based on the
language of the element that the counter applies to at
the point of retrieval.
Florian: Is that defined for pseudos?
Rossen: I'm pretty sure it is, defined in HTML AAM.
<fantasai> I think the resolution actually meant "The language is
bound to the counter *style* from the element on which
it is used"
<TabAtkins> I'm going to object to this btw
<fantasai> TabAtkins: maybe you should object now so we know what
your objection is?
<TabAtkins> Hard to type right now
<TabAtkins> (I asked Rossen to move the counter styles issues to
later in the morning, sigh)
<TabAtkins> But I discussed this with you earlier in person
<Rossen> TabAtkins, are you objecting to the current counter
discussion or the frames()
<TabAtkins> Counter discussion.
<TabAtkins> Didn't see frames, will review it. 😀
<Rossen> ok, we can revisit when you're back
<fantasai> TabAtkins, that's what I thought so I was surprised it
was on the agenda this morning
<br length="10m">
Received on Sunday, 27 August 2017 18:56:59 UTC