[CSSWG] Minutes Telecon 2017-02-15 [css-timing] [css-text-decor] [css-speech] [css-grid] [css-cascade] (original) (raw)

========================================= These are the official CSSWG minutes. Unless you're correcting the minutes, Please respond by starting a new thread with an appropriate subject line.

Request to publish FPWD of CSS Timing Functions

A new property for text decorations to skip ink

Create a display property value for visually hiding an element while making it available for AT

Stretching image grid items in both dimensions

Path to PR with CSS Cascade

===== FULL MINUTES BELOW ======

Agenda: https://lists.w3.org/Archives/Public/www-style/2017Feb/0067.html

Present: Rachel Andrew Rossen Atanassov Tab Atkins Dave Cramer Alex Critchfield Simon Fraser Tony Graham Koji Ishii Dael Jackson Philippe Le Hégaret Vladimir Levantovsky Chris Lilley Myles Maxfield Thierry Michel Michael Miller Rachel Nabors Simon Pieters Anton Prowse Melanie Richards Florian Rivoal Jen Simmons Geoffrey Sneddon Alan Stearns Greg Whitworth

Regrets: Brian Birtles Bert Bos Tantek Çelik Steve Zilles

Scribe: dael

A new property for text decorations to skip ink

astearns: We have plenty of people on the call. https://github.com/w3c/csswg-drafts/issues/962 myles: Is koji on? myles: If he's not on we shouldn't discuss. Rossen: People trickling in.

Request to publish FPWD of CSS Timing Functions

https://lists.w3.org/Archives/Public/www-style/2017Feb/0044.html astearns: That is something we had decided to do, but birtles is now ready to prep FPWD. Does anyone have any comment? +1 to publication ??: Yes, please I think it would be good to also get corresponding updates to Animations and Transitions onto /TR Otherwise in favor Last Transitions draft is from 2013 Last Animations draft is from 2013 These are wayyy out of date :( fantasai, yup...

Rossen: That's the timing functionality that was taken out of web animations? astearns: That and frames. Rossen: Let's do it.

astearns: Objections? smfr: Does this effect transitions and animations in that it removes text? ChrisL: I don't think so. TabAtkins: In a later publication we should probably remove them, but it doesn't have an immediate effect. astearns: And according to birtles it's just frames and he talks about new timings functions, not so much what's in transitions and animations. astearns: Again, objections?

RESOLVED: Publish FPWD of CSS Timing Functions

astearns: Should short name be css-timing or css-timing-functions lots: Timing, please astearns: Great. Short name is css-timing Florian: When doing FPWD and we resolve on a different short name than the ED what's the procedure for renaming in the short name? astearns: If it was just on draft server the short name was provisional. It's only fixed on FPWD. Florian: But there are incoming links. TabAtkins: We have redirecting if needed in the htaccess file. Florian, yes, inform plinss We used to have a .htaccess file We don't anymore TabAtkins, ^^^^^ plinss is maintaining redirects in a different system TabAtkins: css-timing hasn't been reffed much but we can set it up. astearns: [reads fantasai] TabAtkins: Well, we still have a system. Florian: Okay, thank you! TabAtkins, yes, but it doesn't work by editing a file in the csswg-drafts repo... wish it did

A new property for text decorations to skip ink

https://github.com/w3c/csswg-drafts/issues/962 koji: This is about the resolution to add text-decoration skip ink to L3. koji: This is a proposal. 2 discussion points. 1 is property name. Is text-decoration-skip-ink appropriate? Since we don't do text underline-skip would be better. koji: Other is about values. fantasai said auto|yes|no pretty sure she didn't say yes | no as keywords to use ...

Florian: Related is if it should be part of the L4 shorthand. If it is it should start with the same thing. If it's not we can be more creative. Should not be part of shorthand It should cascade independently koji: I'd prefer not to make short hand because this is styling decoration underlines. Rossen: I'm trying to understand...this proposed behavior is supposed to describe what webkit currently does for text decoration underline? myles: For skip ink yes Rossen: And you (myles) do this auto for text decoration underline? myles: I don't remember exactly. Rossen: Let's assume you're doing it at least for underline. Is it done unconditionally? There's no additional optional values? myles: Conditionally where you can turn it off. The initial value was changed to ink so users can use a value of off. Florian: But if it's on it's always on? auto or yes? myles: We do auto because we have special CJK behaviors were we turn on/off at a glyph level. Rossen: That sounds good. Rossen: Thank you. Rossen: Both skip and auto make sense in how you desc them. text-decoration-ink: skip | no-skip ?

