23:49:29 RRSAgent has joined #css 23:49:29 logging to https://www.w3.org/2019/09/15-css-irc 23:49:31 RRSAgent, make logs public 23:49:31 Zakim has joined #css 23:49:33 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 23:49:33 Date: 15 September 2019 23:49:37 rrsagent, this meeting spans midnight 23:51:39 xfq_ has joined #css 23:53:53 prushforth has joined #css 23:54:52 smfr has joined #css 23:58:05 drousso has joined #css 00:01:25 Rossen_ has joined #css 00:01:35 trackbot, start meeting 00:01:38 RRSAgent, make logs public 00:01:41 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 00:01:41 Date: 16 September 2019 00:01:44 Rossen_ has changed the topic to: TPAC 2019, day 1 00:04:20 stantonm has joined #css 00:05:25 skk has joined #css 00:11:57 myles has joined #css 00:12:04 present+ myles 00:12:26 present+ leaverou 00:12:36 present+ 00:13:17 cmp has joined #css 00:13:26 present+ 00:13:37 futhark has joined #css 00:14:06 present+ 00:14:19 present+ 00:14:22 present+ 00:14:53 present+ Florian Rivoal, Invited Expert 00:15:08 present+ 00:15:09 present+ 00:15:12 present+ 00:15:27 present+ 00:15:35 present+ 00:15:43 dino has joined #css 00:15:47 present+ 00:16:06 present+ 00:16:15 kzms2 has joined #css 00:16:19 present+ 00:16:25 Rossen Atanassov, Microsoft 00:16:30 bkardell_ has joined #css 00:16:30 present+ 00:16:30 Alan Stearns, Adobe 00:16:35 Oriol Brufau, Igalia 00:16:36 present+ 00:16:41 present+ 00:16:43 Peter Linss, Invited Expert 00:16:45 L. David Baron, Mozilla 00:16:45 Stanton Marcum, Amazon 00:16:48 present+ Simon Sapin, Mozilla 00:16:48 Hiroshi Sakakibara, Beyond Perspective Solutions(BPS) 00:16:51 Brian Birtles, Invited Expert 00:16:52 Cameron McCormack, Mozilla 00:16:58 Markus Stange, Mozilla 00:17:11 Dirk Schulze, Adobe 00:17:13 Emilio Cobos, Mozilla 00:17:18 cathiechen has joined #css 00:17:21 Emil A Eklund, Google 00:17:23 Dominik Röttsches, Google 00:17:23 Rune Lillesveen, Google 00:17:28 nmccully_ has joined #css 00:17:29 Koji Ishii, Google 00:17:39 zcorpan has joined #css 00:17:43 Myles C. Maxfield, Apple 00:17:43 Christian Biesinger, Google 00:18:10 Elika Etemad, Invited Expert 00:18:11 Nat McCully, Adobe 00:18:12 atotic has joined #css 00:18:13 present+ Rachel Andrew, Fronteers 00:18:20 mattwoodrow has joined #css 00:18:29 Fuqiao Xue, W3C 00:18:29 present+ Aleks Totic, Google 00:18:31 Matt Woodrow, Mozilla 00:18:34 Chase Phillips, Google 00:18:35 Jihye Hong. LGE 00:18:38 present+ 00:18:39 present+ Brian Kardell, Igalia and Open JS Foundation 00:18:42 present+ 00:18:46 Devin Rousso, Apple 00:18:46 present+ 00:18:50 present+ 00:18:51 ScribeNick: fantasai 00:18:55 Topic: F2F Scheduling 00:18:56 present+ 00:18:58 present+ 00:19:31 Rossen_: January is already in the books 00:19:37 Rossen_: Jan 22-24 hosted by Igalia 00:19:44 AmeliaBR has joined #css 00:20:08 fantasai: Should we resolve on Rego's suggestion to run 10-7pm? 00:20:11 present+ 00:20:19 cathiechen_ has joined #css 00:20:31 Amelia Bellamy-Royds, invited expert 00:20:37 ekashida has joined #css 00:20:42 florian: Reason was local schedules, restaurants don't open until 8/8:30pm 00:20:46 RESOLVED: Igalia meeting is 10-7 00:21:03 Rossen_: Dates from Apple? 00:21:13 Peter Rushforth, Natural Resources Canada, Invited Expert, Observer 00:21:15 astearns: Tess said she's trying to reserve April 27-30 00:21:24 astearns: Don't have an update on if she succeeded 00:22:01 Rossen_: Just want to try to sort it out asap, so people who are on tight schedules can finish their scheduling for the spring 00:22:08 skk: Will there be a Houdini meeting? 00:22:10 Rossen_: Not in April 00:22:19 Eugene Kashida, Salesforce, Observer 00:22:22 Rossen_: Possible Summer locations are Kyoto, France, NYC 00:22:27 s/Not in April/Not in Spain, in April there will be one/ 00:22:31 Rossen_: Anyone up for sponsoring F2F meeting? 00:22:56 florian: France is a misunderstanding, can't offer to host in France, but can host in Kyoto but not in July+August 00:23:28 Rossen_: NYC would put two consecutive in USA 00:23:34 astearns: Maybe. April might be in Ireland 00:23:58 Rossen_: So looking at July 20-24 or July 27-31, last two weeks of July 00:24:26 dbaron: That is not the idea for Japan, not only because it's warm but also Tokyo Olympics are then 00:25:01 s/idea/ideal time/ 00:25:10 hober: I have dates! 00:25:20 hober: Did we want to have Houdini, also? 00:25:26 hober: I have three days confirmed, 4th not confirmed yet 00:25:39 hober: Booked for Monday 27 April - 29, in Cork, Ireland 00:26:09 Rossen_: Sounds great 00:26:52 RESOLVED: CSSWG meeting Monday 27 April 2020 - Wed 29 April 2020, Houdini afterward (pending booking confirmation) 00:27:04 Rossen_: Back to summer 00:27:13 Rossen_: Who was offering to host in NYC? 00:27:26 dbaron: Think it was Una (Google) 00:27:34 TabAtkins: We can probably do it 00:27:56 Rossen_: Ok, check about it and let us know 00:28:12 TENTATIVE: End of July 2020 in NYC 00:28:36 Topic: CSS Contain 00:28:52 Rossen_: Proposed to publish a PR of CSS Contain 1 00:29:05 florian: Afaict, it's complete 00:29:16 florian: All tests pass in 2 browsers, except those which depend on other less-mature specs 00:29:21 florian: So I think we are ready for PR 00:29:32 florian: One more note, all tests pass if we don't count the at-risk feature 00:29:35 https://drafts.csswg.org/css-contain/issues-2019-cr.html 00:29:39 florian: the style containment is not implemented properly anywhere 00:29:46 florian: but that's why we marked it at risk 00:29:48 https://drafts.csswg.org/css-contain/implementation-report-2019-09 00:29:56 https://drafts.csswg.org/css-contain/annotated-2019-09-05.html 00:30:03 florian: so my request is to drop it, go to PR, and publish FPWD of Level 2 which just contains that feature 00:30:05 https://github.com/w3c/csswg-drafts/labels/css-contain-1 00:30:12 https://drafts.csswg.org/css-contain-1/ 00:30:19 Rossen_: So PR version will have 3.3 dropped for Level 1 00:30:31 Rossen_: Objections on resolving to publish PR of CSS Contain 1 with dropped section? 00:30:40 xiaochengh has joined #css 00:30:48 dbaron: Is the state of style containment that implementations are shipping support and not passing tests, or not shipping support? 00:30:58 eae: Combination of both 00:31:14 florian: Chrome ships a buggy one, and Gecko doesn't ship iirc 00:31:19 heycam: We don't recognize the value 00:31:29 smfr: Are the two implementations blink and gecko? 00:31:30 florian: Yes 00:31:46 Rossen_: Hearing no objections, 00:32:06 zcorpan has joined #css 00:32:11 RESOLVED: PR of css-contain-1, dropping style containment (at-risk) 00:32:32 florian: For Level 2 00:32:51 florian: if we add new features, need fpwd, but if not adding a new feature can go directly to CR 00:33:02 Topic: Contain Size 00:33:08 explainer: https://github.com/WICG/display-locking/blob/master/explainer-content-size.md 00:33:14 chrishtr: Posted a new explainer 00:33:20 s/Contain Size/content-size/ 00:33:21 chrishtr: content-size is a new CSS property 00:33:39 chrishtr: If 'contain: size' is specified, content-size is treated as intrinsic size of contents 00:34:00 chrishtr: proposing that be able to set intrinsic width/height passed to intrinsic sizing algorithms 00:34:16 chrishtr: Reason we believe it's useful is that you can use it when a subtree is not yet ready or you don't want it to have its own layout 00:34:20 chrishtr: can express a placeholder sizing for it 00:34:34 chrishtr: Allows communicating that placeholder sizing, so that flex/grid/table/etc can take that into account 00:34:41 github: https://github.com/w3c/csswg-drafts/issues/4229 00:34:50 chrishtr: If we've skipped rendering as an optimization, dev can use to communicate placeholder sizing 00:34:58 SimonSapin: Would this property apply without 'contain'? 00:35:07 a? 00:35:08 chrishtr: When you don't have 'contain: size', no 00:35:09 q? 00:35:16 q+ 00:35:28 chrishtr: Only applies when 'contain: size'. Reason is that 'contain: size' causes no competing intrinsic size 00:35:42 chrishtr: 2nd reason is that it fits neatly with render subtree attribute proposal 00:35:57 florian: Can you expand on the second point? I'm not faimilar with that 00:36:15 florian: In isolation proposition makes sense, but not sure why it's not coupled with a more generic intrinsic size feature 00:36:40 TabAtkins: One reason was that, as chrishtr said, that means you have competing information. We don't think that's useful to have two sources of truth there 00:36:53 TabAtkins: Seems like only time you need to provide a better intrinsic size is when you're contain sizing already 00:36:56 dbaron: I'm skeptical of that 00:37:13 dbaron: I think there are a bunch of cases, where intrinsic sizing doesn't provide good results and devs might wnat to provide it 00:37:20 dbaron: Talked about some o those cases in the past 00:37:25 dbaron: Some cases devs want to override only in one dimension 00:37:32 TabAtkins: Bad behavior of intrins scorllers maybe? 00:37:37 TabAtkins: flexboxes blowing up 00:37:41 dbaron: Didn't have that in my head, but sure 00:37:45 TabAtkins: That's intriguing 00:37:54 rakina has joined #css 00:38:02 AmeliaBR: Also cases we've had where certain modes cause things to collapse down to zero, and might be better not to 00:38:09 AmeliaBR: Lots of cases there might be a demand for it 00:38:24 AmeliaBR: Wrt naming, 'content-size' might be interepreted as size of content-box 00:38:34 chris has joined #css 00:38:37 AmeliaBR: If there is a limitation, tho, should be good reasons for it 00:38:41 present+ 00:38:45 TabAtkins: Yes, happy to come up with better name 00:38:52 q? 00:39:05 rrsagent, here 00:39:05 See https://www.w3.org/2019/09/15-css-irc#T00-39-05 00:39:07 TabAtkins: Cases that fantasai and I identified where boxes get too big in intrinsic sizing, and currently don't have a way to opt into better behavior 00:39:07 ack me 00:39:21 TabAtkins: In some cases can inflate itnrinsic size, others might be able to shrink 00:39:29 TabAtkins: good idea 00:39:48 ack fantasai 00:39:52 present+ 00:40:02 fantasai: Support florian and dbaron , this should probably be a generic mechanism 00:40:14 fantasai: the value space would be legacy | auto | 00:40:28 ???: what is the diff between legacy and auto 00:40:35 s/???/cbiesinger/ 00:40:45 fantasai: scrollers collapsing to 0 or not 00:41:46 fantasai: if inside a flex item, there is an overflow:scroll pre element with a very long line, the min-content size is the size of the very long line, that makes the flex item be very large, even though we could just have made it into a scroller 00:42:15 TabAtkins: Semantics are still a bit funky, if you provide a size wouldn't do anything unless you're contain: size 00:42:19 fantasai: Well, I think it would 00:42:31 ack dbaron 00:42:32 dbaron: I would also note that there are cases where intrinsic sizing provids sizes that are too small, e.g. in cases with percents 00:42:32 fremy has joined #css 00:42:47 fantasai: if you specify an explicit size, that takes over and you ignore the content 00:42:59 TabAtkins: Could do that... was wondering if you wanted to max them 00:43:31 AmeliaBR: Doing a max or min doesn't work if we want to accept both use cases of dealing with cases where intrinsic size is too big or too small 00:43:47 AmeliaBR: Just say if you specify a value, you wanted to override 00:43:58 chrishtr: All these examples that were alluded to but not explicit, please write into issue 00:44:16 fantasai: Based on discussion, this doesn't go into contain, goes into Sizing level 4 00:44:19 fantasai: based on this discussion, this goes into sizing-4, not contain-2 00:44:32 Rossen_: Anything else on this topic 00:44:41 TabAtkins: Discussion was good 00:44:53 chrishtr: Point Florian raised about, what are you talking about wrt render subtree 00:44:57 chrishtr: maybe wait until we talk about that 00:45:07 chrishtr: but 5min background on render subtree, though it's on the HTML spec 00:45:18 chrishtr: package, how they fit together matters, so just want to mention 00:45:23 tantek has joined #css 00:45:25 Rossen_: we can put that topic next 00:45:37 chrishtr: Just want to give an overview of what it is, what use csaes are, how it functions 00:45:46 chrishtr: so can get some feedback 00:46:40 Rossen_: So content-size, or whatever we're going to call it, will go to size level 4 00:46:42 present+ 00:46:46 Rossen_: Any objections to add it? 00:47:01 Explainer that contains rendersubtree: https://github.com/WICG/display-locking/blob/master/README.md 00:47:03 TabAtkins: maybe call it intrinsic-size 00:47:07 Dongwoo has joined #css 00:47:07 fantasai: Nobody wants to spell that 00:47:09 TabAtkins: true 00:47:47 fantasai: There was a suggestion that this be split into width/height not one property for both dimensions 00:48:24 fantasai: Seems to be the proposal is foo-width/height/inline-size/block-size 00:48:30 iank_: legacy as initial value? 00:48:56 PROPOSAL: Add proxy-width/height/inline-size/block-size with values legacy | auto | 00:49:03 RESOLVED: Add proxy-width/height/inline-size/block-size with values legacy | auto | 00:49:13 Topic: Contain level 2 00:49:23 florian: We could go CR directly, but we might want to change things so maybe fpwd is better 00:49:35 florian: some suggestions, e.g. single-axis contain, etc. 00:49:41 florian: might want to add 00:50:03 RESOLVED: FPWD css-contain-2 being copy of css-contain-1 (including at-risk features) 00:50:17 Topic: Render subtree 00:50:26 chrishtr: I posted alink to an explainer earlier 00:50:34 Explainer that contains rendersubtree: https://github.com/WICG/display-locking/blob/master/README.md 00:50:42 https://github.com/whatwg/html/pull/4862 00:50:52 chrishtr: PR for spec idea 00:51:00 glenn has joined #css 00:51:05 chrishtr: render-subtree attribute is an attr you can put on any HTML or SVG element 00:51:17 chrishtr:Has one or more keywords that are space-separated 00:51:17 ... or mathml? 00:51:22 chrishtr: ex. rendersubtree=invisible 00:51:30 chrishtr: what that means is that it is invisible, but takes up layout space 00:51:38 HeWenli_ has joined #css 00:51:41 chrishtr: and also is designed so that UA doesn't need to do any render work for that subtree 00:51:50 chrishtr: no heuristics to figure out whether needs to render that subtree 00:51:53 chrishtr: you load a web page 00:51:58 chrishtr: bunch of content not on screne atm 00:52:04 chrishtr: you like that page to load quickly, not have extra layout cost 00:52:07 chrishtr: not load external resources 00:52:10 chrishtr: etc. 00:52:15 chrishtr: for stuff that's not on screen right now 00:52:21 chrishtr: common because scrolling is common on web, and large websites 00:52:27 chrishtr: what does attriute do when set to invisible? 00:52:30 inamori_ has joined #css 00:52:42 chrishtr: First, it applies layout, style, and size containment 00:52:54 chrishtr: layout containment is good, content below can't escape layout of the element at the root of the subree 00:52:58 chrishtr: size containment for imilar reasons 00:53:15 chrishtr: dont' need to know layout to compute layout of the page 00:53:23 chrishtr: so don't need to do layout, don't need to paint it, 00:53:27 chrishtr: not painted to screen and not hit-testable 00:53:32 q+ 00:53:35 chrishtr: so don't need to do any work as UA to process that DOM subtree 00:53:39 chrishtr: is present, but doesn't cause any work 00:53:51 chrishtr: that's the core value-add of the 'rendersubtree=invisible' 00:53:55 chrishtr: Other value syou can add 00:54:21 chrishtr: If you say that rendersubrree is invislbe and activatable, what that means is that UA is allowed to mutate that attriute to be empty string 00:54:24 chrishtr: to render the content 00:54:30 chrishtr: e.g. wikipedia, stuff below the fold 00:54:42 chrishtr: wikipedia markes as activatable 00:54:45 chrishtr: and invisible 00:54:55 chrishtr: when user or a11y API wants to look at that content 00:54:57 q+ 00:55:03 chrishtr: or user wants to do find-in-page operation 00:55:11 chrishtr: and UA notices the content is below the fold off-screen content 00:55:18 browser would be able to cause the content to rnder 00:55:23 chrishtr: which has effect of causing it to render 00:55:31 chrishtr: and script can observe the mutation of the attribute through a mutation observer 00:55:32 q+ 00:55:36 chrishtr: takes some action to help 00:55:45 chrishtr: or in simplest cases, content is just rendered 00:55:54 q+ difference with 'display: none'? 00:55:58 chrishtr: important because lots of UA algorithms not controlled by authro 00:56:06 chrishtr: e.g. a11y, anchor link navigation, tabbing between focusable elements 00:56:13 chrishtr: scroll-int-view operation, find-in-page 00:56:16 q+ 00:56:20 chrishtr: finally, two additional keywords 00:56:25 chrishtr: one prevents external resources from being loaded 00:56:39 ack diff 00:56:39 chrishtr: image wouldn't be loaded until whole-loads keyword is removed 00:56:44 ack with 00:56:48 chrishtr: avoids blocking network pipeline for stuff below the fold 00:56:49 q+ 00:56:50 ack 'dis 00:56:55 ack none 00:57:01 chrishtr: useful for feeds of info like fb, twitter, also for page with lots of images off-screen 00:57:17 chrishtr: This is a lazyloading feature similar to what chromim is trying to ship 00:57:18 inamori_ has joined #css 00:57:23 chrishtr: Finally, web component ?? 00:57:29 chrishtr: if you have custom elements defined in your registry, 00:57:36 chrishtr: if element was registered, runs create callback 00:57:45 chrishtr: allows dev script to participate in rendering the custom elements 00:57:51 chrishtr: but if elements are off-screen, then cost isn't desirable 00:57:57 chrishtr: dev would prefer not to run script until content is on-screen 00:57:59 duga has joined #css 00:58:02 s/??/element upgrades/ 00:58:10 chrishtr: way this fits in with content-size is that if you set the render subtree attribute to 'invisible' 00:58:13 chrishtr: has containment 00:58:22 chrishtr: therefore content-size would take over sizing of unrendered content 00:58:43 chrishtr: this way, when content is subsequently rendered via UA action or dev activation 00:58:48 chrishtr: layout doesn't jump around 00:58:57 chrishtr: contain: size is only applied when invisible 00:59:10 bobbytung has joined #css 00:59:15 chrishtr: when not invisible, then it will no longer have 'contain-size', automatically uses actual size 00:59:25 q+ 00:59:37 chrishtr: intrinsic size without size containment might be compelling enough to drop this connection, but that's what we were thinking 00:59:41 chrishtr: 00:59:49 dauwhe has joined #css 00:59:52 chrishtr: 'display: none' doesn't help for off-screen content because idoesn't take up layout space 01:00:11 chrishtr: 'visibility: hidden' doesn't stop layout, and also can be overridden by descendants, so have to render through the subtree 01:00:28 Rossen_: 'display: none' + 'contain: size" 01:00:32 chrishtr: display: none box is gone 01:00:41 chrishtr: rendersubtree=invisible, the box is still there, only its contents are gone 01:00:54 chrishtr: you could have e.g. a spinner erndered in the elemetn, or a pseudo-element, but don't actually render the subtree 01:01:06 q? 01:01:20 ack smfr 01:01:23 BoCupp has joined #css 01:01:44 smfr: What's the behavior when element with visible subtree changes to invisible 01:01:54 chrishtr: if you just addd 'rendersutreeinvisble' to element 01:02:03 chrishtr: it'll apply contain: style layout size 01:02:07 chrishtr: and not render the contents 01:02:12 chrishtr: but element itself will still read 01:02:21 s/addd 'rendersutreeinvisble'/add `rendersubtree="invisible"`/ 01:02:24 chrishtr:script can still read style, could cause layout thrashing 01:02:37 smfr: so toggle from visible to invisible, ... 01:02:43 smfr: does it give you a stale value? 01:02:51 chrishtr: Will do the work to get you the right value 01:02:57 chrishtr: doesn't cause it to render, but has to do calculations 01:03:01 smfr: seems a bit magic, like a hack 01:03:14 q+ 01:03:22 smfr: seems like maybe it should be a CSS value, e.g. new keyword to 'visibility'? 01:03:26 q+ 01:03:34 chrishtr: if it was a CSS property, would be weird if UA overrides it 01:03:45 chrishtr: but made attriute so UA can remove automatically 01:03:53 smfr: Worried about circularity about activatable 01:03:57 smfr: e.g. user hits Cmd+F to start a find 01:04:10 smfr: I thin kyou have to bring in the subtree in order to search it 01:04:18 smfr: because have to check 'display: none' 01:04:27 chrishtr: Don't have to show on scren, but have to compute style 01:04:35 smfr: activatable has side-effect of removing the attriute? 01:04:44 Zakim, close queue 01:04:44 ok, Rossen_, the speaker queue is closed 01:04:46 q- because smfr just expressed my concern about find-in-page requiring style information 01:04:48 chrishtr: If you try find in page, UA will do the work necessary to compute the disply: none part of pipeline 01:04:50 q- 01:04:55 chrishtr: if it matches query, would activate the subtree 01:05:05 smfr: Worried there are some things that are not specified that end up affecting the activation behavior 01:05:21 smfr: Spec says activation depens on UA behaviors, different browsers iwll have different activation policies if we don't standardize 01:05:33 chrishtr: explainer lists which actions cause activation 01:05:56 chrishtr: scrolling doesn't, JS scrollIntoView does, a11y access does 01:06:09 Rossen_: We have built up quite a queue 01:07:10 ack florian 01:07:12 florian: Maybe I missed something, one part I'm confused about 01:07:13 florian: what' 01:07:22 dauwhe has joined #css 01:07:24 florian: what's the use case for invisible without activation? 01:07:35 florian: I think author will probably miss some important cases if it's not activatable 01:07:48 florian: Also, feels like it's something like a delayed or sync value for visibility 01:07:51 tomalec has joined #css 01:07:56 florian: you're allowed to delay, but once on screen please show 01:08:03 florian: most enefits when combined with contain, 01:08:10 florian: but conceptually could be separate 01:08:16 florian: you're allowed to load the assets later 01:08:25 florian: wouldn't need to override the value, just permission to do it later 01:08:32 florian: maybe that covers requiremtn for running scripts? 01:08:42 florian: rest feels like it could be in CSS somehwere along the lines that smfr was talking about 01:08:49 florian: would like to also know why have a version that's not activatable 01:09:03 chrishtr: Suppose youhave content that is not fully loaded, don't want to show to user. That's why you don't want it to be activatable 01:09:20 chrishtr: wouldn't be visibility: hidden because not performant, layout subtree still applies 01:09:44 myles: if you wnat to leave space for it, you can set visibility: hidden for it, will leave space 01:09:51 myles: if you do want the pop, can set display: none 01:10:04 florian: would combine visibility hidden with contain, to reduce jank 01:10:17 TabAtkins: will have jumping because the content hasn't loaded either 01:10:24 florian: but would use 'contain' and 'content-size' as well 01:10:28 florian: why needs an HTML attribute 01:10:36 TabAtkins: Doesn't allow us to not do layout 01:10:48 TabAtkins: which is a problem if wanting to load 10,000 nodes worht of content 01:11:09 florian: so would want 'visibibity: ...', whic would allow delaying 01:11:21 q? 01:11:23 TabAtkins: recall reason chrishtr just said aobut having invisible but not activatable 01:11:32 TabAtkins: element is in state where it's waiting for stuff to load 01:11:42 TabAtkins: dont' want to allow activation until finished 01:11:45 ack Ame 01:11:45 ack AmeliaBR 01:11:50 AmeliaBR: had same question 01:12:09 AmeliaBR: but final comment, might want to consider making activatable the default 01:12:28 AmeliaBR: authors might *think* they know when to activate, but haven't considered things through very well 01:12:47 AmeliaBR: so suggest to make default acticvatable, author has to explicitly request non-activatable 01:13:02 myles: might be problematic to have elements callback in unpredictable order? 01:13:09 e.g. `inert` version for non-activatable 01:13:18 chrishtr: Can use this feature to automatically activate content which is below the fold, or not even actually visible 01:13:27 chrishtr: e.g. tabbed UI or content hidden behind a ? that can be opened by the user 01:13:31 chrishtr: e.g. details element 01:13:38 chrishtr: still want user to be able to find that content and navigate to it 01:13:40 plh has joined #css 01:13:42 chrishtr: currently, that's not really possible 01:13:53 chrishtr: e.g. yu have content in anotehr tab of the ui, or subwidget 01:14:01 chrishtr: nm, nother reason for activation 01:14:16 ack hey 01:14:16 ack heycam 01:14:17 heycam: two things: one, want to echo what smfr said 01:14:28 heycam: I feel like behavior when subtree isn't rendered seems like CSS kind of feature 01:14:38 heycam: recognize that overriding the style value of some property doesn't feel great 01:14:51 heycam: but otherwise feels like some new 'display' value, like 'display: placeholder' which only generates frame and not contents 01:15:13 heycam: Some kind fo solution where it's somehow reflected in CSS property dispaly would be nice 01:15:20 heycam: 2nd point was about automatic avtivation behavior 01:15:30 sanketj has joined #css 01:15:38 heycam: have you consiered solution where you have strict callbacks for events for these types of activation behaviors? 01:15:50 heycam: so dev can choose to catch events and decide whether to flip activation 01:16:02 chrishtr: So suggesting that script shoudl be able to observe activation 01:16:08 heycam: wonderign if that's a design that you've considered 01:16:11 chrishtr: did consider that design 01:16:16 chrishtr: and prototyped in chromium 01:16:27 chrishtr: the event fo this, which we calle dactivate event, was in psec proposal 01:16:32 chrishtr: but makes sense and is convenient to add 01:16:39 chrishtr: technically can be implemented with mutation observer, but might be inconvenient 01:16:53 heycam: one advantage of that might be that you could then have a new display proeprty value that does the actual work of that 01:17:03 heycam: and let the author change the value of that property 01:17:14 q+ 01:17:20 chrishtr: so tell dev that "i would liek to activate this, please help me out" 01:17:24 chrishtr: problem is defautl behavior is not good 01:17:37 heycam: author specifying 'display: placeholder', on you to complete the solution 01:18:00 chrishtr: comments about flipping default activation, should make it easy as possible to adopt feature without unintentionally breaking accessibility 01:18:12 TabAtkins: copy-paste two-line activation script on every page that uses this feature 01:18:19 TabAtkins: that's not so great 01:18:47 TabAtkins: If they dont' want it to activate, they can use the don't activate value, and have that work as intended automatically 01:19:08 TabAtkins: back to display values, while I wouldn't fight too hard if we decided to add a display subproperty 01:19:28 TabAtkins: but doing non-typed things in 'display' itself is problematic because lose typing 01:19:32 TabAtkins: this is really bad 01:19:42 chrishtr: want UA to be able to activate for you 01:19:44 q? 01:19:44 s/non-/none-/ 01:20:02 chrishtr: with recent testing with partners etc, does seem to be a use case for controlling things with a style sheet 01:20:12 chrishtr: sometimes convenient to do via CSS 01:20:20 @chrishtr: added some notes over here: https://github.com/WICG/display-locking/issues/78 01:20:22 ack fantasai 01:20:23 aka you can't set "display:flex" on the element without paying a *lot* of attention to specificity, or else you'll accidentally override the hide-contents value 01:20:37 fantasai: same concern as amelia about making the activatable version the default 01:21:01 fantasai: It would also be good to have the attribute map to some css construct, instead of having the HTML do its own magic 01:21:03 chrishtr: Less magical means harder to cleanly spec, and some use cases are lost 01:21:13 myles: see readme and whatwg pull request, how do I comment? 01:21:25 chrishtr: I think the pull request ahs a correspondign issue in whatwg, good place to ask questions 01:21:54 s/amelia/AmeliaBR/ 01:21:56 SimonSapin: similar to 'display: none', but different in that only contents are hidden 01:22:05 SimonSapin: how is this different from 'display: none' on children? 01:22:15 TabAtkins: Text content that are direct children can't be styled 01:22:23 plh_ has joined #css 01:22:27 TabAtkins: but also 'display: none' implies a lot of things 01:22:34 Rossen_: animations, do they run on your subtree? 01:22:39 chrishtr: no 01:22:45 Rossen_: so that's also same as display: none 01:22:53 chrishtr: Subtree boxes do have CSS boxes 01:22:59 flackr has joined #css 01:23:02 chrishtr: conceptually are laid out, just don't need to do work unless forced by script 01:23:09 q? 01:23:16 ack SimonSapin 01:23:19 ack mattwoodrow 01:23:34 mattwoodrow: what si additional contstraint that we get over 'contain: all' 01:23:42 mattwoodrow: couldn't UA optimize by not rendering anyway? 01:23:46 chrishtr: it's an explicit API 01:23:53 chrishtr: rather than combo of CSS values 01:24:05 TabAtkins: off-screen 'contain', animations still run 01:24:16 TabAtkins: You will fall down accidentaly perf cliffs 01:24:22 mattwoodrow: so it will block animations? 01:24:25 TabAtkins: among other things, yes 01:24:28 ack bkardell_ 01:24:43 bkardell_: I could be misreading this and not understanding, but sounds like the intent is for the UA to actually change the attribute? 01:24:46 chrishtr: yes 01:24:50 bkardell_: is there a precedent for doing that? 01:24:53 TabAtkins: there's one precedent 01:25:04 bkardell_: think there's been 1000 times that's been suggested, and push to not do that 01:25:08 TabAtkins: one precedent, details 01:25:22 TabAtkins: for similar reason to details, nice thing about directly manipulating attribute than a hidden state 01:25:30 TabAtkins: don't need to expose a new way to report actual value 01:25:40 TabAtkins: and don't need to expose to CSS using custom selector 01:25:44 TabAtkins: just use regular attribute selector 01:25:55 TabAtkins: as long as attribute value is easy enough to work with, and this one will be simple, 01:26:07 TabAtkins: there are usability benefits that come with this for free 01:26:14 cbiesinger: value attribute of input? 01:26:17 TabAtkins: those don't change 01:26:29 Rossen_: OK, thanks for introducing topic, chrishtr ! 01:26:37 Rossen_: ppl wanting to participate, please do so at links provided 01:26:58
01:27:57 Issue for rendersubtree: https://github.com/whatwg/html/issues/4861 01:29:07 futhark has joined #css 01:30:49 plh has joined #css 01:34:49 duga has joined #css 01:39:58 ericc has joined #css 01:42:51 jcraig_ has joined #css 01:54:17 mattwoodrow has joined #css 01:57:32 zcorpan has joined #css 01:57:43 drousso has joined #css 01:58:17 dauwhe has joined #css 02:00:25 smfr has joined #css 02:02:49 rakina has joined #css 02:02:51 xfq_ has joined #css 02:04:13 dauwhe has joined #css 02:05:02 xfq_ has joined #css 02:05:29 yigu has joined #css 02:05:30 present+ 02:05:35 Topic: Highlight APIs 02:05:54 xiaochengh has joined #css 02:06:13 Note: break-out session on rendersubtree Wed at 2:30pm?? 02:07:02 sanketj has joined #css 02:07:08 present+ 02:07:14 present+ 02:07:20 futhark has joined #css 02:07:41 futhark_ has joined #css 02:07:42 stantonm has joined #css 02:07:44 https://github.com/w3c/csswg-drafts/issues/4307 02:07:46 sanketj: Want to talk about new propoal about highligh API 02:07:54 sanketj: builds on top of existing css-pseudo-4 spec 02:08:04 Rossen_ has joined #css 02:08:10 sanketj: existing spec allows styling native highlights of the browser: sleection, grammar-error, spelling-error 02:08:13 sanketj: can style how you want 02:08:20 sanketj: this is useful for editing apps 02:08:29 sanketj: implement own selection, spell-check, grammar error 02:08:37 sanketj: currently authors use spans 02:08:42 sanketj: some problems 02:08:52 sanketj: can be complicated, particularly if span across multiple subtrees 02:08:58 sanketj: then adding/removing creats perf problems 02:09:01 sanketj: wrt invalidation etc. 02:09:13 sanketj: users can add/remove highlight using dom ranges 02:09:13 prushforth has joined #css 02:09:20 sanketj: since can span multiple subtrees, easy to code 02:09:31 sanketj: invalidationis only paint invalidation, due to how highlight pseudo elements worok in css-pseudo-4 02:09:39 q? 02:09:44 sanketj: will overview first, then ask for feedback, also some issues 02:09:59 sanketj: iff ppl support concept, would like to move towards official spec 02:10:03 HeWenli has joined #css 02:10:14 sanketj: two key pieces: one is cssom piece, one is a sleector 02:10:20 sanketj: adding two new types: highlightRangeGroup 02:10:28 sanketj: provides a group of ranges to be handled ogether 02:10:36 sanketj: similar to find-in-page, range per instance of term 02:10:41 sanketj: want to style at once 02:10:45 sanketj: so style all together 02:10:55 fremy has joined #css 02:10:56 sanketj: highlightsMap takes a name key and group as a value 02:11:11 sanketj: introducing a global map per document, contaisn all user-defined highlights 02:11:33 sanketj: way user adds a highlighRangeGroup is calling .set, user will give a name and use that as key itno teh map 02:11:40 smfr: user meaning author? 02:11:41 sanketj: yes 02:11:50 leaverou_ has joined #css 02:11:51 sanketj: two properties on highlightRange which are interesting 02:11:57 sanketj: .style property and .? 02:12:02 bobbytung has joined #css 02:12:08 sanketj: connection from highlightsMap to group is important 02:12:13 sanketj: to make it stylable 02:12:19 sanketj: can only style stuff in the highlightMap 02:12:35 sanketj: to style introduces new pseudo, ::highlight(hlight-name) 02:12:43 sanketj: same properties supported as other highlight pseudo elements 02:12:50 sanketj: can also use .style property 02:12:57 sanketj: works just like cascade 02:12:57 q+ 02:13:07 zakim, open queue 02:13:07 ok, astearns, the speaker queue is open 02:13:08 sanketj: inline style wins 02:13:10 q+ 02:13:23 sanketj: multiple highlight range covering same content 02:13:24 q? 02:13:25 q+ 02:13:26 sanketj: example 02:13:39 sanketj: Here we have two overlapping ranges, some text contained in both ranges 02:13:46 sanketj: each in its own hihlightrangegroup 02:13:52 sanketj: one is bg yellow, one is bg orange 02:13:59 HeWenli: what color is the overlap? 02:13:59 futhark has joined #css 02:14:07 sanketj: what is the order? 02:14:12 sanketj: we use the timestamp of addign to the map 02:14:22 sanketj: if author wants to change that, they can set higher priority 02:14:26 sanketj: default priority is zero 02:14:34 sanketj: but can change .priority attribute on the rangegroup 02:14:40 sanketj: that is core pieces of the proposal 02:14:51 sanketj: want to pause and ask for feedback 02:14:57 Rossen_: already have a queue, so let's go through that 02:14:58 q+ 02:14:58 q+ 02:15:00 ack TabAtkins 02:15:04 q+ 02:15:08 q+ 02:15:10 TabAtkins: Question about the reasoning for having ragnegroup isntead of multigroup, but you explained with priorities 02:15:18 TabAtkins: wrt that, is priority 0+ or can be negative? 02:15:21 sanketj: can be negative 02:15:28 sanketj: want to discuss how priority relates to otehr pseudo elements 02:15:36 TabAtkins: any ties, then fall back to timestamp order? 02:15:56 TabAtkins: one more question, is intention that,if took that example calling foo again, would it ahve a newer timestamp 02:16:04 sanketj: no, timestamp is established when first added to the map 02:16:06 q- 02:16:18 plinss: timestamp order same as iteration order of the map? 02:16:20 sanketj: yes 02:16:28 ack florian 02:16:35 Yeah, so that means even setting "foo" with a *different* highlight group would also not change the timestamp. 02:16:36 florian: first comment, really like this, many of us have been thinking of doing something like this for awhile, actually doing it is great 02:16:44 florian: there already is a similar notion of ? for built-in highlights 02:16:54 (Which totally works for me; phrasing it more explicitly as the map iteration order would make me a little happier.) 02:16:57 florian: not only important to say which one wins, but what does it mean to win, which can be different for different things 02:17:08 florian: so important not to re-invent a new solution for custom pseudo than for highlights 02:17:18 florian: and have the resolution be the same mechanism 02:17:27 sanketj: that's one of the issues I wanted to talk about 02:17:33 q? 02:17:39 ack emilio 02:17:51 emilio: few questions, first how does this interact with shadow DOM and general scoping? 02:17:58 emilio: CSS map is global, but rules that apply... 02:18:10 emilio: global ::highlight speudo that spans shadow tree and part of light DOm, what si the style of that? 02:18:17 sanketj: good question 02:18:29 sanketj: as currently specced, you have a range in ShadowDOM and some outside, all styled by global map 02:18:38 emilio: do normal css scoping rules apply? 02:18:40 kurosawa has joined #css 02:18:56 emilio: global parent group, that will apply to non-shadow-dom group, but not shadow dom group 02:19:09 emilio: do you explain how different groups intersecting priority, have to decide 02:19:26 emilio: when you specify some proeprties in some range and not others, do you still apply properites of the other range? 02:19:40 sanketj: you have one group applying bg color and one applying color, overlapping portion gets both of those 02:19:43 emilio: how do you specify that 02:20:01 florian: we have this problem already, and it's specified in css-pseudo-4 02:20:15 florian: because we have same situation with selection/spelling-error/grammar-err 02:20:26 florian: whichever we resolve it, must be same for custom ones and normal ones 02:20:32 q? 02:20:34 q+ 02:20:35 emilio: a bit annoy8ng but fine I guess 02:20:40 q+ 02:20:46 futhark_ has joined #css 02:20:46 ack dauwhe 02:20:54 dauwhe: higher-level question, Web has been struggling with identifying arbitrary ranges of text for a long time 02:21:00 dauwhe: stuff like Web annotations etc. 02:21:09 dauwhe: does this complement those efforts? is it independent of them? how does it relate? 02:21:22 futhark has joined #css 02:21:33 BoCupp: I would say that they are complementary. This doesn't do anything to identify arbitrary text fragments in a URL to idetnfify a range, etc. 02:21:40 BoCupp: some places in DOM you can get a range, some cannot 02:21:55 BoCupp: this is just about applying style over a range 02:21:58 plh_ has joined #css 02:22:08 hober: There is a propsal right night for some kind of find-i-page fragment syntax, and would be useful to talk to those people 02:22:14 Rossen_: who has proposal? 02:22:16 See Fragmentions for existing work on this too: https://indieweb.org/fragmention 02:22:20 hober: willd rop in minutes 02:22:24 deployed on a bunch of sites 02:22:29 atotic: Any restriction on styles you can apply? 02:22:37 q? 02:22:44 sanketj: set of properties youc an apply to highlight pseudo is same as for other highlight pseudos 02:22:50 sanketj: fairly limited 02:22:50 Text fragment in URL proposal: https://github.com/WICG/ScrollToTextFragment 02:22:55 q? 02:22:55 ack atotic 02:23:10 ack cbiesinger 02:23:23 cbiesinger: Have you considered making priority part of highlight pseudo syntax rather than in JS? 02:23:50 q+ 02:24:11 fantasai: it's more a question of order. For regular element, we have the DOM order, but for pseudos we don't. For the built-in ones, we specificy that order into the spec 02:24:23 fantasai: but for custom ones, we need to specificy where they fit 02:24:44 fantasai: this isn't something you want to redo everytime you select something, so it doesn't belong in the selector 02:25:03 heycam: I like the proposal, wanted to be able to do for awhile 02:25:05 fantasai: we could have a declarative mechanism in addition to JS, but selectors isn't it 02:25:10 heycam: two questions, 02:25:19 heycam: is there a need to style ranges that match multiple higlihgts at the same time 02:25:25 q+ 02:25:28 heycam: rather than just styling all of the individual highlight speduos 02:25:35 heycam: if you have a comma separated name of highlight speudos? 02:25:38 sanketj: trying tunderstand 02:25:46 sanketj: if you have multiple ranges, would you need to style them separately if the same content? 02:26:10 heycam: would you need to be able to style, say I want this style when I match both "a" and "b" type of highlight 02:26:10 q+ 02:26:18 sanketj: scnearious we're looking at, they are independent 02:26:26 sanketj: one implementing spellcheck, one impelmentign selection , etc. 02:26:32 sanketj: want both fo those styles to show up 02:26:52 heycam: two styles of text decorations are underlining, maybe you want to style slightly differently if two underlines 02:27:07 BoCupp: so if you have a range that is overlapping two range groups, e.g. this section is currently selected and also a found word 02:27:20 BoCupp: when combination comes together, you want to pick a different color for that? 02:27:26 BoCupp: don't have a good scenario for that 02:27:33 ack TabAtkins 02:27:37 r12a has joined #css 02:27:41 heycam: the built-in highlights, theyr'e not exposed in the JS API, would it be beneficial to expose those? 02:27:44 q? 02:27:48 heycam: so you could set .style on them, too 02:27:53 sanketj: maybe 02:28:00 ack heycam 02:28:04 ack dbaron 02:28:06 Are we set for a WPT/CSSWG meeting tomorrow at 9am? 02:28:10 dbaron: I'm also a big fan of this, we've talked about having a feature like this for awhile 02:28:13 dbaron: some questions 02:28:19 dbaron: a little concered about ergonomics of the JS api 02:28:29 dbaron: one common thing a user will want to do is create a range and add it to the set of something 02:28:34 dbaron: say the set is called grammar-error 02:28:47 bobbytung has joined #css 02:28:51 dbaron: my reading of what you have in the JS API is that the way you do that is going to be different depending on whether you've added a grammar error before 02:28:57 sanketj: in scenario you're adding a grammar-error 02:29:08 sanketj: if you are creating range for grammar errors 02:29:16 sanketj: user types something, new grammar error appears 02:29:25 sanketj: grammarly made the group and has to keep track of the name 02:29:35 sanketj: they need to keep track of that info 02:29:46 iank_: mentioned someone makeing such a library would ... 02:29:56 dbaron: seems awkward to create all your global errors up front rather than initialize 02:30:15 dbaron: reminds me of various set APIs that have e.g. get APIs that have "get this object out of the set, and if it doesn't exist make me one" 02:30:21 q? 02:30:24 dbaron: it seems like this API should have that mode 02:30:31 dbaron: maybe some other way to structure API 02:30:49 dbaron: other thing is that I'm not sure, there's a bunch of new work in pseudos spec 02:30:52 dbaron: unsure if implemented 02:31:03 dino has joined #css 02:31:07 sanketj: wanted to check status of implementation itnerest of pseudo-spec 02:31:22 dbaron: if those are not implemented, I'd prioritize interests of getting this implemented over those 02:31:43 dbaron: having generic mechanism work reasonably is more important than having existing spec work 02:31:53 florian: the thing that makes them tricky to implement isn't which one exist, but how do they work? 02:31:59 florian: we ahve to figure that out for built-in and for custom 02:32:15 florian: if we implement custom things and drop built-in grammar and spelling-error standard, I don't mind 02:32:22 florian: but definign how the cascade work etc. is still needed 02:32:24 q+ 02:32:49 dbaron: yes, but if that work doesn't extend well to an arbitrary list rather than a specific list, then given that at least it's not implemented, we should fix the cascading/etc to work for arbitrary list of classes 02:33:27 chrishtr: wanted task your current thinking wrt performance of DOM mutations 02:33:31 sanketj: open issue on this 02:33:35 ack chrishtr 02:33:37 sanketj: static range is one of the otpions thinking about 02:33:43 sanketj: might be useful 02:33:50 q+ 02:33:51 sanketj: also going to discuss this topic in editing TF later this week 02:33:57 sanketj: any other APIs to make this useful 02:34:07 sanketj: if you have static range, do you still need live ranges? 02:34:14 sanketj: I'm not sure 02:34:20 Zakim, close queue 02:34:20 ok, Rossen_, the speaker queue is closed 02:34:25 sanketj: but would like to not just restrict it to ranges 02:34:44 chrishtr: Appreciate taking it seriously, ranges have been a significant perf problem 02:34:58 chrishtr: each API that changes DOM has to check that range is still correct, it's a problem 02:35:36 skk: We are develoipng viewr for weak eyesight 02:35:42 drousso_ has joined #css 02:35:42 skk: using text-to-speech using ? API 02:35:46 q- (was going to ask the same about StaticRange and co.) 02:35:47 skk: is it possible to synchronize with speech? 02:35:56 sanketj: Currently, the accessibility concerns haven't been addressed 02:36:02 q- 02:36:11 sanketj: true for all higlights, I think. Don't think have a way to say spelling error exists here 02:36:13 q? 02:36:14 q- a10y question 02:36:15 sanketj: so still need to figure out 02:36:18 ack skk 02:36:22 ack birtles 02:36:31 birtles: priority field feels a bit like z-index 02:36:38 birtles: are there any alternatives like a relative ordering? 02:36:55 birtles: I'm concerned that an extension hlgihglts ranges in the page, going to be a highlight war to get higher priority in teh page 02:37:00 floating point numbers! 02:37:13 sanketj: regardless of option, need to have some kind of recommendation of how priority would interact with application priorities 02:37:38 fantasai: I think that setting the prio rleative to the prio of the builtins is easy, you just set it a prio. 02:37:44 fantasai: Probably you just set it to 0. 02:37:59 fantasai: That doesn't answer brian's question, which is multiple libs competing. 02:38:09 fantasai: so how do they coordinate rather than just assigning random numbers? 02:38:31 fantasai: cuz most of them will then try to assign max-int 02:39:07 BoCupp: I don't think you can coordinate things that are inherently uncoordinated themselves, there has to be an integrator 02:39:23 BoCupp: when frameworks brought together in the web app, maybe grab each one and set its priority to say which is more important 02:39:34 BoCupp: extensions like grammarly, go app by app, look at how do I integrate with each app? 02:39:42 BoCupp: dont' do it blindly, do it after investigating the app 02:40:02 BoCupp: today have to figure out how to integrate spans into app without breaking, this would be much less invasive 02:40:04 s/?/SpeechSynthesis/ 02:40:10 birtles: quick example of relative ordering 02:40:23 birtles: my app does highlights for a short time, so should be above grammarly's hiighlights 02:40:35 birtles: with priority approach, I might see that grammarly uses 1000, so I use 1001. 02:40:40 romain has joined #css 02:40:49 birtles: but then grammarly upgrades to 2000 02:41:05 birtles: maybe have an API that give me the highiest available priority, or priority above this particular name 02:41:08 q? 02:41:17 sanketj: currently best could do is iterate map and get the highest priority 02:41:20 maybe a priority name like "transient" would work? 02:41:36 johannes: Grammarly tries to integrate with other apps, in cases where it cannot, it usually just breaks the app 02:41:46 johannes: in email, can't integrate with it, your email is just gone 02:42:00 johannes: grammarly is trying to do this for awhile, but it's not working unless you have central registry 02:42:03 s/in email/in gmail/ 02:42:17 rune: Thinking about cascding and inheritance 02:42:39 rune: div::selection, implementations aren't using that style for span::selection in the div 02:42:47 rune: concerned there will be too much inheritance 02:42:55 BoCupp: A few questions about priority and inheritance 02:43:01 BoCupp: maybe we should go to the issues? 02:43:12 rune: just a general worry 02:43:25 rune: maybe we should fix that in implementatiosn before adding lots of new ones? 02:43:45 ack atotic 02:43:49 ack fantasai 02:43:49 fantasai, you wanted to reply 02:43:56 ack futhark 02:44:21 zakim, open queue 02:44:22 ok, astearns, the speaker queue is open 02:44:41 sanketj: priority property is currently just distinguishing stacking order for user-defiend highlights 02:44:50 sanketj: wnat to discuss how that relates to native highlights and combination of the two 02:45:04 sanketj: if we extend to native highlights, two pieces here, what is default priority for user-defiend highlights relative to native highlights 02:45:11 sanketj: if user wants to customize that, what is mechanism? 02:45:16 sanketj: some scenarious useful 02:45:25 sanketj: nwhen author is buildign some editing capability, but using native capabitily for something else 02:45:40 sanketj: might impelemtn find-on-page, but use UA's selection 02:45:50 sanketj: and want that to show up above their find-on-page 02:46:04 sanketj: in other cases might want to show over the UA selection 02:46:30 sanketj: solution I propose is that by default, author-defined goes below UA-defined 02:46:35 florian: I agree 02:46:38 q? 02:46:44 zakim, open queue 02:46:44 ok, Rossen_, the speaker queue is open 02:47:05 BoCupp: Is there a need to interleave with the UA highlights? 02:47:13 BoCupp: having phase above or below that is probably easiest 02:47:38 fantasai: the painting rules are already interleaved 02:47:54 fantasai: background is painted before, text decorations are on top 02:48:11 fantasai: it's inevitable that things interleave 02:48:31 sanketj: spelling-error and grammar-error, is one group 02:48:32 fantasai: but if you've got mulitple of them trying to set the same property, the one needs to win 02:48:39 sanketj: selection, find-on-page different 02:48:48 sanketj: let's say user wanted to impelemnt their own spell-check and use their own styles 02:48:59 sanketj: but wanted to use browsers' grammar-error, is there a way to maintain that stacking order? 02:49:30 sanketj: because selection and spelling error are different styles, then would get both 02:49:31 q+ 02:50:02 fantasai: there might be a way to allow the UA defined ones to be manipulated the same way as the custom ones 02:50:25 fantasai: if you had the native ones in that same map, using standard names, the author could style them, change their priority... 02:50:42 fantasai: the author could possibly also replace the range objects 02:51:07 fantasai: so the author could take over built in ones, instead of duplicating 02:51:19 +1 I was just thinking the author may want to use the browser's native styling for grammar etc. with their own range, so it may make sense to expose them in the map to allow that 02:51:33 fantasai: also worth noting that we have spelling-error and grammar-error text decoration styles, so you can duplicate that styling if you want to for other types of highlights 02:51:53 ack florian 02:52:01 florian: need to be careful about priorities 02:52:05 florian: and thining about them 02:52:10 florian: it's not quite about in front / behind 02:52:18 nmccully has joined #css 02:52:24 florian: because even if you have lowest priority, your foreground will be over the background of the ghighest priority 02:52:33 florian: some degree of interleaving is inevitable 02:52:38 florian: if there is a priority that doesn't allow ? 02:52:46 florian: not sure bannign it would sovle the impelementation problem 02:52:59 florian: backgrounds are behind, shadows, then text 02:53:24 BoCupp: .... 02:53:39 BoCupp: we reasoned, does anyone need that, what are schenarios? would you replace grammar/spelling errors? 02:53:46 BoCupp: fishing for scenarious taht would reuqire a more capable API 02:53:53 Rossen_: one procedural recommendation, since running low on time 02:54:00 Rossen_: hearing quite a bit of support and interest from CSSWG 02:54:05 Rossen_: something that has been needed for quite some time 02:54:16 Rossen_: I suggest that we transition into figuring out where this work is going to go 02:54:26 Rossen_: and start transfering text into an actual spec, and star tracking issues in our GH tracker 02:54:39 Rossen_: if going back to explainer, where would work need to be split out? 02:54:46 Rossen_: there's some selectors and then some actual speudo explanation 02:55:16 fantasai: I'd say either its own spec or the pseudo elements module. 02:55:17 fantasai: Would suggest ether its own spec, or integrate into css-pseudo 02:55:35 florian: Starting as own thing, amybe merge into pseudo maybe split it 02:55:40 sanketj: also question on name 02:56:01 sanketj: earlier proposal was range-decoration? 02:56:09 +1 to OM concerns mixed in the feature, instead of in a separate spec 02:56:10 fantasai: css-highlight-api 02:56:26 +1 fantasai 02:56:35 Rossen_: Any objections to adopt as ED, with sanketj as editor? 02:56:47 dbaron: adopt as new ED or integrate into css-pseudo-4? 02:56:53 dbaron: I'd prefer integrating into css-pseudo-4 02:57:04 dbaron: would prefer the closely related things be in the same document 02:57:39 iank_: that said, might be easier to iterate on API if separate 02:57:52 florian: can revisit during FPWD time 02:58:23 Rossen_: so maybe start as separate spec and integrate later? 02:58:35 TabAtkins: an issue into css-pseudo-4 pointing at draft to be integrated later 02:58:44 Rossen_: any co-editor? 02:58:47 florian: propose myself 02:58:52 sanketj: ok! 02:58:56 hober: me too 02:59:18 futhark has joined #css 02:59:32 RESOLVED: Adopt css-highlight-api as ED with sanketj, florian , and hober as editors; add issue into css-pseudo-4 for where it might be integrated pointing at the ED 03:11:22 romain has joined #css 03:18:57 bobbytung has joined #css 03:23:22 dauwhe has joined #css 03:27:18 duga has joined #css 03:40:03 zcorpan has joined #css 03:48:22 futhark has joined #css 03:50:29 futhark_ has joined #css 03:50:48 futhark has joined #css 03:57:27
03:58:42 ericc has joined #css 04:00:59 kurosawa has joined #css 04:01:07 starting back up soon 04:04:19 myles has joined #css 04:09:44 bobbytung has joined #css 04:11:52 ericc has joined #css 04:12:17 myles has joined #css 04:12:38 ScribeNick: myles 04:12:40 Topic: Scroll Anchoring 04:13:18 smfr has joined #css 04:15:05 emilio: Is this microphone on? 04:15:43 github: https://github.com/w3c/csswg-drafts/issues/4239 04:15:45 drousso has joined #css 04:15:48 rakina has joined #css 04:16:00 emilio: The spec sepcifices a few situations where if a given style chagne happens, you don't apply any scrolling adjustments in thecontainer. This is done to avoid manual sticky effects. This is done to prevent them to breaking. 04:16:20 drousso_ has joined #css 04:16:57 emilio: even with this heuristic, we have still found either broken pages that for example, once you scroll to the bottom you can't scroll back up, or they do things that in the regular cases you want scroll anchoring to apply, or pages that get burn a bunch of CPU in infinite scroll event listeners because scrolling triggers more scrolling listeners. This is possible in both chrome and firefox. 04:17:18 emilio: What I did to fix it is to never apply any adjustment for scroll anchoring if you are processing a scroll event listener for htat node. 04:17:46 emilio: When you fire the scroll event listener, you remember the target of the event, and if the element matches, you don't re-fire 04:18:06 emilio: this is mainly to prevent bad scroll events. I'm just interested in feedback from implementors 04:18:35 nmccully has joined #css 04:18:35 chris has joined #css 04:18:42 stantonm has joined #css 04:18:48 : Chrome implementors are in agreement 04:18:59 emilio: Ian Scopes is no longer working on this 04:19:03 eae: No one is working on it now 04:19:17 Rossen_ has joined #css 04:19:20 chrishtr: What about it are you itnerested in? 04:19:20 s/Scopes/Skobes/ 04:19:27 Rossen_TPAC has joined #css 04:19:29 dauwhe has joined #css 04:19:37 s/Ian Skobes/Steve Kobes/ 04:19:42 s/Ian Skobes/Steve Kobes/ 04:20:22 emilio: scroll anchoring restores positions so the offset relative to the scroller is preserved. There are cases where that's undesirable, or break,s if the page is doing stuff like scroll effects. So if you change a static position thing to be below, the anchor node goes up, and then you need another scroll event, and the page realizes that the thing is no longer sticking to the viewport, et.c 04:20:39 emilio: Chrome fixed this by, when changing from in-flow to out-of-flow, don't do the scroll adjustment. 04:20:45 eae: Yes, that's how it works today. 04:21:05 emilio: Even with this heuristic, pages burn CPU by firing infinite scroll events, which is not great. Pages that get locked up on scrolling if you get to the bottom. 04:21:54 emilio: Those cases are not easy to identify generically, because a particular style change happened. The style didn't change, it's a case that scrolling wants to fix. The only thing that's happening is a scroll event listener. Instead of Chrome's heuristics, it would be simpler to not adjust scroll offsets if you're doing scroll anchoring if it's happening during a scroll event listener 04:22:13 eae: We tried that and rejected it, but I don't remember why. Our current behavior is the one that worked the best in the best number of cases. 04:22:23 present+ 04:22:38 chrishtr: If something dirties layout that changes scroll offset in a scroll event listener... you want that readback to not take into account anchoring? 04:22:41 emilio: Yes. 04:22:52 eae: That sounds reasonable. If we can't figure out why we can't do that, we should try it agian and see if it's workable 04:23:04 chrishtr: Is the code doing this loop synchronously? 04:23:20 emilio: I know pages in Chrome that burn CPU because the scroll offset keeps changing 04:23:28 emilio: It changes back and forth, and triggers two scroll events 04:23:29 r12a has joined #css 04:23:57 eae: We try to detect that and short-circuit if we go back and forth more than a few times, but it may not always work. 04:24:22 atotic: If you have feedbakc, that would be great, because we're using a heuristic now 04:24:36 chrishtr: If layout is dirtied and syncrhonously read back in teh same handler .... what does reading it back have to do with .... 04:24:42 q+ 04:24:48 skk has joined #css 04:25:34 emilio: While the page is measurin gsomething, so if you insert something, measure it, then remove it, that measurement triggers a scrolloffset update. If you measure again, you'd get the opposite scrolloffset update. That needs to update the scroll offset 04:25:48 chrishtr: Are you proposing that forced layouts don't do this? 04:25:59 ack smfr 04:26:00 emilio: I'm proposing that Scroll offsets don't do anchoring 04:26:13 smfr: Is the time that scroll anchoring is applied defined in terms of HTML5 event loop. 04:26:22 fremy has joined #css 04:26:44 emilio: no. This is an issue. Mostly for this heuristic, if we can remove it, we don't need that, but the main issue is that it's udnefined when this calculation occurs. We are aware of this. 04:26:55 emilio: Scroll anchoring runs after updating styles but before updating layout. 04:27:06 emilio: In order to have hte tree in the state you want it to, you have to run it every layout 04:27:15 smfr: Scrolls triggered by scroll anchoring fire scroll events? 04:27:16 emilio: yes 04:27:19 smfr: that's necessary? 04:27:20 smfr: yes 04:27:25 emilio: yes 04:27:49 chrishtr: What you're proposing is worth investigating. Chrome can invest engineers to page back in our history here. 04:28:03 eae: If you're impelmenting now, we shoudl revesolve this 04:28:16 astearns: Do we need a resolution? Should we change the spec? 04:28:34 emilio: These heuristics are still implemented in Chrome and Firefox. I want to remove them in Firefox. 04:28:37 emilio: I don't see any reason to remove them now. 04:28:43 chrishtr: We need more investigation. 04:28:58 q+ 04:29:19 dbaron: You talked about, in a certain case, not doing scroll anchoring. Are there are reasons to record but defer the adjustment until later? 04:29:34 dbaron: I haven't thought about it that much. It feels like not doing it sometimes runs the risk of dropping something that you might have wanted 04:29:50 emilio: That may be another approach. And then we can move it to the "update the rendering steps" in HTML5 04:30:07 emilio: The main reason case where you don't want scroll anchroning adjustments is when you're reacting to scroll events yourself 04:30:57 atotic: Part of the problem in Chrome is that, by the time we're in layout, we don't know which handler cuased it. If you can make it work in Firefox, maybe it's possible in Chrome. But we don't have anyone working on it 04:31:16 emilio: Yeah, but you can set a flag.... 04:31:34 atotic: We'd have to pass the flag around.... 04:31:38 emilio: Yeah, it's possible 04:32:53 romain has joined #css 04:33:41 mattwoodrow has joined #css 04:33:56 smfr: High level comment about spec: The spec is unusual because it describes a behavior which is making up for the fact that web developers often make mistakes and cause scroll jank. With specs like this, we need to be careful. We risk a scenario where some UAs implement this, papering over the bad stuff, and authors may only test in UAs that implemented it. In other UAs whcih haven't implemented in it, there's a lot more scroll jank than the other UAs. This 04:33:57 spec increases the disparity between user agents. We need to be careful not to make too many of these in the future 04:34:19 astearns: There are lots of CSS features which are improving the rendering of a page. If a browser doens't implement that feature, that browser will look worse. 04:34:28 zcorpan has joined #css 04:34:46 kurosawa_ has joined #css 04:34:49 smfr: It's invisible to authors. The browser jsut fixes up content. It's easy for authors to create scroll-jank if they don't test in chrome 04:35:02 iank_: there is precidence. Text autosizing behavior is automatic. 04:35:59 kevers has joined #css 04:36:17 astearns: Can we move on? 04:36:41 Topic: Can an anchor node be an inline block 04:36:42 github: https://github.com/w3c/csswg-drafts/issues/4247 04:37:09 skk has joined #css 04:37:34 emilio: A bit of the issues we've found with the spec, the spec uses terms, and the terms don't map to the implementation that wrote teh spec. The spec says "the anchor is either a block box or text" but what blink does is "well any thing that is non an inline or an anonymous block can be an anchor" 04:37:47 emilio: that is not great. I think we've reached agreement with Steve about better terms for the spec. The spec needs some love. 04:37:49 tantek has joined #css 04:37:55 emilio: I'm happy to help out to refine the spec. 04:38:38 emilio: Proposal: Changing the definition of anchor node to be every box but inline boxes and fragmentainers, which are the only things that fragment across 04:38:41 emilio: This is what Blink does. 04:38:43 astearns: Any concerns? 04:38:53 iank_: There's some discussion on the github issue? 04:39:27 oriol: Instead of explicitly specifing the inlines, can we use atomic inline from the display specification? We can use terms from that spec for future additions to the spec? 04:39:51 emilio: So right now, the definition is accurate. That term from the other spec sounds better. 04:40:05 emilio: Proposal: An anchor node can be every box except a non-atomic inline box 04:41:00 RESOLVED: An anchor node only can be every box except a non-atomic inline box 04:41:28 RESOLVED: An anchor node can be any box except non-atomic inline boxes 04:41:54 Topic: JLReq met last week 04:42:08 astearns: There's going to be a breakout session on Wednesday to talk about JLReq updates 04:43:13 duga has joined #css 04:43:15 nat: Japan Language Requirements. We're working on an errata and gap analysis that will add new tests so we can more deliberately affect standards for japanese typography including those on the web. 10-11 Wednesday, called Evolving the JLReq. Will be talking about what we are currently doing and what we will be doing in the future. 04:44:16 TabAtkins: Majid pointed out that Waterloo is available for a summer meeting (instead of New York). 04:44:34 Rossen: Near Toronto 04:44:34 TabAtkins: 1 hour drive 04:44:43 Rossen: Thanks for the offer. 04:44:54 Topic: Transforms 04:45:12 smfr: I'd like to build up the understanding of how they should work incrementally. I have some data from real sites that will inform our discussion. 04:45:14 astearns: Projection? 04:45:15 smfr: yes 04:47:32 futhark has joined #css 04:52:30 mattwoodrow has joined #css 04:53:00 ScribeNick: emilio 04:53:10 https://github.com/w3c/csswg-drafts/issues/4116 04:53:18 GitHub: https://github.com/w3c/csswg-drafts/issues/4116 04:53:26 Topic: Images with layout information 04:53:27 bobbytung has joined #css 04:53:31 GitHub: https://github.com/w3c/csswg-drafts/issues/4116 04:54:07 myles: I'd like to present a problem and no suggestions about how to solve it, but I hope to leave with a sense of whether we're interested in solving it 04:54:16 myles: there are images that need to be positioned similarly to text 04:54:49 myles: like a math formula with a tall integral sign where most of the formula should be aligned to the baseline but the presence of the integral sign the whole image will sit on the baseline 04:54:55 myles: so the formula won't align with the text 04:55:03 if we're talking about things like gaiji, which is inline images that should have a baseline and stuff... there was some proposal to add a property to specify a baseline table 04:55:17 we didn't spec it out because it wasn't a high priority 04:55:21 myles: it'd be cool if the math formula could say "my baseline is in the middle of the image", and layout could align it correctly 04:55:28 but it's certainly possible to do 04:55:45 myles: similarly with the apple pay logo and similar, because of the descender of the y 04:56:20 plh has joined #css 04:56:24 myles: a similar case is for symbols like the play button in the ios music app, which is not fully horizontally centered, but visually centered 04:56:48 myles: it's a triangle, so if you mathematically center it horizontally it would look wrong 04:57:04 myles: so the layout moves it slightly horizontally 04:57:41 myles: same for kanbun, which are cjk chars which are not in unicode and people use them using images 04:57:59 myles: since they're images they behave wrong 04:58:18 myles: three of the examples show the need for horizontal baselines, the other is a vertical baseline 04:58:19 s/kanbun/kaiji 04:58:20 Rossen_TPAC has joined #css 04:58:27 s/kaiji/gaiji/ 04:58:38 There's another fairly common use-case of this, images used for decorative first/initial letters 04:58:47 myles: there are various ways to do this, one option is using it on the image formats and such to provide the information 04:58:56 myles: another option is to add a css properties 04:59:15 myles: mac has these system assets that contain this information 04:59:35 futhark has joined #css 04:59:39 unencoded glyphs = gaiji; Chinese poetry typeset for Japanese audiences = kanbun 04:59:43 myles: another option would be to provide a css function that takes a name to these system assets, and returns the information 04:59:50 myles: so at least we could use it for system assets 05:00:16 myles: I wanted to get an indication of whether this is a problem worth solving, and if it is what's the solution could look like 05:00:27 q+ 05:00:37 TabAtkins: chrome is fine with that, we have taken a look to the image formats to provide x-height and baseline 05:00:43 ack 05:01:20 q+ 05:01:23 q+ to note use-case of decorative image first/initial letters and also prior art / related feature CSS cursors which reference the hotspot of the cursor image 05:01:28 nmccully: a single baseline is fine, but multiple baselines may be needed for multiple writing systems 05:01:32 q= 05:01:32 ack tantek 05:01:33 ack tantek 05:01:35 tantek, you wanted to note use-case of decorative image first/initial letters and also prior art / related feature CSS cursors which reference the hotspot of the cursor image 05:01:36 q+ 05:01:45 q- 05:01:58 Rossen_ has joined #css 05:02:06 Rossen__ has joined #css 05:02:09 tantek: I agree this is worth solving. Another use case is a decorative image for the first-letter which has decorations and borders alone 05:02:20 s/alone/and such 05:02:57 tantek: we have a similar feature / challenge in css-ui with the cursor property 05:03:19 q+ 05:03:20 tantek: cursor has a hotspot. May be something that we could reuse somehow 05:03:58 TabAtkins: cursors are usually set once, but in this case you need the same information every time you set the image 05:03:59 q+ 05:04:18 ack stantonm 05:04:29 kevers has joined #css 05:04:30 tantek: I think cursors can also have the same issue. Having the info in the image would be great, but maybe both 05:04:34 TabAtkins: both is fine 05:05:24 stantonm: we have a similar use case for @font-face / images and cjk, where adding a baseline to the font-face rule would be useful 05:05:29 myles: can you link me to it? 05:06:34 stantonm: we also have a use case to get rid of these images and use the font, so we wanted to use @font-face with the images, and for that the baseline would be great, but for the symbols it may not make sense 05:07:03 @myles: if you want more details about the CUR format wrapper which can contain a PNG image and specify a hotspot: https://en.wikipedia.org/wiki/ICO_(file_format)#Icon_resource_structure 05:07:05 stantonm: another thing we wanted to see if we can treat images more like a bitmap, to invert in dark mode 05:07:10 myles: mix-blend-mode? 05:07:20 stantonm: haven't looked into impl that much 05:07:24 HeWenli has joined #css 05:07:39 heycam: I wanted to express general agreement on the problem being worth solving 05:07:52 heycam: have run into this with svg 05:07:55 creating @font-face from an CJK image (gaiji) - https://github.com/w3c/csswg-drafts/issues/4013 05:08:12 q? 05:08:15 ack heycam 05:08:22 heycam: I think modifying image formats would be useful, though I'm concerned for compat if we run into a situation with image-orientation 05:08:32 heycam: where we start reacting to image metadata and breaking pages 05:08:44 myles: we still need some css integrations to define how these are read or what not 05:09:02 FYI CSS UI cursors with optional hotspot x y that can override any built-in hotspot: https://www.w3.org/TR/css-ui-3/#cursor 05:09:04 ack krit 05:09:09 heycam: using vertical writing mode to getting centering and alignment seems a bit odd 05:09:23 krit: file formats seems nice, but there are formats which we may not be able to modify 05:09:45 krit: so we may want a css-only solution as well 05:09:48 skk has joined #css 05:10:01 ack chrishtr 05:10:06 chrishtr: what formats have this already, any examples? 05:10:09 myles: nope, 0 05:10:26 myles: the ui image in iOS apps have this, but it's not a file format 05:10:39 q+ 05:10:48 chrishtr: so in an iOS app you create an image and set this and use it in your layout? 05:10:49 myles: yes 05:11:02 chrishtr: I'm curious about how feasible is it to modify the formats 05:11:21 myles: people think it's a good idea so I'll try and come back if fail 05:11:54 myles, I think we need to make sure whatever we do can handle multiple baselines 05:12:00 fremy: we may not need to change formats, the cursor format is a small wrapper file with some metadata. May be able to use a similar wrapper-format 05:12:07 e.g. alphabetic vs ideographic vs central vs mathematical 05:12:19 chrishtr: you're proposing a new format? 05:13:03 Adobe's SING glyph format was one way to make an image with font metrics : https://web.archive.org/web/20080627183635/http://www.adobe.com/devnet/opentype/gdk/topic.html 05:13:22 fremy: windows cursors do exist already, and include the hotspot. It already has the hotspot, but we don't want exactly that 05:13:38 fremy: so we may want that instead 05:13:42 ack bkardell_ 05:13:48 q+ 05:13:57 fremy: as changing formats is going to be a pain 05:14:16 myles: only interested in jpeg and png really, and those do have optional tags 05:14:33 myles: but yeah, first thing to try is changing those, second the wrapper format, third css-only solution 05:14:34 optional tags inside their existing formats 05:15:13 bkardell_: We need to specify what do we do with these values, and people thought that a css solution would also be valuable too 05:15:42 bkardell_: so it seems like we'd get into a situation where there are multiple sources of truth 05:15:50 myles: image-orientation was like that until not long ago 05:15:56 bkardell_: right, also aspect-ratio and such 05:16:10 bkardell_: do you think a property of that sort would be valuable? 05:16:37 ack chrishtr 05:16:46 myles: I think the way I'd approach is the underline-{offset,thickness} where there is an auto value, then from-font (which would look and the image), then 05:16:59 chrishtr: we discussed something similar about mathml not long ago right? 05:17:31 myles: I think the mathml proposal was to identify the baseline out of specific elements inside the formula 05:17:44 myles: but that doesn't work for non-formula use-cases like the ones I've provided 05:17:47 chrishtr: that makes sense 05:17:56 cbiesinger: could potentially work for svg 05:18:02 myles: yeah, true 05:18:49 chrishtr: drott mentioned that fonts can be the wrapper format 05:18:56 chrishtr: that may be a lot of overhead 05:19:13 myles: I think making icon fonts is an anti-pattern 05:19:29 drott: there are some ergonomic issues with them 05:19:51 drott: but my point is that we don't need a new wrapper format, you could wrap an image in a font file 05:20:10 myles: I'd prefer a new format, there's tons of unrelated stuff that you'd need to create a valid font 05:20:19 Topic: multicol 05:20:47 Github: https://github.com/w3c/csswg-drafts/issues/4036 05:21:33 rachelandrew: this is an edit made in #3224 (since the last wd) 05:21:50 rachelandrew: dbaron opened this, issue has a bunch of discussion 05:22:25 futhark has joined #css 05:22:29 rachelandrew: I think it was left reverting the resolution in #3224, but then we need to resolve what column-fill: auto and height: auto works 05:22:57 rachelandrew: so we need to decide 05:23:22 rachelandrew: I wanted to sort this so I can publish another wd, and I wouldn't like to publish something that we may revert 05:23:39 iank_: can you describe what happens right now? 05:24:16 rachelandrew: if we're on a continuous context we only look at column-fill: auto in ???, and there were interop issues 05:24:32 stantonm_ has joined #css 05:24:37 rachelandrew: Chrome is doing the new behavior, which is actually the old one that was commented out on the spec 05:24:43 rachelandrew: dbaron has a nice table on that issue 05:24:52 rachelandrew: the second table 05:25:44 rachelandrew: I think if we print from the browser the behavior should be the same 05:26:15 dbaron: yeah, I think we shouldn't get in that situation, because we'd balance the columns separately because we're printing 05:26:21 rego has joined #css 05:26:46 dbaron: I think at least the last fragment in paginated mode should behave the same as the only fragment 05:27:16 dbaron: I suggested a fix, but florian didn't agree because it was not what print formatters do 05:27:27 dbaron: so I suggested going in the other direction 05:27:51 dbaron: I think mstensho was fine with this if we have a clearer definition of what each combination does 05:28:02 dbaron: it'd take me a bit 05:28:21 astearns: so reverting would get us to a better place to improve upon right? 05:28:36 dbaron: I think so if WebKit are fine with changing this 05:28:48 iank_: reverting this leaves less more stuff unspecified right? 05:29:07 rachelandrew: yeah, that's right, but we shouldn't publish something that we might revert 05:29:20 iank_: can we mark it at risk or such? 05:29:47 astearns: it's more of a note "we think this is wrong but we haven't figured out the implications of changing it" 05:30:17 zcorpan has joined #css 05:30:22 iank_: that seems fine for a WD 05:30:34 astearns: but if we know it's flat wrong it may not be useful 05:30:47 iank_: but is it wrong for sure? 05:30:54 dbaron: I think the inconsistency is pretty wrong 05:30:59 dlibby has joined #css 05:31:02 iank_: mstensho didn't agree looks like 05:31:13 dbaron: I don't think he disagreed 05:32:24 dbaron: to be clear the thing mstensho is complaining about is that `height: auto; column-fill: auto` if we revert this change 05:32:31 dbaron: that combination is already not-defined when you're printing 05:33:15 dbaron: so there's an existing spec gap that needs to be filled 05:33:49 dbaron: but I don't think it's too hard since there is existing behavior (though we may not like it) 05:34:25 florian: I think consistency between printing and formatters is important, so it is consistency between a browser on continuous contexts and printing 05:34:41 florian: so we should revert to find a solution that doesn't break any of both 05:34:47 karl has joined #css 05:35:00 astearns: iank_ had objections? 05:35:02 iank_: I think reverting is fine 05:35:19 astearns: proposed resolution is reverting the change and leave issues in the draft to define this 05:35:22 rachelandrew: yeah 05:35:33 iank_: may be useful to link to the reverted change 05:36:05 It looks like what Gecko does for the auto height is just to assume one column. 05:36:16 RESOLVED: revert the change made in #3224, and add spec issues to define this 05:36:26 RESOLVED: republish the wd of css-multicol 05:36:52 Topic: transforms 05:37:17 ScribeNick: heycam 05:37:36 xfq has joined #css 05:37:42 smfr: thinking about 3d transforms 05:37:53 ... I want to make sure any changes to the spec don't have unreasonable web compat impacts 05:38:02 ... so I wanted to understand how people use 3d transforms on the web, I did a poll 05:38:11 ... analysed these sites that are using real 3d 05:38:18 ... not as many sites as I expected 05:38:39 smfr: I've noted the structured 05:38:46 ... the set of properties on the node that's doing 3d stuff 05:38:53 ... properties on the node, the child, the grandchild, etc. 05:39:02 ... generally web sites are putting perspective on the root of the 3d stuff 05:39:10 ... not preserve-3d on the root, mostly just perspective 05:39:18 ... then they put preserve-3d in the child, sometimes with transform 05:39:26 ... sometimes they have a noop element. not no transform related styles on it 05:39:47 ... sometimes they'll have some intermediate elements, e.g. 3 noop divs, then transform/preserve-3d under that 05:40:03 ... sometimes they put just the transform on the leaf nodes. sometimes preserve-3d and transform on the leaf nodes 05:40:16 ... something that came out of this is taht there are a few sites that have these noop divs that cause bugs in Gecko 05:40:40 ... Gecko treats an element in the ancestor chain that doesn't have transform related prtoperties and something taht triggers flattening 05:40:43 ... it's causing problems on a few sites 05:40:53 florian: are there sties that rely on this happening> 05:40:55 not see any 05:41:03 s/not/smfr: did not/ 05:41:18 smfr: people combime overflow-scroll and 3d for parallax effects 05:41:26 ... might have to make some exceptions for overflow-scroll 05:41:40 ... this is how people are using 3d transforms.. most important thing is that noop divs should not cause flattening 05:41:59 smfr: next I want to build up the 3d model from scratch 05:42:05 ... I'ver realised there are some porblems with the current ED 05:42:18 ... we'll end up with a combination of thwat's in the current ED and the preivous WD 05:42:45 [shows transforms-buildup.html] 05:42:58 ... let's started with a simple case. this is a 3d transformed element, in isolation 05:43:03 ... nothing else that is 3d-ish in this content 05:43:12 ... the best behavior for this is that the 3d transform here acts as a painting effect 05:43:22 ... it'll be squished by the transformed, but painted in the regular z-order 05:43:28 ... no intersection with its container or anything else 05:43:38 ... next question is what happens if there are 2 siblings that are transforms 05:43:50 ... think the right answer is that they should act as a painting effect, they should not intersect 05:44:02 ... I think that's the Gecko model, and maybe Blink, but not WebKit. willing to change WebKit here 05:44:15 chrishtr: nothing has the preserve3d here 05:44:19 smfr: right, we're still in "painting" transforms 05:44:28 astearns: is this something the current ED is sayin something differetn about? 05:44:39 smfr: the current ED is written with the notion that you're always in a 3d rendering context, and doing flattening 05:44:45 ... it uses the analgoy of CSS stacking ocntexts and flatening 05:44:58 ... I think a better model is that you only establish a 3d rendering context when you use the magic properties 05:45:02 ... otherwise you paint in the regular z-order 05:45:29 ... now let's change the eexample to put perspective on the container 05:45:55 ... originally the notion was persecptve is we're applying another transform for descendants, a common viewport/perspective 05:46:08 ... looking at the way content is using perspective, think it makes sense to establish a 3d rendering context 05:46:16 ... the 2 siblings would start intersecting with each other 05:46:26 chrishtr: not a behavior any browser has now? 05:46:43 mattwoodrow: WebKit will intersect them (though even without perspective right now) 05:46:59 chrishtr: the perspective proposal is unrelated to current intersecting behavior of WebKIt? 05:47:00 smfr: yes 05:47:13 ... when an author says perspective, they're opting in to 3d stuff, and expecting descendants to depth sort 05:47:28 chrishtr: and currently, in Gecko and Chrome, they don't intersect but the perspectie does adjust teh transform 05:47:29 mattwoodrow: right 05:47:44 ... did you have examples on your spreadsheet of examples where Gecko/Blink are broken? 05:47:54 smfr: most sites had more complex hierarchies 05:48:11 ... nobody had just perspective and transformed chlidren 05:48:24 ... so, hard to say 05:49:23 smfr: going back to the example, next set of questions is about the preserve-3d behavior 05:49:33 ... I think the right hting for preserve-3d is to establish or extend a 3d rendering context 05:50:10 ... so in this case, if you put a preserve3d wrapper around the child -- leaf doesn't have the preserve 3d -- ... 05:50:40 chrishtr: so 2 transformed elements in a single context are sorted with respect to each other 05:50:57 krit: this example would render the same in all browsers now? 05:51:08 smfr: not sure that Gecko will do intersection between the two 05:51:39 krit: the proposal is if you have persecptive set to a value, you'll establish a 3d rendering context? 05:51:40 smfr: yes 05:52:06 chrishtr: support you have an element with perspective. and a child with no transforms. then a grandchild --- 05:52:08 smfr: we'll come to that 05:52:44 ... web site data showed that noop divs should not flatten 05:53:07 ... some interesting cases then, things like opacity that trigger flattening 05:53:18 ... creates a stacking context, and a graphical group, it triggers flattening 05:53:51 mattwoodrow: my biggest concern with the noop thing is it's hard to describe what hte behavior is 05:54:09 ... the spec wording for how to decide how to establish a new one or to participate in an "ancestor" ... 05:54:16 smfr: think that should be written in terms of stacking context ancestors 05:54:24 ... WebKit's implementation is based on paint order, not containing block order 05:54:34 ... I think there are some cases where these properties should trigger a containing block for ease of implementation 05:54:40 ... but effectively we certainly work in painting order 05:54:43 bobbytung has joined #css 05:54:45 mattwoodrow: there are things liek overflow:scroll 05:54:51 ... anything that has a clip ... 05:55:11 chrishtr: setting aside overlfow:scroll, do you think this opacity would need to establish a containing block? 05:55:13 smfr: no? 05:55:35 ... another interesting case. things that trigger stacking contexts but which arent' grouping effects 05:55:40 ... for example z-index 05:55:56 ... that doesn't create a graphical group, but stacking contexts are effectively graphical groups, so it should flatten as well 05:55:58 ... it's no-op-ish 05:56:06 ... so I think in the model it has to flatten 05:56:29 ... then there's the other interesting one, what if you have overflow:scroll -- doesn't create a stacking context. people take advantage of this not flattening to create parallax effects 05:56:38 ... not really sure how to describe the clipping effects of oveflow 05:56:48 mattwoodrow: think we want different behavior for pereserve-3d and perspective 05:57:04 ... for preserve-3d we probably want to flatten. but the persecptive subset we could do relatively easily 05:57:23 chrishtr: can we go through a quick example of doing parallax with this model? 05:57:31 mattwoodrow: currently in Gecko, the clip is applied on the outside of the persecptvie 05:57:38 ... the perspective gets multipled into the transformed elements 05:57:46 ... but the perspective origin is outside the scrolled element 05:57:53 ... the clip is not in the middle of the transform chain 05:58:13 chrishtr: as long as we can preserve parallax scrolling.... 05:59:17 mattwoodrow: spec text could say to look up the DOM to find a preserve3d element, but stop walking if you find overflow:scroll 05:59:32 chrishtr: I think you would want this to be a containing block and stacking context as well 05:59:37 ... it's neither of those 2 things by default 05:59:40 mattwoodrow: right 05:59:46 smfr: when it has preserve3d around somehow? 06:00:00 chrishtr: walk up the tree, if it's got preserve3d around an overflow:scroll, ... 06:00:22 mattwoodrow: not suggesting overflow:scroll should be a stacking context, but the inner preserve-3d would create a new 3d rendering context 06:01:56 [some discussion about preserve-3d on the overflow:scroll element resulting in the computed style being transform-style:flat] 06:02:21 astearns: sounds like there were some existing sites that expected noop divs ... is there a difference between noop divs and those that have an explicit flattening property? 06:02:32 smfr: noop divs don't flatten 06:02:39 mattwoodrow: I think it's easier to specify if they do flatten 06:02:45 astearns: but not what authors expect? 06:02:47 chrishtr: maybe 06:02:59 smfr: none of these examples totally broke. but you could see the perspective looked different on some elements 06:03:08 chrishtr: definitely think aligning browser behavior is going to break some content 06:03:16 ... should minimize that, but come up with a model that we're sure is well defined 06:03:27 smfr: that flattening was the most obvious breakage if we followed the Gecko model straight away 06:03:57 ... I think the last piece is the discussion around how perserve-3d behaves ... 06:04:13 smfr: on #1950, Tab lists four different behaviors 06:04:27 ... don't fully undersatnd if they're the same except for whether preserve-3d is on the parent or the child 06:05:39 chrishtr: Q1 is, do the children 3d sort before they flatten 06:07:25 Q2: do the children sort with the rest of the 3d scene their parent is in, or do they flatten into the parent and then (flat) parent lives in the scene? 06:07:39 chrishtr: and these behaviors are the 2 core ones we control with preserve-3d or perspective 06:07:53 ... taht's your whole point? how do they behave dfeault and how do the properties affect this? 06:07:54 TabAtkins: yes 06:08:04 ... all 4 combinations seem reasonable, don't know if you want to expose them all 06:08:22 ... case 1 is fully 3d, everything is operating in the same graph 06:08:28 duga has joined #css 06:08:33 ... case 2 is you run the children's 3d scene, flatten it, the parent does the 3d scene 06:08:38 One other thought (related to discussions a few minutes back) is that you were talking about walking up the DOM tree, but I'm not sure if you wanted to walk up the DOM tree or the containing block chain. 06:08:54 ... #3 is the weird one. each child does an independent 3d thing in the parent's plane, but they could overlap with other things 06:09:06 ... 4, double flat is simple 06:09:35 smfr: doing all of these with combinations of properties, with the behavior I described, except if perspective establishes a 3d rendering context, authors would not be able to have the transfom effects of perspectie without also the intersection effect 06:09:46 ... but the author could use the perspective transform function on the leaves to get something similar, but not sharing the same origin 06:10:00 chrishtr: I think that first part of the sentence is a good reason why perspective should not imply preserve-3d 06:10:12 smfr: so valid to hav eshared perspective, but siblings not intersecting, which is contrary to my first point 06:11:21 smfr: ok, so we're back to perspective not making a context 06:11:29 ... question is how many of these sites would break 06:11:41 chrishtr: then there's the question of resolving the intermediate divs 06:11:49 ... how we'd spec and implement the corner cases 06:12:00 ... if those intermeidate divs would in some cases be transmitting up the preserve-3d as opposed to flattening 06:12:09 smfr: unless we're willing to go to the Gecko model of always flattening 06:12:15 smfr: still think that's the most web incompatible change 06:12:23 chrishtr: if it was web compatible would it be objectionable to you? 06:12:24 smfr: no 06:12:30 chrishtr: certaimly the easiest to reason about in the spec 06:13:04 ... we should do some homework tonight on why these sites are broken in Firefox, see if it's due to this issue or something else 06:13:07 mattwoodrow: I can do that 06:13:27 chrishtr: and whether it's easy to fix them 06:14:03 smfr: if we say that the root must have perspective and preserve-3d to establish a 3d context, I did not capture dat about whether there are multipel transformed siblings 06:14:09 chrishtr: the intersecting thing? 06:14:11 smfr: yeah 06:14:20 ... no authors are using preserve-3d on the element with perspetive 06:14:25 chrishtr: you would've observed a rendering difference 06:14:41 smfr: these don't have multiple siblings, so wouldn't necessarily see that 06:15:03 chrishtr: nobody's done any httparchive searches 06:15:09 ... would be good to find mor eto sanity check 06:15:28 smfr: the stripe stuff is genuine content, most others are old demos 06:15:47 chrishtr: ancedotally, not sure how common this kind of content is 06:16:00 ... I will volunteer to do an httparchive search tonight 06:16:19 florian: I think the lack of interop is indeed causing a lack of sites using it 06:16:28 ... I did retire a site that used to use 3d 06:18:30 Topic: backface visibility 06:19:39 github: https://github.com/w3c/csswg-drafts/issues/918 06:20:11 mattwoodrow: current spec says that backface-visibility only applies to the element it's on, not descendants 06:20:20 ... doesn't say it would create any plane or layer, which Gecko faithfully implements 06:20:30 ... other engines create a plane for all descendants but not positioned descendants 06:20:45 ... which is not something there's any precedent for, seems a bit crazy. would prefer backface-visibility create a stacking context 06:20:55 smfr: I think in WebKit it does create a stacking context, not a containing block 06:21:02 mattwoodrow: maybe it is that it doesn't create a containing block 06:21:08 chrishtr: definitely doesn't create a stacking context 06:21:11 dauwhe has joined #css 06:21:18 smfr: I'd be scared to change hte behavior of backface-visibility... 06:21:33 mattwoodrow: so try to find a descroption of what it actually does. affects itself and non-positioned descendants? 06:22:17 chrishtr: self painting layers reset the backface visibility thing 06:22:21 mattwoodrow: don't know how to describe it for the spec 06:22:43 chrishtr: similar to the set of things dbaron found that caused "painting as if positioned" 06:22:55 ... in CSS 2.1, positioned elts paint later than regular elements 06:22:56 https://dbaron.org/css/test/2018/stacking-context-z-order 06:23:02 ... anything that has an effect-y thing on it 06:23:09 ... this is exactly what is on self painting layers 06:23:19 ... so we could define it that way 06:23:23 florian: where else did we run into this? 06:23:37 chrishtr: might have been another case yes 06:23:48 ... but the thing about hte paint order is one that's not specified properly, is that right? 06:24:26 mattwoodrow: most of hte psecs that create stacking ocntext say that. but they mean create a stacking ocntext and sort it with positioned descendants 06:24:40 chrishtr: overflow:hidden, backface-visibility, SVG elements and other atomically replaced elements, ... 06:24:54 ... CSS clip probably 06:25:06 ... and the rest of them do create stacking contexts 06:25:30 ... we should define this, get interop on the table in dbaron's test, then use it for the backface-visibility definition 06:25:48 dbaron: I don't think there's a whole lot in there that's not creating a stacking context 06:25:54 ... CSS clip only applies to things that are positioned 06:26:01 chrishtr: but in terms of the "painting as if positioned" 06:26:10 ... I think overflow:clip is the most common 06:26:18 dbaron: have we added that yet? 06:26:23 chrishtr: I mean overlfow:hidden and scroll 06:26:45 ... on the issue in which this table resides, I mention there's a silly quirk in Chrome and probably WebKit, not triggering self painting in some bizarre corner cases of scrolling 06:26:58 smfr: WK does not create self painting layers for [...] 06:27:11 dbaron: I don't htink Gecko sorts overflow:hidden on to positioned descendants list 06:27:13 mattwoodrow: don't think so 06:27:30 s/[...]/overflow:hidden/ 06:27:55 sanketj has joined #css 06:27:57 mattwoodrow: overflow:hidden isn't a stacking context, can interleave things inside and outside, so can't go in the positioned descendants list 06:28:10 smfr: so is everything on the list make stacking context? 06:28:11 mattwoodrow: yes 06:28:21 chrishtr: overflow:hidden does not create a self painting layer (in Blink) 06:28:41 ... if there's overlfow:scroll but is in effect like overflow:hidden since there's nothing to scroll, then we skip it 06:28:47 ... that's something we could change in Chrome 06:29:09 ... in any case, is this a good way to spec it? 06:29:52 mattwoodrow: yes, I agree the CSS 2.1 spec describes floats [...] 06:30:27 I think Gecko calls this "pseudo-stacking context" 06:30:40 RESOLUTION: Add a new "pseudo-stacking context" definition and use it to define how backface-visibility works 06:30:59 dbaron: some of this would be easier if there's a spec to put this old CSS 2.1 text to evolve it 06:31:09 ... maybe a central painting spec 06:31:34 -- break until 4pm -- 06:31:36 futhark has joined #css 06:32:37 ericc has joined #css 06:41:48 romain_ has joined #css 06:42:33 plh has joined #css 06:43:21 dauwhe has joined #css 06:46:06 zcorpan has joined #css 06:46:46 duga has joined #css 06:54:29 xfq has joined #css 06:57:28 mattwoodrow has joined #css 07:01:13 stantonm has joined #css 07:07:25 futhark has joined #css 07:07:41 karl has joined #css 07:10:33 sanketj has joined #css 07:12:09 ScribeNick: TabAtkins 07:12:11 kurosawa has joined #css 07:12:19 nigel has joined #css 07:12:36 Topic: Define path() in Shapes 1 or 2 07:12:51 astearns: A number of specs are using , which has several functions in Shapes 1, but not path(). 07:13:02 astearns: But path() is being implemented for *some* of the properties. 07:13:12 astearns: It's weird to have them linking to a definition in Shapes 2 that's just a diff. 07:13:26 astearns: One option is to flesh out Shapes 2 into an actual spec, with a proper definition for including path() 07:13:41 astearns: Another option is to pull path() back into Shapes 1, which implies we should implement it for shape-outside 07:13:46 astearns: I don't much care which one we do. 07:13:54 astearns: But would like to resolve on which way to o. 07:14:26 dlibby has joined #css 07:14:42 TabAtkins: My preference is whatever gets all the props using the same set of shape functions; all the props use a different subset right now and it's terrible. 07:15:08 fremy has joined #css 07:15:19 TabAtkins: Spec's easy, I'm fine with it in level 1. 07:15:41 astearns: I think Ian said it woudln't be trivial, but seems plausible to do. 07:15:44 eae: Yes. 07:15:59 s/it/doing path() in shape-outside/ 07:16:25 astearns: So I propose adding path() to Shapes 1. There's other things that need to be done in the spec, we can get a draft out that everyone can refer to with all the functions. 07:16:38 astearns: Can deal with how that slows down Shapes 1 from PR as we find impls to try it out. 07:16:41 astearns: Objections? 07:16:56 futhark has joined #css 07:17:07 The problem with adding path() to shapes 1 is that, as currently defined, it can't be used everywhere a shape is. It only defines the outline, not the fill area. 07:17:15 heycam: Any objection to shipping path() in things like offset-path - do they need to ship together? 07:17:59 TabAtkins: [reads Amelia's IRC comment] 07:18:09 astearns: Yeah that's a bit of th eproblem, some properties don't need fill-rule at all. 07:18:23 astearns: So I'm imagining it's an optional param to the function. But I haven't thought about how it's specified yet. 07:18:42 heycam: Would that block Motion Path? 07:19:09 astearns: My proposal is just to put it in Shapes 1. It shoudl improve the Process situation for Motion Path; it can then refer to a CR-level spec instead of a FPWD diff spec. 07:19:20 Motion path would just ignore the fill rule. But for the SVG `d` property, allowing fill-rule in the path() function is possibly confusing, since there's a separate fill-rule property that applies. 07:19:30 astearns: This is really all about Process. 07:19:59 astearns: Tab, you mentioned Chris Coyier's annoyance with the shapes being different everywhere. 07:21:22 astearns: There's the path attribute in SVG; it's possible we won't get all the way to SVG syntax in CSS. 07:21:31 glenn_ has joined #css 07:21:32 [discussion about CSS tokenization not being compatible with SVG] 07:21:36 kevers has joined #css 07:21:40 myles: Does that mean you can't build up paths from varia les? 07:21:47 TabAtkins: Not without defining a new syntax that's CSS compatible. 07:21:55 AmeliaBR: Or doing the string-concat function. 07:22:01 myles: Didn't we resolve to add that? 07:22:07 AmeliaBR: Yeah, but no one's written it yet. 07:22:42 AmeliaBR: wrt it being a Process issue; if we want to put path() in Shapes 1, we have to figure out these issues before Shapes 1 can move forward in the process. 07:23:14 AmeliaBR: I'm not sure who's responsible for Shapes's progress, I think Alan; at this point is it best ot clean up and stabilize, or are we fine to take on this new work? Becaus eit's also abuot impls. 07:23:51 astearns: I think my strat will be to add it to the spec as an at-risk feature, so that we can punt it if we need to move Shapes 1 forward, but I'm perfectly happy with it sitting at CR for a while, or even going back ot WD if there are enough changes. 07:24:02 astearns: I'm not that concerned with getting it to Rec real quick. 07:24:48 AmeliaBR: Does adding path() mean we have to cycle back to WD, as a significant new feature? 07:24:50 Ms2ger has joined #css 07:24:52 florian: Nah it's fine. 07:25:03 florian: Patent Policy will handle it fine; as long as you've got wide review and what not is fine. 07:25:13 AmeliaBR: It's been reviewed in Motion Path, but review there... 07:25:23 florian: The easier it is to demonstrate review, the easier time you'll have. 07:25:29 astearns: And if we have to bounce to WD, that's fine. 07:25:47 AmeliaBR: So long term, is our goal that shapes should be shapes, and you should be able to specify motion-path with circle(), etc? 07:25:59 TabAtkins: Yeah, a circle is a path, whatever. 07:26:23 astearns: So any objection to adding path() to Shapes 1? 07:26:39 RESOLVED: Move path() down to Shapes 1, adding it to . 07:27:06 krit: I missed - are impls willing to support path() in shape-outside? 07:27:14 astearns: Missing a few people that would answer that. 07:27:21 TabAtkins: Ian says it's non-trivial, but doable. 07:27:36 astearns: So yeah that might slow us down, but getting things consistent and well-explained is more useful than a quick Rec for Shapes. 07:28:45 krit: Would it be good to add a note about precision in paths? A very complex path might get transformed to a polygon, maybe have a lot of points, etc. So can we add a note that impls can decide on how precise it wants to be? 07:28:57 duga has joined #css 07:29:18 astearns: I don't know if we currently have text to that effect with polygons... 07:29:26 s/astearns/AmeliaBR/ 07:29:41 astearns: We do have text for some degenerate/difficult situations, saying you do have to do the difficult stuff. 07:29:59 astearns: I'm not sure we need to define that; precision's going to be an impl detail. Tests will have to be fairly coarse anyway to avoid being flaky. 07:30:07 astearns: So I think it's just a QoI detail they can live with. 07:30:18 krit: So if we agree it's just QoI, it's probably fine. 07:30:27 smfr has joined #css 07:30:30 glenn has joined #css 07:30:39 AmeliaBR: There's already a lot of flexibility for, say, *drawing* SVG paths. 07:30:41 krit: Ok. 07:31:03 github: https://github.com/w3c/csswg-drafts/issues/4270 07:31:13 Travis has joined #css 07:32:13 Topic: Sunsetting the fxtf-drafts repo 07:32:32 glazou has joined #css 07:32:48 AmeliaBR: This has already been decided, but there's been no volunteer to do the work. 07:32:53 TabAtkins: I can do it. 07:33:05 Zakim has left #css 07:33:30 plinss: We'll need to add some redirects to the draft server, since the URLs will change. Coordinate with me. 07:33:40 Zakim has joined #css 07:36:01 ScribeNick: heycam 07:36:38 Topic: Should list-item counter reset rule be in a UA stylesheet? 07:36:53 github: https://github.com/w3c/csswg-drafts/issues/4244 07:37:00 emilio: the CSS Lists spec says that ol and ul (should also include menu!) should have a counter-reset: list-item in the UA sheet 07:37:09 .. we've had 2 regression reports, people overriding counter-reset 07:37:21 ... the fix on the author side is trivial, adding list-item to the value 07:37:28 ... afaik, the 2 regressions are fixed that way 07:37:36 ... but we may want to think about whether we should make this reset magical 07:37:46 ... the issue with making it magical, is that there's no way to override it to none 07:37:57 TabAtkins: at the previous meeting, didn't we resolve to do the thing where if you don't mention list-item? 07:38:01 emilio: that's for counter-increment 07:38:05 ... should we do the same for counter-reset? 07:38:14 ... the reason I didn't want to jump to do that, there's no way to override it to none 07:38:14 futhark has joined #css 07:38:27 ... could say you add the counter-reset, unless you explicitly set it to none 07:38:29 ... so it's tricky 07:38:54 ... not totally convinced we need to change it for compat, but I'd like to know if we do need it 07:39:21 TabAtkins: if we wanted to express the reverse mbehavior, in non magical ways, you'd need something special for counter-reset 07:39:32 ... the only way to do that within the syntax of counter-reset would be to add a function 07:39:52 ... because there's no comma, must be an ident and possibly a number. if you add a number ident, that's just another counter 07:40:08 ... if you wanted to change hte behavior, like with reversed lists, synatx would be to use a function rather than an ident 07:40:29 ... could have a dont-reset(...) when you explicitly need to 07:40:44 ... then if it's not explicitly mentioned in this way, it gets reset in this way 07:40:48 emilio: not a fan 07:41:06 AmeliaBR: counter-reset: dont-reset(list-item), xxx 07:41:52 emilio: just looking for ideas if we needed to tackle this 07:41:56 ... for now this is fine I think 07:42:14 ... a more web compatible solution would be to always reset it, but then it's annoying you can't override it 07:42:18 TabAtkins: you can override the use of it 07:42:35 emilio: the browser's doing some extra accounting in the background, but the author just wouldn't use it 07:42:42 s/emilio/TabAtkins/ 07:43:08 glazou_ has joined #css 07:43:12 fremy: what happens if you don't reset, and you have a reversed list inside another reversed list? 07:43:14 AmeliaBR: it's a nested counter 07:43:30 fremy: if you're not resetting th ecounter, you have to consider the nested child as part of the main list 07:43:34 ... does anyone want to implement that? 07:43:38 emilio: I think it would work right now 07:44:02 AmeliaBR: the list items handle if you're incrementing up or down 07:44:14 emilio: we do the counting on the counter nodes, so we count the number of counter nodes that are in the same list 07:44:29 ... I think it would work. mixing reversed and non-reversed lists would be fun... 07:44:35 fremy: not sure it's a big problem if we cannot 07:45:41 AmeliaBR: any interested in supporting reversed counters in general? counter-reset and reset it to the max value the counter would have? 07:45:50 TabAtkins: so far no, since that's what reversed counters actually do in HTML 07:46:01 s/that's not/that's not what/ 07:46:06 s/that's what/that's not what/ 07:46:46 glenn has joined #css 07:46:54 nmccully has joined #css 07:48:08 ScribeNick: TabAtkins 07:48:32 nmccully_ has joined #css 07:49:13 Topic: word-break:keep-all and overflow 07:49:49 florian: In langs like English, word-break:keep-all is same as normal 07:49:52 github: https://github.com/w3c/csswg-drafts/issues/4286 07:50:03 florian: In Japanese, it suppresses a lot of wrapping opportunities. (Not quite all, but most.) 07:50:27 florian: So if you have a very short measure of text, you might have a small sequence of text without break opportunities. 07:50:44 florian: Currently ther'es a provisio in the spec that the UA may reproduce the suppressed wrapping oppo to reduce overflow. 07:50:57 florian: I think this is good, but the "may" isn't. We should harmonize on should or must if we want to do this. 07:51:37 florian: An example of this is a title or figcaption, a short piece of text. 07:51:49 florian: People tend to like it not breaking anywhere in Japanese. 07:52:07 florian: But if the amount of space is small enough that it woudl cause overflow, they'll prefer it to break anyway. 07:52:10 futhark has joined #css 07:52:41 myles: This value is for Korean, right? 07:52:52 florian: It's frequently used for Korean, but it's also useful for other CJK langs. 07:53:06 florian: Any lang that allows breaking at syllable/char boundaries can use this to opt into a less free-form style. 07:53:23 myles: Right, just if Korean use is most common for this, we should see what Korean native speakers prefer. 07:53:49 koji: I'd prefer this be explicit, so it happens only when authors opt in, like overflow-wrap. 07:54:09 koji: If you want overflow-wrap to not break at specific points, that might be the feature you want. I don't see much different from keep-all in English case. 07:54:19 koji: If it's useful for Korean it's probably useful for English. 07:54:48 florian: Difference between like-English and break-all is that in English, there's no real context where breaking anywhere is acceptable. But other langs, that is the default. 07:55:09 florian: So falling back to that behavior in those langs that opt into keep-all is possibly reasonable, while it's not in English. 07:55:18 myles: What about overflow-wrap:anywhere? 07:55:23 florian: This isn't actually anywhere, tho. 07:55:29 myles: Maybe break-word? 07:55:38 florian: break-word and anywhere are identical except for intrinsic sizes. 07:56:03 florian: But maybe we could have a fourth value, that says that if keep-all, it still falls back to breaking anywhere if necessary. 07:56:20 myles: Right, my question is just if we need a new value, or if the existing values are enough and we just specify their interactions a little different. 07:56:33 Rossen_ has joined #css 07:56:44 koji: In my mind, the two variants of Korean linebreaking are just variants; keep-all is normal behavior. 07:57:04 koji: Even in English or German, if you have a tiny space to lay out in, you might still want a break going anywhere. 07:57:39 florian: My proposal is *not* to allow breaks before commas, etc. Those are disallowed in 'normal'. My proposal is that, in these restrained-size situations, revert keep-all to acting like normal. 07:58:06 koji: I understand. but this value is already to suppress this situation from happening in Korean. But I think we want to fix all languages. 07:58:36 florian: We have this in german/english/etc by using hyphenation, with "" for the hyphenation character. 07:59:10 koji: Ok, so say English text has a very long word, and the author uses overflow-wrap:break-all to allow it to break. In that case it can break before a comma, which isn't ideal. 07:59:28 koji: I don't think we can change that, so we might want to add the fourth value. 07:59:42 myles: That's what break-word was supposed to do way back when Hyatt implemented it... 08:00:26 koji: word-break can be commonly used in an issue tracker, for example. But using it on English text is troublesome. overflow-wrap is more useful, but can do bad breaking. 08:00:42 duga has joined #css 08:00:46 myles: My overall point is that the linebreaking properties in the Text spec are already so complex and there are so many of them, that it will be hard to justify another one. 08:01:00 koji: Ok, well, I think this is basically the same as modifying keep-all. 08:01:26 florian: One action item is to ask Korean speakers, since they're a frequent user of this value, if it would be generally acceptable or if it would be weird. 08:01:42 florian: There seems to be a use-case to have it either way, but you're right, there is a big cost to adding new properties in this space. 08:01:57 florian: So we could defer the always-prevent value if it's going to be rare. 08:02:09 florian: It's just having the "may" that I think isn't terribly useful. 08:02:17 myles: Right, making a resolution now seems premature. 08:02:24 florian: Sure. That's enough feedback fo rnow. 08:02:36 Topic: How to handle leading ideographic space sequences 08:03:14 florian: this has evolved over time; they're a strange kind of space, like figure spaces, ideographic spaces, etc 08:03:24 github: https://github.com/w3c/csswg-drafts/issues/4180 08:03:33 florian: These now have the treatment that they'r enot collapsible, that hasn't changed, bu tthey're discarded at the end of the line (assuming white-space:normal) 08:04:16 florian: Unfortunate consequence: if the line is *only* these spaces, they're not discarded for being at the beginning of the line, but they're also at the end of the line and need to be discarded. That leaves an empty line, which is weird. 08:04:21 florian: We coul dinsted hang them. 08:04:30 florian: Diff is you could still see them if you underline or background them. 08:04:42 florian: But from layout, it would be the same as an empty line. 08:04:56 florian: This was found by Igalia when implementing the spec as written, and it seemed weird to them. 08:05:28 florian: I think there's no real author preference between discarding and hanging. So since hanging is simpler for impls, would be preferable. 08:05:37 florian: I made a PR for this, I know fantasai is okay with this. 08:05:50 ???: Is there precedence fo rhaving that many hanging spaces? 08:05:57 s/???/stantonm/ 08:06:02 florian: Yes, we have some other situations like white-space:pre-wrap. 08:06:21 florian: There's an open issue for some variant situations, but... 08:06:39 stantonm: The inline border does seem strange. 08:06:51 stantonm: An inline with a border would project off the edge of the element. 08:06:57 florian: Like any overflowing content, es. 08:08:29 florian: Example: "a b ". If the spaces can hang, these can stay on one line. If they can't and must overflow, instead you must break before b, then let that second line overflow anyway. So not hanging isn't avoiding overflow at all, just introducing extra linebreaks that shouldn't be necessary. 08:08:47 koji: Hanging would require changes to our whitespace code that we'd like to avoid if possible. 08:09:12 myles: there are like 5000 ways to make text look bad on the web already 08:09:21 stantonm: Is there a way to avoid this? 08:09:30 florian: Yes, text-underline-skip for example. 08:10:02 astearns: So proposed resolution is to accept the PR, which states that the spaces will hang. 08:10:06 astearns: Objections? 08:10:47 RESOLVED: Trailing "other-separator spaces" will hang, accepting Florian's PR. 08:11:26 topic: is it OK to ship clip-path:path() 08:11:40 github: https://github.com/w3c/csswg-drafts/issues/4271 08:11:42 astearns: There was a second gh issue we didn't send the comments to 08:11:56 astearns: An impl was asking if it was okay to ship clip-path:path() 08:12:16 astearns: Because they needed to point to an official draft that had this path() thing specified, and all they had was the diff spec 08:12:27 astearns: So in my mind the intent of moving this to level 1 is to let impls ship it. 08:12:44 heycam: clip-path:path() is already shipping in WK, I believe. Not in Chrome yet. Ready in firefox for a while. 08:13:21 heycam: Just wanted to make sure nothing drastic would happen to the syntax. 08:13:47 krit: CSS Masking is already in CR, so implementing clip-path is fine; this is specifically about the path() function. 08:14:26 astearns: Does anyone think Gecko should *not* ship the syntax? 08:14:42 RESOLVED: Impls can ship clip-path:path() 08:15:01 github-bot: end topic 08:15:14 heycam: What's the policy on this sort of "blessing"? 08:15:52 we put it into the Snapshot 08:15:56 astearns: In general, CR means definitely fine to ship; before is usually behind a flag. But it's fine for there to be situations where people need to ship before CR, just check with the group that it's in a stable situation. 08:16:33 Topic: text-size-adjust 08:16:55 myles: People like to view websites on their phones. 08:17:01 [general astonishment] 08:17:08 myles: But phones ar esmall. So the text is usually too small 08:17:31 myles: So way back in 2007, iPhone 1 implemented a feature to automatically increase the text size without increasing page size. 08:17:42 myles: We've been shipping this for a very long time. 08:17:44 FYI some old writing on this here: https://wiki.mozilla.org/CSS/text-size-adjust 08:17:55 myles: This is controllable with a CSS property called -webkit-text-size-adjust 08:18:42 myles: Three values: none, which means "don't mess with my sizes"; auto, the default "mess with them it's fine"; and a %, which means the browser's default method of messing with sizes doesn't work well for a particular element, so they site provides its own % boost for the element. 08:19:12 myles: So if font-size is 10px, and wtsa is 130%, you'd see a 13px size. 08:19:44 myles: So a bit later we shipped the iPad, also a small screen. 08:20:03 myles: This wasn't a problem; we made the iPad view the same content the iPHone viewed; it pretended to be a big iPhone for the web. 08:20:11 myles: So it also got the text-size-adjust behavior. 08:20:20 myles: This past year we've changed iPad behavior. 08:20:28 myles: Now iPads get desktop content. 08:20:43 myles: So this means that sites which said -wtsa, we don't get that behavior anymore. 08:20:50 myles: But ipads are still small, so we have to do something. 08:21:03 myles: After research, turns out the method we need to increase font-sizes is different between ipad and iphone 08:21:21 myles: In iphone, the goal is to make text readable when you double-text an element; we'll zoom in so the text fills the width of the screen, so you avoid scrolling. 08:21:35 myles: In ipad, people don't usually double-tap on elements, so the goal was to make it readable by default. 08:21:42 s/double-text/double-tap/ 08:21:47 myles: So the heuristics are pretty different. 08:21:50 myles: No problem so far. 08:22:06 dauwhe has joined #css 08:22:18 myles: This year we started accepting desktop content. That often has -wtsa property, because desktops don't honor it, so it just kinda sticks around without doing anything. 08:22:31 myles: But when we flipped the switch, ipads were honoring the property, and everything got messed up. 08:23:05 Rossen_ has joined #css 08:23:05 myles: AFter investigation, we discovered that most of the sites that were setting wtsa were using 100%, which is the same as turning it off. 08:23:19 futhark has joined #css 08:23:33 myles: Correlation between sites that did that, and sites that *needed* wtsa to work well on the ipad, unfortunately. 08:23:40 myles: So what we now have implemented in ToT is... 08:23:54 myles: none still means none. auto still means magic; different than phone, but still magic. 08:24:13 myles: But %, we found that if treated %s as auto, it made the web look better than honoring the %s. 08:24:43 myles: Way more sites were using %s to turn wtsa off, than were using it correctly to specify good sizing. In fact, *zero* sites were using it correctly. 08:24:48 myles: So it would be good to write that down. 08:25:00 myles: There is a spec covering this feature, CSS Text Size Adjust. 08:25:04 https://drafts.csswg.org/css-size-adjust/#adjustment-control 08:25:10 myles: I have a bunch of edits I'd like to make to that spec. 08:25:48 myles: Mostly of the form that %s will be used as a hint. On iPHones they'll be honored; on iPads they'll be a suggestion (currently ignored, might change later if sites start using it correctly). 08:25:51 https://github.com/whatwg/compat/issues/18 08:26:05 myles: And I'd also like to generalize the inputs/outputs for the "auto" behavior to make it encompass both the iphone and ipad behavior. 08:26:41 myles: And I'd like to add a section about how authors should use the property to control this behavior; you can look at computed value to see what the brwoser did to your text, and you can use "none" to reset if it you don't like it. 08:26:47 myles: So want to know what wg thinks. 08:26:58 astearns: How are you speccing this behavior? UAs may do this, may do that...? 08:27:01 q+ 08:27:14 myles: Strat we thought best was to keep things general. Two behavior on two platforms, browsers might have other behaviors, etc. 08:27:26 myles: As long as the author can know what was done and fix it, should be fine. 08:27:35 lajava has joined #css 08:27:40 myles: So strategy is to make it very general and have a list of things that may be considered when the browser does auto sizing. 08:27:43 ack heycam 08:28:05 heycam: seems like you want the author to be able to tell what auto adjust the UA has made for an element 08:28:10 heycam: Exposed thru the computed style. 08:28:14 myles: Already how iphone works 08:28:43 heycam: looking at the old spec for the moment; initial value is auto, and it's inherited. so if it computes down to the actual %, wouldn't that be inherited to the children? 08:29:00 myles: In webkit I think we don't follow the inheritance rules to the letter for this property. 08:29:13 myles: If you stack a bunch of %s, they don't multiply. 08:29:34 dbaron: I heard you saying look at computed value of font-size, not text-size-adjust. 08:29:37 myles: Right! 08:29:46 q+ 08:29:56 myles: So you look at font-size and line-height; i think it's important that the spec explicitly says only those two properties will be modified. 08:30:02 myles: S'o they know what to consult and fix. 08:30:07 ack dbaron 08:30:14 dbaron: I think most of this sounds fantastic. 08:30:21 dbaron: A little nervous about generalization. 08:30:36 dbaron: Would be nice to have a good description if someone wants to implement this... 08:30:52 myles: So over the past long time we wanted to change how ipad viewed the web 08:30:55 myles: but text was too small 08:31:00 karl: aliases are cheap 08:31:04 myles: the iphone's model isn't really what we want 08:31:28 myles: want different behavior, and faster (iphone behavior is slow), looks at viewport, style of nearby elements, out-of-flow vs in-flow, etc 08:31:39 myles: Tried to come up with an algo for the ipad, and we implemented it, and it wasn't good 08:31:44 myles: Cycled for a while. 08:32:04 myles: so instead is we got a lot of humans to visit websites, and tap on the things that were too small. custom webkit build that would log this 08:32:16 myles: Adn then did the same to tap on the thins that weren't too msall 08:32:28 myles: Then used ML to predict too-small vs ok-size. 08:32:38 myles: So we have a decision tree, but... 08:32:50 myles: it's not intentional. It just gives good results on a lot of pages. 08:33:03 myles: So I think it would be a bad idea to put those results into a spec. Plus it can change later. 08:33:16 dbaron: I think it would b euseful to have it in the spec even if it's not required to be followed. 08:33:28 myles: Maybe as a non-normative impl guide? 08:33:31 myles: That's fine. 08:33:51 q? 08:33:53 florian: If I'm an author and your algo gets it wrong, that seems unpredictable to me. 08:34:06 myles: We try our best to make the heuristic good, and you can use "none" to fix it. 08:34:18 s/Florian/fremy/ 08:34:30 futhark has joined #css 08:34:46 tantek: You specifically gave examples of authors trying to shut off the bheavior, but accidentally messing the pages up on other devices, and then you having to figure out what they really intended and correcting things for them. 08:34:55 tantek: So that lack of predictability caused authors to misuse the property. 08:36:40 TabAtkins: That's not right. When authors used wtsa on mobile devices, they did it reasonably right. The problem is that wtsa wasn't honored on desktop, but authors were still using (useless, ignored) declarations in their desktop-only code. As soon as ipad starting requesting desktop versions and honoring those declarations, it messed up. 08:37:44 fremy: Ultimately if the heuristic isn't understandable/predictable, Stack Overflow will just recommend swapping 100% to "none". 08:37:51 myles: And that's fine. 08:37:54 ack emilio 08:38:04 emilio: So wk exposes the used font size... 08:38:12 emilio: Your text adust used to be layout time, right? 08:38:27 myles: Yes. But on both iphone and ipad, if you say gCS().fontSize, you'll get the used style. 08:38:40 emilio: Okay, that's not what Firefox does. But maybe we shoudl change it. 08:38:44 myles: Yeah, I think it's important. 08:39:11 q+ to ask if em units are affected 08:39:31 RRSAgent, make minutes 08:39:31 I have made the request to generate https://www.w3.org/2019/09/15-css-minutes.html karl 08:39:46 myles: So if the group thinks this is okay, I'll make a PR for these changes. They're pretty substantial, so maybe I could be added as a coeditor? 08:39:55 tantek: I'm okay with that. 08:39:58 q+ 08:40:06 +1 to myles as a coeditor 08:40:13 SimonSapin: You said computed value of font-size is affected; does that mean that other lengths using em are affected 08:40:16 myles: Yes 08:40:18 drousso has joined #css 08:40:32 q? 08:40:36 emilio: It didn't used to be the case, right? If you did adjustment at layout time, you can't. 08:40:41 myles: Hm, maybe I"m wrong. 08:40:45 ack SimonSapin 08:40:48 SimonSapin, you wanted to ask if em units are affected 08:41:11 tantek: We neve rpublished a fpwd, we had too many issues and didn't understand how to get it ood enough to publish. 08:41:19 tantek: So maybe that's a good goal. 08:41:43 myles: I think that's a reasonable goal. 08:42:01 fremy: do you apply the sam ehueristic for all ipads? 08:42:09 myles: No, depends on screen size and viewport size and specified style 08:42:22 myles: This is listed in the proposed changes 08:42:41 fremy: So if there's a new version of the ipad, are these rules something that'll scale, or is it arbitrary? Do you have to do more tap testing? 08:42:51 myles: I don't htink i can answer that. 08:43:02 astearns: So let's get edits into the draft and raise issues as needed. 08:43:03 dauwhe has joined #css 08:43:10 q+ to express concerns with changing algorithms based on hardware releases 08:43:44 myles: The algo intentionally doesn't describe an algo currently, but it does describe things the browser can consider, and that it only affects two proeprties 08:43:45 ack fremy 08:43:59 plinss: Do you turn these heuristics off when MQs are involved? 08:44:01 myles: no 08:44:11 myles: But does interact with this 08:44:28 myles: So if you have a webpage that is mobile-ready, that'll affect this algo 08:44:50 myles: So the algo is only strong on webpages that are getting shrunk; if they fit well it has minimal effects 08:45:17 RRSAgent, set logs public-visible 08:45:20 plinss: Overall concern is just that we should be encouraging authors to just make pages in general and use MQs . 08:45:46 Rossen_ has joined #css 08:45:46 myles: The overall purpose of tsa is to make things look good on small devices, so it's driving us toward that goal. 08:46:19 myles: Philosophy maybe isn't productive, but generally: a solution in the UA works on every page, and doesn't rely on the author getting it right. 08:46:34 ack tantek 08:46:34 tantek, you wanted to express concerns with changing algorithms based on hardware releases 08:46:35 myles: Users don't say "gee I wish this page used MQs" they say "I can't read NYT, this sucks" 08:46:49 tantek: So a few time syou mention hw releases meaning new algos. 08:47:10 tantek: I'm uncomfortable with algo changing with hw releases. That's not a standard. 08:47:18 tantek: I'd prefer something tha tusrvives hw releases. 08:47:35 myles: First, if we release a new device, we're gonna have to tweak it. The web'll look bad, we have to make it look good. 08:47:56 myles: Second, restricting this to exactly two props, and telling authors how to change it, goes as far as we can to that goal. 08:48:37 myles: So the most future-proof we can do is to say that tsa can only affect font-size and line-length; no matter how the browser changes things, the author can alway slook at those properties, and disable tsa if they want. 08:49:23 jeff has joined #css 08:49:31 TabAtkins: and note that myles wasn't originally intending to publish the algo at all, that was a dbaron request 08:49:47 tantek: I'm concerned that this'll be continuous reverse engineering. 08:50:00 myles: Yeah, when android ships another phone, they'll have to do the same sort of engineering. 08:50:10 hober: This is just acknolwedging reality 08:50:24 dbaron: And realizing that the web's behavior will juts change over time. Maybe that means the spec will need to change over time too. 08:50:53 dbaron: In a world where devs test on these N devices and not every possible-in-theory form factor, there will be things that break when a new device comes out. That'll always be the case, and the impl might need to do new things. 08:51:02 dbaron: so I'd rather have a spec that evolves over time to reflect that 08:51:09 myles: So the alternatives. 08:51:18 myles: One is a spec that changes all the time and is only good on one device, not great. 08:51:28 myles: Another is don't spec it at all, and have i tjust be magic. 08:51:35 myles: I think I've described a good middle ground. 08:51:44 ack dbaron 08:52:01 dbaron: Commenting back on the plinss/myles convo 08:52:08 dbaron: I think using MQ as a signal is a bad idea. 08:52:29 dbaron: It's a passive mechanism. One random stylesheet might use MQs, and if that changes the behavior, it can be a disincentive. 08:52:38 dbaron: So for this sort of thing, I think meta-viewport is a better signal. 08:52:55 I would prefer to not put more and more rendering instructions into HTML? 08:53:21 tantek: I think I need to see the PR to make more comments, so I'd like to make you a coeditor, make the edits, and have continuing discussion 08:53:30 myles: Yeah, not asking for you to pre-approve things you havne't seen. 08:53:42 RESOLVED: Add Myles as co-editor to CSS Size Adjust. 08:53:47 \o/ yeah! 08:54:02 astearns: And I think we have a general agreement ot specify text-size-adjust. Objedtions? 08:54:12 RESOLVED: Specify text-size-adjust more fully. 09:04:33 drousso has joined #css 09:17:08 dauwhe has joined #css 09:31:13 drousso has joined #css 09:46:01 skk has joined #css 09:55:19 dauwhe has joined #css 09:55:32 projector has joined #css 09:56:02 Rossen has joined #css 09:56:33 shans has joined #css 09:57:03 sylvaing has joined #css 09:57:33 leaverou has joined #css 09:58:03 plinss_ has joined #css 10:14:39 duga has joined #css 10:16:11 duga has joined #css 10:24:28 dauwhe has joined #css 10:51:09 tantek has joined #css 11:16:26 Zakim has left #css 11:58:26 dino has joined #css 12:05:45 karl has joined #css 12:11:58 xfq has joined #css 12:33:11 flackr has joined #css 12:52:41 futhark has joined #css 13:01:33 mattwoodrow has joined #css 13:11:02 innovati has joined #css 13:20:07 myles has joined #css 13:32:25 birtles has joined #css 13:57:42 futhark has joined #css 13:58:11 drousso has joined #css 14:10:39 innov4ti has joined #css 14:22:38 dauwhe has joined #css 14:32:27 futhark has joined #css 14:43:02 lajava has joined #css 15:33:46 こんにちはCSSWG! If you're wondering whether to come up the joint session with WPT tomorrow, here's a preview of our short intro: https://docs.google.com/presentation/d/1F1II3lx0krPBIqAzgU9YFIENC-UBEnZtN796hye_bWw/edit?usp=sharing 15:34:17 fantasai florian TabAtkins ^ 15:36:04 Great, see you in the morning :) 15:45:30 futhark has joined #css 16:23:05 dgrogan has joined #css 16:28:22 innovati has joined #css 18:42:09 Savago has joined #css 19:37:54 drousso has joined #css 19:39:23 aja has joined #css 20:23:22 futhark has joined #css 20:59:24 dino has joined #css 21:16:18 ericc has joined #css 21:20:15 duga has joined #css 21:22:12 karl has joined #css 21:22:57 ericc has joined #css 21:52:26 dauwhe has joined #css 21:53:12 rrsagent, off 21:53:45 dino has joined #css 22:25:23 mattwoodrow has joined #css 23:01:14 foolip: in what room is that? 23:11:05 dauwhe has joined #css 23:11:54 SimonSapin: we'll be in the CSS room (Navis-C) 23:12:38 trackbot, start meeting 23:12:41 RRSAgent, make logs public 23:12:41 Zakim has joined #css 23:12:42 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 23:12:42 Date: 16 September 2019 23:12:47 rrsagent, this meeting spans midnight 23:33:36 kzms2 has joined #css 23:36:50 karl has joined #css 23:38:43 ericc has joined #css 23:39:00 drousso has joined #css 23:40:18 skk has joined #css 23:40:19 anssik has joined #css 23:40:46 dauwhe has joined #css 23:43:23 birtles has joined #css 23:47:28 drousso_ has joined #css 23:47:34 karl has joined #css 23:48:33 glenn has joined #css 23:49:31 nmccully has joined #css 23:51:11 jihye has joined #css 23:59:37 drousso has joined #css 00:03:26 romain has joined #css 00:03:28 zcorpan has joined #css 00:03:50 dino has joined #css 00:04:24 nigel has joined #css 00:04:26 topic: testing 00:04:39 aboxhall_ has joined #css 00:04:39 present+ Nigel_Megitt 00:05:05 present+ Florian Rivoal, Invited Expert 00:05:06 stantonm has joined #css 00:05:17 presenting https://docs.google.com/presentation/d/1F1II3lx0krPBIqAzgU9YFIENC-UBEnZtN796hye_bWw/edit?usp=sharing 00:05:18 present+ 00:05:18 scribenick: birtles 00:05:26 present- Invited Expert 00:05:35 mattwoodrow has joined #css 00:05:43 present+ 00:05:48 +1 to wpt documentation improvements. It's much much better! 00:06:10 q+ 00:06:20 present+ Rachel Andrew, Fronteers 00:06:23 q- 00:06:24 AmeliaBR has joined #css 00:06:26 xfq has joined #css 00:06:36 present+ 00:06:42 fergal_daly has joined #css 00:06:58 present+ 00:07:06 present+ 00:08:01 q+ 00:08:15 tantek has joined #css 00:08:23 present+ 00:08:23 q+ 00:08:32 duga has joined #css 00:09:13 ack fantasai 00:09:15 q+ 00:09:20 smfr has joined #css 00:09:24 present+ 00:09:24 fantasai: thank you for updating the docs 00:09:27 present+ 00:09:28 present+ 00:09:28 present+ 00:09:31 q+ 00:09:33 present+ 00:09:42 ... it's great to have everything up front 00:09:44 present+ 00:09:52 ... it would be nice to have a navigation system like a tab bar or footer 00:09:57 ... to connect them all 00:10:07 ... it would be easier to get from wpt.fyi to the docs and back 00:10:20 ... second comment: do we have any plans for testing printing? and paginated modes? 00:10:37 rniwa has joined #css 00:10:53 futhark has joined #css 00:11:04 jgraham: we have talked about it a bit 00:11:07 myles has joined #css 00:11:07 q? 00:11:20 fantasai: do we have any way of helping people find and run and report results for manual tests 00:11:31 ... there are some things that are not automated and are unlikely to be automated in the near future 00:11:42 jgraham has joined #css 00:11:43 foolip: I know Florian does a lot of manual tests 00:11:48 ... the answer is no 00:11:58 ... there is a manual runner on w3test.org but it doesn't work so well 00:12:01 CSSWG_LogBot has joined #css 00:12:04 ... and it doesn't report results in the right format 00:12:12 ... there are not so many building blocks missing 00:12:26 fantasai: that helps close the gaps for the types of the tests for which we don't have infrastructure 00:12:31 ... e.g. printing and media queries 00:12:37 ... I don't know how we'll test media queries 00:12:39 present+ 00:12:45 ... someone should run those 00:12:51 ... e.g. plugging in a monitor 00:13:06 ... if we only run it once, the data will be old 00:13:12 ... we need to be able to run it more frequently 00:13:24 foolip: would it be acceptable if you have to use wpt to run the test? 00:13:28 ... locally wpt run 00:13:50 ... ./wpt run --manual would be less work than a website approach 00:14:00 fantasai: it would be nice if you can load the test on a website 00:14:14 ... but the important thing would be to find the manual tests and then compile a result 00:14:26 ... if you can accept data from Peter's system into wpt reporting system 00:14:29 ... that might be a way 00:14:39 foolip: just converting them would be straightforward I guess 00:14:48 ... but do you want to keep maintaining that? 00:14:57 plinss: I would be happy for it to be replaced 00:15:09 ... once its functions are covered 00:15:22 ... it tracks what git revision of each test is used 00:15:34 jgraham: perhaps we can follow up later 00:16:13 fantasai: minimum requirement is to get a list of manual tests then provide a report of results 00:16:26 foolip: would it be fine to get all the manual tests in a specific directory? 00:16:33 fantasai: yes 00:16:52 florian: if the system is designed so that you have to run all of them, that wouldn't be so convenient 00:17:04 ... there are thousands of tests in writing-modes for example 00:17:16 foolip: if there's no subdirectories then we can maybe use chunking 00:17:26 jgraham: the requirements to run this probably need to be considered in more depth 00:17:39 ... there are data model considerations with regards to wpt.fyi 00:17:46 ... there are lots of technical details 00:18:09 q? 00:18:15 florian: I think it helps breaking the problem down because eventually we want to replace and retire Peter's system 00:18:25 ... even working out how to display manual tests is an interesting problem 00:18:30 ... there might be conflicting reports 00:18:35 karl has joined #css 00:18:48 ... using an existing data source and then working out how to display them later 00:18:58 q+ to discuss scrolling test automation 00:19:00 astearns: we do need to work out how to fix this 00:19:00 ack astearns 00:19:12 astearns: I want to second the joy at the improved documentation 00:19:22 ... I went through the docs to submit a reftest recently and everything was there 00:19:36 ... when I submitted a PR, however, something broken and I didn't know what to do 00:19:52 ... I could see the test results, I submitted another patch and it passed 00:19:59 ... but I don't know how to fix it the first time 00:20:15 ... the first two checks were red and I didn't know what to do about it 00:20:20 ... I didn't want to bother anytone 00:20:26 s/anytone/anyone/ 00:20:31 foolip: please bother us 00:20:35 ... we need to fix this 00:20:48 jgraham: some of this have failed for reasons out of our control 00:20:52 ... e.g. GitHub actions being beta 00:21:05 ... sometimes it takes quite a bit of experience to work out what went wrong 00:21:14 q? 00:21:22 ... there are infrastructure problems but there are also things we can do better 00:21:35 dbaron: is pinging you on #testing the way to reach you? 00:21:37 jgraham: yes 00:21:42 foolip: or on the PR 00:21:57 jgraham: IRC is generally more likely to get attention 00:22:06 ... can get lots on GitHub email 00:22:16 zcorpan: it depends a bit on what it is 00:22:24 ... if it's something you see repeatedly 00:22:30 ... it might be a system bug we need to fix 00:22:37 ... otherwise ping one of us on the PR / IRC 00:22:41 ack florian 00:22:58 florian: in addition to the manual testing, we need 2 more things to retire Peter's tool 00:23:07 ... one is MUST tests vs SHOULD/MAY 00:23:14 ... important for exiting CR 00:23:26 ... the other is that wpt.fyi groups report by directory 00:23:39 fremy has joined #css 00:23:39 ... but using the metadata pulling results by spec not directory would be helpful 00:23:46 ... then we can retire Peter's tool 00:23:55 jgraham: we are working on associating labels with tests 00:24:00 ... I think that would cover these cases 00:24:08 xiaochengh has joined #css 00:24:12 ... if you want that information to be in the test files rather than in metadata 00:24:18 ... then you could have a bot to check they are in sync 00:24:31 florian: currently that data is in the data, the flags meta 00:24:37 ... so we need to sync that with labels 00:24:47 jgraham: that labelling system is quite limited but it is being worked on 00:24:56 ... we could have a script to check they are synced 00:25:17 foolip: if you can search for not labeled tests is that fine? 00:25:29 q? 00:25:29 florian: if there is a button to click that's better, but as long as it's do-able 00:25:38 ... one more question about fuzzy tests 00:25:40 zakim, close queue 00:25:40 ok, astearns, the speaker queue is closed 00:26:00 ... for non-fuzzy reftests we often have problems where one side is don't with Ahem and one is not 00:26:12 ... but the box is quite large... 00:26:20 ... is that covered by fuzzy 00:26:36 jgraham: there are two parameters in fuzzy reftests -- one is the total number of pixels you allow to difffer 00:26:46 ... one is the amount of you allow in difference per color channel 00:27:04 ... so in this case you would allow a very small range in difference per color channel 00:27:25 ... if you specify one number it means exactly this number must be difference, but you can specify a range, e.g. from 0 00:27:45 Rossen_ has joined #css 00:27:55 ... the other thing is that in Gecko we can have meta files that layer over the wpt tests so we can apply different fuzzy parameter for Gecko only 00:28:05 ... e.g. we know our form controls differ 00:28:06 present+ 00:28:20 florian: for the color channel parameter, it sounds like what I want to do 00:28:27 ... but getting the right numbers might be difficult 00:28:39 ... if we can find a way to make that easier that would be good 00:28:45 jgraham: the screenshot tool could do that 00:29:02 dbaron: the gecko reftest failure tells you that -- the failure range 00:29:14 ... makes it easy to know what numbers to use 00:29:37 AmeliaBR: for SVG I have been planning to work around this for SVG reftests 00:29:44 present+ 00:29:50 ... by adding a stroke overline to cover the anti-aliased part 00:29:57 ... not the ideal solution 00:30:14 ... but you can block off the regions where you don't care about differences 00:30:23 ack emilio 00:30:28 emilio: thank you for all your work 00:30:50 ... the tests that keep going to Gecko's internal test suite are crashtests 00:31:06 ... is there any way we can convert them to wpt in the future 00:31:24 jgraham: I think for crashtests the thinking is that it's normally a very browser-specific thing 00:31:31 ... there might be cases where that's not true 00:31:38 bkardell_ has joined #css 00:31:39 ... if we think it's worth doing it's quite do-able 00:31:56 emilio: I can try to see how many of the Gecko crashtests affect other browsers 00:32:23 ack smfr 00:32:26 smfr: thanks for all your hard work 00:32:36 ... getting Safari's stuff working right is great 00:32:54 ... I want to confirm that if a run fails in the middle there's a clear differentiation between failed tests and not run 00:33:14 foolip: if it fails in the middle we don't get results... 00:33:19 inamori_ has joined #css 00:33:34 smfr: I'm interested in cases where a test doesn't not run... it should show up as a fail 00:33:46 foolip: a missing test is better than a fail 00:33:59 smfr: just following up on AmeliaBR's point 00:34:07 karl has joined #css 00:34:07 ... sometimes there are differences we don't care about 00:34:18 ... a number is not sufficient, sometimes you want to obscure the irrelevant part 00:34:35 jgraham: the fuzzy thing is a useful thing, it works in Gecko 00:34:53 ... and when running it locally it will spit out the numbers you need to annotate them 00:35:11 dbaron: the fuzzy number notation is very useful when they are exact numbers 00:35:25 ... since if you get any other kind of number you get an unexpected pass 00:35:29 ack majidvp 00:35:29 majidvp, you wanted to discuss scrolling test automation 00:35:36 majidvp: thank you for adding testdriver annotation 00:35:50 ... for writing scrolling tests, we often need to inject input 00:35:51 s/we don't care about/we do care about in a test with fuzzy parts/ 00:36:16 ... you support pointer actions, what about mouse 00:36:29 foolip: if pointer actions supports it we can do it 00:36:47 jgraham: if it's not in webdriver we can add a feature request for that 00:36:59 topic: Timed Text 00:37:50 nigel: Hi, I'm Nigeal 00:37:56 s/Nigeal/Nigel/ 00:38:07 ... part of this group and the timed text group 00:38:34 ... there are other members of the timed text group here 00:38:40 https://github.com/w3c/ttwg/issues/52 00:38:46 -> https://github.com/w3c/ttwg/issues/52 Joint TTWG/CSS isses 00:38:49 s/isses/issues 00:40:07 nigel: I want to go through the issues in the order they're listed 00:40:43 futhark has joined #css 00:41:53 Topic: Supporting "not within an EM" at text-combine-upright and tts:textCombine for 縦中横 'tate-chu-yoko' 00:42:23 -> https://github.com/w3c/tt-module-cjk-ext-1/issues/1 00:42:37 zcorpan has joined #css 00:42:47 smfr has joined #css 00:42:50 ... This is about text-combine-upright, tatechuuyoko / 縦中横 00:42:52 pal has joined #css 00:43:02 ... the request was to say not to put it in 1em 00:43:02 zcorpan has joined #css 00:43:07 ... to take up more than 1em 00:43:23 q+ 00:43:34 nmccully: the normal way of spacing these characters is that the first two kanji should be flush 00:43:47 zakim, open queue 00:43:47 ok, astearns, the speaker queue is open 00:43:52 q+ koji 00:44:00 gkatsev has joined #css 00:44:02 q? 00:44:14 ... in the example on the screen, when the characters can't be included in the line height, they might be allow to intrude into the sides of the line without making the line any taller 00:44:28 ... then the line won't be any further away than it is 00:44:34 ...the other way is to scale the glyphs 00:44:54 koji: this feature is being considered in writing modes level 3 00:44:56 ack koji 00:45:05 testcase: http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cp%20style%3D%22writing-mode%3A%20vertical-rl%22%3E%E4%B8%AD%3Cspan%20style%3D%22text-combine-upright%3A%20all%22%3E2222%3C%2Fspan%3E%E6%96%87%3C%2Fp%3E 00:45:11 ... but we didn't include it because it makes it more complicated particularly when ruby is included 00:45:18 ... it complicates the spec and it's not clear how it should work 00:45:28 ... and the author can work around using inline blocks 00:45:50 ... the layout is slightly different from the optimized text-combine-upright but it's almost the same using an alternate flow 00:46:09 nmccully: this is a common thing though so to reject it for the case of decoration being difficult 00:46:18 ... makes it difficult for the 80~90% case 00:46:25 ... by requiring authors to do a workaround 00:46:33 ... it seems like a lot to ask for the non-decorated case 00:46:43 myles: ruby has this concept over overhang too 00:46:48 I'd note 民國108年 is a good real example (and common in Taiwan) for the 3-digit case. 00:46:49 ... and that's not controllable by css 00:46:58 ... is this a similar thing that the browser should just do? 00:47:16 fantasai: it's not a new CSS property, it's just a different way of doing text-combine 00:47:34 florian: is this an author choice? Or the browser does the right thing thing? 00:47:37 fantasai: an author choice 00:47:54 AmeliaBR: the current spec gives a limit for how many characters to compress 00:48:06 glenn: the question was "how does the author express a preference"? 00:48:19 koji: they can use a line block to do this 00:48:21 s/to compress/but then beyond that it goes to vertical, not horizontal overflow/ 00:48:38 nmccully: can you still get the same width of the line block doing that? 00:48:46 s/but then beyond that it goes to vertical, not horizontal overflow/to compress, but then beyond that it goes to vertical, not horizontal overflow/ 00:48:47 ... or will there be some small space that messes up the layout? 00:49:17 stantonm: there are two ways you could do it.. you could compress the font size 00:49:32 xiaochengh has joined #css 00:49:33 myles: my question is this additive or a bug we're fixing? 00:49:47 nmccully: the scaling is a less desired behavior from a typographer's point of view 00:49:55 ... we've also tried to work out what the default should be 00:49:58 testcase: 00:49:58 http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cbody%20style%3D%22height%3A%2010em%22%3E%0A%3Cp%20style%3D%22writing-mode%3A%20vertical-rl%22%3E%E4%B8%AD%3Cspan%20style%3D%22text-combine-upright%3A%20all%22%3E2222%3C%2Fspan%3E%E6%96%87%E4%B8%AD%3Cspan%20style%3D%22display%3A%20inline-block%3B%20writing-mode%3A%20horizontal-tb%22%3E333%3C%2Fspan%3E%E6%96%87%3C%2Fp%3E 00:50:03 ... most of the time you see this in dates 00:50:10 ... and dates often use scaled glyphs 00:50:31 ... with variables going forward we hope font designers can be more involved with scaling glyphs so they scale well and don't disturb the line height 00:50:44 updated testcase: 00:50:44 http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cp%20style%3D%22writing-mode%3A%20vertical-rl%3B%20height%3A%2010em%22%3E%E4%B8%AD%3Cspan%20style%3D%22text-combine-upright%3A%20all%22%3E2222%3C%2Fspan%3E%E6%96%87%E4%B8%AD%3Cspan%20style%3D%22display%3A%20inline-block%3B%20line-height%3A%201%3B%20writing-mode%3A%20horizontal-tb%22%3E333%3C%2Fspan%3E%E6%96%87%3C%2Fp%3E 00:50:48 ... for the Web the preference you currently have--biasing to make everything fit--it fine 00:51:01 ... overhang is more of a print thing 00:51:17 q? 00:51:44 AmeliaBR: this suggested layout is going to affect your line-spacing? 00:52:31 fantasai: because it's an inline block it doesn't include the extra line-spacing so it might fit within the line height 00:52:40 nmccully: so this shows it is possible in the browser 00:52:48 florian: this example doesn't show where ruby goes 00:53:06 pal: not scaling is very common practice 00:53:16 ... in 100% of Japanese subtitles it doesn't scale 00:53:45 fantasai: one of the bad things about this is text-emphasis doesn't work how you would want with the inline-block approach 00:53:52 koji: this is not too rare in publishing 00:53:56 smfr has joined #css 00:54:00 ... compression doesn't give good glyph shapes 00:54:05 ... some authors prefer not to compress 00:54:11 ... in a single page, authors don't compress 00:54:11 I wonder if that underline behavior is just the result of text-decoration-skip-inc 00:54:19 -ink 00:54:23 ... but when the text has ruby or decorations, that do compress 00:54:34 with text-emphasis and text-decoration: http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cp%20style%3D%22writing-mode%3A%20vertical-rl%3B%20height%3A%2010em%22%3E%E4%B8%AD%3Cspan%20style%3D%22text-combine-upright%3A%20all%22%3E2222%3C%2Fspan%3E%E6%96%87%E4%B8%AD%3Cspan%20style%3D%22display%3A%20inline-block%3B%20line-height%3A%201%3B%20writing-mode%3A%20horizontal-tb%22%3E333%3C%2Fspan%3E%E6%96%87%3C%2Fp%3E 00:54:38 ... if they don't have decorations, they use inline-block, otherwise they use text-combine 00:54:52 pal: I'd like an action item / next steps 00:55:00 AmeliaBR: file an issue on the CSS repo 00:55:09 fantasai: advanced writing modes level 4 00:55:23 s/advanced/against/ 00:55:48 nigel: also an action to go back to reporter and suggest the best practice we discussed 00:56:14 fremy has joined #css 00:56:17 pal: text combine covers 0% of use cases within the domain of subtitling 00:56:49 florian: an inline block it's a reasonable thing to use when you don't need emphasis, but if we put something in the spec, we need it to work in all cases 00:56:51 plh has joined #css 00:57:05 rrsagent, pointer 00:57:05 See https://www.w3.org/2019/09/15-css-irc#T00-57-05 00:57:17 AmeliaBR: if you can get pictures of actual typography that does those things, that would be wonderful 00:57:31 pal: so ruby, emphasis on both sides 00:57:37 florian: maybe background colors 00:57:49 iank_: does it contribute to the scrollable overflow? 00:58:19 myles: I think CSS should have facilities for this 00:58:30 inamori_ has joined #css 00:58:41 nigel: moving on to issue 2983 00:58:47 Agree that the basic feature request, for a new text-combine-upright value for a common typographic pattern, is strong 00:59:02 github: 00:59:04 github: https://github.com/w3c/csswg-drafts/issues/2983 00:59:05 ... this is about CJK and supporting shearing 00:59:05 github: https://github.com/w3c/csswg-drafts/issues/2983 00:59:16 github: none 00:59:22 Topic: Shearing Vertical Text 00:59:25 github: https://github.com/w3c/csswg-drafts/issues/2983 01:00:08 bobbytung has joined #css 01:00:14 pal: today there's the ability to specify slant on individual characters using oblique 01:00:16 ... or italic 01:00:33 ... sometimes it's useful to apply shear not on character-by-character but entire line 01:00:45 ... that's desirable to apply alignment between ruby and base text 01:00:52 ... it's subtle but really matters to folks that care 01:01:17 ... separate issue about whether or not we should be able to specify the angle of shear per-character 01:01:25 ... issue here is applying by the whole line 01:01:29 karl has joined #css 01:01:48 nmccully: in print, it's not keeping the height/width of the line when you shear it 01:02:04 ... you change the shape of the box of each character to a diamond 01:02:08 ... it's call shatai in Japanese 01:02:14 https://helpx.adobe.com/ch_fr/indesign/using/formatting-cjk-characters.html 01:02:18 this is what Nat is talking about 01:02:20 ... in subtitles has it become just a shear? 01:02:31 pal: it seems to be just a one-dimensional thing in subtitles 01:02:45 ... not sure if it's an artistic desire or technical limitation 01:02:52 koji: the difference here is a position of the ruby, right? 01:02:55 pal: yes 01:03:17 koji: I'm not sure about this use case, but for me changing the position of the ruby looks to me 01:03:30 ... shearing the individual characters looks better to me 01:03:50 pal: on the thread some others seem to prefer shearing the whole line 01:04:05 fantasai: for print we know they want the per-character approach 01:05:15 jcraig has joined #css 01:05:22 ... so I suggest we propose that and take that to the subtitle group and see if that is acceptable 01:05:40 ... it's possible that the request here for shearing the whole inline-block is just coming from technical limitations 01:05:55 pal: I like the idea of going back and asking questions 01:06:17 ... but the issue opened against ttml was specifically about not being able to shear the whole block 01:06:33 fantasai: I thought the problem was that italics shears in the wrong direction 01:06:55 koji: can you point to specific individual / issue so I can follow up 01:06:59 q+ 01:07:10 koji: I can't see any ruby in that issue 01:07:12 fremy has joined #css 01:07:16 Rossen__ has joined #css 01:07:16 https://w3c.github.io/ttml2/index.html#style-attribute-shear 01:07:22 HeWenli has joined #css 01:07:36 text-combine-upright does look bad with individual character shear: https://github.com/w3c/ttml2/issues/784#issuecomment-390856934 01:07:48 https://github.com/w3c/ttml2/issues/784 01:07:49 florian: you said we want to shear the entire line OR paragraph 01:07:53 ... these are two things 01:08:05 ... for the second option, CSS transforms will do it 01:08:17 pal: ttml can do all three: character, line, paragraph 01:08:39 florian: the difference with ruby is more subtle 01:08:50 ... but the text combine upright case is more obviously different 01:09:06 pal: the issue in 2983 shows a good example 01:10:02 ... 2983 ends with a question I asked 01:10:23 myles: any proposal for how the author would describe to the browser the effect they desire 01:10:29 pal: yes there is a proposal there 01:10:34 myles: so a new property? 01:10:49 ... has anyone considered re-purposing the new syntax for font-style to describe the shearing? 01:10:55 glenn: no I have not 01:11:26 ... we introduced three new properties: shear (block), line-shear (per-line including tatechuuyoko), font-shear (glyph box by glyph box) 01:11:44 myles: one option would be to have font-style: oblique -14deg does shear 01:11:53 ... and if it looks bad it's a browser bug 01:12:08 fantasai: I don't think it will look good if there is latin text involved 01:12:17 myles: there's an issue in the agenda for that later today 01:12:33 fantasai: I don't think we can mix this with the oblique/italic feature 01:13:16 nmccully: It's complicated to have these different properties, but I agree with fantasai's desire to have a separate feature for this 01:13:47 ... to say I want to shear these things correctly, and provide an angle, and let the UA decide how to do it (especially for mixed text) 01:13:59 koji: I agree with myles and don't understand why specifying an angle doesn't work 01:14:10 ???: because the fonts 01:14:17 koji: what exactly doesn't work? 01:14:31 myles: my proposal is that the font-style property does more than just font selection 01:14:41 ... it does font selection as it does today and also does the transform as necessary 01:14:57 pal: the way this was explained to me is that the desired effect was literally just shearing 01:15:14 koji: we understand, but the point is there are other glyph shearing use cases 01:15:18 ... that is what myles is proposing 01:15:42 pal: we need to understand three distinct use cases: per block, per line, per character 01:15:51 s/???: because the fonts/nigel: you're asking a lot of the implementation and reducing authoring flexibility 01:16:06 koji: we have per block already, myles is proposing per-character 01:16:17 ... we are wondering what is needed for line shearing 01:16:39 fantasai: this example on the screen shows why we can't cover the line case with the same per-glyph approach 01:16:59 ... the characters all shear in different directions when using font-style: oblique 01:17:13 (example includes mixed CJK and vertical and horizontal latin) 01:17:20 myles: yes, we want to discuss this later today 01:17:27 jgraham has left #css 01:17:29 +1 for keeping this logically separate; too confusing when mixing latin and upright scripts 01:17:53 nigel: I think we've understood the use case better, any proposal action? 01:18:06 fantasai: CSS definitely needs to solve the per-character shearing 01:18:11 ... block shearing is solved 01:18:31 ... open question about if more is needed for line-shearing 01:18:47 pal: for block shearing, transform shears the background too. Is that ok? 01:18:54 AmeliaBR: you need a wrapper element if you want to avoid that 01:19:31 pal: does the size change too for the block too? 01:19:41 ... it doesn't so it extends beyond the background 01:19:59 ... any chance of a shear property that affects block size? 01:20:04 myles: transforms that affect layout? 01:20:05 pal: yes 01:20:19 AmeliaBR: it could be a dedicated block shear property 01:20:30 futhark has joined #css 01:20:35 florian: the general solution for transforms that affect layout is hard 01:20:43 ... a limited use case could be ok 01:20:50 fremy has joined #css 01:20:54 pal: just reacting to the idea that block shearing is solved 01:21:29 Topic: Aligning an aligned block of text within its container 01:21:38 https://github.com/w3c/csswg-drafts/issues/1975 01:21:39 github: https://github.com/w3c/csswg-drafts/issues/1975 01:21:42 futhark_ has joined #css 01:21:42 rniwa has joined #css 01:21:53 nigel: action was with us to check that the draft spec text was ok 01:21:58 draft spec: https://drafts.csswg.org/css-text-4/#text-group-align-property 01:22:06 pal: I haven't had a chance to look. What's the right way to test it? 01:22:14 nigel: there's draft spec, but no tests 01:22:16 duga has joined #css 01:22:34 ... what is the best thing is to do to create those tests 01:22:47 ... we don't have any perspective on implementation 01:22:50 florian: it's not implemented 01:23:27 fantasai: to get it implemented, write tests, convince browsers to implement it, hire Igalia, implement it yourself 01:23:50 florian: as far as the WG is concerned, if the spec is done, there's not much more we can do 01:23:56 AmeliaBR: it would be great to have pictures in the spec 01:24:09 ... if you are keen on the feature, adding pictures and use cases would help 01:24:28 pal: so create a new PR with examples? 01:24:31 all: yes 01:25:07 kurosawa has joined #css 01:25:29 topic: Images with layout information 01:25:39 github: https://github.com/w3c/csswg-drafts/issues/4116 01:25:55 myles: when we discussed this, we talked about annotating images with baseline information 01:26:02 ... is there an image format for subtitles? 01:26:10 nigel: same image format as elsewhere 01:26:25 topic: create a display property value for visually hiding an element while making it available for AT 01:26:32 github: https://github.com/w3c/csswg-drafts/issues/560 01:26:40 nigel: this comes up a lot in subtitles and captions 01:26:55 ... the desire to be able to make text available to the screenreader while not visually displaying it 01:27:17 ... this is particularly important for subtitles because there is a video behind it which might be showing text, for example 01:27:32 ... so we don't need a subtitle necessarily but we want to expose it to a screenreader 01:27:42 ... there are hacks to do this 01:27:53 ... perhaps a display property value 01:27:59 fantasai: this exists in the speech module level 1 01:28:03 ... property is speak 01:28:13 ... initial is 'auto' which defers to display 01:28:29 ... but not implemented it 01:28:33 futhark has joined #css 01:28:36 ... 'never' and 'always' 01:28:48 AmeliaBR: display: none has so many other affects other than just hiding 01:29:01 fantasai: we have a spec but no one is interested in implementing it 01:29:09 nigel: the request is not to speak it 01:29:14 ... it is to make it visible to the screenreader 01:29:23 ... it might be presenting it in some other way 01:29:28 AmeliaBR: braille display etc. 01:29:51 Rossen__: you can use visibility: hidden 01:29:59 ... and refer to it via aria-description etc. 01:30:05 AmeliaBR: as the label of a different element 01:30:23 nigel: if you're just labeling an element then the screenreader might just read that once 01:30:32 ... but this is an element whose contents is live 01:30:36 ... it needs to read it when it changes 01:30:52 bobbytung has joined #css 01:31:00 AmeliaBR: there are many demands this feature beyond the captioning use case 01:31:11 ... I'm sure the accessibility people who come in after the break would be happy to talk about it 01:31:26 nigel: perhaps we can cover it in that session 01:31:40 futhark_ has joined #css 01:32:18 github: end topic 01:32:23 github-bot: end topic 01:38:18 mattwoodrow has joined #css 01:39:00 bobbytung has joined #css 01:41:19 smfr has joined #css 01:43:22 drousso has joined #css 01:50:57 kurosawa has joined #css 01:56:46 IanPouncey has joined #css 01:59:18 romain has joined #css 01:59:26 Rossen__ has joined #css 02:01:27 inamori_ has joined #css 02:01:33 leaverou_ has joined #css 02:01:55 tink has joined #css 02:02:00 duga has joined #css 02:02:14 present+ Léonie (tink) 02:02:26 futhark has joined #css 02:02:51 futhark has joined #css 02:03:02 zcorpan has joined #css 02:05:08 present+ 02:06:06 xfq has joined #css 02:06:38 dauwhe_ has joined #css 02:07:10 present+ mck 02:07:37 pal has joined #css 02:07:41 present+ 02:07:49 present + 02:08:08 jamesn has joined #css 02:08:31 Roy has joined #css 02:09:00 present+ 02:09:12 stantonm has joined #css 02:09:59 inamori_ has joined #css 02:10:21 ScribeNick: fantasai 02:10:30 Topic: Accessibility-CSS Joint Meeting 02:10:37 mhakkinen_ has joined #css 02:10:46 Irfan has joined #css 02:11:05 achraf has joined #css 02:11:13 present+ 02:11:16 present+ 02:11:29 dlibby_ has joined #css 02:11:30 bobbytung has joined #css 02:11:35 Janina: FYI but need support from CSS 02:11:45 Matt_King_ has joined #css 02:11:47 Janina: We have a lto of user requirements about using better for user style sheet things 02:11:59 Janina: Controlling animations was a need, can do , wasn't aware but that's great 02:11:59 chrishall has joined #css 02:12:09 Janina: But need to be able to control spacing between words and between punctuation 02:12:16 Janina: Can be done on user side, I believe? 02:12:25 Janina: Seems youhave to be an expert user, invoke the htings 02:12:39 Janina: Make that more usable, would appreciate CSSWG support on that 02:12:49 Janina: WCAG guidelines are quite regulatory 02:13:00 Janina: help to get technological solutions sorted 02:13:06 Janina: and built into browsers 02:13:19 present+ 02:13:21 (Better browser support for user style overrides would be wonderful, but yes, probably outside of our realm to specify.) 02:13:26 Janina: Cognitive and learnign disabilitys and low-vision requirements 02:13:35 Janina: Would it be reasonable to control flashing? 02:13:42 present+ 02:13:45 florian: There was a long list of things you might want to control in your requirements 02:13:56 florian: not sure we have solution for every single one, but many are things that authors can control 02:14:01 florian: and we do have notion of user style sheets 02:14:02 joanie has joined #css 02:14:11 florian: this is a notion, doesn't have to be a style sheet written in CSS by programmers 02:14:22 florian: perfectly OK for User Agent to have a UI that sets these rules 02:14:29 jemma has joined #css 02:14:30 q+ 02:14:32 florian: cascade then says how the user prefs and author prefs interact 02:14:38 ack fl 02:14:43 florian: but usability of making settings is a UA issue 02:15:01 jcraig: For motion, have prefers-reduced-motion implemented across browses now 02:15:09 jcraig: media features and web pages can adapt to them 02:15:31 jcraig: that seems to be solved wrt CSSWG, but usabitiliy can improve 02:15:49 Janina: Audio, killing all sounds. Part of browser config 02:15:58 jcraig: want sounds on device but not pages? 02:16:06 janina: bubbling up out of ? 02:16:15 florian: we don't generate sounds in CSS generally, so don't have a way to turn off 02:16:19 rniwa has joined #css 02:16:26 myles: desktop browsers have ability to shut off sounds per tab 02:16:42 janina: spacing: interlinear, inter-word, punctuation 02:16:47 jcraig: letter-spacing available since CSS2.1 02:16:54 s/?/COGA (cognitive)/ 02:16:58 jcraig: not easy for users to define, but outside scope of CSSWG to solve 02:17:14 florian: spacing after punctuation specifically is not something we can control on author and user side 02:17:35 janina: request to have more space around punctuation 02:17:49 sounds like a feature request 02:17:49 q+ 02:18:12 fantasai: We do have word-spacing property, but nothing for spacing around punctuation 02:18:19 janina: can add? 02:18:25 q? 02:18:35 fantasai: depends, do you want different spacing at end of sentence vs after abbreviation? We don't know where the end of the sentence is 02:18:49 florian: spacing requirements are also quite dependent on language 02:19:01 florian: various conventions, requirements per language/writing-system 02:19:07 florian: so hard to make that work globally 02:19:43 fantasai: that's language specific 02:20:03 ... a lot of the learning dsiabilityies require -- I would require more spacing after phrases, or sentences, things that need linguistic analysis 02:20:08 ... it's a bit difficult to solve on the CSS side 02:20:16 Myles mentioned text-spacing: punctuation 02:20:16 ... but could be solved with CSS and a browwser extension maybe 02:20:28 q? 02:20:29 ack jcr 02:20:38 Jemma_ has joined #css 02:20:38 s/language specific/typographic mainly/ 02:20:41 ack dauwhe_ 02:21:04 smfr has joined #css 02:21:05 dauwhe_: there's a weird property by Prince called text-replace, we can replace certain characters with e.g. space-punctuation sequence 02:21:23 Rossen__: We have one issue remaining from TTML 02:21:38 astearns: will cover after 02:21:52 janina: next issue, we agreed to do an Accessibility API Mappings with CSS 02:22:05 prince-text-replace: https://www.princexml.com/doc-refs/#prop-prince-text-replace 02:22:06 janina: some people volunteered to edit 02:22:08 bobbytung has joined #css 02:22:13 janina: so will be sending a draft 02:22:31 Zoe Bijl and Joanie Diggs 02:22:32 janina: Joanie will bring a11y expertise 02:22:41 janina: Zoe will bring CSS knowledge 02:22:50 janina: Will specify how to standardize across OSes 02:22:59 janina: Unless questions about that, move on to next issues 02:23:32 jcraig: had issue about dynamic text size, which is CSS issue ??08 02:23:39 astearns: ok next issue... 02:23:47 s/??08/3708/ 02:23:50 issue-3708 02:23:50 Sorry, but issue-3708 does not exist. 02:23:50 Topic: Display property value for visually hiding element while making available to assistive tech 02:24:01 astearns: brought up by TTML also 02:24:18 https://github.com/w3c/csswg-drafts/issues/3708 02:24:24 astearns: question is how to move forward on this capability 02:24:29 dino has joined #css 02:24:30 github: https://github.com/w3c/csswg-drafts/issues/3708 02:24:57 AmeliaBR: The general use case is when you have text that adds a little extra information for assitive technology but either repeats something already visually on the page 02:25:01 github: https://github.com/w3c/csswg-drafts/issues/560 02:25:06 AmeliaBR: or is text that is already obvious because of other visual cuse 02:25:08 s/cuse/cues/ 02:25:19 AmeliaBR: so don't want to print the text, but want available to a11y 02:25:31 AmeliaBR: there are methods used by authors using absolute positioning or clip 02:25:47 AmeliaBR: intentionally picked by authors because not currently used as cues to screen readers to hide the text 02:25:53 Jemma_ has left #css 02:25:54 AmeliaBR: so feature requests coming to ARIA and CSS 02:26:01 AmeliaBR: is to have a simple one property one attribute way to do this 02:26:07 AmeliaBR: there are ways in specs defined to do this 02:26:15 Example of what AmeliaBR is referencing:

