- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 5 Oct 2016 19:37:19 -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. ========================================= Consider support for overlay scrollbars --------------------------------------- - TabAtkins summarized his proposal for creating overflow-gap: auto | stable | always - Rossen asked if making these optional values for auto on the overflow property would make more sense as it would avoid creating another property. - This was considered and a few people originally expressed no preference, but the more it was discussed the more people felt this was the wrong approach. - There still wasn't agreement as to if this new property should be a longhand of the overflow: auto or if it should be completely separate. - RESOLVED: We will work on a solution to accommodate issue 92 (https://github.com/w3c/csswg-drafts/issues/92) Stretching image grid items in both dimensions ---------------------------------------------- - RESOLVED: The normal value of align-self and justify-self preserves aspect of image but stretch causes it to stretch to fit containing block. Default value continues to be normal. CSS Text DoC issues ------------------- - RESOLVED: Accept the proposal for issue 96 (for linebreak transformation rules ambiguous characters are narrow unless it's Chinese or Japanese or Yi in which case they are wide) - RESOLVED: Make tab size animatable - RESOLVED: Make tab size <<number>> - RESOLVED: Have tab-size account for letter spacing and word spacing - RESOLVED: No change to the spec for issue 110 - RESOLVED: Capitalize only title cases lower case things, not upper case letters - RESOLVED: text-align-last: justify will compute to center for CJK ===== FULL MINUNTES BELOW ====== Agenda: https://lists.w3.org/Archives/Public/www-style/2016Oct/0053.html Present: Rossen Atanassov Tab Atkins David Baron Tantek Çelik Dave Cramer Elika Etemad Simon Fraser Tony Graham Jihye Hong Dael Jackson Brad Kemper Ian Kilpatrick Vladimir Levantovsky Peter Linss Myles Maxfield Simon Pieters Anton Prowse Liam Quin Florian Rivoal Jen Simmons Geoffrey Sneddon Alan Stearns Greg Whitworth Regrets: Rachel Andrew Bert Bos Daniel Glazman Chris Lilley Rossen: Let's get going. Rossen: First topic is stretching image grid items in both dimensions. Rossen: There was chatter during TPAC and a bit more on the queue but this is flagged as agenda+. Rossen: So fantasai take it away. [fantasai isn't on] Rossen: Or is TabAtkins on? <TabAtkins> one sec [trying to find a topic with the right people on the phone] Rossen: Does anyone have a topic they can do without TabAtkins and/ or fantasai? <astearns> testing? TabAtkins: I'm in now. Rossen: Can you do the grid topic or do we need to wait for fantasai? <Florian> This one: https://github.com/w3c/csswg-drafts/issues/523 TabAtkins: [looks] I have not read up on this. <dbaron> I could probably speak a little about 523, but not comprehensively Rossen: Second items requires fantasai as well as koji and others. Consider support for overlay scrollbars ======================================= <Florian> https://github.com/w3c/csswg-drafts/issues/92 Florian: We had a fairly long conversation on this. TabAtkins you had the last proposal. TabAtkins: This was from a little while ago where we discussed having table scrollbars issue. Current proposal is overflow-gap using gap terminology from elsewhere with auto|stable|always TabAtkins: Auto is do what the browser currently does. Stable is always have a gap if you have potential scrollbars. Always is always have a gap. TabAtkins: I can go over reasoning if needed. So proposal is overflow-gap: auto|stable|always. This only has effect if you're in overflow: auto. Florian: Only problem left is fantasai didn't like calling it a gap, she wanted gutter. Else wise I like it. Rossen: I've been reading through this, did we consider having an optional value for overflow: auto? Seems to me having this property is overkill given that it only applies to overflow: auto Florian: We partly considered that, though not with the latest incarnation. It goes down to if they should cascade separately and you may want to have this on the entire page except for where you override it. Florian: If you do that it's good to have them separate. TabAtkins: Against that is if you always use this when activating auto you should pick the right value. Florian: Then you have to set it twice to deal with fallback. Rossen: Depends on the what defaults are. TabAtkins: Florian is dealing with fallback for non-supporting browsers and that's true. Florian: Yeah. I would prefer separate but I'm fine if we roll it in. TabAtkins: I'm fine with it being an extra value. Florian: overflow: auto and then overflow: auto|stable|always Florian: Auto is implied. TabAtkins: Stable is okay, I think we want a different name then always. Rossen: Auto always suggests scroll. TabAtkins: I'm happy to go with that and come up with a better name. The question is should I do this in an active draft? There was some interest in Chrome in doing this and removing some properties of overflow, but it requires stability. Florian: It should go in overflow level 4 if we have agreement. Rossen: I think we should start in level 4 and bikeshed in there. We can call for consensus now. Rossen: I see smfr on the queue. smfr: I think it's bizarre to tack this onto overflow. If I read overflow: auto always I wouldn't understand what it means. <jensimmons> I agree. TabAtkins: Always is no longer good, but stable suggests the meaning. smfr: Overflow is how the content behaves. I think a separate property would be so much clearer. smfr: I would prefer overflow-gutter. * fantasai agrees with smfr, this is confusing TabAtkins: If we make overflow a short hand we could say overflow auto stable and it would work correctly. I'm with Florian and don't care either way. Florian: I hadn't realized you meant as long hand. TabAtkins: If we add overflow-gap overflow needs to be a shorthand. * fantasai doesn't think overflow-gap and shorthanding makes that much sense <fantasai> having it cascade independently would make sense <Rossen> overflow-style <Rossen> overflow-style: stable | auto-hiding | gap <jensimmons> Yeah I'm not sure what overflow gap is either. So many times handling overflow doesn't involve scrollbars. Need a way to let people know, hey this is about scrollbars and gaps. And whatever. smfr: Another request we've had is hide scrollbars but allow user scrolling and we should allow extensibility to allow that also. TabAtkins: I talked about that separately, but I think we have room with overflow-gap. I'm not sure it would make sense there, but someone in overflow there's room to accommodate. fantasai: I think gap control should cascade independently of if something scrolls. TabAtkins: We aren't sure why you would want it to cascade separately. There's no reason to use overflow auto and depend on it being set to stable elsewhere. Florian: I kind of disagreed with that logic. Rossen: Sounds like there's a strong desire to have the property. We have a spec where we can put it and continue to argue or agree. So should we get an consensus on adopting this in overflow 4? Florian: We have consensus on the function, but we don't have it on if it's a separate property etc. fantasai: We shouldn't put it into the draft unless there's a concrete proposal. TabAtkins: The proposal as stands is in the issue. Florian: There's 3 proposals and they're different. <gregwhitworth> for the cascade scenario, it would be nice for use cases that authors would want them to cascade separately fantasai: If this is issue 92 the last comment is from me. Rossen: And that was about naming. Florian: We have 3 concrete proposals, not one. TabAtkins: Do we have consensus on having this ability so that we should pursue doing it? fantasai: We have consensus we want to solve the issue so it stays open and we try and discuss proposals. Last comment you have, TabAtkins, is adding overflow-gutter property. Now we're adding a value into overflow directly. TabAtkins: We can fill in that detail in writing. This came up before you joined the call. fantasai: If I'm the only one disagreeing go ahead, but I hear reservations from others. Rossen: That was about using it as a value, not a property. Rossen: That was provoked by me because I didn't see it and we had a brief conversation. Florian: And TabAtkins using overflow implied it's a long hand and I missed the nuance. <jensimmons> It sounds like some new ideas just came up, and further discussion in the issue is the next step. And that everyone want this feature. Just needs a bit more baking before getting put into the spec. Florian: Since there's no concrete proposal I don't know what we should put in the spec. TabAtkins: Let's resolve to add something with this pending agreement with how to do it. I want something on the record saying we want to do this. Florian: I'm in favor of saying we want to do this, not having something in the spec. Rossen: Objections to having us work on overflow [some name] to accommodate issue 92? RESOLVED: We will work on a solution to accommodate issue 92 Stretching image grid items in both dimensions ============================================== <Rossen> https://github.com/w3c/csswg-drafts/issues/523 Rossen: There was a conversation during TPAC with Manuel and others. Can you take this one fantasai? fantasai: The issue was about preserving aspect ratio of grid items that have one. Current spec says squash the image if it's a fixed size grid block. fantasai: You can use object fit properties to contain it or you can change the width but the argument was we should preserve the aspect ratio by default. With object-fit you preserve and clip and if you use auto the image box has this gap and it becomes obvious. fantasai: We could change auto to cause it to shrink and preserve aspect ratio by default. fantasai: I don't have a strong opinion. I do think how object-fit works is super messed up. dbaron: I think Mats feels strongly squashing is wrong by default. Part of the problem is the initial value of object-fit doesn't work well for grid which stretches by default. dbaron: Given that the initial value is stretch, grid does this other sizing on top that makes the stretch happen in more cases. It feels object-fit is the wrong default for gird. If we do the other behavior object-fit becomes slightly less useful. fantasai: You can set width and height to 100% and it'll fill the cell. fantasai: It would be nice if alignment would work to control this, but they work on each axis independently. You can say I want to stretch or do intrinsic sizing in this axis. You can preserve axis ratio, but you may overflow if you don't know which is longer. TabAtkins: I think you're saying that preserving aspect ratio if you let it stretch and do object-fit: contain fantasai: But than you don't resize the borders. That's a problem with object in general. TabAtkins: It's a problem object doesn't solve, sure. <smfr> object-fit has only been applied to replaced elements so far <dbaron> smfr, this is about applying to replaced elements -- images that are grid items Rossen: Is this something dbaron you're okay with? You expressed Mats has a strong preference. Rossen: Having a clear work around for this... fantasai: Another thing we can do to allow an easy switch is we have a normal value for alignment. For grid items it's equivalent to stretch. We could say normal does what Mats is proposing to make sure the image fits in the frame and stretch alters the aspect ratio. That gives us a switch for all common behaviors. dbaron: Seems like a nice idea to me. I'm curious what Mats thinks. jensimmons: Feels to me that stretch should stretch it and something else could be the default. Having stretch not stretch is disappointing. There's use cases to have the containing box be controlled by grid and having the crop to make it fit. Having that be the default is the awkward part. fantasai: Other thoughts on this or should we go with that? fantasai: Summary: The normal value of align-self and justify-self preserves aspect of image but stretch causes it to stretch to fit containing block. Default value continues to be normal. Rossen: Sounds reasonable. Rossen: Objections? <dbaron> This is proposing changing the grid rule in https://drafts.csswg.org/css-align/#distribution-grid <dbaron> ... so that it's a different default for (I guess) replaced elements RESOLVED: The normal value of align-self and justify-self preserves aspect of image but stretch causes it to stretch to fit containing block. Default value continues to be normal. CSS Text DoC issues =================== <Florian> https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-96 <Florian> https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-102 <Florian> https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-108 <Florian> https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-110 <Florian> https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-111 <Florian> https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-114 <Florian> https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-117 <Florian> https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-123 <Florian> https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-122 Use language context for dropping spaces around A (issue 96) ------------------------------------------------------------ fantasai: There is discussion about that the Chinese use same " as English therefore East Asian treats them as ambiguous. fantasai: We're using East Asian width to determine if align-break is just a space of if it disappears as in CJK languages. fantasai: There's rules that say if you're in CJK turn the line break into nothing. If you're non-CJK keep the space. We determine it by looking at East Asian width property of character before and after line break. fantasai: Issue that came up is can we make this context dependent so the " doesn't prevent the line break from collapse. fantasai: Proposal is use the content language if it is known. If it's unknown we treat them as narrow. fantasai: Is this okay for the set-up rule and, if yes, do we adopt? Florian: The alternative is be language dependent in the markup or context dependent in surrounding characters? fantasai: We're using context now and using wide vs narrow to make that distinction. Florian: If it's Kanji " Kanji you're wide? fantasai: Currently all ambiguous is narrow. If content language is East Asian treat ambiguous as wide is the proposal. Florian: That sounds fine. koji: I'm fine with language, I'm concerned with adjacent(?) character. We can only see the character next to. Florian: Adjacent doesn't sound like a good idea. Sorry for brining it up. fantasai: Characters immediately after the one that has the line break? Florian: That's what I thought of and I don't think it's a good idea. fantasai: I think there was easier a rule to walk if there's punctuation but we simplified to immediately adjacent. fantasai: This seemed a simpler solution. Florian: Yeah. <dbaron> Gecko has some language-dependence in justification code (currently conditioned on C or J but not K!) but I'm not sure about how far away the code for this is <dbaron> My suspicion is that the language dependence probably isn't a problem Florian: dbaron says in IRC yes to the on C and J but not K dbaron: fantasai asked about language dependence. I didn't follow what this is about. We have language dependence in code that classifies differently on CJ but not K. I think language dependence is probably okay. It's worth thinking if you mean CJK or just CJ. fantasai: It's Chinese and Japanese, but not K. K has spaces so we don't want to remove those. fantasai: This is in the white-space collapsing code. dbaron: It's hard to know for sure if something is implementable until you implement it, but barring that it sounds okay to me. fantasai: Okay, then I'd say this is a good proposal and we should accept. Rossen: Objections? RESOLVED: Accept the proposal for issue 96 (for linebreak transformation rules ambiguous characters are narrow unless it's Chinese or Japanese or Yi in which case they are wide) Animating tab-size (issue 102) ------------------------------ <fantasai> https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-102 fantasai: Animating tab size. dbaron pointed out it's not animatable. We need to change the integer to a number to make this possible. Is that okay and do we want it to be animatable? Rossen: Let's start with should it be animatable? myles: What's the use case? fantasai: I don't think there is one. TabAtkins: Consistent platform. You have a number and no reason you can't have something between the two. This would be another quirk you have to remember. myles: If we don't expect anyone to do this is there a point is spec? Florian: We have to go one way or another. myles: It is specced one way. TabAtkins: By default. Bikeshed by default says not animatable unless you spec it. Tab size does have a length. It's a weird inconsistency. Small tiny use case, but an inconsistency we don't need to have. Rossen: Sounds like TabAtkins proposes we make it animatable. * fantasai defers to dbaron on this <bradk> Animatable +1. Principal of least surprise. TabAtkins: fantasai proposed it and I support. I don't care if we change it to a number. That they're an integer isn't significant. But even if they're pure integers they'll be animatable. dbaron: I feel there is a real use case for number over integer. People would be surprised they can't do 2.5. Florian: I think we're splitting hairs here. Most likely you're doing this with monospace and you can use ch unit. fantasai: There is another issue that makes numbers different than ch in monospace. fantasai: This issue is coming up on the list. Florian: [dramatic oooh] fantasai: In which case this would be smoothing animatable. Florian: So if it accounts for letter spacing what would 2.5 mean fantasai: It would be space+letterspace+wordspacing and multiply. Florian: Not n-1 on spacing? fantasai: Nope. Florian: Then it's fine. TabAtkins: I don't know if I agree with that proposal, but it doesn't matter because it interpolates fine. Rossen: Let's call for consensus. Objections to making tab size animatable? Objections to be being a number? RESOLVED: Make tab size animatable RESOLVED: Make tab size <<number>> tab-stop should handle word/letter-spacing (issue 114) ------------------------------------------------------ Florian: Letter yes, word I'm not sure. fantasai: Word increases size of space. Every space character would get increased. TabAtkins: Does this have an analog in other environments with tabs? fantasai: I don't think so? Maybe word processors? TabAtkins: The important point is if you have a monospace fonts and tab size is 8 with this change is it lining up to 8 monospace characters? fantasai: Yes. Florian: I'm confused on how we space words, but given that it works this way that's okay. Rossen: Is this Issue #114? fantasai: Yes. Rossen: Objections to have tab-size account for letter spacing and word spacing? RESOLVED: have tab-size account for letter spacing and word spacing * dbaron notes issue 113 is an issue in a feature that's in CSS1 Capitalizing enclosed alphanumerics (issue #110) ------------------------------------------------ fantasai: There was an issue as to if alphanumeric characters with a circle should be capitalized. They're symbols in unicode and the case transforms are only for letters. Jonathan Kew and someone had an argument to have it stay. There was another to say change. <tantek> link to email thread? <gregwhitworth> I think it's this one: https://lists.w3.org/Archives/Public/www-style/2015Mar/0144.html fantasai: My recommendation from all the comments is we should leave the spec as-is and not case transform symbols. Rossen: I think your last e-mail was we should go with whatever unicode case mapping is defined and have CSS match that. fantasai: Yes. I concluded we should keep the spec what it is. We say which set of characters are effected by case mapping. fantasai: So this is a similar restriction where case mapping is only letter characters and not symbols characters. Florian: I would tend to agree based on if we add custom text transforms it will be easier to create a new one that does general capitalization plus that then make one to remove it. <tantek> I think that's wise Rossen: Let's see if we can conclude to leave spec unchanged. Rossen: Objections? RESOLVED: No change to the spec for issue 110 Titlecasing digraphs (issue #111) --------------------------------- <dbaron> https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-111 <gregwhitworth> Email thread: https://lists.w3.org/Archives/Public/www-style/2015Mar/0242.html fantasai: There is a difference in unicode between capitalizing and titlecasing. Most letters it's the same, but in a digraph the titlecase capitalizes the first but not second letter. Issue was we shouldn't take that and put it in title case if it's already in upper case. fantasai: You would get an odd effect where if you title case the first letter you have a lower case letter in the middle somewhere for no reason. I agree with that. Rossen: Is this an addition? fantasai: Yes. Florian: Where we go from fully lower case digraph for fully upper seems non-controversial. fantasai: Text transform uses language dependency. Florian: That makes sense. fantasai: If it's not in unicode case mapping file we don't try and fix it. <dbaron> IJ, ij, etc. fantasai: Otherwise Turkish i wouldn't work. Florian: Give that's covered, I agree fantasai: Capitalize only title cases lower case things, not upper case letter. RESOLVED: Capitalize only title cases lower case things, not upper case letters <TabAtkins> Reviewing the effects of spacing on a <pre>, yeah, I def agree with the resolution from before - literal spaces definitely take letter-spacing and word-spacing into account. I can't tell off-hand whether it's literally (space width + letter-spacing + word-spacing) * spaces, or if there's a -1 in there somewhere, but it looks about right. Fallback alignment for justified text ------------------------------------- <dbaron> https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-117 <fantasai> https://lists.w3.org/Archives/Public/www-style/2014Oct/0395.html fantasai: There is several possibilities for when you justify text and try and space it out to align on both edges. Issue is what do you do if you have no place to insert a space. We have text-align-last property that says what the last line does. There's a justify value. So when you can't justify a line in the middle of the paragraph we say do whatever text-align-last is. fantasai: If it's justify we don't know what to do. We need another fallback. I propose to just use centering. Use cases with text-align-last is justify is where they want centering as the fallback. Classic use case if the dish name is the column and it's 1-7 characters. If last line is 1 character is should center. fantasai: Since there doesn't seem to be a strong case to have the last line fallback to anything other than centering, I'm proposing we make it center all the time if you're not caught by text-align-last. Florian: When do we do something other than center? fantasai: You can't justify text in most languages, you just fall back to start alignment. Those cases are covered by when you have text-align-last to start. Rossen: You're argument is for text-align-last it should be always center. fantasai: The initial value is start. If you have set text-align-last to justify, the fallback is center. Rossen: I'm not 100% sure. Florian: I concur on the CJK use case. I don't know the other languages. Rossen: If you have only one word start makes most sense in non-CJK. fantasai: But for that you wouldn't have set text-align-last koji: I agree with fantasai. text-align-last is set in most CJK use cases. Rossen: Objections? RESOLVED: text-align-last: justify will compute to center for CJK. Rossen: That's the hour. Thanks to everyone. We made good progress on text.
Received on Wednesday, 5 October 2016 23:38:19 UTC