- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 27 Jan 2016 18:56:28 -0500
- 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. ========================================= Missing named line search ------------------------- - RESOLVED: Accept the new language as suggested in option B of this e-mail: https://lists.w3.org/Archives/Public/www-style/2016Jan/0063.html Snap Points ----------- - There were still concerns about avoiding behavior that feels bad to a user when using 2D scrolling, especially when combined with mandatory. - RESOLVED: Bring 2D snapping into the spec and mark as at-risk. - There were varied opinions on if there needs to be more terminology around the viewport to distinguish between different types. - MaRakow reported he wasn't blocked on this, so a decision wasn't needed right away. - It was agreed that the viewport terminology should be defined in device adapt, overflow, or the viewport specs. - fantasai explained that she believed having scroll-snap-padding and scroll-snap-margin physical and scroll-snap-align logical makes sense because scroll-snap-align interacts with the scrollers which operate in logical direction. - MaRakow felt that her example case didn't deal with the case when the user sets two properties on a 1D scroll. He'll make another example case to further the conversation. - The bikeshedding of the properties currently called 'mandatory' and 'proximity' will happen at the F2F, but it was agreed that the names should be improved. - The short conversation on splitting scroll-snap-type seemed to indicate approval of the split, but naming will wait until the F2F. Group Reminders --------------- - Please remember to reply to the e-mail about spec publications (available here: https://lists.w3.org/Archives/Member/w3c-css-wg/2016JanMar/0014.html) - Also, please continue to continue reviewing tests to keep the testing backlog small. ===== FULL MINUTES BELOW ====== Agenda: http://lists.w3.org/Archives/Public/www-style/2016Jan/0250.html Present: Rossen Atanassov David Baron Dave Cramer Alex Critchfield Elika Etemad Simon Fraser Tony Graham Dael Jackson Brad Kemper Simon Pieters Anton Prowse Matt Rakow Francois Remy Florian Rivoal Lea Verou Regrets: Tab Atkins Daniel Glazman Peter Linss Myles Maxfield Edward O'Connor Alan Stearns Ian Vollick Greg Whitworth Scribe: dael Missing named line search ========================= Rossen: Let's get going. Rossen: Do we have any additional agenda items? <Rossen> https://drafts.csswg.org/css-grid/issues-wd-20150917#issue-26 fantasai: The named line search as described in the email was doing some non-consistent things. We changed the rules and wanted whoever was interested to review. This was the last week to review so if you didn't want to you didn't. I won't go over them. Rossen: We went over it on our end. <Rossen> https://lists.w3.org/Archives/Public/www-style/2016Jan/0123.html Rossen: The edits and the conclusion captured in this thread (above) makes sense. Rossen: We're good with that resolution. fantasai: Did we resolve? Rossen: We can sure. Do we have enough other implementors? Anyone from webkit who can look or Mozilla? fantasai: It was raised by the Mozilla implementor so they should be okay. TabAtkins and I made the change so I'm assuming webkit is okay. The webkit implementor said on the thread they liked it. Rossen: Okay. Do we have any objections? RESOLVED: Accept the new language as suggested in option B of this e-mail: https://lists.w3.org/Archives/Public/www-style/2016Jan/0063.html Snap Points =========== 2D Point Snapping ----------------- Rossen: Keep, drop, or at-risk? Rossen: Who wants to take that? MaRakow: I can speak where it is. We talked to...Apple spoke to their concerns about the complexity at the Japan F2F. I was going to omit it, but Google wanted it on the table. I don't have a super strong opinion, but I'd like to decide to keep or drop now. Rossen: We don't have to resolve to keep if it's there. If you want drop or at-risk we should resolve. MaRakow: It's not in the spec, but in the TabAtkins and fantasai proposal. Rossen: It's not part of an official spec. So if we want to add it let's resolve. Florian: I'm not sure I agree because we've agreed to align to the proposal. I'd rather a resolution either way so that we don't have to debate which spec is official. Rossen: We have an official one and it's part of our charter. There's changes being brought from the proposed spec. We did resolve to have the slow combining of the spec. As the wording from last week's resolution is masterfully crafted by fantasai, we're not rubber stamping, we're moving many of the terminology pieces. Rossen: The topic was brought to the group to see if this part of the spec is to move forward or put at-risk. * fantasai thinks the point of Florian's comment was to avoid this topic. Rossen: So, what is the proposed resolution at this point? MaRakow: I'd not resolve at this point, but leave it out, but I wanted to make sure everyone had a chance to speak. fantasai: We'd prefer leave it in and marked at-risk. I think a big part of Apple's concerns was from unclarity and we've clarified. TabAtkins and I believe there are reasons to keep it so we'd prefer in the spec and at risk instead of drop it. <Florian> +1 to fantasai Rossen: So the proposal is to move it into the WD and mark as at-risk. MaRakow: fantasai, do you have what would remove it from at-risk in either direction. fantasai: at-risk is in the draft and gets dropped if there isn't sufficient interest to implement. The WG likes it and thinks it's a good idea but it needs implementor interest. MaRakow: So keep or cut depends on if there's other implementations when we want to go to PR. Florian: Yes, if it's not implemented we can drop it quietly. If there's implementations we keep. smfr: My concern isn't implementation complexity, but experience. We do axis locking on scrolling. My concern with 2D is you have a situation where you're scrolling on one axis and 2D will move you on the other axis. I want implementation that doesn't feel bad to user. A polyfill to implement this behavior may help us see what it feels like and work out details in JS form. Florian: I don't think spec requires you go off axis, especially if you're in proximity. What proximity means is up to you. smfr: But mandatory + 2D would feel weird. fantasai: The intended use case is for something like a 2D map where you want to pan. A map or a planet or a game where you're going between worlds in 2D. If you're doing scrolling with a scrollbar it will be awkward. It's intended for other cases. smfr: So what about when a user without a trackpad encounters content like that? Florian: I think a map like that with proximity is logical, but mandatory can be odd. fantasai: You have that problem without snapping. If you're navigating something like the Super Mario Bros map with a scroll wheel it won't work. smfr: So I prefer to mark it at-risk. Once we have an implementation we may not like it. fantasai: Seems good to me. Rossen: So, resolution is to bring it into the spec and mark as at-risk. Rossen: Objections? RESOLVED: Bring 2D snapping into the spec and mark as at-risk. Viewport Snapping ----------------- <Rossen> https://drafts.csswg.org/css-scroll-snap/issues-2015-12#issue-6 MaRakow: This is talking about the terminology in the spec for the scrollable region in question. Is it a visual viewport or a new term? fantasai has proposed scrollport, I think. There was debate on that. MaRakow: The visual viewport implies some of the shared technology the browsers have for UI and what's viewed by the user. The content you see on screen is the visual viewport. That's the term in the spec. fantasai: It wasn't clear to me that viewport was being used for the scroller rather than the main root. And we have places in our syntax where we use viewport to refer to the root viewport. fantasai: The issue is that we need a new term for the portion of the viewport that is the boundary of snapping so we wanted the active region used for snapping for this viewport. We were discussing terminology for that. I'd heard scrollport in a couple of places. So that could be the viewport of any scrollable box. The root is the only place that has the distinction. So do we introduce it as the visual viewport and the viewport of all scrollable divs. Florian: I think I'm in favor of fantasai's proposal because it's complex enough to need to understand and hard to learn. If we can keep the terms clear I think it will make CSS more learn-able. MaRakow: The visual viewport only pertaining to the root may not stay true. One item we added back in IE10 was to declare a region with overflow as zoomable. I think that's functionality we'd like to introduce and that has zooming at the root and sub elements. MaRakow: I wouldn't expect that the split in the long-term be unique. I think if we want to distinguish between root and element viewport, we might want to specify the root for vw and vh Florian: It's also meta-viewport, @viewport MaRakow: Right. All those things we'd want to distinguish. <smfr> iframes have viewports too Florian: We would need to disambiguate all of CSS at that point. Florian: I think a hierarchy of terms for visual and root and another term that's for scrollable...these are clearly related...but keeping layout as the root is more clear. MaRakow: But then there's still the case for sub-elements. You'll have visual and layout and scrollport and then there's too many terms for the number of concepts. Florian: Do you need to have zoom for this to matter? You have an element that's overflowing and scrollable MaRakow: Only case where they're different dimensions is when you have a zoom, currently. You can imagine other features, but that's the big one. Rossen: It also makes the difference...most obvious is any container that can position fixed position. The root viewport, but also iframes. We also have a device:fixed positioning which is similar to fixed but doesn't get effected by zoom so any UI you want to attach on the side of a viewport (using the term loosely) the optical zoom may or may not effect those. Rossen: For naming sake, the scrollport only talks about scrolling but doesn't have panning or other manipulation you can use to target that. Rossen: Is this something we need to discuss for scrollsnaps or should this be in the viewport spec that Florian plinss and I are working on. Florian: This kind of term definition belongs in that root spec or the device adaptation spec. Rossen: I'm just curious if this is worth being captured in any way in scrollsnap. Florian: It's good to know which term, even if defined elsewhere. fantasai: It should be defined in overflow. MaRakow: Either way, I think I can make an unambiguous spec without another term. fantasai: I think it's fine. Rossen: For this issue, do you not need a resolution. fantasai, MaRakow: no Rossen: Okay. Rossen: So we decided to take this into device adapt, overflow, or the viewport. Between these specs one can define this. Physical/Logical Coordinates Mismatch ------------------------------------- <Rossen> https://drafts.csswg.org/css-scroll-snap/issues-2015-12#issue-7 fantasai: TabAtkins and I replied to this. I don't think I added it to the list. fantasai: Let me find it. fantasai: This may need to be at the F2F <fantasai> https://lists.w3.org/Archives/Public/www-style/2016Jan/0138.html fantasai: MaRakow pointed out that the coordinate system for scroll-snap-padding and scroll-snap-margin is physical and scroll-snap-align is logical. He was listing the background in that we added logical to margin and padding so both coordinate systems will work in both. fantasai: scroll-snap-align is logical for a few reasons. The direction that you're scrolling is almost never going to want to be physical because the direction of the scrollers are logical. So we designed scroll-snap-align to match that scrolling are mostly logical. Also when you set the axis you can choose physical or logical and you pay attention to that. fantasai: So we don't think it's harmed by being just logical. We could add physical and have them both expressible, but I think you'll always want to be logical even when referring to physical. If we find we want it in the future we have the space to do so, but we can limit it now. That encourages authors to do the right think and limits testing. MaRakow: I don't think it helps for mismatch between horizontal and vertical. fantasai: You can use the scroll-snap-type and say x or y. That's provided. In the alignment if you give one keyword it applies to both axes. MaRakow: I looked at your example and when you give two keywords which is the first? fantasai: We wanted to be consistent with how alignment and box-alignment works. MaRakow: The example in your mail is only a single keyword for align, but the issue arises with two keywords. So I don't think your example covers the situation. fantasai: The situation is... MaRakow: If someone wants a thing only scrollable in one direction so the specify x and then they specify center and none, we want it to work. Florian: Why would they specify both? Why put both keywords on scroll-snap-align. MaRakow: It's not an argument as to if it's a good idea, but if you have two, which is the first and which is the second? MaRakow: The spec needs to say what happens for two. Florian: The author would make his life harder. The simple way to author is one keyword in one direction. In the vast majority of cases the contradiction doesn't happen. If you use it the normal way there is no contradiction. You can get yourself there but you don't have to. MaRakow: I'm not saying this is the way you should build it, but if someone uses two keywords which is first and which is second? I'd like the spec to say something to keep it consistent. I'm not saying you should use two, but if you do what do you do? Florian: I was trying to go after that we should try to have the syntax that makes sense in most use cases. If the scroller is 1D, if you have two we have to decide, but it's not common. I think fantasai made more sense in her argument for what we do when there's 2D. That's the scenario that it makes sense to look at. MaRakow: So it would help to have an example that more clearly shows when the problem arises? Florian: So I think because setting one keyword for 1D the logical option is to set one keyword, so that's neutral. So we should look at the 2D scenario and see what's more relevant to express for that scenario. MaRakow: I don't think it's unique between. The only thing that changes isn't if you can scroll, but if snapping is interesting in the other axis. I can do an example with overflow in both directions and you want snapping physical. Florian: Yeah, probably that would help. It's a good thing to compare. fantasai: The default of scroll-snap is to work in block. We default to doing only one axis because we imagine that that's the most common. If we were to default to both directions the author could assume it's great on their big screen, but it could give horrible behavior on a smaller screen. To prevent that which could be common we made the default to accept both. fantasai: The default is logical. So it makes sense that snap-align should be logical. If there's compelling cases for when logical isn't appropriate we can add physical keywords. I'm just not seeing a case for that. Florian: So what we need to address this is 2D snapping and 2D scrolling example. MaRakow: I'll see if I can come up with a better example. Florian: Thanks. scroll-snap-type Bikeshedding - Mandatory/Proximity --------------------------------------------------- <Rossen> https://drafts.csswg.org/css-scroll-snap/issues-2015-12#issue-1 <Rossen> https://lists.w3.org/Archives/Public/www-style/2015Dec/0177.html MaRakow: The proposal is 'near' and 'always'. I would agree that's there's better names than 'mandatory' and 'proximity'. fantasai: I'm the same on this issue. We could do better, though I'm not super excited about those names. I'm open to other ideas. MaRakow: If it helps, I can add an issue to the spec saying we're searching for better names. fantasai: We'll have more people at F2F so that may be better for bikeshedding. MaRakow: I won't be there, but if something comes up... Rossen: We can try and find a time you can call in if you'll be in the office. MaRakow: I won't be in the office, so I won't be able to call. Rossen: Bikeshedding can be re-bikeshedded. So fantasai proposes we take these to the F2F, look for better ideas, and bring them back as proposed changes. Rossen: Would that apply to the next issue? Florian: Probably. Splitting scroll-snap-type -------------------------- <Rossen> https://drafts.csswg.org/css-scroll-snap/issues-2015-12#issue-3 fantasai: We can talk about if we agree on splitting. But names should wait. Florian: I can see why we can, what's the use case? MaRakow: It's a goal to make it more clear as to which type of snapping applies to which axis. I have a hard time telling which would work better, but it's a lot of info into a single property. If we can be clear which snap types are for which axis it's a good goal. Florian: Splitting into 2 properties makes sense if we expect them to cascade separately. Do we expect that? Rossen: Good point. I don't see why they couldn't. Florian: You can, but is it useful? Florian: Is it a writing mode story where if you're mandatory or proximity it's fixed but if you flip...eh, maybe. Rossen: I don't know how much the inheritance model helps anyway. MaRakow: Seems like we maybe need a good example that shows an advantage. Florian: I think the split is possible...just...wondering how often you'll want. Florian: You can rely on default and be fine but you can rely on the shorthand. Sure. If we can get good names, why not? Rossen: Sounds like we came back to needing more people and more bikeshedding at the F2F. Group Reminders --------------- Rossen: Spec updates. This is a nudging. We don't need to discuss. Florian: Related to the updates, how are we on testing and clearing the queue? Rossen: What in particular? Florian: We still have quite a few things in the test queue. Rossen: Right. It did move, but not significantly reduction. There was a lot of move right after the discussion we had. I would have to go back and see. I'm not sure if that was a momentary surge. Florian: I think it was. Rossen: I don't think we'd be able to decide a lot more on the call. Florian: Yep. Just a nudge. Rossen: Fair enough. If you can help reviewing tests, please do so. Rossen: Let's call it a day. We'll see most of you in Sydney. Safe travels!
Received on Wednesday, 27 January 2016 23:57:27 UTC