Read more About widgets

02:26:17 AmeliaBR: there's aria-hidden=false, originally specified to do this 02:26:25 q? 02:26:26 AmeliaBR: there is the 'speak' property in CSS Speech module 02:26:34 https://www.w3.org/TR/css-speech/#speaking-props-speak 02:26:37 hidden=true aria-hidden=false 02:26:39 present+ leaverou 02:26:58 AmeliaBR: neither of these is implemented because in reality the visual display property has all sorts of side-effects in how elements are processed 02:27:04 aria-hidden=true was problematic for a variety of reasons 02:27:09 AmeliaBR: and saying 'display: none' or visually hidden but still available to AT 02:27:14 AmeliaBR: has never happened in borwsers 02:27:17 s/=true/=false/ 02:27:19 AmeliaBR: so feature request is for specific way to do things 02:27:34 AmeliaBR: in ARIA yesterday had a talk about, is this really use case pattern we want to encourage by making it easier to do? 02:27:44 AmeliaBR: visually-hidden styles can be misused by developers 02:27:53 AmeliaBR: who are only thinking about visually-able vs. blind users 02:28:03 AmeliaBR: missing a huge swath of people usign both AT and visual rendering 02:28:13 AmeliaBR: so argument that this is a hacky approach for a reason, shouldn't make it easier 02:28:26 AmeliaBR: but it is widely-used on the Web anyway, so argument for paving that cowpath 02:28:35 AmeliaBR: my recommendation is to go ahead with this 02:28:38 AmeliaBR: and do it in CSS 02:28:44 AmeliaBR: because sometimes visually-hidden content depends on MQ 02:28:49 q+ to remind the group that many (most?) screen reader users are not completely blind... 02:28:51 AmeliaBR: e.g. button might have icon and text on big screen 02:28:56 AmeliaBR: but on small screen only the icon 02:29:06 AmeliaBR: but want AT to be able to see that text 02:29:08 q+ 02:29:13 ack jcraig 02:29:14 jcraig, you wanted to remind the group that many (most?) screen reader users are not completely blind... 02:29:21 jcraig: I think this is valuable and needed 02:29:36 jcraig: but remind group that most screen reader users are not blind 02:29:46 jcraig: there are a lot of low-vision users 02:30:00 jcraig: ~ 1/5 are actually blind 02:30:12 q+ to point out that for text to describe media content the solution has to work in an ARIA live context 02:30:17 ack florian 02:30:21 astearns: Amelia's comment was that this is a bad assumption some authors make, shouldn't encourage 02:30:24 Q+ 02:30:35 florian: the reason why neither ARIA attr or speak has been easy to implement 02:30:42 florian: is because AT works by reading plain text off the render tree 02:30:45 florian: this is the reality today 02:30:51 florian: can't ignore it 02:31:00 florian: but causes many problems 02:31:04 florian: exposing info to AT 02:31:11 florian: I hope this is merely current reality 02:31:16 florian: and not long-term goal we want to maintain 02:31:25 florian: because in that case many limitations 02:31:36 florian: there are many cases where we would want to work from DOM, not render tree 02:31:37 r12a has joined #css 02:31:42 florian: because render tree has lost information that's in the DOM\ 02:31:53 florian: I think we will see that problem in a number of use cases 02:32:12 florian: I would like us to not abandon idea that aria / display proposals 02:32:20 ack nigel 02:32:20 nigel, you wanted to point out that for text to describe media content the solution has to work in an ARIA live context 02:32:25 florian: I hope this is taken as a current situation, not a design goal, because otherwise many things cannot be solved 02:32:41 nigel: Some of the proposed solutions/hacks might not work for ARIA live environment 02:32:52 nigel: for ? put forward this morning, want something that describes content in a video 02:32:53 q+ to mention that WebKit was the one engine that implemented `hidden=false aria-hidden=true` and I can discuss some of the implementation details 02:32:57 nigel: gets read out during playback of video 02:33:02 nigel: want to use ARIA live region approach 02:33:05 nigel: and have AT notice that 02:33:13 s/live environment/live regions/ 02:33:17 s$that aria / display proposals$that aria / speak proposals$ 02:33:18 nigel: biggest gap we have is something that, following from florian's point, here is some text from render tree 02:33:25 nigel: don't actually paint pixesl for it, leave layout alone 02:33:36 nigel: atm visibility: hidden has effect that some screen readers don't read it out 02:33:42 nigel: I would separate visibilty from display 02:33:50 nigel: I would expect display: none to never feature in a display 02:33:55 nigel: but visibilty is not rich enough 02:34:14 fantasai: visibility hidden currently leave things in the layout tree 02:34:20 fantasai: so they take up space 02:34:27 q+ to say that there are more assistive technologies than screen readers 02:34:29 fantasai: we probably want variant that doesn't 02:34:37 jcraig: technique used is positionign off-screen and clipping 02:34:42 nigel: want something more proper 02:34:43 s/variant/a variant/ 02:34:44 astearns: and more simple 02:34:54 ack tink 02:34:56 tink: I'm really strongly in favor of this proposal 02:35:03 tink: than existing methods, which cause alls orts of problems 02:35:17 tink: can confirm that visibility: hidden does get hidden from screen readers 02:35:26 tink: if we go ahead with an idea like this attribute 02:35:30 tink: what will we do with tab focus? 02:35:40 tink: techniqe that jcraig describes 02:35:46 tink: tab focus disappears off screen 02:35:55 tink: some renderers will screw up rendering as a result 02:36:01 tink: would there be some mechanism to get around that problem? 02:36:15 AmeliaBR: that's a very good argument for a proper bult-in feature 02:36:21 AmeliaBR: then browser knows to override hiding and make things visible 02:36:31 AmeliaBR: with current techniques, up to author to have a special focus rule 02:36:38 AmeliaBR: to handle that case 02:36:53 AmeliaBR: strong argument to have dedicated feature so browser knows why this style is being set, and to override 02:37:02 tink: so if was focusable content hidden, once it got focus would become visible 02:37:10 tink: makes visible, but if contents appear from off-screen, that would be quite disruptive 02:37:27 tink: is there a possibility to do it the other way around, take things outside of focusability? 02:37:32 AmeliaBR: that wouldn't help with skip links 02:37:45 tink: screenreaders have much better ways to navigate content 02:37:52 tink: skip links are mainly useful for sighted suers 02:37:58 futhark has joined #css 02:38:02 s/sighted suers/sighted keyboard users/ 02:38:08 plh has joined #css 02:38:11 florian: would be problem to make things visible without author expecting it 02:38:16 florian: likely to break things 02:38:21 q+ 02:38:26 florian: would rather make it not visible, invoke HTML inert behavior 02:38:37 florian: author can pop things into visual space if they want 02:38:43 Matt_King_ has joined #css 02:38:45 AmeliaBR: or maybe two different values of a property, recognize different use cases 02:39:00 AmeliaBR: standard skip link that should become visible 02:39:05 AmeliaBR: and extra information for screen readers 02:39:08 q? 02:39:41 ack me 02:39:41 jcraig, you wanted to mention that WebKit was the one engine that implemented `hidden=false aria-hidden=true` and I can discuss some of the implementation details 02:39:47 ack jcraig 02:39:57 jcraig: couple techniques mentioned, one seemed reasonable was HTML hidden=false 02:40:04 jcraig: aria-hidden=true 02:40:08 jcraig: or reverse of that rather 02:40:08 q+ to reply 02:40:14 jcraig: webkit was the only browser to implement 02:40:24 bobbytung has joined #css 02:40:27 jcraig: was very tricky, because webkit builds accessibiltiy tree off of render tree 02:40:34 jcraig: this was after fork from blink, so blink doesn't have 02:40:35 Judy has joined #css 02:40:37 jcraig: firefox same thing 02:40:40 jcraig: so very challenging 02:40:42 jcraig: after noticing bugs 02:40:51 jcraig: decided to only allow this if every ancestor above was displayed 02:41:00 jcraig: so child node could be hidden, but not descendant 02:41:02 present+ Judy 02:41:07 jcraig: not sure that's the right path, but is the one available atm 02:41:21 jcraig: technique in the ARIA spec, aria-hidden=false not recommended 02:41:23 ack nigel 02:41:23 nigel, you wanted to reply 02:41:34 jcraig: hidden=true aria-hidden=false 02:41:58 nigel: interaction between attributes and CSS properties not clear in spec, and varies in implementations 02:42:11 nigel: there some weird stuff going on there 02:42:17 nigel: my conclusion was to ignore HTML hidden 02:42:31 jcraig: on WebKit side, implementation was hidden=true { display: none; } 02:42:48 Rossen__: Edge actually supports everything you said about computing aria and various permutations 02:42:59 Rossen__: there is an effort that was in EdgeHTML 02:43:13 Rossen__: have ongoing work in Chromium to add additional capabilities to handle that n Chromium-based browsers 02:43:18 Rossen__: not sure where Mozilla is 02:43:23 jcraig: no plans last I heard 02:43:37 ack ZoeBijl 02:43:37 ZoeBijl, you wanted to say that there are more assistive technologies than screen readers 02:43:48 ZoeBijl: Want to remidne veryone that there are more AT than just screenreaders that might be affected by this stuff 02:44:00 ack jamesn 02:44:16 ?: displaying something ... 02:44:26 ?: Issue of deliberately making things visible 02:44:28 s/?/jamesn/ 02:45:01 jamesn: another use case is when you have native HTML control that you do not want to display but you want to use all of the properties that you get for free 02:45:12 jamesn: e.g. range control, can't increment/decrement unless native 02:45:17 jamesn: but can't sytle it properly 02:45:23 jamesn: so hide it, and display your own control over it 02:45:29 smfr has joined #css 02:45:35 jamesn: common authoring technique right now, because can't make controls accessible on moble 02:45:49 jamesn: is one custom control for visual, and one hiden native control for interaction 02:45:58 jamesn: hidden using very low opacity so stll there 02:46:03 jamesn: you wnat it to not be inert in this case 02:46:24 scribe: nigel 02:46:32 fantasai: we've heard a lot of new info in this meeting 02:46:37 fantasai: we've heard a lot of new information 02:46:43 .. next step is someone to draft a proposal for a new CSS property or value 02:46:43 Matt_King has joined #css 02:46:46 .. probably a property 02:46:51 ericc_ has joined #css 02:46:52 display value? 02:46:56 .. that takes into account the use cases here and the various limitations 02:47:05 .. I haven't heard a proposal yet. 02:47:15 astearns: https://github.com/w3c/csswg-drafts/issues/560 02:47:15 astearns: Is there a specific CSS spec for this? 02:47:21 s/spec/issue 02:47:31 fantasai: We definitely don't want to use the display property for this. 02:47:34 .. too many other effects. 02:47:45 .. There is an existing property in the speech module called speak 02:47:53 q+ 02:48:00 .. which was intended for this use case but it doesn't address the issues of the render tree and focusability 02:48:13 jcraig: I've evidence that it was never intended to address this 02:48:29 HeWenli has joined #css 02:48:35 zcorpan has joined #css 02:48:36 .. it's well specced for DAISY 02:48:39 jcraig: css-speech is very well-specced for DAISY use case, not for screenreader 02:48:45 scribe: fantasai 02:48:46 ack jcraig 02:48:48 ack me 02:49:00 astearns: need a volunteer 02:49:23 astearns: lacking a volunteer, keep the issue open and periodically ping people 02:49:30 tink: can try to put words together but need someone on CSS side 02:49:34 AmeliaBR: I can help 02:49:42 ACTION: Amelia and tink to draft a proposal 02:49:43 Created ACTION-883 - And tink to draft a proposal [on Amelia Bellamy-Royds - due 2019-09-24]. 02:49:48 I can also help. 02:49:50 astearns: and bkardell_ 02:50:47 Topic: ??? 02:50:52 futhark has joined #css 02:51:01 github: https://github.com/w3c/csswg-drafts/issues/3870 02:51:03 krit: To summarize issue here, we ahve a spec where animations are appleid to transforms in the transforms spec with combination of SMIL 02:51:09 krit: but I think this entire section shoudl be removed 02:51:14 s/???/accessibility section in transforms 02:51:33 Jemma_ has joined #css 02:51:40 krit: section introduces transform to the animate and set elements, both SMIL elements that refer to svg aniamtions 02:51:44 krit: in addition to what is in SVG already 02:51:50 krit: but there is no ? and no interest to implement 02:51:56 krit: so request to either defer or remove entirely 02:52:09 krit: if section gets removed, then there's nothing about motion in the spec anymore 02:52:26 AmeliaBR: issue is just asking you to add an accessibiltiy section? 02:52:33 krit: issue was about adding section about accessibility 02:52:45 krit: but we removed the section reference to motion, so no need for adding an accessibility section 02:53:13 AmeliaBR: one paragraph of animating transforms can be bad ? 02:53:23 fantasai: anything can be animated, width, margins, etc. do we add to every layout feature of CSS? 02:53:33 fantasai: I think better to keep in the animation section 02:54:04 AmeliaBR: so requesting to clsoe this issue as wontfix and follow up with getting it addressed in CSS Animations 02:54:14 krit: yes, but request woudl be to defer the entire feature 02:54:25 krit: if we want to do that, would suggest to try with SVGWG or SVGCG first 02:54:38 dauwhe has joined #css 02:54:41 AmeliaBR: so other feature request is adding way to pause CSS Animations, which we don't currently have 02:54:44 krit: right 02:54:47 dot-miniscule has joined #css 02:55:12 q+ 02:55:24 AmeliaBR: Dont' see why this should be deferred to SVG, CSS Animations has ... 02:55:40 fantasai: do we need to discuss all this with A11y? 02:55:49 krit: need to close issue no change beause moving teh section 02:56:26 IanPouncey: comment about documenting a11y concerns 02:56:48 IanPouncey: while I don't have a particular problem in this case 02:57:00 dauwhe_ has joined #css 02:57:03 IanPouncey: just want to say the wya ppl use these documents is to find example they need and copy it directly 02:57:09 I'm wondering if the request for the ability to "pause animation" also includes the ability to slow down the animation 02:57:10 IanPouncey: not going to look at different document 02:57:19 IanPouncey: in some cases we might want to have notes in multiple locations therefore 02:57:32 krit: would maybe put in boilerplate to add to every single module 02:58:01 fantasai: if you put it in the boilerplate, it'll be at the top of the spec, and someone linking into the middle of the spec won't see it. maybe in the animation type definition? 02:58:14 fantasai: which is linked from propdef table 02:58:20 IanPouncey: happy to draft that note 02:58:41 AmeliaBR: I like fantasai's point, we do have a link from every CSS property definition "Animation Type", can put the note there 02:59:02 AmeliaBR: each spec item in the spec would be connected to the warning 02:59:17 ack Ian 02:59:21 AmeliaBR: Proposal is wontfix on request to add a11y consideration section to css-transforms 02:59:29 AmeliaBR: for the remainder of the issue, request for pausing/stopping 02:59:38 AmeliaBR: that will be opened as new issue on Animations or Transitoins 02:59:59 krit: can only wontfix if remove the animation section 03:00:04 krit: so request is to remove animation section 03:00:24 krit: since feature that is added on top of SMIL and no interest form impelmenters and from community 03:00:33 astearns: so proposed to remove the section and wontfix the issue 03:00:42 AmeliaBR: can be moved to SVG Animations Level 2 which may or may not ever go anywhere 03:00:47 AmeliaBR: but that's where the text is lived 03:00:51 astearns: open a separate issue on that 03:00:57 astearns: for this particular issue, remove section and wontfix 03:01:19 RESOLVED: Remove section on animation and wontfix issue about paragraph about accessibility because no longer relevant 03:01:25 astearns: out of time 03:01:32 topic: lunch 03:02:05
03:02:29 futhark has joined #css 03:12:06 zcorpan has joined #css 03:12:51 nigel has joined #css 03:13:51 zcorpan has joined #css 03:14:18 tantek has joined #css 03:19:53 zcorpan has joined #css 03:19:55 zcorpan has joined #css 03:26:24 dauwhe has joined #css 03:27:32 duga has joined #css 03:30:08 smfr has joined #css 03:35:32 plh has joined #css 03:37:26 futhark has joined #css 03:39:35 drousso has joined #css 03:52:18 myles has joined #css 03:52:41 futhark has joined #css 03:56:35 futhark has joined #css 03:56:39 pal has joined #css 03:57:16 inamori_ has joined #css 03:57:26 ericc has joined #css 03:58:30 smfr has joined #css 03:59:46 dauwhe has joined #css 04:01:35 DavidClarke has joined #css 04:01:52 Present+ 04:02:30 rniwa has joined #css 04:03:36 addison has joined #css 04:04:20 futhark has joined #css 04:05:17 nmccully has joined #css 04:06:08 duerst has joined #css 04:06:20 zcorpan has joined #css 04:06:59 bobbytung has joined #css 04:07:13 stantonm has joined #css 04:08:36 dauwhe has joined #css 04:08:54 Rossen__ has joined #css 04:09:17 ScribeNick: heycam 04:09:26 Bert has joined #css 04:09:40 r12a has joined #css 04:09:43 nigel has joined #css 04:10:33 https://wiki.csswg.org/planning/tpac-2019#tuesday 04:11:04 Matt_King has joined #css 04:12:49 atsushi has joined #css 04:12:56 Matt_King has left #css 04:12:58 Topic: canonicalization of :lang() selectors 04:13:04 github: https://github.com/w3c/csswg-drafts/issues/4154 04:13:14 florian: the :lang selector lets you select pieces of the DOM for styling based on the language 04:13:21 ... it's alreay somehat smart, since lang tags are structured 04:13:24 mattwoodrow has joined #css 04:13:32 ... selecting zh, and the document saing zh-Hant, it will do the right thing and match it 04:13:36 ... that logic is already built in 04:13:41 kurosawa has joined #css 04:13:46 ... the IANA maintains a registry of the langauges that exist and what they mean 04:13:47 sanketj has joined #css 04:13:48 ... tags and subtags 04:14:02 ... and in addition to just listing them, there is logic in that registry. some languages are a deprecated version of some other languages 04:14:16 ... Cantonese used to be zh-yue. that is deprecated and replaced with yue 04:14:23 ... the lang selector does not take that logic into account 04:14:42 ... so if you have a document marked as lang="yue", and you are matching :lang(zh) or :lang(zh-yue), it won't match 04:14:50 ... we may want to use the registry definitions of how to match 04:14:57 ... I propose we do that 04:15:23 addison: some tag canonicalization is defined by BCP 47 to consume some of the information in the registry 04:15:33 xfq has joined #css 04:15:43 ... you've been corresponding on the IETF langauges list and I think some of your questions have been about handling macro-languages -- zh-yue is a macro language 04:15:53 florian: zh-yue is a macro language, zh is a macro language 04:16:12 addison: there's a separate thing. previous to the current BCP 47, there was a mechanism for regsitring whole tags 04:16:19 ... that's grandfathered now 04:16:24 ... some of them match subtags, some don't 04:16:33 ... [...] is replaced by xtg 04:16:46 fremy has joined #css 04:17:09 addison: ignoring grandfathered tags, they all map to something. the ones you're referring to are structurally identical, the tags are composed of subtags 04:17:12 ... like zh-yue 04:17:28 florian: the way I'm looking at this, there are variety of reasons for why certain langauges might be the same 04:17:36 ... there is a defined canonicalization that handles some of them 04:17:51 addison: for the BCP 47 canonicalization, that will do awy with the grandfathered ones and other strucutral weirdness 04:17:56 florian: it won't deal with the two types of norwegian 04:18:13 inamori_ has joined #css 04:18:14 ... this is a complicated topic with many weird variants 04:18:21 addison: there's a subset there that's well defined 04:18:29 ... there's a second set of rules, which are in CLDR 04:18:33 ... UTF 35 04:18:46 s/UTF/UTR/ 04:18:50 ... for handling some additional cases around Chinese, where you have different script subtags that you want to appear or not in some circurmstances 04:18:59 ... some of those may be of interest, but it's more complicated 04:19:03 smfr has joined #css 04:19:08 ... I don't want to pretend that doesn't exist, but they do 04:19:15 florian: if you have a link, please drop it 04:19:30 addison: defining matching, if you're just using BCP 47 "lookup" IINM 04:19:32 florian: extended filtering 04:19:44 ... the text for extended filtering says you should canonicalize 04:19:50 addison: yes you should 04:19:56 florian: thanks for bringing up that the topic is broader 04:20:08 addison: if you do the minimum set, it'll make it the most predictable. the other aspects are worth studying 04:20:17 ... there are some annoying corner cases in Chinese 04:20:27 florian: I hear support for the current proposal, and complicatd problems to think about in addition to that 04:20:39 addison: yes I agree with your current proposal and then do further study, and track the other standards happening in that space 04:20:47 florian: there is a PR for this 04:20:57 addison: should we review that? 04:21:02 https://github.com/frivoal/csswg-drafts/commit/3cff5d844b6415ef30d3e2dac221f9479e0ec7aa 04:21:02 florian: if you haven't I suggest you do 04:21:15 AmeliaBR: the other question on the topic, do we have implementor commitments? 04:22:02 r12a: the current text I'm looking at says "... must be converetd to x-lang form" 04:22:13 ... that's a slightly different discussion from what you canonicalize it as 04:22:20 ... zh-yue would become yue 04:22:24 florian: I had that discussion on the list as well 04:22:35 ... this is the right direction 04:22:49 ... zh doens't match yue. so if you canonicalize both to x-lang format, it'll match 04:23:35 xfq has joined #css 04:23:53 florian: I raised this on the mailing list, and they agreed it was the right form to canonicalize it to 04:23:57 addison: some people on the list did 04:24:07 ... the challenge is taht this will bring you more promiscuous matching than the author may have intended 04:24:15 ... it'll make Canontese match Mandarin Chinese in some cases 04:24:32 florian: if you want to match Mandarin specifically that's also possible 04:24:40 addison: normally Mandarin is tagged just as zh 04:24:51 r12a: for all the macro languages there's usually a preferred language 04:24:58 fantasai: if the author cares that much, they can put the information there 04:25:00 q? 04:25:00 addison: that's right 04:25:13 q+ 04:25:21 ... you don't want to have them with a correctly tagged document, have the :lang match things they were [...] 04:25:26 ack du 04:25:28 dauwhe has joined #css 04:25:41 duerst: that mailing list is no longer a WG 04:25:51 http://www.unicode.org/reports/tr35/#Canonical_Unicode_Locale_Identifiers 04:25:53 ... so people can give you opinions and background knowledge, but no formal resolutions 04:26:01 dino has joined #css 04:26:01 So, to cases: (A) author used zh in stylesheet and yue in HTML; doesn't expect a match. (B) author used zh in stylesheet and zh-yue in HTML; does expect a match. Canonicalizing both yue and zh-yue to the same value will break one or the other. 04:26:06 q? 04:26:23 florian: I agree that the problem can exist in both directions, too much or not enough, I think since we're doing it for typographical purposes, and the languages are realted, most of the time if you have zh styles you want it to match Cantonese too 04:26:27 http://www.unicode.org/reports/tr35/#Likely_Subtags 04:26:40 ... it's possible to style Mandarin differently from Cantonese, Hakka, etc., but that's rare 04:26:57 r12a: it's not just Chinese we're talking about 04:27:13 ... there are other languages that have much more differentiation between the language depending on which of the subtags you choose 04:27:15 q+ to suggest that this is better dealt with in the user agent stylesheet 04:27:25 ... the point I watned to make was that we said that let's go ahead with the proposal at the moment 04:27:38 ... looking at the issue, there was a proposal you wrote, I responded saying you had to modify that 04:27:43 ... the PR doesn't say much 04:27:47 ... not sure what the exact proposal is 04:27:55 ... I think this information we're talking about now should also be part of that 04:28:16 florian: the earlier proposal that you rightfully pointed out I wrote too much, including making zh-HK match yue and things like this, that's not defined in the repo I'm referring to 04:28:30 ... I'm just saying, just the canonicalization to x-lang form as defined by BCP 47 04:28:42 ... and as supported by the mailing list that used to be the WG defining that document 04:28:53 ... btu whichever way we go, including no change at all, has a risk of mismatching things in some cases 04:29:00 addison: not all tags match all values, otherwise what's the point 04:29:04 s/WG defining/WG that used to define/ 04:29:16 ... the problem is to arrive at something that authors understand how to get the results they want 04:29:22 ... we'll make some compromises, the question in which ones 04:29:37 dauwhe_ has joined #css 04:29:54 fantasai: based on the conversation so far, it seems like I don't think canonicalizing yue to zh-yue is going to be good. either we don't canonicilze, or in a direction where zh encompasses Cantonese 04:30:16 ... I am sure there are style sheets that just use :lang(zh), and they'll expect it to match 04:30:46 addison: the other possibility is that the inclusion or non-inclusion of the enclosing subtag -- in this case zh -- is a choice the author is making deliberately. if they've made that choice deliberately, if we mess eith their tags when doing matching it may produce results they don't expect 04:30:54 ... most of the matching algorithms are strict "remove from right" subtag matching 04:30:58 ... to make it obvious what's happening 04:31:18 ... what's you start adding or subtracting subtags in ways other than the deprecation/renaming, I think that has more risk to it in your space 04:31:23 ... since it's not obvious what's going to happen 04:31:40 ... I would support doing the mappings that's in the registry, since that's where if you have mlutiple variations, because people have older documents and style sheets, they'll get the right answer 04:31:44 dauwhe__ has joined #css 04:31:47 ... that's different than adding or subtracting subtags 04:32:00 ack Ame 04:32:00 AmeliaBR, you wanted to suggest that this is better dealt with in the user agent stylesheet 04:32:04 AmeliaBR: we covered a lot of what I was going to say, but witha different conclusion 04:32:13 Judy has joined #css 04:32:19 tantek has joined #css 04:32:23 ... it's important that when matching a style sheet and a document that we respect the way that the author matched it, don't want to introduce spurious matching from canonicalization 04:32:26 ...also don't want to break matching 04:32:40 ... from the examples brought up, it's obvious that any canoniclization may end up breaking one site or the other 04:32:56 ... the question is then how do we make it easier in the general case for having new style sheets or new UA style rules deal with all these deprecated synonyms 04:33:10 ... at the UA style sheet, that can just be an advice to UAs to look up the BCP deprecation list 04:33:17 ... then also included the deprecated synonmous 04:33:37 .. that doesn't work for things like a style sheet that is coming from a library or CSS reset 04:33:40 dlibby has joined #css 04:33:50 ... or the case of newer code, writing a new new style sheet, but still apply to the old pages with the older language tags 04:34:03 ... one approach that might address that use case is something like what we do with case insensitive selector matching 04:34:12 duga has joined #css 04:34:12 ... a flag in the selector that means "this value or any synonms" 04:34:18 tink has left #css 04:34:22 florian: so an opt in for canonicalization 04:34:27 addison: there are three sets 04:34:42 ... the grandfathered list is permanently fixed and has been for 10 years 04:34:51 ... all those tags have explicit mappings, you can safely map them to modern equivalents or vv 04:35:15 addison: individual subtags that ahve mappings, it's mostly about countries going out of business 04:35:26 dino has joined #css 04:35:31 ... yiddish has two subtags, hebrew has two subtags, there's a canonical one 04:35:56 .... the third thing is the x-lang thing, which is inconvenient 04:36:05 ... because there's two ways to say things. with or without the enclosing subtag 04:36:18 ... the canonicalization rule in BCP 47 says you can drop the primary langauge subtag and use the x-lang by itself 04:36:24 ... it's permissible for implementations to do that 04:36:32 ... I don't recall it says you can put it back 04:36:35 florian: there are 2 sets of rules 04:36:47 ... one that just strips it off. the other says when you're done stripping it off, put it back 04:36:55 r12a: it says you could consider doing that 04:37:08 addison: the first two are completely safe 04:37:10 ... you want to do those 04:37:14 ... for interop 04:37:19 ... the x-lang thing, I think you can choose 04:37:26 ... whether to put the enclosing subtag on 04:37:44 ... the challenge is that Chinese you'd want to do that, but some of the other macro languages are not as crisp. Arabic is one of these, Malaysian 04:38:02 https://r12a.github.io/app-subtags/ 04:38:11 r12a: Omani Arabic and Moroccan Arabic, which treat certain things differently, may have different font requirements 04:38:13 Rossen_ has joined #css 04:38:27 ... but they both resolve to "ar" if we follow this PR 04:38:31 ... but that's used for standard Arabic 04:38:58 zcorpan has joined #css 04:38:58 florian: I think we're not ready to merge the PR 04:39:16 ... action items: the safe subset of canonicalization, I don't think it's defined as a canonicalizing operation separately from the x-lang thing 04:39:20 ... action on me to find out if we can 04:39:28 addison: this is an area that probably deserves better documentation from us 04:39:33 ... we can go offline and make sure we get the right answer 04:39:46 ... we can go back and talk to the locale folks at UNicode and the languages list and make sure we're capturing the sense of this 04:39:55 florian: one, figure it ouf if the safe subset exists as a standard operation 04:40:12 ... two, if we do what I'm proposing, look at the affected languages and see if it's good for them 04:40:47 Topic: Breaking Rules at inline element boundaries 04:40:50 github: https://github.com/w3c/csswg-drafts/issues/3897 04:41:13 fantasai: there was an issue raised about what happens when you have two inline elements that have different ine breaking rules 04:41:23 ... 3 props control this. white-space, word-break, line-break 04:41:32 ... looking at an example (in the GitHub issue) 04:41:54 ... at the boundaries of the span, which line breaking rules applies when it has a different word-break prop value to the rest of the text 04:42:09 ... for white-space, the nearest common ancestor is used 04:42:28 ... the complication for word-break and line-break is that the determining rules for where you're allowed to break requires running an analysis on a lot of text 04:42:39 ... and every time that value changes you have to do another run, so impl wise it's a bit awkward 04:42:49 ... there's been some discussion about what's the best behavior here 04:42:55 ... I wanted to ask i18n if you have feedback on this issue 04:43:10 ... and ask the WG if this proposal to leave this undefined for L3, give impl time to experiment 04:43:20 ... doesn't seem to be a terribly high importance case to solve at the moment 04:43:55 florian: I think one of the more interesting cases -- and I suppose making it undefined -- is if the aprent div allows a break between every latter, and two spans next to each other which don't 04:43:58 ... can you break between the spans or not 04:44:05 ... current spec says yes, but it's hard-ish to implement 04:44:11 .. if we need time to think about this, undefine it for a while, seems reasonable 04:44:18 ... but that's the kind of case this brings to the surface 04:44:28 Rossen: any objections to leaving it undefined? 04:44:35 r12a: we should look at it as a group offline 04:44:48 bobbytung has joined #css 04:44:52 ... it's quite a long thread. I seem to remember someone brought up an example that didn't work 04:45:24 nmccully: are there layout engines working on this that would benefit from the extra time? 04:45:35 fantasai: part of the issue is part of the ICU APIs make it awkward for the rules to change in the middle of the line 04:45:39 ... so impl wise it's awkward 04:45:47 ... could be factorial if you're changing it every other letter in the line 04:45:55 ... so there's some hesistancy to impl that given the current infrastructure 04:46:01 ... but there doesn't seem to be great solutions 04:46:10 ... some of the behaviours you'd get from doing an easy thing would be non-symmetrics 04:46:17 ... you'd be switching slightly less if you use the current rule in the spec 04:46:29 ... there's not a high pressure to solve this and get interop 04:46:32 smfr has joined #css 04:46:33 ... look at it again in L4 04:46:52 myles: tangential comment, the general thing we're discussin is styling element boundaries 04:46:57 ... this is something letter-spacing also does 04:47:04 ... the spec says something that all browsers diagree ith 04:47:18 ... with we do come up with a good way to describe boundary behavior, we should try to use this system to describe letter-spacing too 04:47:23 fantasai: I think the spec is right on letter-spacing 04:47:45 ???: I think it would be good to have a general way to handle this 04:48:00 florian: we have a current generalized rule, that is general, and does the right thing, and is painful to impl 04:48:32 s/???/nigel/ 04:48:43 RESOLVED: It's undefined 04:49:10 https://github.com/w3c/csswg-drafts/issues/3481 04:50:16 https://github.com/w3c/csswg-drafts/issues/337 04:50:18 RESOLVED: i.e., the presence of soft break opportunities between spans which change soft breaking opportunities is undefined 04:50:42 Topic: Remove collapsible line breaks adjacent to word separators 04:50:43 Topic: Collapsible breaks adjacent to word separtors 04:50:46 github: https://github.com/w3c/csswg-drafts/issues/3481 04:51:20 fantasai: we generally have this concept in CSS and HTML that you can use white space to format your source, and we collapse white space down to a single space 04:51:22 ... including line breaks 04:51:42 ... for Chinese and Japanese which don't use spaces, we have some rules to remove the space otherwise you will be forced to put all paras on one line 04:51:45 inamori_ has joined #css 04:51:51 ... there are some rules for doing that based on character classes 04:52:04 ... what we didn't consider thoroughly is languages that use a word separator that's not a space 04:52:11 ... we do special case ZWSP, for Thai and other languages 04:52:16 joanie has left #css 04:52:25 zcorpan has joined #css 04:52:26 ... but we don't have something similar for Ethiopic word space 04:52:32 ... probably don't also want a regular space there 04:52:45 ... proposal is when there's a word separator character adjacent to a line break, the line break just goes away 04:53:28 smfr_ has joined #css 04:53:33 ... I think the characters that are affected here are Ogham space mark and Ethiopic word space and the Tibetan tsek 04:53:43 AmeliaBR: does this map to something in Unicode? or do we need to maintain this list? 04:53:55 https://drafts.csswg.org/css-text-3/#word-separator 04:54:04 r12a: I think there is something, not sure if it's fit for this purpose 04:54:15 r12a: archaic scripts have other examples 04:54:21 y 04:54:41 fantasai: [reads definition in the spec right now for word-spacing] 04:54:50 florian: we need to maintain a list 04:54:54 myles: let's ask Unicode to do it 04:55:17 ... if there is such a facility for these character lists, hard to believe it's specific for the web platform 04:55:26 ... and not needed in text editors for example 04:55:36 ... I don't think the web specs should maintain this list 04:55:44 florian: I agree with part of your statement, should try to work this out with Unicode 04:55:55 ... this one specifically maybe, but some are specifically web platform relatively 04:56:01 ... since this is relevant to turning HTML markup into text 04:56:09 myles: there are many different markup languages... 04:56:14 fantasai: there are 2 questions 04:56:30 ... if we want to do this, and then whether we maintain the list of if Unicode should 04:56:36 addison: i think we want to do some research 04:56:43 ... space or no space is a classic problem 04:56:53 ... I would be surprised if there weren't something, but don't know off the top of my head 04:57:05 plh has joined #css 04:57:08 ... would be happy to engage 04:57:33 myles: if this is a classical problem, it's been solved, and we should figure out how it's been solved in the past and re-use that solution 04:57:36 zcorpan_ has joined #css 04:57:41 fantasai: looking at some of the stuff in css-text, weh ave a concept of word separateors 04:57:47 ... and it includes a set of code points 04:57:53 ... it excludes Ogham space mark 04:58:03 ... since it would cause text to not join any more 04:58:20 ... so general usage in UNicode is text processing segmentation is not going to account ofr that concern, since they don't deal with typesetting 04:58:36 ... so there's gonna be some aspects of how we're using Unicode codepoints with sepecific requirements that haven't come up in Unicode's context so far 04:58:55 ... unbreaking lines is something that's been hard to explain to them 04:59:03 myles: maybe we shouldn't be unbreaking them? 04:59:06 fantasai: too late for that! 04:59:38 addison: fwiw I've had to write this code in the past, and it's not any fun 04:59:48 ... it maye have been individually solved but not written down 04:59:49 fantasai: HTML has been unbreaking lines for as long as it has existed, we want to make that ability available to more languages 05:00:02 r12a: like with the other issues, we need to look in more detail 05:00:09 ... the Tsek is a syllable separator, not the same as a word joiner 05:00:24 ... you could end a line with a Tsek, then start with more Tibetan on the next line, with indentation, and no real reason to join those together necessarily 05:00:35 fantasai: you wouldn't make the Tsek go away, just avoid the extra space going in there 05:01:24 ACTION: i18n to look this issue of word separators next to newlines 05:01:25 Error finding 'i18n'. You can review and register nicknames at . 05:01:40 action: addison: ensure we respond to css 3481 05:01:40 Error finding 'addison'. You can review and register nicknames at . 05:04:53 Topic: ResizeObserver Device Pixel Border Box 05:04:57 ScribeNick: fantasai 05:05:47 chrishtr: device-pixel-border-box is the actual device pixel bounds of a canvas element 05:06:01 chrishtr: including pixel-snapping feature which is ued by browsers to avoid blurriness by snapping to pixel grid 05:06:08 chrishtr: fundamental problem with no complete solution 05:06:14 chrishtr: authors that use canvas 05:06:25 chrishtr: have no reliable method to determine on-screen pixel size of the canvase 05:06:35 chrishtr: if off by one pixel due to pixel-snapping, rounding, or other issue 05:06:41 chrishtr: will end up with wrong or blurry results 05:06:43 atsushi_ has joined #css 05:06:44 stantonm_ has joined #css 05:06:50 chrishtr: pixel-snapping is intentionally not specced to allow UAs to do their best 05:06:57 sanketj has joined #css 05:06:57 chrishtr: acocunt for varying rendering architecture 05:06:59 chrishtr: and evolution 05:07:07 chrishtr: so no way to reliably find this size 05:07:16 chrishtr: proposal is to add a box that observes device pixel border box 05:07:20 chrishtr: to ResizeObserver 05:07:25 chrishtr: which will notify if that box changes 05:07:43 chrishtr: will happen at similar timing as other ResizeObserver 05:07:46 github: https://github.com/w3c/csswg-drafts/issues/3554 05:07:50 chrishtr: there were two main objections to adding this 05:07:57 chrishtr: one was raised by Jeff Gilbert 05:08:09 chrishtr: had a long discussion with him and Kem Russel, our WebGL expert (?) 05:08:16 chrishtr: have a compromise proposal that both of us agree to 05:08:22 s/Kem Russel/Ken Russell/ 05:08:24 chrishtr: objection he raised was that if you have a WebGL-centric application 05:08:34 chrishtr: e.g. full-screen game that uses WebAssembly and only DOM in minimal way 05:08:40 chrishtr: want to have a continuous requestAnimationFrame loop 05:08:43 chrishtr: drawing the canvas 05:08:49 chrishtr: in that model where you are canvas-centric 05:09:33 zcorpan has joined #css 05:09:51 chrishtr: it still lives in a DOM shell or browser window that has a size 05:09:54 chrishtr: need to observe that size 05:09:59 chrishtr: where pixel snapping will work 05:10:05 chrishtr: but ... not in JS 05:10:14 s/.../in Web Assembly/ 05:10:21 chrishtr: most convenient to query device border box directly from canvas during rAF loop 05:10:29 chrishtr: rather than by observer 05:10:43 chrishtr: if layout was dirty at the time during making the query, it will force layout and other things in order to compute pixel snapping 05:10:48 chrishtr: in taht use case maybe it's OK 05:10:53 chrishtr: other use case, which I was most focused on 05:10:54 bobbytung has joined #css 05:11:01 chrishtr: you have canvas element embedded in a DOM-centric website 05:11:09 chrishtr: maybe photo-app or ad or widget, 05:11:16 chrishtr: potential multi-actor scenario 05:11:19 chrishtr: want to avoid layout thrashing 05:11:26 chrishtr: cases for which ResizeObserver was designed 05:11:29 Bert has left #css 05:11:31 chrishtr: this makes most sense 05:11:39 chrishtr: compromise proposal is that we just have both APIs 05:11:45 chrishtr: The End! :D 05:11:54 inamori_ has joined #css 05:12:00 jeff: .... 05:12:33 jgilbert: ... moving forward with both propsoals works out 05:12:41 jgilbert: having it be in ResizeObserver also makes sense 05:12:56 jgilbert: like you went over, there was some concerns about it covering espeically more easily some more trivial cases 05:13:03 jgilbert: having both lets people pick and choose appropriate API 05:13:13 jgilbert: default should be to use ResizeObserver, most reliable 05:13:25 HeWenli has joined #css 05:13:29 jgilbert: kindof like getClientBOundingRect() , need to be careful if calling that often 05:13:32 jgilbert: maybe warn in UA 05:13:35 jgilbert: if called too often 05:13:47 jgilbert: but getDeviceClientRect() API alone ... 05:13:53 chrishtr: 2nd objection smfr raised 05:14:01 chrishtr: pixel-snapping requires more information than just layout in today's engines 05:14:05 chrishtr: in Chrome requires pre-paint step 05:14:09 chrishtr: in Safari requires paint 05:14:18 chrishtr: don't have solution to that problem 05:14:24 chrishtr: just note readback method for rAF 05:14:29 chrishtr: canvas.getThing 05:14:33 chrishtr: also has to run the same steps 05:14:40 Rossen_: but that's not blocking to accept the proposla 05:14:46 smfr: in some ways make sit worse 05:14:52 smfr: because 2 places we have to do this painting calculation 05:15:05 Rossen_: was asking if this second objection is blocking accepting the proposal 05:15:19 smfr: so to clarify the proposal is having API to return the box on canvas and also in ResizeObserver 05:15:26 smfr: I'm not a fan of doing partial paitn to get this info 05:15:40 smfr: I would expect for games , especially in full-screen, to position on ? boundaries 05:15:50 smfr: surprised if using fractional pixel positioning 05:16:01 jgilbert: for full-screen, unlikely, but for partial screen almost always get this 05:16:18 jgilbert: both on Windows and on Android, I believe, Windows will happily give you 1.6574 device pixel ratio 05:16:22 jgilbert: you just have to deal with it 05:16:30 jgilbert: you end up trying to reverse-engineer what pixel-snapping is to figure that out 05:16:50 jgilbert: pre-snap a rect to a non-integre CSS size , if that works out to integer pixels... then no artifacts? but it's a huge mess 05:17:00 smfr: other case that's confusing is on our iPhone's that have retina displays 05:17:06 smfr: already 2.7? scaling factors 05:17:13 smfr: so can cause hairlines to disappear aetc. 05:17:18 smfr: seems like also on windows, too 05:17:29 smfr: getting pixel perfection, seems like OS is doing scaling behind your back, how can you expect it to work? 05:17:38 jgilbert: out of the box cases where if you play around with virtual scaling 05:17:52 jgilbert: on a Mac and play with scaling on a retina screen 05:17:56 jgilbert: no way to get 1-1 device pixel 05:18:11 myles: even worse, the default ratio is not 1-1 or 2-1 05:18:25 jgilbert: it really depends on how the OS is doing this sort of scaling 05:18:51 jgilbert: I'll add that what you end up with, for instance in Mac, when you have this OS-level virtual resolution scaling 05:18:56 jgilbert: can't get one to one 05:19:03 jgilbert: if can't get 1-1 in application, can still get moire effects 05:19:10 jgilbert: can't entirely eliminate scaling artifacts, but can do better 05:19:17 jgilbert: than naively try to grid on the screen and hope it looks good 05:19:35 mattwoodrow: difference is on Windows the scaling isn't hidden 05:19:48 mattwoodrow: can attempt to match 05:20:02 jgilbert: windows 10 implements scaling that llows 1-1 rendering, not virtual scaling as default 05:20:14 jgilbert: Mac doesn't expose effective scaling, just says 2x all the time 05:20:18 jgilbert: Android says 3x all the time 05:20:22 q? 05:20:29 ??: regarldess of what operating systems do, if application renders pixel -perfect 05:20:35 ??: Result will be better than if it wasn't 05:20:41 ??: I think we agree on that 05:20:44 plh has joined #css 05:20:49 rniwa has joined #css 05:20:56 myles: if goal is to get hairlines, even if you get a little closer to hairline, can still disappear 05:21:09 ??: Display scaling might give you smoother color if checkerboard is pixel-perfect before the scaling 05:21:19 ??: and if you have checkerboard before scaling, then less smooth design 05:21:34 s/??/mstage/ 05:21:41 s/mstage/mstange/ 05:21:50 mstange: still discussing value of getting an accurate box? what's status? 05:22:07 jgilbert: if we decide that we don't want to give ppl this box, then ? 05:22:23 jgilbert: do we want to get into that? or do we want to take it as a given that we're trying to give ppl most correct idea of device pixel than we can? 05:22:37 mstange: what we would need to do in Firefox to get this result 05:22:48 mstange: Firefox takes into account the full zoom, and takes into account CSS Transforms 05:23:11 mstange: space in which we snap is established by the closest non-animated transform or the root 05:23:24 mstange: we only know this info during painting 05:23:32 mstange: so would need to run more steps before giving info 05:23:49 smfr: this device border box would not be affected by transforms 05:23:56 smfr: so would have to do *special* calculation 05:24:03 jgilbert: 3D transforms no idea what to fee dback 05:24:07 jgilbert: pixel-snapped bounding box? 05:24:22 atotic: if you're doing transforms won't be pixel-perfect anyway, so don't worry about it 05:24:37 atotic: your'e also talking about implementation that you need to get this nformation during pre-painting 05:24:43 atotic: remember you had this information ?? 05:24:54 atotic: Might be ok to deliver incorrect information and not have to paint 05:25:06 myles: there's a chance of you never get correct info 05:25:19 s/closest non-animated transform/closest animated ancestor transform/ 05:25:22 atotic: I think you want, once things have settled down want accurate box size 05:25:27 atotic: if animating, don't care so much 05:25:33 inamori_ has joined #css 05:25:47 jgilbert: deliver informmation lately 05:25:59 jgilbert: would be nice if we could try so that you could do 1-1 perfect every time within certain set of constraints 05:26:08 jgilbert: be nice if we didn't immediately settle on a 1 frame late policy 05:26:14 jgilbert: matching what native APIs are able to do 05:26:24 jgilbert: don't want to suffer if dont' have to suffer on native 05:26:41 myles: if it is one frame late then the exact timeline that we drop frames is exposed to the Web so don't think we want 05:27:07 myles: similarly, worried that we'd have to reverse-engineer chrome's pixel-snapping strategy 05:27:15 jgilbert: shouldn't have to do more normalziation than you do today, I think 05:27:29 jgilbert: if trying to use this to get anti-moire, in order to do this today have to ?? 05:27:49 smfr: one frame late version also problem of which rectangle to trust 05:27:54 chrishtr: not late if layout occured 05:27:59 chrishtr: only late if you have a threaded animation 05:28:16 smfr: thought it would be late because we woudl collect info at paint time 05:28:23 chrishtr: I don't think we shoudl do that, disagree with atotic 05:28:28 chrishtr: think we can do it therefore we should 05:28:32 chrishtr: in cases where layout has occured 05:28:40 chrishtr: agree with point about threaded animations and not syncing with JS thread 05:29:03 smfr: want to tie together two of previous points, first that if we implement this paint day device pxel border box, will be more expensive for us 05:29:17 smfr: secondly because of physical mismatch, wouldn't have some user benefit 05:29:24 smfr: display is scaling anyway 05:29:32 smfr: can we get examples? 05:29:45 smfr: want to try on Apple devices, see what would happen if looks right 05:29:49 atotic: moire patter 05:30:07 atotic: if you're moving canvas around the screen, the moire is animated. looks really bad 05:30:11 smfr: please give us some tests 05:30:15 chrishtr: I think time is up? 05:30:27 chrishtr: propose to add the feature? 05:30:41 Rossen_: does the group feel there's enough merit to add this? 05:30:48 Rossen_: would be adding both APIs 05:30:52 Rossen_: is there any objection? 05:31:07 smfr: I dont' think we can accept new API without evidence that it's so much better that it's worth the extra cost 05:31:21 karl has joined #css 05:31:30 fremy: you can agree with the API and just return some approximate result if you feel it's good enough 05:31:39 myles: your'e saying implement the API without implementing teh API 05:31:47 fremy: might not be useful on your device 05:31:53 fremy: but might be useful on Android 05:31:58 fremy: so just return the result 05:32:18 AmeliaBR: Not having an API is better than having API with bad results 05:32:45 AmeliaBR: if a particular browser has particular concerns about implementing the particular API 05:33:07 fantasai: in this case it would be, if you as an author were trying to do this thing, and you had this browser gives me the actual DPR, and this one gives me some approximation of the size 05:33:11 ... I still need to size my box either way 05:33:42 ... if my choice is I can get teh actual device pixel size from Chrome, but calcaulate it myself from widht/height props in WebKit, and get an approx result, then I don't know it might be better to have an API that does that calculation for me 05:33:46 ... then I only need to write one code flow 05:34:10 AmeliaBR: might make sense, but have existing cases where you can't trust the API 05:34:19 florian: In general I agree with your statement, this doesn't seem to be such a case 05:34:25 Rossen_: I woudld like to end this topic 05:34:48 Rossen_: going to call for objections to adding the API, if we have objections we'll deal with them and have additional conversatiosn with the TAG and whatnot 05:34:54 Rossen_: any objections to having these APIs? 05:35:01 smfr: Can we wait until we ahve the examples? 05:35:11 astearns: I might object because seems like we need more data 05:35:21 astearns: so I will object on Safari's behalf 05:35:35 Rossen_: so back to you to get test cases, we'll discuss again on telecon 05:36:02 Topic: CSS Writing Modes Implementation Report and Open Issues 05:36:21 https://drafts.csswg.org/css-writing-modes-3/implementation-report-2019-08 05:36:32 ScribeNick: mstange 05:37:01 florian: We've been working on the writing mode spec for some time. I've updated it since I've showed it last month. 05:37:12 sanketj has joined #css 05:37:27 ... Out of about 1000 tests, about 14 failed and 24 others failed. (?) 05:37:29 ericc has joined #css 05:37:37 ... There will always be some tests that fail. We'll be fixing things forever. 05:37:48 ... Have we done enough fixing already to move on? 05:38:03 ... There is a number of issues that are marked in yellow, which are a not insignificant part of the remaining tests. 05:38:13 ... They have some patches which are about to land in Gecko so that they will pass. 05:38:30 ... Some tests could be split up into two tests, both of which will each pass in different browsers. 05:39:02 bobbytung has joined #css 05:39:05 ... There are a couple legitimate failures as well. 05:39:30 iank_: Please don't remove tests that test intersections of features. Those tests are useful. 05:39:41 florian: In this particular test, the two features are independent. The intersection is not tested. 05:40:26 ... The test results are from current Chrome Canary. 05:40:39 sanketj has joined #css 05:40:42 ... We have not done enough work on writing modes to never think about it again. 05:40:54 ... But I don't think any problems are in areas we believe to be wrong in the spec. 05:41:06 ... It's my opinion that we can move on despite those failures. 05:41:37 Current open issues (for L3): https://github.com/w3c/csswg-drafts/issues?q=is%3Aopen+is%3Aissue+label%3Acss-writing-modes-3 05:41:38 https://github.com/w3c/csswg-drafts/issues?q=is%3Aopen+is%3Aissue+label%3Acss-writing-modes-3 05:41:44 fantasai: There are some issues about things where the spec is unclear, and we should just do those clarifications. 05:42:13 florian: All issues are about things that ought to be better defined. But we need help. 05:42:51 fantasai: I think it would be better to address these issues before saying that writing mode L3 is done. 05:43:18 dbaron: I've been uncomfortable with some of the things about intrinsic sizing. 05:43:42 ... I think the third issue is more on the material and sizing than on the material and writing modes. 05:43:44 rachelandrew_ has joined #css 05:44:13 ... In response to being asked to implement something in Firefox, I ran into a list of conditions that was unclear. 05:44:21 florian: Was this not partly answered by text that was restored? 05:44:33 dbaron: I think this was after it was being restored. 05:45:07 florian: fantasai discovered that some section had been lost and it was recovered in late August. 05:45:33 dbaron: This is a specification pattern that is difficult for authors. Rather than saying "You want to compute X", it says "You calculate in the following terms". 05:46:15 dbaron: It is very hard to know what some of the terms mean in a specific context. 05:46:33 mattwoodrow has joined #css 05:46:52 florian: I agree that this specific text should be tweaked. But the level of writing in L3 is higher than in L2. Raising the bar of writing is good, but gating specs on that bar might not be necessary. 05:46:59 florian: Can we address this in L4? 05:47:20 dbaron: I guess. L2.2 probably did not have backward references to things that were poorly defined to the degree that L3 does. 05:47:41 astearns: How do we move writing modes forward? 05:47:54 s/astearns/Rossen_ / 05:48:02 ... Do we actually want to hold off and resolve on these issues with additional spec works and re-enter PR at a later time? 05:48:31 chris has joined #css 05:48:35 fantasai: With the exception of some tweaks, Gecko seems to have implemented this just fine. 05:48:39 zcorpan_ has joined #css 05:48:57 smfr has joined #css 05:50:07 ... We are basically rewriting all of CSS 2, but we need to do it in pieces. The current writing is not ideal, but it is the best I could do without rewriting chapter 10. 05:50:28 AmeliaBR: Given that fantasai has said that Gecko is right, are we ok with (?) 05:51:00 dbaron: The hard part is the edge cases. The question is not, "Do we follow this list of things in simple case X which is being tested", it's "what is the exact list of cases where we need to do this list of things" 05:51:27 Rossen_: We almost went into Rec two or three years ago. I think the level of the spec is fairly high at this point. 05:51:34 s/are we ok with (?)/could dbaron suggest new text that describes that & addresses his issues (in time for publication)/ 05:51:52 dbaron: I'm ok moving forward if you want, but there are cases that are not defined enough to be implementable in an interoperable way. 05:52:19 fantasai: This spec was written assuming grid and flexbox do not exist. We can't make this gate on defining exactly how things work in grid and flexbox. 05:53:16 dbaron: It would be nice to give an example where this list doesn't apply. 05:53:21 fantasai: I don't know of one. 05:53:37 dbaron: That's why I suggested stating in the spec that it always applies. 05:54:28 inamori_ has joined #css 05:54:45 +1 koji 05:55:03 Rossen_: The proposal was not to resolve the issues, it was to move them and retag them for L4. 05:55:33 Rossen_: Any objects to retagging the three issues to level 4? Those are 4026 3095 and 2819. 05:55:44 and they will need to be added/updated in the DOC 05:55:44 No objections. We will move these issues to be tracked under L4. 05:55:52 s/2819/2890/ 05:56:07 s/No objections. We will move these issues to be tracked under L4./Rossen_: No objections. We will move these issues to be tracked under L4./ 05:56:17 Rossen_: Are there any objections to move CSS writing mode Level 3 to PR? 05:56:19 plh has joined #css 05:56:24 Rossen_: No objections, resolved. 05:56:32 fantasai: Ah, the case was about computing max-content inline-size vs auto block box inline size: in latter case, it's not well-defined what max-content computation is in CSS2, so could be conceptually that available size is infinite, and it's OK. But auto width computation needs definite length to subtract margin/padding/border from and result in non-infinite content-box width, so can't use infinity, so 05:56:33 RESOLVED: Move CSS Writing Modes L3 to PR. 05:56:38 have to use fallback size 05:57:37 pal has joined #css 05:58:05 james has joined #css 05:58:05 Topic: Remove font-variant @font-face descriptor from Fonts 3 05:58:12 github: https://github.com/w3c/csswg-drafts/issues/2531 05:58:50 myles: We have two text paths. In WebKit. The distinction which path to go to has to happen before font fallback. 05:59:23 ... Sometimes we detect something too late and can't go back and re-do everything, so we just do our best. 05:59:47 ... If this is not necessary for the web platform, let's remove it. 06:00:00 fantasai: It does look like there is an implementation (faceless2 says it in the issue) 06:00:54 ... If the feature doesn't have a problem, we should leave it. We do not need implementations to move this spec at the moment. 06:01:03 myles: When is the deadline? It's been years. 06:01:19 Rossen_: This is a non-verifiable implementation. How do we evaluate it? 06:02:00 q? 06:02:25 drott: We would support removing it because the semantics are unclear in some cases. 06:02:36 heycam: We would also be fine with removing it. We haven't heard much demand from authors. 06:02:47 ... In principle it seems like a useful thing, but we would be fine with removing it. 06:02:54 Rossen_: Any objections to removing it? 06:02:59 Rossen_: No objections. 06:03:08 RESOLVED: Remove font-variant @font-face descriptor from Fonts 3 06:03:26 Topic: mitigations for font based fingerprinting 06:03:31 github: https://github.com/w3c/csswg-drafts/issues/4055 06:04:26 chris: The issue is that you can pretty much identify individuals based on the set of installed fonts. 06:04:45 ... For example, I have all CSS test fonts installed and some fonts for languages I don't spec, and that identifies me uniquely. 06:04:57 s/spec/speak/ 06:05:01 fantasai, florian, TabAtkins: we're in the #testing meeting debating what your requirements actually are. can we interview you later? 06:05:08 ... One proposal was to only report fonts that are the standard fonts for that platform. 06:05:19 ... But this would cause you to re-download fonts you already have. 06:05:30 ... This consumes unnecessary bandwidth. 06:05:54 florian: On some OSes, even the set of default fonts can almost uniquely identify you. 06:06:05 myles: It is impossible for the spec to describe the set of default fonts. 06:06:28 ... The proposal is to say in the spec that browsers must have some affordances to protect user privacy by having some sort of (?) 06:07:32 florian: On the performance vs privacy question, I lean towards privacy. On performance vs internationalization, it's less clear: If you don't have the font for a particular language and can't read the text, that's bad. 06:07:51 chris: There is a strong web compat problem here. Things that used to work should not break. 06:08:07 florian: When working means look pretty, there's a trade-off. When it means you cannot read it, it's different. 06:08:21 myles: WebKit has been doing this for over a year. We discard user-installed fonts. 06:08:34 florian: Mongolian without fonts is unreadable. 06:08:46 ... When it is readable, removing the fonts breaks it. 06:08:50 myles: It's a trade-off. 06:08:57 heycam: How did you choose that list of fonts? 06:09:02 myles: I commented on the issue. 06:09:02 s/heycam/thomas/ 06:09:36 It was also pointed out that downloading fonts can cost money in some areas, and this is more likely to be the case in areas which are more likely to use minority languages 06:09:37 thomas: Rather than a bespoce list, could we come up with a list that can be updated periodically? Some list that covers languages for i18n use cases, as well as some fonts that are installed on machines. 06:09:52 and which have less money to spend 06:10:11 sanketj has joined #css 06:10:50 iank_: The information about fonts is queriable by measuring the bounds of boxes, without getting the list of fonts from an API. 06:11:11 Rossen_: We will pause the discussion of this issue and unpause it after the break. 06:11:23 Topic: Vertical text doesn't play nicely with font-style and font-stretch 06:11:39 Topic: Dynamic text size 06:11:42 github: https://github.com/w3c/csswg-drafts/issues/3708 06:12:13 ???: For a long time we've had scalable fonts that are based on the Desktop Web. 06:12:26 s/???/jcraig/ 06:12:45 smfr has joined #css 06:12:51 jcraig: It took us a while to make it work on all extreme cases. 06:13:03 ... We would like to support low vision users who have extremely large text sizes. 06:13:36 ... Forcing such giant font sizes on web pages would make most web pages unreadable. 06:13:48 ... We would like to have a way to opt in to larger font sizes. 06:13:57 ... as an author. 06:14:22 ... We would also like to propose a feature that allows web pages to detect large font sizes and adjust the sizes of other elements. 06:14:41 ... We have some aspects of this that are available today: You could detect based on min-width in ems, but that does not work consistently. 06:14:51 ... Right now there is no standard way to opt in to this that works across all browsers. 06:15:02 ... Most browsers on mobile systems don't want to break their users' layout. 06:15:30 ... We have examples where it would be very difficult or even impossible to achieve the intended layouts today. 06:16:26 jcraig: [demo] 06:16:54 ... I have applied iOS settings that render text extremely large and bold. 06:17:05 ... I can show how different apps deal with this setting. 06:17:14 ... Calendar switches to 3 or 2 column layouts. 06:17:32 ... The Books app switches from a 2 column layout to a single column layout. 06:17:55 These are all very easy to do if you have flexbox/grid and correctly implement media queries in em units 06:18:16 or ch units 06:18:35 ... In Mail, with larger font sizes, the title gets clipped but the email's time is preserved. 06:19:06 fantasai: Is the problem that we can't actually implement media queries with em and ch units because the web would break, but you want to have media queries with em and ch units? 06:19:17 ... Everything you've demonstrated here is totally possible with em and ch units in media queries. 06:19:19 rniwa has joined #css 06:19:37 ... On mobile you're not returning the correct values because that would break. So what you're saying is you want real units? 06:19:54 jcraig: What we want is an ability for an author to say "I can handle any font size you throw at me." 06:21:07 florian: How possible is that this signal becomes worthless over time as it gets copied around, and we need to add still another signal? 06:21:22 chris: People are rapidly going to find out that just copying this around will break them. 06:21:23 inamori_ has joined #css 06:21:41 jcraig: The reason we don't turn this on by default is that web developers *don't* find out that it breaks them. 06:21:52 ... They haven't turned on these large fonts on their system. 06:22:17 fair point, retracted 06:23:14 jcraig: The first part of what we need is the opt in to the higher font sizes. The second part is the media query part. 06:23:40 fantasai: In order to do the kind of layout transformations you want, you also have to know how many letters fit on the screen. You'd use the min-width query. 06:23:48 jcraig: That would get us some of the way. 06:24:07 tantek has joined #css 06:24:26 fantasai: Having just the media query for the font size is not enough if you can't relate it to the size of the viewport. 06:24:44 florian: You can't compare the font size and the viewport because the lengths have different units. 06:24:57 ... The thing you call an opt in would also opt in the media queries to behave properly. 06:25:15 ... Whichever opt-in we have needs to opt in both to behave how things were originally intended. 06:25:28 `@media (min-height: 10em)` only works if the window root em size is accurate. So if we don't reveal the accurate preferred em value except in an environment value, you'd need to use `@media (min-height: calc(10*env(user-font-size)) )` 06:25:51 ???: If you have a user font size variable, you can use calc to obtain the right answer. 06:25:58 s/???/fremy/ 06:25:59 fantasai: As an environment variable, it would work out. 06:26:34 ... But (?) it would be multiple variables, not one variable. 06:26:42 Mek has joined #css 06:26:43 futhark has joined #css 06:26:53 fantasai: The size of ch is dependent on the initial font, not on the font that is used. 06:27:29 florian: There is a number of ways you can use environment variables to do what you want, but if the opt-in mechanism opted in everything, it would also work. 06:27:30 s/(?)/Firefox uses different font-sizes for different languages, so/ 06:27:33 fremy has joined #css 06:27:45 florian: Is there reason to exclude media queries from the opt in? 06:27:54 jcraig: It should not be excluded. 06:28:16 mattwoodrow has joined #css 06:28:23 fremy: You want to be able to opt in only parts of a web site. 06:28:46 ... If the developer in the iframe did the work to deal with large fonts, if it is embedded in another website that does not handle them, all the work is for nothing. 06:28:53 jcraig: The reverse is also true. 06:29:15 fantasai: If the widget is inheriting the font from the parent document, then it's going to have problems if the parent document picks a larger font, regardless. 06:29:44 fremy: You cannot say media queries behave differently for different parts of the same document. 06:30:00 florian: Yes, if you put a responsive widget into a non-responsive website, then yes, your responsiveness is wasted. 06:32:15 duga has joined #css 06:32:35 jcraig: It sounds like we're agreeing that it would be useful to have an opt-in for websites to express that they can handle large font sizes. 06:33:09 florian: And we do not agree on the media query part - depending on how we do the opt-in switch, that switch may also opt in media queries automatically. 06:34:00 florian: If we can't make the existing media queries work, we maybe need to add more media queries. 06:34:26 jcraig: That sounds reasonable. Once we have an opt-in we can experiment and see in what cases it's not good enough. 06:34:45 AmeliaBR: Having it in CSS would be better than having it in markup because you can put it into one shared stylesheet. 06:35:17 ... In order to get useful media queries, the opt in has to be outside of a property. 06:35:46 ... If somebody has explicitly set this opt in value, then the existing font-size keywords that were supposed to be relative to the user-chosen default font size can actually do that. 06:35:58 q+ 06:35:58 ... Otherwise, the default size will be the legacy 16px. 06:36:20 jcraig: I think that sounds ok. But a new media query would be clearer in terms of what we want to communicate to authors. 06:36:42 ... Without that, the complexity of doing layouts based on width and layouts based on font-size is going to result in lots of media query blocks. (?) 06:36:50 Rossen_: We need to work towards a resolution. 06:37:17 q? 06:37:21 ack plh 06:37:26 ack plinss 06:37:46 dino has joined #css 06:37:51 ack fantasai 06:37:52 Q+ 06:37:52 plinss: I'm concerned about adding yet another mode switch. Mode switches are bad. Can we do the right thing without a switch? 06:38:06 fantasai: I hate meta tags because you can't put them in a stylesheet and link them from everywhere. 06:38:29 ... However, it seems to make the most sense to add this as a meta tag because it affects media queries and the initial containing block size. 06:38:56 smfr has joined #css 06:39:01 dauwhe_ has joined #css 06:39:15 RRSAgent: make the minutes 06:39:15 I have made the request to generate https://www.w3.org/2019/09/15-css-minutes.html gsnedders 06:39:16 ... And once the mode has been switched, font sizes and everything else can start working the way initially intended. 06:39:32 q+? 06:39:35 ... These things all belong together so we should just tack on a meta tag. 06:39:49 Rossen_: I do not hear agreement on exact technicalities. 06:40:39 Rossen_: Let's have a resolution on having a way to opt in, even if we don't have the exact way of doing it. 06:40:57 Rossen_: Objections on opting in to true user font sizes? 06:41:13 jcraig: We (Apple) tried to do this without a mode switch, by default, and all 200 000 apps broke. 06:41:39 ... Even with an opt-in switch, it took years for all first party apps to support this mode. 06:42:04 fantasai: I don't like mode switches either, but the alternative is to add an entire set of units. A mode switch is a lot simpler. 06:42:38 AmeliaBR: I came in with the same concerns as plinss, but one thing I did bring up was that, at the user agent level, there should be reflection of the fact that there are two cclasses of users. 06:43:07 ... Some users want fonts that don't want broken web pages, and some users want readable fonts even if pages are broken. 06:43:26 ... It seems that most users will accept smaller fonts if it means that pages are not broken. 06:43:32 zcorpan has joined #css 06:43:47 plinss: I have no concerns with a user switch. I have concerns with adding a switch to the web platform. 06:44:11 dauwhe has joined #css 06:44:18 zcorpan has joined #css 06:44:38 ... If we have to commit the sin again of adding another mode switch, let's add it in a way that it can fade away in the future, and not such that content will break if authors don't anticipate the switch. 06:44:50 ... There is real costs to adding mode switches. 06:45:09 myles: The resolution seems to be about intention, not implementation. Let's try to agree on that. 06:45:19 Rossen_: Objections to having the option to have two font sizes? 06:45:23 s/two/true/ 06:45:30 futhark has joined #css 06:45:43 RESOLVED: There should be a way to have true font sizes. 06:45:49 RRSAgent, make minutes 06:45:49 I have made the request to generate https://www.w3.org/2019/09/15-css-minutes.html karl 06:46:20 futhark has joined #css 06:46:34 nigel has joined #css 06:53:44 nigel has joined #css 06:55:25 atsushi has joined #css 07:02:04 rniwa has joined #css 07:03:04 dauwhe has joined #css 07:05:07 dauwhe_ has joined #css 07:05:28 duga has joined #css 07:06:02 zcorpan has joined #css 07:06:02 xfq has joined #css 07:06:09 cmp: https://bugzilla.mozilla.org/show_bug.cgi?id=1252821 07:06:14 futhark has joined #css 07:07:08 Rossen_ has joined #css 07:07:16 dino has joined #css 07:07:45 stantonm has joined #css 07:08:07 fremy has joined #css 07:08:54 Topic: [css-fonts] Vertical text doesn't play nicely with font-style and font-stretch 07:09:01 Github:https://github.com/w3c/csswg-drafts/issues/4044 07:09:04 glenn has joined #css 07:11:18 ??: CJK text differs from latin because of the multiple orientations 07:11:33 .. because of that multiple features related to the line width become quite complex 07:11:59 ... [explains example in the issue] 07:12:36 ... depending on the glyph orientation glyphs get stretched in different directions 07:12:55 ... as a user is backwards, as an implementor you need to poke at the internal characters 07:13:17 ... while the feature is about stretching the whole line 07:13:30 Ms2ger has joined #css 07:13:37 myles: this was discussed in OpenType and there was some discussion 07:14:13 ... the font can't know how to do it right and there's an opentype feature that only gets applied to upright characters 07:14:23 ... but it's pretty hard to set up 07:14:42 ... so opentype would introduce a new axis 07:14:51 ... vertical and horizontal width 07:15:18 ... and the application would set the relevant vertical / horizontal axis depending on whether the glyph is upright or not 07:15:41 ... no resolutions anywhere yet but need to move it together 07:16:53 ... so we need font-face descriptor to say that it supports stretching in the vertical axis or not 07:17:20 ... so plan is to extend font-stretch to specify using a `vertical` direction that it's stretched in the vertical axis 07:17:50 sanketj has joined #css 07:17:51 s/??/nmccully 07:18:07 ... the font-stretch property wouldn't change syntax, but it'd change behavior 07:18:22 ... rotating the font in the appropriate direction 07:18:47 ... which means that writing-mode and text-combine and such would also be inputs to the font selection algorithm 07:19:08 ... because if it's vertical it'd need to download the font that can expand in the vertical axes 07:19:13 ... thoughts? 07:19:19 fantasai: sgtm 07:19:27 leaverou: would the property change? 07:19:42 myles: the property has no grammar change but has behavior change 07:19:58 nmccully: you may need it for TCY 07:20:54 myles: the system I'm describing would either select an horizontal or vertical font, but it's important that fonts can support both so you don't require different files for fonts that support both japanese and latin scripts 07:21:06 ... everything I've said also applies to font-style (for the italic angle) 07:21:14 koji: what's the syntax proposal? 07:21:29 myles: [explains proposal in the issue] 07:22:03 myles: The OpenType piece is that we need to standardize a new axis for vertical width and for non-vertical font you also need a vertical width 07:22:18 nmccully: Adobe has formed an opinion already and has a prototype 07:22:22 q+ 07:22:24 dlibby has joined #css 07:22:31 xfq has joined #css 07:22:39 koji: should it be physical or logical? 07:22:45 fantasai: for font needs to be physical 07:22:47 ack jcraig 07:22:50 ack ? 07:23:14 ... when you're typesetting vertical text you mix both upright and rotated characters, for the glyph's perspective depends on the uprightness 07:23:47 ... upright chars get "longer" in the vertical axes, the other keeps the same height but 07:24:14 ... so for the font descriptor it needs to be physical and the property is logical and only applies in the inline direction 07:24:32 koji: so you're saying physical to line orientation not to glyph orientation 07:24:52 fantasai: font-stretch is line-relative and the font-stretch capability in the font file is physical relative to the glyph orientation 07:25:14 futhark has joined #css 07:25:32 koji: agree 07:25:36 myles: [explains that in a different way] 07:25:40 koji: agree 07:25:51 ack heycam 07:26:13 heycam: I think proposal makes sense, I'd like to understand how authors can achieve this without this feature and how difficult that is compared to the font 07:26:39 nmccully: the browser would have to know how each browser treats the font (regarding upright-ness) 07:26:57 ... then go browser by browser and change fonts per rune 07:27:25 heycam: so part of the issue is that browsers disagree on that, right? (fantasai mentioned punctuation before) 07:27:37 fantasai: yeah, even by that is a per-codepoint thing 07:28:52 fantasai: the initial values of text-orientation mix orientation by default, the author would have to do the automated determination of rotated vs. not for the particular font 07:28:59 ... way too much work to request on an author 07:29:17 nmccully: it's mixing two things, whether something is sideways is not the author decision 07:29:36 ... it's automated based in unicode-range 07:29:39 zcorpan has joined #css 07:29:59 heycam: Oh I assumed that authors would have expectations and browsers would be consistent 07:30:36 fantasai: I think this is the right design, I think it works great for font-stretch 07:30:43 ... for oblique and such it may not 07:31:07 myles: there's another piece. Today if you say font-style: italic on vertical text you'll get weird stuff 07:31:13 ... this proposal will fix that 07:31:23 fantasai: don't we have a resolution on that? 07:31:37 florian: I think hiroshi wanted to reopen that 07:31:50 ... but didn't because nobody seemed to run into a spec 07:32:07 Rossen_: would this change this resolution? 07:32:22 florian: only if we apply it to font-style 07:32:45 fantasai: I think we may have a font-stretch-vertical descriptor rather than stashing it on font-stretch 07:32:59 ... but that's more bikeshedding and I generally agree with the proposal 07:33:06 Rossen_: objections to adopt this? 07:33:23 RESOLVED: Adopt the proposal for font-stretch 07:33:44 Topic: end 07:34:33 Topic: mitigations for font based fingerprinting 07:34:37 duga has joined #css 07:34:44 github: https://github.com/w3c/csswg-drafts/issues/4055 07:35:25 TabAtkins: [introduces the issue] 07:35:48 TabAtkins: we expose a lot of PI data on the web 07:36:24 ... even if you plug fonts we're probably not below the level where you cannot identify a single user 07:36:40 ... to do that you probably need to do software rendering on canvas for example 07:37:00 ... so unless somebody comes up with a list of stuff and data 07:37:08 chris has joined #css 07:37:16 present+ 07:37:18 ... I think we shouldn't do that 07:37:30 ... a bit annoying from a PR standpoint to argue why it doesn't really matter but... 07:37:44 myles: our goal is to remove all the sources of fingerprinting on the web 07:37:57 ... we should reduce as much as possible 07:38:15 TabAtkins: you cannot remove all of them 07:38:27 ... no media queries, etc.. 07:38:37 smfr has joined #css 07:39:08 TabAtkins: unless you could reduce it to 20 you haven't done anything 07:39:26 myles: well you're closer to the goal 07:39:30 [funny methafores] 07:39:42 metaphors* 07:39:42 q? 07:40:13 TabAtkins: going from "individually identify someone" to "individually identify someone" does nothing 07:40:34 ... there's a specific threshold we need to reach to do anything 07:40:45 ... and nobody can 07:40:48 myles: we'll try 07:41:16 dino: I really believe we should ask the question for each feature of what the cost is 07:41:26 ... I accept what TabAtkins says about the number of bits 07:41:49 ... but it's this group's duty to do the cost of the feature vs. the privacy impact 07:42:02 florian: cost is breaking the web for minority languages, benefit is not clear yet 07:42:33 TabAtkins: w3c has the privacy interest group working on this, if their conclusion is that we can hit this range by doing this 07:42:37 ... then happy to 07:43:24 plinss: every time we add a bit we make it that much harder, if we throw our hands up in the air then sure, let's add identifiers 07:43:48 thomas: There's also ways to alert the user it's being fingerprinted 07:44:00 q? 07:44:15 nmccully: I'm hearing mostly that it's not the right fix. We shouldn't make it worse but... 07:45:09 q+ 07:45:18 myles: our job is to design CSS APIs and we have to weight pros and cons. We found that font-based fingerprinting is one of the most unique ways users are fingerprinted. We also found that it doesn't affect most users' experience 07:45:27 ack leaverou 07:45:30 ... so pros and cons seem clear here 07:45:37 emilio: I agree with myles 07:45:58 leaverou: Lots of old sites rely on common fonts like Calibri or Cambria installed 07:46:07 q? 07:46:10 q+ 07:46:12 ... also there's a perf impact of always downloading the font since sites tend to use `local()` 07:46:30 ???: Are we getting ahead of the game between standards and impls 07:46:36 s/???/glenn/ 07:46:37 s/???/Glenn/ 07:46:37 myles: the spec can't do much here 07:47:12 ack flackr 07:47:14 myles: we are an standardization, we can't do more that saying in the spec that should have privacy considerations 07:47:16 ack florian 07:47:24 ... but browsers like Safari can and have gone further 07:47:55 florian: so you mentioned that you investigated the amount of sites 07:48:04 ... that broke or not 07:48:27 ... if you're removing language support minority users can't use the web 07:48:36 ... also bandwidth may be a concern 07:49:00 ... I don't care if sites are slowly slower for californians 07:49:19 myles: having philosophical discussions is not particularly useful 07:49:23 dauwhe has joined #css 07:49:24 ... we need a concrete proposal 07:49:32 ... and there's nothing to resolve on until there's one 07:50:54 ... the spec already says that a UA may or not scan al fonts in the system 07:51:01 Rossen_: out of time 07:51:04 Topic: end 07:51:32 https://github.com/w3c/csswg-drafts/issues/3440#issuecomment-530702998 07:51:49 topic: [css-text][css-sizing] When to/not to include preserved trailing spaces 07:51:57 github: https://github.com/w3c/csswg-drafts/issues/3440#issuecomment-530702998 07:52:16 fantasai: [summarizes situation] 07:52:29 fantasai: proposal is to accept the proposal in https://github.com/w3c/csswg-drafts/issues/3440#issuecomment-530702998 07:52:41 ... I think we should agenda 07:52:53 s/agenda/resolve on that/ 07:52:59 florian: I think koji is ok with it now 07:53:02 Rossen_: objections? 07:53:08 RESOLVED: Accept the proposal in https://github.com/w3c/csswg-drafts/issues/3440#issuecomment-530702998 07:53:15 Topic: end 07:53:38 Topic: system-ui fonts 07:53:43 GitHub: https://github.com/w3c/csswg-drafts/issues/4107 07:54:33 This is my position: https://github.com/w3c/csswg-drafts/issues/4107#issuecomment-525824422 07:54:53 myles: should we expose these like any other font like "Times new roman" or as a keyword like a generic font family, which other browsers would also implement and whose behavior would change across OSes 07:55:00 ... ? 07:55:05 myles: I'd prefer the later 07:55:13 @myles: does adding this as a keyword add a fingerprinting method? is it worth it? ;-) 07:55:13 fantasai: (explains her position above) 07:55:54 fantasai: tldr it makes sense to have system-ui keywords, but they should be exposed also behind an actual name 07:56:16 myles: It's impossible for us to determine because the fonts are nice or because they're systemy 07:56:28 Rossen_: how are you going to determine it? 07:56:29 drousso has joined #css 07:56:57 ... expose it with a proprietary name and you're done 07:57:07 thomas has joined #css 07:57:28 koji: I think regardless of exposing them via the name I think there's use case for the keywords 07:58:20 florian: I think they should be exposed by name, and if after that there's still users asking for that then we're done 07:58:45 q? 07:58:46 ... but just font families is not the only thing that emulating the system 07:58:56 s/that/for 07:59:22 myles: but it's a required part of matching the system, regardless of the rest of the design 08:00:16 florian: it doesn't seem helpful to use system-ui vs. named, if you can just ua-sniff and set the font name 08:00:24 dino: it may help authors in other systems too 08:01:22 koji: we learned from system-ui that authors don't want the exact same font as the system 08:01:51 ... on windows server a bunch of big pages didn't want the system font which was tahoma, they wanted segoe instead 08:02:08 Rossen_: that's why when we released segoe we did it as a font not as a ui keyword 08:03:21 florian: that's interesting, so this is appropriate in the sense that people wants ui fonts, but not the system ui font 08:03:40 myles: so ui-serif rather than system-ui-serif? 08:03:49 florian: if that's the use case that sounds fine 08:04:17 nmccully: having a shorthand seems useful to guarantee that the font is current, is there, and not have to worry about the list of system fonts 08:04:33 q+ 08:05:02 myles: so it seems we're coalescing to add `ui-rounded`, `ui-serif`, `ui-monospace`, ... 08:05:21 florian: I'd also also encourage apple to expose them by name 08:05:26 nmccully: that seems useful 08:05:30 myles: ok, we'll do both 08:05:48 florian: less sure about *-rounded 08:06:23 fantasai: what do we do for `ui-rounded` if there's no rounded font? 08:06:31 ... maybe you have only arial and times? 08:06:44 ... what do you fallback to? 08:06:56 florian: I'd propose just for it not to match so it falls back to the next of the list 08:07:19 leaverou: if we need more granularity to system ui fonts why mapping them to apple? 08:07:35 ... why not system-ui-titletext? 08:07:59 myles: when a platform has a different font for titletext we can consider that 08:08:21 dlibby has left #css 08:08:35 RESOLVED: Add them with the `ui-` prefix and make them not match if they're not available 08:08:56 topic: end 08:09:00 Also resolve that the WG encourages Apple to make their system fonts available under regular names :) 08:09:16 Topic: Mathml 08:09:31 https://mathml-refresh.github.io/mathml-core/ 08:09:45 bkardell_: just letting everybody know that the spec considerably complete, and so is our initial implementation 08:09:53 bkardell_: lots of wpt, lots of answers in the spec 08:10:01 ... total css proposals amount to for 08:10:07 ... *four 08:10:14 ... one of them is `display: math` 08:10:32 ... other three is to display the information that you need to extend mathml 08:11:18 ... we intend to send an intent to implement in october to upstream it so please open your issues and ask your questions and help us make that successful 08:11:40 iank_: mathml cg has decided on some of the mathml / css integration, it'd be great to take a look at those 08:11:50 Topic: ScrollTimeline 08:11:57 lajava has joined #css 08:12:55 zcorpan has joined #css 08:12:56 majidvp: Last f2f I explained the 2 big issues that remained, the css syntax and the problem that the spec only accepts concrete scroll offsets and such and most use cases rely on viewport offsets and such 08:13:20 ... so we got lots of feedback from devs that it's hard to compute the right offsets 08:13:37 basically, same problem as scroll-snap had in the beginning... 08:13:59 ... so we want to propose some changes to scroll timeline to make the scroll offsets not specified but match intersection of boxes or such 08:14:20 majidvp: flackr has done a polyfill for that and the api 08:14:32 nigel_ has joined #css 08:14:44 ... what we're proposing here is specifying offsets in terms of intersection observer semantics 08:14:44 q+ 08:15:17 ... which is start and end of animation as intersection observer offsets 08:15:32 ... just one-dimensional rather than two-dimensional 08:15:52 majidvp: [goes through the proposal in https://github.com/WICG/scroll-animations/issues/51] 08:15:58 github: https://github.com/WICG/scroll-animations/issues/51 08:16:50 majidvp: we're also proposing a function-like syntax 08:17:08 ... but let me show demos 08:18:58 majidvp: [goes through https://flackr.github.io/scroll-timeline/demo/parallax/] 08:21:09 inamori_ has joined #css 08:21:42 majidvp: [goes back to the proposed css syntax] 08:24:37 dauwhe has joined #css 08:24:46 ... there are some open questions like how to fix the circularity in the case layout moves the element while animation 08:25:00 ... proposal is to freeze the offset when the animation starts 08:25:20 q- 08:25:31 ... also how intersections are computed and such 08:25:43 ... these are open questions that we're trying to work through 08:25:48 ... not proposing concrete solution 08:26:07 ... happy to answer questions / feedback / concerns 08:26:27 smfr: I like the way it generally looks, and I like the IntersectionObserver thing 08:26:33 ... seems much more natural 08:26:34 dlibby has joined #css 08:27:04 ... can you do something like a spinner that stops as soon as soon as you scroll away? 08:27:28 majidvp: ScrollTimeline should not solve that, you need a trigger for that... 08:28:19 ... I don't wanted to fix that use case here, but maybe a `:visible` pseudo-class or a CSS intersection observer like syntax 08:28:50 iank_: you can polyfill that already with intersection observer, I think it's nice to keep it focused 08:29:05 dino: I think this would be a simple addition now that we have the range to address this use case 08:29:37 smfr: there's also the case where you stop the animation but let it run to complete a cycle 08:29:55 ... so that it comes back into the viewport in a good position 08:30:01 zcorpan has joined #css 08:30:13 majidvp: may be addressable with the range 08:30:31 zcorpan has joined #css 08:30:41 smfr: another piece of feedback is that it seems that the css api is getting a bit out of control 08:30:48 ... I'd be fine with just a JS api 08:31:10 majidvp: that's the opposite of the last F2F discussion, but it's fine for me... 08:31:59 heycam: the small additions to the Intersection Observer model, they sohuld just be added to Intersection Observer itself 08:32:05 majidvp: I think they should be added to the spec even if they're not web-exposed. 08:32:23 heycam: it'd be nice specially if you don't solve the time-based viewport-triggered animation 08:32:44 majidvp: I _think_ you can compute that with the current IntersectionObserver given it provides the intersection area 08:33:28 Rossen_: Looks awesome, what are you asking from us? 08:33:45 majidvp: confirmation of general direction would be great 08:34:01 ... may be nice to bring into csswg-drafts, though may not be that important 08:34:06 Rossen_: I think we could do that 08:34:13 smfr: where does web-animations live? 08:34:20 birtles: CSS 08:34:36 RESOLVED: moved scroll-timeline into csswg-drafts 08:34:44 topic: end 08:35:07 zcorpan has joined #css 08:35:28 Topic: [css-text-4] Update on word boundaries, previously know as space expansion and discussed in Toronto (Florian) [i18n] 08:35:31 https://drafts.csswg.org/css-text-4/#word-boundaries 08:35:52 florian: at the last f2f I presented a proposal to expand zero width spaces into ideographic spaces 08:35:57 fremy has joined #css 08:36:08 ... I got spec text after the group discussion 08:36:22 ... Another request was to automatically insert them into the markup 08:36:35 ... got review from fantasai and (less) i18n 08:37:06 ... i18n was working on line-breaking of thai text, which needs some analysis on the text, which is not right all of the time 08:37:20 ... since you can use thai alphabet to write non-thai languages 08:37:51 ... so the group wanted to be more explicit about line-breaking in thai, which is similar to the word boundary injection 08:38:07 ... that's all in text-4, it'd be nice for you to review it 08:38:16 ... will start to write text soon, may tweak naming 08:38:30 ... fantasai was a bit skeptic about the automatic insertion 08:38:51 ... about whether browsers will implement language-dependent analysis 08:39:19 ... I think kindle did that, though kindle does have a bounded number of languages unlike browsers 08:39:46 glenn: I'm with fantasai, don't do it, many business do this 08:40:05 Topic: end 08:40:27 Topic: republishing transforms CR 08:40:34 smfr has joined #css 08:40:49 krit: we got some editorial changes 08:41:01 https://drafts.csswg.org/css-transforms/#CR20190214 08:41:25 krit: I don't expect a lot more changes to the spec 08:41:39 ... so I expec to be the last CR before the next step 08:42:01 RESOLVED: publish CR of css-transforms 08:42:19 Topic: Calc for table layout 08:42:27 Github: https://github.com/w3c/csswg-drafts/issues/94 08:43:33 xiaochengh: So the issue is what to do with percentages and calc 08:43:51 ... spec says a bunch of stuff may be treated as auto 08:43:59 "Given the complexities of width and height calculations on table cells and table elements, math expressions involving percentages for widths and heights on table columns, table column groups, table rows, table row groups, and table cells in both auto and fixed layout tables MAY be treated as if auto had been specified." 08:44:00 ... I'm proposing changing the MAY into MUST 08:44:13 ... it's pretty complicated if we don't treat it as auto 08:44:16 q+ 08:44:29 ... second reason is that this is creating friction when implementing min() / max() 08:44:54 ... calc() is complicated, but min() / max() make it a pretty hardly solvable problem 08:45:00 ... so I propose to make this a MUST 08:45:21 rego has joined #css 08:45:28 TabAtkins: this is what dbaron proposed back in the day 08:45:48 ... and we punted min and max because of that 08:45:54 heycam: implementation status? 08:46:08 fremy: all browsers match the spec 08:46:26 ... for normal table layout 08:46:38 ... the algorithm just doesn't make it possible 08:47:09 ... in fixed table layout there's one browser that supports percentages based on the size of the table 08:47:29 ... as to the question of whether we should remove the behavior for normal table layout is fine 08:47:55 ... for fixed layout it'd be nice to also remove it, but Chrome and Safari 08:48:18 ... do respect it so it'd be nice to remove that 08:48:37 ... or add to the spec that it is respected in fixed table layout and how, which should be straight-forward 08:48:49 emilio: there's also the question of whether we should in presence of min and max ... 08:49:05 ... Firefox uesd to treat calc(%) as auto 08:49:07 ... we no longer do that 08:49:16 ... but it raises the question of how min and max behave with only percentages 08:49:20 ... I guess that's fine to resolve? 08:49:25 TabAtkins: I don't want to special case min and max on type 08:49:29 ... that's awkward 08:49:45 ... having min and max work in some case if you have certain shapes of expression inside of it 08:50:17 emilio: I think given the way we behave, all browsers treat calc with percentages as a percentage, we should do the same for min and max 08:50:30 fremy: that sounds reasonable to me 08:50:43 .... if there is a sum of % and px, after you've computed, then you decide not to do anything, follow the MUST 08:50:52 ... if you have min(10%, 20%), the computed value will be 10%, so you don't have the problem 08:50:58 .... I would be in favour of that wording 08:51:45 futhark has joined #css 08:52:30 emilio: what about calc(10% + 0)? 08:52:35 ... that's simplifies to 10% in all browsers 08:52:47 Rossen: yes we've resolved that previously 08:53:28 fremy: so what about fixed mode 08:53:47 ... I assume it's probably fine to apply this rule to both? 08:53:48 zcorpan has joined #css 08:54:02 RESOLVED: Any math expression of a complex type is treated as auto. Simple typed things continue to work as today. 08:54:06 TabAtkins: https://github.com/w3c/csswg-drafts/issues/3482#issuecomment-451590359 08:54:19 zoe: no objections 08:55:27 Topic: Hanging spaces cannot be scrollable overflow 08:55:30 Github: https://github.com/w3c/csswg-drafts/issues/4297 08:56:12 florian: fantasai points out that if we treat hanging spaces as scrollable overflow there's a bunch of cases where we got scrollbars where we don't want 08:56:39 inamori_ has joined #css 08:56:42 ... but on editable stuff you want to create scrollable overflow 08:57:02 ... blink and webkit agree with me, gecko always treats it as ink overflow, edge always layout overflow 08:57:27 ... proposed resolution is treat hanging spaces as ink overflow in general but layout overflow in editable context 08:57:38 fremy: how did you test for editable context 08:58:11 ... you may be testing a different `white-space` due to UA rules 08:58:57 emilio: it feels weird to special case layout based on editable context, whatever that is 08:59:00 Rossen: why? 08:59:15 emilio: there's no good reason for the layout engine to know the editable state of the DOM 08:59:20 ... in Gecko this all works via UA sheets 08:59:34 ... we change a bunch of stuff when something becomes editable, but it's explained through CSS properties 08:59:40 ... specifying something like this seems quite awkward 08:59:53 florian: make it specific to contenteditable only, and not other kinds of editable, would be weird 09:00:03 ... but if it's all kinds of editable, and good old fashioned textarea, .... 09:00:07 But it can be detected with CSS selectors 09:00:12 emilio: if you do that, I would prefer to have some kind of CSS value that causes this effect 09:00:25 ... and specify in HTML or whever that contenteditable and textarea input have this in the UA sheet 09:00:40 florian: if you are editing the content, you never want to not reach the content 09:00:56 ... if you are trying to edit/delete them, if the cursor moves where you can't see it, that's not desirable 09:01:08 emilio: then the UA sheet can have an !important rule 09:01:22 florian: if we define this how is it magical? 09:01:30 emilio: what if it's something slotted into a contenteditable element? 09:01:31 chris has joined #css 09:01:47 fantasai: the main thing that's happening here, if spaces are overflowing in the document, you don't want to create scrollbars for them 09:01:56 ... when you're editing text, it's nice to be able to see the text 09:02:12 ... I don't think authors care. don't think adding a CSS property, increasing the number of things authors could learn, is a benefit here 09:02:15 emilio: sure 09:02:26 fantasai: it makes sense to allow the UA to make it scrollable overflow when that piece of text is editable 09:02:33 ... how you got to that state, doesn't really matter 09:02:45 emilio: why only when it's editable, and not selectable? 09:02:50 ... the caret movement is pretty much the same 09:02:56 ... don't know why those owuld be different 09:03:05 fantasai: the characters are still there, you can select if you go frmo one line to the next 09:03:12 ... but there's a higher priority on not introducing scrollbars 09:03:29 emilio: can we confirm Chrome is doing what you claim it is? 09:03:54 florian: Elika pointed out, if this is awkward to do on the C++ thing, you can have the dedicated CSS value, and make it !Important, and not accessible to users 09:04:12 emilio: I know how to implement it, just doing want it defined in a magical way 09:04:14 futhark has joined #css 09:04:55 -- end -- 09:05:04 github-bot: end 09:05:04 heycam, Sorry, I don't understand that command. Try 'help'. 09:05:07 github-bot: end topic 09:13:48 nigel has joined #css 09:21:57 ericc has joined #css 09:51:22 projector has joined #css 09:51:52 Rossen has joined #css 09:52:22 shans has joined #css 09:52:52 sylvaing has joined #css 09:53:23 leaverou has joined #css 09:53:53 plinss_ has joined #css 10:03:48 drousso has joined #css 10:17:55 smfr has joined #css 11:30:40 futhark has joined #css 11:37:45 mattwoodrow has joined #css 11:53:19 futhark has joined #css 12:02:43 birtles has joined #css 12:06:17 rniwa has joined #css 12:13:09 dauwhe has joined #css 12:16:05 futhark has joined #css 12:46:17 dino has joined #css 12:51:08 Rossen_ has joined #css 12:57:17 futhark has joined #css 12:59:49 karl has joined #css 13:04:03 Zakim has left #css 13:27:24 lajava has joined #css 13:50:58 skk has joined #css 13:52:38 xfq has joined #css 14:22:38 drousso has joined #css 14:42:44 ericc has joined #css 14:58:04 lajava has joined #css 15:03:58 Tav has joined #css 15:19:02 ed has joined #css 19:19:35 atsushi has joined #css 20:58:16 ericc has joined #css 21:36:41 rachelandrew has joined #css 21:36:41 esprehn has joined #css 21:44:07 ericc has joined #css 21:51:21 ericc has joined #css 22:00:23 dauwhe has joined #css 22:15:31 ericc has joined #css 22:37:40 AmeliaBR has joined #css 00:03:10 plh has joined #css 00:03:20 stantonm has joined #css 00:03:25 dauwhe has joined #css 00:05:54 duga has joined #css 00:09:26 ericc has joined #css 00:09:57 skk has joined #css 00:11:59 nigel has joined #css 00:15:41 dauwhe has joined #css 00:25:04 plinss plinss_ which of you should I message? 00:25:38 either, but 'plinss' is always-on 00:28:50 duga has joined #css 00:31:04 inamori_ has joined #css 00:32:56 drousso has joined #css 00:35:10 kzms2 has joined #css 00:35:45 dauwhe has joined #css 00:35:46 drousso_ has joined #css 00:41:05 dino has joined #css 00:49:37 duga has joined #css 00:52:19 birtles has joined #css 00:53:47 mattwoodrow has joined #css 00:58:26 tantek has joined #css 01:06:51 drousso has joined #css 01:08:23 drousso_ has joined #css 01:09:09 ericc has joined #css 01:13:25 duga has joined #css 01:19:30 karl has joined #css 01:20:31 dauwhe has joined #css 01:23:28 inamori_ has joined #css 01:28:48 plh has joined #css 01:34:40 drousso has joined #css 01:39:19 atsushi has joined #css 01:39:23 karl has joined #css 01:45:31 plh has joined #css 01:46:22 skk has joined #css 01:48:33 ericc has joined #css 02:00:13 dauwhe has joined #css 02:00:30 duga has joined #css 02:00:55 rniwa has joined #css 02:01:10 jihye has joined #css 02:02:01 zcorpan has joined #css 02:02:19 dino has joined #css 02:02:38 anssik has joined #css 02:05:03 tdresser has joined #css 02:06:07 karl has joined #css 02:06:13 myles has joined #css 02:06:37 Dongwoo has joined #css 02:07:06 nigel has joined #css 02:07:31 dauwhe has joined #css 02:07:31 Dongwoo has joined #css 02:09:03 skk has joined #css 02:11:09 AmeliaBR has joined #css 02:13:34 fantasai: do you have a link to dbaron's clever gradient test, in plinss's harness? 02:13:50 DavidClarke has joined #css 02:13:58 DavidClarke has left #css 02:14:28 foolip: test at http://test.csswg.org/suites/css-backgrounds-3_dev/nightly-unstable/html4/box-shadow-blur-definition-001.htm 02:15:15 test harness results lists http://test.csswg.org/harness/results/css-backgrounds-3_dev/grouped/box-shadow-blur-definition-001/ 02:15:41 detailed results http://test.csswg.org/harness/details/css-backgrounds-3_dev/box-shadow-blur-definition-001/ 02:15:54 running the test http://test.csswg.org/harness/test/css-backgrounds-3_dev/single/box-shadow-blur-definition-001/format/html4/ 02:17:02 middle stripe is yellow here like the page background 02:17:17 yellow o_O? 02:17:39 i.e. browser default (which i think i configured years ago) 02:18:37 liam, CSSWG test running assumes some things, specifically https://test.csswg.org/suites/css-backgrounds-3_dev/nightly-unstable/#common 02:18:55 one of those things is white background :) 02:19:15 ahm so it is 02:19:19 ok 02:19:38 although it also says, Tests should avoid relying on these assumptions unless necessary. 02:21:53 looks like the test passes now 02:22:38 (having the bg/fg colour defined helps me find places where i didn't set them, but i forget i've done it sometimes!) 02:25:26 fantasai: thanks! 02:40:10 tdresser has joined #css 02:53:02 drousso_ has joined #css 02:53:54 tdresser has joined #css 02:54:40 inamori_ has joined #css 03:04:38 nigel has joined #css 03:09:08 duga has joined #css 03:10:00 mattwoodrow has joined #css 03:10:37 ericc has joined #css 03:13:06 inamori_ has joined #css 03:16:43 atsushi has joined #css 03:18:23 dauwhe has joined #css 03:20:37 ericc_ has joined #css 03:28:48 zcorpan has joined #css 03:34:06 dauwhe has joined #css 03:34:44 ericc has joined #css 03:35:31 zcorpan has joined #css 03:40:02 ericc has joined #css 03:44:39 zcorpan has joined #css 03:49:56 zcorpan has joined #css 03:50:36 dauwhe has joined #css 03:53:41 dauwhe has joined #css 03:56:42 mattwoodrow has joined #css 03:58:31 inamori_ has joined #css 04:03:07 dauwhe has joined #css 04:05:01 sanketj has joined #css 04:08:15 inamori_ has joined #css 04:18:39 zcorpan has joined #css 04:19:52 duga has joined #css 04:22:10 tantek has joined #css 04:22:17 tdresser has joined #css 04:22:39 duga has joined #css 04:24:07 karl has joined #css 04:24:52 dauwhe has joined #css 04:29:53 rego has joined #css 04:30:24 rniwa has joined #css 04:30:44 ericc_ has joined #css 04:32:07 nigel has joined #css 04:33:11 myles has joined #css 04:33:51 plh has joined #css 04:34:06 drousso has joined #css 04:34:54 dino has joined #css 04:35:01 bkardell_ has joined #css 04:36:02 aboxhall_ has joined #css 04:36:22 rachelandrew_ has joined #css 04:37:22 tdresser has joined #css 04:37:47 zcorpan has joined #css 04:37:49 zcorpan has joined #css 04:42:06 skk has joined #css 04:46:55 atsushi has joined #css 04:50:59 dauwhe_ has joined #css 04:51:13 karl has joined #css 04:52:41 dino has joined #css 04:56:26 inamori_ has joined #css 05:09:03 mattwoodrow has joined #css 05:11:15 tdresser has joined #css 05:19:14 dino has joined #css 05:20:06 smfr has joined #css 05:24:15 tdresser has joined #css 05:24:34 duga has joined #css 05:26:54 zcorpan has joined #css 05:27:32 dauwhe has joined #css 05:27:55 ericc has joined #css 05:28:57 smfr has joined #css 05:29:26 zcorpan_ has joined #css 05:29:58 myles has joined #css 05:30:13 nigel has joined #css 05:30:37 rniwa has joined #css 05:31:33 drousso has joined #css 05:31:35 fergal_daly has joined #css 05:32:35 zcorpan__ has joined #css 05:33:03 kzms2 has joined #css 05:33:36 most interoperable directories in css/, with 4/4 stable browsers passing: WOFF2, css-box, css-conditional, css-variables, css-flexbox, css-namespaces, css-transitions, cssom, css-tables, css-inline… 05:33:45 mattwoodrow has joined #css 05:33:46 dauwhe_ has joined #css 05:33:50 css-tables is surprisingly high up there 05:34:17 dino has joined #css 05:34:34 dino has joined #css 05:36:22 tantek has joined #css 05:36:44 nigel_ has joined #css 05:42:41 skk has joined #css 05:45:48 atsushi has joined #css 05:48:46 gsnedders: is that number of 4/4 tests, or percentage of tests that are 4/4, or ?? 05:51:16 smfr has joined #css 05:51:19 tdresser has joined #css 05:54:09 inamori_ has joined #css 05:55:05 skk has joined #css 05:55:09 astearns: percentage of tests that are 4/4 06:05:39 liam has joined #css 06:22:50 mattwoodrow has joined #css 06:30:16 duga has joined #css 06:32:17 rniwa has joined #css 06:33:22 dauwhe has joined #css 06:38:19 myles has joined #css 06:59:12 plh has joined #css 07:04:35 nigel has joined #css 07:10:44 myles has joined #css 07:11:14 myles has joined #css 07:16:12 tdresser has joined #css 07:17:42 Ms2ger has joined #css 07:21:58 nigel has joined #css 07:22:32 nigel_ has joined #css 07:23:03 duga has joined #css 07:24:02 duga has joined #css 07:24:07 dauwhe has joined #css 07:27:28 ericc has joined #css 07:27:47 zcorpan has joined #css 07:28:09 zcorpan has joined #css 07:31:12 myles has joined #css 07:31:50 smfr has joined #css 07:31:51 drousso has joined #css 07:31:59 nigel has joined #css 07:32:04 zcorpan has joined #css 07:32:15 kereliuk has joined #css 07:33:21 birtles has joined #css 07:33:30 duga has joined #css 07:33:47 plinss_ has joined #css 07:34:12 plh has joined #css 07:34:44 emilio has joined #css 07:35:24 dino has joined #css 07:35:44 tantek has joined #css 07:36:26 skk has joined #css 07:36:44 smfr has joined #css 07:49:53 RRSAgent: where are the logs? 07:49:53 I'm logging. Sorry, nothing found for 'where are the logs' 07:59:56 plh has joined #css 08:00:07 nigel_ has joined #css 08:00:23 skk_ has joined #css 08:01:51 RRSAgent, pointer? 08:01:51 See https://www.w3.org/2019/09/15-css-irc#T08-01-51 08:01:56 foolip: ^^^ 08:02:02 RRSAgent, make logs public 08:04:53 lajava has joined #css 08:06:14 mattwoodrow has joined #css 08:19:11 karl has joined #css 08:23:52 liam has joined #css 08:25:18 dauwhe has joined #css 08:27:05 tantek: thanks! 08:28:29 smfr has joined #css 08:30:39 drousso has joined #css 08:30:46 zcorpan has joined #css 08:30:57 myles has joined #css 08:31:04 drousso has joined #css 08:31:25 zcorpan has joined #css 08:33:06 dino has joined #css 08:34:36 ericc has joined #css 08:35:01 nigel_ has joined #css 08:35:06 dauwhe has joined #css 08:35:46 nigel has joined #css 08:41:16 luyan has joined #css 08:41:29 aaaaa 08:44:11 dauwhe has joined #css 08:45:50 luyan has joined #css 08:46:18 luyan has left #css 08:46:33 skk has joined #css 08:55:43 ...why is trackbot our only op? 08:57:19 trackbot owns us. 08:57:19 Sorry, gsnedders, I don't understand 'trackbot owns us.'. Please refer to for help. 08:57:34 thanks trackbot. 08:57:36 trackbot is a comrade 08:57:36 Sorry, TabAtkins, I don't understand 'trackbot is a comrade'. Please refer to for help. 09:07:43 dauwhe has joined #css 09:12:27 plh has joined #css 09:15:45 mattwoodrow has joined #css 09:31:45 nigel has joined #css 09:54:00 atsushi has joined #css 10:05:51 projector has joined #css 10:06:21 Rossen has joined #css 10:06:51 shans has joined #css 10:07:21 sylvaing has joined #css 10:07:51 leaverou has joined #css 10:08:22 plinss_ has joined #css 10:15:46 plh has joined #css 10:47:27 plh has joined #css 11:28:47 tdresser has joined #css 12:46:48 plh has joined #css 12:49:05 karl has joined #css 13:17:25 tdresser has joined #css 13:23:24 dauwhe has joined #css 13:28:19 antonp has joined #css 13:28:27 tdresser has joined #css 13:37:27 tdresser has joined #css 13:49:42 dauwhe has joined #css 13:50:31 innovati has joined #css 14:02:02 tdresser has joined #css 14:09:16 projector has joined #css 14:09:46 Rossen has joined #css 14:10:16 shans has joined #css 14:10:46 sylvaing has joined #css 14:11:16 leaverou has joined #css 14:11:47 plinss_ has joined #css 14:13:19 mattwoodrow has joined #css 14:46:44 atsushi has joined #css 15:29:59 lajava has joined #css 15:56:05 bdc has joined #css 16:19:51 plh has joined #css