17:14:47 RRSAgent has joined #css 17:14:47 logging to https://www.w3.org/2017/11/06-css-irc 17:14:49 ericwilligers_ has joined #css 17:14:49 RRSAgent, make logs public 17:14:52 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 17:14:52 Date: 06 November 2017 17:15:03 dtapuska has joined #css 17:15:17 Rossen: Welcome everyone, let's start with intros 17:15:58 Hexcles_ has joined #css 17:16:04 Naomi has joined #css 17:16:04 +1 we need dbaron for multicol 17:16:09 present+ 17:16:10 szager has joined #css 17:16:18 Rossen Atanassov, Microsoft 17:16:18 alan stearns, adobe 17:16:26 Peter Linss, Invited Expert 17:16:30 Florian Rivoal, Vivliostyle 17:16:32 lajava has joined #css 17:16:32 L. David Baron, Mozilla 17:16:47 Xidorn Quan, Mozilla 17:16:49 François REMY, Microsoft 17:16:52 chrishtr has joined #css 17:16:56 Melanie Richards, Microsoft 17:16:56 Ian Kilpatrick, Google 17:16:57 Eric Willigers, Google 17:16:57 Surma, Google 17:17:02 Greg Whitworth, Microsoft 17:17:03 Rob Flack, Google 17:17:05 Brian Kardell, JS Foundation 17:17:06 present+ 17:17:08 present+ Naina Raisinghani, Google 17:17:11 Jihye Hong, LGE 17:17:14 Rachel Andrew, Invited Expert 17:17:15 present+ 17:17:22 Christian Biesinger, Google 17:17:22 present+ 17:17:26 Tomoya, VOYAGER Japan 17:17:32 dtapuska, Google 17:17:35 Jet Villegas, Mozilla 17:17:45 fantasai, Invited Expert 17:17:55 present+ 17:18:02 Chris Harrelson, Google 17:18:04 Brad Kemper, Invited Expert 17:18:36 LD has joined #css 17:18:43 present+ Javier Fernandez, Igalia 17:18:47 hyojin has joined #css 17:19:02 present+ 17:20:12 Daniel Holbert, Mozilla 17:20:41 Topic: Selectors 17:21:22 tmichel has joined #css 17:21:30 TabAtkins: We don't need to discuss this 17:21:31 Younji_Jang has joined #CSS 17:21:42 trchen has joined #css 17:21:43 wilhelm has joined #css 17:21:53 ericwilligers_: I'll add a test 17:21:57 aboxhall has joined #css 17:21:59 Proposed Resolution: no change 17:22:03 github issue https://github.com/w3c/csswg-drafts/issues/1933 17:22:25 Rossen: let's move on then 17:23:03 Rossen: leaverou added this to the F2F 17:23:09 Rossen: who wants to summarize this 17:23:25 Rossen: let's swap and wait for leaverou 17:23:29 Rossen: last issue on the list 17:23:33 smfr has joined #css 17:23:34 Rossen: target-within 17:24:18 plh has joined #css 17:24:47 *projector being setup* 17:24:50 Chris has joined #css 17:25:13 tpac_room has joined #css 17:26:14 Rossen: CSS Backgrounds 17:26:27 dbaron: was there someone not wanting to miss sizing? 17:26:50 *discusses timing for agenda* 17:27:04 topic: Sizing 17:27:34 github: https://github.com/w3c/csswg-drafts/issues/1722 17:27:39 Rossen: max-content size of replaced elements 17:28:10 fantasai: we discussed what to do with replaced elements that is percentage sized that has an intrinsic aspect ratio 17:28:14 tantek has joined #css 17:28:19 fantasai: *gives an example* 17:28:37 fantasai: if there is a specified min-width or min-height use that rather than the intrinsic aspect ratio in that dimension 17:29:08 dbaron: the effect that that would have is that if your min-width or min-height is smaller than the intrinsic size in that direction then you use that 17:29:20 dholbert: if it's not min-width/height of auto? 17:29:22 fantasai: yes 17:29:39 dbaron: what your saying is if min-width/height are non-auto you'd use them in the aspect ratio? 17:29:42 fantasai: yes 17:29:49 dbaron: there are some weird interactions around this 17:29:53 dbaron: it seems worth trying 17:30:05 present+ 17:30:08 dbaron: I think someone should try it before committing 17:30:14 dbaron: I'm worried about web compat 17:30:22 fantasai: this scenario is not a very common case 17:30:23 cyril has joined #css 17:30:32 fantasai: I don't know why you're doing this 17:30:38 dbaron: the main case I can think of is SVG 17:31:02 Rossen: currently that will work 17:31:08 dholbert: in FF that doesn't work 17:31:14 fantasai: so it isn't interoperable right now 17:31:16 fantasai: so... 17:31:30 fantasai: let's give it a try 17:31:46 dbaron: put it into the spec with the note to provide feedback 17:32:04 tantek: we're changing a resolution right? 17:32:10 fantasai: right, from a few months ago 17:32:16 tantek: I'm worried about back compat 17:32:26 tantek: they may have implemented 17:32:35 fantasai: they haven't, that's the point 17:32:46 There are some examples in this pen, if you want to look at current behavior: https://codepen.io/AmeliaBR/pen/brdBvQ 17:32:52 tantek: when we had auto sizing for SVG things we had all kinds of interop issues 17:33:07 s/auto sizing/box sizing/ 17:33:11 Rossen: who's going to write the test cases 17:33:13 thank you AmeliaBR ! 17:33:34 Rossen: I hear some concerns about compat 17:33:37 no objection, now that we have a test case to check impls 17:33:54 Rossen: but also given the fact there is no interop on the issue then we should resolve on something that makes more sense 17:33:59 Rossen: any objections? 17:34:16 Rossen: resolved 17:34:25 Vlad has joined #css 17:34:33 Rossen: please bring the test cases forward when you start working on the actual text 17:34:33 present+ 17:34:45 zcorpan has joined #css 17:34:56 Topic: Auto resizing of iframes and textarea based on content size 17:35:13 github: https://github.com/w3c/csswg-drafts/issues/1771 17:35:14 TabAtkins: there have been many requests for textarea and iframes resize on content 17:35:23 TabAtkins: we talked it over and thought, yeah probably ok 17:35:33 present+ 17:35:35 TabAtkins: we started experimenting with this 17:35:56 TabAtkins: figure our some mechanism content based sizing for textarea and iframes 17:36:10 present+ 17:36:17 TabAtkins: we learned some issues impl seamless with iframes due to COR leaking information 17:36:36 TabAtkins: we suspect we'd walk up the frame tree until we hit a fixed size to resolve the mqs 17:36:48 TabAtkins: Someone from Moz impl this 17:37:05 dbaron: we got the spec to say that's how media queries work, but seamless was removed 17:37:19 dbaron: we have code for it - but it's not necessarily something you can write up in a spec 17:37:27 MIKI_ has joined #css 17:37:27 dbaron: you need to figure out how to spec it 17:37:33 iank_: what type of interesting things 17:37:45 dbaron: I'd need to look, like it tries to do layout 17:37:59 s/do layout/do layout, and then tries again/ 17:38:17 rossen: we used to have a technology that would allow you to do layout based on then content size and we killed it 17:38:24 q+ 17:38:25 Rossen: performance becomes a concern for those 17:38:53 The iframe use-case for me is known width (set by container), auto (preferably auto-expanding) height 17:38:57 Rossen: when you consider extensions they try to size the box, and it's shrink to fit it becomes very bad for perf 17:39:12 Rossen: Our experimentation for this suggests it was bad, but maybe you'll find something 17:39:21 TabAtkins: they're both pretty separate features anyways 17:39:26 q? 17:39:33 TabAtkins: are we ok experimenting in this space 17:39:48 TabAtkins: the textarea would go into sizing 4 17:40:01 smfr: we've had the auto sizing of the iframe even COR 17:40:16 smfr: it makes your frame layout outside in rather than inside out 17:40:27 smfr: we've had quite a few media query bugs 17:40:48 smfr: we ran into media query cycles 17:40:59 TabAtkins: that means that you weren't doing media queries the way we defined 17:41:06 q- 17:41:09 pkerr has joined #css 17:41:13 skk2 has joined #css 17:41:19 smfr: it does bring about nasty things in the code 17:41:33 TabAtkins: how is this different from regular layout 17:41:35 sam has joined #css 17:41:47 smfr: you can avoid laying out the iframe, if you have to you have to dirty the other nodes 17:41:54 TabAtkins: ok, let's talk about this later 17:42:16 dbaron: I think the media query problems you had were due to doing what authors weren't expecting 17:42:17 sam_ has joined #css 17:42:19 TabAtkins: this would be opt in 17:42:31 tantek: how do you trigger behavior in iOS 17:42:34 smfr: you always get it 17:42:56 smfr: users don't experience nested scrollers, we always wanted page scrolling to win so you don't get trapped 17:43:09 tantek: width is expected and height is auto 17:43:11 smfr: yes 17:43:27 glazou has joined #css 17:43:34 Rossen: ok, so - it seems that Google wants to experiment with this - Apple has it and wants to remove it 17:43:44 Rossen: do you want a resolution 17:43:55 TabAtkins: The textarea one is simple enough to go into sizing 4 17:44:01 TabAtkins: the iframe one can go in WICG 17:44:19 Rossen: any objections to adding textareas to CSS Sizing L3 17:44:25 fantasai: yes 17:44:33 TabAtkins: I said 4 17:44:37 Rossen: Ok, L4 17:44:42 fantasai: ok - I'm ok with that 17:44:53 Rossen: Changes to sizing L4 17:44:57 fantasai: we can add a note for L3 17:45:06 Resolved: Add textarea sizing to Sizing L4 17:45:42 RESOLVED: Add textarea sizing to Sizing L4 17:46:13 *discuss whether to do in WICG* 17:46:47 TabAtkins to spin up a WICG regarding auto sizing of iframes 17:46:50 I'm a bit surprised that we're not even putting into a WD something that's been shipping in iOS for 10 years 17:47:13 Topic: Restricting stretch and fit-content to width and height 17:47:16 github: https://github.com/w3c/csswg-drafts/issues/1913 17:47:25 TabAtkins: I missed the telecon 17:47:44 tpac_room_ has joined #css 17:47:48 dbaron: I'm a bit hesitant as it exposes primitives to the system but yeah you can't use it over here 17:48:00 dbaron: I don't feel that strongly though 17:48:31 TabAtkins: we didn't feel that strongly either but it felt like more effort than warranted 17:48:43 Chris has joined #css 17:49:12 TabAtkins: we use min in weird ways, fit-content especially 17:49:29 fantasai: it's fine but we couldn't figure out how to use the stretch as a minimum 17:49:33 fantasai: do we need this? 17:49:44 fantasai: if we don't we don't need to put the effort in for testing etc 17:50:01 Rossen: so do we keep it 17:50:09 florian: do authors have any opinions 17:50:18 jensimmons: fantasai can you explain what this is 17:50:35 fantasai: would you ever use min-width or min-height of 100%, it does effectively that 17:50:46 jensimmons: I'm sure people do use that 17:50:55 fantasai: if that seems like a reasonable thing to use 17:51:18 I've definitely used min-height: 100%; height: 0; in some cases. 17:51:19 q? 17:51:22 cbiesinger: Seems useful, might want to fill a screen but grow if more content 17:51:27 dbaron: the other question is would you want to use them inside a calc() expression for min-width and min-height 17:51:41 jensimmons: I am hesitant to remove it 17:52:18 Resolved: Keep them as they are in the spec (don't remove them) 17:52:50 https://github.com/w3c/csswg-drafts/issues/1865 17:53:04 Topic: intrinsic size of 'overflow: auto/scroll' and its impact on auto-sized grid/flex item ancestors 17:53:08 github: https://github.com/w3c/csswg-drafts/issues/1865 17:53:25 pkerr has joined #css 17:53:51 fantasai: grid and flexbox show this issue, where people have an element with a scrollbar and they put it among a whole bunch of other content 17:54:21 fantasai: it forces that has a min-content size which defeats the purpose of the scrolling the author defined 17:54:37 fantasai: this leads to a lot of confusion for authors 17:55:04 fantasai: they're already handling their overflow and it would be nice if they just worked 17:55:15 fantasai: this was filed that would allow us to come up with a way for this to work 17:55:24 q+ 17:55:47 fantasai: I was talking with cbiesinger on Saturday to try and have the min-content zero'd out 17:56:36 fantasai: the min-content contribution which has overflow be 0, but not the logical height depending on its overflow. If you did this you'd have to relayout in flow content to determine it's min and max 17:56:43 q+ 17:56:46 fantasai: it's an idea, we're looking for other ideas 17:56:47 q- 17:57:26 dbaron: The thing with overflow that is not visible the size is the content within it, it has to propagate through it if it's the only thing 17:57:51 dbaron: I tend to think, that there is not going to be a thing that we can do to solve this with a property that allows them to choose the thing that they want 17:58:05 dbaron: I think there are two different scopes 17:58:27 q+ 17:58:34 q? 17:58:56 1. intrinsic control intrinsic width that has overflow 17:59:10 2. properties that allow assignment to the intrinsic widths 17:59:26 dbaron: the advantage of the first one is it gives more room for auto behaviors that do the right thing 17:59:37 dbaron: the advantage of the second is it is strictly more powerful 17:59:41 q+ 17:59:42 q? 17:59:47 ack fremy 17:59:47 fremy: I wanted to note that we had a similar issue in the table spec 18:00:26 fremy: if you have a % height and you're overflowing in a non visible way we should resolve to 0 18:00:38 fremy: the author intent is pretty clear here 18:00:51 fremy: to me this makes sense and is generalized 18:00:55 q? 18:01:24 fantasai: for grid and flex items specifically the automatic minimum size is not triggered on items that are not with overflow that is not visible but it does impact content contribution 18:01:55 cbiesinger: you said that the single items need the content contribution to propagate through 18:02:10 dbaron: because people will use it to hide things rather than scroll it 18:02:14 fantasai: that's a good point 18:02:23 s/use it/use 'overflow: hidden'/ 18:02:28 dbaron: you're talking about zering out the min-content sizes 18:02:35 fantasai: yeah, just the min-content size 18:02:43 s/zering/zeroing/ 18:02:47 q? 18:02:51 ack cbiesinger 18:02:52 dbaron: presumably the min-content sizes don't matter 18:03:15 cbiesinger: for the min size of flex and grid would make it zero in this cases 18:03:24 dbaron: in many cases you want them to get smaller but not to 0 18:03:51 fantasai: a lot of the cases that are here the minimum would be controlled by other content that happens to be there 18:04:47 fantasai: if they don't want it to get to 0 they can set a min size on the flex or grid item 18:05:06 or on the scroller itself 18:05:07 dbaron: the other thing I worry about here is compat 18:05:16 cbiesinger: that is concerning 18:05:26 dholbert: Chrome already does this correct? 18:05:35 This is more understandable than having a scrollable descendant of a grid or flex item several layers deep in a subsection of a subsection cause the flex/grid item's width to explode out 18:05:51 cbiesinger: I don't think we do that, but we do is for column flex we don't give it a min-height 18:06:03 dholbert: I thought there was something there for overflow: scroll 18:06:10 cbiesinger: I'd need to look at it 18:06:10 s/column flex/nested column flexboxes/ 18:06:57 Proposal in two parts: 18:07:13 1 flex/grid items with overflow != visible | hidden have min-content contribution of zero 18:07:15 Rossen: I read through the post about this issue, but I'd want more use cases for this. I am not going to object, but there will be compat issues for this 18:07:22 Rossen: dbaron any objections? 18:07:24 Rossen: can you speak up? You are very quiet. Or move a mike closer to you. 18:07:30 2 inline dimension of block with ovefow != visible | hidden has mincontent contribution of zero 18:08:01 dbaron: I wouldn't object, but I'd like to discuss the compat implications 18:08:16 Rossen: we can discuss this on the side - let's not rush the resolution 18:08:45 dbaron: I would be hesitant to come up with something too magical 18:08:53 Rossen: unless there is something else to be discussed 18:09:03 jcraig has joined #css 18:09:35 Topic: Define which replaced elements are affected by width: % rule zeroing min-content 18:09:37 github: https://github.com/w3c/csswg-drafts/issues/1889 18:09:55 fantasai: we would like to resolve on this issue 18:10:05 fantasai: we would want dbaron approval 18:10:39 text is: https://github.com/w3c/csswg-drafts/commit/6a3be51bdda0ccb92af0d09556d6d1f2e7d8874d 18:10:46 https://drafts.csswg.org/css-sizing-3/#min-content-zero 18:11:07 elements include: select, textarea, progress, meter. 18:11:13 *explains commit up above* 18:11:47 fremy: the only one I can think of is input type="color" as I think most browsers implement it as a button 18:12:19 fantasai: these are things that the min-content contribution is going to be zero'd out if a %age is used on there 18:12:34 fremy: I think for us it's just easier to add color to this 18:12:39 dholbert: same for us 18:13:06 nmccully has joined #css 18:13:22 fantasai: for things that need to remain for UX, you might want to reserve some amount of that space, the exception list should include button 18:13:51 fantasai: the button gets its size from the content 18:14:17 Rossen: what fremy is advocating for is so that input type color doesn't disappear 18:14:37 trchen has joined #css 18:14:50 TabAtkins: we can say some spec lang to allow anything that's like a button 18:15:12 Rossen: in our case it's just a button that has the swatch 18:15:37 fantasai: that makes it so that you can't go down to zero and would loose the swatch? 18:15:43 Rossen: yes, which defeats the point 18:16:04 fantasai: that is the same with the text input you can go down to 0 and can't type 18:16:24 Rossen: what is the push back on including color 18:16:41 fantasai: maybe it's that is tied to a button 18:16:53 TabAtkins: that's why I suggested "button like" 18:17:14 TabAtkins: everything that looks like a button 18:17:53 Rossen: are you ok with this? 18:17:55 fantasai: yeah 18:18:09 Rossen: with the amended button like to the list, any objections? 18:18:31 Rossen: ok resolved, pending dbaron opinion 18:18:53 *break 15 minutes* 18:19:10 side note: css-ui-4 should likely say something about "button like" per the properties it has 18:21:55 MS has joined #css 18:22:49 bill_hofmann_ has joined #css 18:31:32 Tomoya_Kimura has joined #css 18:36:26 duga has joined #css 18:37:55 MS has joined #css 18:39:31 smfr has joined #css 18:39:53 Hexcles has joined #css 18:41:50 bradk has joined #css 18:42:59 myakura has joined #css 18:45:36 ed has joined #css 18:47:47 rachelandrew has joined #css 18:50:07 smfr has joined #css 18:50:38 bradk_ has joined #css 18:51:04 jensimmons has joined #css 18:53:12 tantek has joined #css 18:54:02 ScribeNick: TabAtkins 18:54:05 LD has joined #css 18:54:23 Topic: Sizing - moving min-width/height partial dfns to Sizing 18:54:39 github: https://github.com/w3c/csswg-drafts/issues/1920 18:54:54 fantasai: Oriol pointed out the Flexbox isn't the best place to define a new initial value for min-widht/height. 18:55:01 fantasai: Suggested it move to the Sizing spec. Makes sense to me. 18:55:21 fantasai: Definition of what automatic size means in Flexbox wills tay, but move the propdef that defines the keyword to Sizing. 18:55:24 Rossen: Sounds reasonable. 18:55:25 myles has joined #css 18:55:33 present+ myles 18:55:38 sam has joined #css 18:55:39 RESOLVED: Move definition of the min-width:auto keyword to Sizing. 18:55:52 present+ 18:55:59 Topic: Move box-sizing to Sizing 18:56:16 https://github.com/w3c/csswg-drafts/issues/1906 18:56:33 github: https://github.com/w3c/csswg-drafts/issues/1906 18:56:42 florian: Width and height are defined in 2.1. Box-sizing is defined in UI as a monkey-patch on that. 18:56:46 florian: Works, but is ugly. 18:56:57 florian: Now that UI is getting to Rec, it's about time we get that into a spec of its own. 18:57:07 joone has joined #css 18:57:11 present+ 18:57:13 florian: So we should take what's in 2.1, apply the box-sizing patch, and put it into a spec, probably Sizing. 18:57:19 florian: Also need ot make sure it work for logical/etc. 18:57:30 florian: So Sizing 4 looks like a good place to have it. 18:57:39 Naomi_ has joined #css 18:57:55 Rossen: This is in UI3, already tested, right? 18:58:09 Yes 18:58:10 [Ian Kilpatrick wins CSS Bingo] 18:58:14 lajava has joined #css 18:59:15 florian: Right, it's in UI3, and staying there as it goes to Rec. It's only in there, tho, because 15 years ago we thought UI would be the first to hit Rec. Turns out to have been true, but there are better places for it. 18:59:31 fantasai: Happy to pull in the monkey patch, hesitant to pull in all of 2.1... 18:59:39 >_< 18:59:59 Rossen: No need to dive into details, just about moving box-sizing from UI4 to Sizing. 19:00:09 RESOLVED: Move the box-sizing property from UI 4 to Sizing. 19:00:18 Topic: CSS BAckgrounds - background-flip and text-underline 19:00:26 Younji_Jang has joined #CSS 19:00:32 github: https://github.com/w3c/csswg-drafts/issues/900 19:00:43 fremy: It seems we always consider underlines as part of the text shape 19:01:05 chrishtr has joined #css 19:01:05 fremy: So for background-clip: text, you draw the background only under the text of th eelement. Intention is you set the text to transparent, so the background layer fills in for the text. 19:01:29 fremy: In Firefox tho, the color of the text doesn' tmatter for the shape, but the transparency fo the underline is applied as an opacity on the background. 19:01:47 fremy: So if people use color:transparent, the underline is too, and the background under the underline becomes transparent. 19:01:49 @___________@ 19:02:00 fremy: I don't think this makes sense... Edge is not doing this. 19:02:01 BogdanBrinza has joined #css 19:02:26 TabAtkins: This sounds like accidentally over-applying an opacity filter... 19:02:41 fremy: I think it would be good to specify the behavior. 19:02:41 zcorpan has joined #css 19:02:52 jcraig has joined #css 19:03:42 smfr: Related, the fill and stroke module will someday handle this, right? Should we even specify this, given that it'll be replaced? 19:04:55 TabAtkins: So back to François's point - settle that text color shouldn't ahve any effect on background 19:05:03 fremy: And that text-decoration should be included as part of the text shape. 19:05:18 RESOLVED: text color has no effect on background-clip 19:05:34 RESOLVED: text-decorations should be considered as part of the text shape for background-clip purposes 19:05:46 I would definitely expect background-clip: text to include the underline area. Looks like browsers do that even when the underline is from a parent element: https://jsfiddle.net/yLwq77ss/2/ 19:05:59 Topic: Transforms 3d contexts 19:06:45 github issue https://github.com/w3c/csswg-drafts/issues/1944 19:07:11 trchen: In CSS, having a stacking context does not guarantee an element to be a containing block for every descendent element 19:07:20 trchen: And being a contining block doesn't imply being a stacking context 19:07:30 github: https://github.com/w3c/csswg-drafts/issues/1944 19:07:36 trchen: 3d context is a stacking concept - it decides which planes need to be 3d-sorted against each other 19:07:50 trchen: But at the same time we define 3d context of elements based on containing block 19:07:56 trchen: Causes "3d context penetration problem" 19:08:07 trchen: Element can be flattened by another element that's not part of its containing block chain 19:08:09 aaronchu__ has joined #css 19:08:28 trchen: We're working on a project in Blink to simplify compsoiting code, foudn some ill-defined corner cases 19:08:49 trchen: Planning to have a breakout session tomorrow afternoon? 19:08:53 aaronchu_ has joined #css 19:09:00 smfr: Would like to have a browser vendor rep from each for the breakout tomorrow. 19:09:53 zcorpan_ has joined #css 19:10:26 [discuss details of the breakout] 19:12:07 bingo update: all 4 rewards are gone :) Thanks for playing 19:12:35 scribenick: bkardell_ 19:13:32 topic: css grid 19:13:42 github: https://github.com/w3c/csswg-drafts/issues/509 19:14:05 ??: we have two different issues 19:14:23 me 19:14:37 s/??/lajava/ 19:14:55 :we have undefined width and height 19:15:05 all options for percentage gaps listed in https://github.com/w3c/csswg-drafts/issues/509#issuecomment-333236096 19:15:15 the issue we are discussing now is for grid gaps 19:15:26 fantasai listed different options after some discussion 19:15:57 Karen has joined #css 19:16:09 dydz has joined #css 19:16:12 our discussion from blink/webkit : we prefer to keep exisitng behavior keeping, treat them as 0 for intrinsic size/layout 19:16:21 estellevw has joined #CSS 19:16:25 lajava: is requesting option F = contribute zero, resolve as percent for columns, resolve as zero for rows 19:16:34 in the issue there is an explanation 19:16:54 we think that what happens in ff is broken with that approach 19:17:07 ed has joined #css 19:17:08 if we dont do that for margins, we should be consistent 19:17:27 we have to decide from the options fantasai listed and agree to do it the same 19:18:29 fantasai: my concern with f) in that list is that it has been a goal of grid to have symetric behavior in both axis 19:18:39 fantasai (before previous): I think we agreed to eliminate C and E. 19:18:50 We're discussing the list in https://github.com/w3c/csswg-drafts/issues/509#issuecomment-333236096 , I assume? 19:18:57 related to that, we think there are issues to do that with tracks as well 19:19:01 yes, dbaron 19:19:08 it's not impossible, but there is no browser doing that 19:19:27 all of the browsers consider cols and rows diff 19:19:50 so I'm not sure that should be important in solving for gaps - perhaps we decide not to do it for the tracks 19:20:47 rachelandrew: there are issues teaching this to authors. generally people understand when you say this will resolve to 0, the goal of having symmetrical gaps would be nice. 19:21:08 rachelandrew: if we can't have them symmetical, having the rows go to 0 makes sense 19:21:17 lajava: I agree with that 19:22:21 ??: are we just talking about intrinsically resized grids 19:22:30 estellevw has joined #css 19:22:41 joone has joined #css 19:23:32 s/??/dholbert/ 19:24:08 lajava: d) tries to resolve the same way in both axis 19:24:45 so rachelandrew is for F, not D 19:24:48 rachelandrew: if we didn't have % gaps, if we changed existing behavior ...? 19:25:40 jensimmons: if you had that situation in the inline direction where you didn't have an explicit width those gaps would also resolve to 0, it's just not a common use case 19:26:03 jensimmons: if you said you want this to be 100x100px - in both directions the gap would be 10 19:26:57 jennsimmons: i dont know if what you are describing is that the algo is doing the math diff ? 19:28:01 ScribeNick: fantasai 19:28:08 ScribeNick: dbaron 19:28:20 frremy has joined #css 19:28:24 ScribeNick: frremy 19:28:58 lajava: there are two reasons we don't want back compute for the gaps 19:29:21 lajava: backcomputing when the percentages are close or bigger than 100% the solution isn't that great 19:29:57 lajava: the second reason is that we decided not to do that for margins, and so we would like to work the same for gaps 19:30:20 q? 19:30:24 dholbert: well, on that, I think margins are just a legacy thing 19:30:55 TabAtkins: I would be opposed to anything that could yield to sizes bigger than the max size a browser can allocate 19:31:09 TabAtkins: it's very easy to end up in such cases with back-computing 19:31:14 Rossen: +1 19:31:24 bradk_ has joined #css 19:31:45 Rossen: for this issue, the currently listed options are on the screen, and the github 19:32:11 Igalia would prefer B, D, or F 19:32:16 lajava: yes 19:32:20 yatil has joined #css 19:32:34 Rossen: Edge's preference would be to keep symmetry 19:32:38 present+ EricE_(observing) 19:32:57 bill_h has joined #css 19:33:10 Rossen: if resolving in one of the pass is not possible, though, resolving to zero as usual is fine 19:33:50 Rossen: F is therefore not a great solution 19:34:09 Rossen: between B and D, I would like to hear more opinions 19:34:19 TabAtkins: B is expensive, there might be fragmentation issues 19:34:26 Rossen: which fragmentation issue? 19:35:15 TabAtkins: could contribute, but we could discuss this later when this comes up 19:35:34 glazou has joined #css 19:35:46 dholbert: What would happen for auto grid with percent columns? 19:36:02 Rossen: let's say you have a 2x2 grid that has to shrink in both dimentions 19:36:05 smfr has joined #css 19:36:33 Rossen: if that grid had a size, we would compute properly and things would be symmetric 19:36:47 Rossen: but if the grid is floated, we will have to compute percentages has zero 19:37:02 Rossen: but in the second pass, we are given a choice 19:37:05 here's the example Rossen is stating: http://jsbin.com/dozonezuvi/edit?html,css,output 19:37:09 Rossen: either add the gaps and overflow slightly 19:37:11 The float will have the width & height of 2x item size, then have choice of how to compute percentages 19:37:15 Rossen: or you can continue to resolve to zero 19:37:24 Rossen: this is the difference between B and D 19:38:25 SteveZ has joined #css 19:38:26 sorry - wrong snapshot: http://jsbin.com/lalayakuxe/1/edit?html,css,output 19:38:53 lajava: Igalia doesn't mind B but the problem is that if you are auto and overflow by default, that seems counter-intuitive 19:39:48 Rossen: the only con of D seems that some authors could be unhappy about this 19:39:57 Rossen: but I would like to make sure that is really the case 19:40:25 Rossen: because authors can still use other units, or give a specified size to the grid 19:40:53 fantasai: (reading a summary of the A-F proposals) 19:41:09 A = contribute back-computatation ratio, 19:41:09 resolve as percent 19:41:09 B = contribute zero, resolve as percent 19:41:09 NOT C = contribute auto, resolve as percent 19:41:10 D = contribute zero, resolve as zero 19:41:11 NOT E = contribute auto, resolve as auto 19:41:14 F = contribute zero, resolve cols as percent & 19:41:16 rows as zero 19:41:19 NOTE: only for intrinsically-sized grids 19:41:20 jcraig has joined #css 19:41:21 explicit / stretch-fit grids always resolve 19:41:24 Cons: 19:41:26 A = contribution can explode grid 19:41:29 B = unhappy authors with overflowing grids 19:41:31 C = super broken 19:41:34 D = unhappy authors missing % column-gap? 19:41:36 E = even more broken 19:41:39 F = B + D + asymmetrical 19:42:13 Rossen + florian discussing why A cannot be fixed 19:42:25 jeff__ has joined #css 19:42:31 q? 19:42:35 (aka, see previous times this was discussed) 19:42:35 ack fantasai 19:42:45 dsinger has joined #css 19:43:10 jensimmons: Using percentages for gaps for auto-sized things is not great 19:43:25 jensimmons: because they will see their gap change size when the content changes 19:43:26 dauwhe has joined #css 19:43:37 jensimmons: so they will realize this is not what they wanted 19:44:03 fantasai: yeah, I can see that happening, I'm getting convinced by D too now 19:44:51 Rossen: Proposed resolution: gaps expressed in percentages resolved and layouted as 0 in auto-sized directions 19:45:36 rachelandrew: there might be a few people that are going to hit this problem if they try to replace parts of an existing layout they cannot entirely control 19:46:10 fantasai: but this would apply to cases where the grid is auto-sized 19:46:17 s/auto-sized/shrinkwrapped/ 19:46:30 not to cases that have a definite containing block 19:46:31 rachelandrew: yes, but I don't know how common that would be 19:46:48 iank_: we are at 0.1% of all pages for grid all up 19:47:17 iank_: so I guess this case wouldn't be frequent at all 19:47:35 Rossen: but the conversation is about porting content that currently uses percentages to grids 19:47:45 s/at all/at all once you consider it has to be also using percentage gaps, in a shrink-wrapped context/ 19:47:49 Rossen: though I don't really see how they can achieve this today in a way that works in all browsers 19:48:32 jensimmons: I think those cases are very fragile currently, they use margins/paddings on floats 19:48:52 jensimmons: but in those cases usually, the container has a width, even if it is 100% 19:49:26 rachelandrew: (general feeling of doubt, but I didn't catch the exact words) 19:49:26 q? 19:50:25 dholbert: so this would only happen about floated grids, and abspos grids 19:51:04 dholbert: but in a flexbox, you are suppose to layout as having a definite size after flexing, so percentages would work there right? 19:51:08 TabAtkins: correct 19:52:09 rachelandrew & jensimmons talking about author's work to port existing things, ex: new york times shipping grid inside bootstraps 19:52:43 Rossen: so, would your doubts be enough to raise an exception today? 19:53:13 rachelandrew: no, I just wanted to shed some light on this, we can come back on this if needed 19:53:22 Rossen: any objection? 19:53:25 D = contribute zero, resolve as zero 19:54:03 RESOLVED: Option D: percentage gaps in shrink-wrapped grids min-size as 0 and layout as 0 19:54:25 s/min-size as/contribute/ 19:54:32 Topic: Percentage tracks 19:54:37 Github: https://github.com/w3c/csswg-drafts/issues/1921 19:54:42 github:https://github.com/w3c/csswg-drafts/issues/1921 19:55:27 lajava: To keep things symmetric, we tried to add cases to resolve percentages for height of rows 19:55:31 dauwhe_ has joined #css 19:55:47 lajava: But we don't have min-content phase in the block direction, like we do for width 19:56:07 lajava: So we would need to duplicate a second pass to make this work 19:56:21 lajava: So 1st we would like this recorded clearly in the spec if that is required 19:56:35 lajava: And all browsers would have to change their implementation 19:57:01 florian: and why not just follow what browsers already have implemented? 19:57:15 Rossen: the change would be relatively straighforward, it's no big deal 19:57:29 florian: but we would possibly break content, right? 19:57:47 Rossen: everything we do ends up breaking someone's content, I don't think this would be an issue here 19:58:53 lajava: well, we are still unsure about what would happen in more complex cases like in orthogonal flows 19:59:11 lajava: but at the very least it would require a second pass, once you know the intrinsic height 20:00:01 Rossen: any opinion from Mozilla? 20:00:12 Rossen: there is still time to fix, but window is closing 20:00:31 dholbert: I don't have a strong opinion, and Matt hasn't commented on the issue 20:00:57 dholbert: I don't like adding new layout steps usually 20:01:08 Rossen: but it's easy to know if you need to do it before hand 20:01:23 Rossen: only do it if you have percentage-sized row tracks 20:02:12 dholbert: but if it is an orthogonal flow, you have to relayout entirely right? 20:02:25 lajava: yes, but this already happens anyway 20:02:35 s/Matt/Mats/ 20:02:43 Rossen: any objection? 20:03:25 RESOLVED: percentage tracks sized as percentage resolve the same way for columns and rows, which involves a second layout pass in some cases 20:04:01 Topic: "Equal Gutter" with justify-content 20:04:11 github: https://github.com/w3c/csswg-drafts/issues/1116 20:04:14 myles has joined #css 20:04:28 fantasai: users often want row-gaps and col-gaps to be equal 20:05:04 fantasai: but they also want the horizontal gaps to fill the remaining space once you've put as many columns as possible in the width direction 20:05:22 fantasai: they can do that using justify-content 20:05:34 fantasai: but they cannot transfer this size in the other direction 20:05:44 fantasai: this is basically a request for thoughts on the topic 20:05:51 https://github.com/w3c/csswg-drafts/issues/1116#issuecomment-288472394 20:05:57 Just to summarize, the example is 20:05:57 definite width, auto height grid container 20:05:57 auto-fill columns e.g. 100px 20:05:57 auto-placed items 20:05:58 place-content: space-between 20:05:59 The spacing produced by space-between is not equal in both axes. 20:07:57 jensimmons: so is the idea { row-gap: as-column-gap } 20:08:02 jensimmons: ? 20:08:17 TabAtkins: pretty much 20:09:44 (general discussion, but it was thought to minute) 20:09:54 s/thought/tough/ 20:10:03 fantasai: the tricky thing is that two things control the gap size 20:10:08 fantasai: the gap property 20:10:14 fantasai: and the alignment properties 20:10:25 fantasai: you do have to consider both to get the desired effect 20:11:02 fantasai: and there are interersting cases of space-evenly which creates a gap before the first column and after the last column, we will need to define what to do about that 20:11:21 the gap properties only distribute space between the columns, but alignment can do other things 20:11:36 florian: and the proposed syntax would allow to also define alignment in the direction in which you said to copy 20:12:03 florian: I think we should have a more restrictive syntax that doesn't allow the impossible cases would be better 20:12:13 florian: but I don't have a concrete proposal right now 20:13:27 jensimmons: just to clarify, the alignment do not update the gap, they add a gutter right? 20:13:39 fantasai: yes, but visually it looks like the same thing 20:13:54 jensimmons: so it looks like we want something to transfer the gutter not the gap 20:14:06 dholbert: maybe some align: symmetrical then? 20:14:46 dholbert: alignment properties already are allowed to increase a gap 20:15:12 dholbert: it would be possible to also shrink the gap to make it match, that doesn't sound unreasonable 20:15:20 Naomi_ has left #css 20:15:29 dsinger has joined #css 20:15:42 Or possibly not shrink, but grow-or-leave-the-same (to avoid) 20:15:42 Rossen: alright, I think we should probably break out to lunch, and have people interested in this proposal talk with each other 20:16:12 Rossen: let's get back here at 1.30 20:16:26 rachelandrew has joined #css 20:16:30 *(to avoid violating author expectations that "grid-row-gap: 100px" should actually insert at least 100px of space) 20:16:51 Topic: lunch 20:20:32 florian has joined #css 20:24:45 Hexcles has joined #css 20:26:08 florian_ has joined #css 20:26:43 dauwhe has joined #css 20:30:46 estellevw has joined #css 20:42:25 aaronchu has joined #css 20:51:20 florian has joined #css 21:02:14 Karen has joined #css 21:03:35 duga has joined #css 21:06:47 lajava has joined #css 21:12:08 Karen has joined #css 21:16:22 bradk has joined #css 21:16:30 florian has joined #css 21:17:56 florian has joined #css 21:17:57 myles has joined #css 21:18:22 dauwhe_ has joined #css 21:19:08 florian has joined #css 21:24:31 dydz has joined #css 21:27:28 jcraig has joined #css 21:27:52 Tomoya_Kimura has joined #css 21:28:14 xidorn: https://drafts.csswg.org/bin/issuegen.pl 21:29:05 florian has joined #css 21:32:12 If you're in town for TPAC, leonie, Chris and I are hosting a party on wednesday night. DM me for an invite. 21:32:15 glazou has joined #css 21:32:22 jamesn has joined #css 21:32:22 florian_ has joined #css 21:33:24 trchen has joined #css 21:33:26 Chris has joined #css 21:34:42 florian has joined #css 21:35:07 will start again at 1:45 21:37:26 jensimmons has joined #css 21:39:20 zcorpan has joined #css 21:42:01 SteveZ has joined #css 21:42:37 smfr has joined #css 21:42:38 xiaochengh has joined #css 21:43:26 Hexcles has joined #css 21:44:20 jamesn has joined #css 21:46:31 ScribeNick: iank_ 21:47:29 lajava has joined #css 21:47:59 tantek has joined #css 21:48:08 dsinger has joined #css 21:48:48 Naomi_ has joined #css 21:51:10 astearns: Talked with the chair of TTWG, about CSSWG equiv things, talking with them on Friday this week. 21:51:11 https://github.com/w3c/ttml2/issues/406 21:51:12 rachelandrew has joined #css 21:52:33 astearns: Looking for volunteers to go the meeting. 21:52:48 astearns: Lets go to non-interop of sizing images in flexbox 21:53:04 Topic: Non-interop of sizing images in flexbox 21:53:06 github: https://github.com/w3c/csswg-drafts/issues/1322 21:53:29 fantasai: 21:53:41 bradk has joined #css 21:53:53 fantasai: Testcase in last comment 21:54:29 fantasai: Flex container, and has some content that shrink down to their min-content size, if you have too many items they'll start to overflow. 21:54:52 fantasai: Excess space starts to take up, the text starts to break, 21:55:05 fantasai: The item with the image starts shrinking. 21:55:16 fantasai: This FF behaviour is kinda nice. 21:55:44 fantasai: So we want to make FF follow the spec? Or make other vendors follow FF implmentation> 21:55:45 ? 21:56:04 fremy has joined #css 21:56:14 dholbert: I wrote most of the flex code in FF, and don't know whats going on here. 21:56:26 gregwhitworth: What is the usecase where folks would want this behaviour? 21:56:43 fantasai: This means that it won't overflow, where other implmentations would. 21:57:03 dholbert: being able to shrink them is kinda nice. 21:57:09 I just dropped this example in this codepen: https://codepen.io/jensimmons/pen/aVmogq 21:57:15 fantasai: The image doesn't shrink until everything else has wrapped. 21:57:46 cbiesinger: If you give the image a flex-basis: auto , and others a flex-basis of 0, don't you get that behaviour? 21:57:59 fantasai: You wouldn't be able to get them to start out at their content sizes? 21:58:28 fantasai: I don't think we need to resolve now, but interesting to think about. 21:59:03 dholbert: I'll try and figure out whats happening in our impl, and report back on the github issue. 21:59:51 jensimmons: I had a few questions about flexbox, lets of interop issues around squishing images, and because of those issues, they are really hard for authors to think about. 22:00:06 astearns: Def. want interop here, just need to agree what that behaviour is. 22:00:27 Rossen: It looks like we have all the impls apart from FF, having interop. 22:00:43 Rossen: Switching to FF, means that we might run into compat. 22:01:06 fantasai: We were going through interop cases, and most of them were obv., but this one seemed interesting. 22:01:30 jensimmons: It also seems like we could do what we want, as there seems to be such lack of interop around images. 22:01:42 gregwhitworth: Only about this issue? 22:01:53 jensimmons: No, more broadly about images as flex items. 22:02:05 gregwhitworth: Where are the bugs? 22:02:06 jcraig has joined #css 22:02:15 fantasai: Don't have them here. But this one just seemed interesting. 22:02:31 Topic: Image Decoding 22:03:01 smfr: This should be fairly short. WebKit making more of its image decoding async, to a separate thread. 22:03:08 jensimmons: it would be cool to see the full list of issues for images as flex items 22:03:31 smfr: Browsers do this in different ways, if an image has loaded (event), there won't be a flash. 22:03:54 smfr: Off main thread decoding for animated images, - fairly straight forward. 22:04:09 smfr: Also tried to do this for a large images. 22:04:23 smfr: A bunch of authors have assumptions about where the decode happens. 22:04:46 smfr: Would like to propose a new APIs to allow us to do background image decoding. 22:04:50 https://html.spec.whatwg.org/multipage/embedded-content.html#dom-img-decode 22:04:51 smfr: 2 things we've done so far. 22:04:55 lajava has joined #css 22:05:11 smfr: Proposed an API for decoding. promise = img.docode(); 22:05:28 smfr: 22:05:51 https://github.com/whatwg/html/issues/1920 22:06:13 Github: https://github.com/whatwg/html/issues/1920 22:06:13 smfr: The 2nd thing that we've proposed, a way for authors to tell the engine that is ok to decode these images async. (may be a flash). 22:06:31 chrishtr has joined #css 22:06:36 smfr: A way for authors to opt into async decoding for , but no way to do this for CSS images. 22:06:36 https://github.com/whatwg/html/issues/1920 22:06:56 smfr: This might be something like a new image function, or additional argument to the image function, etc. 22:07:08 smfr: Nothing written up yet. 22:07:32 TabAtkins: We left space for an async tag, in the url() function. 22:07:46 22:08:26 smfr: Google images does a thing where they load a low res image, and then replace to a high res image. 22:08:38 smfr: This is broken in FF, and Edge. 22:09:15 Thomas Moz: Can authors opt into sync decoding instead? 22:09:37 s/Moz/Wisniewski/ 22:09:43 smfr: I think we need the attribute to go both ways... might have an "auto" which is current browser behaviour. 22:10:10 leaverou: Whats the usecase for authors to control this? 22:10:25 smfr: Want to display large images, without blocking the large images. 22:10:32 leaverou: Why control for authors. 22:10:54 smfr: For compat reasons we can do this in more cases, as it introduces flashes. 22:11:17 smfr: Lots of sites to this based on size of page, this case we'd always to sync decoding. 22:12:02 Flash Of Asyncronous Image Loading (FAIL) 22:12:13 smfr: If an image is going low-high res, you really don't want a flash. The user-agent doesn't have enough information to make the best decision. 22:12:17 smfr: It's hard for a UA to tell whether the image is replacing something similar to itself (e.g., a low res version) or whether it's replacing a blank space or a placeholder. 22:12:28 smfr has joined #css 22:12:40 leaverou: Is there a way to provide a fallback image. 22:12:44 leaverou: ? 22:12:55 TabAtkins: image() function has this. 22:13:13 does "no loading" include something that's cached? 22:13:24 TabAtkins: We could have it such that the image() function will look until it can render something that can be immediately rendered. 22:13:46 leaverou: What's a data URL of an SVG considered to be? 22:14:01 dbaron: Isn't there one reason that you need this the fact that there is a 'load' event for images, do you need this for CSS as there isn't a load event for CSS? 22:14:24 TabAtkins (in response to lea): idk 22:14:43 smfr: Authors do things like load the same image with an img tag, then place the same image into CSS. 22:15:11 smfr: With decode you need to have additional information like the size of the image. 22:15:13 also a remote image that has already been loaded and decoded for some other reason should probably be fair game too? 22:15:16 though then you have race conditions 22:15:34 chrishtr: The promise returned isn't permanent, such that the UA can evict it from the cache if needed. 22:15:48 smfr^: prefer to have a declarative solution to this problem 22:16:09 fremy: There are way for authors to place images on top of each other. 22:16:22 (assuming no transparency, anyway!) 22:16:33 smfr: We saw a bunch of different ways that people did this. 22:17:02 smfr: We found that there wasn't a way to do this well unless that authors told us what they wanted. 22:17:17 plinss: Is there going to be an event? 22:17:36 smfr: No, unless we want to fire events for CSS images in general, I don't think that we should special case. 22:17:49 Topic: Line Clamping 22:18:45 GitHub: https://github.com/w3c/csswg-drafts/issues/390 22:19:23 ms has joined #css 22:19:28 TabAtkins: Ignore the topic of the github issue, basically many years ago, hyatt added some hacky code that turned the -webkit-box code, to allow it to do line clamping. 22:19:41 TabAtkins: If you have more ignore them for sizing purposes. 22:20:02 TabAtkins: The implemenation is weird, very weird behaviour, property etc. 22:20:03 jnurthen has joined #css 22:20:08 TabAtkins: We'd like to address this properly. 22:20:38 TabAtkins: This is the only major part of the -webkit-box code that needs to be maintained. 22:20:50 TabAtkins: What needs to be mapped, preserved for line-clamp, and removed. 22:21:15 TabAtkins: We'd like to start up a spec to handle the line-clamping behaviour. 22:21:28 q+ 22:21:43 eae: Would like a way to eventually alias this property over. 22:22:10 eae: And would like to do this in a way that other folks can alias. 22:22:23 florian: I don't remember the discussion of the spec. 22:22:30 q+ 22:22:41 florian: Expand on what we already have? 22:22:45 TabAtkins: yes. 22:22:51 ack smfr 22:23:02 smfr: Would like to extend this feature a little. 22:23:12 smfr: Collapses quoted text... 22:23:35 smfr: Collapses in the middle of the content. 22:23:42 q? 22:23:55 q- 22:23:59 smfr: We would like to see this as start, end, middle. 22:24:42 q+ 22:25:04 q+ 22:25:13 aaronchu has left #css 22:25:40 florian: max-lines as currently specified is a fragmentation thing, makes the div into a fragmentainer, that breaks after a certain number of lines. 22:25:50 florian: Drop the rest of the lines. 22:26:02 s/Collapses quoted text.../Mail client has a feature where it keeps some lines at the beginning, keeps osme lines at the end, and collapses in the middle of the content, with clicky in the middle to expand itall back/ 22:26:05 florian: Could make it such that you get additional lines. 22:26:44 yjang has joined #css 22:26:53 smfr: We did consider fragmentation to implement this feature, I don't really have opinions on how to do this. 22:27:06 smfr: It does interact with fragmentation possibly 22:27:16 ack leaverou 22:27:20 leaverou: Why is this being discussed in terms of max-lines, and not max-height? 22:27:50 florian: images inbetween for example, typically people want to clamp lines. 22:28:03 florian: and break at a fragmentation point ,not slice partway through a line 22:28:31 florian: The generalized this in overflow-4 lets you deal with heights... 22:28:37 q+ 22:28:48 florian: And let you decide if the additonal div gets dropped. 22:29:01 leaverou: In most cases i've seen the clipping is visual. 22:29:07 nmccully has joined #css 22:29:16 florian: But you don't want to split in the middle? 22:30:38 leaverou: If an ellipsis isn't displayed, people want use this. 22:30:50 florian: Its a separate issue... 22:30:54 s/want/won't/ 22:30:57 ScribeNick: eae 22:30:57 I am absolutely for postponining ellipsis discussion variants until CSS3-UI is a REC :) 22:31:01 ack iank_ 22:31:15 s/postponining/postponing 22:31:20 estellevw has joined #css 22:31:23 iank_: One thing I'd like to stress is that we've seen a lot of demand for somehting simple like clamping the number of max-lines. Would like to keep it simple and not expand scope too much. 22:31:47 iank_: Clamping both start and end adds complexity as it requires layout out all of the text. Have to think about. 22:32:11 wdh_ has joined #css 22:32:24 iank_: We're looking to remove support for percentage values for webkit-line-clamp. Behavior is bizare and there is essentially zero usage. 22:32:38 ack fantasai 22:32:39 use counter for percentage values: https://www.chromestatus.com/metrics/feature/timeline/popularity/2139 22:32:41 q+ 22:32:43 ack gregwhitworth 22:33:10 fantasai: I agree that we should limit scope. A lot of thoughts are great and valid use cases. I don't want to go there right now. Want to understand actual proposal 22:33:40 fantasai: As I understand from proposal, treat as max lines and set height based on that. Is there more to it then that? 22:34:14 TabAtkins: Yon don't want the lines to still be there like with line-clamp, we want to omit the rest of the lines. 22:34:26 TabAtkins: Want to supress display of line boxes after the cut off. 22:34:44 TabAtkins: Right now they are simply considered to be of zero height for sizing but are still there 22:35:05 fantasai: So the ellipsis gets inserted? 22:35:42 https://drafts.csswg.org/css-overflow-4/#issue-6fadc074 22:35:44 florian: The machinery of clamping or cloning or fragmentation is invoked implicitly if set max-lines. There is an issue saying that one has to explicitly enabling the fragmentation support. 22:36:06 q+ 22:36:22 iank_: My only concern with that is that invokes a bunch of machinery that takes a lot of implementation work. A simple max-lines beahvior is potentially a lot simpler. 22:36:32 florian: Concerned that it would require a lot of reinvention. 22:36:52 Rossen: Want to reemphasis fantasais question. In my mind we keep going back and forth between two different things: 22:37:07 Rossen: 1) Fragmentation and stop layout at some boundary. should thing of this in css4 22:37:29 Rossen: 2) Existing pane, what tab is taking about. We have a a lot of requests for webkit-line-clamp support. 22:37:30 plh has joined #css 22:38:06 Rossen: My point here again. This is different. If we want to be compatible with -webkit-line-clamp then the behavior is different. Not fragmenting, consumes space differently. 22:38:29 Rossen: Not that different to implement as long as it doesn't involve fragmentation. 22:38:39 fantasai: Would like to see a concrete proposal. 22:39:02 TabAtkins: The goal of this was to start up something that at the bare minimum addresses the "I want n of something". 22:39:19 TabAtkins: All resonable things that I'd like to see addressed. Should resolve whether we want to do or not. 22:39:48 fantasai: line-clamp can be made to support a subset of uses cases but if you want support for more complex use cases then the problem gets a lot harder. 22:40:13 Chris has joined #css 22:40:22 fantasai: Should try to tackle the problems one at a time. Have something basic that isn't quite 0webkit-ine-clamp, but without eventually supporting everything. 22:40:55 q? 22:41:08 TabAtkins: I would like to explore the space. Replace -webkit-line-clamp first and then, maybe, extend it later. 22:41:19 ack florian 22:41:58 What I'm saying is I don't want to expand line-clamp, I would rather it stayed as some minimally simple property that could be used to build other things. not be expanded to do other things. 22:42:08 florian: responding to ian/rossen. When I was talking about invoking the machinery not walking about ..., to deal with fragmentation. I think we sort of have to, if not then we'd have to resolve what to do about text shadow, intruding floats etc. Would rather refer to the fragmentation spec. 22:42:27 florian: Would also be compatible with the rest of the spec in the future. 22:42:49 florian: css overflow invokes css break, max-lines already speced there. 22:43:00 https://www.w3.org/TR/css-break-3/#possible-breaks 22:43:45 ScribeNick: TabAtkins 22:43:58 Topic: Cleaning up OWNERS files 22:44:15 gregwhitworth: I got put on a review for Syntax (which shoudl never occur, I don't know it) 22:44:27 gregwhitworth: That exposed a problem - I submitted some tests, those people should be in owners. 22:44:42 gregwhitworth: When I add a flexbox test, 9 or 10 owners are added, but geoffrey ends up always reviewing them 22:45:03 gregwhitworth: So if we could go thru and review the oWNERS files and make sur eit's actually the QA owners 22:45:14 boaz_ has joined #css 22:45:15 foolip has joined #css 22:45:17 gregwhitworth: Whoever is actually going to be the person that will review a given spec. 22:45:41 astearns: I think >1 person is good, but yeah, if you're on an OWNERS file and not willing to review, is it just a PR to remove yourself? 22:45:51 gregwhitworth: Yeah, just asking everyone to do it for themselves. ^_^ 22:45:58 astearns: And adding yourself to oWNERS where appropriate. 22:46:10 q+ 22:46:24 gsnedders: There has historically been some habit of using that like a cc flag, rather than a test-owners thing. 22:47:09 Chris has joined #css 22:47:10 foolip: This ties into triage - we can mess with OWNERS files, but we also need to ntoice when people in those files aren't doing reviews. 22:47:25 foolip: Also helps us discover where we need to add people. 22:47:42 foolip: What do people who are submitting tests want? Immediate review, I guess, but how do you deal with spec issues when things go unnoticed for a while? 22:47:56 florian: For spec issues we eventually had to do a DoC, so we go thru and make sure nothing was dropped. 22:48:04 dydz has joined #css 22:48:16 florian: That helps with specs that are worked on, even if slowly. But it doesn't help specs that aren't worked on. 22:48:29 foolip: So that's like every quarter or so? 22:48:31 [laughter] 22:48:39 florian: Usually much slower. Sometimes every few years. 22:49:01 foolip: So any prefs on how this should work? A bot emailing the list when things go unnoticed? 22:49:21 florian: If we sent something every *year* when things were reviewed, it would be a massive improvement. 2 days would be crazy fast. 22:49:29 Vlad_ has joined #css 22:49:49 gregwhitworth: Related: if you've ever committed to a spec, go to w-p-t repo and check the OWNERS files. If you're not actually relevant for that spec, remove yourself. 22:50:02 dbaron: Or if you notice yourself getting reviews for something you feel like you shouldn't be reviewing. 22:50:10 Topic: Feedback on testing policy 22:50:39 zcorpan: I made a PR in Sep to add a testing policy for the CSSWG for specs in CR. 22:50:45 zcorpan: + CSSOM and CSSOM-view 22:51:04 zcorpan: I wanted to get feedback from the WG on how this has been going - if policy is working, what benefits, what might need changing. 22:51:28 chris: In other groups that do this, editors do PRs and then the WG approves and merges. 22:51:36 chris: IN there, adding a test in is really easy. 22:51:44 Chris: 22:51:56 Chris: In our group we don't do that, editors push to master. that makes this hard. 22:52:21 Chris: *Some* editors seem to be doing tests and specs together, it's useful. 22:52:36 florian: I've tried to be more systematic about writing tests with changes, and linking to the tests from the changes. 22:52:53 florian: What I haven't noticed is a significant difference in reviewer activity; I was worried it would be the bottleneck, and it still is. 22:53:08 florian: We haven't been doing this long enough for my anecdotes to become data, but it doesn't seem improved from the past. 22:53:35 Chris: The spec-readiness things that go out every week, I've been guilty of using that to push people on reviewing things. 22:54:09 Karen has joined #css 22:54:16 (issues with "Needs Testcase" label https://github.com/w3c/csswg-drafts/issues?utf8=✓&q=label%3A"Needs%20Testcase%20(WPT)"%20 ) 22:54:33 gregwhitworth: I'm gonna be a pain - I agree with florian from last discussion. I desire a world where everything modern - I run flex, grid, vars, etc - I'm running daily our build system, and if it turns red I know we regressed or the spec changed. 22:54:42 gregwhitworth: This is very important, I can't keep track of everything. 22:54:50 gregwhitworth: I'd like to start giving teeth to this. 22:55:14 gregwhitworth: I don't think we'll ever get to the interop goals us browsers want without tests added for every change. 22:55:30 foolip: What teeth would you like to add? 22:55:36 gregwhitworth: There's words that it's CR. 22:55:51 gregwhitworth: I feel like it should be more universal. 22:56:07 gregwhitworth: Every other WG MS is in has this policy - every spec change has tests along with it. We're the only WG that doesn't. 22:56:10 I would be ok with WD + impls 22:56:17 = require test case to make normative change 22:56:20 not just WD 22:56:29 gregwhitworth: Just spent a lot of time reviewing flexbox tests, finding a lot of old redundant tests, a huge waste of time. 22:56:50 florian: Even tho this is somewhat informal, this group sometimes does internal incubation, and forcing tests then seems counter-intuitive. 22:56:53 q+ 22:56:55 jcraig has joined #css 22:56:59 dydz has joined #css 22:56:59 TabAtkins: I wanna talk, do I q+ 22:57:05 ? 22:57:06 yes 22:57:06 florian: Once we reach the point we're no longer brainstorming, actually refining... 22:57:09 q+ 22:57:12 q+ 22:57:39 foolip, it's not required always, but when things get crowded it's helpful :) 22:57:40 ack gregwhitworth 22:57:44 plh_ has joined #css 22:57:49 ack foolip 22:57:54 boazsender has joined #css 22:57:56 q+ 22:58:01 foolip: Most other groups don't have a CR req, it's jsut a matter of "if it makes sense at this point, let's do that". 22:58:07 foolip: That's a problem for immature stuff. 22:58:18 foolip: So the criteria I propose is: anything with one or more impl has tests. 22:58:20 +1 22:58:26 foolip: Means you can punt on testing until someone tries to implement. 22:58:33 q+ 22:58:39 q+ 22:58:45 foolip: And first implementor is in a good position to write tests. Shouldn't always be editor's task; it's not that in the WHATWG. 22:58:51 ack TabAtkins 22:58:54 dbaron: Same - when you ahve impls. 22:58:54 ack dbaron 22:59:01 dbaron: Also it's very dangerous to write tests without impls. 22:59:16 dbaron: You write a whole bunch of tests, try to execute spec in your head, and it turns out that people are worse at that than software. 22:59:27 q+ gregwhitworth 22:59:27 q+ gregwhitworth 22:59:28 q+ 22:59:30 dbaron: So you end up with lots of tests that are wrong in subtle ways. 22:59:32 +1 22:59:37 q+ 22:59:46 +1 22:59:48 dbaron: We also have a general problem of losing track of things like spec changes, edits, and figuring out the state of things. 22:59:51 q? 22:59:56 dbaron: Part of that is that we tend to resolve to change things, and then nothing happens. 23:00:05 dbaron: I feel like we should try to use GH issues more for this. 23:00:15 for people reading the logs, https://github.com/foolip/testing-in-standards/blob/master/lifecycle.md is my whole thinking about when it makes sense to start caring about testing. 23:00:18 dbaron: If we ahve a thing we agree to do and it's not done yet, we should be tracking it in GH as an open issue. 23:00:19 resolutions for normative changes MUST be in a github issue 23:00:23 florian: ARen't we already doing that? 23:00:26 dbaron: I feel like we're not. 23:00:47 dbaron: This includes us agreeing to some resolution, and there isn't an issue for it. 23:01:07 TabAtkins: After F2F, make sure everything is in an issue or tracked otherwise 23:01:17 dbaron: Even in a meeting - should have an issue as soon as we discuss something. 23:01:55 astearns: Going back a bit, question of teeth. 23:02:09 astearns: Whether we should apply this rule to CR+, or bring it back to things with impls. 23:02:13 astearns: What are the teeth? 23:02:21 astearns: We haven't been consistent about it even with CR+ 23:02:25 q+ 23:02:41 q? 23:02:49 TabAtkins: For anything in testing stage, only do edits via PR-merging. 23:02:49 ack astearns 23:02:55 TabAtkins: Only push to master for incubation-stage stuff. 23:02:58 for normative changes 23:03:04 editorial should not require that 23:03:11 astearns: Agree 23:03:18 agree with tantek 23:03:19 q+ someone_i_cant_see_raising_hand 23:03:55 florian: If we agree to enforce it that way, we need to be careful about how to process the giant backlog, and if elika and tab create 25 PRs per week, still problem with processing them 23:04:06 dsinger has joined #css 23:04:11 florian: So going from "a bunch of specs not tested" to "most of the spec is in hanging PRs" isn't an improvement. 23:04:32 fantasai: That's my point - "why don't you block edits on writing tests", I think it's better to publish things where they can see them, instead of seeing a diff. 23:04:46 fantasai: Some things will only require one test, others will need 200. I don't want to be on the hook for all of those. 23:04:56 astearns: That's not the request - SOME tests, not a full test-suite. 23:05:10 also important to drop or update existing tests that are affected! 23:05:11 florian: Not full test suite, just full tests *for the feature being tested*. 23:05:18 astearns: I'm saying just "at least one". 23:05:28 fantasai: Like, if I change an orthogonal flow thing, I need to write like 500 tests. 23:05:28 q? 23:05:29 q? 23:05:29 q+ 23:05:31 q+ 23:05:33 fantasai: That's an extreme example 23:05:41 ack florian 23:05:43 fantasai: but 30+ test isn't uncommon 23:05:57 florian: REgardless of the rules we set up, we won't solve this until some companies set up a budget to pay for QA. 23:06:07 florian: If we don't get that, we'll rely on the goodwill of people like me, and that doesn't scale. 23:06:18 ack zcorpan 23:06:28 zcorpan: PR model in the whatwg - every change has a PR, someone needs to review, someone needs a testcase. 23:06:37 zcorpan: Without that, the PR is left open, we never commit to master. 23:07:01 zcorpan: Sounds like there's some issue with the workmode - edits get made, we forget about testcases, or resolution are made and we forget about edits, that sort of thing. 23:07:15 zcorpan: So what workmode do we need to not lose track of things. 23:07:23 fantasai: I think GH is helping a ton with that, to the extent that things are in GH. 23:07:31 fantasai: resolutions get in there from gh-bot 23:07:37 fantasai: And we have a needs-testcase flag. 23:07:51 q? 23:08:04 zcorpan: Responding to fantasai's point, about changes with a big testcase burden. 23:08:24 zcorpan: The whatwg policy is that in such cases, instead of writing the tests, you file an issue with wpt explaining that this change needs testcases. 23:08:35 zcorpan: Or something is blocking writing the testcases. 23:08:38 boazsender has joined #css 23:08:42 zcorpan: So documenting that testcases are missing, and why. 23:08:44 s/The whatwg poicy/The policy in CONTRIBUTING.md/ 23:08:59 florian: So this sounds like a variant of our needs-testcases flag; not sure which is better if nobody looks at them? 23:09:09 s/The whatwg policy/The policy in CONTRIBUTING.md/ 23:09:19 zcorpan: If it's straightforward but a lot of work, then needs-testcases in CSSWG seems like it's sufficient. 23:09:35 zcorpan: But sometimes there's toolin gmissing to write it at all, in wpt, so that needs a separate fallback. 23:09:45 zakim, close queue 23:09:45 ok, astearns, the speaker queue is closed 23:09:55 q? 23:09:55 zcorpan: So then we need an issue in wpt, saying that the current tooling makes it impossible to write a case for. 23:10:03 ack gregwhitworth 23:10:12 gregwhitworth: I agree with the once-one-impl thing. 23:10:27 gregwhitworth: I know internally we're focusing more on testing. 23:10:44 gregwhitworth: I think it's worthwhile, as much as we'd all love to solve every problem in spec form, we all depend on interop. 23:10:57 gregwhitworth: Doesn't matter if we all implement some new thing if it doesn't work properly in every browser. 23:11:13 gregwhitworth: So go with PR, say it doesn't land without at least one test. 23:11:29 gregwhitworth: And with gh issues, often there are already testcases, just informal, need to be wrapped up in testharness 23:11:39 gregwhitworth: I don't think it's a monumental task to get this working. 23:11:51 gregwhitworth: And when we go implement it, we'll create more testcases, and implement that. 23:12:11 fantasai: Yeah, one or two testcases is way more manageable than "please fully test this change in all permutations". 23:12:25 gregwhitworth: I'd love when we go to CR we already have a testcase working. 23:12:56 gregwhitworth: To hammer home the point - I'd like to get some reoslution that's beyond CR. 23:13:13 gregwhitworth: I think we need teeth or else nothing will happen. 23:13:22 ack gsnedders 23:13:24 q? 23:13:29 gsnedders: I have 2 viewpoints. 23:13:40 gsnedders: I don't think there's any point in testsuites before impl, same as others. 23:13:56 gsnedders: But when there is an impl, the vendors who impl'd will have written tests, to land the feature. 23:14:02 gsnedders: So inherently there's already a testsuite. 23:14:08 florian: It might not be shared, or shareable. 23:14:27 gsnedders: Tho now we have 2-way sync from Gecko and Blink, so hopefully more and more tests are in wpt from the get-go. 23:14:33 gsnedders: The other thing is getting tests per edit. 23:14:41 gsnedders: So presumably, when someone impls the edit, there's a test for it. 23:15:29 TabAtkins: We don't want to hold up PRs until someone impls something. 23:15:29 q? 23:15:39 fantasai: Yeah, anything that forces us to hold a PR for 2 weeks is a failure. 23:15:55 fantasai: In 2.1, we had that errata list, and if you wanted to impl something you had to check the spec and the errata. 23:16:10 fantasai: This got super unwieldy s,o we eventually merged it in. 23:16:15 fantasai: I don't want to get into that same state. 23:16:39 fantasai: But if we're withholding edits from being published for too long, that's a failure state. 23:17:00 gsnedders: When it comes blocking things on PRs, the experience from the other groups that have done this is that we don't end up blocking on PRs. 23:17:02 florian: How? 23:17:03 the point of changing the process is to change the way people spend their time 23:17:08 gsnedders: Someone comes along and actually looks at it. 23:17:17 s/same state/same state, except way worse because instead of an errata list you have a disorganized pile of diffs in GH PRs/ 23:17:30 gsnedders: Sometimes someone wanted ot impl it, so they want the PR landed. Sometimes because someone is watching and reviewing the changes. 23:17:38 gsnedders: Generally there's far less problem getting review. 23:17:47 dbaron: The point of changing the process is ot change how people spend their time. 23:18:05 dbaron: I think if we're changing the process ot make people spend more time writing tests, people will spend more time writing tests. 23:18:09 q? 23:18:10 also the point is to reduce information loss (e.g. decisions) 23:18:15 q? 23:18:20 liam has joined #css 23:18:29 florian: And we might distinguish between "everybody" and "tab and elika". If we don't want tab and elika to spend less time writing specs, we nee dmore people to write specs. 23:18:42 s/specs/tests/ 23:18:48 florian: Their plate is already more than full being the catch-all editors. That's why I suggested someone funding the QA work. 23:19:04 ack foolip 23:19:16 foolip: I don't think it's a matter of decreasing thruput. 23:19:23 foolip: Ultimately everything needs to be implemented. 23:19:39 foolip: It's a matter of closing the feedback cycle, so the thing being written is closer to time of test being written and tine of implementation. 23:19:54 foolip: So getting impls more involved in writing tests and keeping track of changes to the spec. 23:20:07 foolip: It would be a failure if it ends up with the editor writing all the tests. 23:20:28 florian: My earlier point here - either we decrease tab and elika's thru-put, or we move test burden. 23:20:45 foolip: IN Blink, soon to actually ship something we'll require it to have wpt. So that's a forcing function. 23:20:56 foolip: Can't go on indefinitely without it being on a Chromium engineer's plate to get the work done. 23:21:29 fantasai: So that bug - made edits, made a PR, then engineer is leave of absence for months, then doe sa perf push, then a yEAR LATER someone finally impls it... the PR has been there for a year 23:21:47 fantasai: The spec needs to be reliably up-to-date with what we decided. 23:22:10 +1. We can’t have secret spec updates living in pull requests, invisible to people. 23:22:33 dbaron: If you make a spec change and *nobody* tries to implement it for a year, we'll just wait and change it again anyway. 23:22:50 fantasai: But if it hangs, and I need to change something about it, I can't see those edits. 23:23:03 fantasai: I can't deal with a pile of PRs like that. 23:23:11 hey when's the break? 23:23:11 fantasai: If we wait for impls to make the change, it'll always be months. 23:23:27 as a person who’s worked in git code repos for years, with teams, you cannot leave things lying around in pull requests. That’s a terrible way to work. 23:23:35 q? 23:23:36 I don't think the implementors have to be the ones who make the change 23:23:41 ack someone_i_cant_see_raising_hand 23:23:59 ???: I was gonna suggest we start with something simple, like have gh hooks that say when there's open requests in the spec. Someone will be annoyed and poke people. 23:24:08 dbaron: right, which brings us back to the eidtor has to make the test change 23:24:12 s/dbaron:/dbaron,/ 23:24:29 ???: And there's a push for people to go fix it up. 23:24:43 basically I'm saying foolip's idea that implementors will take up the responsibility to write tests for all spec changes is unworkable 23:24:46 q? 23:24:55 jensimmons: the experience in other groups hasn't been things lying around in PRs; if this WG can't get things reviewed that implies something is going wrong within this WG 23:24:56 s/???/twisniewski/ 23:25:09 Chris: Echoing fantasai, it's hard to review spec changes and tests with a bunch of diffs. 23:25:29 Chris: When I was doing the fonts 3 review, I put them in the w3c repo just so people could see them execute. 23:25:35 plh_: We have a mechanism for that in wpt. 23:26:25 astearns: I suggest we take out of this discussion to tighten up what we resolved on. 23:26:29 gsnedders: but that is the experience of *this* working group 23:26:31 astearns: Already resolved on tests for CR+ 23:26:49 astearns: I suggest we try out the PR for CR-level specs model. 23:26:54 --> http://w3c-test.org/submissions/ pull requests for WPT 23:27:10 astearns: With the caveat that we want to see how we deal with those PRs, so they don't just pile up. 23:27:11 jensimmons: yes, indeed; the question is why are participants, most of whom work for vendors, act differently to their colleagues in other WGs 23:27:26 florian: We'll still have stuff piling up. 23:27:35 florian: Nobody's been reviewing tests, even tho I'm blocked. 23:28:01 this is has been sitting here for 2 months: https://github.com/w3c/web-platform-tests/pull/7364 23:28:06 astearns: I don't see a way of solving that issue before break. 23:28:35 florian: I don't have a solution without money. 23:28:42 gregwhitworth: Or down the thru-put. 23:28:59 fantasai: So say we're like "you need tests for the PR, nobody else will do it, editors have to write the tests". 23:29:09 fantasai: So 50% of my time goes to tests or whatever. 23:29:22 jensimmons: and this is something we see relatively rarely for other testsuites, which implies for whatever reason the layout developers behave differently to e.g. the DOM developers, and it's not clear why 23:29:30 fantasai: Then people complain "why isn't this in the spec, I want to ship it yesterday" 23:30:05 gsnedders: struggling with getting people to write tests is *insanely* common in the industry of people who make websites. It’s not the CSSWG. 23:30:14 thank you astearns 23:30:22 jensimmons: yes, that's true; but it's not an issue we see around most of WPT 23:30:28 TabAtkins: The earlier faiure mode was "no impl happens for al ong while, so no urgency on the test, and the PR hangs". Here you're positing someone wanting to implement. They'll produce a test, then. 23:30:32
23:36:41 Chris has joined #css 23:37:04 Karen has joined #css 23:40:09 nmccully has joined #css 23:40:30 jcraig has joined #css 23:41:34 rachelandrew has joined #css 23:45:54 Naomi has joined #css 23:53:25 estellevw has joined #css 23:54:16 smfr has joined #css 23:55:21 jensimmons has joined #css 23:55:39 tantek has joined #css 23:59:20 dsinger has joined #css 00:01:58 nmccully has joined #css 00:02:52 We might need to recalibrate our definition of a minute... 00:03:03 ^ lol 00:03:11 isn't that in Units? 00:03:32 Units and values, clearly. 00:08:59 yjang has joined #CSS 00:11:30 A minute contains sixty seconds. Maybe , or maybe not. 00:12:17 bradk has joined #css 00:12:26 wonders what happened to http://testthewebforward.org/ seems to fade out in 2014 00:12:39 Hexcles has joined #css 00:13:19 zcorpan has joined #css 00:14:11 zcorpan_ has joined #css 00:14:19 smfr has joined #css 00:14:25 rachelandrew: basically we got no recurring contributions as a result of it so it basically fissiled out 00:14:38 s/fissiled/fizzled/ 00:14:49 rachelandrew: and it was Adobe people leading it and when the Adobe web platform team got laid off… 00:17:15 Topic: testing negative calc() clamping 00:17:27 astearns: I wrote some tests, and modified them before I checked them in, and now they're bad tests. 00:17:29 xiaochengh has joined #css 00:17:48 astearns: As far as I can tell, we have no interop at all. EVery browser clamps at a different time, depending on whether the animation goes up or down... 00:18:10 astearns: So I want impls to check on it. 00:18:35 ScribeNick: fantasai 00:18:37 Topic: Contains 00:19:24 github: https://github.com/w3c/csswg-drafts/issues/1809 00:19:26 TabAtkins: Whenever element generates more than one box? 00:19:36 TabAtkins: which box do we clip to? 00:19:45 TabAtkins: suggestion is principal box, that sounds great to me 00:20:24 fantasai: The principal box is the box that contains the content, seems like the right call 00:20:31 florian: list markers? 00:20:38 Chris has joined #css 00:20:39 TabAtkins: They get clipped if they're outside markers 00:20:45 fantasai: just like for 'overflow: hidden' 00:20:50 dbaron: Table captions? 00:20:58 fantasai: Table wrapper box is principal 00:21:07 RESOLVED: use principal box 00:21:42 topic: clarify style containment 00:21:46 Github: https://github.com/w3c/csswg-drafts/issues/1872 00:21:59 TabAtkins: question is, why does style containment restrict break properties? 00:22:08 fremy has joined #css 00:22:11 TabAtkins: Reason why I have these things set is I want to ignore a style tree for style computation purposes 00:22:21 TabAtkins: Should be able to completely ignore that subtree 00:22:27 TabAtkins: break property if allowed to work would violate that 00:22:45 TabAtkins: break properties propagate up 00:22:50 fantasai: They don't affect computation tho 00:22:57 TabAtkins: but they affect layout further up the tree 00:23:18 fantasai: break-inside doesn't propagate up, only forced breaks do 00:23:48 fantasai: Also sounds pretty bad in terms of fragmentation if you can't honor 'break-before: avoid' 00:23:56 Karen has joined #css 00:24:00 TabAtkins: Avoiding breaks should work, yeah... 00:24:39 fantasai: ... 00:25:14 florian: Since contain property is ahead of css-content, should put the bookmark-* / string-set prose into the css-content spec 00:25:17 boazsender has joined #css 00:25:48 dbaron: I'm trying to understnand model of possible optimizations here 00:25:58 dbaron: I don't see anything for which this is relevant 00:26:12 dbaron: Still doesn't feel like style containment tome 00:26:37 fantasai: Also if disallowing break-*, then why not margin-*? 00:26:49 dbaron: It seems like you're trying to introduce soemething but not really worked out what 00:27:07 dbaron: Maybe write out what that optimization is to make that clear 00:27:30 dbaron: and discuss others 00:27:55 fantasai: also pretty sure if break-* needs to be disallowed the margin-* collapsing should also... but that sounds more like layout containment 00:28:07 Topic: Scoped Counters 00:28:10 github: https://github.com/w3c/csswg-drafts/issues/1887 00:28:33 TabAtkins: If you have a style scoped element, which says counters are scoped to the subtree 00:28:41 TabAtkins: does that create a new counter? 00:28:46 s/that/counter-increment/ 00:28:55 Hexcles has joined #css 00:29:07 +1 on this one 00:29:20 TabAtkins: or does it increment the existing counter from the outside 00:29:42 tmichel has joined #css 00:29:54 TabAtkins: I think it should implicitly create a new counter scope at the style scoping root 00:30:29 fantasai: And so counters() would reveal a new level of counter? 00:30:30 TabAtkins: yes 00:31:02 tantek has joined #css 00:31:03 TabAtkins: Don't want to fuss with the subtree when calculating counters further down in the document 00:31:50 fantasai: so you're disagreeing with Oriol's comment? 00:31:54 TabAtkins: ... 00:32:00 astearns: Write a test? 00:32:09 s/.../yes/ 00:32:55 astearns: So proposed to implicitly create new counter scopes at style scoping root for style containment 00:33:09 RESOLVED: create new counter scopes at style scoping root for style containment 00:33:46 Topic: becoming a formatting context root 00:33:48 github: https://github.com/w3c/csswg-drafts/issues/1457 00:34:02 TabAtkins: we addressed this a bit in the past, text we had was bad 00:34:23 TabAtkins: layout containment needs a formatting context root 00:34:31 TabAtkins: wanted to say that the element ends up being an FC root somehow 00:34:36 TabAtkins: only a few places where that's difficult 00:34:38 TabAtkins: Some are easy 00:34:44 TabAtkins: flow root, table, flex, grid, all satisfy condition 00:34:55 TabAtkins: for display: flow, becomes flow-root 00:35:04 TabAtkins: Next issue is with ruby 00:35:14 TabAtkins: ruby is effectively inline element 00:35:34 TabAtkins: wanted to create a ruby inline block thing 00:36:07 florian: we don't have that yet. If it's not useful, do we really want to add it? 00:36:14 lajava has joined #css 00:36:54 TabAtkins: Better to fill the boxes, so this is consistent and defined 00:37:25 fantasai: How about saying layout containment doesn't apply to inlines. If you want it to apply, turn it into an inline block 00:37:55 Xidorn: create a wrapper box? 00:38:32 TabAtkins: wrapper boxes are scary and bad 00:38:39 fantasai: We have block ruby, it just creates a wrapper 00:38:53 TabAtkins: Make something block-like, either inline-block or block or somehting 00:40:21 fantasai: For most of these layout modes, the FCR-ification doesn't have much effect. Layout is fundamentally the same 00:40:34 fantasai: but for inlines and ruby, it's a very significant change to layout 00:41:06 fantasai: I'd rather say that layout containment just doesn't apply here, so the author is making an explicit decision about the layout change they're getting 00:41:48 TabAtkins: My two constraints for this problem is that contain should work on ruby because it works on inline, and that whatever effect it has should be possible to get without using 'contain' for its side-effect 00:42:00 florian: Suggestion is to apply contain to neither inline nor ruby 00:42:04 fantasai: that is my suggestion, yes 00:42:13 astearns: We don't have contain and inline ruby 00:42:25 astearns: is there a use case for contain on inlines? 00:42:33 fantasai: You can't get that. It turns into inline-block 00:42:46 astearns: So if we do this, what do we lose? 00:43:08 TabAtkins: Just that authors have to take an extra step of declaring inline-block 00:43:27 fantasai: I'm arguing that's a feature, not a bug 00:43:34 s/if we do this/if we choose not to apply contain to inlines/ 00:44:29 atai has joined #css 00:45:09 fantasai: If the author wants to have an inline block, should be explicit about it. if they didn't, then they're not going to be happy anyway 00:46:19 TabAtkins: internal table elements? 00:46:25 florian: We already resolved they don't apply 00:46:31 Topic: Calling Koji 00:46:59 ScribeNick: eae 00:48:56 Topic: line height / line spacing related 00:48:56 Topic: https://lists.w3.org/Archives/Public/www-style/2017Oct/0013.html 00:49:02 https://github.com/dbaron/css-line-spacing/blob/master/explainer.md 00:49:10 waiting for koji on webex 00:49:29 says "connecting..." for a long time... 00:49:51 smfr has joined #css 00:50:00 dbaron: Based on the discussions we had in paris. We were talking about rhythmic sizing and the connecitons to line box contain. We've also had the line grid module which was designed to address many of the same issues and rhythmic sizing. 00:50:28 dbaron: What I've been trying to do is look at the two and come up with a minimal viable product for line spacing in css and address existing concerns about line spacing. 00:50:45 dbaron: I've tried to separate out the important pieces, as described in doc linked above. 00:51:06 dbaron: Some people have raised concernes that I have addressed in the doc, others have raised concerns that I did not address 00:51:28 dbaron: Not interested in talking about naming. More interested in important use cases and what developers and designers really need form line spacing. 00:51:48 dbaron: That requires distinguishing what existing tools actually do versus what developers actually want. 00:52:18 dbaron: Figuring out what we need for line-spacing in css requires more knowledge about what these requirements are than I know. I think we have people in this room that know more about this than I do. 00:52:30 dbaron: People are welcome to read and comment on the doc. There is also a github page. 00:52:46 dbaron: More importantly, I want to determine what the requirmeents are 00:53:10 florian: I'm not the ultimate expert but have thought a bout it a fair bit. All use cases I want to address are equally addressed by your proposal. 00:53:30 I can't connect voice 00:53:30 florian: If it is a simplification I'm all for switching to it. There are tweaks that might make it better but lets leave that to the side for now. 00:53:38 and phone doesn't accept the mtg number 00:53:42 florian: FUndeamental problem shared width line grid. 00:54:01 florian: From my point of view, if it helps implementation I'm in favor of this proposal over line grid. 00:54:20 dbaron: I don't now what the key differences are. I don't think implementability was a key factor. 00:54:34 florian: I didn't notice anything I missed during the remvoval proces 00:54:44 iank_: is a line grid shared between formating contexts? 00:54:51 dbaron: think it is shared 00:54:55 yes, I think so...let me try again 00:54:56 florian: issue I want to tackle later. 00:54:59 boazsender has joined #css 00:55:12 dbaron: I think a lot of the key use cases are driven by things that are pretty separate. 00:55:34 fantasai: One think that was dropped which we might be able to readd later. Was to have every other or every third line snap to the line grid. 00:55:44 fantasai: Not super important right now but is issue that comes up. 00:56:12 fantasai: For instance if you have different font sizes, i.e. line with smaller text size that takes up 1/3 the space. 00:56:24 dbaron: I think of that as establishing a new grid. 00:56:39 florian: Don't think it is epeicaly critical. 00:57:10 myles: You're totally right, making an inner line grid that has a size of 1/2 is common and somehting we should eventaully support. 00:57:30 dbaron: some ways to approximate it. You could establish a new line grid. 00:57:50 dbaron: In order to snap baselines oyu need to be careful in how it relates to the other grid. 00:58:35 myles: Voicing weak support for your proposal. We haven't seen broad adoption of existing line grid spec. If this can get better support I like it 00:58:52 florian: Reverse question. Does switching to this increase the chance of getting it? What are we gaining? 00:59:10 dbaron: One thing we're gaining is the changing of the line hight model itself. 00:59:15 Hexcles has joined #css 00:59:27 florian: I'd argue we should add that as a seprate thing as people might want it without the grid. 00:59:38 dbaron: Agree but syntax will be tricky. 00:59:48 q+ 00:59:55 zakim, open queue 00:59:55 ok, astearns, the speaker queue is open 01:00:14 fantasai: From what I understand from prev. discussion: there are a variety of different levels of strictness re aligning to grid behavior. 1) I want a sane inline model, no grid. 01:00:16 estellevw has joined #css 01:00:51 fantasai: concept of really strict line grid, like physical pages where you can see things from the other side or facing pages. Multi-col in general. Where you want text to align across columns. Being stricter about grid in those cases is more important,. 01:01:55 fantasai: If you gave a large single block of text and an intrusion then a strict set of margins is more important than having an integral number of grid items. Reading might not see that it aligns to a grid. Width of margins might be more noticable. In those cases having a strict grid isn't desirable. 01:02:02 fantasai: We might need both approaches 01:02:05 q+ 01:02:14 ack Chris 01:02:21 zakim, clear queue 01:02:21 I don't understand 'clear queue', astearns 01:02:46 fremy: Wheteher we'll be more likely ti implement. Questions around BFC. Flexible columns snap to grid, how would that work? Needs to be cleared before we proceed 01:02:51 florian: On agenda for later 01:03:01 q? 01:03:35 iank_: Echo your concerns. As it stands I can't say whether we're happy with this proposal. Seems okay but we'd want to limit it with regards to bfc, flexbox etc. When line hight changes etc. Lots of remaining issues. 01:03:37 liam has joined #css 01:04:14 koji: I agree with fantasi that it should be avaliabl without grid. I also agree that we need a strict grid model. 01:04:36 nigel has joined #css 01:04:41 koji: I think dbaron's proposal is a little different. We need a less strict model as well. I think the flow model works better. 01:05:27 liam has joined #css 01:05:41 astearns: any other concerns or comments on David's proposal? 01:06:46 ???: I also agree that it seems like a good propsal. I have concerns about baselines defined in other specs and how they relate. You mentioned dominant baselines being used to align, other specs talk about other baselines and flow. I have use cases that need support for setting different baselines. Being able to specify the baseline to snap to the grid. 01:06:56 astearns: Those use cases are next on the agenda. 01:07:01 q+ 01:07:49 s/???/nmcully/ 01:07:52 Hexcles has joined #css 01:07:53 dsinger has joined #css 01:08:00 me 01:08:04 s/nmcully/nmccully/ 01:08:22 fantasai: I think that Davis proposal can handle this. Allows use of first or last baseline, you also have the option to use hanging baseline, etc using align-baseline property. You can not have it align the alphanumeric baeline with the cap height though, for instance. 01:08:32 s/Davis/David's/ 01:08:38 s/align-baseline/alignment-baseline/ 01:09:04 koji: Question to David. The item 4 in your proposal looks like a possible solution to double spacing? 01:09:39 dbaron: I think the changes to the line height calculation reduces the double spacing problem depending on ... hard to say if it fully solves it but in many cases when used well it'll solve it. 01:10:27 ack koji 01:10:29 dbaron: E.x if you're going to set a large line height it'll solve it more than a small line height. You're now applying the height on the line as a whole rather than the little pieces thus less likely to exceed height. If small line height more risk. 01:10:59 florian: If you're setting the size of the grid independently from the size of the font then it increases the risk. The problem isn't there in your proposal, 01:11:17 koji: That item 4 can then be applied to line-grid or rhythmic sizing? It's a general approach? 01:11:19 fantasai: Yes. 01:11:35 fantasai: No syntax for it but the feature would be generic. 01:11:39 koji: Thanks 01:11:46 s/would/could/ 01:11:53 s/for it/for it in the proposal/ 01:12:03 astearns: I think it would be interesting to try to apply that to the rhythm model and see what comes from it. 01:12:03 It's listed as the first Open issue 01:12:20 astearns: More comments or should we go on to use cases? 01:12:25 *silence* 01:12:45 astearns: Both the line rid and the rhythm proposals should take David's explainer into account. 01:13:20 fantasai: We should a) ty to fix the inline layout problem, helps everyone regardless of grid. No 1 priority in relation to fixing inconsitent line heights in a paragraph. 01:13:40 fantasai: We should continue to work on line-grid and ??? and both have come up as use cases that people want. 01:13:51 fantasai: block step size is probably easier, would work on that first. 01:13:58 fantasai: We should go through use cases and get a clear idea. 01:14:13 s/first/first, before line grid/ 01:14:22 dsinger has left #css 01:14:27 florian: Question. Do we want to try to resolve on replacing exisitng line grid with David's proposal? Or should we postpone that decition until after. 01:14:40 fantasai: Should put note in spec to point to the alternative. 01:15:07 q+ 01:15:14 myles: We shouldn't resolve to replace existing spec without first going through fixing to exisintg spec. 01:15:55 fantasai: We need to fix the inline model, need a lose grid and a strict grid. 01:16:24 fantasai: We have a step sizing proposal and a line grid proposal. Would work on step sizing next as it is better understood. Then to line-grid later. 01:16:31 koji: ok 01:16:37 s/lose/loose/ 01:16:48 ack koji 01:17:53 ???: Have a couple of use cases for grid snapping. I looked at the baseline spec and there are a couple of overloaded terms. There is center but it is not obvious whether which opentype baseline it maps to. 01:18:05 ???: Depending on the font and the font design are going to be quite different. 01:18:13 Karen has joined #css 01:18:46 s/???/nmccully 01:19:07 s/???/nmccully/ 01:19:12 nmccully: Projecting, for CJK layout the relevant metrics are the em box. Differ from bounding top/bottom. 01:20:14 nmccully: Mapping between latin and CJK font metrics are overloaded and the interaciton between western and cjk content is not up to designer. Would like to see more baselines or explicit ones for japanese fonts to allow pairing between CJK and latin with layout as expected. Would like these baselines to be avalible for all fonts. 01:20:34 nmccully: These baselines are critical for aligning. The metrics top center and bottom are then snapped to a grid. 01:21:37 nmccully: There are different snapping ebahvior begining to be supported in css. The possibilities where you snap lines, whether body grid with 14pt and letting with 21pt and a title between two paragrapghs where it is larger. You want to center that on two grid lines. The options of how you position glyphs within that tall line, whether you consider the taller one to be the line-hight or the large one. 01:22:18 nmccully: You're aligning glyphs within a line and the taking the line and aligning it to the grid. Each visible in different types of design. All possible variations might not be possible with the proposal. 01:23:03 nmccully: Snapping the firts line of a paragpgh, two use cases. 1) Body text paragrapgh followed by smaller size one, first line is snapped to grid smaller ttype one is not. Fllowing one is re-snapped to grid. Subtleties around what you do with the smaller line. Whether it is centered or 01:23:27 nmccully: ...two examples. First one is snapping to the top. Second one snapping to center. 01:23:42 Hexcles has joined #css 01:23:47 nmccully: Is not an even letting amount in first case. 01:23:59 nmccully: Both cases have adjacent flow that is top aligned in main column. 01:24:21 nmccully: This type of snapping, two flows snapping to grid, is one of the goals of this proposal 01:24:40 florian: Would this be solved using a line grid on the larger block and disabling it for the smaller one? 01:24:55 fantasai: If you know the relative sizes of the fonts you can make that work. 01:25:17 fantasai: In the first case you'd have a zero margin or line gap as needed, the second case you'd have that plus half the difference. 01:25:35 florian: You alig the stepped block on the dominant baseline 01:26:05 tantek has joined #css 01:26:13 q+ 01:26:13 fantasai: If you're able to align baselines that is easay to do. If you are in a conetxt without relationship and UA can't do baselines alugnment you'd have to compute the margin. 01:26:35 q+ 01:27:01 myles: Are everything you've shown here is common and valuable and are things the css spec need to support? 01:27:04 ack myles 01:27:06 ack koji 01:27:08 nmccully: Yes, I don't thinok any are edge cases. 01:27:48 koji: I agree that em top/bottom are important. Can't comment on line grid at the moment. em top and em bottom are not well defined today. 01:27:58 plh has joined #css 01:28:08 koji: I wish we defined it better and how it relates to dominant baselines. 01:28:39 koji: When we tried to do underlines for CJK there was no font metrics we could use for it. We computed em top and em bottom. Are not defined. 01:28:50 koji: This might be a good oppertunity to finally define them clearly. 01:29:23 nmccully: I agree. One of the things we did in OpenType was to add metrics like this. ICF box top/bottom and em top/bottom to allow type designers to specifying them for layout engines. 01:29:57 nmccully: Agree that having the metrics available is essential for layout engines. 01:30:06 Chris has joined #css 01:30:08 myles: If you don't have them, you synthesize? 01:30:15 koji: It's great to have the metrics, is ill defined. 01:30:15 nmccully: Yes, have synthesized in engines I've worked on. 01:30:35 Chris_ has joined #css 01:31:07 myles: It seems that none of the three proposals have anywhere near enough details to explain the difference between the grids. 01:31:27 smfr has joined #css 01:31:43 nmccully: Would greatly improve matters if line-heights and glyph placement were more controllable. 01:32:09 The OpenType algorithm to synthesize em box is here https://www.microsoft.com/typography/otspec/baselinetags.htm#ideoembox 01:32:24 nmccully: The existing baselines aren't sufficient, glyphs can shift today, being more explicit is important even if that requires adding more baselines. 01:32:52 nmccully: Defining how layout engines should use these baselines to position glyphs needs better definition. Smaller group should discuss this. 01:33:41 Topic: https://github.com/w3c/csswg-drafts/issues/1796 01:33:47 github: https://github.com/w3c/csswg-drafts/issues/1796 01:34:20 florian: This is a meta issues, many issues linked from it. Want to work on that css 2.1 doesn't define how line height is calculated. It tries to but contradicts with itself. 01:34:41 florian: I've written a bunch of tests to see what browsers actually do. Much more interop between browsers than expected. 01:34:59 florian: I'm not talking about which font metrics are used. Separate discussion, 01:35:36 florian: I'm also not talking about when we have multiple inline elements within a line. Several fonts with different glyphs within a line, how are they algned? That is what I'm talking about. 01:36:07 florian: There are two general cases where line height is normal or has a value, resolves to specific size. Then there is normal. 01:36:39 florian: In case where it is a size, you get exactly that size. Not clear from spec. Some spec text suggest it shoud be union of that per font, no browser does that. 01:37:13 florian: The baselines from the first font is used and everyhting else is aligned from there. Not what the spec says but it is what all UAs do. That is good. 01:37:21 astearns: Is it worth resolving to change spec to match that? 01:37:23 florian: Yes. 01:37:46 florian: Have proposed wording. If enough people have looked at my tests to verify them I'd be happy to resolve. 01:37:54 florian: We have to be very specific when patching css 2.1 01:38:16 florian: Happy to craft detailed diff if we agree on the high level issue 01:38:37 eae: Matches our behavior 01:38:58 myles: We should just make the change and revisit if it causes problems. 01:39:25 florian: The specific proposal is listed in issue 1801 at the bottom. 01:39:28 https://drafts.csswg.org/css2/visudet.html#leading 01:39:36 dbaron: I was still looking at the previous issue. 01:39:46 florian: One is about size, the other about alignment. 01:40:37 florian: "When the value of the line-height property is something other than normal, determine the leading L to add, where L = 'line-height' - AD of the first available font. Half the leading is added above A of first available font and the other half below D of first available font, giving the glyph and its leading a total height above the baseline of A' = A + L/2 and a total depth of D' = D + L/2. Glyphs from fonts other that the first available font do 01:40:37 not impact the height of the inline box." 01:41:02 dbaron: I think that seems resoanble. You might even want to say height or baseline of the inline box. 01:41:20 dbaron: There might be some cases where that is not what we do but think that is for normal line height. Seems reasonable to me. 01:41:25 astearns: Next step would be? 01:41:29 florian: Resolve if we agree. 01:41:39 astearns: and then we can review that pull request? 01:42:05 RESOLVED: Take florians proposed change to definitive line heights. 01:43:28 florian: CSS 2.1, in some cases, claims that line height normal behaves the same way as defined with a specific value. Probably between 1 and 1.5. Not what browsers do. What UAs do is take all fonts that are used, plus the first font, even if not used. That is what everybody does. Not what CSS 2.1 clains. 01:43:36 github issue: https://github.com/w3c/csswg-drafts/issues/1802 01:43:58 dbaron: I have a vague memory of gecko doing this in some cases. If there is a simpler impl I'd be happy to change. 01:44:44 florian: Only case I could find that skipped first font if unicode range is used for the first font. Chrome and Gecko have different behaviors. Other then that and the case where the first font' doesn't have the space glyph there is full interop. 01:44:55 astearns: Has anyone reviewed these tests? 01:45:02 florian: frenemy said he did. 01:45:04 zcorpan has joined #css 01:45:13 astearns: Is Edge fine with taking this change? And Chrome? 01:45:15 eae: Yes 01:45:21 myles: Let's do it! 01:45:40 dbaron: Go ahead, trying to figure it out will take awhile. 01:45:43 astearns: Any objections? 01:46:08 dbaron: I'm pretty sure the gecko behavior is too weird. Might be worth having test coverage. 01:46:47 florian: There is 2.5 browsers doing one thing, 1.5 the other. 01:47:11 RESOLVED: Take florians proposed change for line-height normal. 01:47:32 github issue: https://github.com/w3c/csswg-drafts/issues/1798 01:47:45 topic: github issue: none 01:48:21 dbaron: Want to go back to line height normal. In some cases we use different font metrics. 01:48:40 dbaron: The text in the proposal was very specific about the metric. 01:49:14 florian: Will update it to be more clear about the specifics and that the font metrics in question isn't defined. 01:49:30 dbaron: What metrics are used should be looked at separately. Will add comment. 01:49:33 github issue: https://github.com/w3c/csswg-drafts/issues/1798 01:49:41 smfr has joined #css 01:50:24 florian: We discussed whether the first font in the fallback list should count as the first available font even if it doens't have a space glyph. We did not specify whether it should also apply to line height. 01:50:38 florian: Safari, Edge, and FF half the time consideres it even if it doesn't have a space glyph. 01:50:39 boazsender has joined #css 01:50:47 florian: Safari and Chrome does not. 01:51:03 q+ 01:51:22 fantasai: The first available font should have a strict consistent definition across specs. 01:51:32 florian: Is not consistent across implementations. 01:51:52 q? 01:51:58 florian: Happy to change if implementations are willing to change. 01:52:24 florian: I don't really care strongly, arguments on both sides. 01:52:30 florian: Are edge and safari ok with that? 01:53:09 fremy: I didn't run all of the tests but I think we do the same thing? 01:53:15 florian: So there are three compat implementations? 01:54:06 florian: The first available font wording is used in 2.1 just not defined. 01:54:27 astearns: Might be acceptable to not test the presence of space in 2.1 01:54:57 florian: Define it in fonts3 and then have that definition apply to all cases where we mention first available font 01:55:44 Proposed Resolution: To define first available font more strictly in the fonts model and leave it undefined in 2.1 01:55:52 RESOLVED: To define first available font more strictly in the fonts model and leave it undefined in 2.1 01:56:19 estellevw has joined #css 01:56:41 github issue: none 01:57:13 florian: All browsers agree that the size of the content area depends on the size of the primary font, even if no characters from the primary font are used. 01:57:40 florian: The specification doesn't define the behavior, say "may do A or B". 01:57:57 zcorpan has joined #css 01:58:04 florian: Should remove "may do A" as no browser does that. 01:58:26 florian: Suggest we remove suggestion saying that one may do something that nobody does. 01:58:41 dbaron: Would argue it should be a SHOULD rather than MUST instead of a MAY. 01:58:54 liam has joined #css 01:59:01 myles: Content area also depends on the line-gap property 01:59:11 florian: Just depends on font metrics. 01:59:28 liam_ has joined #css 01:59:53 florian: Spec says "do whatever you want, here are two suggestions". Doesn't mandate a specific metric. 02:00:04 myles: Shouldn't say ascent or decent, have specific meaning. 02:00:20 dbaron: I don't think this ones includes line gap, only asc+dsc. 02:00:49 github issue: https://github.com/w3c/csswg-drafts/issues/1804 02:01:17 nmccully has joined #css 02:01:42 florian: There is a paragraph saying that if more fonts are used the height of the area isn't defined but we suggest... I propose we remove that. 02:01:47 Rossen: What about overflow? 02:02:09 florian: People don't do that for background I think. 02:02:16 Rossen: I'll follow up with a test case. 02:02:23 FYI, I did figure out the crazy Gecko behavior I was trying to remember: https://github.com/w3c/csswg-drafts/issues/1802#issuecomment-342349505 02:02:33 astearns: Let's continue making tests given the number of questions raised. 02:03:02 fantasai: This is about where the backgorund is painted for inline elements, very specifically about backgrounds. 02:03:23 Rossen: I might be miss-reading the issue. 02:03:28 dauwhe: don't worry, computers are fast 02:03:52 fantasai: The question is how tall is the background painted behind the text, can't set overflow on that element. Has to be set on containing block. 02:04:11 florian: I'm not an editor for any of these specs, there will be pull requests not in spec. 02:04:18 florian: Would like to move forward. 02:05:06 Proposed resolution: Change the wording such that 2.1 is saying you should define the content area based on the first available font and only that font. 02:05:16 RESOLVED: Change the wording such that 2.1 is saying you should define the content area based on the first available font and only that font. 02:05:29 02:05:59 florian has joined #css 02:10:54 bradk has joined #css 02:10:55 nmccully_ has joined #css 02:12:10 nmccully_ has joined #css 02:12:38 sam has joined #css 02:14:19 nmccully has joined #css 02:19:42 atai has joined #css 02:24:18 zcorpan has joined #css 02:26:18 zcorpan_ has joined #css 02:26:25 tantek has joined #css 02:26:36 florian has joined #css 02:28:17 florian has joined #css 02:29:57 atai has joined #css 02:30:18 zcorpan has joined #css 02:30:29 nmccully has joined #css 02:31:19 florian_ has joined #css 02:42:55 atai has joined #css 02:46:38 florian has joined #css 02:47:26 nmccully has joined #css 02:52:49 nmccully has joined #css 03:07:22 liam has joined #css 03:15:21 nmccully has joined #css 03:23:55 Hexcles has joined #css 03:31:20 tantek has joined #css 04:01:13 tantek has joined #css 04:01:25 rachelandrew has joined #css 04:44:42 smfr has joined #css 04:47:43 florian has joined #css 04:56:39 atai has joined #css 05:05:50 Hexcles has joined #css 05:06:56 nmccully has joined #css 05:39:57 Hexcles has joined #css 05:40:51 atai has left #css 05:52:41 nmccully has joined #css 05:53:56 nmccully has joined #css 06:06:43 Hexcles has joined #css 06:21:30 sam has joined #css 06:33:29 topic: end 07:06:31 florian has joined #css 07:22:46 tantek has joined #css 07:37:55 antonp has joined #css 07:43:28 nmccully has joined #css 07:49:02 rego has joined #css 07:53:36 Hexcles has joined #css 07:55:36 florian has joined #css 08:05:37 jcraig has joined #css 08:09:21 florian has joined #css 08:51:30 florian has joined #css 09:36:15 Ms2ger has joined #css 09:43:27 Ms2ger_ has joined #css 10:14:04 fantasai has joined #css 10:17:53 rego_ has joined #css 10:50:20 projector has joined #css 10:50:47 Rossen has joined #css 10:51:18 shans has joined #css 10:51:48 sylvaing has joined #css 10:52:19 leaverou has joined #css 10:52:49 plinss has joined #css 11:27:10 rachelandrew has joined #css 13:12:08 glazou has joined #css 13:16:44 sam has joined #css 14:37:15 glazou has joined #css 14:40:39 rachelandrew has joined #css 15:00:41 smfr has joined #css 15:43:21 tantek has joined #css 15:47:52 jensimmons has joined #css 15:51:43 jcraig has joined #css 15:53:07 Karen has joined #css 15:57:20 dydz has joined #css 16:02:30 duga has joined #css 16:02:32 Savago has joined #css 16:04:37 Karen_ has joined #css 16:06:35 Karen has joined #css 16:14:45 Karen_ has joined #css 16:15:47 Karen has joined #css 16:16:06 rachelandrew has joined #css 16:17:54 boazsender has joined #css 16:26:47 Karen_ has joined #css 16:29:04 Karen has joined #css 16:33:17 rachelandrew has joined #css 16:34:06 bradk has joined #css 16:34:41 florian has joined #css 16:37:00 florian has joined #css 16:37:24 AmeliaBR has joined #css 16:39:19 Chris_ has joined #css 16:46:28 duga has joined #css 16:48:52 tantek has joined #css 16:51:11 Karen_ has joined #css 16:53:13 Tomoya_Kimura has joined #css 16:55:52 bkardell_ has joined #css 16:57:43 natasha has joined #css 16:57:51 jamesn has joined #css 16:59:14 anssik has joined #css 17:00:11 ms__ has joined #css 17:00:13 Hexcles has joined #css 17:00:19 boazsender has joined #css 17:00:20 duga_ has joined #css 17:02:09 trackbot, start meeting 17:02:12 RRSAgent, make logs public 17:02:15 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 17:02:15 Date: 07 November 2017 17:02:42 yatil has left #css 17:04:41 kazho has joined #css 17:05:59 scribenick: gregwhitworth 17:07:41 ericwilligers has joined #css 17:07:50 Topic: Interop on List-item outside marker 17:08:02 github: https://github.com/w3c/csswg-drafts/issues/1934 17:08:32 *francois works on getting projector setup* 17:09:54 present+ 17:09:55 present+ 17:09:58 plh has joined #css 17:10:08 present+ 17:10:22 present+ 17:10:35 myles has joined #css 17:10:58 present+ 17:10:58 present+ 17:10:59 github: none 17:11:02 present+ 17:11:06 Topic: logical/physical property cascade and the .style API 17:11:12 cyril has joined #css 17:11:14 present+ myles 17:11:19 github: https://github.com/w3c/csswg-drafts/issues/1898 17:12:03 present+ 17:12:14 present+ 17:12:27 TabAtkins: someone pointed out that there are problems with the way logical properties are defined when trying to use the DOM APIs 17:12:57 TabAtkins: they get resolved in the normal order and then go through the cascade and we deal with the physical and logical based on ordering and writing mode 17:13:08 fremy has joined #css 17:13:14 TabAtkins: when you set a property it gets appended to the list of properties in the style attribute 17:13:19 present+ 17:13:27 TabAtkins: and if you set one that's already there it just replaces it 17:13:43 TabAtkins: so this can cause it to be out of sync with what would happen in the cascade 17:14:04 TabAtkins: the proposal is to amend the CSSOM that if something is there it is always appended 17:14:09 TabAtkins: related to this 17:14:23 TabAtkins: we had an issue with !important and we resolved to append to make this work 17:14:31 dbaron: I'm happy to make that change 17:14:46 dbaron: we had a long discussion and resolved the opposite way 17:14:51 dbaron: a setter should append 17:15:10 dbaron: at the time implementations were inconsistent due to optimizations 17:15:12 xiaochengh has joined #css 17:15:26 dbaron: for existing properties in the fast path they would replace and others they would append 17:15:39 dbaron: one question, would having to do that mess up optimizations? 17:15:51 TabAtkins: when we discussed it internally we were fine making the change 17:16:02 dbaron: I found the minutes from 2013 but I'm looking for the other one 17:16:06 dydz has joined #css 17:16:16 astearns: so I'm clear, the suggestion to append or remove and then append? 17:16:21 TabAtkins: those are equivelant 17:16:34 dbaron: I think it may turn out that it's not equivelant in the future 17:16:48 nigel_ has joined #css 17:16:53 TabAtkins: we should figure out which one we want, it will need to have a note to determine this 17:16:59 present+ 17:17:05 dholbert: you could inspect the style attr and determine that way 17:17:16 TabAtkins: the current model limits to only one 17:17:28 astearns: I'm hearing two engines happy to change 17:17:37 astearns: any compat concerns? 17:17:43 dbaron: possibly 17:18:06 astearns: the compat issue would be limited to logical props shorthands? 17:18:09 TabAtkins: no 17:18:26 fantasai: it would only affect people looking at .style expecting a particular order 17:18:37 fantasai: which doesn't make much sense, so it's probably not very common 17:18:43 florian: I doubt it's common 17:18:51 Rossen: tools and editors might be doing this 17:19:09 TabAtkins: I'd be surprised if the editor was reading the style and writing to .style 17:19:16 Rossen: they could 17:19:33 astearns: The proposed resolution is to change CSSOM to append values via the .style API and add a note 17:19:48 TabAtkins: yeah, and try to figure that out in the future 17:19:55 Things I found were https://lists.w3.org/Archives/Public/www-style/2013Sep/0469.html and https://lists.w3.org/Archives/Public/www-style/2013Oct/0007.html but I think there was further followup after the latter 17:19:55 astearns: any other opinions? objections? 17:20:00 RESOLVED 17:20:09 smfr has joined #css 17:20:23 RESOLVED: Make it so that setters to the .style api are appended rather than put in place 17:20:42 TOPIC: Interop on List-item outside marker 17:20:44 lajava has joined #css 17:20:48 github: https://github.com/w3c/csswg-drafts/issues/1934 17:21:04 fremy projects 17:21:26 fremy: more precisely the positioning of the marker 17:21:45 fremy: you can center things, but it's 2017 and we still don't know where to put the bullets 17:21:52 Naomi_ has joined #css 17:22:00 fremy: got a bug to put the bullet in the right place 17:22:07 fremy: shows bug in Edge 17:22:26 fantasai: wait it is spec conformant? 17:22:29 dbaron: yes it is 17:22:36 fremy: shows Chrome 17:22:40 fremy: let's fix it 17:22:51 fremy: so I started to look at the spec and it's missing 17:23:01 fremy: spec isn't ready to implement 17:23:51 peter has joined #css 17:23:58 fremy: put the 2.1 spec text and technically Edge is matching but the spec is very vague 17:24:12 dbaron: I think I may have been responsible for that note 17:24:27 fremy: I get the impression that nothing is defined 17:24:54 dbaron: in Chrome it is inside the principal box so it violates the 2.1 text 17:25:01 fremy: we want to fix this issue, but we want to spec it 17:25:10 fantasai: yes 17:25:16 atai has joined #css 17:25:25 tantek: all of those sentences come from long discussions and not agreeing 17:25:34 fremy: so I'll describe how Edge is implementing this 17:26:18 *fremy shows slides and he will post them a bit later* 17:27:07 since we're talking about weird bullet positioning, I'll quietly drop this Chrome & Edge issue here, in case it's relevant… http://dabblet.com/gist/3731c920fa0ee56efe3ec24a33a88964 17:27:41 fremy: there are two different steps, find out which line box do you need to affect with the bullet 17:27:50 fremy: then horizontally position the bullet 17:28:06 sam has joined #css 17:28:38 fantasai: how we end up describing this, we'll need to really think about the markers - what they need to do and what they're trying to achieve typographically 17:28:38 tomalec has joined #css 17:28:48 fantasai: we shouldn't need to switch the model 17:29:09 zcorpan has joined #css 17:29:11 q+ 17:29:25 ack fremy 17:29:29 q? 17:30:01 TabAtkins: attaching it to the first LI, and the first item may be overflow: hidden and the marker can disappear 17:30:19 dbaron: that doesn't happen in Gecko because we position it to the align but it's not actually contained in that 17:30:58 ack iank_ 17:31:06 dbaron: back when Gecko did what was in fremy feedback and when we fixed it we don't get bugs 17:31:22 iank_: we're looking at re-implementing markers, our current list marker behavior is not nice 17:31:27 Karen has joined #css 17:31:32 iank_: we're doing something very similar to what you described 17:31:39
  • ...
    <= list marker is clipped in Chrome! 17:31:55 iank_: I'll need to check with Koji, we're doing something very similar to what you described, so if you could specify it that sounds great 17:32:00 fremy: that's what we want 17:32:14 eae: now is the right time for us to spec this 17:32:43 Karen_ has joined #css 17:32:54 fremy: to reply to Tab, to have overflow: hidden we can't put it inside of a non-bfc and this is would not happen 17:33:03 astearns: so what is the action? 17:33:20 fremy: I wanted to know if there was interest, it seems like there is 17:34:05 fremy: Sure I'll be a co-editor but I care more about interop 17:34:20 yjang_ has joined #css 17:34:20 RESOLVED: Add Francois to the Lists spec 17:34:39 some links to previous discussion:https://bugzilla.mozilla.org/show_bug.cgi?id=172073 https://lists.w3.org/Archives/Public/www-style/2008Feb/0116.html https://lists.w3.org/Archives/Public/www-style/2008Feb/0118.html 17:34:53 (and there's more that I haven't found yet) 17:35:17 Topic: Interaction of scroll-snap and JS scrolling APIs 17:35:49 github: https://github.com/w3c/csswg-drafts/issues/1707 17:35:59 trchen has joined #css 17:36:06 TabAtkins: A bit late but bullet is not clipped in Chrome in your example, it just inserts a line, see here: http://dabblet.com/gist/07b894c9f6c1bbc3237c422172d0e5b9 17:36:27 TabAtkins: the scroll snap spec defines that if you do a fragment nav and it defines margin or something, you should pay attention to those 17:36:44 TabAtkins: it doesn't have any guidance on similar scrollIntoView APIs rather than just target scrolling 17:36:54 Karen has joined #css 17:36:58 TabAtkins: we have the API opt into that 17:37:13 TabAtkins: the API has other properties of its own 17:37:21 leaverou, add the
      17:37:23 florian: when you say some properties what are those 17:37:45 fantasai: the things we were consider the scroll snap margin that's the indication that there should be additional space 17:37:53 Rossen: oops, added. Same result. 17:38:00 fantasai: if it has a snap position that's an indication that you should snap that position 17:38:18 leaverou, there is a bullet, right? 17:38:30 jeff has joined #css 17:38:31 Rossen: yes. Tab said there wouldn't be. 17:38:36 present+ jeff 17:38:48 fantasai: the third thing, the UA could opt into using the snap position even if snapping is not turned on because the UA is trying to determine this and they may utilize this info from the author for the best end user behavior 17:39:00 leaverou: good, we have interop then :) 17:39:12 astearns: it's a bit vague, but you're going for a must to consider the padding and positioning 17:39:38 smfr: if it an element is in scrolled to it but look at it's container's scroll margin? 17:39:59 fantasai: usually you're looking at the border box for SIV and it will then take scroll margin into account 17:40:29 florian: the other aspect about snap position, if snapping is not turned on but it has position you may use that to position 17:40:43 smfr: would you only look at the targeted item or the ancestor chain? 17:40:50 fantasai: just the one that's being targeted 17:40:59 glazou has joined #css 17:41:35 smfr: it seems weird that your taking a property that's meant solely for scroll snapping and you're adding it to the SIV 17:41:54 wuyaohua_ has joined #css 17:41:57 fantasai: this is adding author intent to the SIV 17:42:00 pkerr has joined #css 17:42:04 smfr: you could add props to SIV 17:42:12 fantasai: this makes it so that you don't have to track it all though 17:42:15 glazou_ has joined #css 17:42:15 q? 17:42:22 smfr: is the UA allowed to override scroll snap margins? 17:42:31 florian: is it implied that we should take scroll padding? 17:42:34 fantasai: yes 17:42:52 florian: I recall doing it in general, but wasn't aware we did it for this API 17:43:12 fantasai: that was intentional, you shouldn't be able to get in a state in JS that you can't get to as a user 17:43:34 astearns: the two of you smfr and Rossen showed some concern 17:44:15 myles: we have to make sure that websites that turn off scroll snapping, with this change the margin will now have effect 17:44:23 fantasai: usually this will get you a better experience 17:44:34 myles: I'll be for implementing this and seeing if this has a web compat issue 17:44:47 fantasai: I don't think we should have a web compat issue 17:44:58 Karen has joined #css 17:44:59 myles: I think we can resolve on this 17:45:08 astearns: I'm hearing some movement to resolving 17:45:13 astearns: anyone object? 17:45:55 glazou__ has joined #css 17:46:05 RESOLVED: When using SIV you should take scroll snap margin into account 17:46:31 BogdanBrinza has joined #css 17:47:44 scroll-into-view must use element's snap position if it has one and snapping is on 17:47:53 RESOLVED: SIV must use the element position if it has one and snapping is on 17:48:22 RESOLVED: Implementation may use the snap position if snapping is off 17:48:42 Vlad has joined #css 17:50:10 florian: should this change intersection observer? 17:50:21 TabAtkins: I don't think we should bring this in? 17:50:47 Topic: Scroll Into View options 17:50:55 github: https://github.com/w3c/csswg-drafts/issues/1708 17:51:05 fantasai: there are several different options that target an element, such as scroll into view 17:51:11 fantasai: then there is the focus api 17:51:31 fantasai: this takes a bunch of args for smooth scrolling or not, how that element should be aligned within the viewport 17:51:53 fantasai: the default behavior you should be following the scroll snap if the scroll snap says something 17:52:15 fantasai: the second question is, are those options even necessary if there are scroll snap options 17:52:35 TabAtkins: we discussed this internally, there may be areas where you want to do one off alignment 17:52:45 fantasai: do you have a usecase 17:53:01 eae: one is up and down arrows, you may want to align to the top or the bottom 17:53:30 iank_: if you have a news feed you may want to use one or the either based on direction 17:53:40 dbaron: we had a discussion about these options a few weeks ago 17:54:24 dbaron: in that discussion I pasted the link to our internal code and if we want use cases where we use it 17:54:41 smfr: is scrollIntoView default the same as SIV false 17:54:45 The Gecko internal API is documented here: https://searchfox.org/mozilla-central/source/layout/base/nsIPresShell.h#669-763 17:54:55 er, better permalink: https://searchfox.org/mozilla-central/rev/7e090b227f7a0ec44d4ded604823d48823158c51/layout/base/nsIPresShell.h#669-763 17:55:01 smfr: we may scroll it into the top or the bottom, just as long as it's in the view 17:55:19 TabAtkins: this became a weird api for legacy issues 17:55:39 eae: our default is either true or false based on distance 17:56:15 florian: your usecase of the newsfeed I think we should solve that in CSS scroll snapping 17:56:35 myles: but that criteria of direction could be a bunch of different criteria, I don't think we should do that 17:56:45 dbaron: most of the complicated ones come from the a11y code 17:57:03 iank_: it looks like scrollIntoView args might be different than scrollIntoView with bool 17:57:06 s/most/some/ 17:57:13 iank_: if it's bool we set the block to start 17:57:20 TabAtkins: that isn't per spec 17:57:22 iank_: ok 17:57:32 eae: ours is completely broken 17:57:50 TabAtkins: I may open an issue on this 17:57:58 astearns: I'm hearing at least 4 threads of convo 17:58:11 astearns: do we need to have any more discussion about scrolling the least amount? 17:58:20 TabAtkins: that's a separate thing to consider for scroll snap 17:58:35 astearns: 1. The argument at the end should be dropped - sounds like they should not be 17:58:56 2. Should scroll snap win when there are no args in SIV - that sounds like there are no arguments against that 17:59:07 fantasai: the two specs conflict 17:59:31 fantasai: the OM spec doesn't ack scroll snap 17:59:32 there seem to be different behaviors for: various a11y things, going to named anchors, focus changes, caret position changes, dom apis to scroll element into view, and some other things (e.g., things related to form autofill popups or devtools) 17:59:39 astearns: does anyone have any objection to making those changes 18:00:03 RESOLVED: We will make the changes to specs as necessary to ack scroll snap when no arguments are provided to ScrollIntoView 18:00:16 fantasai: anything that does scrolling needs to be evaluated 18:00:59 astearns: any objections with not mucking with the ScrollIntoView() args? 18:01:26 RESOLVED: To keep scrollIntoView() options as they are 18:02:36 glazou_ has joined #css 18:02:56 TOPIC: Spatial Navigation 18:02:59 https://github.com/lgeweb/spatial-navigation/blob/master/explainer.md 18:03:25 szager has joined #css 18:04:15 SM has joined #css 18:06:22 jihye: Spatial navigation is the ability to focus elements based on their position on the screen 18:06:42 jihye: the focus key can be changed with tab or shift tab key 18:06:59 going through https://github.com/lgeweb/spatial-navigation 18:07:14 jihye: two way remote control and with four way keys and a11y it is becoming more and more important for input mechanism 18:07:29 jihye: it is interesting for a11y for explaining the layout of the page 18:07:46 jihye: to support this, we need to consider the following three steps 18:08:04 jihye: *reads from explainer* 18:08:48 jihye: the heuristic will be built for navigation, tab and arrow keys in Opera/Vivaldi allow for spatial navigation 18:09:15 jihye: Blink it moves the scroll bar but you can enable it via a flag 18:09:34 jihye: *shows a testcase* 18:09:53 jcraig has joined #css 18:09:54 jihye: It isn't perfect but we need to improve the mechanisms in blink 18:10:14 jihye: shows that when you press arrow keys it goes to the focusable elements 18:11:07 jihye: shows the heuristic on scrollable regions that allow it scroll until a focusable element is in view that element is then given focus 18:11:49 jihye: In CSS UI there are left, right, up, down properties 18:11:52 I wrote code to do this (user-friendly spatial navigation) automatically in Tasman for WebTV/MSTV back in the day but cannot remember exactly how I solved all these problems. 18:11:53 robdodson has joined #css 18:12:03 https://drafts.csswg.org/css-ui-4/#nav-dir 18:12:11 jihye: it is quite inconvenient because it needs to be defined on each element 18:12:18 jihye: I want to solve this problem 18:12:43 jihye: *shows page with proposed API page from explainer* 18:12:49 nav-rule: auto | projection | direction | nearest 18:12:51 Karen has joined #css 18:13:07 jihye: there is a rule that can customize spacial navigation 18:13:15 duga has joined #css 18:13:59 (describes nav-loop) 18:14:17 jihye: when the page is too long and a lot of scroll, when the focus reaches the bottom of the page, the focus can go to the next thing and when you want to go up you need to press the up key so many times, but loop can go directly back up by going to first focusable element in the tree 18:14:32 jihye: does the WG have any feedback? 18:14:52 fantasai: the first question I have is, some of these things seem like as a user preference rather than an author preference 18:15:00 florian: which ones 18:15:04 fantasai: like the loop 18:15:30 florian: there is a tv program, being able to move the left to the right is dependent on layout 18:15:48 florian: the person that knows how this is laid out is the author 18:16:00 florian: and that's why it should be on the author, but that's the general state of CSS 18:16:29 myles: so I think in general, I think it's a good area of investigation 18:16:32 myles: woooo 18:16:46 myles: there are many devices out there that use spatial navigation 18:17:16 myles: the heuristic for arrow keys there isn't a lot of interop, that would be valuable, but I also think there is a place for the web author to override the default 18:17:32 myles: I think mostly this would be used for tweaks 18:18:16 Chris_ has joined #css 18:18:24 florian: I think there are three: 1. Leave it up by the UA 2.) Picking the bit that you want to override 18:18:56 florian: I do think we'll need some specifically selectable method, and I don't think today we can define this - we need to take some type of extensible web approach here 18:19:09 q+ 18:19:14 florian: send an event when the user tries spatial navigation 18:19:30 florian: then a little bit down the road we can enable it based on usage 18:19:44 florian: having worked a little bit, there all sorts of corner cases 18:19:51 florian: transforms, opacity, etcs 18:20:16 florian: I don't think we should dictate the heuristics right now will be very hard, not the whole problem 18:20:43 fantasai: what would be the difference between javascript and events 18:21:09 fantasai: you're saying we should have an event handler and then do that live, we already have that the JS could set the nav properties 18:21:24 fantasai: a page that has too many JS 18:21:57 ack tantek 18:22:14 tantek: I have some experience working on this, there are a couple things worth looking at 18:22:25 tantek: the first of - what are the real world layouts that authors have used 18:22:35 tantek: where automatic algos haven't done a great job 18:23:06 tantek: if any of you were at jensimmons talk laid out in a circle they expect the focus to go in the circle 18:23:41 glazou has joined #css 18:23:49 https://lists.w3.org/Archives/Public/www-style/2013May/0076.html 18:24:02 tantek: we've tried to solve this before, it's very hard and this is beyond CSS and brain storming here isn't going to be a good use of time 18:24:25 tantek: if you want to pursue this, make it a platform effort 18:24:44 tantek: I'd hate to see you spend a lot of time on that and hit a lot of the same issues we've hit before 18:25:17 fantasai: the key thing to point out from the email is being able to group elements rather than just one thing after another 18:25:31 astearns: any other points you'd like to make jihye? 18:25:41 jihye: I'm looking for general interest? 18:25:52 I think spatial navigation would be better pursued in a new WICG draft 18:25:54 astearns: I think this should start in the WICG and get wider interactions 18:26:09 florian: the thing is, what do we mean by "THIS" 18:26:20 florian: this an entire area of features 18:26:49 iank_: that's what WICG is for, find the problem and then start identifying and beginning to solve the problem 18:27:11 astearns: taking this to WICG, doesn't preclude us from making changes to things that are already in CSSUI 18:27:26 tantek: we'll definitely help out here in what makes sense being in CSSWG 18:27:42 q+ 18:27:52 florian: as long WICG doesn't preclude us, I'm ok 18:28:01 jihye: I'm on discource 18:28:28 ack jcraig 18:28:52 astearns: we should take it from Discourse and make an official WICG repo 18:29:29 +1 to jcraig's comment 18:29:34 +1 to jcraig's comments 18:29:36 jcraig has joined #css 18:29:53 jcraig: we should solve this in WICG but with everyone, CSS is part of it but we should include solutions to tabindex, etc 18:30:05 s/I think mostly this would be used for tweaks/I think there is definitely a case for author tweaks to the heuristics/ 18:30:24 Topic: https://github.com/w3c/csswg-drafts/issues/1910 18:30:25 jcraig: this will fail on its own in the weeds 18:30:42 github: https://github.com/w3c/csswg-drafts/issues/1910 18:31:20 florian: one of the weird things that we have with arrow keys, it lets you define where you should focus to 18:31:42 florian: what happens if the element where you want to go to isn't focusable 18:31:57 florian: what is currently defined is that if the user wants to go there we should make it focusable 18:32:17 florian: these days many/most are built are out of components 18:32:43 florian: this may allow the browser to go the "right" and then seek for the first focusable element 18:33:08 florian: if you're the author you can point to what's there, if your using a component and you don't know what's there maybe a heuristic is better 18:33:49 tantek: as an author you may want to use a seamless iframe but you don't know what's on the other side. I don't think we can determine the best behavior 18:34:03 tantek: since you mentioned components, I think we shouldn't be solving this in isolation 18:34:26 florian: I'm not disagreeing with what you state, I'm not sure how that answers my question 18:34:48 Karen has joined #css 18:34:49 tantek: I'm saying this discussion doesn't belong in CSSWG 18:35:06 smfr: so are you saying these props don't belong in CSSUI 18:35:29 smfr: to me, it sounds like spacial navigation would be in its own spec rather than here in its own naïve form 18:36:07 florian: do you think there is a potential case where the focusable behavior is what you would want? 18:36:11 tantek: very unlikely 18:36:30 florian: I think searching inside of that makes sense and is uncontroversial 18:36:59 tantek: you're asking about something n the weeds and I'm not sure it helps/hurts and I think we should move this to a different arena 18:37:29 astearns: is anyone lining up to implement this improvement, then I think there would be a case to make a change to the spec 18:37:38 astearns: if this is just an academic change, what's the point? 18:38:04 atai has joined #css 18:38:04 (sorry for speaking out of turn) but the notion of creating focus "groups" seems to already exist today with Shadow DOM. jsbin.com/lidaguf/edit?html,output 18:38:05 florian: the fact that, it works poorly when you have blackbox component which was mentioned by Blink 18:38:25 tantek: I don't think it's experimental 18:38:41 astearns: *reads rob's comment* 18:39:12 robdodson: the notion of focus groups kind of exists already, that will allow once focus is within that shadow root boundary 18:39:34 robdodson: the notion of the grouping kind of exists if you're willing to use shadow dom 18:40:02 AFAIK, Shadow DOM also propagates, kind of scoped focus, to elements distributed via `` 18:40:05 issue filed: https://github.com/w3c/csswg-drafts/issues/1948 18:40:07 florian: what I was thinking of trying to specify if you focus that non-focusable element - if there is tabindex, etc use that 18:40:14 I mean GH issue filed https://github.com/w3c/csswg-drafts/issues/1948 18:40:32 " [css-ui-4] Spatial Navigation needs a new home in WICG #1948 " 18:40:52 florian: since we don't seem to have consensus can I suggest a lighter one to make a change to what we agree is stupid" 18:41:12 ???: What do we all agree is stupid? 18:41:24 ???: Currently you only seem to say that you should look for tabindex 18:41:28 florian: or is a button, etc 18:41:31 s/???/bradk/ 18:42:18 florian: it seems very weird to me that something is focusable will take you to something that isn't focusable but with a tab key you can't 18:42:21 florian: that's weird 18:42:31 astearns: since we're not closing, let's table the issue for now 18:42:53 topic: end 18:43:12 rachelandrew has joined #css 18:46:37 Hexcles has joined #css 18:48:31 boazsender has joined #css 18:48:55 zcorpan has joined #css 18:49:29 rachelandrew has joined #css 18:55:35 jnurthen has joined #css 18:57:02 bradk has joined #css 18:58:13 IanPouncey has joined #css 18:59:59 IanPouncey1 has joined #css 19:01:31 duga_ has joined #css 19:03:04 tomalec has joined #css 19:03:06 MichaelC has joined #css 19:03:57 Karen has joined #css 19:05:33 Karen has joined #css 19:06:37 tink has joined #css 19:07:30 IanPouncey has joined #css 19:07:31 Karen has joined #css 19:07:31 bradk has joined #css 19:07:56 clapierre has joined #CSS 19:08:07 dydz has joined #css 19:08:10 tantek has joined #css 19:08:29 I have made the request to generate https://www.w3.org/2017/11/06-css-minutes.html MichaelC 19:08:35 Topic: Accessbility joint meeting 19:08:40 present+ 19:08:52 duga has joined #css 19:09:03 smfr has joined #css 19:09:06 q? 19:09:13 janina: We've been lsiting some issues with CSS for severl years, and tried several ways to get traction. 19:09:13 yatil has joined #css 19:09:16 present+ George_Kerscher 19:09:22 janina: Had some wonderful conversation; some issues are on our end. 19:09:26 I have made the request to generate https://www.w3.org/2017/11/06-css-minutes.html MichaelC 19:09:31 janina: Formed a TF a year ago, had some trouble staffing it on our end 19:09:46 janina: Think we've got it staffed now. 19:10:01 Chris_ has joined #css 19:10:04 janina: Ian Pouncey (sp?). Ted Drake is still involved. 19:10:22 present+ 19:10:34 Naomi_ has joined #css 19:10:37 janina: Want to talk process, introduce the TF between CSS and ARIA and APA. 19:10:47 kazho has joined #css 19:11:01 LJWatson has joined #css 19:11:11 janina: Illustrating some persistent issues that keep showing up - we've picked one to kick around a little bit. 19:11:50 ian: [introduces himself] 19:12:03 ian: work for Paciello Group, been writing css for a long time 19:12:58 tmichel has joined #css 19:13:03 myles Apple 19:13:04 present+ 19:13:04 [intros] 19:13:13 Xidorn Quan, Mozilla 19:13:17 present+ Janina 19:13:20 present+ 19:13:22 aaronchu has joined #css 19:13:29 present+ Léonie 19:13:34 Brad Kemper, Invited Expert 19:13:34 present+ myles 19:13:38 thierry MICHEL, W3C 19:13:47 Peter Linss, Invited Expert 19:13:52 present+ 19:13:56 aaron chu, apple 19:13:57 Brian Kardell, JS Foundation 19:14:08 Chris Lilley, W3C 19:14:15 ericwilligers has joined #css 19:14:17 Rossen Atanassov, Microsoft 19:14:22 Janina Sajka, APA WG chair 19:14:27 Emil A Eklund, Google Inc 19:14:36 TAb Atkins, Google 19:14:38 Tantek Çelik, Mozilla 19:14:39 Rob Flack, Google 19:14:39 Surma, Google 19:14:44 present+ 19:14:45 present+ 19:14:47 Greg Whitworth, Microsoft 19:14:48 Bogdan Brinza, Microsoft 19:14:49 Alice Boxhall google 19:14:54 Eric Willigers, Google 19:15:01 Tomoya Kimura, VOYAGER Japan 19:15:01 Melanie Richards, Microsoft 19:15:27 Michael Cooper, W3C 19:15:29 Simon Fraser, Apple Inc. 19:15:30 Jason White, ETS 19:15:34 Naomi Kennedy, Penguin Random House 19:15:34 Alan Stearns, Adobe, CSS Co-chair 19:15:52 Rachel Andrew, Invited Expert 19:16:01 Tomek Wytrebowicz, (Webplat) Invited Expert 19:16:09 Charles LaPierre, Benetech (Personalization ARIA TF co-facilitator) 19:16:22 cyril has joined #css 19:16:32 Ian Kilpatrick, Google 19:16:46 fremy has joined #css 19:17:14 Francois REMY, Microsoft 19:17:24 ian: Have a bit of an agenda 19:17:30 ian: First item is a history lesson on the TF 19:17:39 ian: Discussed at last year's TPAC and activated in Jan 2017 19:17:45 ian: Took a bit to get going. 19:17:59 ian: Back in August my employer gave me explicit time. 19:18:07 ian: Have reviewed 4-5 modules and commented on one - MQ4 19:18:22 ian: Lots of work, have limitied participants. Here today to ask for your help. 19:18:34 lisa has joined #css 19:18:38 public-css-a11y@w3.org 19:18:38 ian: Anyone interested in participation in the a11y TF, please contact us - I'll put some email addresses in the IRC channel. 19:18:50 w3c@ipouncey.co.uk 19:18:52 Lea Verou, Invited Expert 19:18:54 -> https://www.w3.org/WAI/APA/task-forces/css-a11y/ CSS A11Y TF 19:19:14 IanPouncey: First, what's the best way to interact with the CSSWG. 19:19:20 IanPouncey: We've raised one issue so far. 19:19:23 https://github.com/w3c/csswg-drafts/issues/1925 19:19:43 IanPouncey: So far all I've done is tagging it appropriately. 19:19:51 -> https://github.com/w3c/css-a11y/ CSS TF GitHub repo 19:20:18 jensimmons has joined #css 19:20:19 florian: I've seen this review - one reason to not dive in yet is that this is one review, but lots of issues. 19:20:29 florian: Would be much more digestible if each issue was a separate GH issue. 19:20:37 github: 19:20:37 https://github.com/w3c/csswg-drafts/issues/1925 19:20:41 florian: Some are linked so it's not always obvious, but one giant issue makes it hard to look at 19:21:00 nmccully has joined #css 19:21:11 fantasai: We do have tags we can use - you can tag them all together and easily tell what to pay attention to. 19:21:26 fantasai: We ahve a tag specifically for *requesting* a11y feedback, but we can add another tag for feedback specifically from y'all. 19:21:40 [someone says "a11y" label] 19:21:44 fantasai: Sure. 19:21:56 IanPouncey: Dunno if we want to differentiate between review from individuals and from the TF? 19:22:21 Rossen: Not really different. One of the motivations behind the TF is that there's a group dealing with CSS a11y focus offline, so it doesn't take a ton of time otherwise. 19:22:35 mck has joined #css 19:22:49 Rossen: Once those issues are identified and we've convinced ourselves we need to solve them, we can move them to the csswg modules and start tracking the work there. 19:23:03 Rossen: But echoing fantasai, issues are issues, no reason to deal with your specially. 19:23:10 Rossen: Let's just use the "a11y" label, then. 19:23:19 Rossen: Less process in the way, the better. 19:23:25 q? 19:23:41 IanPouncey: There's a label for specs that need review? 19:23:42 ally label created 19:24:01 https://github.com/w3c/css-a11y/projects/4 19:24:13 jcraig has joined #css 19:24:39 “Needs a11y feedback” label https://github.com/w3c/csswg-drafts/labels/Needs%20a11y%20feedback 19:24:41 ??: we set this project up 6 months ago, but have been adding as we went along 19:25:04 hyojin: ack ; will reply asap 19:25:04 Master list of CSS GH labels: https://github.com/w3c/csswg-drafts/labels 19:25:04 IanPouncey: Currently there are 13 specs in this project, question is how do we add to it and communicate what needs review, and how to prioritize 19:25:45 IanPouncey: So one example spec review as an example. 19:26:00 IanPouncey: Topic is navigation, in combination with the layout specs. 19:26:09 https://github.com/w3c/css-a11y/projects/1 19:26:14 IanPouncey: We have a project in the a11ytf specifically for layout, but not much there at the moment 19:26:29 IanPouncey: Round Display, Position, and Fragmentation 19:26:43 IanPouncey: Need to put Grid in there. 19:27:02 IanPouncey: Grid currently has a single piece of advice- 19:27:08 https://www.w3.org/TR/css-grid-1/#placement-a11y 19:27:18 lajava has joined #css 19:27:38 IanPouncey: Advice is basically just "don't mess it up", and to pay attention to content order. 19:27:50 IanPouncey: Question we have - is this sufficient? We know it's not a new problem. 19:27:56 See also https://www.w3.org/TR/css-grid-1/#order-accessibility 19:27:58 IanPouncey: We still see a lot of issues from devs tho 19:28:39 florian: I had a discussion yesterday - "source order nav is king" has been longstanding advice, and we've pushed back against shortcuts taken by well-intended people who don't want to bother about that, and we've thou 19:28:48 florian: But maybe there are places you do need the different behavior. 19:29:09 florian: Different cases for different a11y needs - probably non-sighted users can live in a world where DOM order is king - tabbing thru DOM order seems to make sense 19:29:25 florian: But for sighted keyobard users this is less true - a stronger disconnect between what they see and where the tab key takes them. 19:29:43 florian: Thinking about addressing this thru re-ordered sequential nav 19:30:11 florian: "take me to teh next thing" might take to an unexpected place, but "take me to the next thing to the left/up/etc" might b emore useful. was just discussing that. 19:30:36 florian: Does this high-level description make sense? Do we need re-ordered sequential nav once we have spatial nav? What other things do we need? 19:30:42 q? 19:30:58 IanPouncey: This is the sort of thing we want to talk about! 19:31:14 jihye: I just gave a presentation on the spatial nav proposal. 19:31:34 IanPouncey: A question is, is this something that needs to be considered? Should DOM be the only source of truth? Can this be fixed with better docs? 19:31:46 IanPouncey: We know this isn't working, devs aren't getting the message. 19:31:49 q+ 19:32:32 https://1drv.ms/v/s!AvBfF-T7CmB2het1xoPdYm0kee63Tghttps://1drv.ms/v/s!AvBfF-T7CmB2het1xoPdYm0kee63Tg 19:32:54 Rossen: Our last half-hour before this is that we recognize the problems, some might need to be fixed on the css layer, and it's a much bigger-scope problem than just the CSSWG. 19:33:07 Rossen: Our pref was to move this to a wicg group and have a broader exposure and request for feedback and input. 19:33:16 Rossen: Particularly for people on html and dom side 19:33:23 MaRakow has joined #CSS 19:33:29 Rossen: And if anything falls out that is specific to css, we'll bring that back as appropriate 19:33:56 Rossen: This is def something to be solved, just want to make sure it's the right set of people, not necessarily just CSS. 19:34:19 florian: To expand, it's obvious that spatial nav is related to layout, but not *only* - it's also interacting with JS, with web components, etc. 19:34:29 florian: Things this group doesn't master. We should b einvolved, but not just us. 19:34:36 q? 19:34:43 florian: But still question of if there's something left to solve in sequential nav once we've solved spatial nav. 19:35:19 tink: Wanted to emphasize that this isnt' a new problem, florian suggested this already. 19:35:33 q+ 19:35:39 tink: Become more of a priority now because CSS modules are fixing long-term problems with layout, amking re-ordering so much easier, so it's becoming a larger problem now. 19:36:00 q? 19:36:04 ack tink 19:36:05 nigel has joined #css 19:36:10 ack rachelandrew 19:36:13 rachelandrew: In the past I've said I'm happy to contribute examples or feedback form community 19:36:27 rachelandrew: When I teach Grid, people say "oh, mamkes it so easy to have a different layout for desktop vs mobile" 19:36:36 q+ 19:36:39 rachelandrew: I teach not to have different orderings, and people say "oh, but surely that's what this is for?" 19:36:47 rachelandrew: So ther'es a real use-case fo rthe re-ordering. 19:36:56 rachelandrew: So happy to contribute my experience teaching devs here. 19:37:01 q+ 19:37:02 q? 19:37:12 q+ 19:37:14 ack jensimmons 19:37:19 jensimmons: I want to assure people that we've had extensive convos about this. 19:37:29 jensimmons: I've been talking to RAchel and a11y experts outside the WG for months, etc. 19:37:48 clapierre has left #css 19:37:48 jensimmons: Briefly, I'm hesitant to get away from DOM order. Leaves authors who want to do the right thing without an idea of what to do. 19:37:57 jensimmons: Always need more education, always. 19:38:10 jensimmons: I know that still leaves a gap, a lot of authors just don't understand what they're doing. 19:38:29 Savago has joined #css 19:38:32 jensimmons: Was talking to Derek Featherstone, does a11y retro-fitting for sites, and he felt like the only thing that would work is a user pref. 19:38:42 clapierre has joined #css 19:38:46 jensimmons: DOM order staying the best preference, but a switch to visual order for people who'd prefer that. 19:38:56 jensimmons: So yeah, need to have the right people in the room for this. 19:39:07 q? 19:39:15 IanPouncey: Yeah, bringing this to the WG because we know it's something of interest. 19:39:27 Chris_: Ane xample where document order is not what you want. 19:39:31 ack Chris_ 19:39:36 Chris_: An SVG which is a map, a thousand villages, rivers, etc. 19:39:52 Chris_: Probably don't want it to start at top and work down. Want to start from a point and move spatially. 19:40:16 +1 to Chris 19:40:21 astearns: There were two topics on sequential nav on our agenda, thought they might be good in this meeting 19:40:24 q? 19:40:34 ack astearns 19:40:51 Controlling sequential navigation issues: https://github.com/w3c/csswg-drafts/issues/1748 + https://github.com/w3c/csswg-drafts/issues/1764 19:40:59 IanPouncey: If there's gonna be a wicg group, make sure the tf is involved - we can help facilitate. 19:41:22 florian: For topics in wicg, typically people involve themselves; i'm happy to invite the right people 19:41:28 florian: Who are they? A mail to the tf is the way to go? 19:41:28 q+ to ask what meant by incubator grup 19:41:41 MichaelC, WICG 19:41:42 IanPouncey: Perhaps the right people are the ones from the CSSWG that will volunteer... 19:41:46 q? 19:41:49 florian: Where should I send a mail to? 19:41:57 IanPouncey: Put it earlier in the chat, there's a public email for the tf 19:41:59 MichaelC: https://wicg.io/ 19:42:10 public-css-a11y@w3.org 19:42:34 janina: Ian coordinates with APA all the time on this, so we have ways to find people with the right expertise. 19:42:40 q+ to note that WICG is meeting all day Thursday 19:42:44 ack MichaelC 19:42:45 MichaelC, you wanted to ask what meant by incubator grup 19:43:07 q+ 19:43:20 MichaelC: Part of the purpose of the APA was to incubate solutions - are there beneifts to working with the wicg that aren't obtained by our tf? Want to know we're working in the right incubator. 19:43:28 q- 19:43:33 ack t 19:43:33 tantek, you wanted to note that WICG is meeting all day Thursday 19:43:34 tantek: The experience we've had is that trying to solve this jsut in css won't work, as pointed out for previous reasons. 19:44:06 tantek: In wicg, the point is to consider styling, markup, and/or script-realted aspects of navigation. They all inter-relate, plus tabindex, etc. Solving only in CSS, likely to repeat years of frustration. 19:44:18 tantek: So earlier, just from the WG's perspective, made sense to take this to WICG. 19:44:40 tantek: And point out - WICG is holding meetings all Thursday. If we have a quick repo, we can reconvene during one of those timeslots on thursday' 19:44:49 q? 19:45:11 Sand Pebble E 19:45:12 see also https://discourse.wicg.io/t/proposal-spatial-navigation-for-the-web/2402 19:45:22 Sandpebble E 19:45:23 sorryyyyy 19:45:39 q? 19:45:48 pkerr has joined #css 19:45:52 florian: We've had a few proposals to try and solve the reordered-sequential nav. 19:45:55 florian: Quick overview 19:46:17 florian: As a complement to the spatial nav up/down/left/right, there's a proposal for nav-next/prev, directing where the Tab should take you 19:46:30 IanPouncey: Android has a similar thing. 19:46:53 florian: There's been suggestion that you don't need both, you could infer -back from -next 19:47:03 tantek and tab: NO you can't, you can have multiple things pointing to the same. 19:47:10 florian: Another is to move tab-index to CSS. 19:47:24 no, nav-index was removed due to being an incomplete solution and having accessibility issues 19:47:28 florian: And/or combined with something letting you scope it to subtrees of the DOM, letting you re-order parts without interfering with the rest. 19:47:55 florian: Hard to talk about what to do for these and how to tweak them, without knowing what needs to be solved, and what's left to solve after spatial navigation happens. 19:48:11 florian: Not saying there will be nothing left after spatial nav, just not sure what it will be. 19:48:15 IanPouncey: Lacking testcases? 19:48:32 florian: Use-cases. SAying here's a page, fix spatial nav, clearly something is still broken. 19:48:37 I think it should be noted that ideally visual order, AT traversal order and focus traversal order should be in sync at all times 19:48:52 Fixing one of those in isolation risks getting them out of sync 19:48:53 Adding scoping issue from list mail a few years back: https://github.com/w3c/csswg-drafts/issues/1949 19:49:02 florian: So finding cases where DOM order is right, visual order is inconsistent, and it's a problem... list of these sorts of cases are what's needed. 19:49:03 nmccully has joined #css 19:49:10 florian: I don't have a good udnerstanding of that; I don't think anyone does yet. 19:49:18 q? 19:49:20 janina: Same problem in APA, we need to frame this up better. 19:49:24 q+ 19:49:37 Visual positioning is important to blind users. 19:49:44 ack aboxhall 19:49:52 tantek, I don’t know that there is a definitive list of *all* the problems with tabindex 19:49:55 aboxhall: Ideally visual order, AT order, and focus order need to be as close as possible. Anything touching one of those risks them getting out of sync/ 19:49:58 florian: Why is that a problem? 19:50:07 aboxhall: Not all AT users are non-sighted, so it's confusing to get those out of sync. 19:50:16 q+ 19:50:19 aboxhall: If tab and visual order are out of sync, tab order flies around the page. 19:50:20 jcraig, I vaguely remember you pointing me to a "problems with tabindex and proposals for fixing it" document years ago and I can't find it 19:50:53 florian: We haven't had spatial nav on mainstream browsers so far. If we did, I suspect sighted keyboard users, when they want to go right, will want to go right, rather than going "next" and hoping it's to the right. 19:51:09 left/right does not translate to next/prev universally across cultures! 19:51:12 florian: I'm also not convinced that "visual order" is actually a thing - points are in 2d, they're not ordered, contrast and motion and such also matter... 19:51:27 q+ to mention that most visually impaired people (even screen reader users) are not entirely blind. and that spatial navigation is relevant to blind users. 19:51:33 aboxhall: I think there's a difference between "DOM is linear" and "visual order doesn't matter". You can have regions that have a very logical visual order, like a tablist. 19:51:55 nmccully has joined #css 19:51:56 florian: Right, locally there is, but in those cases you listed, DOM order should already match. 19:52:13 q+ 19:52:13 florian: Not saying they don't exist, but as long as we merely *assert* they exist, we won't have an idea what they actually are. 19:52:29 florian: Often in same order, but in the cases they're not, to me, it seems that spatial nav is better for sighted users. 19:52:44 florian: Overlapping problems and solutions, and once we consider future ones we've committed to, what's still uncovered? 19:52:45 q+ 19:53:04 aboxhall: I think those have answers, but this meeting isn't the place for them. 19:53:17 florian: I think I have answers, but it's based on personal pref right now. 19:53:28 florian: I just don't think we can have a productive dicussion before listing use-cases 19:53:32 aboxhall: I think we agree. 19:53:36 a? 19:53:39 q? 19:53:56 janina: We're dancing on the edge of some concerns - personalization will come up, different users will want different things. Making that possible is another convo we want to have. 19:54:19 +1 to janina 19:54:25 q+ 19:54:46 mck: AS a blind user who I think can rep blind users well - I want to say as forcefull as I can, VISUAL ORDER MATTERS TO BLIND USERS. 19:54:54 mck: Happy to talk extensively for more detailed reasoning. 19:55:03 mck: One important reason is the existence of touch screens. 19:55:08 ack me 19:55:08 jcraig, you wanted to mention that most visually impaired people (even screen reader users) are not entirely blind. and that spatial navigation is relevant to blind users. 19:55:15 q? 19:55:15 ack mck 19:55:19 ack mck 19:55:31 jcraig: Visual layout affects the spatial orientation, and completely blind users are very aware of spatial orientation. 19:55:45 q+ George_Kerscher 19:55:55 jcraig: And most visually impared people aren't completely blind - a new study cam eout recently said 230mil people in the world are imparied, onlya bout 50mil would be called completely blind. 19:56:04 jcraig: Most screen-reader users probably aren't ocmpletely blind, too. 19:56:15 jcraig: We get bugs all the time were the screen-reader doesn't align with the visual order. 19:56:36 +1 to jcraig about sliding scale 19:56:39 jcraig: I've heard assupmtions in the past that people are either sighted and not using AT, or totally blind, and that's not true. It's a big multi-pole spectrum. 19:56:46 ack jensimmons 19:56:53 jensimmons: Alice, you mentioned keeping visual and DOM order together. 19:57:02 jensimmons: Taht's absolutely what we're teaching right now. 19:57:02 q+ Janina 19:57:21 +1 jensimmons 19:57:25 I'm actually less concerned about DOM order - focus traversal order and AT traversal order are my concerns 19:57:37 if they diverge from DOM order but stay in sync that's probably? ok? 19:58:00 jensimmons: Florian, I think you were onto something. Saying "what is visual order" "what is spatial order"; layout design will change drastically over the enxt few years, if my last few years of life meant anything, and "what is the visual order" doesn't have a clear answer. Very subjective, involves hierarchy. 19:58:33 jensimmons: So that's probably part of the disconnect - lose notion of a clear order. When you hit 2d or 3d, a more visual amorphous order. Maybe more about thinking of a set of navigation tools that work in a more visual space. 19:58:46 +1000 to jensimmons 19:59:03 jensimmons: Just, don't think webpages will continue to look like they do - header/nav/main/etc. I'm encouraging people to play with this, but telling people to build an accessible dom first. 19:59:13 Stats and resource site for blindness and vision impairments around the world… (disclaimer: site itself unfortunately has a number of accessibility problems) http://atlas.iapb.org 19:59:18 fantasai: How many people have seen Jen's presentations on Grid? 19:59:24 q? 19:59:51 fantasai: If you ahven't, I recommend you find a video. I can't emphasize enough how the difference is going to be, and visual order will not be left->right, top->bottom. Will be different from just scanning pixels. 20:00:01 leaverou: A common use-case i Haven't heard yet 20:00:42 leaverou: When you're writing a library augmenting elements on a page you don't own, when you need to append and position relative to something else, often easier to append to body and just visually position them, rather than appending near the element and deal with stacking context, overflow, etc. 20:00:53 leaverou: This applies to tooltips, editting... 20:01:10 ack leaverou 20:01:12 ack leaverou 20:01:14 ack lisa 20:01:19 s/tooltips/libraries that do tooltips/ 20:01:20 http://jensimmons.com/post/feb-27-2017/learn-css-grid and http://labs.jensimmons.com/ 20:01:42 [i'm missing Lisa's call] 20:01:49 lisa: One of the things that might help is predictable positioning 20:01:55 this video is a good one: http://jensimmons.com/presentation/revolutionize-your-page-real-art-direction-web 20:02:05 plh has joined #css 20:02:06 lisa: If people expect it to be a distance from the corner of the screen, they know where to find things, where the search can stop 20:02:24 lisa: A MQ I don't know exist, dunno if interested in use-cases for this, but I think i tmight fit in somehow... 20:02:36 [still missing details] 20:02:43 q? 20:02:45 [waht i wrote above doesn't make sense] 20:03:10 IanPouncey: There was a discussion last year about the possibility of MQ helping personalization. 20:03:22 IanPouncey: Dunno how that would work with layout, but it should be mentioned. 20:03:42 IanPouncey: A preference for spatial nav vs DOM order communicated, maybe thru MQ. 20:03:59 george: IPDF has merged with the W3C, so publishing is now under w3c, including epub 20:04:04 ack George_Kerscher 20:04:20 george: DOM order and publishing's "correct reading order" are closely linked 20:04:34 george: Need to be able to maintain that not even in a single webpage, but across a collection of items. 20:05:01 george: In visual vs DOM order, there are things we need to preserve. If a skull-crossbones is next to a note, need to make sure the warning is read before the note, so people don't hurt themselves. 20:05:08 george: So this is important discussion in the epub wg. 20:05:24 I'm hoping there is follow-up Thursday in a WICG session on this 20:05:29 janina: Thank you for the time. 20:05:37 q? 20:05:38 wondering if we should build use case for personlization for people with cognitive disabilities, either via media queries, or for predictable positioning here. 20:05:38 janina: We should be careful not to limit where we think the problems are. 20:05:42 ack janina 20:05:55 janina: Range of people affected is far larger than just fully blind, or even just visual disabilities. 20:06:07 janina: People with cognitive or learning disabilities are big part, aging population is big part. 20:06:35 janina: Analogy - if you move to new city, everything you're used to is there, but in a new location. Reorientating is hard, peole can get dropped. 20:06:58 janina: So I think we need to look for the commonalities and ways to let people make things work for them. 20:06:59 tantek: me too, I think we can make sure that happens 20:07:11 janina: Like "what does next and prev mean" and make it work hierarchically 20:07:21 janina: Surprised us a bit by agreeing with us before we got very far. 20:07:30 janina: Looking forward to looking at this as we move forward. 20:07:40 so who is coming to WICG on Thursday for this? 20:07:51 I will come 20:07:59 Rossen: Those who are interested, plz join the css-a11y list. 20:08:07 same. jcraig, aboxhall, florian, jensimmons ? 20:08:08 I would love to if it's not around 11am 20:08:24
      20:09:37 jeff has joined #css 20:12:52 florian has joined #css 20:12:53 clapierre has joined #css 20:15:19 lisa has left #css 20:15:50 atai has joined #css 20:33:43 How does one join the css-a11y list? 20:35:22 projector has joined #css 20:35:22 If I send it a normal subscribe message, I get an autoreply telling me to use http://www.w3.org/Member/Mail/ instead 20:35:50 Rossen has joined #css 20:36:20 shans has joined #css 20:36:51 sylvaing has joined #css 20:37:21 leaverou has joined #css 20:37:51 plinss has joined #css 20:39:09 bradk has joined #css 20:40:48 SteveZ has joined #css 20:41:04 https://www.w3.org/2000/09/dbwg/details?group=94039 says only staff and chairs can edit the group 20:41:46 Drawing #4 on the flipchart is https://lists.w3.org/Archives/Public/www-archive/2017Nov/att-0007/IMG_20171107_123911.jpg 20:41:52 er, that was meant for #fx 20:44:57 tantek has joined #css 20:45:45 bradk_ has joined #css 20:50:55 SteveZ2 has joined #css 20:55:36 clapierre has joined #css 20:59:04 innovati has joined #css 21:05:53 SteveZ has joined #css 21:12:59 SteveZ2 has joined #css 21:13:16 florian has joined #css 21:16:59 lajava has joined #css 21:18:05 MichaelC has joined #css 21:21:36 tomalec has joined #css 21:21:42 MichaelC has left #css 21:23:47 Hexcles has joined #css 21:24:20 clapierre has joined #css 21:24:28 xiaochengh has joined #css 21:25:58 florian has joined #css 21:27:57 dydz has joined #css 21:28:41 florian_ has joined #css 21:28:58 tantek has joined #css 21:31:40 SteveZ has joined #css 21:32:27 so it looks like the group that went out to lunch and would "absolutely" be back by 1:30 may be a bit late (shocking!) 21:33:17 the CSS WG restarting late? 21:33:19 :O 21:33:56 pkerr has joined #css 21:34:13 clapierre has joined #css 21:35:35 present+ 21:35:38 tink has joined #css 21:35:57 Tomoya_Kimura has joined #css 21:35:59 aaronchu has joined #css 21:36:02 aaronchu has left #css 21:36:04 present+ 21:36:15 jamesn has joined #css 21:36:17 cyril has joined #css 21:36:18 we need to start - come back all 21:36:21 myles has joined #css 21:36:21 zcorpan has joined #css 21:36:24 IanPouncey has joined #css 21:38:01 jcraig has joined #css 21:38:58 rachelandrew has joined #css 21:39:06 duga has joined #css 21:39:30 Naomi has joined #css 21:40:36 ScribeNick: fantasai 21:40:37 jensimmons has joined #css 21:40:39 present+ 21:40:42 Topic: scrollbar colors 21:40:49 github: https://bugzilla.mozilla.org/show_bug.cgi?id=77790 21:40:52 Chris_ has joined #css 21:41:04 10min late is pretty much on time :D 21:41:10 comparatively speaking 21:41:23 IanPouncey has joined #css 21:41:29 background: https://bugzilla.mozilla.org/show_bug.cgi?id=77790 21:41:50 tantek: bg fo the discussion is this is a 17-yr-old set of properties introduced by winIE5.5 21:42:05 tantek: we've resisted standardizing, but FF has discovered some compat probs 21:42:22 tantek: trying to capture 80/20 of use cases, which is scrollbar properties 21:42:31 tantek: linking to bugzilla issue of first rquest 21:42:35 tantek: links to more issues and sites 21:42:42 tantek: many sites wanting/using this 21:42:45 github: https://github.com/w3c/csswg-drafts/issues/1955 21:43:00 https://github.com/tantek/css-scrollbar-style 21:43:01 tantek: There are sites saying “don't use Firefox because they don't support colored scrollbars” 21:43:05 fantasai: ?????????! 21:43:22 tantek: These are the properties that shipped unprefixed IE5.5-IE8 21:43:24 florian has joined #css 21:43:25 jcraig has joined #css 21:43:26 tantek: IE9 has -ms- prefi 21:43:34 tantek: all authoring guidelines suggest using without prefix 21:43:47 tantek: we can spec as published, which is essentially what I've tried to do 21:43:58 https://stackoverflow.com/questions/25480565/how-can-i-create-custom-scrollbar-for-mozilla-firefox-with-css 21:44:02 nmccully has joined #css 21:44:04 tantek: asking wg if can adopt as ED 21:44:56 present+ 21:44:56 https://tantek.github.io/css-scrollbar-style/Overview.html 21:45:05 smfr has joined #css 21:45:41 clapierre has left #css 21:45:58 thanks leaverou 21:46:15 fremy has joined #css 21:46:17 Rossen: so asking for feedback on adopting this in CSSWG? 21:46:18 tantek: yes 21:46:25 q+ 21:46:30 q+ 21:46:47 Chris_: Any indication that ff will adopt and webkit will drop -webkit- and do this instead? 21:46:52 nigel has joined #css 21:46:59 tantek: Yes, at Mozilla we intend to intend this, and having a spec is precondition, which is why I'm spending time on it 21:47:06 florian has joined #css 21:47:21 TabAtkins: We would like to drop as much of our weird -webkit- stuff as possible 21:47:25 q? 21:47:26 I am strongly, strongly, strongly in favour of having a CSS spec for this. 21:47:36 xiaochengh has joined #css 21:47:42 Karen has joined #css 21:47:42 TabAtkins: Beyoond color which is important, other use case we found important to address is scrollbar sizing 21:47:59 TabAtkins: Most Google properties using custom scrollbars are doing it to get skinnier scrollbars 21:48:10 q+ 21:48:12 TabAtkins: So I think we need to add that, but other than those two, don't think we need anything else 21:48:28 tantek: For our analysis 80/20 was color, sizing far behind, but good feedback that Google thinks sizing is critical 21:48:35 ack smfr 21:48:40 ack TabAtkins 21:48:43 smfr: We're interested only in very limited customization of scrollbars. Would like to get rid of -webkit- scrollbar pseudo stuff 21:48:49 smfr: we're only interested in coloring, and hiding scrollbars 21:49:04 smfr: Currently ppl use hack of setting display: none on scrollbar thumb in order to hide the scrollbar 21:49:16 smfr: Really really don't want scrollbar-color-3d-face-something-something 21:49:17 +100 to smfr 21:49:19 q+ 21:49:38 smfr: I won't implement it 21:49:49 smfr: Historically, I think mistake to put OS-specific color things into CSS specifications 21:50:01 smfr: This has assumptions that there are these things you can apply these coors to 21:50:06 these are the properties in the spec that have been adopted by sites: scrollbar-3dlight-color, scrollbar-arrow-color, scrollbar-base-color, scrollbar-darkshadow-color, scrollbar-face-color, scrollbar-highlight-color, scrollbar-track-color, scrollbar-shadow-color 21:50:07 smfr: e.g. on mac we don't have scrollbar arrows 21:50:18 tantek: Some of these proeprties afect others, details below 21:50:24 tantek: so authors can omit specific pieces 21:50:29 tantek: maybe don't need to specify those specific pieces 21:50:39 tantek: so open to dropping some properties if superfluous 21:50:41 "Implementations may ignore any scrollbar part color properties for scrollbar parts that do not exist on the underlying platform." 21:50:53 tantek: wnated to start with exact set that have been on the Web since 2000 and use compat as the argument to start draft 21:50:57 tantek: if we can make simplier, all for that 21:51:05 tantek: I am pro reducing the set if that helps the concern 21:51:08 q? 21:51:12 +1 to smfr 21:51:30 smfr: Want to avoid properties that flip the scrollbar from looking platform-native to something different 21:51:50 smfr: so I support allowing customization of the appearance of scrollbar in terms of applying colors, but not looking completely different 21:51:58 bradk_: In Gmail it looks completely different. Square, visible all the time 21:52:10 q? 21:52:14 ack leaverou 21:52:18 leaverou: Agree with smfr, strongly support styling scrollbars but OS-specific low-level control doesn't belong in CSS 21:52:33 leaverou: Even if it does, can add it later as longhands for a shorthand 21:52:37 IanPouncey has joined #css 21:52:44 leaverou: Just to give a color that dominates, would go very far 21:53:12 leaverou: These are very repetitive. Although Tantek said some set by others, seems like you have to repeat the same color and do many calculations to cal lighter/darker variations 21:53:16 leaverou: authors shouldn't have to do this 21:53:30 leaverou: all we need to start is a scrollbar-color and scrollbar-width 21:53:40 tantek: Existing eamples, typically two colors 21:53:52 tantek: Then they copy/paste those into pieces they want to style in that asion 21:53:57 tantek: some might be superfuous 21:54:07 tantek: but general pattern is a light color and a dark color that matches their theme 21:54:11 MS has joined #css 21:54:11 tantek: hard to do just one color 21:54:21 tantek: the other comment I'll make is to smfr wrt rendeirng flattened look 21:54:29 tantek: Some sites doing this, that's exactly their goal 21:54:44 tantek: want a scrollbar that doesn't stand out at all compared to the rest of their visual design 21:54:49 tantek: ... 21:55:08 tantek: At this point Web devs are clamoring for that level of control, and having gotten used to that level of control in native apps their expectations have changed from the past 21:55:14 q? 21:55:31 ack xidorn 21:55:40 xidorn: question to Tab, is there any use case that wanting to widen the scrollbar 21:55:50 xidorn: or just make it thinner? 21:56:06 xidorn: So we want maximum width of scrollbar rather than just the width 21:56:12 btw a classic example where authors need scrollbar styling: http://dabblet.com/gist/b639cbdd5c7b3e48e9d1e0a5af188869 21:56:32 melanierichards: Not always, sometimes want to have a chunky scrollbar 21:56:38 melanierichards: to make it more prominent 21:57:13 Rossen: For ease of touch, there are apps who will restyle and add larger UI in general to make the hit areas larger; scrollbars are one of them 21:57:20 Rossen: Other cases hide sscrollbars for panning 21:57:29 Rossen: So might want to change iwdth in either direction 21:57:52 xidorn: I raise this because concerned about specifying exact widht of scrollbar, that may be narrower than native scrollbar on windows but not on Mac 21:58:04 xidorn: which may make the visual effect odd on some platforms 21:58:17 q? 21:58:28 Rossen: Hearing a bunch of interest 21:58:31 Rossen: Some things here 21:58:35 Rossen: Still need to resolve on adopting this 21:58:37 Rossen: as a WD 21:58:40 Rossen: or ED 21:58:51 Rossen: guessing one reason to keep it out of css-ui-4 is to make this a very quick spec to REC? 21:58:58 tantek: yes 22:00:08 fantasai: Yes, if the concern is getting it to REC faster, then can just have it part of UI, and then when you want to transition to CR, drop the other parts of UI to L5 22:00:29 tantek: Different because don't want to invent a bunch of new stuff, want to just get compat with minimal work, very different than what UI 4 is scoped for 22:00:35 tantek: so semantically deserves its own draft 22:00:55 tink has joined #css 22:01:56 fantasai: Might be helpful to your work, but not helpful to people using the specs if related features aren't together 22:02:08 Rossen: Let's see how it goes first 22:02:21 Rossen: Objections to adopting as ED? 22:02:43 tink has left #css 22:03:02 RESOLVED: Adopt css-scrollbars as ED 22:03:36 mck has joined #css 22:03:42 ScribeNick: eae 22:04:11 github: https://github.com/w3c/csswg-drafts/issues/1170 22:04:26 myles has joined #css 22:04:39 github: none 22:04:57 Functional pseudo-class like :matches() with 0 specificity 22:05:01 topic: Functional pseudo-class like :matches() with 0 specificity 22:05:02 leaverou: As we all know specificity tries to infer importance from selectors. Resulting specificity might not always be logical. 22:05:08 github: https://github.com/w3c/csswg-drafts/issues/1170 22:05:34 github, delete all comments 22:06:18 leaverou: My favorite example of specificity not being a good heuristic is using the not pseudo class. 22:06:27 div:not(#foo):not(#bar):not(#baz) 22:06:29 leaverou: ^^^ 22:06:44 tmichel has joined #css 22:06:57 leaverou: In this example we want to target all dives except three, yet gets very high specificity. 22:07:16 leaverou: Especially for libraries, when trying to be specific, it is hard to override. 22:07:30 jcraig has joined #css 22:07:35 leaverou: uses something called BAM(?) encodes selector in class name and uses js to apply it. 22:07:42 BEM 22:07:43 s/BAM/BEM/ 22:07:45 .how__many__people__have__hear__of__bem 22:07:46 leaverou: Willing to not use selectors at all, to bypass specificity. 22:08:18 http://getbem.com/introduction/ 22:08:23 leaverou: One way to fix this would be to define selectors with a known specificity of one, would allow last selector win and make it easier to override. 22:08:34 q+ 22:08:40 leaverou: I.e. put all nots in a single pseduo class. Easy solution vs other ones like per origin. 22:09:04 leaverou: Lets one be very specific with regardess to specificty, can be selected per selector and solves most of the known problems. 22:09:14 leaverou: Something that could be done as a pre-processor. 22:09:24 leaverou: Many names have been proposed, we can bikeshed that. 22:10:09 fantasai: Seems like a reasonable idea to me. The fact that authors can chose which parts of the selector applies to specificity sounds good to me. 22:10:20 ?+ 22:10:50 fantasai: Lower priority for an entire style sheet, library author might want to allow the entire stylesheet to be allowed to be overriden by author rules. 22:11:32 q? 22:11:36 leaverou: Example: in ?? there is a toolbar that has a class of mv-bar, also class of mv-ui that means applpy default style. Want author to be able to overrule using just mv-bar but I don't want their "div" rules to override. 22:11:42 q+ 22:11:44 s/??/mavo/ 22:11:51 ack fantasai 22:11:58 ack bkardell_ 22:12:06 ericwilligers has joined #css 22:12:11 bkardell_: I don't think they are mutually exclusive. May be that you can do an awful lot for a whole bunch of things and we know we can do that easily. 22:12:24 bkardell_: For a number of polyfills that I have worked on this would have been really useful. 22:12:56 bkardell_: There are things like headings that need to take aria roles into account that make them have very high specificity which makes it hard to override. 22:13:14 q+ 22:13:20 ack bradk_ 22:13:30 bradk_: Seems to me like we could solve this without taking specificity all the way down to zero. 22:13:38 bradk_: Specificty only matters when there is a tie. 22:14:13 bradk_: If there is a tie when it comes to ID or class, if the ID selector inside the funciton was more specific then outside the function that would solve the same problem while still allowoing specificity. 22:14:21 q? 22:15:17 Dael, here's the diagrams for Nat's presentation on line grids; please insert them in the correct section of the minutes. :) https://lists.w3.org/Archives/Public/www-archive/2017Nov/att-0008/CSSWG_2017.11.6_nmccully.pdf 22:15:43 leaverou: As dicussed in issue, if we have fractions of specificity that introduces new levels of specificity and no one is suggestion that the entire thing doesn't have specicifity. All the classes and IDs outside of it still applies. It allows the specificity to be controlled. To have it count as a class you would just add it to the end, a bit hacky. 22:15:54 bradk_: No use case for specifying it for the entire selector? 22:16:13 leaverou: Yes but usaully not. You would only want to [put some criteria in the pseduo class. Like all the not for example. 22:17:03 leaverou: Makes it less predictable. Now we know that we can count the number of IDs, number of classes, tags etc. If it is always zero it is very obiovus, if not it makes it much more complciated to compute it. 22:17:12 q? 22:17:17 ack TabAtkins 22:17:38 TabAtkins: I agree in general with what leaverou is saying. Authors can often do just fine when specificity is in order. Opting out or in-order seems ot match what users want. 22:18:02 TabAtkins: AS for chrome, we're happy with this, and would like to implement the stornger version of matches. This is easier, we might do this firts. 22:18:07 TabAtkins: We're supportive. 22:18:11 q? 22:18:41 florian: Let's put this in level 4 for now, we don't have a five. 22:18:45 fantasai: 22:18:52 Rossen: Let's add it to four. 22:19:04 fantasai: Very simple feature, as long as we're happy with the name. 22:19:34 ericwillgers: What about web platform tests? 22:19:39 fantasai: Not in CR yet, not needed. 22:19:41 22:19:47 q+ 22:20:12 dbaron: One comment: I think it is worth nothing that it is not clear how easy it would be to implement matches. This has most of the same risk. 22:20:23 ack dbaron 22:20:47 dbaron: One of the things with selectors, they're heavily optimized. Implementing without optimizaions not very useful. With optimizations is quite a bit of work and not clear how quickly that can happen. 22:21:07 fantasai: Start with implemented subset. 22:21:17 TabAtkins: WebKit goes beyond spec, also has support for pseduo elements. 22:21:41 dbaron: Caution in that it's being tied to a feature which has an uncertain future. 22:21:55 fantasai: De-risk by having certain things in level 4 vs 5. 22:22:04 dbaron: Other alternatives that solves leaverou use cases. 22:22:19 leaverou: I don't want to reduce *all* of it to zero but only a part. 22:22:24 ?+ 22:22:43 q? 22:22:43 dbaron: I don't have a syntax proposal at this time but would avoid tie to branching combinators. 22:23:02 TabAtkins: Earliest version didn't support that, does not. 22:23:05 does now. 22:23:08 ?- 22:23:32 fantasai: Making up a completely new unrelated syntax seems silly and doesn't make sense. Cut down on the syntax instead. 22:23:44 q? 22:23:54 tmichel has joined #css 22:24:00 dbaron: What doesn't make sense to me is spec moving so far ahead of what implementors are willing to do. Implementor by-in was not a factor. 22:24:35 fantasai: Disagree, you're arguing against it based on implementation priority. 22:24:39 s/by-in/buy-in 22:24:44 dbaron: you're acting like we can only do everything or nothing. 22:24:46 eae, that's not what I said 22:24:47 fantasai: Not what I said. 22:24:48 at all 22:25:18 dbaron: I'm fine with the proposal but I do not think it's the only one. 22:25:34 leaverou: If implementors aren't willing to do that at the moement shouldn't we discuss that? 22:25:54 dbaron: I think I bought this up when we went to CR 22:25:56 fantasai: Selectors are not in CR yet. 22:26:06 dbaron: But people are goimg ahead to implement it. 22:26:09 s/aren't willing to do that/aren't willing to implement a part of :matches()/ 22:26:16 dbaron: This is the problem with sticking things in editors draft. 22:26:33 There shouldn't be anything in Selectors that didn't have a WG resolution to add. 22:26:35 Rossen: Would you prefer to see this go in in another way? If not can we try to settle on a resoluiton and go on. 22:26:38 If there is, the editors made a mistake. 22:26:50 If there was a resolution and you didn't like it you should have objected. 22:27:03 dbaron: Fine with matches without combinators under a different name. 22:27:07 Being angry about it now is neither helpful nor fair. 22:27:27 q+ 22:27:29 leaverou: I'm fine with that (adding combinators later) 22:27:53 lajava has joined #css 22:27:56 TabAtkins: The no combinators version is the one that desugars effecitvely. Start with simple version. 22:28:03 leaverou: Still supports commas, right? 22:28:03 q? 22:28:06 TabAtkins: Yes 22:28:34 bkardell_: Is there a suggestion to take combinators out of matches level 4 as well? 22:28:36 TabAtkins: Yes 22:28:58 Rossen: Are you OK with that? 22:29:05 leaverou: Yes, can we have a resolution? 22:29:16 fwiw, we did discuss moving selectors4 to cr at least in https://lists.w3.org/Archives/Public/www-style/2015Jul/0349.html 22:29:17 Proposed resolution: Add to selectors level 4 with a TBD name 22:29:29 RESOLVED: Add to selectors level 4 with a TBD name. 22:29:43 fantasai: Do we have a list of candidate names? 22:29:52 leaverou: is, when, and filter 22:30:19 Rossen: Any particular favorite we can resolve on right now? 22:30:29 ericwilingers: I like filter 22:30:38 Rossen: filter has the most plusses on github? 22:30:44 leaverou: No, I think it was either is or when. 22:30:46 yoichio has joined #css 22:30:51 filter is also the name of a property 22:30:52 Rossen: You all work it out. 22:31:01 Rossen: let's move on. 22:31:08 Topic: Target within 22:31:13 github: https://github.com/w3c/csswg-drafts/issues/457 22:31:20 Karen has joined #css 22:31:40 i think "filter()" vs. "filter:" would lead to confusion 22:32:08 leaverou: This is probably best explained with an example. Image a photo gallery, clicking a phot enlarges it, often done with pseduo and having an anchor with a hash url. Every time you click an image it becomes the target. 22:32:25 leaverou: You also want to apply a style to the entire gallery without a selection, also done with target. 22:32:33 leaverou: No way to target the state where there is no hash. 22:32:58 leaverou: Suggested this on github but got no comments. Think it is useful and not terrible difficult to implement. 22:33:12 TabAtkins: I see the use case and see similar uses, I'm supportive of the use case. 22:33:41 ???: What if you have a photo gallery that also has some sections that aren't images that are stil targetable by a hash? 22:34:04 leaverou: Another use case for target-within as it allows both for the selected image and not to be supported. 22:34:19 s/???/dholbert/ 22:34:25 +1 22:34:27 Rossen: Any objections to target within? 22:34:38 RESOLVED: Add target within to selectors 4. 22:34:40 s/as it allows both for the selected image and not to be supported./as it allows you to use it on the image, which will apply both when the image is target or when it contains a target/ 22:34:41 florian has joined #css 22:34:53 Topic: Color 22:34:58 github: https://github.com/w3c/csswg-drafts/issues/300 22:35:17 Chris_: This issue is about making computations on color boundaries. 22:35:29 Chris_: If used in a gradient, transitions, animations, etc. 22:36:09 Chris_: Right now, by default, given that we've never had anything outside of srgb, is that it happens in srgb which is unfortunate. You'll end up with the wrong color due to the gamma curve. 22:36:25 Chris_: We've had several resolutions where we don't have the right color space. 22:36:43 Chris_: In April we discussed this and someone suggested a linear 16 bit color space. 22:37:11 Chris_: That would allow colors outisde of the srgb gamma to be expressed. Another option would be to have it be unbounded. 22:37:26 s/outisde of the srgb gamma/outisde of the srgb gamut/ 22:37:29 Chris_: I'd like to push this forward to have spec text about this. 22:37:57 Chris_: There will be people here at 3:30 that are exerts in this and will have an in-depth dicussion about it. 22:38:32 Chris_: One of the reasons I started this community group is to get expert input - should help the spec move forward. 22:39:11 I don't have a better proposal yet. Does anyone have any thoughts on this? 22:39:35 q+ 22:39:49 pkerr: You need to do you calculations in a linear space. Whether it is sRGB or float-16 that gives you the same flexibility but with better math 22:40:04 pkerr: Gives an infine space between 0 and 1 22:40:24 Chris_: The movie industry likes having absolute values defined. 22:40:29 pkerr: Linear pixels is the way to go. 22:40:33 ack bkardell_ 22:40:38 ack dbaron 22:40:39 q+ 22:40:41 sumie_ has joined #css 22:40:53 dbaron: One comment: I'm fine with putting stuff in spec that isn't quite sure yet but please stick a note on it to explain that/ 22:41:40 ack next 22:41:44 smfr: You can't change the color space to be linear without breaking stuff. A lot of pages have assumptions that would break. Authors needs to opt in. 22:42:22 q? 22:42:39 pkerr: When I said use linear I meant use it for the math and then convert back, not necessarily switching everything to linear. 22:43:07 RESOLVED: Chris to do more work :) 22:43:35 Topic: css-transforms-2 authors 22:43:59 smfr: I would like to propose adding trchen as an author for css-transforms-2 22:43:59 Chris__ has joined #css 22:44:03 Rossen: Any objections? 22:44:12 Naomi has joined #css 22:44:25 Topic: Constructible style sheets 22:44:37 not github: https://tabatkins.github.io/specs/construct-stylesheets/ 22:44:51 q+ 22:45:08 ericwillinger: Common use case is with shadow dom. Ppl will construct a stylesheet inside a shadow root. Cretes a thousands of stylehseets 22:45:13 Minutes where we resolved to allow combinators in :matches, *at dbaron's request* https://lists.w3.org/Archives/Public/www-style/2014Jan/0607.html 22:45:31 ericwillinger: Could have browser logici that shares them. A better way might be to have a js api to explicitly share it. 22:46:08 Karen has joined #css 22:46:19 TabAtkins: We'd like style sheet parsing to be async. Will decide later factory functions. 22:46:33 q? 22:46:36 s/decide later/decide later between an async constructor or / 22:46:46 Hexcles has joined #css 22:46:49 astearns: dglzman had some comments he wanted me to forward: He's really happy and want to use it right away. 22:47:16 florian has joined #css 22:47:22 pkerr has joined #css 22:47:23 astearns: if you have a doc with a style node, he'd like to be able to add a style to the documing through that. 22:47:47 TabAtkins: Want to be able to replace a stylesheet with a constructed one? 22:47:58 cyril has joined #css 22:48:12 astearns: Yes, and further also for link elements. The link element question could remain open but he'd really like it for the style element. 22:48:15 q? 22:48:20 florian has joined #css 22:48:22 ack astearns 22:48:27 eae: you have sRGB where I said scRGB (I know, it sounds almost the same but is a linear space) 22:49:07 fantasai: yeah, I was wrong... I should probably stop participating in synchronous decision making 22:49:13 s/fantasai:/fantasai,/ 22:49:55 TabAtkins: One of the issues with applying styles to shadow roots is wanting to apply them to all shadow roots. You want to apply UA styles that are easy, trivial, to override. One possiblity for that is defining another origin that lives just before author style. Might be done with constructor for constructible style sheets. 22:50:05 TabAtkins: Some discussion in shadow dom around this. This is one possibility/ 22:50:22 q? 22:50:43 Rossen: do you need a resolution? 22:50:51 TabAtkins: More than one implementor is usually needed. Any takers? 22:51:20 TabAtkins: We have a consumer, which is useful, but no other implementor as of yet. 22:51:36 dbaron: Don't know yet. 22:51:50 smfr: Seems interesting, not high priority at the moment. 22:51:53 dbaron, Alternately maybe don't assume bad faith on the part of the editors as your default assumption for why the spec isn't the way you want it to be right this minute 22:52:30 Rossen: on edge side, not opposed to it but it's interesting and needed. Not a priority at the moment. 22:52:44 Rossen: So two interested parities but no commitments. 22:52:49 mck has joined #css 22:53:11 RESOLVED: Start working on constructible style sheets in WICG 22:53:12 myles has joined #css 22:53:54 Topic: selection cascade 22:54:11 github: https://github.com/w3c/csswg-drafts/issues/374 22:54:36 fremy has joined #css 22:55:07 TabAtkins: The original part of the issue: I assumed my testing had proven that there was a simple subset we could agree on. A few weeks ago Greg posted that not to be the case. David recently commented and linked to data dating back many many years. 22:55:31 TabAtkins: The propable issue is that it's still more complicated than I though it was. We need to figure it out and be consistent. 22:55:59 fantasai: We looked at this many times in the past. Once was when dbaron posted all options, another time was during psuedo discussion, when we realized we couldn't do it for interop/web compat. 22:56:13 Rossen: You're saying spec text is not accidental? 22:56:15 fantasai: Yes 22:56:16 s/propable/probable/ 22:56:54 TabAtkins: My memory are hazy but I said something like "all browsers agree on behavior but all disagree with spec". We need to either update spec or change behavior. 22:56:58 dbaron: When is spec text from? 22:57:03 TabAtkins: In psedo 22:57:12 florian: 2-3 years old? 22:57:18 TabAtkins: More than one year old 22:57:21 florian: Less than five 22:58:18 dbaron: 3.3 in psedo spec links to substantially more info that lead to the text. 22:58:34 darktears has joined #css 22:59:13 TabAtkins: The point is: As far as I can tell no implementing matches the spec. We're trying to do more of these and would be good to have at least the first one match the spec. 22:59:17 TabAtkins: I need to write good tests for it 22:59:41 s/I need/Someone needs/ 22:59:42 ^_^ 22:59:43 dbaron: Hard part is how the election styles interact with each other across elements. 23:00:06 s/election/selection 23:00:08 dbaron: This is the reason gecko hasn't unprefixed it. 23:00:43 fantasai, sorry for implying that. 23:00:50 TabAtkins: The only actionable point is "make this all better", my original premise was ruined by youall pointing out I was wrong. 23:00:59 Topic: none 23:01:01 duga has joined #css 23:01:03
      23:01:17 FYI CSS Scrollbars now in csswg-drafts repo: https://github.com/w3c/csswg-drafts/tree/master/css-scrollbars-1 23:01:22 lajava has joined #css 23:01:25 please file issues for concerns and feature requests as noted above! 23:02:32 dbaron, it's okay, we all make mistakes. And sometimes change our opinion of what the spec should say after 3-4 years :) 23:02:39 atai has joined #css 23:06:45 jcraig has joined #css 23:06:58 Karen has joined #css 23:07:05 rachelandrew has joined #css 23:07:51 mck_ has joined #css 23:07:58 and bikeshed-processed version: https://drafts.csswg.org/css-scrollbars-1/ 23:11:54 innovati has joined #css 23:14:26 atai has joined #css 23:15:12 mck has left #css 23:15:53 tomalec has joined #css 23:24:26 Chris__ has joined #css 23:28:30 bradk_ has joined #css 23:28:51 Next up, [css-multicol] Small legacy issues 23:29:00 jensimmons has joined #css 23:29:03 Topic: z-order of column-rule and column scrolling 23:29:10 github issue: https://github.com/w3c/csswg-drafts/issues/1739 23:29:26 smfr has joined #css 23:30:05 Topic: Multicolumn issues 23:30:19 github: https://github.com/w3c/csswg-drafts/issues/1739 23:30:38 rachelandrew: These first three issues are ones I dig out from the mailing list archive. They're all quite old. 23:30:48 rachelandrew: Things we've discussed, not sure what to do so brinng them up here. 23:30:52 Naomi_ has joined #css 23:30:56 rachelandrew: First one. z-order for column scrolling. 23:31:04 rachelandrew: Suggested change to wording. 23:31:18 rachelandrew: Is this something we want to add into the spec or do we need to dicuss it? 23:31:27 florian: Do we have interop on the proposed wording? 23:31:50 boazsender has joined #css 23:31:50 rachelandrew: There is an issue with overflow which as resolved a while ago, interop on the issue across browsers as far as I can tell. 23:32:14 rachelandrew: Firefox does not support spanning. 23:32:40 Rossen: Firefox is different due to that. 23:32:54 rachelandrew: Right, relating to the fact that thay haven't implemented it. 23:33:09 florian: The things that is linked to is not a minimized test case. Is an example. 23:33:15 rachelandrew: Correct. 23:33:39 byoo_ has joined #css 23:33:46 Proposed resolution: Apply proposed edit from Oct 2013 to spec. 23:34:05 sfbay 23:34:05 florian: A minimal test case would be good, but I'm fine with it. 23:34:10 Rossen: There is one in the github issue 23:34:18 rachelandrew: I'll add a test as part of spec change. 23:34:30 IanPouncey has joined #css 23:34:35 florian: I volunteer to review it. 23:34:36 RESOLVED: Apply proposed edit from Oct 2013 to spec. 23:34:50 Topic: Text describing column boxes as block container boxes 23:34:56 https://github.com/w3c/csswg-drafts/issues/1738 23:35:07 github issue: https://github.com/w3c/csswg-drafts/issues/1738 23:35:48 zcorpan has joined #css 23:35:53 jcraig has joined #css 23:35:53 rachelandrew: This is another text change for column boxes. Basically there is a section in the spec, example 9, about container boxes. 23:36:05 rachelandrew: There was a proposal to have the second sentence to be omitted. 23:36:12 tantek has joined #css 23:36:24 rachelandrew: There was no objections yet no edit took place. Looks like it was dropped. 23:36:37 zcorpan has joined #css 23:36:51 rachelandrew: Idea of containing block not defined in spec. 23:37:04 TabAtkins: I agree, go ahead and kill second sentence 23:37:18 Kill "That is, column boxes behave like block-level, table cell, and inline-block boxes as per CSS 2.1, section 10.1, item 2 [CSS21]." 23:37:26 zcorpan has joined #css 23:37:34 rachelandrew: Should we remove either or both of these sentences? 23:37:43 florian: Remove 2nd and 3rd? 23:37:52 fantasai: I don't think we should remove the 3rd. 23:38:01 TabAtkins: Default case applies. 23:38:18 IanPouncey has left #css 23:38:24 florian: This might be read as shutting down other properties that could apply unless specified. 23:39:00 fantasai: Behavior when you apply position relative needs to be defined 23:39:04 byoo__ has joined #css 23:39:29 TabAtkins: doesn't turn column boxes into abs containig blocks is fine, makes sense, should be explicitly informative. As written it is bad and should be removed. 23:39:35 rachelandrew: A clarification would be useful. 23:40:10 fantasai: It might help to clarify that the multicol container is the principle box, not mentioned in spec, and that the column boxes are anonymous. 23:40:26 fantasai: For example pos relative doesn't apply to column box. 23:40:30 rachelandrew: Makes sense to me 23:40:45 Rossen: Super good clarification. We all know this yet it isn't mentioned anywhere. 23:41:03 Rossen: Common source of confusion 23:41:30 rachelandrew: What are we suggesting to remove here? Turn third sentence into a note? 23:41:52 TabAtkins: Yes, and also make it clear that it clarifies that nothing you do on the column box... 23:42:15 fantasai: The part about being a principle box should go in sentence two. We should fix that. 23:42:43 fantasai: We don't have a good term for that box now, we refer to it as the multicol element, separate issue. 23:43:25 gregwhitworth: One thing that would be beneficial is having an example in there. Saying principle box isn't necessarily going to help web developers clarify. 23:43:39 Rossen: Similar to the table example in 2.1, speaks volumnes when people see it 23:44:12 Proposed resolution: Remove sentence 2 and 3 and adding clarification about the principle box. 23:44:32 RESOLVED: Remove sentence 2 and 3 and adding clarification about the principle box. 23:44:40 florian has joined #css 23:44:42 Topic: Proposal to drop example XVII 23:44:50 github issue: https://github.com/w3c/csswg-drafts/issues/1740 23:44:58 rachelandrew: Again, raised in 2013. 23:45:12 rachelandrew: This example was dropped for reasons mentioned in issue. 23:45:19 rachelandrew: No resolution. 23:45:45 rachelandrew: Perhaps needs a clearer example. 23:46:00 Rossen: OK. Any opinions? 23:46:27 "If a tall image is moved to a column on the next page to find room for it, its natural column may be left empty. If so, the column is is still considered to have content for the purpose of deciding if the column rule should be drawn." 23:47:03 RESOLVED: Remove example XVII 23:47:10 Topic: column spanning issues 23:47:21 github issue: https://github.com/w3c/csswg-drafts/issues/1072 23:47:49 rachelandrew: Three issues all referring back to each other. Main issue is 1072. Propose we resolve it first and then refer back to it. 23:48:01 rachelandrew: Quite a long issue. dbaron raised it and florian commented quite a lot. 23:49:13 rachelandrew: Quick summary: When you got an element with column spanning and they're not a direct child of the multicol box container and they're still spanning. The definition says what happens to the ancestor. A good example would be a section with headings and one of them has span all. 23:49:46 rachelandrew: Was discussed on a call in May, June, and then went back to discuss on github and then stopp.ed 23:50:00 dydz has joined #css 23:50:03 rachelandrew: Perhaps we shouldn't allow these nested things to span. 23:50:35 fantasai: There was some comments on allowing nesting of block but not things within another formatting context. Seems like a reasonable compromise. 23:51:19 fantasai: I don't think it is particularly useful for it to pop out as long as regular block elements work. The restriction makes sense from a behavior and implementation point of view. 23:51:41 fantasai: It is what I'd expect to happen it it makes what implementations seem to do. Makes sense to specify that behavior. 23:51:48 rachelandrew: I'd be happy to draft that up, makes sense to me. 23:51:54 fantasai: Happy to review spec text. 23:52:47 * discussion about florians comment in issue 1072 * 23:52:55 myles has joined #css 23:53:11 https://github.com/w3c/csswg-drafts/issues/1072#issuecomment-299097552 23:53:12 ? 23:53:41 fantasai: Arbitrary depths but you cannot cross a formatting context. 23:53:53 florian has joined #css 23:53:53 fantasai: Header inside a section is a good example. 23:54:34 Proposed resolution: Column span applies to elements lower than the first level of decendence as long as it doesn't cross a formatting context 23:54:42 Naomi__ has joined #css 23:54:47 nmccully has joined #css 23:55:01 jensimmons has joined #css 23:55:23 rachelandrew has joined #css 23:55:49 florian has joined #css 23:55:51 RESOLVED: Column span applies to elements lower than the first level of descendants as long as it's part of the same formatting context. 23:56:23 Topic: Background and borders for spanners 23:56:51 github issue: https://github.com/w3c/csswg-drafts/issues/1072 23:57:10 https://github.com/w3c/csswg-drafts/issues/1072#issuecomment-299076034 23:57:26 fantasai: What if the spanner is the very first element in an element that has borders and margins and paddings? 23:57:44 fantasai: Is the top margin pushed to after the spanner? 23:58:58 fantasai: For an inline what florian suggest in the issue that would be broken, what would we do in that case? 23:59:14 rachelandrew: I'd like to see what implementations do at this point. Heavn 23:59:17 't looked at that 23:59:39 http://software.hixie.ch/utilities/js/live-dom-viewer/?%0A%0A splitblock<%2Fspan>%0Arest of text<%2Fspan> 23:59:47 florian has joined #css 00:00:12 fantasai: Here is an example with a block splitting an inline. You can see that the border and then the split inline. 00:00:45 fantasai: There is a lot of fragmentation bugs as well. Entirely separate pile of "fun". Right now we're only dealing with the multicol aspects. What are the implications for this split. 00:01:21 * fantasi gives an example with spanners and multicol and borders * 00:01:22 Hexcles has joined #css 00:01:45 florian has joined #css 00:01:54 iank_: What appears if the spanner is the first child? What do you want to appear before the spanner? Maring border padding? 00:01:56 fantasai: Yes 00:01:58 iank_: Makes sense 00:02:17 zcorpan has joined #css 00:02:24 fantasai: I don't know if I want that but it is what would fall out from it being analogs 00:02:43 s/analogs/analogous/ 00:03:05 Rossen: The example is having a section inside an element with border? 00:03:33 boazsender has joined #css 00:04:09 * fantasi draws an example * 00:04:44 fantasai: We have a multicol with some stuff and a section element, then we have an h2 and the h2 is a spanner. 00:04:48 fantasai: The section has a border 00:05:05 The in-progress Gecko implementation treats it as analogous to block-in-inline splitting. 00:05:16 although it's a little harder in a few ways, and a little different in others. 00:05:37 fantasai: We definitively have a border around the section. The question is where the border goes. 00:05:50 fantasai: Remember the header is inside the section. 00:06:14 fantasai: First piece of border is before the split. Then you have the block and then the border continues. 00:06:57 fantasai: If that is bad behavior we could say that this fragment doesn't exist and then ... 00:07:11 * these notes makes no sense without the visual of the example... * 00:08:01 Rossen: For the purpose of margin collapsing, When we take the spanner out of the element, the right element, asusming it was the only content, then margin collasoing with the red border would change. 00:08:52 Rossen: If the element is effectively taken out of the flow of the containing blocks flow and then I don't see a reason why this element would be breaking the position of the top border of its parent. 00:08:59 Board images: https://photos.app.goo.gl/sm5cc7q8pywbSF0P2 00:09:07 sho has joined #css 00:09:18 Rossen: Now that the spanner is outside of the containing block and margin collasping would change, the red box in the digram could be pushed further down due to margin collapsing. 00:09:57 florian: So you're saying it would normally be posioined here but there being no margin between them there would be no space between them and the margin would not be in between. I think that is a pretty good point, arguing for leaving it up here. 00:10:10 s/florian/fantasi/ 00:10:54 rachelandrew: It is little weird, if that was one line of text up there it is still odd. 00:11:00 q+ 00:11:07 iank_: Effecitvely the spanner is treated as out of flow positioned? 00:11:18 Rossen: Yes, pulling it out of flow is getting tricky. We're there already 00:11:23 Reading the IRC, this doesn't make any sense to me. 00:11:29 iank_: That would mean that margins would collapse though it 00:11:35 but I don't know what people are pointing at. 00:11:50 o 00:13:20 I also suspect you haven't even gotten to any of the interesting issues yet... :-P 00:13:27 hey, is what I just said getting noted? 00:14:19 seems like a lot of this conversation is being missed, sadly 00:15:06 ScribeNick: TabAtkins 00:15:25 fantasai: I think rossens argument about the marign collapsing bebehvor this is confusing. The margin top is never going to be between the header and the first paragrapgh. If we go with the behavior where the top fragment doesn't exist then the margin is between the header and first paragraph. Then why is it above the header? 00:15:30 fantasai: That for me is the compelling argument to not do anything. 00:16:13 tmichel has joined #css 00:16:23 jensimmons: I can see a use-case where section>h2>content is the proper markup for content, and for small viewport sizes it's styled one way, and for large it's done in this diagram style 00:16:25 does box-decoration-break apply to the first fragment above the spanner? 00:16:27 jensimmons: I think it's fine if we let it break 00:16:39 rachelandrew: I think so too. Just need a resolution for that so it's tied to the spec 00:16:52 fantasai: I think this is a common situation, just question of where to draw top mbp; it goes above the header 00:16:57 rachelandrew: Happy with that. 00:17:30 RESOLUTION: If the fragment before the spanner is empty, nothing special happens; the top mbp is above the header, and it's just an empty fragment. 00:17:50 s/RESOLUTION/RESOLVED/ 00:17:51 ;) 00:18:26 lajava has joined #css 00:18:35 Topic: INteraction between column-span and column-fill 00:18:47 github: https://github.com/w3c/csswg-drafts/issues/1075 00:18:50 liam has joined #css 00:19:12 rachelandrew: The multicol spec doesn't define the interaction between column-fill and elements with column-span 00:19:21 rachelandrew: Says content is auto-balanced across columns. 00:20:22 “ The current spec appears to be more of a use cases document than a specification on this topic.” :) 00:21:10 iank_: So this is - i fyou've got a bunch of text before the spanner, does it just fill the first column, or does it balance? 00:21:14 TabAtkins: Examples show it balancing 00:21:43 dholbert: Not sure that's what's being asked, it's something about pagination... 00:22:02 fantasai: So c-f takes auto, balance, and balance-all 00:22:29 fantasai: balance means the last page is balanced, all the rest you fill the first column, then the second, etc. When you run out of content that'll fit (a forced break, or a big chunk) you just stop, don't balance. 00:22:42 fantasai: balance-all means you *do* balance on all pages 00:22:47 fantasai: auto means you don't do any balance at all 00:23:09 fantasai: column-span says if you ahve content befor ethe span, the span is a break (like a page-break), but you always balance what's left. 00:23:37 ^^ you balance the stuff *before* the span 00:23:41 byoo__ has joined #css 00:23:49 (I'm not in the room, though, but "What's left" seems wrong) 00:24:23 fantasai: So question in issue is, if you have a span in the middle of a page, the content after the span is balanced depending on the column-fill property. 00:24:31 fantasai: But if there's another spanner two pages down... 00:24:51 fantasai: The rule "balance the content before the spanner", does that apply to the previous pages ? 00:25:05 fantasai: I don't think that makes sense - a page break should limit how far you balance. 00:25:25 TabAtkins: Agree 00:25:47 fantasai: The row of boxes that get terminated by the spanner is the row that is forced to balance. Previous column rows don't balance by default (that depends on column-fill) 00:26:33 Rossen: ... TabAtkins: The concept you're talking about is the column row 00:26:41 Rossen: But not previous page 00:26:47 TabAtkins: by definition those are previous column rows 00:27:02 fantasai: You can ahve multiple column rows per fragmentainer. 00:27:09 fantasai: Generated by spanners and page breaks. 00:27:38 Rossen: So autofill rebalancing applies to the immediatley preceding column row of a spanning element. 00:27:56 ^^ I agree 00:28:09 s/what's left/the content before the spanner/ 00:28:26 Resolved: autofill rebalancing applies to the immediatley preceding column row of a spanning element only. 00:28:45 dholbert: [gives a questionable example, we're trying to figur eit out] 00:30:18 Topic: How does abspos work in a containing block split by a spanner 00:30:51 rachelandrew: It's not clear how abspos works when the containing block is split by a spanner 00:30:53 florian has joined #css 00:31:02 rachelandrew: I built an exmaple, we dont' ahve interop, it's all very strange 00:31:14 rachelandrew: How should we resolve this? 00:31:14 github: https://github.com/w3c/csswg-drafts/issues/1894 00:31:38 TabAtkins: My first instinct is that the contianing block is generated by the fragments 00:31:55 dbaron: that's the easiest to implement for us, and what we were planning to do unless someone disagreed 00:32:11 Rossen: It's not what we do 00:32:45 iank_: We were looking at multicol and abspos; dunno if webcompatible, but would be nice to have the fragment that contains the abspos do it. 00:32:57 dbaron: What's hard about that is the only case where you don't know the abspos cb at the tim eyou construct it. 00:33:47 TabAtkins: Situation ian was talkinga bout erlier, a large containing block at the end of a column, part of it is at the top of the next column 00:33:52 TabAtkins: what happens there? 00:34:00 https://codepen.io/rachelandrew/pen/rYeagj?editors=1100 00:34:05 dbaron: That happens during fragmentation, and this happens during frame construction 00:34:11 dbaron: fragmentation happens during layout 00:34:15 TabAtkins: CSS doesn't treat those two separately... 00:34:17 TabAtkins: per spec 00:34:42 dbaron: In ours you have to duplicate the logic then, in each place 00:35:05 iank_: Ah, we do some layout. 00:35:33 dbaron: The other two options are (1) always use first fragment, (2) union the fragments 00:35:36 TabAtkins: Dont' union, that's bad 00:35:50 dbaron: I think the "per fragment" is the sanest thing. Did the tests show something else? 00:36:03 rachelandrew: I think authors would prefer what grid does, unsure what tests show 00:36:27 rachelandrew: In grid, if you have an abspos grid item, the grid area generates the containing block 00:36:46 rachelandrew: Unsure about usage in multicol right now 00:36:51 TabAtkins: (because multicol sucks on the web) 00:37:14 iank_: Is there use-cases for wanting an abspos to span across a spanner? 00:37:58 dbaron: There's another set of issues we haven't resolved yet; if you have an abspos whose cb is part of a pagination sequence, and it has a large negative or positive top that pushes it up or down into a different fragment, i don't think we've defined that yet. 00:38:13 iank_: It would be nice if a box has fragmented, and the abspos is in that fragment, we consider that fragment as the cb 00:38:29 florian has joined #css 00:38:33 fantasai: What you want is that if you have a page in screen media and it's in abspos, you want it to paginate in a sane way, and you can't get that with this 00:38:44 fantasai: We want a page that is laid out with abspos to print out well for the user. 00:39:03 dbaron: The other model that gets you something in that direction is you consider the db to be the entire fragment chain 00:39:29 q+ 00:39:30 byoo_ has joined #css 00:39:38 TabAtkins: What's meant by that? 00:40:19 dbaron: Pretend all the fragmentes are together; top is relative to first frag, bottom is relative to last, etc... 00:40:29 fantasai: This is all defined in css-break-3 00:41:10 florian: Can I ask what we're trying to solve here? If we want to solve printing pages as they exist, I think Fragmenting gets it right; something else, what? 00:41:26 dydz has joined #css 00:41:26 dbaron: Less about that, more figure out what engines should do for a feature that's alreayd been specced for a decade. 00:42:19 fantasai: I'm okay with that behavior (spanner causing the break) being different form the general fragmentation behavior. I think that's a weird case. 00:42:30 fantasai: IMportant to make regular fragmentation make sense. 00:42:48 dbaron: I think it makes sense to make this agree; I just didn't thinka bout that when I filed th eissue, because impl-wise it's separate in our code. 00:43:22 [dbaron draws an example] 00:44:06 q- 00:44:25 There are three columns, split by a spanner 00:44:39 byoo_ has joined #css 00:44:49 there's an element which starts in the second column above the spanner, then continues into the third column above the spanner, then finishes parway through the first column after the spanner 00:44:54 atai has joined #css 00:45:39 dbaron if an abspos is in the element, and you say "top:0; bottom:0", it'll start in the second column, span across the third, and across the first after the spanner. 00:46:39 rachelandrew: Are we happy to resolve on that behavior? 00:46:43 [general agreement] 00:46:50 Karen has joined #css 00:47:14 q- 00:47:15 florian: I think most of these use-cases are best solved by page floats, not abspos, but if you have a use-case not solved, please bring it up 00:48:20 RESOLVED: Behavior already defined in CSS Fragmentation; file any issues there. 00:48:31 Topic: Moving WebAnim into CSSWG 00:49:41 Rossen: The WA spec is pretty active, realtively speaking, but issues don't seem to get attention from the WG. I think this is a straightforward request. 00:49:50 Rossen: We can separately talk about whether to do something with the rest of th especs. 00:50:08 fantasai: Fine if we can get history preservation 00:50:14 TabAtkins: Right, so let plinss do it 00:50:25 RESOLVED: Move WebAnim to the CSSWG repo. 00:51:25 tantek has joined #css 00:51:58 Topic: Filter effects - filters should establish containing blocks for abspos and fixpos 00:52:51 TabAtkins: Filters are morally equivalent to opacity (or vice versa) and opacity establishes a cb, so what's wrong? 00:53:17 ericwilligers: People were using extensions to apply a filter ot the whole page, and they didn't want things to rearrange 00:53:22 TabAtkins: Ah, it would break fixpos in that case. 00:53:41 TabAtkins: opacity creates stacking context, not contaiing block 00:53:51 ahhhh 00:54:15 lajava has joined #css 00:54:25 TabAtkins: Right, I was thinking of stacking context; i don't have a strong opinion on cb 00:55:19 TabAtkins: So my position is just: opacity is a filter, we need a very good reason to make filter and opacity work differently in any regard 00:55:38 github: https://github.com/w3c/fxtf-drafts/issues/11 00:57:26 Perhaps it's worth reading the background in https://www.w3.org/2015/02/10-fx-minutes.html#item02 on the previous time this was resolved? 00:58:38 TabAtkins: In the linked details, roc gives an explanation for why opacity is different. It commutes with the clipping operation, whatever that means 00:58:46 TabAtkins: That doesn't apply to other filters 00:58:53 TabAtkins: tha'ts a reason for opacity to work different from other filters 00:59:07 TabAtkins: that is a reason for filters to make a containing block 'cuz awkward wherenot for opacity 00:59:20 TabAtkins: can special case root element to have filters apply to canvas 00:59:24 TabAtkins: since that's the compat issue 00:59:27 TabAtkins: and maybe also body 00:59:47 We are worried about web compat 00:59:51 TabAtkins: root has filter, fixedpos, and filters keep cb, then fixedpos is not fixedpos, it's abspos 01:00:15 blur then clip is different from clip then blur 01:00:17 TabAtkins: Filters create a containing block for fixedpos 01:00:21 TabAtkins: turn them into abspos 01:00:49 TabAtkins: opacity doesn't have this problem much, so doesn't need to do this 01:01:21 +1 to myles 01:01:28 TabAtkins: Are you worried aobu tmore than just filter on body? 01:01:32 myles: yes 01:01:42 TabAtkins: You get weird results, as dbaron points out 01:01:51 TabAtkins: Blur followed by clip is very different than clip then blur 01:01:59 TabAtkins: fixedpos figuring out what that menas is weird 01:02:05 TabAtkins: what do you do now? 01:02:07 myles: I don't know 01:02:14 we’re kinda broken 01:02:15 florian has joined #css 01:02:15 :) 01:02:30 I think Gecko has been shipping this for a while 01:02:33 not sure if bugs or fundamental problems with implememtation 01:02:37 Rossen: fixe,d everyone expects to behave a certain way 01:02:44 Rossen: If you have a filte on a nelement you expet an effect 01:03:00 Rossen: want to trap abspos things so they filter applies to them as well 01:03:04 we did get a small number of bug reports when we shipped it, I think 01:03:13 Rossen: but for fixed, not so much 01:03:16 although at least some of them were due to bugs in what we initially shipped 01:03:20 TabAtkins: Shoudl fixedpos be blurred or not blurred? 01:03:22 Rossen: Should not be 01:03:32 TabAtkins: OK, that's an entirely diferent solution 01:03:42 tienr-ren: Does that mean fixedpos escapes stacking context? 01:03:55 ... including Opacity and CSS Mask stackign context? 01:04:04 ... Does it still follow z-index stacking order? 01:04:06 Rossen: Of course 01:04:12 TabAtkins: We already have these same cases addressed 01:04:17 florian has joined #css 01:04:17 TabAtkins: So we should change everything in lockstep 01:04:31 fantasai: The reason we did this for transforms is we need to find the staticpos 01:04:52 fantasai: But for filters, nothing's moving... 01:04:56 TabAtkins: Sure can - displacement filter 01:05:34 fantasai: You can have a fixpos in a scroll container, it escapes the container unless there's special trapping behavior there. Why would filters be different from that? 01:06:22 plh has joined #css 01:06:22 TabAtkins: but then can't apply the filter 01:06:26 fantasai: That seems reasonable 01:06:31 TabAtkins: But it's different from other things 01:06:53 fantasai: I'm not really convinced that any of these should trap fixedpos... 01:07:04 TabAtkins: yeah but that's what ppl implemented so now we're stuck with it 01:07:24 Rossen: So proposed resolution is apply both containing block for and abspos on filters as well as stacking context 01:07:27 Rossen: Now that we've caught up, the proposed resolution is to make filters apply a cb to abspos and fixpos 01:07:38 Rossen: Second is potentially add a quirk for the root containing block to not trap fixpos 01:07:41 Rossen: and other is add a quirk for root containing block, where fixed positioes remain fixed rather than turning into abspos 01:07:50 Rossen: can take in order or together 01:07:55 TabAtkins: Think we need to take them together 01:08:25 Rossen: So Filters establish stacking context as well as containing block for any positioned descendants except when they are apply to the root element, in which case they affect everthing 01:08:43 SteveZ2 has joined #css 01:09:02 fwiw, the group already resolved to do this, it just never got edited into the spec... 01:09:05 Tien-Ren: Do we have to do this on body or just root? 01:09:12 fantasai: Please not on body, it's so terrible 01:09:23 TabAtkins: Depends on web-compat 01:09:39 Tien-Ren: describes some horrible thing that happens with style-stealing from body 01:09:45 TabAtkins: Yes, I would prefer root only if possible 01:10:08 Rossen: dbaron kindly reminds us that we resolved on all of this and we just need to edit 01:12:36 proposed: follow the existing resolution, add a quirk for filters on the root element to not trap fixpos 01:12:52 RESOLVED: follow the existing resolution, add a quirk for filters on the root element to not trap fixpos 01:13:09 Topic: rootScroller 01:14:05 bokan: Proposal based on feedback from internal google teams 01:14:14 bokan: Problem to solve is that the document element is special in many case 01:14:20 bokan: Particularly the url bar on mobile 01:14:41 bokan: You get overscroll-glow on the root element only (on android) or elastic (on ios) 01:14:54 bokan: on ios if you tap the url bar, the root is scrolled to its top 01:15:09 bokan: But authors might want to compose their app in multiple views: a stream with multiple items where ach animates in nicely 01:15:20 bokan: Each stream is a separate scroller, only one displayed at a time. 01:15:31 bokan: But now you lose those nice effects, like scrolling it hides the url bar 01:15:43 bokan: Same with AMP pages 01:15:54 bokan: So proposal is a simple API with some difficult implementation 01:16:04 bokan: You specify which element is the "special" scroller. Starts as the root element 01:16:05 SteveZ has joined #css 01:16:11 bokan: When you animate to a view, you designate that as the root. 01:16:24 bokan: Looking to gauge interest from other vendors. 01:16:33 bokan: I have this impl'd in a flag in chrome 01:17:12 bokan: This is unrelated to viewport stuff. 01:17:27 bokan: Not as concerned about API shape; willing to explore alternatives as long as we solve the problem. 01:18:03 TabAtkins: I remember some interesting questions about what displays if the element isn't screen-filling... 01:18:13 bokan: We currently spec that it only applies if the element fills the viewport. 01:18:21 myles: How to do that? 01:19:20 bokan: width/height: 100%. Just needs to be the same size as the ICB. 01:19:39 bokan: There was some interesting in having, say, a header element that sits alongside it. 01:19:49 TabAtkins: [discussion about how it's bad ot overlap the scroller] 01:19:59 myles: Some real complexity here. [something about tiling and scrollers] 01:20:08 myles: Hooking this to an arbitrary scroller is mechanically difficult. 01:20:18 myles: So I hesitate to support this yet. 01:21:24 rachelandrew has joined #css 01:21:29 s/[something about tiling and scrollers]/we have at least 3 codepaths for scrollers, and the root scroller has a fair amount of machinery associated with it including tiling, hardware layers, and inter-process layer hosting. Hooking this up for an arbitrary scroller would be very difficult for us/ 01:22:38 Rossen: During the break David, Simon, etc were actually discussing this, and wanted to incorporate the work into CSS Viewport. 01:22:57 Rossen: Ignore what I just said. 01:23:04 s/During the break David, Simon, etc were actually discussing this, and wanted to incorporate the work into CSS Viewport.// 01:24:42 gregwhitworth: We haven't recieved author interest about this yet. 01:24:45 florian has joined #css 01:25:11 bokan: Today you can hack around this - teams at Google will pull things in and out of the document element. But this is hard to do well and interoperably, you can get scrollbar flashes, etc. 01:25:27 bokan: And you have to keep track of scroll positions yourself; scrollbar flashing is unavoidable, everyone does it. 01:25:46 myles: So objection is that when the height of the root scroller change,s the scrollbar moves? 01:25:58 bokan: So say you have a stream loaded in the doc element, and you expand one of the items. 01:26:12 bokan: Today you hide all the content, and insert the expanded stuff. That causes the scrollbars to flash. 01:26:23 bokan: Some are bugs or inconsistencies, some are just general issues. 01:27:18 myles: I guess browsers control that scrollbar - if your goal is to not flash the scrollbar, maybe we can solve that more directly, without the complexity of arbitrary scrollers becoming root. 01:27:30 TabAtkins: So it sounds like you might support the use-case, if not the API. 01:27:42 myles: We're all for being able to remove and replace stuff from the DOM hierarchy, and do it in a non-jarring way. 01:28:00 TabAtkins: Yeah, that's our use-case then. 01:28:20 myles: Right, then we support that. 01:28:36 TabAtkins: So you'd support a wicg to solve that problem? 01:28:39 myles: Sure. 01:29:31 Topic: CSS Viewport 01:29:52 Rossen: A while back, we had a resolution to work on a spec that describes the viewport 01:30:32 Rossen: We want to explain/define all the different things like zooming, pinch-zooming, content-zooming, all the zooms. 01:30:53 Rossen: More recently, the separation between visual and layout viewport, what applies to what. 01:31:09 Rossen: What units are we returning OM results from... 01:31:29 Rossen: Today we have non-interop behavior where Edge returns one set of results, in a mix between viewport and layout units. 01:31:41 Rossen: Chrome does only layout viewport units, I think 01:31:47 Rossen: And Safari is trying to align with this 01:32:03 Rossen: So the work we have planned that is supposed to be split between myself, Peter, and Florian, hasn't had much traction 01:32:16 Rossen: There are a lot of specs starting to come about that need to reference the viewports 01:32:25 Rossen: DAvid graciously agreed to start writing spec text 01:32:38 Rossen: So the proposal is to add David as an editor to Viewport and start writing spec text 01:32:48 Rossen: smfr said he's thumbs up 01:33:05 RESOLVED: Add David Bokan as editor to the Viewport spec 01:33:56 Topic: Intrinsic sizing and containers for grid/flex sizing 01:34:00 github: https://github.com/w3c/csswg-drafts/issues/1865 01:34:14 r12a has joined #css 01:35:10 fantasai: We discussed yesteray this problem of, in flex and grid we have implied minimum size, and people put stuff in there with scrollbars, expecting that to handle overflow, but because we'r elooking for min-content size *including* overflow, stuff gets too big and it's awkward 01:35:18 fantasai: Don't know how to fix it, because it's a deep descendant 01:35:26 fantasai: We opened an issue to find better ways here 01:35:55 fantasai: Proposal is that grid/flex items that have non-visible overflow ignore their content for the purpose of calculating min-content contribution 01:36:00 fantasai: In both axises 01:36:06 fantasai: And block boxes do the same thing in the inline axis 01:36:15 fantasai: Excluding the block axis because it's awkward and idfficult to compute 01:36:55 fantasai: dbaron brought up the point that you might want to consider overflow:hidden different from scroll, because it's sometimes used just for bfc, nothing to do with clipping. That's probably only relevant for blocks. 01:37:18 fantasai: For authors that want the min-content size to handle the sizing, they can explicitly use "min-height: min-content" 01:37:35 fantasai: I think this will give more intuitive behavior; people wont' be as confused when their items get much wider than expected 01:37:48 fantasai: And for hte people who do need to have this old behavior, they can just use min-content keyword 01:38:34 TabAtkins: I'm confused - I thought this was about *descendants* of flex/grid items 01:38:46 fantasai: Right, but those descendants might be flex/grids again 01:40:10 fantasai: So a block with auto-size in the inline axis, and the flexbox container says "how much space does my content want?" and the block says "THIIIIIIIIIIIS wide" and the flexbox gets huge 01:40:53 fantasai: So if the block reports that it's 2ems wide (just padding), the flex container can say "2ems here for this scroll container, 3ems for that word", and then becomes 3ems wide, and the extra stuff will scroll as intended. 01:41:27 s/auto-size/auto-size and scroller/ 01:43:01 fantasai: So the intrinsic size of a scroll container is dictated by its contents. The fact that it has a scrollbar is irrelevant to its contribution; but in practice, you put a scrollbar on it, you're *okay with* it shrinking, so it should be able to shrink below the min-content size. 01:43:39 (and if you don't want to, you can set min-width: min-content) 01:44:53 dbaron: Trying to see how specific it is to grid/flex 01:45:20 fantasai: Currently not specific. it would effect a float or table-cell that contains an element with overflow:scroll, *if* that float's size is dictated by the size of the overflow element 01:45:51 dbaron: I suspect we can't change the float/table behavior, we're probably stuck with this. 01:46:03 TabAtkins: So just min-width/height:auto, then 01:46:26 gregwhitworth: We resolved about something similar on tables yesterday 01:46:55 fantasai: The cases effected by this proposal would be where author sets overflow:auto/scroll, but nothing ever scrolls because the box is always big enough to fit its contents. This seems weird. 01:47:26 fantasai: Where the overflow-controlled box is the one dictating the size of the container, such that it never ends up needing to overflow. Seems kinda odd. 01:47:30 dydz has joined #css 01:47:42 fantasai: Usually when you ask for overflow, your size is dictated by something else, such that you might have overflow. 01:48:28 boazsender has joined #css 01:48:28 TabAtkins: I think this needs more thought and compat analysis before I"m comfortable with this. 01:48:40 fantasai: Should be able to do it for flexbox and grid, at least, which would solve a lot. 01:49:07 fantasai: Currently we say if you have overflow:non-visible your automatic min-size is zero, but your min-content contribution is not zero. 01:49:15 fantasai: So I think it's safe to say your min-content contribution is also 0. 01:50:02 TabAtkins: I'd still want some thinking time about this, even for the limited case. 01:51:56 Topic: computed value for font-variation-settings 01:52:13 https://github.com/w3c/csswg-drafts/issues/1959 01:52:38 gregwhitworth: You can duplicate values in f-v-s; set axis "x" over and over again. 01:52:45 gregwhitworth: When you ask for computed value, should you get the dupes? 01:52:54 gregwhitworth: Or get the simplified version. 01:53:03 gregwhitworth: Currently Chrome and Edge return what the author wrote. 01:53:50 TabAtkins: I think Safari makes sense. It should be a map. 01:54:04 eae: And it would simplify our implementation. 01:54:13 dbaron: Is this sthe same as font-feature-settings? 01:54:23 myles: In our impl, yes. And it makes sense to keep them in lockstep. 01:54:37 Rossen, testcase for previous discussion - http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=5495 01:54:54 myles: If there is a script calling gCS() and parse that value, it's more likely to get it right with deduped values too. 01:55:16 gregwhitworth: So barring testcases, resolution is to have it be deduped for f-v-s 01:55:26 dbaron: We should resolve for both, and come back if testing says it's a bad idea. 01:55:45 RESOLVED: For both font-variation-settings and font-feature-settings, the computed value is a map (and thus specified dupes are removed) 01:57:35 github-bot, end topic 01:57:59 oh, it wasn't right above... 01:58:16 florian has joined #css 01:58:19 Topic: ... 01:58:26 TabAtkins: Definition of what a propdef block means is in 2.1 01:58:31 TabAtkins: I would like to move it to someplace better 01:58:37 TabAtkins: snapshot's probably the best place for that 01:58:43 florian has joined #css 01:58:45 github: https://github.com/w3c/csswg-drafts/issues/1867 01:58:55 TabAtkins: Problem is defintion of propdef tblesis probably normative 01:59:05 TabAtkins: snapshot was decided to be non-normative awhile back 01:59:27 TabAtkins: which as other consequences such as the ton of conformance boilerplate that we have to put in every one of our specs 01:59:46 Chris: We could hip that spec to other spec liek Value sand Units 01:59:53 Chris: Or we can make it non-normative 01:59:56 chris: so let's do that 02:00:08 Florian: Youc an do that in a Note? 02:01:22 Chris: reading prodpef tables isn't really a conformance thing 02:01:27 fantasai: but the other bits of boilerplate are 02:01:43 Chris: Then, we'll publish the snapshot as a WD, and the a year later when the new snapshot is a WD, turn it into a note 02:01:54 flackr: You'l deal with that? 02:01:55 Chris: yeah 02:02:18 topic:none 02:05:02 atai has joined #css 02:07:07 Hexcles has joined #css 02:08:49 florian_ has joined #css 02:13:31 SteveZ2 has joined #css 02:14:11 duga has joined #css 02:14:20 boazsender has joined #css 02:23:51 SteveZ has joined #css 02:24:33 Chris__ has joined #css 02:28:08 atai has joined #css 02:33:17 dbaron: http://jsbin.com/zebecokaqi/edit?html,css,output 02:34:06 SteveZ2 has joined #css 02:38:13 plh has joined #css 02:44:48 SteveZ has joined #css 02:53:09 zhaolei has joined #css 02:54:35 zhaolei has left #css 03:06:58 SteveZ has joined #css 03:23:07 SteveZ has joined #css 03:32:56 tantek has joined #css 04:02:46 SteveZ2 has joined #css 04:04:16 tantek has joined #css 04:07:54 byoo has joined #css 04:08:56 byoo has joined #css 04:08:58 SteveZ2 has joined #css 04:09:59 jensimmons has joined #css 04:14:36 rachelandrew has joined #css 04:17:08 SteveZ has joined #css 04:25:01 dydz has joined #css 04:36:59 SteveZ has joined #css 04:37:04 sam has joined #css 04:44:09 innovati has joined #css 04:46:51 SteveZ2 has joined #css 05:01:37 tomalec has joined #css 05:02:06 SteveZ has joined #css 05:04:39 SteveZ2 has joined #css 05:05:04 innovati has joined #css 05:07:53 duga has joined #css 05:11:16 SteveZ has joined #css 05:14:42 SteveZ2 has joined #css 05:20:46 atai has joined #css 05:32:01 innovati__ has joined #css 05:37:17 SteveZ has joined #css 05:38:35 smfr has joined #css 05:40:06 lajava has joined #css 05:46:16 SteveZ2 has joined #css 05:54:01 SteveZ has joined #css 05:56:51 SteveZ2 has joined #css 06:06:07 SteveZ has joined #css 06:09:34 Hexcles has joined #css 06:13:01 tantek has joined #css 06:27:21 SteveZ has joined #css 06:28:25 dydz has joined #css 06:37:21 SteveZ2 has joined #css 06:37:58 florian has joined #css 06:39:37 florian_ has joined #css 06:44:00 dydz has joined #css 07:02:34 SteveZ has joined #css 07:09:03 SteveZ has joined #css 07:23:21 zcorpan has joined #css 07:25:33 florian has joined #css 07:25:50 SteveZ2 has joined #css 07:34:38 jensimmons has joined #css 07:38:14 SteveZ has joined #css 07:42:47 rego has joined #css 07:50:54 SteveZ has joined #css 08:00:44 SteveZ has joined #css 08:01:36 sam has joined #css 08:06:52 antonp has joined #css 08:08:27 florian has joined #css 08:10:12 florian has joined #css 08:15:58 tomalec has joined #css 08:16:16 SteveZ2 has joined #css 08:25:40 SteveZ has joined #css 08:33:59 SteveZ2 has joined #css 08:35:53 atai has joined #css 08:43:59 SteveZ has joined #css 08:53:45 SteveZ2 has joined #css 08:57:01 SteveZ has joined #css 09:03:57 SteveZ2 has joined #css 09:14:05 Ms2ger has joined #css 09:15:46 SteveZ has joined #css 09:28:14 SteveZ has joined #css 09:32:18 SteveZ has joined #css 09:37:44 SteveZ2 has joined #css 10:15:22 SteveZ has joined #css 10:17:49 SteveZ2 has joined #css 10:27:43 SteveZ has joined #css 10:44:22 SteveZ has joined #css 10:44:43 zhaolei has joined #css 10:57:00 SteveZ2 has joined #css 10:58:47 flyingzl has joined #css 10:59:20 你好，石头 11:00:36 florian has joined #css 11:07:52 SteveZ has joined #css 11:11:16 glazou has joined #css 11:15:40 SteveZ2 has joined #css 11:18:50 rachelandrew has joined #css 11:29:23 SteveZ2 has joined #css 11:32:25 tomalec has joined #css 11:47:01 SteveZ2 has joined #css 11:54:12 SteveZ has joined #css 12:05:44 SteveZ2 has joined #css 12:06:53 sam has joined #css 12:10:57 SteveZ2 has joined #css 12:15:23 SteveZ has joined #css 12:20:44 SteveZ2 has joined #css 12:31:44 SteveZ has joined #css 12:38:20 SteveZ2 has joined #css 12:44:42 SteveZ has joined #css 12:52:46 SteveZ has joined #css 13:02:23 SteveZ has joined #css 13:17:41 SteveZ2 has joined #css 13:26:14 SteveZ has joined #css 13:34:58 SteveZ2 has joined #css 13:37:29 tantek has joined #css 13:39:56 tantek has joined #css 13:44:27 SteveZ has joined #css 13:50:21 Ms2ger_ has joined #css 13:53:55 SteveZ2 has joined #css 14:00:08 SteveZ has joined #css 14:03:46 SteveZ2 has joined #css 14:17:46 SteveZ2 has joined #css 14:24:34 SteveZ has joined #css 14:27:17 projector has joined #css 14:27:48 Rossen has joined #css 14:28:18 shans has joined #css 14:28:49 sylvaing has joined #css 14:29:19 leaverou has joined #css 14:29:49 plinss has joined #css 14:38:03 SteveZ has joined #css 14:48:57 tomalec has joined #css 14:50:30 SteveZ has joined #css 14:58:44 SteveZ2 has joined #css 15:16:08 SteveZ2 has joined #css 15:22:26 atai has joined #css 15:25:01 SteveZ has joined #css 15:27:29 boazsender has joined #css 15:31:12 SteveZ has joined #css 15:33:49 SteveZ2 has joined #css 15:46:09 SteveZ has joined #css 15:49:23 SteveZ has joined #css 16:01:57 SteveZ2 has joined #css 16:17:44 SteveZ2 has joined #css 16:23:09 atai has left #css 16:26:21 dydz has joined #css 16:26:27 SteveZ has joined #css 16:26:34 florian has joined #css 16:29:56 jcraig has joined #css