- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 21 Jun 2017 20:32:11 -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. ========================================= Spec Rec -------- - The open Values & Units topics will be prepared for discussion next week. Make selection change behavior configurable ------------------------------------------- - There were three proposed options: 1) no change 2) change from current and make it so clicking in user-select:none undoes current section 3) have two values, one for each behavior - RESOLVED: option 1: no change and add perhaps a non-normative note explaining adding this on the root isn't a great pattern word-break: break-all doesn't break before sentence-ending punctuation if UAX #14 is used ---------------------------------------------------------------------- - RESOLVED: line-break: break-all on its own has the effect of allowing breaks everywhere. - This change will be put in L3 of CSS Text. Clipping of content that overflows a column ------------------------------------------- - RESOLVED: Columns do not clip by default Clarify that column-* properties only apply to block containers --------------------------------------------------------------- - RESOLVED: Columns are properties applied to block containers only. Alias "nowrap" as "no-wrap" --------------------------- - Those arguing in favor of the alias did so for author usability. - However, the argument against the alias is that it adds weight to the API and sets a precedent for doing this again in the future. - The two sides couldn't agree within the time of the call so the topic was deferred back to github. ===== FULL MINUTES BELOW ====== Agenda: https://lists.w3.org/Archives/Public/www-style/2017Jun/0023.html Present: Rachel Andrew Rossen Atanassov Tab Atkins David Baron Dave Cramer Alex Critchfield Benjamin De Cock Elika Etemad Dael Jackson Brad Kemper Tomoya Kimura Peter Linss Myles Maxfield Thierry Michel Melanie Richards Florian Rivoal Alan Stearns Greg Whitworth Regrets: Bert Bos Tantek Çelik Daniel Glazman Tony Graham Vlad Levantovsky Simon Pieters François Remy Scribe: dael Rossen: Let's get going. Rossen: Hello again. As usual, wanted to check if there are last minute items people want to add to the agenda today fantasai: We could add bikeshedding outset properties, but that's only if we run out of topics. fantasai: top/left/bottom/right shorthands. Rossen: Yes, we'll do it if time permits. Spec Rec -------- Rossen: I only saw gregwhitworth reply. There were a few progress changes around fonts and variables. Seemed like writing modes was close. Are we ready with transition fantasai? fantasai: There were substantive changes to the spec. I can't recall if it needs CR. Rossen: Is this on you or Chris? fantasai: I need to know if we're publishing CR or PR before I give it to Chris. Rossen: And I don't see Chris on the call. I'll ping him. Rossen: Values & units, is it ready? fantasai: I think changes section isn't compiled. fantasai: I did find discrepancies between L3 and L4. There's also open issues in the DoC. <fantasai> https://drafts.csswg.org/css-values-3/issues-cr-2016 fantasai: I updated with resolutions yesterday. Issue 4 requires edits and is still open. <fantasai> https://github.com/w3c/csswg-drafts/issues/708#issuecomment-302240095 fantasai: Issue 13 ^ is still open b/c there are comments from Patrick. <fantasai> https://github.com/w3c/csswg-drafts/issues/708#issuecomment-303786908 fantasai: And the one after it ^ Rossen: Do any of those needs to be on the call agenda? fantasai: I suggest for next week. I'll prep a list <Florian> Also waiting for CR publication of css-contain. It's on Chris / Ralph's desks Rossen: Okay, and last is UI. It was pending some test reviews I think on fantasai fantasai: I need to do that. Florian promised to pester me today * Florian pesters Rossen: Thank you. Make selection change behavior configurable ------------------------------------------- Github: https://github.com/w3c/csswg-drafts/issues/1317 Florian: user-select: none makes it impossible to select things. But also if something is selected somewhere else in the doc and you click in a user-select: none area the spec says this should not effect existing selection. Florian: I believe we picked this because in native UI there are often places that are inert. However, someone has said they sometimes want the other way around where if you click in a user-select: none area it should unselect. Florian: Example for that I think was a FB page with posts. Post content is selectable, but if you click in the empty areas, like the margin around the post, people expect that to undo the selection Florian: My original reaction was then don't use user-select: none However people that do app-like things do user-select:none on the root and make some small area selectable. Florian: Maybe they shouldn't be doing that, but maybe there is a need. We should either flip the behavior or create the ability to do the two behaviors. What do people think? fantasai: I don't think flipping makes sense. It seems there are two behaviors wanted here. Florian: I think I agree flipping wouldn't be good. I'm less sure if we want 2 values or we recommend people don't do user-select:none on the root and instead selectively apply it. Rossen: Have we circled back with the editing group and asked if they have any best practices for such scenarios? Florian: We have not but could. Rossen: I think they have reviewed these kinds of patterns. I don't think we should re-invent the wheel here. If they have a recommendation we should match. Florian: I think it's fair to ask. I'm not sure we'll get an answer as the editing TF is focused on content:editable and that isn't primarily about selection. This is also used in non-editing places. Rossen: I don't disagree, but since editing is their charter I would expect most people would be expert in editing behaviors and use cases so they may have a recommendation. If they don't we're at square one. Florian: Even if they do, this isn't about just editing so we may not want to just take it. We need to think about non-editing use cases. That's the majority of the use cases. This is about making tool bars and labels non-selectable so when people select something to copy/ paste they don't get UI as well. Florian: It does interact with editing, but it's not limited to that. Rossen: What are the options on the table? Florian: 1) no change 2) change from current and make it so clicking in user-select:none undoes current section 3) have two values, one for each behavior. Florian: Together with option 1 it comes with add a note about setting user-select:none on the root having undesirable behavior. Rossen: What do people think? Can we live with #1? bdc: From a designer perspective I feel this is a very minor issue I've never seen before. I feel we have everything in place to leave as-is. I would personally go with option 1. Rossen: Thanks. Rossen: Other opinions or should we resolve? Rossen: Objections to option 1: no change and add a non-normative note explaining adding this on the root isn't a great pattern RESOLVED: Option 1: no change and add perhaps a non-normative note explaining adding this on the root isn't a great pattern. word-break: break-all doesn't break before sentence-ending punctuation if UAX #14 is used ---------------------------------------------------------------------- Github: https://github.com/w3c/csswg-drafts/issues/1171 Florian: Title is a bit old. Now, at the last F2F we agreed to add a break-all value to line-break that might, in isolation allow breaks anywhere and everywhere. We did not decide if this should work on its own or if putting it on line-break should only effect punctuation. Florian: We said impl would prefer it work on its own and it appeared unlikely there were use cases to have breaks around punctuation but not inside words, but we weren't sure. Florian: I tried to ping i18n but there has been no answer. fantasai: I asked on one of the telecons, they said they had not heard of a use case. Florian: So we should have line-break: break-all have effects on its own. fantasai: I agree. Rossen: In the absence of other recommendations from i18n or any other proposals, do we resolve? fantasai: I think we can. Rossen: Any other opinions or options before we resolve? Florian: Proposal: Line-break: break-all on its own has the effect of allowing breaks everywhere Rossen: Objections? RESOLVED: line-break: break-all on its own has the effect of allowing breaks everywhere. * fantasai thinks we need a shorthand for line-break and word-break so that we can have some kind of sensible interface to all of this nonsense <Florian> +1 to fantasai Rossen: Is this a change to the current spec? Florian: Yes, we're adding this new value. Rossen: And this is L3 or 4 of text? Florian: I've made a pull for L3 but I'm not sure we resolved either way. Rossen: fantasai, do you have a preference? fantasai: I don't. I think the feature is so simple it could be in 3. fantasai: We can mark at-risk. Rossen: Okay. Rossen: We'll add it to L3. Clipping of content that overflows a column ------------------------------------------- Github: https://github.com/w3c/csswg-drafts/issues/314 Florian: The TR version of multicol and the ED are contradicting. Florian: Browsers aren't interop. Florian: If something overflows from a column should it be visibly overflowing or clipped when the line is in the middle of the two columns. Rossen: Do you mean overflow in the inline direction in a column, block, both? Florian: That's the other part. Specs are vague and they don't define all cases. The case I'm interested in is not the kind that triggers fragmentation. I'm interested in any other kind of overflow. Florian: Both versions contradict. TR says clip, ED says overflow. Both use wording that means you do that in some cases, but don't say what to do in other cases. Florian: I think we should not clip and overflow for everything for 3 reasons. First, there are use cases for positioned content to overflow. 2 is that lists, numbered or bullet...because the default HTML styling have the bullets overflow by default because it's padding on the <ul> in the stylesheet. That means bullet stick out and that's bad. Florian: If we're doing it for this we should be consistent and not invent a new behavior to let some things overflow and some clip. Florian: That's bad, especially if one day we have a selector to select column boxes. <bradk> +1 on those examples <rachelandrew> I think currently firefox overflows, Chrome clips <rachelandrew> https://codepen.io/rachelandrew/pen/YpXqNY?editors=110 Rossen: Speaking of our impl, the columns themselves do not clip and the multicol box wrapping around all the columns may or may not clip depending on the overflow prop. You're not clip in either horizontal or vertical. I don't have bugs suggesting we change this. So I would be in support of your proposal. Florian: Current spec says not to clip in some cases, but doesn't define other cases. The behavior you describe agrees with FF, but not Chrome. I think Safari is with Chrome. gregwhitworth: Is there a test case? I'm looking at bugzilla and all browsers have overflow. Florian: 5 minutes ago I made a test case and I lost it, but with a float with a margin that makes it stick out and Chrome clips that. Rossen: That's why I was asking about inline or block. Block direction has very specific rules in fragmentation and when we have monolithic boxes that don't fragment multicol lets you create net column. If your column count is fixed you may overflow in the box direction eventually and that should be controlled by overflow property. fantasai: Even if you have fix column count you can overflow by creating more columns. Rossen: You're correct. Rossen: You can always have an item that overflow the height. fantasai: We're talking about an item that overflows the column box itself. Overflow in block we're clear it's visible. Overflow in the inline you have a box in the first column and it'll overflow, will it overlap content in the second column? Florian: That's the core. Slightly broader do we want to distinguish between types of content that might overflow or do we want one answer for all the things? fantasai: I'm guessing one answer is easier to impl. Florian: Yes, and that's not what the spec says fantasai: Also, abspos elements is a different question as it's not in the column. Florian: It depends on the containing block. fantasai: Right, they would be clipped by containing block, not the column necessarily. So the abspos case splits into two sub-cases. Florian: I think I would like nothing gets clipped and if people come up with use cases to clip we'll add a selector for column boxes and they can use overflow on that. <Rossen> https://codepen.io/rachelandrew/pen/YpXqNY?editors=110 Rossen: To be on the same page, rachelandrew pasted a codepen^ Rossen: I want to make sure this is the test case we're talking about. There's an image in the middle which is too wide. Question is does it clip. Florian: That's one of the cases. Rossen: What is see is that all browsers but FF clip. Rossen: This is most likely a change in our behavior that was made for interop purposes. <fantasai> Rossen, the original spec called for clipping iirc, that's why multiple browsers clip Rossen: If we agree to not clip it means we'll have to change all but one implementation. We have to be mindful of the effect of the overall web compat. Florian: I thought you said Edge doesn't clip. Rossen: We didn't used to. At some point we must have changed for interop. fantasai: Or it could have been for spec compliance. It did say to clip. Rossen: What I wanted to point out is if we change the spec it means changes to webkit, blink, and edge. I'm not sure what that would mean for web compat. Florian: Another argument for that is multicol has been more successful in printed media and prince does overflow. Rossen: That could be, though I've seen epub readers use multicol for pagination. Those might suffer. Florian: Then again, these do not want to have the selective clipping and overflow, they likely want always clipping which is not what we have today. Rossen: It might suggest this is either an optional value to multicol where you can say clip or not and then put the behavior in the author hands and then we decide what the default is. Florian: If we want to put it in author hands... dbaron: It seems like the overflow is the easy way to make it author controlled. Rossen: dbaron did you mean overflow of multicol or have it apply to a selector. dbaron: Probably some sort of pseudo element. Problem is overflow defaults to visible and it's weird to have one thing default to clipping. Florian: I think visible is a good default. For regular multicol there's no clear reason why clipping would be a good default and turning list into multicol isn't crazy. Rossen: If you put together market share I'd say a majority of content does clipping. Florian: You can cope with it, doesn't make it good. Rossen: It's what's expected on the web. Florian: Except for people in print and people using FF. dbaron: I also haven't seen this as a compat issue for us. gregwhitworth: [missed] dbaron: I don't remember seeing it Florian: I don't think it would be mobile browsers, I think it would be apps that use browser as the run time. <fantasai> Those would be easier to handle, since when they pull a new copy of the engine they can make the adjustment via ::column { overflow: hidden; } Rossen: That's what I was referring to. I've seen multiple touch webapps that do provide epub experience based on multicol. Florian: I think that's how ibook works. Florian: I'd like to go visible by default and have a column selector that could take overflow. Florian: Current behavior isn't clip by default. It's clip by default except something and that's not great. <dbaron> do Chromium, WebKit, and Edge all clip columns in both dimensions? Rossen: What is not clipped? I couldn't find anything. Florian: abspos and the like? Rossen: You cannot make a column be a containing block fantasai: You can make an element in the column. Rossen: In which case the element itself is clipped. fantasai: Box can overflow the element. Rossen: If you have a non-breaking word that expands past the column it's clipped anywhere except FF <Rossen> https://bug1282363.bmoattachments.org/attachment.cgi?id=8765359 Florian: And floats with negative are clipped. I haven't tested transformed content. Maybe everything is clipped, I haven't tested all variants. Rossen: Going through the test case what you're desc for abspos is clipped in FF. Florian: If we can prove there's no compat problem, would we agree visible by default is a better behavior or not? Rossen: I cannot speak on better or not. Rossen: It's preferential. fantasai: It's more expected since that's what we do everywhere else. <bradk> Overflow should be visible * dauwhe ran Rachel's codepen through Prince. Photo overflows column all the way to the page edge Rossen: I'd like to hear from blink or webkit if they're willing to change. myles: I'm not prepared to comment. TabAtkins: I dunno. <rachelandrew> I don't have a strong opinion, not sure many authors are using this (on the web) Rossen: I think the overall behavior proposed change is well understood. Let's try to close and see how to move forward. Florian's proposal is to change the behavior and define that overflow of items inside columns of multicol are not clipped. And if we add a column selector with overflow is a separate topic. Rossen: In the absence of the column selector, are there objections to changing the behavior of items being clipped to not clipped. <fantasai> is in favor <bradk> +1 * Florian is in favor Rossen: objections? RESOLVED: Columns do not clip by default Rossen: If there are use cases for clip we'll decide if we need the selector <fantasai> It's possible to workaround the lack of clipping on columns by wrapping the columns entire contents in a block with overflow: hidden. This also addresses the weirdness of the clipping boundary being in the middle of the gap instead of at the near edge. Clarify that column-* properties only apply to block containers --------------------------------------------------------------- Github: https://github.com/w3c/csswg-drafts/issues/1364 Florian: This is not a hard change for the spec. If there's agreement I'll do it. Florian: There is behavior agreement, it's a question as to if we should update multicol to say it or are we happy with where it's defined. Rossen: Opinions? Rossen: Proposed: leave it where it is, don't change. fantasai: It's an error in the spec and needs to be changed. We need an exception for tables where they don't apply to tables or table wrapper box. That should be called out. <dbaron> yeah, seems better for the multicol spec to just say the right thing fantasai: For sure block containers. The list is really specific and not quite correct <gregwhitworth> not tables Rossen: You propose to change to it applies to only block containers? fantasai: Yeah. Block containers is well defined. fantasai: They weren't when the spec was originally written. Rossen: Reasonable. Other opinions? Rossen: Proposal: COlumns are properties applied to block containers only Rossen: Objections? RESOLVED: Columns are properties applied to block containers only. Alias "nowrap" as "no-wrap" --------------------------- Github: https://github.com/w3c/csswg-drafts/issues/1537 Rossen: shane added this TabAtkins: I can explain TabAtkins: Deal is a while ago we discussed...we agree nowrap was a legacy mistake. It was a legacy issue. There was discussion as to if we should try and fix it and add an alias of no-wrap where nowrap is accepted. TabAtkins: zcorpan brought up counter argument that they'll have to recognize no space as they'll have to return it in cssom. Is it worth it to add the alias? TabAtkins: My position is same as Naina where I do see people making this mistake still. I've never been happy with the no dash version and I still have to fix it when I'm using the property. I think it's good to add the alias and in the future just use the dashed one. Rossen: What's the default and how does this roundtrip? Do we need to have enough state inside to know which was cascaded as? TabAtkins: I don't have a strong opinion. It is lower cost to map the dashed version to the no dash. You don't need anything new in the data structure. It's probably better for authors to maintain them separately. TabAtkins: I would slightly prefer them as distinct values in the OM, but I'm not hugely opposed. dbaron: I'd prefer not to have multiple different mechanisms for value aliasing and I think we have the parse time one. Rossen: I'm on the same page. As a first step I'd be okay with parse-only aliasing. Next would make it mess, but we could do it if we have to. TabAtkins: I don't remember any other value time aliases. In the property spec it doesn't matter which way, they'll get it back. Values don't have that affordance. Rossen: We have some mostly around legacy webkit values from what I recall. Again, the feedback is it's a pain, but possible. Rossen: If we can do parse only aliasing we would be happy. If you say this makes author life easier that's fine. Supporting the round tripping...ehhhh...if we have to. Florian: It's not hard to impl. Rossen: But cascade is tricky dbaron: You have to decide if they're different as computed. Rossen: And if they are different when you have to roundtrip it becomes messy if they're variables involved TabAtkins: It's just adding a new value. We take nowrap definition and copy/paste it to no-wrap. myles: That's my primary concern. If there's no actually difference it's only increasing the API surface. Florian: It doesn't have behavior benefits, but typo benefits. TabAtkins: I suspect a lot of authors mistype this. I do. Platform comprehensibility is important and making this one weird exception work is not 0 benefit. myles: I don't think adding a new alias value is worth the API cost. <dbaron> So in Gecko we have parse-time aliasing for overflow:hidden/-moz-scrollbars-none, user-select:none/-moz-none, writing-mode:horizontal-tb/lr/rl/lr-tb/rl-tb, writing-mode: vertical-rl/tb/tb-rl, and probably some others since this was from visually scanning a list of tables Rossen: We have 3 possible scenarios. 1) no change at all, don't add dash. 2) add dash as parse aliasing. 3) add dash version as a recognized new value that behaves same as no dash. Rossen: What do people prefer? <bradk> Treat it like a prefixed value? myles: I prefer 1 because setting up the pure alias that isn't about prefix sets a precedent. We don't want the to keep occurring. TabAtkins: This is fixing a legacy mistake so I don't think this establishes a strong precedent. Florian: I think we'll ask about currentcolor but that's where it will stop. myles: That we know about now. TabAtkins: Worse case scenario is if we import more SVG <fantasai> https://www.w3.org/TR/css-writing-modes-3/#svg-writing-mode dbaron: I scanned the keyword tables in gecko I found two parse time for moz prefix and one for standard that's writing mode. So existing case for parse time is from writing modes. myles: Why don't we continue this next week since it's after time? Rossen: We can try and resolve on #1. TabAtkins would you object to resolve on no change? TabAtkins: I wouldn't be the happiest. I wouldn't want to throw this out because it's late. Rossen: In that case let's go back to gihub. We can try and resolve this next week and it'll let Naina weigh in. * astearns notes that Naina wanted to be on the call for this discussion <fantasai> defers to dbaron on this issue, fwiw <dbaron> I don't have strong feelings about 1 vs. 2 <dbaron> I just prefer not to do 3. Rossen: We'll continue next week. Thank you everyone, talk to you next week.
Received on Thursday, 22 June 2017 00:33:16 UTC