[CSSWG] Minutes Telecon 2017-10-18 [flexbox] [cssom-view] [css-ui-3] [css-grid] [filter-effects]

# Dael Jackson (a day ago)

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

with an appropriate subject line.

Spec Rec Next Steps

  • There is a request to add needed tests to the flexbox test suite.


  • There is a need to find out from implementors if they want to standardize on Element.focus() and, if yes, on what.
    • The two behavior options are detailed here: w3c/csswg-drafts#1805 with both options having multiple implementations.
    • There was general support to standardize, but not enough implementors were available to decide on which path.
  • Discussion then turned to if ScrollIntoView is necessary given the existence of scroll snap.
    • If it is needed, there's also a need to define how it would interact with the scroll snap properties.
  • Discussion will continue on GH and may need to be split into sub issues to decide what the default should be, what options should be available to override the default, and how do the overrides interact with scroll snap.


  • RESOLVED: Change the definition of cursor auto to look like text
          over selectable text in CSS UI 3.
  • RESOLVED: Add exception for editable text into L3 UI.

CSS Grid

  • There are two open items around percentage size that still need to resolved:
  • Both items have examples in the github issue, so everyone was asked to review and add their thoughts to the issue to help reach a resolution.

Filter Effects

  • RESOLVED: Accept hue-rotate() as an exception to unitless values.


Agenda: lists.w3.org/Archives/Public/www-style/2017Oct/0034.html

Present: Rachel Andrew (IRC only) Rossen Atanassov Tab Atkins Bert Bos Tantek Çelik Benjamin De Cock Robert Flack Tony Graham Jihye Hong Dael Jackson Brian Kardell Peter Linss Myles Maxfield Michael Miller Simon Pieters Manuel Rego Florian Rivoal Alan Stearns Sergio Villar Senin Greg Whitworth Eric Willigers

Regrets: Dave Cramer Chris Lilley Lea Verou

Scribe: dael

Spec Rec Next Steps

Rossen: There were a few specs in the publish pipeline which is awesome. I wanted to check on if there has been any movement on testing or if anyone needs help. Especially for things like Writing Modes, Backgrounds & Borders, Flexbox. Rossen: Has there been work? Do you need help?

florian: I have no made progress on writing modes. I don't need help, just time. Rossen: For writing modes, what is the timeline for rec? Is it only those tests? florian: They're the only ones on my radar. You'd need to check with authors. fantasai: Mainly the orthogonal flows, but they need implementors to update. It was supposed to be CR published, I think. I'm wondering if that happened. Rossen: No. fantasai: Writing modes 3 was supposed to be CR published and 4 as a FPWD. I'm not sure where that's blocked. It hasn't happened. Rossen: I'll follow up with Chris. Rossen: I'll see what the hold up is.

Rossen: Backgrounds & Borders is in the publish pipeline. Rossen: Anything else to update?

gregwhitworth: Regarding flex I sent that review is completed, but I haven't gotten to work on the tests at the base. I'm not sure I have time before TPAC. If anyone wants to help please send PRs on flex. I plan to write tests for the changes fantasai has been making, but I don't know about the rest. I would welcome the help. Rossen: If you can help, that would be awesome. Rossen: Please give a hand to gregwhitworth. <gregwhitworth> Particularly before TPAC for those tests. <gsnedders> wrt flexbox, also note there's a bunch of PRs awaiting review at w3c/web-platform-tests/pulls?utf8=✓&q=is%3Aopen%20is%3Apr%20label%3Acss-flexbox-1%20-label%3A%22do%20not%20merge%20yet%22


Add notIfViewed to ScrollIntoViewOptions; add FocusScrollOptions

Github: w3c/csswg-drafts#1805

<jihye> related PR in WHATWG: whatwg/html#2787 zcorpan: This is about disabling scrolling from the focus method in html. Or customizing how the scrolling should behave. zcorpan: For scroll into view there is a dictionary to customize. but for focus there is no way to turn off or customize scrolling. zcorpan: There is a proposal to do these things. The open issue is what the API shape should be and the semantics and how to get interop on default behavior. <zcorpan> w3c/csswg-drafts#1805 zcorpan: On one comment there is a table describing default behaviors in browsers. zcorpan: In chrome, opera, safari the behavior is different between if it's partially in view or entirely out. In FF and Edge there's no scroll if it's partially in view. You get nearest alignment if it's entirely out of view. zcorpan: That's where we're at. We should figure out a way forward and a way to address these use cases.

florian: One thing mentioned in discussion is there is a number of event options we might want to support. You don't strictly need them but it's not convenient. Probably should take some shortcuts, but how many isn't clear.

