- 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