koji: Ink has same behavior in beta(?). myles: I don't have many preferences. I just have that the auto keyword to do what I described should not go away. koji: I agree. We're interested in opt out and opt in. Florian: Do we need all three or auto and don't skip? myles: Currently webkit it's impossible to skip on CJK. Rossen: But you can opt out of the auto with the non-skipping version? myles: Yes, you can opt out Florian: So you have 2 values. Do we want 2 or 3? myles: The reason we decided to never skip on CJK is because it looks terrible more or less always. But my preference isn't strong. Rossen: We shouldn't make bad decisions easy. Florian: Adding a value later isn't hard astearns: We can do auto and no for now. If a need appears later to force it we can consider it them +1 myles: I think that's a good idea.

Florian: I think that helps with naming. In that case having text-decoration-skip: auto makes sense because it knows not to do line-through. Florian: That also depends on koji's point about no short hand. I didn't understand why. koji: I think you had an example that most of the other properties apply to a specific element but skip-ink applies to root elements Florian: mmm...okay astearns: And fantasai put in irc that they should cascade separately. I'm not sure the reason.

astearns: I'm not hearing a strong desire to change the name to underline. astearns: I think we should keep the name as text-decoration-skip. Florian: Even if not part of the short hand? fantasai: Behavior is a lot more like text underline position. You'll want to set it at a higher level for how you want to behave for the document. Turning on and off for the underline is separate. Thus they shouldn't be conflated. Florian: Then they shouldn't have same prefix. fantasai: Yeah, in general we try that but something is closely related will share a prefix and not be in the shorthand. astearns: I would prefer the same prefix so you don't have to remember a different word. And it's easy to remember difference because people will be using it differently. koji: We have text-emphasis where it's not in the short hand. I think if this should be in the short hand can be separate. Florian: It's intuitive enough.

Florian: Can I suggest off instead of no? myles: None? Florian: That's fine too.

Rossen: Can we summarize? Rossen: I've heard it's text-decoration-skip: auto|none text-decoration-skip-ink: none | auto astearns: I think it's text-decoration-skip-ink koji: yes I'm provisionally OK with this. Need to think about integration with other text-decoration-skip values. ✅ astearns: proposal: text-decoration-skip-ink: none | auto with auto as the default. Rossen: Reason to not remove ink? Florian: There's a level 4 that skips in other places. Ink is a sub case that's in level 3. Rossen: So...I see. https://www.w3.org/TR/css-text-decor-3/#text-decoration-skip-property

Florian: Should we define what auto does? myles: No. :) Florian: There has been discussion on github that auto shifts the baseline. I don't think it should do that. koji: That was a misunderstanding. myles: If we don't define auto UA can tweak. Florian: I'd rather UA not to use skipping for positioning. agreed Rossen: Aside from bikeshedding I think these are good things to agree on.

astearns: Is text-decoration-skip-ink with values as none|auto with auto default...is anyone opposed? fantasai: It's okay to me. I'd like to think about how it integrates with other skipping, but it's fine for now. We should note that it's not in the shorthand. astearns: Yes, and I believe how it works with the rest is for the next level. dbaron: So that's saying that impl are expected to turn it on by default upon impl. dbaron: We're saying that there will be no way to opt into more skipping than default. Rossen: As of now, yes. astearns: For this level. We're doing the minimum to finish this level of text decoration. We'll add more later. dbaron: Okay. It feels a little odd to introduce it as a change in behavior rather than opting in to the different behavior Florian: As part of peopling auto to UI does that make it non-testable? Because then auto could be same as none. astearns: I would prefer having some suggestions that it SHOULD skip ink in roman but not Arabic. astearns: I'm not sure that the impl notes should be normative. Florian: If we don't we can go to rec with no impl. Florian: That doesn't sound helpful. myles: If there are non-normative or normative notes they shouldn't list every language. Maybe a couple of examples are valuable. Saying which language should and shouldn't shouldn't be in spec. I should say script, not language. dbaron: On the other hand then you're asking impl to figure it out. So 4 teams do it. myles: The teams can talk. astearns: I'm not sure any team has an exhaustive list. Florian: We can have a base case and exceptions. myles: We can say it's expected to skip in Latin and others are up to UA. Florian: Yes. Can that be a must?

astearns: Objection to having a normative must on skipping ink in Latin cases? ChrisL: It's not an objection, but it comes across that this is the language we care about. I know that's not the intention but it sounds a bit awkward. I don't have a better suggestion. +1 to ChrisL ChrisL: I just have a slight concern. We could ask i18n for help. fantasai: It would make more sense to go the other way and say skip ink for everything except cases where you know you shouldn't. This is mostly on or mostly off. If we want to make an exception for if there's a case where you think it looks bad you can not do it. But it should clearly say if you don't know what to do you should define what to do dbaron: Saying do it is awkward for something that will be the default. dbaron: If it were an option dev turn on that's fine. But given that the default is skip ink we need to gather a list where it would look bad. Like, say, is skip-ink desirable for Kannada? or Malayalam? dbaron: I think it is desired for South Asian and Southeast Asian scripts. The ones I've investigated use it. fantasai, those in particular have different sorts of descenders, which is why they seem interesting (and different from many North Indian scripts) dbaron, http://scripts.sil.org/cms/sites/nrsi/media/LannaThai.png