fantasai: I had a question on this point in terms of the options for start vs end alignment of the thing you're scrolling into view. These conflict with the scrollsnap properties. My question is are these options necessary Do we need something in JS to override them? Do we use those prop instead? fantasai: Has anyone thought about that? florian: My intuition was the JS do the eq/ of maual and when you release scrollsnap kicks in. I haven't thought in depth. zcorpan: I haven't given enough thoughts about integration, but they should pay well together and cssom view should be aware of scrollsnap.

fantasai: What's the impl status of the options? zcorpan: I don't know the current interaction. fantasai: No, are the options implemented and deployed or just in spec? zcorpan: ScrollIntoView is impl at least in firefox and chromium. I'm not sure if they're interop. It would work for basic things. I think 'nearest' keyword isn't supported

fantasai: I think it would be worth thinking about if we need these options or rely on css properties. If you have ScrollIntoView why would you set a value different then scroll snap. If there isn't the property many not need to exist. If they do we need to think from that perspective. dbaron: There's definitely use cases for this when not using scrollsnap. fantasai: But we have wording where if something has a snapping area defined and you target that you can use the scroll s nap into to choose the scroll offset. Snap area has a meaning without snapping. florian: That tells you have for offset from to top edge if your at the top. It doesn't say how offset if you're at the middle. fantasai: Scroll snap align would tell you. florian: But only if you're snapping. fantasai: By default that value is none. You're not choosing an alignment, just marking an area. fantasai: But if you have an alignment it means you have a preferred alignment when that element is being considered. fantasai: As far as the JS is concerned it's less powerful and has to duplicate it with every call and keep track of that. The declarative method has that associated with the element the element tells you the information. fantasai: The only reason I can think of is if there is a scroll alignment and you want to do something different and you may or may not snap to the preferred behavior anyways. I'm not convinced that's something anybody wants. fantasai: I think that needs thought as to if we need those options. The information it's giving you for scroll options are less powerful then th scroll snap options. dbaron: I think many of the JS interactions the behavior you want is specific to the interaction. If you're tabbing through controls and focusing on next you want different the reverse tab and focus previous. fantasai: Right, but that's generally going to fall out of UA. If next and previous rearrange based on layout it won't help you. UA should choose if you shift to top or bottom and pick the right side. Doing that manually through JS doesn't seem right. zcorpan: I think the point is that the one who decides the behavior...like if you write an app it's the JS dev that makes the call to pull into view, not the UA. fantasai: Scroll into view the UA chooses a position to have the thing in view. It's an optional argument so if you leave out start or end it'll do dbaron's behavior but more intelligently. The JS dev doesn't have to figure out lots of things. florian: But in some cases it doesn't. In some cases it just centers the thing.

jihye: First of all when I suggested to add some options to control scrolling when focus is called I wanted to prevent scroll or make smooth scrolling. I think if that can be handled by scroll snap? fantasai: No, but the start vs end is provided by scroll snap. I think you were trying to add this to a new API and they were copied over. I don't think anyone has thought through does anyone need this option if we have scroll snap. I think we need to add the auto non smooth, but my concern is adding start and end and in having it in the API. I don't know why it needs to be in JS if there's css properties to control it. florian: Another axis of reflection is how much do we want to expose on in view, partially out of view, out of view...how much do we expose? Do we want a numerical threshold, leave it to browser? There's various use cases we can think of and various levels we can expose.

Rossen: Going back to zcorpan...in the beginning of your description you had a more specific question of focus and if it should align the same as scroll. Rossen: The rest of the conversation seems necessary around if we're going to expose these APIs and dive into how this interacts with scroll snap. I'm trying to wind down the discussion. zcorpan is there anything else you want from this? <zcorpan> w3c/csswg-drafts#1805 zcorpan: Regardless of API shape and scroll snap interaction there is the default behavior of the focus method and how it does scrolling. Do we want to align the behavior between browsers and, if so, what should that be? Rossen: Seems like webkit based browsers have one type of behavior and edge and FF are aligned to not scrolling if it's partially in view Rossen: So impl, would this be something that you're interested in aligning to and, if so, which should we align to? <tantek> IMHO interop on that would be good, I would think webapp devs would like it Rossen: As an impl I'm personally for interop where possible, but I'm not sure which is better b/c I haven't spent much time on it and seeing how it intersects across windows platform. But I want to hear what others thinks. <tantek> +1 Rossen

