15:53:49 RRSAgent has joined #css 15:53:49 logging to https://www.w3.org/2019/10/09-css-irc 15:53:51 RRSAgent, make logs public 15:53:51 Zakim has joined #css 15:53:53 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 15:53:53 Date: 09 October 2019 15:54:10 astearns has changed the topic to: agenda for Oct 9 meeting: https://lists.w3.org/Archives/Public/www-style/2019Oct/0008.html 15:56:57 dauwhe has joined #css 15:58:44 dael has joined #css 16:00:18 present+ 16:00:19 Today (October 9th) is Hangul day. Let us all celebrate this very ingenuous and beautiful writing system. 16:00:19 smfr has joined #css 16:00:22 present+ 16:00:29 stantonm has joined #css 16:00:49 present+ 16:00:51 AmeliaBR has joined #css 16:01:07 astearns: For first topic I believe we need emilio or another firefox person on the call 16:01:13 scribenick: dael 16:01:17 Present+ antonp 16:01:50 Rossen_ has joined #css 16:02:00 present+ 16:02:00 jensimmons has joined #css 16:02:04 present+ 16:02:14 present+ 16:02:33 present+ 16:03:04 astearns: I think we have enough to start 16:03:18 astearns: As always, are there any changes to the agenda? 16:03:18 present_ 16:03:20 present+ 16:03:31 astearns: One change, we can't usefully do item 5 unless we get some extra people on the call 16:03:36 astearns: Other changes? 16:03:48 Topic: propagation from body to document element is annoying 16:03:50 github: https://github.com/w3c/csswg-drafts/issues/4357 16:04:08 astearns: Who wants to lead? 16:04:28 [discussion about if emilio has audio] 16:04:51 github: none 16:04:53 Topic: Should automatic list-item increment adjust for ol[reversed]? 16:05:01 github: https://github.com/w3c/csswg-drafts/issues/4181 16:05:07 now does 16:05:15 github: none 16:05:20 Topic: propagation from body to document element is annoying 16:05:26 github: https://github.com/w3c/csswg-drafts/issues/4357 16:05:49 emilio: We resolved hesitantly on prop. the used writing mode from body to document element and to viewport I assume 16:05:55 teleject_ has joined #css 16:06:12 emilio: We have an impl but afaict other engines are not ready to impl since don't store value in layout tree 16:06:15 emilio: Resolution is hacky to impl. 16:06:41 emilio: Should we implement this? Do what other engine impl which is just prop to viewport? And tell people if they want orthogonal set on document element 16:07:36 florian: Discussion on GH is this looks hacky but doable in Blink as well. Given we resolved there is some willingness to do this. If not, I wonder why we resolved. We can reopen but it's unplesent. If can do in blink and FF and we're moving the spec forward and it's nicest for author I would hope keep as is 16:07:38 aja has joined #css 16:07:50 florian: If people not going to do it you're right it's not helpful for spec to say one thing and do another 16:07:53 svoisen has joined #css 16:08:01 emilio: This is only thing that prop to document element, right? 16:08:26 florian: propagation on other things is a bit complicated but less so. Only thing that propagates in this way 16:08:46 emilio: AS gecko dev I'm not in lovewith hack. Easier to propagate to viewport. Happy to impl if other engines will do it 16:09:07 fantasai: In WM we wanted ot make sure it's prop in same way as direction. Means spec was not quite correct in way direction prop. 16:09:27 present+ 16:09:35 myles has joined #css 16:09:43 fantasai: Adding writing modes and direction need to prop together. Iunderstand how hacky it is, Blink solution sounds pretty crazy. I think prop was a mistake, but it happens so have to address. Doens't have to be perfect. 16:09:56 present+ myles 16:10:05 emilio: Direction in gecko does not prop at all, only have hack for scrollbar directionality and that would not be needed if both prop to viewport 16:10:26 emilio: Blink prop to the viewport is to fix the same case and the hack for look up body style from scrollbox is doing. 16:10:37 emilio: Intent is same, behavior is different as is impl complexity 16:11:08 florian: Would like to hear from blink. WE can investigate ideal. It's hacky but doable in gecko. If blink will do we don'th ave to revist. We have discussed preferable behavior. 16:11:20 bradk has joined #css 16:11:35 emilio: But it was on assumption direction was prop somehow. But in blinka nd webkit it is prop with writing mode to viewport. In gecko there'sno prop, just lookup a box for this style 16:11:51 florian: I suspect that's if you fix bugs related to printing you'll have to do it there as well. 16:12:10 emilio: Sure, but scrollbar position....that also works if you prop writing mode to viewport 16:12:44 bradk has joined #css 16:12:50 florian: Direction only not prop to document element is fine. But direction if you don't go through element you create horizontal flow and tha'ts not nice. Ideally for authors we prop the whole thing properly. If can't do that there are intermediate solutions. 16:13:19 fantasai: I think important point that page progression direction and frag direction needs to be consistant with how modify scrollers. That doens't require us to change the root element 16:13:51 fantasai: Means content will overflow root, but in a direction we've choosen. Similar to how the root element in the scrolling case doesn't grow to accomodate the content. Solveable but important to solve 16:14:01 florian: If we jsut prop to viewport it's workable but less nice for authors 16:14:22 Rossen_: That solution will be commonly hit by authors bc most tools set direction on body rather than root element 16:15:19 Rossen_: When orginally disc I was in full support as documented in spec and that's the behavior in Edge where we prop from body to root and all the way to viewport. Allows us to avoid all these corner cases of root element and body element differing by writing mode and causing scrollbars 16:15:36 Rossen_: Unless explicitly set rules elsewhere that set different writing modes explicitly 16:16:22 Rossen_: In our impl it wasn't crazy to impl given we're kinda sorta doing it in overflow. I looked at blink and what I desc is impl there. I don't know if we have resources right now, but wouldn't be opposed to giving that a go and having better results for authors as we have desc 16:16:37 Rossen_: Doens't mean I'm saying I'll def land it in blink, saying not opposed to landing. 16:17:14 Rossen_: Looking at rune's comments on GH he's not crazy about it but doens't sound against. Don't want to speak for him/chrome, but looking through what's needed and what we spec that matches what as an author I would expect to see happen 16:17:27 emilio: I'm okay closing no change if this is eventually impl interop 16:17:48 astearns: sounds to me that yes impl is hacky but people are willing to change. Given author benefit I think we close no change and wait on impl 16:17:51 astearns: Objections? 16:18:03 RESOLVED: Close this issue no change 16:18:10 astearns: Thanks emilio for bringing this up 16:18:16 present+ 16:18:18 Topic: Should automatic list-item increment adjust for ol[reversed]? 16:18:26 github: https://github.com/w3c/csswg-drafts/issues/4181 16:18:51 fantasai: There was a request from someone to discussed resize-observer earlier in the agenda 16:19:12 github: none 16:19:17 [agenda discussing] 16:19:51 Topic: device-pixel-border-box size 16:20:02 github: https://github.com/w3c/csswg-drafts/issues/3554#issuecomment-538465771 16:20:19 astearns: Discussed device-pixel-border-box size at TPAC 16:20:47 astearns: I recall we still weren't sure how change will effect Safari. Example have now been provided. Do we have enough information on impact to Safari? 16:21:26 drousso has joined #css 16:21:41 smfr: Saw a couple of examples. I think Chris said he ran the tests on Macbook pro retina with the fixes and it made it look better. Can't say without doing work in webkit, but I think sufficient proof this is useful. On non-apple it's well known it's necessary 16:21:47 astearns: Any other new information? 16:22:06 ??: Nothing new except demos and version of chrome that fixes 16:22:13 s/??/chrishtr/ 16:22:29 smfr: I'm surprised you could get good results. Most macbooks have default scaling. Surprised you got good results on a machine with that behavior 16:22:39 chrishtr: It's not the newest 16:22:49 presnet+ 16:22:53 present+ 16:23:04 [audio problems 16:23:43 chrishtr: Tested on not absolute newest, but a macbook pro retina. I think it does have value and OS scaling if it's outside of control of application those situations can't be fixed 16:24:51 smfr: What I'm interested in understanding is if on hardware with builtin scaling suc htat you never get pixel perfect is there improvement in device-pixel-border-box ? Is there value in making it optional and allow UA to not provide if it thinks it can provide better. Or do we make it required and force UA to do this when it's not going to get better 16:25:06 myles: Easy to test if you change resolution of OS in your macbook pro 16:25:39 astearns: Sounds to me like we don't have an objection to adding device-pixel-border-box size to the API, but may want another issue about behavior of API possibly making it optional? 16:26:00 chrishtr: Would app fallback be multiply css pixel width and height by device-pixel ratio if UA doesn't supply? 16:26:29 smfr: Impl will alreayd have to multiply by device-pixel-ratio. No, does multiply. Okay. 16:26:39 chrishtr: That was the point, rounding or flooring can't get consistent 16:26:46 smfr: Okay, then makes optional thing annoying 16:27:17 chrishtr: I don't know if built in scaling is higher quality but we got really good results on macbook pros even with non-1 to 1 scaling. 16:27:21 smfr: Okay 16:27:38 s/ chrishtr / ken 16:28:07 smfr: Not objecting to adding. Question if needs to be rectangle or just a size since left and top don't mean anything 16:28:18 chrishtr: Use case for canvas sizing top left not nec 16:28:23 smfr: We don't have a dom size object 16:28:45 chrishtr: Yep. More consistent to have a rect, rect does have meaning. Not used in canvas case 16:29:04 ken: Position of rect a little confusing if you consider overflow area 16:29:13 chrishtr: Does mean where it is on device window though 16:29:15 s/ken/myles/ 16:29:53 chrishtr: It's used within the native texture if there's not special scaling smfr referred to. If texture is scrolled it's still...it doesn't take into account transforms and scrolls 16:29:58 myles: Values off the top of the screen? 16:30:09 chrishtr: I think would be fine to have size only for this reason 16:30:22 chrishtr: top left doesn't seem to mean much, want to know canvas size 16:30:34 astearns: Array of 2 values or are you minting a new size objection? 16:30:41 chrishtr: I don't know. Maybe new size object? 16:30:43 s/objection/object/ 16:30:47 smfr: If it always integral? 16:30:49 chrishtr: Yeah 16:31:01 smfr: Maybe you jsut have two long on the entry 16:31:07 chrishtr: THat are just width and height 16:31:45 chrishtr: As relates to desire to add the eq method to getBoundingClientRect it would change to get device pixel width and height 16:31:54 smfr: If we agree to resizeObserver do we still need? 16:32:08 chrishtr: Don't think so, but ?? from Mozilla thought case was strong so I was okay adding 16:32:13 smfr: Which case was it? 16:32:29 s/??/Jeff Gilbert/ 16:32:33 chrishtr: You have a full screen where you don't want resizeObserver and you want a slight jump on resize frames 16:32:53 ken: Jeff also had concerns that it fires late and application would fall behind a frame which is legit concern 16:33:22 myles: You would need to executecode every frame with this. resizeObserver means code only called when need to be. 16:33:37 tantek has joined #css 16:33:43 s/executecode/execute heavy calculations/ 16:33:54 ken: Agree, but in experience from a dev on FF stack we felt it was important to aleviate concern. And FF intends to not recompute if layout isn't dirty 16:34:04 regrets+ 16:34:11 smfr: I don't want every getBoundingClientRect to be more expensive 16:34:13 chrishtr: Adding a new thing 16:34:21 smfr: Okay, okay. Should discuss sep. 16:34:35 chrishtr: Okay with me. Is Jeff Gilbert on? Want ot make sure he's okay to separate. 16:34:44 chrishtr: If he's not, maybe tentatively do that. 16:34:59 ken: I think Jeff would object. Not to represent his opinion, but I think he would. 16:35:16 chrishtr: Great to resolve device-pixel-border-box size makes sense and then follow-up on the other one 16:35:25 chrishtr: To make progress. 16:35:29 ken: Want progress too 16:35:44 astearns: smfr you would rather continue new API discussion or resolve to add it and continue discussion? 16:35:52 smfr: Prefer to fork into separate issue 16:36:14 fantasai: Question, says doing device-pixel-border-box size. What if person wants size of padding or content box? 16:36:50 chrishtr: Those other boxes have use cases and tracked via other issues on the spec 16:36:59 florian: But not at device pixel level the others 16:37:07 chrishtr: No. Only use case for device pixels is canvas 16:37:19 fantasai: But why wouldn't people using canvas want to paint inside the border? 16:37:37 Wouldn't it be the content-box that is important for the canvas? Since that's what they're using in their code? 16:37:37 chrishtr: Canvas has a certain size and border is outside of that. Browser does that for you. 16:37:49 drousso_ has joined #css 16:37:51 fantasai: boder box size includes border so if it's not included it's not a border box 16:38:07 chrishtr: It's the device pixel box size in case of canvas. It's actual size of canvas 16:38:11 drousso has joined #css 16:38:18 fantasai: Then it's the content box and we should call it that and not border box 16:38:20 chrishtr: Right 16:38:21 fantasai, you wanted to ask about padding/content boxes 16:38:27 ken: Sounds good 16:38:39 astearns: Other discussion? 16:38:43 fantasai: Summary of proposal? 16:38:54 astearns: Add an API to get canvas height and width to resizeObserver 16:39:13 chrishtr: Actual device width and height of the canvas. When changes resizeObserver fires. 16:39:36 fantasai: I want to be clear. Adding and API which is only available on canavas element. Reflects pixel size of content box of canvas element 16:39:47 fantasai: And it has a name that is not device-pixel-border-box 16:39:49 chrishtr: Yes 16:40:02 smfr: Available for any element you resizeObserve not jsut canvas 16:40:14 fantasai: Have had various discussion on only canvas or all and want to be clear 16:40:23 chrishtr: Only use case I know is canvas. Could do it for all 16:40:37 smfr: I wonder if this should be something the user of the API request. 16:40:48 chrishtr: For any API you ask for what you want and you're saying only available on canvas? 16:40:59 smfr: ONly want browser to do computation if author asks for data 16:41:25 chrishtr: For sure. Part of draft spec to observe multiple types of boxes. You say what to observe. I agree browser should only do this if needed 16:41:39 astearns: Further question of if someone requests this on not canvas what happens 16:41:55 chrishtr: Allow or not allow is both okay. In terms of APIs implicity maybe better on all 16:42:05 smfr: Can imagine on something like video. Better on all 16:42:15 chrishtr: No impl difficulty from allowing it 16:42:40 fantasai: Add API to get content box height and width in device pixel sizes to resize observer. ONly return when requested and applies to all. 16:42:45 chrishtr: Can bikeshed name 16:43:21 florian: Not obj, but want to be cautios on all elements. pixels vs device pixels people can get confused about and I have mild concern making this too easily available people will try and use it. 16:43:50 astearns: A lot of things discussing now should be separate issues once we have draft text in place. 16:44:00 astearns: objections to adding this? 16:44:08 RESOLVED: Add API to get content box height and width in device pixel sizes to resize observer. Only return when requested and applies to all element. 16:44:13 astearns: Thanks chrishtr 16:44:19 chrishtr: I appriciate all the feedback 16:44:24 ken: Thanks for discussion 16:44:49 fantasai: Want to discuss optionality 16:44:52 astearns: Add an issue for that 16:45:01 TOpic: Should automatic list-item increment adjust for ol[reversed]? 16:45:09 github: https://github.com/w3c/csswg-drafts/issues/4181 16:45:12 https://github.com/w3c/csswg-drafts/issues/4181#issuecomment-522196318 16:45:17 fantasai: Where we are is in this comment ^ 16:45:24 fantasai: Given TabAtkins isn't here maybe not now 16:45:28 github: none 16:45:36 Topic: Allow breaking anywhere when dictionary is missing for SEA scripts 16:45:43 github: https://github.com/w3c/csswg-drafts/issues/4284 16:46:47 fantasai: Certain lang where breakpoint not obvious from character code. hvae to do analysis. If you do not have the dictionary or rules in the engine you don't break the text and it'll be long and overflow. I suggest saying if you don't know how to break then you should break somewhere. Doesn't matter where but between grapheme clusters. hvae to have break opportunities 16:46:56 myles: Did you mean must? 16:46:59 fantasai: Yeah 16:47:24 fantasai: Proposal to add that. Discussion in issue about where to break in languages, but this is about what to happen when UA doens't have rules. 16:47:59 florian: I think saying you must break somewhre and not middle of grapheme cluster. If you can do mid analysis with meaningful unit of breaking do that. But must break and not break grapheme closters 16:48:08 myles: How does browser know which scripts? 16:48:18 fantasai: THere's a classification, let me see. 16:48:23 http://unicode.org/reports/tr14/#SA 16:48:43 fantasai: Class SA is complex context dependant. If you're one of these scripts and don't have a resource to tell you where to break you should break somewhere 16:48:54 myles: As long as spec says that this is fine 16:48:57 fantasai: Okay 16:49:10 astearns: Other concerns? 16:49:45 fantasai: Prop: If there is a language for which you do not know the breaking rules. Rather then treating as unbreakable you treat it as breakable anywhere 16:49:57 astearns: And something about not breaking through grapheme cluster? 16:50:11 fantasai: Yes. If we copy from overflow: anywhere that comes 16:50:32 RESOLVED: f there is a language for which you do not know the breaking rules. Rather then treating as unbreakable you treat it as breakable anywhere similar to overflow:anywhere 16:50:49 Topic: `grid-template-rows/columns` Computed / Resolved Values for 'subgrid' values 16:50:55 https://github.com/w3c/csswg-drafts/issues/4362 16:51:01 github: https://github.com/w3c/csswg-drafts/issues/4362 16:51:08 fantasai: Just accept Mats proposal 16:51:17 astearns: Opinions? 16:51:28 Rossen_: Wish I had time to read it. 16:51:40 Rossen_: This doesn't sound like something needed right now. Resolve next week? 16:52:02 jensimmons: Can fantasai explain and then Rossen_ you can feel you understand? I don't want to postpone because we're trying to ship subgrid 16:52:59 fantasai: Issues is when getting resolved value, value from gCS, what that value is not well defined. Regular grids resolved value expands all repititions so you have number of tracks/columns. Mats proposal is same for subgrid but don't include length b/c that's not valid value. 16:53:11 fantasai: You would say subgrid and then a list of all the line names. 16:53:19 fantasai: Example in the bottom makes it clear 16:53:41 Rossen_: In this way it will be...subgrid columns will be serialized as part of grid col? 16:54:02 fantasai: grid-template-columns is property, subgrid keyword. Optional line names which are matched up. Can use repeat notation 16:54:25 Rossen_: Grid-template-columns would resolve to what he suggests in very last sentence? 16:54:30 Rossen_: Is that the expected behavior? 16:54:32 fantasai: Yeah 16:54:59 fantasai: WE do the same thing as for regular grids, but we don't specify sizes in resolved value. Otherwise same rules for expanding repetitions 16:55:42 Rossen_: Going through examples to figure out if it's lossy for what you can reconstruct 16:56:07 fantasai: It is lossy in same way as current without subgrid. We return resolved style, not computed. 16:56:21 Rossen_: I'm trying to figure out if it's more lossy, but seems about same 16:56:23 fantasai: Yeah 16:56:29 Rossen_: Doesn't sound bad 16:56:50 fantasai: Alternatives is to fill in all sizes, but then can't read it back in. Want it to roundtrip 16:56:52 Rossen_: Agree 16:57:06 fantasai: Other is to not unwrap but that's inconsistent with regular grids. 16:57:22 Rossen_: Yeah. That would have been my pref but we are where we are. 16:57:51 Rossen_: This seems consistent. Not opposed 16:58:14 astearns: Prop: Accept Mats' suggestion which preserves consistency with the rest of grid but allows subgrid values to roundtrip 16:58:59 fantasai: Prop: Accept Mat's proposal which is that resolved value unwraps repeat notations and does not insert track sizes for subgrid 16:59:08 astearns: Objections? 16:59:13 RESOLVED: Accept Mat's proposal which is that resolved value unwraps repeat notations and does not insert track sizes for subgrid 16:59:32 Topic: publication 16:59:42 fantasai: Related topic, this is only issue on subgrid. I suggest we go to CR in the next week or two. 16:59:45 Rossen_: Yay! 16:59:50 astearns: Alright, fair warning. 16:59:55 Topic: end 17:00:04 astearns: Thanks everyone for calling in. 17:00:18 ya subgrid let's ship it! 17:00:27 anyone else? webkit? chromium?? 17:00:32 ship it! 17:07:13 Karen has joined #css 17:08:05 drousso_ has joined #css 17:08:42 drousso has joined #css 17:33:43 bradk has joined #css 17:36:28 drousso has joined #css 17:57:07 dholbert has joined #css 18:48:29 innovati has joined #css 18:55:16 Zakim has left #css 18:59:44 trackbot, end meeting 18:59:44 Zakim, list attendees 18:59:52 RRSAgent, please draft minutes 18:59:52 I have made the request to generate https://www.w3.org/2019/10/09-css-minutes.html trackbot 18:59:53 RRSAgent, bye 18:59:53 I see no action items