Brief   Full   Jump  

Small
Medium
Large

Teal
High contrast
Bluish
Black

Sans-serif
Serif
Monospaced
Close
d
?
Styles

[CSSWG] Minutes Telecon 2016-12-21 [css-grid] [css-overflow] [cssom-view] [css-text-decor] [cssom] [css-color]

1 message.

[CSSWG] Minutes Telecon 2016-12-21 [css-grid] [css-overflow] [cssom-view] [css-text-decor] [cssom] [css-color]
Dael Jackson   Wed, 21 Dec 2016 20:28:14 -0500

www-style > December 2016 > 0076.html

Received on Thursday, 22 December 2016 01:29:13 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent 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. ========================================= Publishing next snapshot ------------------------ - Will-change, Variables, and Flexbox were mentioned as specs that should move to a higher status in the 2016 snapshot. - ChrisL will prepare a list of specs not mentioned in the 2015 snapshot to help the group discover any specs that should be included in 2016. Grid Items ---------- - The proposal on how to address stretching grid items in both directions is summarized in the github issue: https://github.com/w3c/csswg-drafts/issues/523 Anyone interested, especially from the design/webdev community, was asked to review before the next call (4 Jan). - Similarly, the proposal to correct the language around implied minimum size is summarized on github (https://github.com/w3c/csswg-drafts/issues/283) and edited into the spec. A resolution will be sought on the next call. - RESOLVED: Accept proposal from TabAtkins and fantasai in https://github.com/w3c/csswg-drafts/issues/767 Color properties should use "used value" as "resolved value" ------------------------------------------------------------ - RESOLVED: Make color properties return used value as resolved value. Overflow: Consider support for overlay scrollbars ------------------------------------------------- - The topic will be added to the F2F agenda and was renamed to 'Consider reserving space for scrollbars with some property' to avoid confusion. New feature - scroll-boundary-behavior (an extension of -ms-scroll-chaining) -------------------------------------------------------- - There was general support in formally specifying this type of behavior, but it wasn't ready for a resolution. - The latching behavior done by webkit and Chrome should be added to the proposal or at least able to be done with the properties. - It was agreed that the name will need to be improved. - This will be added to the F2F agenda. Should text-decoration-skip apply to overline and line-through? --------------------------------------------------------------- - RESOLVED: Ink skipping applies to overline and underline, but not line-throughs ===== FULL MINUTES BELOW ====== Agenda: https://lists.w3.org/Archives/Public/www-style/2016Dec/0073.html Present: Rachel Andrew Rossen Atanassov Tab Atkins David Baron Simon Fraser Tony Graham Dael Jackson Chris Lilley Peter Linss Michael Miller Florian Rivoal Jen Simmons Geoffrey Sneddon Alan Stearns Steve Zilles Regrets: Bert Bos Tantek Çelik Dave Cramer Elika Etemad Daniel Glazman Anton Prowse Scribe: dael Publishing next snapshot ======================== Rossen: Hello everyone. Rossen: First thing, any additional items? <ChrisL> https://drafts.csswg.org/css-2015/#css ChrisL: We said in the charter we'd publish a snap shot at end of 2016. We haven't quite made it, but I think that's fine. Looking at current WD I think there's a few things we could move from stable but not much tested. will-change, maybe variables ChrisL: I wanted to kick of discussion. What makes this different from last snap shot? Rossen: I think variables is a good candidate. Not sure about will-change for other implementations. Rossen: Blink? Mozilla? Rossen: Who is implement will-change? smfr: Webkit. dbaron: Gecko as well. Rossen: That's good. Do you folks feel we can move this up to ready but not much tested? smfr: I think that's reasonable. <dbaron> fine with me Rossen: k ChrisL: I think flexbox could move out of the not fully tested. Rossen: Sure. I think flexbox is fairly interop. ChrisL: I think so. Rossen: I'm not sure on Grid. Did Mozilla release it non-prefixed? dbaron: It hasn't yet, but plan is to ship not far in the future. Rossen: But in 2016 it will not. jensimmons: It's march. Chrome I think is also March. <jensimmons> Grid is slated to ship in Firefox 52, in early March 2017 Rossen: So it's a bit early. ChrisL: CSS Speech, are we keeping that in? ChrisL: I think it dropped off the charter. Rossen: I believe we agreed to continue work on this at CSS a11y TF. Rossen: I'd prefer the updates to come from that TF since that's the purpose of it. Since Speech is fairly a11y targeted it would be good to make it there. ChrisL: So leave it in. dbaron: I think it's interesting to look through things that aren't listed here. It's a little hard to do mentally. Rossen: You mean for new modules added? dbaron: Yeah. I'm guessing there's a module floating around we think is stable and not listed because we forgot. ChrisL: I think you're right. I can go through the WD list and make a subset of things not listed. dbaron: Yeah. I don't remember what's in color 4 or selectors 4 and if any of those should move up. ChrisL: Yeah. We should do a new draft of selectors 4 but that's separate. Okay. I'll kick of discussion by making the list of not listed things. ChrisL: It is hard to mentally do. Rossen: That would be great. Like round display is missing. Please also look at FX. <astearns> a list will be good to maintain for future snapshots as well Rossen: So you can take an action and then open an issue against the snapshot in github? ChrisL: Yes. ACTION ChrisL list all the specs not currently listed in snapshot 2016 <trackbot> Created ACTION-806 Grid Items ========== TabAtkins: Yes, I'll review them all real quick. Stretching image grid items in both dimensions ---------------------------------------------- TabAtkins: First is from Mats about stretching image grid in both dimensions. The spec was written where default stretches in both axes. For images that means you lose intrinsic dimensions. That's not expected behavior. TabAtkins: You could use start or end, but then you're at native size. Original suggestion was change behavior of stretch for replaced items so the stretch until one dimension his grid area. This was edited in, but after fantasai and I discussed we realized that the alignment properties would now be in charge of sizing and you then can't align the image in the dimension not filling the area. TabAtkins: That's clearly a bad solution. So the solution we proposed was to say 'normal' has different behavior on if the item has an intrinsic aspect ratio. If not it's stretch, if yes it's start. TabAtkins: So images are start, start. TabAtkins: If the image is potentially larger than the grid area you can use max width 100% and max height 100%. Then as sizing spec comes to it's own and exposes fill you can make small images fill a grid area. TabAtkins: Then you could have an image fill a grid area regardless if it's smaller or larger, maintains aspect ratio, and responds to align. TabAtkins: That's all written in the github issue. TabAtkins: Please review and let us know if you have opinions. Spec has been edited and we'll seek resolution in the future. Rossen: So next meeting is 4 Jan. Rossen: So this is mostly brought up as a call to action. Rossen: I went through your summary and it seems reasonable. Last time we discussed there was feedback from jensimmons and I think leaverou. I'd like to hear again from the design/ webdev folks to see if they consider this normal in their view. TabAtkins: Yep. Florian: I have a question. I didn't deep dive in, but have you considered instead of a magic value, using the magic value on object fit? TabAtkins: That doesn't do what we want. Mainly, object-fit isn't a natural way to resize. It doesn't have the desired effect on box-shadow or filters. Florian: Okay. TabAtkins: Yeah. It's good for a number of features, but not as a generic. Florian: Alright, thanks. Implied Minimum Size of Grid Items ---------------------------------- Rossen: Then let's got the the next. TabAtkins: Implied min size. Started with a question about what we meant for a particular clause on auto min size. We clarified that. TabAtkins: Restarting. TabAtkins: Flexbox introduced automatic min size to prevent things from shrinking too small. It also prevents shrinking to 0. Rossen: Yeah, it was meant to keep things in natural size. TabAtkins: There's similar use cases in grid. TabAtkins: It works exactly the same. It references flex definition. It had an extra clause where if your grid area spans tracks your min shouldn't be bigger then that. That was clarification on what precise size it should be because you need min and max track sizing. We clarified that. TabAtkins: It meant to talk about max track sizing function in the actual size. That's the first bit. TabAtkins: Should be a small clarification. TabAtkins: Second is based on further discussion the auto min size was happening too often and was making things grow in unwarranted ways. We decided only cases where we want auto min size is when something can get shrunk too small. This maps to tracks with an auto size. TabAtkins: If an item spans one of these it should invoke automatic min size. TabAtkins: [reads definition] TabAtkins: We believe this correctly captures the intent and keeps things from growing too small, but doesn't accidentally activate it and make things too large in other cases. Review would be appreciated. It's edited into spec and the issue has a good breakdown. Rossen: I did go through...you're saying I have an item that spans 3 columns. And they all have an auto min width. The middle track is auto, the others are 0. Rossen: At first the image size will be the min size of the image. Rossen: Then if I change the middle track from auto to be 1fr then all the sudden everything shrinks to 0? TabAtkins: No, using 1fr is the same as auto, min: 1fr. Rossen: So if I toggle between auto and fr in this case it will have no effect. TabAtkins: Yeah. Rossen: So if I make it a big size... TabAtkins: Or if you do min/max 0, 1fr. Rossen: And if the track has min-content? TabAtkins: It already has a similar effect. It will ask the item what the min size is. Rossen: And the item is spanning so it's contradiction to the track is all it's size. TabAtkins: I think so...we didn't touch that bit of the algorithm. Rossen: Okay. I think I'm fine with that. Rossen: So I think you're asking for review today and a CTA for everyone impl or interested to look at this issue and we'll revisit before F2F. TabAtkins: Yep. Automatic minimum size clamping by grid area should transfer through aspect ratio -------------------------------------------------------------------- TabAtkins: Third is a fairly small issue. If you're in a situation where you care about auto min size. You have an image 200px that spans 2 tracks that are min/max auto, 50px, auto, 50px. TabAtkins: We clamp the auto min size to that value because you've said no more than 100 px. So the image exactly fits. TabAtkins: Issue is in the older spec we didn't clamp the transferred size which sizes the height axis. So if width is a value you multiple through aspect ratio and get a preferred height. That wasn't getting clamped by this clause that limited to 100px. TabAtkins: So you would calculate transferred size by 200px. So we clarified that so all things surrounding auto sizing in both axis care about clamping. TabAtkins: At the end of the thread there's a clause to clarify. <jensimmons> I think I’ve encountered this bug, the one Tab is describing. It’s annoying. Rossen: Out of curiosity, aren't specified size and content size specified somewhere? TabAtkins: Yes. They're linked appropriately. TabAtkins: Read the quotes as being links. Rossen: That's fine. jensimmons: I've run into this bug so...yay, thank you! Let's fix it. Rossen: That is one thumbs up I'm hearing. Rossen: Anyone else? <rachelandrew> makes sense to me Rossen: Let's call for objections. RESOLVED: Accept proposal from TabAtkins and fantasai in https://github.com/w3c/csswg-drafts/issues/767 Color properties should use "used value" as "resolved value" ============================================================ Florian: I didn't raise this, but I have dependencies. Color properties are not listed in CSSOM as properties that use used value. In all implementations when you have currentColor you get a numeric value, not the keyword. Florian: This isn't due to poor implementation. Everyone is already doing getComputedStyle for color properties as used value. If we change this it will unlock a pending test case. Rossen: What spec? Florian: CSSOM. There's a list of properties and a definition saying that it's used value in specific cases. Color isn't listed. ChrisL: [missed] Florian: xidorn checked. ChrisL: I asked if this is what impl already do. Rossen: Yes. It's defining the standard. ChrisL: Would any tests change because of that? Florian: None I'm looking at. TabAtkins: Makes sense to me. I don't like expanding resolved value, but matching implementation is good. <dbaron> This is really fallout from the change that makes currentcolor a computed value Rossen: I'm hearing a lot of thumbs up. Objections to making color properties return used value as resolved value? ChrisL: Does it have any effect on color 4 and color 3 errata? Rossen: I would assume only OM. Florian: Yes. Only OM. There's a separate issue about CSS 3 and 4 saying different things about computed, but that's separate. RESOLVED: Make color properties return used value as resolved value. Overflow: Consider support for overlay scrollbars ================================================= <Florian> https://github.com/w3c/csswg-drafts/issues/92#issuecomment-251727301 Florian: I don't know if people remember, but we've discussed before. Florian: This comment summarizes where discussion went last time. Florian: Allowing authors to opt into variant behaviors with overflow: auto. You may want to reserve space on scrollbar. Or you may not want to if scrollbar is overlay. But if browser would need space you want to reserve it. Florian: We had 3 proposals. Does anyone else remember this? <gsnedders> remembers the discussion and remembers no conclusion Rossen: I remember the discussion and going through github I didn't see much since then. Florian: I think the conversation was just cut off on the last call. Having stagnated it could be interested to re-open. Florian: We had agreed on the behavior, but not syntax. The alternatives were a dedicated prop with 3 values or a long hand of the overflow with 3 values, or adding these additional values as switches to overflow. <dbaron> seems like this might be a good topic for a face-to-face meeting * smfr agrees with dbaron Florian: Are people ready to debate or is this too much off everyone's mind? smfr: Can we do it in Seattle? Florian: Sure, sure. I wanted to revive the debate. Rossen: I think there's plenty of interest so we should add it to the F2F. smfr: Can we object to the title of the issue? It confuses me every time. Florian: Do you have a suggestion? smfr: It's about reserving space for the scrollbar. Rossen: [changes the gitbub] Florian: So if anyone wants to refresh their mind before, the link I pasted is a good summary. Intrinsic size of replaced elements incorrect ============================================= <dael> https://github.com/w3c/csswg-drafts/issues/794 TabAtkins: Without fantasai I don't think we can talk about this. Rossen: This is similar to the first topic we did. I'm not sure this is separate. TabAtkins: It is. New feature - scroll-boundary-behavior (an extension of -ms-scroll-chaining) ======================================================= TabAtkins: This was created by Majid. Rossen: I see zcorpan added it, but he's not on. TabAtkins: I can discuss it. Rossen: Do we want to try and resolve? Yeah. Let's take it. TabAtkins: MS has had an unspecified prop called -ms-scroll-chaining Rossen: It was specified, but not documented. TabAtkins: Unstandardized. TabAtkins: Controls if you're scrolling and hit top or bottom if the scroll intent escapes or is stuck inside. TabAtkins: There's a lot of app cases where if you're allowed to escape it's annoying. That's why MS did it and we thought it reasonable to standardize. scroll-boundary-behavior: propagate | contain | none TabAtkins: propagate allows you to escape. contain traps scroll and does things like the android bounce. none traps you but doesn't do any indication. TabAtkins: Majid suggests specing in CSSOM View. zcorpan agrees on functionality. We REALLY need better names. Propagate is hard to spell too. TabAtkins: Concept-wise does this group feel we should standardize? smfr: Webkit has the scroll latching to a scrollable area. You latch in a single gesture. During the latch you scroll a single thing. If you're at the bottom and you scroll again you go to the parent. So there's a difference between the middle and the beginning of a gesture. This behavior should distinguish or say only at the beginning. smfr: Second comment is if you do scroll none you have the ability to not let a user manipulate the page and that's bad behavior. This impinges on where browsers may want their own behavior that lets the user interact in ways they prefer. I'd like good use cases for the three values. TabAtkins: I can before the F2F have Majid draw up example use cases of apps that mess up if scrolls chain. We also do the latching so I think we need to define to allow or address that. smfr: There's on use case from FB for example where the chat widgets if you hit the bottom you don't want to propagate for the page. That's a good use for none. TabAtkins: I think they're mostly cases like that where it's a mostly independent widget. Rossen: In our case when we had the demand any time there was a list involved...one of the initial design concepts that were mostly in windows 8 apps was that general scroll of apps was horizontal and the content inside was in vertical lists. There was a handshake between the two to propagate between vertical & horizontal. Rossen: Having these complex behavior and not capture scroll was difficult. I believe we have a bunch of examples we can dig out for the F2F if we're not resolving now. We'd support standardizing this going forward. Rossen: I also don't like the name. scroll-contain sounds nice. TabAtkins: I like scroll-chain. Rossen: Unless you're an implementor it doesn't resonate as much. <smfr> scroll-contain sounds overflow-related Florian: You described the containment of scrolling to be going up the chain. Can this be used in the other direction where you have a map in the middle of a page and you scroll the map when you meant do the page? Rossen: This will make it hard. So assume you have a bunch of iframes. When you gesture to scroll down your page scrolling will stop in a number of ways. It will be very confusing. How do you compute the sum of your scroll bar. The aggregated scrollable areas of all scrollers? And what if some are scrolled already. Propagating down is complex. Florian: I'm not saying it should happen. I think it does happen. Rossen: I think it only happens if it's the last one...I'm not sure. Florian: I'll research the problem better before raising it. Rossen: Doesn't sound like we can resolve on this. Rossen: We'll revisit as a part of the scrolling discussions at the F2F. Should text-decoration-skip apply to overline and line-through? =============================================================== koji: The proposal is to change text-decoration-skip to only apply to overline and line-through. Not strike-through. Webkit has this behavior. People on the issue seem to be on consensus. Florian: I think it makes sense. If you skip on strike through you mostly can't see the line. TabAtkins: Oh gosh yeah. I'm seeing the example image and...they're showing how you can't see a line through because it's obscured by the letter. TabAtkins: Saying overlines do skipping [missed] TabAtkins: Saying overlines doing skipping does make sense. koji: I think so. <leaverou> are there any use cases for skipping the line on line-through? Rossen: You said this is shipped by webkit? koji: Yes. smfr: Just underline. Florian: Why not overline? smfr: Because it's used on the web a million times more. Maybe we do overline. We do it, yeah. koji: So are you okay to resolve not to apply strike through? smfr: Yeah. It seems strike through should strike through all the glyphs. koji: Yes. And the specs say apply to overline. koji: smfr is fine to say apply to overline. Rossen: I'm hearing consensus. Anyone objecting? RESOLVED: Ink skipping applies to overline and underline, but not line-throughs Rossen: That's the end of today's topics and this year's phone calls unless anyone wants to bring a 4 minutes topic. Rossen: Any topics? Or should we adjourn. Rossen: Okay. Thank you all for calling. Happy holidays, happy new year, safe travels. We'll talk on Jan 4 and meeting Jan 10. Thank you everyone!