florian: Additional question: has anyone checked if behavior is done when calling focus method when there is padding? zcorpan: If you check in the link <zcorpan> jihyerish.github.io/all-about-focus tantek: Another question is if the scrolling is similar to fragment link scrolling since that's done on to an element. zcorpan: That is governed by html spec and calls scroll into view algo. zcorpan: I'm not sure if that's what you're asking. tantek: I'd be surprised if that works differently as an app dev. Rossen: I want to wind this down. <florian> answering my own question from earlier: tab focusing and script focusing appear to have the same behaviors <florian> Also, based on the example pasted above, the FF/Edge behavior seems much more intuitive to me. Could be different in different examples, and could be subjective, but for this one and for me, it's very clear.

Rossen: What you were looking for was alignment between focus and scrolling. It seems your question to impl was answered as either they don't care or they're happy with what they have. Either case, the topic is still open. As fantasai pointed out there are a lot of things to think about in terms of snapping and how these should interact. Rossen: I suggest we take those new questions back to GH. If not we can work through during F2F. It seems your specific question about focus isn't quite answered. zcorpan: I think an option for going forward is if we can quickly agree on API shape or behavior then trim down properties to be able to disable scrolling in focus and then JS dev will have to use intersection observer and ScrollIntoView. fantasai: I have no problem with aligning params between focus and ScrollIntoView. I don't have an opinion on the default, but having the same options is reasonable. My main objection is I think part of the API shouldn't exist, but that's applicable to both. Rossen: Agreed.

Rossen: Again, I was hoping you could get a better answer, but it doesn't sound like there is one. Let's go back to GH and I invite impl to think what the default should be and if we can align. Focusing is important. People with a11y needs require that quite a bit. I'm going to continue advocating for alignment here. fantasai: It seems to me there's 3 issues. 1) what's the default? 2) should there be options to change the default 3) those options, should they have params that would override scroll snap or not. If we override scroll snap how does that work. florian: And another where do we care about things that are partially or totally outside the screen. Rossen: We'll have those recorded in the minutes and if needed we can split into sub issues.


Auto cursor should behaves as default cursor except for text?

github: w3c/csswg-drafts#1598

florian: We've already narrowed problem considerably. It's only about distinguishing things we can't in UA stylesheet. There's two things reopened. We say one cursor over text, one over everything else. We should change that to be one over selectable text. That was in originally, seemed an unintentional omissions. fremy: I can give some background as to why this is useful. If you have text inside a button you don't want the cursor to become a text cursor, but you don't want that. To me it seems straight forward and most browsers are doing this. I think that should be in the spec. florian: I sort of have this in L4. In L4 I put an exception to not look like text cursor. I forgot the other things that might make the text not selectable. [missed] Rossen: What is the request? florian: For a resolution to change the definition of the auto cursor to change on selectable text, not all text. I'll make edits. <tantek> and I already +1 that here: w3c/csswg-drafts#1598 <tantek> last week

Rossen: That would mean change of behavior...fremy your example. What would the change mean to you? fremy: We are already doing this in edge. I think all browsers also. fremy: This is aligning spec with browsers. dbaron: Were you going to get to the editable thing? florian: I wanted that sep.

florian: Proposed resolution: Change the definition of cursor auto to look like text over selectable text. Rossen: Objections?

RESOLVED: Change the definition of cursor auto to look like text over selectable text in CSS UI 3.

florian: Second part is another thing where we may want to align to browsers, but it contradicts previous intention. In the general case browsers change to text cursor over editable, even if it's not next. This is doable in UA stylesheet, but we're interop in not doing that. There's reluctance to change, especially on Chrome side. Do we want to change or grant an exception for this because we are interop? Rossen: Opinions? Esp from Chrome? Rossen: Do we have anyone from Chrome? Rossen: I guess there's no one from Chrome. florian: Chrome seemed if other browsers commit to change and we push hard they'll do it. They probably don't want to be alone in this. I'd like to hear from Mozilla. dbaron: I'm fine with having editable thing in spec. It's not 100% clear to me that read/write pseudo does the right thing here. dbaron: I just haven't thought through it. I'm okay with the editable exception. <tantek> +1 similar thoughts to dbaron fremy: I'm in favor too. It's interop in all browsers. We can change, but I don't think we need to. I don't think author would expect it and changing something interop could cause problems. My opinion is we should make the change to make things easier for impl. Rossen: I hear a lot in favor or don't mind. Rossen: Objections to adding an exception into L3 UI?

RESOLVED: Add exception for editable text into L3 UI

<tantek> ready for CSS3-UI PR? florian: That probably takes us to a passing test suite and we can begin to move toward rec <tantek> SGTM

CSS Grid

Percentages and intrinsic size

github: w3c/csswg-drafts#509