fantasai: I would prefer on and off and if you want to do it language dependent you can do it that way. Florian: It's glyph based. myles: We found it looks terrible in too many cases with untagged docs. Rossen: The huge benefit is when it comes online and it just works. When I've seen it on Apple it was cool to see it. No authors had to do anything. I agree we need to do better homework for when to turn it off by default. I don't think we need to decide it this moment. Rossen: We'll continue working on this feature. I think we can wrap up by agreeing to adopt the properties and values and then continue tech details of auto's definition. Florian: In general I agree. I want to add a nuance. I'm okay with doing homework later. I don't want to call it done in L3 without an explanation.

astearns: Things are going in circle. I think we should close for now. I do believe we can resolve we're using text-decoration-skip-ink with at least values of auto and none and it cascade separately from shorthand. We will have some normative text describing how auto works, but we'll figure the details out in the future. astearns: Objections to leaving it there? fantasai: The spec is in CR. The goal for me has been to wrap up issues and do a stable CR. Maybe it should go next draft. astearns: That's possible. astearns: Would there be objections to moving this to next level? Rossen: Once we accept we can move it back in to L3 Florian: I'm okay with L3 or L4. It just needs to be with its defined normative behavior. +1 to Florian

astearns: Proposed resolution: everything before in L4 astearns: Objections? koji: Webkit has a separate behavior we had the ability to opt out and this removes the ability. astearns: I think this is process. We're defining it, it's just in a next module level so we can get to the current impl interop things done. Florian: L4 isn't an ED yet astearns: I'm hearing no objections I really object to having "no skipping" and "maybe skipping, not sure if we want this to be mostly skipping or mostly not skipping" If it's "no skipping" and "skip unless it's really bad"... I could deal with that.

RESOLVED: Use text-decoration-skip-ink with at least values of auto and none and have it cascade separate from shorthand. We will have some normative text describe how auto works, but we'll figure the details out in the future. Do this in L4.

Create a display property value for visually hiding an element while making it available for AT

https://github.com/w3c/csswg-drafts/issues/560 fantasai: I think we decided not to do anything. This was really if we wanted to do anything with speak or speak-as. There may be further discussion on this draft, but I don't see solid proposals. Maybe republish CSS Speech. astearns: Anyone have something more to add? astearns: Shall we resolve to close the issue? fantasai: I would say do we want to republish CSS Speech CR. astearns: With what changes? fantasai: We renamed some values and def they're effected by visibility. We did that last month astearns: Objections?

RESOLVED: Republish CSS Speech CR

ChrisL: New features, or just text? Do I do the non-technical? fantasai: It's non-technical ChrisL: DoC? fantasai: I can update in 5 minutes; there were only 2 issues. ChrisL: And a changes section? fantasai: Yep. ChrisL: Thanks.

Stretching image grid items in both dimensions

https://github.com/w3c/csswg-drafts/issues/523 fantasai: The discussion we had in Seattle...Mats said it was unclear if we're distinguishing by if it's replaced or has an aspect ratio. TabAtkins and I thought it should be based on if they have an aspect ratio. Images that don't generally take their size from the container anyways. fantasai: We need to answer what happens to an image that has no aspect ratio & no size. fantasai: An SVG with no viewbox, width, or height fantasai: Other question is what if it just has width. Rossen: For SVG these things are defined in integration spec. The internal sizing algo for all the permutations. I don't think there's anything new that will be added for SVG. Rossen: You can word it so SVG is treated as non aspect ratio image and it won't effect sizing in SVG. It's just a choice of which to we apply in SVG. fantasai: Only thing that really makes sense if for it to take the size of the fixed size grid container. That's what we do in blocks when we can. Rossen: I think this is reasonable.

Rossen: From text POV if we tried to make a distinction between what applies with and without intrinsic ratio this isn't the place. If we want the spec to call out this applies to when it has an intrinsic size and this is when it does and leave out the definition for another spec. fantasai: Right. We don't say when, but we define different behavior for when it has one and when it doesn't. Rossen: From what I understand Mats pushed back this isn't well defined in grid? fantasai: We had defined it and Mats pushed back it didn't match what was resolved in his understanding that all replaced elements have one behavior which is the shrink to fit. Rossen: I think if we change the wording to refer to replaced elements with an intrinsic ratio it solves both issues. Rossen: Does that sound right? fantasai: I need to look at the wording. astearns: As much as I'm following, we need a resolution that our previous resolution only applies to replaced elements... Rossen: The other way. It currently applies to all replaced elements. https://github.com/w3c/csswg-drafts/issues/523#issuecomment-275869984 fantasai: Here's the comment ^ fantasai: [reads] dbaron: Yep. dbaron: I think Mats' point is he wants the WG to resolve something that matches what people put in the issue. Since there have been previous edits where edits and the resolution diverge. He's sensitive that edits and resolutions can diverge and he's pointing those out. Rossen: Yes. That's a valid point. Having a tighter definition of which replaced elements will be good.

fantasai: There's two questions we need to resolve [reads] The two questions we need to resolve are https://github.com/w3c/csswg-drafts/issues/523#issuecomment-277103785 fantasai: First should get stretched.

astearns: Before we get to the questions don't we need to resolve that we meant the previous resolution to only apply to those with an aspect ratio. astearns: What is the THIS that only applies to things with an aspect ratio? Rossen: Instead of stretch we respect the intrinsic ratio. [looks for exact previous resolution wording] Items without an intrinsic ratio use, in both axes, the width calculation rules for non-replaced block boxes as defined in CSS2.1 § 10.3.3. (Meaning, auto values in either axis are effectively sized to fill the remaining space.) However, the box alignment properties have special effects: when align-self/justify-self is neither normal nor stretch, an auto size for the grid item in that axis is treated as fit-content instead of as the stretch-fit size. Se[CUT] Items with an intrinsic ratio follow the same rules, except that in the case of a normal alignment value, an auto size for the grid item is sized as for align-self: start (consistent with the width calculation rules for block-level replaced elements in CSS2.1 § 10.3.4). fantasai: Current spec text^ Rossen: The resolution says we're keeping the current behavior as-is. astearns: What's the change to satisfy Mats? TabAtkins: We talked about replaced elements when we meant those with aspect ratio. Resolving that. Then some questions falling out from that. Rossen: Reading from fantasai text we're talking about [reads] This is talking about intrinsic ratio. fantasai: That's not what was in the minutes so Mats wants confirmation. astearns: Proposed resolution is that the sentence pasted above is what was intended from the Seattle resolution and we resolve on that text. astearns: Objections?

RESOLVED: The sentence beginning with "Items without an intrinsic ratio use," is what we as a WG wanted to use.

astearns: Okay, the questions. fantasai: We didn't really talk about the first case. It makes sense to me that the axis with an intrinsic size should follow the second clause. In the dimension without a size it behaves as stretch. astearns: So that first sentence would be that items without an intrinsic size in the axis.... Rossen: I'd rather say items with defined size in only one dimension, that dimension is start and the other is stretch. fantasai: I'm happy to word smith, but if we conclude on the behavior. Rossen: Proposed: replaced elements with only one intrinsic size are sized as start in that dimension and stretch in the other. ChrisL: I think that makes sense. astearns: Replaced elements with one intrinsic size and no aspect ratio. fantasai: Yes. astearns: Objections to Rossen proposal?

RESOLVED: Replaced elements with only one intrinsic size are sized as start in that dimension and stretch in the other.

astearns: We'll let the editors get that into the spec text. Rossen: fantasai you doing this? fantasai: I'll do the edits.

Path to PR with CSS Cascade

https://lists.w3.org/Archives/Public/www-style/2017Feb/0067.html astearns: Main thing is drops scoped styles. TabAtkins: Which is due to support. FF might impl, but no one else is planning on them. dbaron: We are keeping our impl for now. fantasai: It is also defined in cascade L4. astearns: If we drop from level 3 would we also from L4? fantasai: We can decide on that once we're blocked on PR. Do we have 2 implementations of revert keyword? fantasai: That's the main new thing on L4.

astearns: Objections to dropping scoped styles from current level of css cascade?

RESOLVED: Drop scoped styles from current level of css cascade.

fantasai: We need action items for getting impl test into the repo. fantasai: If no one wants to import tests they can point to where the tests are so someone else can import. fantasai: If we don't have tests we can't go to PR. astearns: Anyone willing to take an action item? TabAtkins: I can find the ones for us.

ACTION TabAtkins to find cascade tests

astearns: I guess we'll see if the blink tests are sufficient. I'd like more participation since we don't do enough compiling of test suites. I'd rather volunteers. fantasai: What I can do is I can grab and import the Mozilla tests and they have 2 copies. dbaron: I'm having trouble finding tests. The only tests I know we have are mochitests. dbaron: You can't import those. fantasai: If you can drop in the URLs we can look to try and convert. fantasai: Then it's more solvable of a problem. astearns: We're over time. Thanks everyone for calling in.

I'd like to take this opportunity to remind people to watch the csswg-test Pull Request queue. There's quite a bit of tests there sitting and waiting. +1 to Florian


Virus-free. www.avast.com

Received on Thursday, 16 February 2017 01:32:55 UTC