Rossen: fantasai summary? fantasai: There is...the never ending topic keeps branching into variations. The current variation has 2 issues. First is that the resolution we took on percentage sizing, we made edits that are symmetrical for block and inline axis. Igalia guys said we implemented asymmetric. So that's an issue of do we want to change for symmetric. <fantasai> w3c/csswg-drafts#509 fantasai: Summary comment ^ fantasai: Basically, I think we resolved this is correct behavior, but if someone thinks different we should discuss. <rego> related to first issue, this comment is also important: w3c/csswg-drafts#509

<fantasai> w3c/csswg-drafts#509 fantasai: Second is what do we do with % gaps. All options ^ fantasai: C and E are terrible. F is impl by chrome. B and D are the ones they're combining. Gecko does A. fantasai: I don't have a strong opinion, but we should think carefully. We have a mix of impl and we need impl, spec, and authors to agree on best option.

rego: Regarding first issue, I think the change to make symmetric for columns and rows is contrary to rest of impl. We've been checking options and if we do it we have to do extra passes. We'd like to check if other impl will do that or if we should revert status. fantasai: Another pass for track sizing algorithm, or just through the items? rego: We believe it needs another pass of the algorithm. We were finding some strange issues to resolve that. Rossen: Are you talking about the % resolution of gaps? rego: Tracks Rossen: Okay. Rossen: And there's no interop? rego: There is interop, but it's contrary to what the resolution says. fantasai: It's an intrinsically sized grid with a % size grid track. Does that % resolve. It does with columns, not with rows. Spec says resolve in both axises. <rego> the spec text is: <rego> > then the must be treated as auto, for the purpose of calculating the intrinsic sizes of the grid container and then resolve against that resulting grid container size for the purpose of laying out the grid and its items.

TabAtkins: Current is similar to how block works. Rossen: But block has nothing to do with grid. We shouldn't define one layout system with a completely different. The original desire to keep things symmetric in grid was based on how a good system should work. it's up to us to decline from that model, that's fine if this is what everyone agrees we should do. But let's not justify current with what we intended. TabAtkins: Sure. We're just saying block behavior wasn't an accident. It was reasonable to avoid extra layout in common cases. Might not be right for grid, but there was good reason behind our choice to copy it over.

Rossen: Trying for progress. Current proposal is to back out on our original resolution from Seattle and go with the asymmetric one. TabAtkins: Intention isn't to get a resolution this week, it's to bring it up for talk later. Rossen: If you're not asking for a resolution, let's keep working on it. We should resolve on this during F2F at the latest. fantasai: Agree. <rego> this was the change from the resolution: w3c/csswg-drafts/commit/15cf0c6d56efdbb44383134ebe19dff672b01546 Rossen: We should put a time limit on this. We'll have to get consensus. <tantek> It does feel like an issue that would benefit from seeing / discussing diagrams in person at the f2f <tantek> Have we made progress on this at previous f2fs? fantasai: It would be useful for people to think and comment on the GH. Understanding the ramifications of this is most useful if people think through use cases and behavior and we're not going to get that around the table. Rossen: Agree.

Rossen: Did you want to discuss gap % resolution or should we let that go? TabAtkins: I don't think we'd get that in 4 minutes.

Filter Effects

hue-rotate() is being used with unitless zero angle

github: w3c/fxtf-drafts#228

TabAtkins: When we realized several impl support unitless angles we marked out the few to worry about and then said not to do it in the future. Our dev figured out what is used and the only one we didn't consider already is hue-rotate. TabAtkins: Proposal is we add hue-rotate to the list of functions that explicitly allow a unitless angle. TabAtkins: I don't believe we need anything else. Rossen: Options against? Rossen: We're fine with that. I see dbaron said on GH he's okay. I +1 his request to add a web platform test with that issue. Rossen: Objections to accepting hue-rotate as an exception to unitless values?

RESOLVED: Accept hue-rotate() as an exception to unitless values

ACTION TabAtkins to add a test case <trackbot> Created ACTION-865


Change default <sup> and <sub> styling?

github: w3c/csswg-drafts#1888

TabAtkins: Dominic read an article about <sub> and <sup> and was wondering if he could change html stylesheet to support them instead of the basic way we do. I think it's okay, but we need yes/no from other people. florian: There are comments. The problem is when you start nesting. TabAtkins: Okay. Reasonable. Rossen: Let's put it back to the issue. There's discussion. We'll bring it back next week.

Rossen: That's the top of the hour. Rossen: Thank you everyone, we'll talk next week.

Contact us to advertise here

Want more features?

Request early access to our private beta of readable email premium.