IRC log of css on 2019-09-15
Timestamps are in UTC.
- 23:49:29 [RRSAgent]
- RRSAgent has joined #css
- 23:49:29 [RRSAgent]
- logging to https://www.w3.org/2019/09/15-css-irc
- 23:49:31 [trackbot]
- RRSAgent, make logs public
- 23:49:31 [Zakim]
- Zakim has joined #css
- 23:49:33 [trackbot]
- Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
- 23:49:33 [trackbot]
- Date: 15 September 2019
- 23:49:37 [astearns]
- rrsagent, this meeting spans midnight
- 23:51:39 [xfq_]
- xfq_ has joined #css
- 23:53:53 [prushforth]
- prushforth has joined #css
- 23:54:52 [smfr]
- smfr has joined #css
- 23:58:05 [drousso]
- drousso has joined #css
- 00:01:25 [Rossen_]
- Rossen_ has joined #css
- 00:01:35 [Rossen_]
- trackbot, start meeting
- 00:01:38 [trackbot]
- RRSAgent, make logs public
- 00:01:41 [trackbot]
- Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
- 00:01:41 [trackbot]
- Date: 16 September 2019
- 00:01:44 [Rossen_]
- Rossen_ has changed the topic to: TPAC 2019, day 1
- 00:04:20 [stantonm]
- stantonm has joined #css
- 00:05:25 [skk]
- skk has joined #css
- 00:11:57 [myles]
- myles has joined #css
- 00:12:04 [myles]
- present+ myles
- 00:12:26 [leaverou]
- present+ leaverou
- 00:12:36 [eae]
- present+
- 00:13:17 [cmp]
- cmp has joined #css
- 00:13:26 [skk]
- present+
- 00:13:37 [futhark]
- futhark has joined #css
- 00:14:06 [plinss]
- present+
- 00:14:19 [smfr]
- present+
- 00:14:22 [cbiesinger]
- present+
- 00:14:53 [florian]
- present+ Florian Rivoal, Invited Expert
- 00:15:08 [krit]
- present+
- 00:15:09 [futhark]
- present+
- 00:15:12 [cam]
- present+
- 00:15:27 [mstange]
- present+
- 00:15:35 [jihye]
- present+
- 00:15:43 [dino]
- dino has joined #css
- 00:15:47 [birtles]
- present+
- 00:16:06 [prushforth]
- present+
- 00:16:15 [kzms2]
- kzms2 has joined #css
- 00:16:19 [dbaron]
- present+
- 00:16:25 [Rossen_]
- Rossen Atanassov, Microsoft
- 00:16:30 [bkardell_]
- bkardell_ has joined #css
- 00:16:30 [Rossen_]
- present+
- 00:16:30 [astearns]
- Alan Stearns, Adobe
- 00:16:35 [oriol]
- Oriol Brufau, Igalia
- 00:16:36 [xfq_]
- present+
- 00:16:41 [emilio]
- present+
- 00:16:43 [plinss]
- Peter Linss, Invited Expert
- 00:16:45 [dbaron]
- L. David Baron, Mozilla
- 00:16:45 [stantonm]
- Stanton Marcum, Amazon
- 00:16:48 [SimonSapin]
- present+ Simon Sapin, Mozilla
- 00:16:48 [skk]
- Hiroshi Sakakibara, Beyond Perspective Solutions(BPS)
- 00:16:51 [birtles]
- Brian Birtles, Invited Expert
- 00:16:52 [heycam]
- Cameron McCormack, Mozilla
- 00:16:58 [mstange]
- Markus Stange, Mozilla
- 00:17:11 [krit]
- Dirk Schulze, Adobe
- 00:17:13 [emilio]
- Emilio Cobos, Mozilla
- 00:17:18 [cathiechen]
- cathiechen has joined #css
- 00:17:21 [eae]
- Emil A Eklund, Google
- 00:17:23 [drott]
- Dominik Röttsches, Google
- 00:17:23 [futhark]
- Rune Lillesveen, Google
- 00:17:28 [nmccully_]
- nmccully_ has joined #css
- 00:17:29 [koji]
- Koji Ishii, Google
- 00:17:39 [zcorpan]
- zcorpan has joined #css
- 00:17:43 [myles]
- Myles C. Maxfield, Apple
- 00:17:43 [cbiesinger]
- Christian Biesinger, Google
- 00:18:10 [fantasai]
- Elika Etemad, Invited Expert
- 00:18:11 [nmccully_]
- Nat McCully, Adobe
- 00:18:12 [atotic]
- atotic has joined #css
- 00:18:13 [rachelandrew]
- present+ Rachel Andrew, Fronteers
- 00:18:20 [mattwoodrow]
- mattwoodrow has joined #css
- 00:18:29 [xfq_]
- Fuqiao Xue, W3C
- 00:18:29 [atotic]
- present+ Aleks Totic, Google
- 00:18:31 [mattwoodrow]
- Matt Woodrow, Mozilla
- 00:18:34 [cmp]
- Chase Phillips, Google
- 00:18:35 [jihye]
- Jihye Hong. LGE
- 00:18:38 [oriol]
- present+
- 00:18:39 [bkardell_]
- present+ Brian Kardell, Igalia and Open JS Foundation
- 00:18:42 [stantonm]
- present+
- 00:18:46 [drousso]
- Devin Rousso, Apple
- 00:18:46 [mattwoodrow]
- present+
- 00:18:50 [chrishtr]
- present+
- 00:18:51 [fantasai]
- ScribeNick: fantasai
- 00:18:55 [fantasai]
- Topic: F2F Scheduling
- 00:18:56 [drousso]
- present+
- 00:18:58 [drott]
- present+
- 00:19:31 [fantasai]
- Rossen_: January is already in the books
- 00:19:37 [fantasai]
- Rossen_: Jan 22-24 hosted by Igalia
- 00:19:44 [AmeliaBR]
- AmeliaBR has joined #css
- 00:20:08 [fantasai]
- fantasai: Should we resolve on Rego's suggestion to run 10-7pm?
- 00:20:11 [AmeliaBR]
- present+
- 00:20:19 [cathiechen_]
- cathiechen_ has joined #css
- 00:20:31 [AmeliaBR]
- Amelia Bellamy-Royds, invited expert
- 00:20:37 [ekashida]
- ekashida has joined #css
- 00:20:42 [fantasai]
- florian: Reason was local schedules, restaurants don't open until 8/8:30pm
- 00:20:46 [fantasai]
- RESOLVED: Igalia meeting is 10-7
- 00:21:03 [fantasai]
- Rossen_: Dates from Apple?
- 00:21:13 [prushforth]
- Peter Rushforth, Natural Resources Canada, Invited Expert, Observer
- 00:21:15 [fantasai]
- astearns: Tess said she's trying to reserve April 27-30
- 00:21:24 [fantasai]
- astearns: Don't have an update on if she succeeded
- 00:22:01 [fantasai]
- 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 [fantasai]
- skk: Will there be a Houdini meeting?
- 00:22:10 [fantasai]
- Rossen_: Not in April
- 00:22:19 [ekashida]
- Eugene Kashida, Salesforce, Observer
- 00:22:22 [fantasai]
- Rossen_: Possible Summer locations are Kyoto, France, NYC
- 00:22:27 [AmeliaBR]
- s/Not in April/Not in Spain, in April there will be one/
- 00:22:31 [fantasai]
- Rossen_: Anyone up for sponsoring F2F meeting?
- 00:22:56 [fantasai]
- 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 [fantasai]
- Rossen_: NYC would put two consecutive in USA
- 00:23:34 [fantasai]
- astearns: Maybe. April might be in Ireland
- 00:23:58 [fantasai]
- Rossen_: So looking at July 20-24 or July 27-31, last two weeks of July
- 00:24:26 [fantasai]
- dbaron: That is not the idea for Japan, not only because it's warm but also Tokyo Olympics are then
- 00:25:01 [fantasai]
- s/idea/ideal time/
- 00:25:10 [fantasai]
- hober: I have dates!
- 00:25:20 [fantasai]
- hober: Did we want to have Houdini, also?
- 00:25:26 [fantasai]
- hober: I have three days confirmed, 4th not confirmed yet
- 00:25:39 [fantasai]
- hober: Booked for Monday 27 April - 29, in Cork, Ireland
- 00:26:09 [fantasai]
- Rossen_: Sounds great
- 00:26:52 [fantasai]
- RESOLVED: CSSWG meeting Monday 27 April 2020 - Wed 29 April 2020, Houdini afterward (pending booking confirmation)
- 00:27:04 [fantasai]
- Rossen_: Back to summer
- 00:27:13 [fantasai]
- Rossen_: Who was offering to host in NYC?
- 00:27:26 [fantasai]
- dbaron: Think it was Una (Google)
- 00:27:34 [fantasai]
- TabAtkins: We can probably do it
- 00:27:56 [fantasai]
- Rossen_: Ok, check about it and let us know
- 00:28:12 [fantasai]
- TENTATIVE: End of July 2020 in NYC
- 00:28:36 [fantasai]
- Topic: CSS Contain
- 00:28:52 [fantasai]
- Rossen_: Proposed to publish a PR of CSS Contain 1
- 00:29:05 [fantasai]
- florian: Afaict, it's complete
- 00:29:16 [fantasai]
- florian: All tests pass in 2 browsers, except those which depend on other less-mature specs
- 00:29:21 [fantasai]
- florian: So I think we are ready for PR
- 00:29:32 [fantasai]
- florian: One more note, all tests pass if we don't count the at-risk feature
- 00:29:35 [dbaron]
- https://drafts.csswg.org/css-contain/issues-2019-cr.html
- 00:29:39 [fantasai]
- florian: the style containment is not implemented properly anywhere
- 00:29:46 [fantasai]
- florian: but that's why we marked it at risk
- 00:29:48 [dbaron]
- https://drafts.csswg.org/css-contain/implementation-report-2019-09
- 00:29:56 [dbaron]
- https://drafts.csswg.org/css-contain/annotated-2019-09-05.html
- 00:30:03 [fantasai]
- 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 [dbaron]
- https://github.com/w3c/csswg-drafts/labels/css-contain-1
- 00:30:12 [dbaron]
- https://drafts.csswg.org/css-contain-1/
- 00:30:19 [fantasai]
- Rossen_: So PR version will have 3.3 dropped for Level 1
- 00:30:31 [fantasai]
- Rossen_: Objections on resolving to publish PR of CSS Contain 1 with dropped section?
- 00:30:40 [xiaochengh]
- xiaochengh has joined #css
- 00:30:48 [fantasai]
- dbaron: Is the state of style containment that implementations are shipping support and not passing tests, or not shipping support?
- 00:30:58 [fantasai]
- eae: Combination of both
- 00:31:14 [fantasai]
- florian: Chrome ships a buggy one, and Gecko doesn't ship iirc
- 00:31:19 [fantasai]
- heycam: We don't recognize the value
- 00:31:29 [fantasai]
- smfr: Are the two implementations blink and gecko?
- 00:31:30 [fantasai]
- florian: Yes
- 00:31:46 [fantasai]
- Rossen_: Hearing no objections,
- 00:32:06 [zcorpan]
- zcorpan has joined #css
- 00:32:11 [fantasai]
- RESOLVED: PR of css-contain-1, dropping style containment (at-risk)
- 00:32:32 [fantasai]
- florian: For Level 2
- 00:32:51 [fantasai]
- florian: if we add new features, need fpwd, but if not adding a new feature can go directly to CR
- 00:33:02 [fantasai]
- Topic: Contain Size
- 00:33:08 [astearns]
- explainer: https://github.com/WICG/display-locking/blob/master/explainer-content-size.md
- 00:33:14 [fantasai]
- chrishtr: Posted a new explainer
- 00:33:20 [dbaron]
- s/Contain Size/content-size/
- 00:33:21 [fantasai]
- chrishtr: content-size is a new CSS property
- 00:33:39 [fantasai]
- chrishtr: If 'contain: size' is specified, content-size is treated as intrinsic size of contents
- 00:34:00 [fantasai]
- chrishtr: proposing that be able to set intrinsic width/height passed to intrinsic sizing algorithms
- 00:34:16 [fantasai]
- 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 [fantasai]
- chrishtr: can express a placeholder sizing for it
- 00:34:34 [fantasai]
- chrishtr: Allows communicating that placeholder sizing, so that flex/grid/table/etc can take that into account
- 00:34:41 [astearns]
- github: https://github.com/w3c/csswg-drafts/issues/4229
- 00:34:50 [fantasai]
- chrishtr: If we've skipped rendering as an optimization, dev can use to communicate placeholder sizing
- 00:34:58 [fantasai]
- SimonSapin: Would this property apply without 'contain'?
- 00:35:07 [Rossen_]
- a?
- 00:35:08 [fantasai]
- chrishtr: When you don't have 'contain: size', no
- 00:35:09 [Rossen_]
- q?
- 00:35:16 [AmeliaBR]
- q+
- 00:35:28 [fantasai]
- chrishtr: Only applies when 'contain: size'. Reason is that 'contain: size' causes no competing intrinsic size
- 00:35:42 [fantasai]
- chrishtr: 2nd reason is that it fits neatly with render subtree attribute proposal
- 00:35:57 [fantasai]
- florian: Can you expand on the second point? I'm not faimilar with that
- 00:36:15 [fantasai]
- florian: In isolation proposition makes sense, but not sure why it's not coupled with a more generic intrinsic size feature
- 00:36:40 [fantasai]
- 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 [fantasai]
- TabAtkins: Seems like only time you need to provide a better intrinsic size is when you're contain sizing already
- 00:36:56 [fantasai]
- dbaron: I'm skeptical of that
- 00:37:13 [fantasai]
- 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 [fantasai]
- dbaron: Talked about some o those cases in the past
- 00:37:25 [fantasai]
- dbaron: Some cases devs want to override only in one dimension
- 00:37:32 [fantasai]
- TabAtkins: Bad behavior of intrins scorllers maybe?
- 00:37:37 [fantasai]
- TabAtkins: flexboxes blowing up
- 00:37:41 [fantasai]
- dbaron: Didn't have that in my head, but sure
- 00:37:45 [fantasai]
- TabAtkins: That's intriguing
- 00:37:54 [rakina]
- rakina has joined #css
- 00:38:02 [fantasai]
- 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 [fantasai]
- AmeliaBR: Lots of cases there might be a demand for it
- 00:38:24 [fantasai]
- AmeliaBR: Wrt naming, 'content-size' might be interepreted as size of content-box
- 00:38:34 [chris]
- chris has joined #css
- 00:38:37 [fantasai]
- AmeliaBR: If there is a limitation, tho, should be good reasons for it
- 00:38:41 [chris]
- present+
- 00:38:45 [fantasai]
- TabAtkins: Yes, happy to come up with better name
- 00:38:52 [Rossen_]
- q?
- 00:39:05 [chris]
- rrsagent, here
- 00:39:05 [RRSAgent]
- See https://www.w3.org/2019/09/15-css-irc#T00-39-05
- 00:39:07 [fantasai]
- 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 [AmeliaBR]
- ack me
- 00:39:21 [fantasai]
- TabAtkins: In some cases can inflate itnrinsic size, others might be able to shrink
- 00:39:29 [fantasai]
- TabAtkins: good idea
- 00:39:48 [Rossen_]
- ack fantasai
- 00:39:52 [iank_]
- present+
- 00:40:02 [florian]
- fantasai: Support florian and dbaron , this should probably be a generic mechanism
- 00:40:14 [florian]
- fantasai: the value space would be legacy | auto | <size>
- 00:40:28 [florian]
- ???: what is the diff between legacy and auto
- 00:40:35 [TabAtkins]
- s/???/cbiesinger/
- 00:40:45 [florian]
- fantasai: scrollers collapsing to 0 or not
- 00:41:46 [florian]
- 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 [fantasai]
- 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]
- fantasai: Well, I think it would
- 00:42:31 [xfq_]
- ack dbaron
- 00:42:32 [fantasai]
- 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]
- fremy has joined #css
- 00:42:47 [florian]
- fantasai: if you specify an explicit size, that takes over and you ignore the content
- 00:42:59 [fantasai]
- TabAtkins: Could do that... was wondering if you wanted to max them
- 00:43:31 [fantasai]
- 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 [fantasai]
- AmeliaBR: Just say if you specify a value, you wanted to override
- 00:43:58 [fantasai]
- chrishtr: All these examples that were alluded to but not explicit, please write into issue
- 00:44:16 [fantasai]
- fantasai: Based on discussion, this doesn't go into contain, goes into Sizing level 4
- 00:44:19 [florian]
- fantasai: based on this discussion, this goes into sizing-4, not contain-2
- 00:44:32 [fantasai]
- Rossen_: Anything else on this topic
- 00:44:41 [fantasai]
- TabAtkins: Discussion was good
- 00:44:53 [fantasai]
- chrishtr: Point Florian raised about, what are you talking about wrt render subtree
- 00:44:57 [fantasai]
- chrishtr: maybe wait until we talk about that
- 00:45:07 [fantasai]
- chrishtr: but 5min background on render subtree, though it's on the HTML spec
- 00:45:18 [fantasai]
- chrishtr: package, how they fit together matters, so just want to mention
- 00:45:23 [tantek]
- tantek has joined #css
- 00:45:25 [fantasai]
- Rossen_: we can put that topic next
- 00:45:37 [fantasai]
- chrishtr: Just want to give an overview of what it is, what use csaes are, how it functions
- 00:45:46 [fantasai]
- chrishtr: so can get some feedback
- 00:46:40 [fantasai]
- Rossen_: So content-size, or whatever we're going to call it, will go to size level 4
- 00:46:42 [tantek]
- present+
- 00:46:46 [fantasai]
- Rossen_: Any objections to add it?
- 00:47:01 [chrishtr]
- Explainer that contains rendersubtree: https://github.com/WICG/display-locking/blob/master/README.md
- 00:47:03 [fantasai]
- TabAtkins: maybe call it intrinsic-size
- 00:47:07 [Dongwoo]
- Dongwoo has joined #css
- 00:47:07 [fantasai]
- fantasai: Nobody wants to spell that
- 00:47:09 [fantasai]
- TabAtkins: true
- 00:47:47 [fantasai]
- fantasai: There was a suggestion that this be split into width/height not one property for both dimensions
- 00:48:24 [fantasai]
- fantasai: Seems to be the proposal is foo-width/height/inline-size/block-size
- 00:48:30 [fantasai]
- iank_: legacy as initial value?
- 00:48:56 [fantasai]
- PROPOSAL: Add proxy-width/height/inline-size/block-size with values legacy | auto | <length>
- 00:49:03 [fantasai]
- RESOLVED: Add proxy-width/height/inline-size/block-size with values legacy | auto | <length>
- 00:49:13 [fantasai]
- Topic: Contain level 2
- 00:49:23 [fantasai]
- florian: We could go CR directly, but we might want to change things so maybe fpwd is better
- 00:49:35 [fantasai]
- florian: some suggestions, e.g. single-axis contain, etc.
- 00:49:41 [fantasai]
- florian: might want to add
- 00:50:03 [fantasai]
- RESOLVED: FPWD css-contain-2 being copy of css-contain-1 (including at-risk features)
- 00:50:17 [fantasai]
- Topic: Render subtree
- 00:50:26 [fantasai]
- chrishtr: I posted alink to an explainer earlier
- 00:50:34 [chrishtr]
- Explainer that contains rendersubtree: https://github.com/WICG/display-locking/blob/master/README.md
- 00:50:42 [chrishtr]
- https://github.com/whatwg/html/pull/4862
- 00:50:52 [fantasai]
- chrishtr: PR for spec idea
- 00:51:00 [glenn]
- glenn has joined #css
- 00:51:05 [fantasai]
- chrishtr: render-subtree attribute is an attr you can put on any HTML or SVG element
- 00:51:17 [fantasai]
- chrishtr:Has one or more keywords that are space-separated
- 00:51:17 [bkardell_]
- ... or mathml?
- 00:51:22 [fantasai]
- chrishtr: ex. rendersubtree=invisible
- 00:51:30 [fantasai]
- chrishtr: what that means is that it is invisible, but takes up layout space
- 00:51:38 [HeWenli_]
- HeWenli_ has joined #css
- 00:51:41 [fantasai]
- chrishtr: and also is designed so that UA doesn't need to do any render work for that subtree
- 00:51:50 [fantasai]
- chrishtr: no heuristics to figure out whether needs to render that subtree
- 00:51:53 [fantasai]
- chrishtr: you load a web page
- 00:51:58 [fantasai]
- chrishtr: bunch of content not on screne atm
- 00:52:04 [fantasai]
- chrishtr: you like that page to load quickly, not have extra layout cost
- 00:52:07 [fantasai]
- chrishtr: not load external resources
- 00:52:10 [fantasai]
- chrishtr: etc.
- 00:52:15 [fantasai]
- chrishtr: for stuff that's not on screen right now
- 00:52:21 [fantasai]
- chrishtr: common because scrolling is common on web, and large websites
- 00:52:27 [fantasai]
- chrishtr: what does attriute do when set to invisible?
- 00:52:30 [inamori_]
- inamori_ has joined #css
- 00:52:42 [fantasai]
- chrishtr: First, it applies layout, style, and size containment
- 00:52:54 [fantasai]
- chrishtr: layout containment is good, content below can't escape layout of the element at the root of the subree
- 00:52:58 [fantasai]
- chrishtr: size containment for imilar reasons
- 00:53:15 [fantasai]
- chrishtr: dont' need to know layout to compute layout of the page
- 00:53:23 [fantasai]
- chrishtr: so don't need to do layout, don't need to paint it,
- 00:53:27 [fantasai]
- chrishtr: not painted to screen and not hit-testable
- 00:53:32 [florian]
- q+
- 00:53:35 [fantasai]
- chrishtr: so don't need to do any work as UA to process that DOM subtree
- 00:53:39 [fantasai]
- chrishtr: is present, but doesn't cause any work
- 00:53:51 [fantasai]
- chrishtr: that's the core value-add of the 'rendersubtree=invisible'
- 00:53:55 [fantasai]
- chrishtr: Other value syou can add
- 00:54:21 [fantasai]
- 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 [fantasai]
- chrishtr: to render the content
- 00:54:30 [fantasai]
- chrishtr: e.g. wikipedia, stuff below the fold
- 00:54:42 [fantasai]
- chrishtr: wikipedia markes as activatable
- 00:54:45 [fantasai]
- chrishtr: and invisible
- 00:54:55 [fantasai]
- chrishtr: when user or a11y API wants to look at that content
- 00:54:57 [AmeliaBR]
- q+
- 00:55:03 [fantasai]
- chrishtr: or user wants to do find-in-page operation
- 00:55:11 [fantasai]
- chrishtr: and UA notices the content is below the fold off-screen content
- 00:55:18 [fantasai]
- browser would be able to cause the content to rnder
- 00:55:23 [fantasai]
- chrishtr: which has effect of causing it to render
- 00:55:31 [fantasai]
- chrishtr: and script can observe the mutation of the attribute through a mutation observer
- 00:55:32 [heycam]
- q+
- 00:55:36 [fantasai]
- chrishtr: takes some action to help
- 00:55:45 [fantasai]
- chrishtr: or in simplest cases, content is just rendered
- 00:55:54 [SimonSapin]
- q+ difference with 'display: none'?
- 00:55:58 [fantasai]
- chrishtr: important because lots of UA algorithms not controlled by authro
- 00:56:06 [fantasai]
- chrishtr: e.g. a11y, anchor link navigation, tabbing between focusable elements
- 00:56:13 [fantasai]
- chrishtr: scroll-int-view operation, find-in-page
- 00:56:16 [fremy]
- q+
- 00:56:20 [fantasai]
- chrishtr: finally, two additional keywords
- 00:56:25 [fantasai]
- chrishtr: one prevents external resources from being loaded
- 00:56:39 [astearns]
- ack diff
- 00:56:39 [fantasai]
- chrishtr: image wouldn't be loaded until whole-loads keyword is removed
- 00:56:44 [astearns]
- ack with
- 00:56:48 [fantasai]
- chrishtr: avoids blocking network pipeline for stuff below the fold
- 00:56:49 [SimonSapin]
- q+
- 00:56:50 [astearns]
- ack 'dis
- 00:56:55 [astearns]
- ack none
- 00:57:01 [fantasai]
- chrishtr: useful for feeds of info like fb, twitter, also for page with lots of images off-screen
- 00:57:17 [fantasai]
- chrishtr: This is a lazyloading feature similar to what chromim is trying to ship
- 00:57:18 [inamori_]
- inamori_ has joined #css
- 00:57:23 [fantasai]
- chrishtr: Finally, web component ??
- 00:57:29 [fantasai]
- chrishtr: if you have custom elements defined in your registry,
- 00:57:36 [fantasai]
- chrishtr: if element was registered, runs create callback
- 00:57:45 [fantasai]
- chrishtr: allows dev script to participate in rendering the custom elements
- 00:57:51 [fantasai]
- chrishtr: but if elements are off-screen, then cost isn't desirable
- 00:57:57 [fantasai]
- chrishtr: dev would prefer not to run script until content is on-screen
- 00:57:59 [duga]
- duga has joined #css
- 00:58:02 [astearns]
- s/??/element upgrades/
- 00:58:10 [fantasai]
- chrishtr: way this fits in with content-size is that if you set the render subtree attribute to 'invisible'
- 00:58:13 [fantasai]
- chrishtr: has containment
- 00:58:22 [fantasai]
- chrishtr: therefore content-size would take over sizing of unrendered content
- 00:58:43 [fantasai]
- chrishtr: this way, when content is subsequently rendered via UA action or dev activation
- 00:58:48 [fantasai]
- chrishtr: layout doesn't jump around
- 00:58:57 [fantasai]
- chrishtr: contain: size is only applied when invisible
- 00:59:10 [bobbytung]
- bobbytung has joined #css
- 00:59:15 [fantasai]
- chrishtr: when not invisible, then it will no longer have 'contain-size', automatically uses actual size
- 00:59:25 [smfr]
- q+
- 00:59:37 [fantasai]
- chrishtr: intrinsic size without size containment might be compelling enough to drop this connection, but that's what we were thinking
- 00:59:41 [fantasai]
- chrishtr:
- 00:59:49 [dauwhe]
- dauwhe has joined #css
- 00:59:52 [fantasai]
- chrishtr: 'display: none' doesn't help for off-screen content because idoesn't take up layout space
- 01:00:11 [fantasai]
- chrishtr: 'visibility: hidden' doesn't stop layout, and also can be overridden by descendants, so have to render through the subtree
- 01:00:28 [fantasai]
- Rossen_: 'display: none' + 'contain: size"
- 01:00:32 [fantasai]
- chrishtr: display: none box is gone
- 01:00:41 [fantasai]
- chrishtr: rendersubtree=invisible, the box is still there, only its contents are gone
- 01:00:54 [fantasai]
- 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 [Rossen_]
- q?
- 01:01:20 [Rossen_]
- ack smfr
- 01:01:23 [BoCupp]
- BoCupp has joined #css
- 01:01:44 [fantasai]
- smfr: What's the behavior when element with visible subtree changes to invisible
- 01:01:54 [fantasai]
- chrishtr: if you just addd 'rendersutreeinvisble' to element
- 01:02:03 [fantasai]
- chrishtr: it'll apply contain: style layout size
- 01:02:07 [fantasai]
- chrishtr: and not render the contents
- 01:02:12 [fantasai]
- chrishtr: but element itself will still read
- 01:02:21 [AmeliaBR]
- s/addd 'rendersutreeinvisble'/add `rendersubtree="invisible"`/
- 01:02:24 [fantasai]
- chrishtr:script can still read style, could cause layout thrashing
- 01:02:37 [fantasai]
- smfr: so toggle from visible to invisible, ...
- 01:02:43 [fantasai]
- smfr: does it give you a stale value?
- 01:02:51 [fantasai]
- chrishtr: Will do the work to get you the right value
- 01:02:57 [fantasai]
- chrishtr: doesn't cause it to render, but has to do calculations
- 01:03:01 [fantasai]
- smfr: seems a bit magic, like a hack
- 01:03:14 [mattwoodrow]
- q+
- 01:03:22 [fantasai]
- smfr: seems like maybe it should be a CSS value, e.g. new keyword to 'visibility'?
- 01:03:26 [bkardell_]
- q+
- 01:03:34 [fantasai]
- chrishtr: if it was a CSS property, would be weird if UA overrides it
- 01:03:45 [fantasai]
- chrishtr: but made attriute so UA can remove automatically
- 01:03:53 [fantasai]
- smfr: Worried about circularity about activatable
- 01:03:57 [fantasai]
- smfr: e.g. user hits Cmd+F to start a find
- 01:04:10 [fantasai]
- smfr: I thin kyou have to bring in the subtree in order to search it
- 01:04:18 [fantasai]
- smfr: because have to check 'display: none'
- 01:04:27 [fantasai]
- chrishtr: Don't have to show on scren, but have to compute style
- 01:04:35 [fantasai]
- smfr: activatable has side-effect of removing the attriute?
- 01:04:44 [Rossen_]
- Zakim, close queue
- 01:04:44 [Zakim]
- ok, Rossen_, the speaker queue is closed
- 01:04:46 [fremy]
- q- because smfr just expressed my concern about find-in-page requiring style information
- 01:04:48 [fantasai]
- chrishtr: If you try find in page, UA will do the work necessary to compute the disply: none part of pipeline
- 01:04:50 [fremy]
- q-
- 01:04:55 [fantasai]
- chrishtr: if it matches query, would activate the subtree
- 01:05:05 [fantasai]
- smfr: Worried there are some things that are not specified that end up affecting the activation behavior
- 01:05:21 [fantasai]
- smfr: Spec says activation depens on UA behaviors, different browsers iwll have different activation policies if we don't standardize
- 01:05:33 [fantasai]
- chrishtr: explainer lists which actions cause activation
- 01:05:56 [fantasai]
- chrishtr: scrolling doesn't, JS scrollIntoView does, a11y access does
- 01:06:09 [fantasai]
- Rossen_: We have built up quite a queue
- 01:07:10 [xfq_]
- ack florian
- 01:07:12 [fantasai]
- florian: Maybe I missed something, one part I'm confused about
- 01:07:13 [fantasai]
- florian: what'
- 01:07:22 [dauwhe]
- dauwhe has joined #css
- 01:07:24 [fantasai]
- florian: what's the use case for invisible without activation?
- 01:07:35 [fantasai]
- florian: I think author will probably miss some important cases if it's not activatable
- 01:07:48 [fantasai]
- florian: Also, feels like it's something like a delayed or sync value for visibility
- 01:07:51 [tomalec]
- tomalec has joined #css
- 01:07:56 [fantasai]
- florian: you're allowed to delay, but once on screen please show
- 01:08:03 [fantasai]
- florian: most enefits when combined with contain,
- 01:08:10 [fantasai]
- florian: but conceptually could be separate
- 01:08:16 [fantasai]
- florian: you're allowed to load the assets later
- 01:08:25 [fantasai]
- florian: wouldn't need to override the value, just permission to do it later
- 01:08:32 [fantasai]
- florian: maybe that covers requiremtn for running scripts?
- 01:08:42 [fantasai]
- florian: rest feels like it could be in CSS somehwere along the lines that smfr was talking about
- 01:08:49 [fantasai]
- florian: would like to also know why have a version that's not activatable
- 01:09:03 [fantasai]
- 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 [fantasai]
- chrishtr: wouldn't be visibility: hidden because not performant, layout subtree still applies
- 01:09:44 [fantasai]
- myles: if you wnat to leave space for it, you can set visibility: hidden for it, will leave space
- 01:09:51 [fantasai]
- myles: if you do want the pop, can set display: none
- 01:10:04 [fantasai]
- florian: would combine visibility hidden with contain, to reduce jank
- 01:10:17 [fantasai]
- TabAtkins: will have jumping because the content hasn't loaded either
- 01:10:24 [fantasai]
- florian: but would use 'contain' and 'content-size' as well
- 01:10:28 [fantasai]
- florian: why needs an HTML attribute
- 01:10:36 [fantasai]
- TabAtkins: Doesn't allow us to not do layout
- 01:10:48 [fantasai]
- TabAtkins: which is a problem if wanting to load 10,000 nodes worht of content
- 01:11:09 [fantasai]
- florian: so would want 'visibibity: ...', whic would allow delaying
- 01:11:21 [Rossen_]
- q?
- 01:11:23 [fantasai]
- TabAtkins: recall reason chrishtr just said aobut having invisible but not activatable
- 01:11:32 [fantasai]
- TabAtkins: element is in state where it's waiting for stuff to load
- 01:11:42 [fantasai]
- TabAtkins: dont' want to allow activation until finished
- 01:11:45 [xfq_]
- ack Ame
- 01:11:45 [Rossen_]
- ack AmeliaBR
- 01:11:50 [fantasai]
- AmeliaBR: had same question
- 01:12:09 [fantasai]
- AmeliaBR: but final comment, might want to consider making activatable the default
- 01:12:28 [fantasai]
- AmeliaBR: authors might *think* they know when to activate, but haven't considered things through very well
- 01:12:47 [fantasai]
- AmeliaBR: so suggest to make default acticvatable, author has to explicitly request non-activatable
- 01:13:02 [fantasai]
- myles: might be problematic to have elements callback in unpredictable order?
- 01:13:09 [AmeliaBR]
- e.g. `inert` version for non-activatable
- 01:13:18 [fantasai]
- chrishtr: Can use this feature to automatically activate content which is below the fold, or not even actually visible
- 01:13:27 [fantasai]
- chrishtr: e.g. tabbed UI or content hidden behind a ? that can be opened by the user
- 01:13:31 [fantasai]
- chrishtr: e.g. details element
- 01:13:38 [fantasai]
- chrishtr: still want user to be able to find that content and navigate to it
- 01:13:40 [plh]
- plh has joined #css
- 01:13:42 [fantasai]
- chrishtr: currently, that's not really possible
- 01:13:53 [fantasai]
- chrishtr: e.g. yu have content in anotehr tab of the ui, or subwidget
- 01:14:01 [fantasai]
- chrishtr: nm, nother reason for activation
- 01:14:16 [xfq_]
- ack hey
- 01:14:16 [Rossen_]
- ack heycam
- 01:14:17 [fantasai]
- heycam: two things: one, want to echo what smfr said
- 01:14:28 [fantasai]
- heycam: I feel like behavior when subtree isn't rendered seems like CSS kind of feature
- 01:14:38 [fantasai]
- heycam: recognize that overriding the style value of some property doesn't feel great
- 01:14:51 [fantasai]
- heycam: but otherwise feels like some new 'display' value, like 'display: placeholder' which only generates frame and not contents
- 01:15:13 [fantasai]
- heycam: Some kind fo solution where it's somehow reflected in CSS property dispaly would be nice
- 01:15:20 [fantasai]
- heycam: 2nd point was about automatic avtivation behavior
- 01:15:30 [sanketj]
- sanketj has joined #css
- 01:15:38 [fantasai]
- heycam: have you consiered solution where you have strict callbacks for events for these types of activation behaviors?
- 01:15:50 [fantasai]
- heycam: so dev can choose to catch events and decide whether to flip activation
- 01:16:02 [fantasai]
- chrishtr: So suggesting that script shoudl be able to observe activation
- 01:16:08 [fantasai]
- heycam: wonderign if that's a design that you've considered
- 01:16:11 [fantasai]
- chrishtr: did consider that design
- 01:16:16 [fantasai]
- chrishtr: and prototyped in chromium
- 01:16:27 [fantasai]
- chrishtr: the event fo this, which we calle dactivate event, was in psec proposal
- 01:16:32 [fantasai]
- chrishtr: but makes sense and is convenient to add
- 01:16:39 [fantasai]
- chrishtr: technically can be implemented with mutation observer, but might be inconvenient
- 01:16:53 [fantasai]
- 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 [fantasai]
- heycam: and let the author change the value of that property
- 01:17:14 [myles]
- q+
- 01:17:20 [fantasai]
- chrishtr: so tell dev that "i would liek to activate this, please help me out"
- 01:17:24 [fantasai]
- chrishtr: problem is defautl behavior is not good
- 01:17:37 [fantasai]
- heycam: author specifying 'display: placeholder', on you to complete the solution
- 01:18:00 [fantasai]
- chrishtr: comments about flipping default activation, should make it easy as possible to adopt feature without unintentionally breaking accessibility
- 01:18:12 [fantasai]
- TabAtkins: copy-paste two-line activation script on every page that uses this feature
- 01:18:19 [fantasai]
- TabAtkins: that's not so great
- 01:18:47 [fantasai]
- 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 [fantasai]
- TabAtkins: back to display values, while I wouldn't fight too hard if we decided to add a display subproperty
- 01:19:28 [fantasai]
- TabAtkins: but doing non-typed things in 'display' itself is problematic because lose typing
- 01:19:32 [fantasai]
- TabAtkins: this is really bad
- 01:19:42 [fantasai]
- chrishtr: want UA to be able to activate for you
- 01:19:44 [Rossen_]
- q?
- 01:19:44 [astearns]
- s/non-/none-/
- 01:20:02 [fantasai]
- chrishtr: with recent testing with partners etc, does seem to be a use case for controlling things with a style sheet
- 01:20:12 [fantasai]
- chrishtr: sometimes convenient to do via CSS
- 01:20:20 [fremy]
- @chrishtr: added some notes over here: https://github.com/WICG/display-locking/issues/78
- 01:20:22 [xfq_]
- ack fantasai
- 01:20:23 [TabAtkins]
- 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 [florian]
- fantasai: same concern as amelia about making the activatable version the default
- 01:21:01 [florian]
- 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 [fantasai]
- chrishtr: Less magical means harder to cleanly spec, and some use cases are lost
- 01:21:13 [fantasai]
- myles: see readme and whatwg pull request, how do I comment?
- 01:21:25 [fantasai]
- chrishtr: I think the pull request ahs a correspondign issue in whatwg, good place to ask questions
- 01:21:54 [florian]
- s/amelia/AmeliaBR/
- 01:21:56 [fantasai]
- SimonSapin: similar to 'display: none', but different in that only contents are hidden
- 01:22:05 [fantasai]
- SimonSapin: how is this different from 'display: none' on children?
- 01:22:15 [fantasai]
- TabAtkins: Text content that are direct children can't be styled
- 01:22:23 [plh_]
- plh_ has joined #css
- 01:22:27 [fantasai]
- TabAtkins: but also 'display: none' implies a lot of things
- 01:22:34 [fantasai]
- Rossen_: animations, do they run on your subtree?
- 01:22:39 [fantasai]
- chrishtr: no
- 01:22:45 [fantasai]
- Rossen_: so that's also same as display: none
- 01:22:53 [fantasai]
- chrishtr: Subtree boxes do have CSS boxes
- 01:22:59 [flackr]
- flackr has joined #css
- 01:23:02 [fantasai]
- chrishtr: conceptually are laid out, just don't need to do work unless forced by script
- 01:23:09 [Rossen_]
- q?
- 01:23:16 [Rossen_]
- ack SimonSapin
- 01:23:19 [Rossen_]
- ack mattwoodrow
- 01:23:34 [fantasai]
- mattwoodrow: what si additional contstraint that we get over 'contain: all'
- 01:23:42 [fantasai]
- mattwoodrow: couldn't UA optimize by not rendering anyway?
- 01:23:46 [fantasai]
- chrishtr: it's an explicit API
- 01:23:53 [fantasai]
- chrishtr: rather than combo of CSS values
- 01:24:05 [fantasai]
- TabAtkins: off-screen 'contain', animations still run
- 01:24:16 [fantasai]
- TabAtkins: You will fall down accidentaly perf cliffs
- 01:24:22 [fantasai]
- mattwoodrow: so it will block animations?
- 01:24:25 [fantasai]
- TabAtkins: among other things, yes
- 01:24:28 [Rossen_]
- ack bkardell_
- 01:24:43 [fantasai]
- 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 [fantasai]
- chrishtr: yes
- 01:24:50 [fantasai]
- bkardell_: is there a precedent for doing that?
- 01:24:53 [fantasai]
- TabAtkins: there's one precedent
- 01:25:04 [fantasai]
- bkardell_: think there's been 1000 times that's been suggested, and push to not do that
- 01:25:08 [fantasai]
- TabAtkins: one precedent, details
- 01:25:22 [fantasai]
- TabAtkins: for similar reason to details, nice thing about directly manipulating attribute than a hidden state
- 01:25:30 [fantasai]
- TabAtkins: don't need to expose a new way to report actual value
- 01:25:40 [fantasai]
- TabAtkins: and don't need to expose to CSS using custom selector
- 01:25:44 [fantasai]
- TabAtkins: just use regular attribute selector
- 01:25:55 [fantasai]
- TabAtkins: as long as attribute value is easy enough to work with, and this one will be simple,
- 01:26:07 [fantasai]
- TabAtkins: there are usability benefits that come with this for free
- 01:26:14 [fantasai]
- cbiesinger: value attribute of input?
- 01:26:17 [fantasai]
- TabAtkins: those don't change
- 01:26:29 [fantasai]
- Rossen_: OK, thanks for introducing topic, chrishtr !
- 01:26:37 [fantasai]
- Rossen_: ppl wanting to participate, please do so at links provided
- 01:26:58 [fantasai]
- <br duration=25min>
- 01:27:57 [chrishtr]
- Issue for rendersubtree: https://github.com/whatwg/html/issues/4861
- 01:29:07 [futhark]
- futhark has joined #css
- 01:30:49 [plh]
- plh has joined #css
- 01:34:49 [duga]
- duga has joined #css
- 01:39:58 [ericc]
- ericc has joined #css
- 01:42:51 [jcraig_]
- jcraig_ has joined #css
- 01:54:17 [mattwoodrow]
- mattwoodrow has joined #css
- 01:57:32 [zcorpan]
- zcorpan has joined #css
- 01:57:43 [drousso]
- drousso has joined #css
- 01:58:17 [dauwhe]
- dauwhe has joined #css
- 02:00:25 [smfr]
- smfr has joined #css
- 02:02:49 [rakina]
- rakina has joined #css
- 02:02:51 [xfq_]
- xfq_ has joined #css
- 02:04:13 [dauwhe]
- dauwhe has joined #css
- 02:05:02 [xfq_]
- xfq_ has joined #css
- 02:05:29 [yigu]
- yigu has joined #css
- 02:05:30 [majidvp]
- present+
- 02:05:35 [fantasai]
- Topic: Highlight APIs
- 02:05:54 [xiaochengh]
- xiaochengh has joined #css
- 02:06:13 [fantasai]
- Note: break-out session on rendersubtree Wed at 2:30pm??
- 02:07:02 [sanketj]
- sanketj has joined #css
- 02:07:08 [yigu]
- present+
- 02:07:14 [tantek]
- present+
- 02:07:20 [futhark]
- futhark has joined #css
- 02:07:41 [futhark_]
- futhark_ has joined #css
- 02:07:42 [stantonm]
- stantonm has joined #css
- 02:07:44 [AmeliaBR]
- https://github.com/w3c/csswg-drafts/issues/4307
- 02:07:46 [fantasai]
- sanketj: Want to talk about new propoal about highligh API
- 02:07:54 [fantasai]
- sanketj: builds on top of existing css-pseudo-4 spec
- 02:08:04 [Rossen_]
- Rossen_ has joined #css
- 02:08:10 [fantasai]
- sanketj: existing spec allows styling native highlights of the browser: sleection, grammar-error, spelling-error
- 02:08:13 [fantasai]
- sanketj: can style how you want
- 02:08:20 [fantasai]
- sanketj: this is useful for editing apps
- 02:08:29 [fantasai]
- sanketj: implement own selection, spell-check, grammar error
- 02:08:37 [fantasai]
- sanketj: currently authors use spans
- 02:08:42 [fantasai]
- sanketj: some problems
- 02:08:52 [fantasai]
- sanketj: can be complicated, particularly if span across multiple subtrees
- 02:08:58 [fantasai]
- sanketj: then adding/removing creats perf problems
- 02:09:01 [fantasai]
- sanketj: wrt invalidation etc.
- 02:09:13 [fantasai]
- sanketj: users can add/remove highlight using dom ranges
- 02:09:13 [prushforth]
- prushforth has joined #css
- 02:09:20 [fantasai]
- sanketj: since can span multiple subtrees, easy to code
- 02:09:31 [fantasai]
- sanketj: invalidationis only paint invalidation, due to how highlight pseudo elements worok in css-pseudo-4
- 02:09:39 [florian]
- q?
- 02:09:44 [fantasai]
- sanketj: will overview first, then ask for feedback, also some issues
- 02:09:59 [fantasai]
- sanketj: iff ppl support concept, would like to move towards official spec
- 02:10:03 [HeWenli]
- HeWenli has joined #css
- 02:10:14 [fantasai]
- sanketj: two key pieces: one is cssom piece, one is a sleector
- 02:10:20 [fantasai]
- sanketj: adding two new types: highlightRangeGroup
- 02:10:28 [fantasai]
- sanketj: provides a group of ranges to be handled ogether
- 02:10:36 [fantasai]
- sanketj: similar to find-in-page, range per instance of term
- 02:10:41 [fantasai]
- sanketj: want to style at once
- 02:10:45 [fantasai]
- sanketj: so style all together
- 02:10:55 [fremy]
- fremy has joined #css
- 02:10:56 [fantasai]
- sanketj: highlightsMap takes a name key and group as a value
- 02:11:11 [fantasai]
- sanketj: introducing a global map per document, contaisn all user-defined highlights
- 02:11:33 [fantasai]
- 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 [fantasai]
- smfr: user meaning author?
- 02:11:41 [fantasai]
- sanketj: yes
- 02:11:50 [leaverou_]
- leaverou_ has joined #css
- 02:11:51 [fantasai]
- sanketj: two properties on highlightRange which are interesting
- 02:11:57 [fantasai]
- sanketj: .style property and .?
- 02:12:02 [bobbytung]
- bobbytung has joined #css
- 02:12:08 [fantasai]
- sanketj: connection from highlightsMap to group is important
- 02:12:13 [fantasai]
- sanketj: to make it stylable
- 02:12:19 [fantasai]
- sanketj: can only style stuff in the highlightMap
- 02:12:35 [fantasai]
- sanketj: to style introduces new pseudo, ::highlight(hlight-name)
- 02:12:43 [fantasai]
- sanketj: same properties supported as other highlight pseudo elements
- 02:12:50 [fantasai]
- sanketj: can also use .style property
- 02:12:57 [fantasai]
- sanketj: works just like cascade
- 02:12:57 [TabAtkins]
- q+
- 02:13:07 [astearns]
- zakim, open queue
- 02:13:07 [Zakim]
- ok, astearns, the speaker queue is open
- 02:13:08 [fantasai]
- sanketj: inline style wins
- 02:13:10 [TabAtkins]
- q+
- 02:13:23 [fantasai]
- sanketj: multiple highlight range covering same content
- 02:13:24 [Rossen_]
- q?
- 02:13:25 [florian]
- q+
- 02:13:26 [fantasai]
- sanketj: example
- 02:13:39 [fantasai]
- sanketj: Here we have two overlapping ranges, some text contained in both ranges
- 02:13:46 [fantasai]
- sanketj: each in its own hihlightrangegroup
- 02:13:52 [fantasai]
- sanketj: one is bg yellow, one is bg orange
- 02:13:59 [fantasai]
- HeWenli: what color is the overlap?
- 02:13:59 [futhark]
- futhark has joined #css
- 02:14:07 [fantasai]
- sanketj: what is the order?
- 02:14:12 [fantasai]
- sanketj: we use the timestamp of addign to the map
- 02:14:22 [fantasai]
- sanketj: if author wants to change that, they can set higher priority
- 02:14:26 [fantasai]
- sanketj: default priority is zero
- 02:14:34 [fantasai]
- sanketj: but can change .priority attribute on the rangegroup
- 02:14:40 [fantasai]
- sanketj: that is core pieces of the proposal
- 02:14:51 [fantasai]
- sanketj: want to pause and ask for feedback
- 02:14:57 [fantasai]
- Rossen_: already have a queue, so let's go through that
- 02:14:58 [emilio]
- q+
- 02:14:58 [dauwhe]
- q+
- 02:15:00 [Rossen_]
- ack TabAtkins
- 02:15:04 [cbiesinger]
- q+
- 02:15:08 [heycam]
- q+
- 02:15:10 [fantasai]
- TabAtkins: Question about the reasoning for having ragnegroup isntead of multigroup, but you explained with priorities
- 02:15:18 [fantasai]
- TabAtkins: wrt that, is priority 0+ or can be negative?
- 02:15:21 [fantasai]
- sanketj: can be negative
- 02:15:28 [fantasai]
- sanketj: want to discuss how priority relates to otehr pseudo elements
- 02:15:36 [fantasai]
- TabAtkins: any ties, then fall back to timestamp order?
- 02:15:56 [fantasai]
- TabAtkins: one more question, is intention that,if took that example calling foo again, would it ahve a newer timestamp
- 02:16:04 [fantasai]
- sanketj: no, timestamp is established when first added to the map
- 02:16:06 [TabAtkins]
- q-
- 02:16:18 [fantasai]
- plinss: timestamp order same as iteration order of the map?
- 02:16:20 [fantasai]
- sanketj: yes
- 02:16:28 [Rossen_]
- ack florian
- 02:16:35 [TabAtkins]
- Yeah, so that means even setting "foo" with a *different* highlight group would also not change the timestamp.
- 02:16:36 [fantasai]
- 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 [fantasai]
- florian: there already is a similar notion of ? for built-in highlights
- 02:16:54 [TabAtkins]
- (Which totally works for me; phrasing it more explicitly as the map iteration order would make me a little happier.)
- 02:16:57 [fantasai]
- 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 [fantasai]
- florian: so important not to re-invent a new solution for custom pseudo than for highlights
- 02:17:18 [fantasai]
- florian: and have the resolution be the same mechanism
- 02:17:27 [fantasai]
- sanketj: that's one of the issues I wanted to talk about
- 02:17:33 [Rossen_]
- q?
- 02:17:39 [Rossen_]
- ack emilio
- 02:17:51 [fantasai]
- emilio: few questions, first how does this interact with shadow DOM and general scoping?
- 02:17:58 [fantasai]
- emilio: CSS map is global, but rules that apply...
- 02:18:10 [fantasai]
- emilio: global ::highlight speudo that spans shadow tree and part of light DOm, what si the style of that?
- 02:18:17 [fantasai]
- sanketj: good question
- 02:18:29 [fantasai]
- sanketj: as currently specced, you have a range in ShadowDOM and some outside, all styled by global map
- 02:18:38 [fantasai]
- emilio: do normal css scoping rules apply?
- 02:18:40 [kurosawa]
- kurosawa has joined #css
- 02:18:56 [fantasai]
- emilio: global parent group, that will apply to non-shadow-dom group, but not shadow dom group
- 02:19:09 [fantasai]
- emilio: do you explain how different groups intersecting priority, have to decide
- 02:19:26 [fantasai]
- emilio: when you specify some proeprties in some range and not others, do you still apply properites of the other range?
- 02:19:40 [fantasai]
- sanketj: you have one group applying bg color and one applying color, overlapping portion gets both of those
- 02:19:43 [fantasai]
- emilio: how do you specify that
- 02:20:01 [fantasai]
- florian: we have this problem already, and it's specified in css-pseudo-4
- 02:20:15 [fantasai]
- florian: because we have same situation with selection/spelling-error/grammar-err
- 02:20:26 [fantasai]
- florian: whichever we resolve it, must be same for custom ones and normal ones
- 02:20:32 [Rossen_]
- q?
- 02:20:34 [chrishtr]
- q+
- 02:20:35 [fantasai]
- emilio: a bit annoy8ng but fine I guess
- 02:20:40 [TabAtkins]
- q+
- 02:20:46 [futhark_]
- futhark_ has joined #css
- 02:20:46 [Rossen_]
- ack dauwhe
- 02:20:54 [fantasai]
- dauwhe: higher-level question, Web has been struggling with identifying arbitrary ranges of text for a long time
- 02:21:00 [fantasai]
- dauwhe: stuff like Web annotations etc.
- 02:21:09 [fantasai]
- dauwhe: does this complement those efforts? is it independent of them? how does it relate?
- 02:21:22 [futhark]
- futhark has joined #css
- 02:21:33 [fantasai]
- 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 [fantasai]
- BoCupp: some places in DOM you can get a range, some cannot
- 02:21:55 [fantasai]
- BoCupp: this is just about applying style over a range
- 02:21:58 [plh_]
- plh_ has joined #css
- 02:22:08 [fantasai]
- 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 [fantasai]
- Rossen_: who has proposal?
- 02:22:16 [tantek]
- See Fragmentions for existing work on this too: https://indieweb.org/fragmention
- 02:22:20 [fantasai]
- hober: willd rop in minutes
- 02:22:24 [tantek]
- deployed on a bunch of sites
- 02:22:29 [fantasai]
- atotic: Any restriction on styles you can apply?
- 02:22:37 [Rossen_]
- q?
- 02:22:44 [fantasai]
- sanketj: set of properties youc an apply to highlight pseudo is same as for other highlight pseudos
- 02:22:50 [fantasai]
- sanketj: fairly limited
- 02:22:50 [AmeliaBR]
- Text fragment in URL proposal: https://github.com/WICG/ScrollToTextFragment
- 02:22:55 [florian]
- q?
- 02:22:55 [astearns]
- ack atotic
- 02:23:10 [Rossen_]
- ack cbiesinger
- 02:23:23 [fantasai]
- cbiesinger: Have you considered making priority part of highlight pseudo syntax rather than in JS?
- 02:23:50 [skk]
- q+
- 02:24:11 [florian]
- 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 [florian]
- fantasai: but for custom ones, we need to specificy where they fit
- 02:24:44 [florian]
- fantasai: this isn't something you want to redo everytime you select something, so it doesn't belong in the selector
- 02:25:03 [fantasai]
- heycam: I like the proposal, wanted to be able to do for awhile
- 02:25:05 [florian]
- fantasai: we could have a declarative mechanism in addition to JS, but selectors isn't it
- 02:25:10 [fantasai]
- heycam: two questions,
- 02:25:19 [fantasai]
- heycam: is there a need to style ranges that match multiple higlihgts at the same time
- 02:25:25 [emilio]
- q+
- 02:25:28 [fantasai]
- heycam: rather than just styling all of the individual highlight speduos
- 02:25:35 [fantasai]
- heycam: if you have a comma separated name of highlight speudos?
- 02:25:38 [fantasai]
- sanketj: trying tunderstand
- 02:25:46 [fantasai]
- sanketj: if you have multiple ranges, would you need to style them separately if the same content?
- 02:26:10 [fantasai]
- 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 [birtles]
- q+
- 02:26:18 [fantasai]
- sanketj: scnearious we're looking at, they are independent
- 02:26:26 [fantasai]
- sanketj: one implementing spellcheck, one impelmentign selection , etc.
- 02:26:32 [fantasai]
- sanketj: want both fo those styles to show up
- 02:26:52 [fantasai]
- heycam: two styles of text decorations are underlining, maybe you want to style slightly differently if two underlines
- 02:27:07 [fantasai]
- 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 [fantasai]
- BoCupp: when combination comes together, you want to pick a different color for that?
- 02:27:26 [fantasai]
- BoCupp: don't have a good scenario for that
- 02:27:33 [TabAtkins]
- ack TabAtkins
- 02:27:37 [r12a]
- r12a has joined #css
- 02:27:41 [fantasai]
- heycam: the built-in highlights, theyr'e not exposed in the JS API, would it be beneficial to expose those?
- 02:27:44 [Rossen_]
- q?
- 02:27:48 [fantasai]
- heycam: so you could set .style on them, too
- 02:27:53 [fantasai]
- sanketj: maybe
- 02:28:00 [Rossen_]
- ack heycam
- 02:28:04 [Rossen_]
- ack dbaron
- 02:28:06 [foolip]
- Are we set for a WPT/CSSWG meeting tomorrow at 9am?
- 02:28:10 [fantasai]
- dbaron: I'm also a big fan of this, we've talked about having a feature like this for awhile
- 02:28:13 [fantasai]
- dbaron: some questions
- 02:28:19 [fantasai]
- dbaron: a little concered about ergonomics of the JS api
- 02:28:29 [fantasai]
- 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 [fantasai]
- dbaron: say the set is called grammar-error
- 02:28:47 [bobbytung]
- bobbytung has joined #css
- 02:28:51 [fantasai]
- 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 [fantasai]
- sanketj: in scenario you're adding a grammar-error
- 02:29:08 [fantasai]
- sanketj: if you are creating range for grammar errors
- 02:29:16 [fantasai]
- sanketj: user types something, new grammar error appears
- 02:29:25 [fantasai]
- sanketj: grammarly made the group and has to keep track of the name
- 02:29:35 [fantasai]
- sanketj: they need to keep track of that info
- 02:29:46 [fantasai]
- iank_: mentioned someone makeing such a library would ...
- 02:29:56 [fantasai]
- dbaron: seems awkward to create all your global errors up front rather than initialize
- 02:30:15 [fantasai]
- 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 [Rossen_]
- q?
- 02:30:24 [fantasai]
- dbaron: it seems like this API should have that mode
- 02:30:31 [fantasai]
- dbaron: maybe some other way to structure API
- 02:30:49 [fantasai]
- dbaron: other thing is that I'm not sure, there's a bunch of new work in pseudos spec
- 02:30:52 [fantasai]
- dbaron: unsure if implemented
- 02:31:03 [dino]
- dino has joined #css
- 02:31:07 [fantasai]
- sanketj: wanted to check status of implementation itnerest of pseudo-spec
- 02:31:22 [fantasai]
- dbaron: if those are not implemented, I'd prioritize interests of getting this implemented over those
- 02:31:43 [fantasai]
- dbaron: having generic mechanism work reasonably is more important than having existing spec work
- 02:31:53 [fantasai]
- florian: the thing that makes them tricky to implement isn't which one exist, but how do they work?
- 02:31:59 [fantasai]
- florian: we ahve to figure that out for built-in and for custom
- 02:32:15 [fantasai]
- florian: if we implement custom things and drop built-in grammar and spelling-error standard, I don't mind
- 02:32:22 [fantasai]
- florian: but definign how the cascade work etc. is still needed
- 02:32:24 [futhark]
- q+
- 02:32:49 [fantasai]
- 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 [fantasai]
- chrishtr: wanted task your current thinking wrt performance of DOM mutations
- 02:33:31 [fantasai]
- sanketj: open issue on this
- 02:33:35 [Rossen_]
- ack chrishtr
- 02:33:37 [fantasai]
- sanketj: static range is one of the otpions thinking about
- 02:33:43 [fantasai]
- sanketj: might be useful
- 02:33:50 [atotic]
- q+
- 02:33:51 [fantasai]
- sanketj: also going to discuss this topic in editing TF later this week
- 02:33:57 [fantasai]
- sanketj: any other APIs to make this useful
- 02:34:07 [fantasai]
- sanketj: if you have static range, do you still need live ranges?
- 02:34:14 [fantasai]
- sanketj: I'm not sure
- 02:34:20 [Rossen_]
- Zakim, close queue
- 02:34:20 [Zakim]
- ok, Rossen_, the speaker queue is closed
- 02:34:25 [fantasai]
- sanketj: but would like to not just restrict it to ranges
- 02:34:44 [fantasai]
- chrishtr: Appreciate taking it seriously, ranges have been a significant perf problem
- 02:34:58 [fantasai]
- chrishtr: each API that changes DOM has to check that range is still correct, it's a problem
- 02:35:36 [fantasai]
- skk: We are develoipng viewr for weak eyesight
- 02:35:42 [drousso_]
- drousso_ has joined #css
- 02:35:42 [fantasai]
- skk: using text-to-speech using ? API
- 02:35:46 [emilio]
- q- (was going to ask the same about StaticRange and co.)
- 02:35:47 [fantasai]
- skk: is it possible to synchronize with speech?
- 02:35:56 [fantasai]
- sanketj: Currently, the accessibility concerns haven't been addressed
- 02:36:02 [emilio]
- q-
- 02:36:11 [fantasai]
- sanketj: true for all higlights, I think. Don't think have a way to say spelling error exists here
- 02:36:13 [florian]
- q?
- 02:36:14 [atotic]
- q- a10y question
- 02:36:15 [fantasai]
- sanketj: so still need to figure out
- 02:36:18 [Rossen_]
- ack skk
- 02:36:22 [Rossen_]
- ack birtles
- 02:36:31 [fantasai]
- birtles: priority field feels a bit like z-index
- 02:36:38 [fantasai]
- birtles: are there any alternatives like a relative ordering?
- 02:36:55 [fantasai]
- 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 [dbaron]
- floating point numbers!
- 02:37:13 [fantasai]
- sanketj: regardless of option, need to have some kind of recommendation of how priority would interact with application priorities
- 02:37:38 [TabAtkins]
- 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 [TabAtkins]
- fantasai: Probably you just set it to 0.
- 02:37:59 [TabAtkins]
- fantasai: That doesn't answer brian's question, which is multiple libs competing.
- 02:38:09 [TabAtkins]
- fantasai: so how do they coordinate rather than just assigning random numbers?
- 02:38:31 [fantasai]
- fantasai: cuz most of them will then try to assign max-int
- 02:39:07 [fantasai]
- BoCupp: I don't think you can coordinate things that are inherently uncoordinated themselves, there has to be an integrator
- 02:39:23 [fantasai]
- 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 [fantasai]
- BoCupp: extensions like grammarly, go app by app, look at how do I integrate with each app?
- 02:39:42 [fantasai]
- BoCupp: dont' do it blindly, do it after investigating the app
- 02:40:02 [fantasai]
- BoCupp: today have to figure out how to integrate spans into app without breaking, this would be much less invasive
- 02:40:04 [skk]
- s/?/SpeechSynthesis/
- 02:40:10 [fantasai]
- birtles: quick example of relative ordering
- 02:40:23 [fantasai]
- birtles: my app does highlights for a short time, so should be above grammarly's hiighlights
- 02:40:35 [fantasai]
- birtles: with priority approach, I might see that grammarly uses 1000, so I use 1001.
- 02:40:40 [romain]
- romain has joined #css
- 02:40:49 [fantasai]
- birtles: but then grammarly upgrades to 2000
- 02:41:05 [fantasai]
- birtles: maybe have an API that give me the highiest available priority, or priority above this particular name
- 02:41:08 [Rossen_]
- q?
- 02:41:17 [fantasai]
- sanketj: currently best could do is iterate map and get the highest priority
- 02:41:20 [heycam]
- maybe a priority name like "transient" would work?
- 02:41:36 [fantasai]
- johannes: Grammarly tries to integrate with other apps, in cases where it cannot, it usually just breaks the app
- 02:41:46 [fantasai]
- johannes: in email, can't integrate with it, your email is just gone
- 02:42:00 [fantasai]
- johannes: grammarly is trying to do this for awhile, but it's not working unless you have central registry
- 02:42:03 [astearns]
- s/in email/in gmail/
- 02:42:17 [fantasai]
- rune: Thinking about cascding and inheritance
- 02:42:39 [fantasai]
- rune: div::selection, implementations aren't using that style for span::selection in the div
- 02:42:47 [fantasai]
- rune: concerned there will be too much inheritance
- 02:42:55 [fantasai]
- BoCupp: A few questions about priority and inheritance
- 02:43:01 [fantasai]
- BoCupp: maybe we should go to the issues?
- 02:43:12 [fantasai]
- rune: just a general worry
- 02:43:25 [fantasai]
- rune: maybe we should fix that in implementatiosn before adding lots of new ones?
- 02:43:45 [astearns]
- ack atotic
- 02:43:49 [astearns]
- ack fantasai
- 02:43:49 [Zakim]
- fantasai, you wanted to reply
- 02:43:56 [astearns]
- ack futhark
- 02:44:21 [astearns]
- zakim, open queue
- 02:44:22 [Zakim]
- ok, astearns, the speaker queue is open
- 02:44:41 [fantasai]
- sanketj: priority property is currently just distinguishing stacking order for user-defiend highlights
- 02:44:50 [fantasai]
- sanketj: wnat to discuss how that relates to native highlights and combination of the two
- 02:45:04 [fantasai]
- 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 [fantasai]
- sanketj: if user wants to customize that, what is mechanism?
- 02:45:16 [fantasai]
- sanketj: some scenarious useful
- 02:45:25 [fantasai]
- sanketj: nwhen author is buildign some editing capability, but using native capabitily for something else
- 02:45:40 [fantasai]
- sanketj: might impelemtn find-on-page, but use UA's selection
- 02:45:50 [fantasai]
- sanketj: and want that to show up above their find-on-page
- 02:46:04 [fantasai]
- sanketj: in other cases might want to show over the UA selection
- 02:46:30 [fantasai]
- sanketj: solution I propose is that by default, author-defined goes below UA-defined
- 02:46:35 [fantasai]
- florian: I agree
- 02:46:38 [Rossen_]
- q?
- 02:46:44 [Rossen_]
- zakim, open queue
- 02:46:44 [Zakim]
- ok, Rossen_, the speaker queue is open
- 02:47:05 [fantasai]
- BoCupp: Is there a need to interleave with the UA highlights?
- 02:47:13 [fantasai]
- BoCupp: having phase above or below that is probably easiest
- 02:47:38 [florian]
- fantasai: the painting rules are already interleaved
- 02:47:54 [florian]
- fantasai: background is painted before, text decorations are on top
- 02:48:11 [florian]
- fantasai: it's inevitable that things interleave
- 02:48:31 [fantasai]
- sanketj: spelling-error and grammar-error, is one group
- 02:48:32 [florian]
- fantasai: but if you've got mulitple of them trying to set the same property, the one needs to win
- 02:48:39 [fantasai]
- sanketj: selection, find-on-page different
- 02:48:48 [fantasai]
- sanketj: let's say user wanted to impelemnt their own spell-check and use their own styles
- 02:48:59 [fantasai]
- sanketj: but wanted to use browsers' grammar-error, is there a way to maintain that stacking order?
- 02:49:30 [fantasai]
- sanketj: because selection and spelling error are different styles, then would get both
- 02:49:31 [florian]
- q+
- 02:50:02 [florian]
- 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 [florian]
- 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 [florian]
- fantasai: the author could possibly also replace the range objects
- 02:51:07 [florian]
- fantasai: so the author could take over built in ones, instead of duplicating
- 02:51:19 [heycam]
- +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]
- 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 [astearns]
- ack florian
- 02:52:01 [fantasai]
- florian: need to be careful about priorities
- 02:52:05 [fantasai]
- florian: and thining about them
- 02:52:10 [fantasai]
- florian: it's not quite about in front / behind
- 02:52:18 [nmccully]
- nmccully has joined #css
- 02:52:24 [fantasai]
- florian: because even if you have lowest priority, your foreground will be over the background of the ghighest priority
- 02:52:33 [fantasai]
- florian: some degree of interleaving is inevitable
- 02:52:38 [fantasai]
- florian: if there is a priority that doesn't allow ?
- 02:52:46 [fantasai]
- florian: not sure bannign it would sovle the impelementation problem
- 02:52:59 [fantasai]
- florian: backgrounds are behind, shadows, then text
- 02:53:24 [fantasai]
- BoCupp: ....
- 02:53:39 [fantasai]
- BoCupp: we reasoned, does anyone need that, what are schenarios? would you replace grammar/spelling errors?
- 02:53:46 [fantasai]
- BoCupp: fishing for scenarious taht would reuqire a more capable API
- 02:53:53 [fantasai]
- Rossen_: one procedural recommendation, since running low on time
- 02:54:00 [fantasai]
- Rossen_: hearing quite a bit of support and interest from CSSWG
- 02:54:05 [fantasai]
- Rossen_: something that has been needed for quite some time
- 02:54:16 [fantasai]
- Rossen_: I suggest that we transition into figuring out where this work is going to go
- 02:54:26 [fantasai]
- Rossen_: and start transfering text into an actual spec, and star tracking issues in our GH tracker
- 02:54:39 [fantasai]
- Rossen_: if going back to explainer, where would work need to be split out?
- 02:54:46 [fantasai]
- Rossen_: there's some selectors and then some actual speudo explanation
- 02:55:16 [dbaron]
- fantasai: I'd say either its own spec or the pseudo elements module.
- 02:55:17 [fantasai]
- fantasai: Would suggest ether its own spec, or integrate into css-pseudo
- 02:55:35 [fantasai]
- florian: Starting as own thing, amybe merge into pseudo maybe split it
- 02:55:40 [fantasai]
- sanketj: also question on name
- 02:56:01 [fantasai]
- sanketj: earlier proposal was range-decoration?
- 02:56:09 [astearns]
- +1 to OM concerns mixed in the feature, instead of in a separate spec
- 02:56:10 [fantasai]
- fantasai: css-highlight-api
- 02:56:26 [tantek]
- +1 fantasai
- 02:56:35 [fantasai]
- Rossen_: Any objections to adopt as ED, with sanketj as editor?
- 02:56:47 [fantasai]
- dbaron: adopt as new ED or integrate into css-pseudo-4?
- 02:56:53 [fantasai]
- dbaron: I'd prefer integrating into css-pseudo-4
- 02:57:04 [fantasai]
- dbaron: would prefer the closely related things be in the same document
- 02:57:39 [fantasai]
- iank_: that said, might be easier to iterate on API if separate
- 02:57:52 [fantasai]
- florian: can revisit during FPWD time
- 02:58:23 [fantasai]
- Rossen_: so maybe start as separate spec and integrate later?
- 02:58:35 [fantasai]
- TabAtkins: an issue into css-pseudo-4 pointing at draft to be integrated later
- 02:58:44 [fantasai]
- Rossen_: any co-editor?
- 02:58:47 [fantasai]
- florian: propose myself
- 02:58:52 [fantasai]
- sanketj: ok!
- 02:58:56 [fantasai]
- hober: me too
- 02:59:18 [futhark]
- futhark has joined #css
- 02:59:32 [fantasai]
- 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]
- romain has joined #css
- 03:18:57 [bobbytung]
- bobbytung has joined #css
- 03:23:22 [dauwhe]
- dauwhe has joined #css
- 03:27:18 [duga]
- duga has joined #css
- 03:40:03 [zcorpan]
- zcorpan has joined #css
- 03:48:22 [futhark]
- futhark has joined #css
- 03:50:29 [futhark_]
- futhark_ has joined #css
- 03:50:48 [futhark]
- futhark has joined #css
- 03:57:27 [eae]
- <br type="lunch">
- 03:58:42 [ericc]
- ericc has joined #css
- 04:00:59 [kurosawa]
- kurosawa has joined #css
- 04:01:07 [astearns]
- starting back up soon
- 04:04:19 [myles]
- myles has joined #css
- 04:09:44 [bobbytung]
- bobbytung has joined #css
- 04:11:52 [ericc]
- ericc has joined #css
- 04:12:17 [myles]
- myles has joined #css
- 04:12:38 [myles]
- ScribeNick: myles
- 04:12:40 [fantasai]
- Topic: Scroll Anchoring
- 04:13:18 [smfr]
- smfr has joined #css
- 04:15:05 [myles]
- emilio: Is this microphone on?
- 04:15:43 [astearns]
- github: https://github.com/w3c/csswg-drafts/issues/4239
- 04:15:45 [drousso]
- drousso has joined #css
- 04:15:48 [rakina]
- rakina has joined #css
- 04:16:00 [myles]
- 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_]
- drousso_ has joined #css
- 04:16:57 [myles]
- 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 [myles]
- 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 [myles]
- 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 [myles]
- emilio: this is mainly to prevent bad scroll events. I'm just interested in feedback from implementors
- 04:18:35 [nmccully]
- nmccully has joined #css
- 04:18:35 [chris]
- chris has joined #css
- 04:18:42 [stantonm]
- stantonm has joined #css
- 04:18:48 [myles]
- <missed>: Chrome implementors are in agreement
- 04:18:59 [myles]
- emilio: Ian Scopes is no longer working on this
- 04:19:03 [myles]
- eae: No one is working on it now
- 04:19:17 [Rossen_]
- Rossen_ has joined #css
- 04:19:20 [myles]
- chrishtr: What about it are you itnerested in?
- 04:19:20 [heycam]
- s/Scopes/Skobes/
- 04:19:27 [Rossen_TPAC]
- Rossen_TPAC has joined #css
- 04:19:29 [dauwhe]
- dauwhe has joined #css
- 04:19:37 [TabAtkins]
- s/Ian Skobes/Steve Kobes/
- 04:19:42 [heycam]
- s/Ian Skobes/Steve Kobes/
- 04:20:22 [myles]
- 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 [myles]
- emilio: Chrome fixed this by, when changing from in-flow to out-of-flow, don't do the scroll adjustment.
- 04:20:45 [myles]
- eae: Yes, that's how it works today.
- 04:21:05 [myles]
- 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 [myles]
- 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 [myles]
- 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 [chris]
- present+
- 04:22:38 [myles]
- 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 [myles]
- emilio: Yes.
- 04:22:52 [myles]
- 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 [myles]
- chrishtr: Is the code doing this loop synchronously?
- 04:23:20 [myles]
- emilio: I know pages in Chrome that burn CPU because the scroll offset keeps changing
- 04:23:28 [myles]
- emilio: It changes back and forth, and triggers two scroll events
- 04:23:29 [r12a]
- r12a has joined #css
- 04:23:57 [myles]
- 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 [myles]
- atotic: If you have feedbakc, that would be great, because we're using a heuristic now
- 04:24:36 [myles]
- 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 [smfr]
- q+
- 04:24:48 [skk]
- skk has joined #css
- 04:25:34 [myles]
- 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 [myles]
- chrishtr: Are you proposing that forced layouts don't do this?
- 04:25:59 [astearns]
- ack smfr
- 04:26:00 [myles]
- emilio: I'm proposing that Scroll offsets don't do anchoring
- 04:26:13 [myles]
- smfr: Is the time that scroll anchoring is applied defined in terms of HTML5 event loop.
- 04:26:22 [fremy]
- fremy has joined #css
- 04:26:44 [myles]
- 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 [myles]
- emilio: Scroll anchoring runs after updating styles but before updating layout.
- 04:27:06 [myles]
- emilio: In order to have hte tree in the state you want it to, you have to run it every layout
- 04:27:15 [myles]
- smfr: Scrolls triggered by scroll anchoring fire scroll events?
- 04:27:16 [myles]
- emilio: yes
- 04:27:19 [myles]
- smfr: that's necessary?
- 04:27:20 [myles]
- smfr: yes
- 04:27:25 [myles]
- emilio: yes
- 04:27:49 [myles]
- chrishtr: What you're proposing is worth investigating. Chrome can invest engineers to page back in our history here.
- 04:28:03 [myles]
- eae: If you're impelmenting now, we shoudl revesolve this
- 04:28:16 [myles]
- astearns: Do we need a resolution? Should we change the spec?
- 04:28:34 [myles]
- emilio: These heuristics are still implemented in Chrome and Firefox. I want to remove them in Firefox.
- 04:28:37 [myles]
- emilio: I don't see any reason to remove them now.
- 04:28:43 [myles]
- chrishtr: We need more investigation.
- 04:28:58 [smfr]
- q+
- 04:29:19 [myles]
- 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 [myles]
- 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 [myles]
- emilio: That may be another approach. And then we can move it to the "update the rendering steps" in HTML5
- 04:30:07 [myles]
- 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 [myles]
- 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 [myles]
- emilio: Yeah, but you can set a flag....
- 04:31:34 [myles]
- atotic: We'd have to pass the flag around....
- 04:31:38 [myles]
- emilio: Yeah, it's possible
- 04:32:53 [romain]
- romain has joined #css
- 04:33:41 [mattwoodrow]
- mattwoodrow has joined #css
- 04:33:56 [myles]
- 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 [myles]
- 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 [myles]
- 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]
- zcorpan has joined #css
- 04:34:46 [kurosawa_]
- kurosawa_ has joined #css
- 04:34:49 [myles]
- 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 [myles]
- iank_: there is precidence. Text autosizing behavior is automatic.
- 04:35:59 [kevers]
- kevers has joined #css
- 04:36:17 [myles]
- astearns: Can we move on?
- 04:36:41 [myles]
- Topic: Can an anchor node be an inline block
- 04:36:42 [astearns]
- github: https://github.com/w3c/csswg-drafts/issues/4247
- 04:37:09 [skk]
- skk has joined #css
- 04:37:34 [myles]
- 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 [myles]
- 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]
- tantek has joined #css
- 04:37:55 [myles]
- emilio: I'm happy to help out to refine the spec.
- 04:38:38 [myles]
- 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 <missed>
- 04:38:41 [myles]
- emilio: This is what Blink does.
- 04:38:43 [myles]
- astearns: Any concerns?
- 04:38:53 [myles]
- iank_: There's some discussion on the github issue?
- 04:39:27 [myles]
- 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 [myles]
- emilio: So right now, the definition is accurate. That term from the other spec sounds better.
- 04:40:05 [myles]
- emilio: Proposal: An anchor node can be every box except a non-atomic inline box
- 04:41:00 [myles]
- RESOLVED: An anchor node only can be every box except a non-atomic inline box
- 04:41:28 [myles]
- RESOLVED: An anchor node can be any box except non-atomic inline boxes
- 04:41:54 [myles]
- Topic: JLReq met last week
- 04:42:08 [myles]
- astearns: There's going to be a breakout session on Wednesday to talk about JLReq updates
- 04:43:13 [duga]
- duga has joined #css
- 04:43:15 [myles]
- 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 [myles]
- TabAtkins: Majid pointed out that Waterloo is available for a summer meeting (instead of New York).
- 04:44:34 [myles]
- Rossen: Near Toronto
- 04:44:34 [myles]
- TabAtkins: 1 hour drive
- 04:44:43 [myles]
- Rossen: Thanks for the offer.
- 04:44:54 [myles]
- Topic: Transforms
- 04:45:12 [myles]
- 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 [myles]
- astearns: Projection?
- 04:45:15 [myles]
- smfr: yes
- 04:47:32 [futhark]
- futhark has joined #css
- 04:52:30 [mattwoodrow]
- mattwoodrow has joined #css
- 04:53:00 [emilio]
- ScribeNick: emilio
- 04:53:10 [myles]
- https://github.com/w3c/csswg-drafts/issues/4116
- 04:53:18 [myles]
- GitHub: https://github.com/w3c/csswg-drafts/issues/4116
- 04:53:26 [emilio]
- Topic: Images with layout information
- 04:53:27 [bobbytung]
- bobbytung has joined #css
- 04:53:31 [emilio]
- GitHub: https://github.com/w3c/csswg-drafts/issues/4116
- 04:54:07 [emilio]
- 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 [emilio]
- myles: there are images that need to be positioned similarly to text
- 04:54:49 [emilio]
- 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 [emilio]
- myles: so the formula won't align with the text
- 04:55:03 [fantasai]
- 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 [fantasai]
- we didn't spec it out because it wasn't a high priority
- 04:55:21 [emilio]
- 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 [fantasai]
- but it's certainly possible to do
- 04:55:45 [emilio]
- myles: similarly with the apple pay logo and similar, because of the descender of the y
- 04:56:20 [plh]
- plh has joined #css
- 04:56:24 [emilio]
- 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 [emilio]
- myles: it's a triangle, so if you mathematically center it horizontally it would look wrong
- 04:57:04 [emilio]
- myles: so the layout moves it slightly horizontally
- 04:57:41 [emilio]
- myles: same for kanbun, which are cjk chars which are not in unicode and people use them using images
- 04:57:59 [emilio]
- myles: since they're images they behave wrong
- 04:58:18 [emilio]
- myles: three of the examples show the need for horizontal baselines, the other is a vertical baseline
- 04:58:19 [fantasai]
- s/kanbun/kaiji
- 04:58:20 [Rossen_TPAC]
- Rossen_TPAC has joined #css
- 04:58:27 [fantasai]
- s/kaiji/gaiji/
- 04:58:38 [tantek]
- There's another fairly common use-case of this, images used for decorative first/initial letters
- 04:58:47 [emilio]
- 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 [emilio]
- myles: another option is to add a css properties
- 04:59:15 [emilio]
- myles: mac has these system assets that contain this information
- 04:59:35 [futhark]
- futhark has joined #css
- 04:59:39 [nmccully]
- unencoded glyphs = gaiji; Chinese poetry typeset for Japanese audiences = kanbun
- 04:59:43 [emilio]
- 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 [emilio]
- myles: so at least we could use it for system assets
- 05:00:16 [emilio]
- 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 [tantek]
- q+
- 05:00:37 [emilio]
- TabAtkins: chrome is fine with that, we have taken a look to the image formats to provide x-height and baseline
- 05:00:43 [smfr]
- ack
- 05:01:20 [stantonm]
- q+
- 05:01:23 [tantek]
- 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 [emilio]
- nmccully: a single baseline is fine, but multiple baselines may be needed for multiple writing systems
- 05:01:32 [heycam]
- q=
- 05:01:32 [astearns]
- ack tantek
- 05:01:33 [emilio]
- ack tantek
- 05:01:35 [Zakim]
- 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 [heycam]
- q+
- 05:01:45 [smfr]
- q-
- 05:01:58 [Rossen_]
- Rossen_ has joined #css
- 05:02:06 [Rossen__]
- Rossen__ has joined #css
- 05:02:09 [emilio]
- 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 [emilio]
- s/alone/and such
- 05:02:57 [emilio]
- tantek: we have a similar feature / challenge in css-ui with the cursor property
- 05:03:19 [krit]
- q+
- 05:03:20 [emilio]
- tantek: cursor has a hotspot. May be something that we could reuse somehow
- 05:03:58 [emilio]
- TabAtkins: cursors are usually set once, but in this case you need the same information every time you set the image
- 05:03:59 [chrishtr]
- q+
- 05:04:18 [astearns]
- ack stantonm
- 05:04:29 [kevers]
- kevers has joined #css
- 05:04:30 [emilio]
- 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 [emilio]
- TabAtkins: both is fine
- 05:05:24 [emilio]
- 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 [emilio]
- myles: can you link me to it?
- 05:06:34 [emilio]
- 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 [fremy]
- @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 [emilio]
- stantonm: another thing we wanted to see if we can treat images more like a bitmap, to invert in dark mode
- 05:07:10 [emilio]
- myles: mix-blend-mode?
- 05:07:20 [emilio]
- stantonm: haven't looked into impl that much
- 05:07:24 [HeWenli]
- HeWenli has joined #css
- 05:07:39 [emilio]
- heycam: I wanted to express general agreement on the problem being worth solving
- 05:07:52 [emilio]
- heycam: have run into this with svg
- 05:07:55 [stantonm]
- creating @font-face from an CJK image (gaiji) - https://github.com/w3c/csswg-drafts/issues/4013
- 05:08:12 [astearns]
- q?
- 05:08:15 [astearns]
- ack heycam
- 05:08:22 [emilio]
- 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 [emilio]
- heycam: where we start reacting to image metadata and breaking pages
- 05:08:44 [emilio]
- myles: we still need some css integrations to define how these are read or what not
- 05:09:02 [tantek]
- 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 [astearns]
- ack krit
- 05:09:09 [emilio]
- heycam: using vertical writing mode to getting centering and alignment seems a bit odd
- 05:09:23 [emilio]
- krit: file formats seems nice, but there are formats which we may not be able to modify
- 05:09:45 [emilio]
- krit: so we may want a css-only solution as well
- 05:09:48 [skk]
- skk has joined #css
- 05:10:01 [astearns]
- ack chrishtr
- 05:10:06 [emilio]
- chrishtr: what formats have this already, any examples?
- 05:10:09 [emilio]
- myles: nope, 0
- 05:10:26 [emilio]
- myles: the ui image in iOS apps have this, but it's not a file format
- 05:10:39 [bkardell_]
- q+
- 05:10:48 [emilio]
- chrishtr: so in an iOS app you create an image and set this and use it in your layout?
- 05:10:49 [emilio]
- myles: yes
- 05:11:02 [emilio]
- chrishtr: I'm curious about how feasible is it to modify the formats
- 05:11:21 [emilio]
- myles: people think it's a good idea so I'll try and come back if fail
- 05:11:54 [fantasai]
- myles, I think we need to make sure whatever we do can handle multiple baselines
- 05:12:00 [emilio]
- 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 [fantasai]
- e.g. alphabetic vs ideographic vs central vs mathematical
- 05:12:19 [emilio]
- chrishtr: you're proposing a new format?
- 05:13:03 [nmccully]
- 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 [emilio]
- 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 [emilio]
- fremy: so we may want that instead
- 05:13:42 [astearns]
- ack bkardell_
- 05:13:48 [chrishtr]
- q+
- 05:13:57 [emilio]
- fremy: as changing formats is going to be a pain
- 05:14:16 [emilio]
- myles: only interested in jpeg and png really, and those do have optional tags
- 05:14:33 [emilio]
- myles: but yeah, first thing to try is changing those, second the wrapper format, third css-only solution
- 05:14:34 [myles]
- optional tags inside their existing formats
- 05:15:13 [emilio]
- 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 [emilio]
- bkardell_: so it seems like we'd get into a situation where there are multiple sources of truth
- 05:15:50 [emilio]
- myles: image-orientation was like that until not long ago
- 05:15:56 [emilio]
- bkardell_: right, also aspect-ratio and such
- 05:16:10 [emilio]
- bkardell_: do you think a property of that sort would be valuable?
- 05:16:37 [astearns]
- ack chrishtr
- 05:16:46 [emilio]
- 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 <length>
- 05:16:59 [emilio]
- chrishtr: we discussed something similar about mathml not long ago right?
- 05:17:31 [emilio]
- myles: I think the mathml proposal was to identify the baseline out of specific elements inside the formula
- 05:17:44 [emilio]
- myles: but that doesn't work for non-formula use-cases like the ones I've provided
- 05:17:47 [emilio]
- chrishtr: that makes sense
- 05:17:56 [emilio]
- cbiesinger: could potentially work for svg
- 05:18:02 [emilio]
- myles: yeah, true
- 05:18:49 [emilio]
- chrishtr: drott mentioned that fonts can be the wrapper format
- 05:18:56 [emilio]
- chrishtr: that may be a lot of overhead
- 05:19:13 [emilio]
- myles: I think making icon fonts is an anti-pattern
- 05:19:29 [emilio]
- drott: there are some ergonomic issues with them
- 05:19:51 [emilio]
- 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 [emilio]
- 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 [emilio]
- Topic: multicol
- 05:20:47 [emilio]
- Github: https://github.com/w3c/csswg-drafts/issues/4036
- 05:21:33 [emilio]
- rachelandrew: this is an edit made in #3224 (since the last wd)
- 05:21:50 [emilio]
- rachelandrew: dbaron opened this, issue has a bunch of discussion
- 05:22:25 [futhark]
- futhark has joined #css
- 05:22:29 [emilio]
- 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 [emilio]
- rachelandrew: so we need to decide
- 05:23:22 [emilio]
- 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 [emilio]
- iank_: can you describe what happens right now?
- 05:24:16 [emilio]
- 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_]
- stantonm_ has joined #css
- 05:24:37 [emilio]
- rachelandrew: Chrome is doing the new behavior, which is actually the old one that was commented out on the spec
- 05:24:43 [emilio]
- rachelandrew: dbaron has a nice table on that issue
- 05:24:52 [emilio]
- rachelandrew: the second table
- 05:25:44 [emilio]
- rachelandrew: I think if we print from the browser the behavior should be the same
- 05:26:15 [emilio]
- 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]
- rego has joined #css
- 05:26:46 [emilio]
- dbaron: I think at least the last fragment in paginated mode should behave the same as the only fragment
- 05:27:16 [emilio]
- dbaron: I suggested a fix, but florian didn't agree because it was not what print formatters do
- 05:27:27 [emilio]
- dbaron: so I suggested going in the other direction
- 05:27:51 [emilio]
- dbaron: I think mstensho was fine with this if we have a clearer definition of what each combination does
- 05:28:02 [emilio]
- dbaron: it'd take me a bit
- 05:28:21 [emilio]
- astearns: so reverting would get us to a better place to improve upon right?
- 05:28:36 [emilio]
- dbaron: I think so if WebKit are fine with changing this
- 05:28:48 [emilio]
- iank_: reverting this leaves less more stuff unspecified right?
- 05:29:07 [emilio]
- rachelandrew: yeah, that's right, but we shouldn't publish something that we might revert
- 05:29:20 [emilio]
- iank_: can we mark it at risk or such?
- 05:29:47 [emilio]
- 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]
- zcorpan has joined #css
- 05:30:22 [emilio]
- iank_: that seems fine for a WD
- 05:30:34 [emilio]
- astearns: but if we know it's flat wrong it may not be useful
- 05:30:47 [emilio]
- iank_: but is it wrong for sure?
- 05:30:54 [emilio]
- dbaron: I think the inconsistency is pretty wrong
- 05:30:59 [dlibby]
- dlibby has joined #css
- 05:31:02 [emilio]
- iank_: mstensho didn't agree looks like
- 05:31:13 [emilio]
- dbaron: I don't think he disagreed
- 05:32:24 [emilio]
- 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 [emilio]
- dbaron: that combination is already not-defined when you're printing
- 05:33:15 [emilio]
- dbaron: so there's an existing spec gap that needs to be filled
- 05:33:49 [emilio]
- dbaron: but I don't think it's too hard since there is existing behavior (though we may not like it)
- 05:34:25 [emilio]
- 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 [emilio]
- florian: so we should revert to find a solution that doesn't break any of both
- 05:34:47 [karl]
- karl has joined #css
- 05:35:00 [emilio]
- astearns: iank_ had objections?
- 05:35:02 [emilio]
- iank_: I think reverting is fine
- 05:35:19 [emilio]
- astearns: proposed resolution is reverting the change and leave issues in the draft to define this
- 05:35:22 [emilio]
- rachelandrew: yeah
- 05:35:33 [emilio]
- iank_: may be useful to link to the reverted change
- 05:36:05 [dbaron]
- It looks like what Gecko does for the auto height is just to assume one column.
- 05:36:16 [emilio]
- RESOLVED: revert the change made in #3224, and add spec issues to define this
- 05:36:26 [emilio]
- RESOLVED: republish the wd of css-multicol
- 05:36:52 [emilio]
- Topic: transforms
- 05:37:17 [heycam]
- ScribeNick: heycam
- 05:37:36 [xfq]
- xfq has joined #css
- 05:37:42 [heycam]
- smfr: thinking about 3d transforms
- 05:37:53 [heycam]
- ... I want to make sure any changes to the spec don't have unreasonable web compat impacts
- 05:38:02 [heycam]
- ... so I wanted to understand how people use 3d transforms on the web, I did a poll
- 05:38:11 [heycam]
- ... analysed these sites that are using real 3d
- 05:38:18 [heycam]
- ... not as many sites as I expected
- 05:38:39 [heycam]
- smfr: I've noted the structured
- 05:38:46 [heycam]
- ... the set of properties on the node that's doing 3d stuff
- 05:38:53 [heycam]
- ... properties on the node, the child, the grandchild, etc.
- 05:39:02 [heycam]
- ... generally web sites are putting perspective on the root of the 3d stuff
- 05:39:10 [heycam]
- ... not preserve-3d on the root, mostly just perspective
- 05:39:18 [heycam]
- ... then they put preserve-3d in the child, sometimes with transform
- 05:39:26 [heycam]
- ... sometimes they have a noop element. not no transform related styles on it
- 05:39:47 [heycam]
- ... sometimes they'll have some intermediate elements, e.g. 3 noop divs, then transform/preserve-3d under that
- 05:40:03 [heycam]
- ... sometimes they put just the transform on the leaf nodes. sometimes preserve-3d and transform on the leaf nodes
- 05:40:16 [heycam]
- ... 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 [heycam]
- ... Gecko treats an element in the ancestor chain that doesn't have transform related prtoperties and something taht triggers flattening
- 05:40:43 [heycam]
- ... it's causing problems on a few sites
- 05:40:53 [heycam]
- florian: are there sties that rely on this happening>
- 05:40:55 [heycam]
- not see any
- 05:41:03 [heycam]
- s/not/smfr: did not/
- 05:41:18 [heycam]
- smfr: people combime overflow-scroll and 3d for parallax effects
- 05:41:26 [heycam]
- ... might have to make some exceptions for overflow-scroll
- 05:41:40 [heycam]
- ... this is how people are using 3d transforms.. most important thing is that noop divs should not cause flattening
- 05:41:59 [heycam]
- smfr: next I want to build up the 3d model from scratch
- 05:42:05 [heycam]
- ... I'ver realised there are some porblems with the current ED
- 05:42:18 [heycam]
- ... we'll end up with a combination of thwat's in the current ED and the preivous WD
- 05:42:45 [heycam]
- [shows transforms-buildup.html]
- 05:42:58 [heycam]
- ... let's started with a simple case. this is a 3d transformed element, in isolation
- 05:43:03 [heycam]
- ... nothing else that is 3d-ish in this content
- 05:43:12 [heycam]
- ... the best behavior for this is that the 3d transform here acts as a painting effect
- 05:43:22 [heycam]
- ... it'll be squished by the transformed, but painted in the regular z-order
- 05:43:28 [heycam]
- ... no intersection with its container or anything else
- 05:43:38 [heycam]
- ... next question is what happens if there are 2 siblings that are transforms
- 05:43:50 [heycam]
- ... think the right answer is that they should act as a painting effect, they should not intersect
- 05:44:02 [heycam]
- ... I think that's the Gecko model, and maybe Blink, but not WebKit. willing to change WebKit here
- 05:44:15 [heycam]
- chrishtr: nothing has the preserve3d here
- 05:44:19 [heycam]
- smfr: right, we're still in "painting" transforms
- 05:44:28 [heycam]
- astearns: is this something the current ED is sayin something differetn about?
- 05:44:39 [heycam]
- smfr: the current ED is written with the notion that you're always in a 3d rendering context, and doing flattening
- 05:44:45 [heycam]
- ... it uses the analgoy of CSS stacking ocntexts and flatening
- 05:44:58 [heycam]
- ... I think a better model is that you only establish a 3d rendering context when you use the magic properties
- 05:45:02 [heycam]
- ... otherwise you paint in the regular z-order
- 05:45:29 [heycam]
- ... now let's change the eexample to put perspective on the container
- 05:45:55 [heycam]
- ... originally the notion was persecptve is we're applying another transform for descendants, a common viewport/perspective
- 05:46:08 [heycam]
- ... looking at the way content is using perspective, think it makes sense to establish a 3d rendering context
- 05:46:16 [heycam]
- ... the 2 siblings would start intersecting with each other
- 05:46:26 [heycam]
- chrishtr: not a behavior any browser has now?
- 05:46:43 [heycam]
- mattwoodrow: WebKit will intersect them (though even without perspective right now)
- 05:46:59 [heycam]
- chrishtr: the perspective proposal is unrelated to current intersecting behavior of WebKIt?
- 05:47:00 [heycam]
- smfr: yes
- 05:47:13 [heycam]
- ... when an author says perspective, they're opting in to 3d stuff, and expecting descendants to depth sort
- 05:47:28 [heycam]
- chrishtr: and currently, in Gecko and Chrome, they don't intersect but the perspectie does adjust teh transform
- 05:47:29 [heycam]
- mattwoodrow: right
- 05:47:44 [heycam]
- ... did you have examples on your spreadsheet of examples where Gecko/Blink are broken?
- 05:47:54 [heycam]
- smfr: most sites had more complex hierarchies
- 05:48:11 [heycam]
- ... nobody had just perspective and transformed chlidren
- 05:48:24 [heycam]
- ... so, hard to say
- 05:49:23 [heycam]
- smfr: going back to the example, next set of questions is about the preserve-3d behavior
- 05:49:33 [heycam]
- ... I think the right hting for preserve-3d is to establish or extend a 3d rendering context
- 05:50:10 [heycam]
- ... so in this case, if you put a preserve3d wrapper around the child -- leaf doesn't have the preserve 3d -- ...
- 05:50:40 [heycam]
- chrishtr: so 2 transformed elements in a single context are sorted with respect to each other
- 05:50:57 [heycam]
- krit: this example would render the same in all browsers now?
- 05:51:08 [heycam]
- smfr: not sure that Gecko will do intersection between the two
- 05:51:39 [heycam]
- krit: the proposal is if you have persecptive set to a value, you'll establish a 3d rendering context?
- 05:51:40 [heycam]
- smfr: yes
- 05:52:06 [heycam]
- chrishtr: support you have an element with perspective. and a child with no transforms. then a grandchild ---
- 05:52:08 [heycam]
- smfr: we'll come to that
- 05:52:44 [heycam]
- ... web site data showed that noop divs should not flatten
- 05:53:07 [heycam]
- ... some interesting cases then, things like opacity that trigger flattening
- 05:53:18 [heycam]
- ... creates a stacking context, and a graphical group, it triggers flattening
- 05:53:51 [heycam]
- mattwoodrow: my biggest concern with the noop thing is it's hard to describe what hte behavior is
- 05:54:09 [heycam]
- ... the spec wording for how to decide how to establish a new one or to participate in an "ancestor" ...
- 05:54:16 [heycam]
- smfr: think that should be written in terms of stacking context ancestors
- 05:54:24 [heycam]
- ... WebKit's implementation is based on paint order, not containing block order
- 05:54:34 [heycam]
- ... I think there are some cases where these properties should trigger a containing block for ease of implementation
- 05:54:40 [heycam]
- ... but effectively we certainly work in painting order
- 05:54:43 [bobbytung]
- bobbytung has joined #css
- 05:54:45 [heycam]
- mattwoodrow: there are things liek overflow:scroll
- 05:54:51 [heycam]
- ... anything that has a clip ...
- 05:55:11 [heycam]
- chrishtr: setting aside overlfow:scroll, do you think this opacity would need to establish a containing block?
- 05:55:13 [heycam]
- smfr: no?
- 05:55:35 [heycam]
- ... another interesting case. things that trigger stacking contexts but which arent' grouping effects
- 05:55:40 [heycam]
- ... for example z-index
- 05:55:56 [heycam]
- ... that doesn't create a graphical group, but stacking contexts are effectively graphical groups, so it should flatten as well
- 05:55:58 [heycam]
- ... it's no-op-ish
- 05:56:06 [heycam]
- ... so I think in the model it has to flatten
- 05:56:29 [heycam]
- ... 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 [heycam]
- ... not really sure how to describe the clipping effects of oveflow
- 05:56:48 [heycam]
- mattwoodrow: think we want different behavior for pereserve-3d and perspective
- 05:57:04 [heycam]
- ... for preserve-3d we probably want to flatten. but the persecptive subset we could do relatively easily
- 05:57:23 [heycam]
- chrishtr: can we go through a quick example of doing parallax with this model?
- 05:57:31 [heycam]
- mattwoodrow: currently in Gecko, the clip is applied on the outside of the persecptvie
- 05:57:38 [heycam]
- ... the perspective gets multipled into the transformed elements
- 05:57:46 [heycam]
- ... but the perspective origin is outside the scrolled element
- 05:57:53 [heycam]
- ... the clip is not in the middle of the transform chain
- 05:58:13 [heycam]
- chrishtr: as long as we can preserve parallax scrolling....
- 05:59:17 [heycam]
- 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 [heycam]
- chrishtr: I think you would want this to be a containing block and stacking context as well
- 05:59:37 [heycam]
- ... it's neither of those 2 things by default
- 05:59:40 [heycam]
- mattwoodrow: right
- 05:59:46 [heycam]
- smfr: when it has preserve3d around somehow?
- 06:00:00 [heycam]
- chrishtr: walk up the tree, if it's got preserve3d around an overflow:scroll, ...
- 06:00:22 [heycam]
- 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 [heycam]
- [some discussion about preserve-3d on the overflow:scroll element resulting in the computed style being transform-style:flat]
- 06:02:21 [heycam]
- 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 [heycam]
- smfr: noop divs don't flatten
- 06:02:39 [heycam]
- mattwoodrow: I think it's easier to specify if they do flatten
- 06:02:45 [heycam]
- astearns: but not what authors expect?
- 06:02:47 [heycam]
- chrishtr: maybe
- 06:02:59 [heycam]
- smfr: none of these examples totally broke. but you could see the perspective looked different on some elements
- 06:03:08 [heycam]
- chrishtr: definitely think aligning browser behavior is going to break some content
- 06:03:16 [heycam]
- ... should minimize that, but come up with a model that we're sure is well defined
- 06:03:27 [heycam]
- smfr: that flattening was the most obvious breakage if we followed the Gecko model straight away
- 06:03:57 [heycam]
- ... I think the last piece is the discussion around how perserve-3d behaves ...
- 06:04:13 [heycam]
- smfr: on #1950, Tab lists four different behaviors
- 06:04:27 [heycam]
- ... don't fully undersatnd if they're the same except for whether preserve-3d is on the parent or the child
- 06:05:39 [heycam]
- chrishtr: Q1 is, do the children 3d sort before they flatten
- 06:07:25 [TabAtkins]
- 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 [heycam]
- chrishtr: and these behaviors are the 2 core ones we control with preserve-3d or perspective
- 06:07:53 [heycam]
- ... taht's your whole point? how do they behave dfeault and how do the properties affect this?
- 06:07:54 [heycam]
- TabAtkins: yes
- 06:08:04 [heycam]
- ... all 4 combinations seem reasonable, don't know if you want to expose them all
- 06:08:22 [heycam]
- ... case 1 is fully 3d, everything is operating in the same graph
- 06:08:28 [duga]
- duga has joined #css
- 06:08:33 [heycam]
- ... case 2 is you run the children's 3d scene, flatten it, the parent does the 3d scene
- 06:08:38 [dbaron]
- 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 [heycam]
- ... #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 [heycam]
- ... 4, double flat is simple
- 06:09:35 [heycam]
- 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 [heycam]
- ... 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 [heycam]
- chrishtr: I think that first part of the sentence is a good reason why perspective should not imply preserve-3d
- 06:10:12 [heycam]
- smfr: so valid to hav eshared perspective, but siblings not intersecting, which is contrary to my first point
- 06:11:21 [heycam]
- smfr: ok, so we're back to perspective not making a context
- 06:11:29 [heycam]
- ... question is how many of these sites would break
- 06:11:41 [heycam]
- chrishtr: then there's the question of resolving the intermediate divs
- 06:11:49 [heycam]
- ... how we'd spec and implement the corner cases
- 06:12:00 [heycam]
- ... if those intermeidate divs would in some cases be transmitting up the preserve-3d as opposed to flattening
- 06:12:09 [heycam]
- smfr: unless we're willing to go to the Gecko model of always flattening
- 06:12:15 [heycam]
- smfr: still think that's the most web incompatible change
- 06:12:23 [heycam]
- chrishtr: if it was web compatible would it be objectionable to you?
- 06:12:24 [heycam]
- smfr: no
- 06:12:30 [heycam]
- chrishtr: certaimly the easiest to reason about in the spec
- 06:13:04 [heycam]
- ... 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 [heycam]
- mattwoodrow: I can do that
- 06:13:27 [heycam]
- chrishtr: and whether it's easy to fix them
- 06:14:03 [heycam]
- 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 [heycam]
- chrishtr: the intersecting thing?
- 06:14:11 [heycam]
- smfr: yeah
- 06:14:20 [heycam]
- ... no authors are using preserve-3d on the element with perspetive
- 06:14:25 [heycam]
- chrishtr: you would've observed a rendering difference
- 06:14:41 [heycam]
- smfr: these don't have multiple siblings, so wouldn't necessarily see that
- 06:15:03 [heycam]
- chrishtr: nobody's done any httparchive searches
- 06:15:09 [heycam]
- ... would be good to find mor eto sanity check
- 06:15:28 [heycam]
- smfr: the stripe stuff is genuine content, most others are old demos
- 06:15:47 [heycam]
- chrishtr: ancedotally, not sure how common this kind of content is
- 06:16:00 [heycam]
- ... I will volunteer to do an httparchive search tonight
- 06:16:19 [heycam]
- florian: I think the lack of interop is indeed causing a lack of sites using it
- 06:16:28 [heycam]
- ... I did retire a site that used to use 3d
- 06:18:30 [heycam]
- Topic: backface visibility
- 06:19:39 [astearns]
- github: https://github.com/w3c/csswg-drafts/issues/918
- 06:20:11 [heycam]
- mattwoodrow: current spec says that backface-visibility only applies to the element it's on, not descendants
- 06:20:20 [heycam]
- ... doesn't say it would create any plane or layer, which Gecko faithfully implements
- 06:20:30 [heycam]
- ... other engines create a plane for all descendants but not positioned descendants
- 06:20:45 [heycam]
- ... which is not something there's any precedent for, seems a bit crazy. would prefer backface-visibility create a stacking context
- 06:20:55 [heycam]
- smfr: I think in WebKit it does create a stacking context, not a containing block
- 06:21:02 [heycam]
- mattwoodrow: maybe it is that it doesn't create a containing block
- 06:21:08 [heycam]
- chrishtr: definitely doesn't create a stacking context
- 06:21:11 [dauwhe]
- dauwhe has joined #css
- 06:21:18 [heycam]
- smfr: I'd be scared to change hte behavior of backface-visibility...
- 06:21:33 [heycam]
- mattwoodrow: so try to find a descroption of what it actually does. affects itself and non-positioned descendants?
- 06:22:17 [heycam]
- chrishtr: self painting layers reset the backface visibility thing
- 06:22:21 [heycam]
- mattwoodrow: don't know how to describe it for the spec
- 06:22:43 [heycam]
- chrishtr: similar to the set of things dbaron found that caused "painting as if positioned"
- 06:22:55 [heycam]
- ... in CSS 2.1, positioned elts paint later than regular elements
- 06:22:56 [dbaron]
- https://dbaron.org/css/test/2018/stacking-context-z-order
- 06:23:02 [heycam]
- ... anything that has an effect-y thing on it
- 06:23:09 [heycam]
- ... this is exactly what is on self painting layers
- 06:23:19 [heycam]
- ... so we could define it that way
- 06:23:23 [heycam]
- florian: where else did we run into this?
- 06:23:37 [heycam]
- chrishtr: might have been another case yes
- 06:23:48 [heycam]
- ... but the thing about hte paint order is one that's not specified properly, is that right?
- 06:24:26 [heycam]
- 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 [heycam]
- chrishtr: overflow:hidden, backface-visibility, SVG elements and other atomically replaced elements, ...
- 06:24:54 [heycam]
- ... CSS clip probably
- 06:25:06 [heycam]
- ... and the rest of them do create stacking contexts
- 06:25:30 [heycam]
- ... we should define this, get interop on the table in dbaron's test, then use it for the backface-visibility definition
- 06:25:48 [heycam]
- dbaron: I don't think there's a whole lot in there that's not creating a stacking context
- 06:25:54 [heycam]
- ... CSS clip only applies to things that are positioned
- 06:26:01 [heycam]
- chrishtr: but in terms of the "painting as if positioned"
- 06:26:10 [heycam]
- ... I think overflow:clip is the most common
- 06:26:18 [heycam]
- dbaron: have we added that yet?
- 06:26:23 [heycam]
- chrishtr: I mean overlfow:hidden and scroll
- 06:26:45 [heycam]
- ... 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 [heycam]
- smfr: WK does not create self painting layers for [...]
- 06:27:11 [heycam]
- dbaron: I don't htink Gecko sorts overflow:hidden on to positioned descendants list
- 06:27:13 [heycam]
- mattwoodrow: don't think so
- 06:27:30 [astearns]
- s/[...]/overflow:hidden/
- 06:27:55 [sanketj]
- sanketj has joined #css
- 06:27:57 [heycam]
- 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 [heycam]
- smfr: so is everything on the list make stacking context?
- 06:28:11 [heycam]
- mattwoodrow: yes
- 06:28:21 [heycam]
- chrishtr: overflow:hidden does not create a self painting layer (in Blink)
- 06:28:41 [heycam]
- ... 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 [heycam]
- ... that's something we could change in Chrome
- 06:29:09 [heycam]
- ... in any case, is this a good way to spec it?
- 06:29:52 [heycam]
- mattwoodrow: yes, I agree the CSS 2.1 spec describes floats [...]
- 06:30:27 [dbaron]
- I think Gecko calls this "pseudo-stacking context"
- 06:30:40 [heycam]
- RESOLUTION: Add a new "pseudo-stacking context" definition and use it to define how backface-visibility works
- 06:30:59 [heycam]
- 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 [heycam]
- ... maybe a central painting spec
- 06:31:34 [heycam]
- -- break until 4pm --
- 06:31:36 [futhark]
- futhark has joined #css
- 06:32:37 [ericc]
- ericc has joined #css
- 06:41:48 [romain_]
- romain_ has joined #css
- 06:42:33 [plh]
- plh has joined #css
- 06:43:21 [dauwhe]
- dauwhe has joined #css
- 06:46:06 [zcorpan]
- zcorpan has joined #css
- 06:46:46 [duga]
- duga has joined #css
- 06:54:29 [xfq]
- xfq has joined #css
- 06:57:28 [mattwoodrow]
- mattwoodrow has joined #css
- 07:01:13 [stantonm]
- stantonm has joined #css
- 07:07:25 [futhark]
- futhark has joined #css
- 07:07:41 [karl]
- karl has joined #css
- 07:10:33 [sanketj]
- sanketj has joined #css
- 07:12:09 [TabAtkins]
- ScribeNick: TabAtkins
- 07:12:11 [kurosawa]
- kurosawa has joined #css
- 07:12:19 [nigel]
- nigel has joined #css
- 07:12:36 [TabAtkins]
- Topic: Define path() in Shapes 1 or 2
- 07:12:51 [TabAtkins]
- astearns: A number of specs are using <basic-shape>, which has several functions in Shapes 1, but not path().
- 07:13:02 [TabAtkins]
- astearns: But path() is being implemented for *some* of the <basic-shape> properties.
- 07:13:12 [TabAtkins]
- astearns: It's weird to have them linking to a definition in Shapes 2 that's just a diff.
- 07:13:26 [TabAtkins]
- astearns: One option is to flesh out Shapes 2 into an actual spec, with a proper definition for <basic-shape> including path()
- 07:13:41 [TabAtkins]
- astearns: Another option is to pull path() back into Shapes 1, which implies we should implement it for shape-outside
- 07:13:46 [TabAtkins]
- astearns: I don't much care which one we do.
- 07:13:54 [TabAtkins]
- astearns: But would like to resolve on which way to o.
- 07:14:26 [dlibby]
- dlibby has joined #css
- 07:14:42 [TabAtkins]
- 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]
- fremy has joined #css
- 07:15:19 [TabAtkins]
- TabAtkins: Spec's easy, I'm fine with it in level 1.
- 07:15:41 [TabAtkins]
- astearns: I think Ian said it woudln't be trivial, but seems plausible to do.
- 07:15:44 [TabAtkins]
- eae: Yes.
- 07:15:59 [TabAtkins]
- s/it/doing path() in shape-outside/
- 07:16:25 [TabAtkins]
- 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 [TabAtkins]
- astearns: Can deal with how that slows down Shapes 1 from PR as we find impls to try it out.
- 07:16:41 [TabAtkins]
- astearns: Objections?
- 07:16:56 [futhark]
- futhark has joined #css
- 07:17:07 [AmeliaBR]
- 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 [TabAtkins]
- heycam: Any objection to shipping path() in things like offset-path - do they need to ship together?
- 07:17:59 [TabAtkins]
- TabAtkins: [reads Amelia's IRC comment]
- 07:18:09 [TabAtkins]
- astearns: Yeah that's a bit of th eproblem, some properties don't need fill-rule at all.
- 07:18:23 [TabAtkins]
- 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 [TabAtkins]
- heycam: Would that block Motion Path?
- 07:19:09 [TabAtkins]
- 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 [AmeliaBR]
- 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 [TabAtkins]
- astearns: This is really all about Process.
- 07:19:59 [TabAtkins]
- astearns: Tab, you mentioned Chris Coyier's annoyance with the shapes being different everywhere.
- 07:21:22 [TabAtkins]
- 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_]
- glenn_ has joined #css
- 07:21:32 [TabAtkins]
- [discussion about CSS tokenization not being compatible with SVG]
- 07:21:36 [kevers]
- kevers has joined #css
- 07:21:40 [TabAtkins]
- myles: Does that mean you can't build up paths from varia les?
- 07:21:47 [TabAtkins]
- TabAtkins: Not without defining a new syntax that's CSS compatible.
- 07:21:55 [TabAtkins]
- AmeliaBR: Or doing the string-concat function.
- 07:22:01 [TabAtkins]
- myles: Didn't we resolve to add that?
- 07:22:07 [TabAtkins]
- AmeliaBR: Yeah, but no one's written it yet.
- 07:22:42 [TabAtkins]
- 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 [TabAtkins]
- 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 [TabAtkins]
- 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 [TabAtkins]
- astearns: I'm not that concerned with getting it to Rec real quick.
- 07:24:48 [TabAtkins]
- AmeliaBR: Does adding path() mean we have to cycle back to WD, as a significant new feature?
- 07:24:50 [Ms2ger]
- Ms2ger has joined #css
- 07:24:52 [TabAtkins]
- florian: Nah it's fine.
- 07:25:03 [TabAtkins]
- florian: Patent Policy will handle it fine; as long as you've got wide review and what not is fine.
- 07:25:13 [TabAtkins]
- AmeliaBR: It's been reviewed in Motion Path, but review there...
- 07:25:23 [TabAtkins]
- florian: The easier it is to demonstrate review, the easier time you'll have.
- 07:25:29 [TabAtkins]
- astearns: And if we have to bounce to WD, that's fine.
- 07:25:47 [TabAtkins]
- 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]
- TabAtkins: Yeah, a circle is a path, whatever.
- 07:26:23 [TabAtkins]
- astearns: So any objection to adding path() to Shapes 1?
- 07:26:39 [TabAtkins]
- RESOLVED: Move path() down to Shapes 1, adding it to <basic-shape>.
- 07:27:06 [TabAtkins]
- krit: I missed - are impls willing to support path() in shape-outside?
- 07:27:14 [TabAtkins]
- astearns: Missing a few people that would answer that.
- 07:27:21 [TabAtkins]
- TabAtkins: Ian says it's non-trivial, but doable.
- 07:27:36 [TabAtkins]
- 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 [TabAtkins]
- 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]
- duga has joined #css
- 07:29:18 [TabAtkins]
- astearns: I don't know if we currently have text to that effect with polygons...
- 07:29:26 [TabAtkins]
- s/astearns/AmeliaBR/
- 07:29:41 [TabAtkins]
- astearns: We do have text for some degenerate/difficult situations, saying you do have to do the difficult stuff.
- 07:29:59 [TabAtkins]
- 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 [TabAtkins]
- astearns: So I think it's just a QoI detail they can live with.
- 07:30:18 [TabAtkins]
- krit: So if we agree it's just QoI, it's probably fine.
- 07:30:27 [smfr]
- smfr has joined #css
- 07:30:30 [glenn]
- glenn has joined #css
- 07:30:39 [TabAtkins]
- AmeliaBR: There's already a lot of flexibility for, say, *drawing* SVG paths.
- 07:30:41 [TabAtkins]
- krit: Ok.
- 07:31:03 [astearns]
- github: https://github.com/w3c/csswg-drafts/issues/4270
- 07:31:13 [Travis]
- Travis has joined #css
- 07:32:13 [TabAtkins]
- Topic: Sunsetting the fxtf-drafts repo
- 07:32:32 [glazou]
- glazou has joined #css
- 07:32:48 [TabAtkins]
- AmeliaBR: This has already been decided, but there's been no volunteer to do the work.
- 07:32:53 [TabAtkins]
- TabAtkins: I can do it.
- 07:33:05 [Zakim]
- Zakim has left #css
- 07:33:30 [TabAtkins]
- plinss: We'll need to add some redirects to the draft server, since the URLs will change. Coordinate with me.
- 07:33:40 [Zakim]
- Zakim has joined #css
- 07:36:01 [heycam]
- ScribeNick: heycam
- 07:36:38 [TabAtkins]
- Topic: Should list-item counter reset rule be in a UA stylesheet?
- 07:36:53 [astearns]
- github: https://github.com/w3c/csswg-drafts/issues/4244
- 07:37:00 [heycam]
- 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 [heycam]
- .. we've had 2 regression reports, people overriding counter-reset
- 07:37:21 [heycam]
- ... the fix on the author side is trivial, adding list-item to the value
- 07:37:28 [heycam]
- ... afaik, the 2 regressions are fixed that way
- 07:37:36 [heycam]
- ... but we may want to think about whether we should make this reset magical
- 07:37:46 [heycam]
- ... the issue with making it magical, is that there's no way to override it to none
- 07:37:57 [heycam]
- TabAtkins: at the previous meeting, didn't we resolve to do the thing where if you don't mention list-item?
- 07:38:01 [heycam]
- emilio: that's for counter-increment
- 07:38:05 [heycam]
- ... should we do the same for counter-reset?
- 07:38:14 [heycam]
- ... the reason I didn't want to jump to do that, there's no way to override it to none
- 07:38:14 [futhark]
- futhark has joined #css
- 07:38:27 [heycam]
- ... could say you add the counter-reset, unless you explicitly set it to none
- 07:38:29 [heycam]
- ... so it's tricky
- 07:38:54 [heycam]
- ... not totally convinced we need to change it for compat, but I'd like to know if we do need it
- 07:39:21 [heycam]
- TabAtkins: if we wanted to express the reverse mbehavior, in non magical ways, you'd need something special for counter-reset
- 07:39:32 [heycam]
- ... the only way to do that within the syntax of counter-reset would be to add a function
- 07:39:52 [heycam]
- ... 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 [heycam]
- ... 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 [heycam]
- ... could have a dont-reset(...) when you explicitly need to
- 07:40:44 [heycam]
- ... then if it's not explicitly mentioned in this way, it gets reset in this way
- 07:40:48 [heycam]
- emilio: not a fan
- 07:41:06 [heycam]
- AmeliaBR: counter-reset: dont-reset(list-item), xxx
- 07:41:52 [heycam]
- emilio: just looking for ideas if we needed to tackle this
- 07:41:56 [heycam]
- ... for now this is fine I think
- 07:42:14 [heycam]
- ... a more web compatible solution would be to always reset it, but then it's annoying you can't override it
- 07:42:18 [heycam]
- TabAtkins: you can override the use of it
- 07:42:35 [heycam]
- emilio: the browser's doing some extra accounting in the background, but the author just wouldn't use it
- 07:42:42 [heycam]
- s/emilio/TabAtkins/
- 07:43:08 [glazou_]
- glazou_ has joined #css
- 07:43:12 [heycam]
- fremy: what happens if you don't reset, and you have a reversed list inside another reversed list?
- 07:43:14 [heycam]
- AmeliaBR: it's a nested counter
- 07:43:30 [heycam]
- fremy: if you're not resetting th ecounter, you have to consider the nested child as part of the main list
- 07:43:34 [heycam]
- ... does anyone want to implement that?
- 07:43:38 [heycam]
- emilio: I think it would work right now
- 07:44:02 [heycam]
- AmeliaBR: the list items handle if you're incrementing up or down
- 07:44:14 [heycam]
- 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 [heycam]
- ... I think it would work. mixing reversed and non-reversed lists would be fun...
- 07:44:35 [heycam]
- fremy: not sure it's a big problem if we cannot
- 07:45:41 [heycam]
- 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 [heycam]
- TabAtkins: so far no, since that's what reversed counters actually do in HTML
- 07:46:01 [TabAtkins]
- s/that's not/that's not what/
- 07:46:06 [TabAtkins]
- s/that's what/that's not what/
- 07:46:46 [glenn]
- glenn has joined #css
- 07:46:54 [nmccully]
- nmccully has joined #css
- 07:48:08 [TabAtkins]
- ScribeNick: TabAtkins
- 07:48:32 [nmccully_]
- nmccully_ has joined #css
- 07:49:13 [TabAtkins]
- Topic: word-break:keep-all and overflow
- 07:49:49 [TabAtkins]
- florian: In langs like English, word-break:keep-all is same as normal
- 07:49:52 [astearns]
- github: https://github.com/w3c/csswg-drafts/issues/4286
- 07:50:03 [TabAtkins]
- florian: In Japanese, it suppresses a lot of wrapping opportunities. (Not quite all, but most.)
- 07:50:27 [TabAtkins]
- 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 [TabAtkins]
- florian: Currently ther'es a provisio in the spec that the UA may reproduce the suppressed wrapping oppo to reduce overflow.
- 07:50:57 [TabAtkins]
- 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 [TabAtkins]
- florian: An example of this is a title or figcaption, a short piece of text.
- 07:51:49 [TabAtkins]
- florian: People tend to like it not breaking anywhere in Japanese.
- 07:52:07 [TabAtkins]
- 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]
- futhark has joined #css
- 07:52:41 [TabAtkins]
- myles: This value is for Korean, right?
- 07:52:52 [TabAtkins]
- florian: It's frequently used for Korean, but it's also useful for other CJK langs.
- 07:53:06 [TabAtkins]
- florian: Any lang that allows breaking at syllable/char boundaries can use this to opt into a less free-form style.
- 07:53:23 [TabAtkins]
- myles: Right, just if Korean use is most common for this, we should see what Korean native speakers prefer.
- 07:53:49 [TabAtkins]
- koji: I'd prefer this be explicit, so it happens only when authors opt in, like overflow-wrap.
- 07:54:09 [TabAtkins]
- 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 [TabAtkins]
- koji: If it's useful for Korean it's probably useful for English.
- 07:54:48 [TabAtkins]
- 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 [TabAtkins]
- 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 [TabAtkins]
- myles: What about overflow-wrap:anywhere?
- 07:55:23 [TabAtkins]
- florian: This isn't actually anywhere, tho.
- 07:55:29 [TabAtkins]
- myles: Maybe break-word?
- 07:55:38 [TabAtkins]
- florian: break-word and anywhere are identical except for intrinsic sizes.
- 07:56:03 [TabAtkins]
- 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 [TabAtkins]
- 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_]
- Rossen_ has joined #css
- 07:56:44 [TabAtkins]
- koji: In my mind, the two variants of Korean linebreaking are just variants; keep-all is normal behavior.
- 07:57:04 [TabAtkins]
- 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 [TabAtkins]
- 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 [TabAtkins]
- 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 [TabAtkins]
- florian: We have this in german/english/etc by using hyphenation, with "" for the hyphenation character.
- 07:59:10 [TabAtkins]
- 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 [TabAtkins]
- koji: I don't think we can change that, so we might want to add the fourth value.
- 07:59:42 [TabAtkins]
- myles: That's what break-word was supposed to do way back when Hyatt implemented it...
- 08:00:26 [TabAtkins]
- 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]
- duga has joined #css
- 08:00:46 [TabAtkins]
- 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 [TabAtkins]
- koji: Ok, well, I think this is basically the same as modifying keep-all.
- 08:01:26 [TabAtkins]
- 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 [TabAtkins]
- 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 [TabAtkins]
- florian: So we could defer the always-prevent value if it's going to be rare.
- 08:02:09 [TabAtkins]
- florian: It's just having the "may" that I think isn't terribly useful.
- 08:02:17 [TabAtkins]
- myles: Right, making a resolution now seems premature.
- 08:02:24 [TabAtkins]
- florian: Sure. That's enough feedback fo rnow.
- 08:02:36 [TabAtkins]
- Topic: How to handle leading ideographic space sequences
- 08:03:14 [TabAtkins]
- florian: this has evolved over time; they're a strange kind of space, like figure spaces, ideographic spaces, etc
- 08:03:24 [astearns]
- github: https://github.com/w3c/csswg-drafts/issues/4180
- 08:03:33 [TabAtkins]
- 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 [TabAtkins]
- 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 [TabAtkins]
- florian: We coul dinsted hang them.
- 08:04:30 [TabAtkins]
- florian: Diff is you could still see them if you underline or background them.
- 08:04:42 [TabAtkins]
- florian: But from layout, it would be the same as an empty line.
- 08:04:56 [TabAtkins]
- florian: This was found by Igalia when implementing the spec as written, and it seemed weird to them.
- 08:05:28 [TabAtkins]
- 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 [TabAtkins]
- florian: I made a PR for this, I know fantasai is okay with this.
- 08:05:50 [TabAtkins]
- ???: Is there precedence fo rhaving that many hanging spaces?
- 08:05:57 [astearns]
- s/???/stantonm/
- 08:06:02 [TabAtkins]
- florian: Yes, we have some other situations like white-space:pre-wrap.
- 08:06:21 [TabAtkins]
- florian: There's an open issue for some variant situations, but...
- 08:06:39 [TabAtkins]
- stantonm: The inline border does seem strange.
- 08:06:51 [TabAtkins]
- stantonm: An inline with a border would project off the edge of the element.
- 08:06:57 [TabAtkins]
- florian: Like any overflowing content, es.
- 08:08:29 [TabAtkins]
- florian: Example: "<span>a b </span>". 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 [TabAtkins]
- koji: Hanging would require changes to our whitespace code that we'd like to avoid if possible.
- 08:09:12 [TabAtkins]
- myles: there are like 5000 ways to make text look bad on the web already
- 08:09:21 [TabAtkins]
- stantonm: Is there a way to avoid this?
- 08:09:30 [TabAtkins]
- florian: Yes, text-underline-skip for example.
- 08:10:02 [TabAtkins]
- astearns: So proposed resolution is to accept the PR, which states that the spaces will hang.
- 08:10:06 [TabAtkins]
- astearns: Objections?
- 08:10:47 [TabAtkins]
- RESOLVED: Trailing "other-separator spaces" will hang, accepting Florian's PR.
- 08:11:26 [astearns]
- topic: is it OK to ship clip-path:path()
- 08:11:40 [astearns]
- github: https://github.com/w3c/csswg-drafts/issues/4271
- 08:11:42 [TabAtkins]
- astearns: There was a second gh issue we didn't send the comments to
- 08:11:56 [TabAtkins]
- astearns: An impl was asking if it was okay to ship clip-path:path()
- 08:12:16 [TabAtkins]
- 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 [TabAtkins]
- astearns: So in my mind the intent of moving this to level 1 is to let impls ship it.
- 08:12:44 [TabAtkins]
- heycam: clip-path:path() is already shipping in WK, I believe. Not in Chrome yet. Ready in firefox for a while.
- 08:13:21 [TabAtkins]
- heycam: Just wanted to make sure nothing drastic would happen to the syntax.
- 08:13:47 [TabAtkins]
- krit: CSS Masking is already in CR, so implementing clip-path is fine; this is specifically about the path() function.
- 08:14:26 [TabAtkins]
- astearns: Does anyone think Gecko should *not* ship the syntax?
- 08:14:42 [TabAtkins]
- RESOLVED: Impls can ship clip-path:path()
- 08:15:01 [TabAtkins]
- github-bot: end topic
- 08:15:14 [TabAtkins]
- heycam: What's the policy on this sort of "blessing"?
- 08:15:52 [fantasai]
- we put it into the Snapshot
- 08:15:56 [TabAtkins]
- 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 [TabAtkins]
- Topic: text-size-adjust
- 08:16:55 [TabAtkins]
- myles: People like to view websites on their phones.
- 08:17:01 [TabAtkins]
- [general astonishment]
- 08:17:08 [TabAtkins]
- myles: But phones ar esmall. So the text is usually too small
- 08:17:31 [TabAtkins]
- myles: So way back in 2007, iPhone 1 implemented a feature to automatically increase the text size without increasing page size.
- 08:17:42 [TabAtkins]
- myles: We've been shipping this for a very long time.
- 08:17:44 [tantek]
- FYI some old writing on this here: https://wiki.mozilla.org/CSS/text-size-adjust
- 08:17:55 [TabAtkins]
- myles: This is controllable with a CSS property called -webkit-text-size-adjust
- 08:18:42 [TabAtkins]
- 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 [TabAtkins]
- myles: So if font-size is 10px, and wtsa is 130%, you'd see a 13px size.
- 08:19:44 [TabAtkins]
- myles: So a bit later we shipped the iPad, also a small screen.
- 08:20:03 [TabAtkins]
- 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 [TabAtkins]
- myles: So it also got the text-size-adjust behavior.
- 08:20:20 [TabAtkins]
- myles: This past year we've changed iPad behavior.
- 08:20:28 [TabAtkins]
- myles: Now iPads get desktop content.
- 08:20:43 [TabAtkins]
- myles: So this means that sites which said -wtsa, we don't get that behavior anymore.
- 08:20:50 [TabAtkins]
- myles: But ipads are still small, so we have to do something.
- 08:21:03 [TabAtkins]
- myles: After research, turns out the method we need to increase font-sizes is different between ipad and iphone
- 08:21:21 [TabAtkins]
- 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 [TabAtkins]
- myles: In ipad, people don't usually double-tap on elements, so the goal was to make it readable by default.
- 08:21:42 [TabAtkins]
- s/double-text/double-tap/
- 08:21:47 [TabAtkins]
- myles: So the heuristics are pretty different.
- 08:21:50 [TabAtkins]
- myles: No problem so far.
- 08:22:06 [dauwhe]
- dauwhe has joined #css
- 08:22:18 [TabAtkins]
- 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 [TabAtkins]
- myles: But when we flipped the switch, ipads were honoring the property, and everything got messed up.
- 08:23:05 [Rossen_]
- Rossen_ has joined #css
- 08:23:05 [TabAtkins]
- 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]
- futhark has joined #css
- 08:23:33 [TabAtkins]
- myles: Correlation between sites that did that, and sites that *needed* wtsa to work well on the ipad, unfortunately.
- 08:23:40 [TabAtkins]
- myles: So what we now have implemented in ToT is...
- 08:23:54 [TabAtkins]
- myles: none still means none. auto still means magic; different than phone, but still magic.
- 08:24:13 [TabAtkins]
- myles: But %, we found that if treated %s as auto, it made the web look better than honoring the %s.
- 08:24:43 [TabAtkins]
- 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 [TabAtkins]
- myles: So it would be good to write that down.
- 08:25:00 [TabAtkins]
- myles: There is a spec covering this feature, CSS Text Size Adjust.
- 08:25:04 [drott]
- https://drafts.csswg.org/css-size-adjust/#adjustment-control
- 08:25:10 [TabAtkins]
- myles: I have a bunch of edits I'd like to make to that spec.
- 08:25:48 [TabAtkins]
- 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 [karl]
- https://github.com/whatwg/compat/issues/18
- 08:26:05 [TabAtkins]
- 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 [TabAtkins]
- 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 [TabAtkins]
- myles: So want to know what wg thinks.
- 08:26:58 [TabAtkins]
- astearns: How are you speccing this behavior? UAs may do this, may do that...?
- 08:27:01 [heycam]
- q+
- 08:27:14 [TabAtkins]
- myles: Strat we thought best was to keep things general. Two behavior on two platforms, browsers might have other behaviors, etc.
- 08:27:26 [TabAtkins]
- myles: As long as the author can know what was done and fix it, should be fine.
- 08:27:35 [lajava]
- lajava has joined #css
- 08:27:40 [TabAtkins]
- 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 [astearns]
- ack heycam
- 08:28:05 [TabAtkins]
- 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 [TabAtkins]
- heycam: Exposed thru the computed style.
- 08:28:14 [TabAtkins]
- myles: Already how iphone works
- 08:28:43 [TabAtkins]
- 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 [TabAtkins]
- myles: In webkit I think we don't follow the inheritance rules to the letter for this property.
- 08:29:13 [TabAtkins]
- myles: If you stack a bunch of %s, they don't multiply.
- 08:29:34 [TabAtkins]
- dbaron: I heard you saying look at computed value of font-size, not text-size-adjust.
- 08:29:37 [TabAtkins]
- myles: Right!
- 08:29:46 [emilio]
- q+
- 08:29:56 [TabAtkins]
- 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 [TabAtkins]
- myles: S'o they know what to consult and fix.
- 08:30:07 [astearns]
- ack dbaron
- 08:30:14 [TabAtkins]
- dbaron: I think most of this sounds fantastic.
- 08:30:21 [TabAtkins]
- dbaron: A little nervous about generalization.
- 08:30:36 [TabAtkins]
- dbaron: Would be nice to have a good description if someone wants to implement this...
- 08:30:52 [TabAtkins]
- myles: So over the past long time we wanted to change how ipad viewed the web
- 08:30:55 [TabAtkins]
- myles: but text was too small
- 08:31:00 [emilio]
- karl: aliases are cheap
- 08:31:04 [TabAtkins]
- myles: the iphone's model isn't really what we want
- 08:31:28 [TabAtkins]
- 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 [TabAtkins]
- myles: Tried to come up with an algo for the ipad, and we implemented it, and it wasn't good
- 08:31:44 [TabAtkins]
- myles: Cycled for a while.
- 08:32:04 [TabAtkins]
- 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 [TabAtkins]
- myles: Adn then did the same to tap on the thins that weren't too msall
- 08:32:28 [TabAtkins]
- myles: Then used ML to predict too-small vs ok-size.
- 08:32:38 [TabAtkins]
- myles: So we have a decision tree, but...
- 08:32:50 [TabAtkins]
- myles: it's not intentional. It just gives good results on a lot of pages.
- 08:33:03 [TabAtkins]
- 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 [TabAtkins]
- 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 [TabAtkins]
- myles: Maybe as a non-normative impl guide?
- 08:33:31 [TabAtkins]
- myles: That's fine.
- 08:33:51 [tantek]
- q?
- 08:33:53 [TabAtkins]
- florian: If I'm an author and your algo gets it wrong, that seems unpredictable to me.
- 08:34:06 [TabAtkins]
- myles: We try our best to make the heuristic good, and you can use "none" to fix it.
- 08:34:18 [florian]
- s/Florian/fremy/
- 08:34:30 [futhark]
- futhark has joined #css
- 08:34:46 [TabAtkins]
- 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 [TabAtkins]
- tantek: So that lack of predictability caused authors to misuse the property.
- 08:36:40 [TabAtkins]
- 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 [TabAtkins]
- fremy: Ultimately if the heuristic isn't understandable/predictable, Stack Overflow will just recommend swapping 100% to "none".
- 08:37:51 [TabAtkins]
- myles: And that's fine.
- 08:37:54 [astearns]
- ack emilio
- 08:38:04 [TabAtkins]
- emilio: So wk exposes the used font size...
- 08:38:12 [TabAtkins]
- emilio: Your text adust used to be layout time, right?
- 08:38:27 [TabAtkins]
- myles: Yes. But on both iphone and ipad, if you say gCS().fontSize, you'll get the used style.
- 08:38:40 [TabAtkins]
- emilio: Okay, that's not what Firefox does. But maybe we shoudl change it.
- 08:38:44 [TabAtkins]
- myles: Yeah, I think it's important.
- 08:39:11 [SimonSapin]
- q+ to ask if em units are affected
- 08:39:31 [karl]
- RRSAgent, make minutes
- 08:39:31 [RRSAgent]
- I have made the request to generate https://www.w3.org/2019/09/15-css-minutes.html karl
- 08:39:46 [TabAtkins]
- 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 [TabAtkins]
- tantek: I'm okay with that.
- 08:39:58 [fremy]
- q+
- 08:40:06 [dbaron]
- +1 to myles as a coeditor
- 08:40:13 [TabAtkins]
- SimonSapin: You said computed value of font-size is affected; does that mean that other lengths using em are affected
- 08:40:16 [TabAtkins]
- myles: Yes
- 08:40:18 [drousso]
- drousso has joined #css
- 08:40:32 [tantek]
- q?
- 08:40:36 [TabAtkins]
- emilio: It didn't used to be the case, right? If you did adjustment at layout time, you can't.
- 08:40:41 [TabAtkins]
- myles: Hm, maybe I"m wrong.
- 08:40:45 [TabAtkins]
- ack SimonSapin
- 08:40:48 [Zakim]
- SimonSapin, you wanted to ask if em units are affected
- 08:41:11 [TabAtkins]
- 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 [TabAtkins]
- tantek: So maybe that's a good goal.
- 08:41:43 [TabAtkins]
- myles: I think that's a reasonable goal.
- 08:42:01 [TabAtkins]
- fremy: do you apply the sam ehueristic for all ipads?
- 08:42:09 [TabAtkins]
- myles: No, depends on screen size and viewport size and specified style
- 08:42:22 [TabAtkins]
- myles: This is listed in the proposed changes
- 08:42:41 [TabAtkins]
- 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 [TabAtkins]
- myles: I don't htink i can answer that.
- 08:43:02 [TabAtkins]
- astearns: So let's get edits into the draft and raise issues as needed.
- 08:43:03 [dauwhe]
- dauwhe has joined #css
- 08:43:10 [tantek]
- q+ to express concerns with changing algorithms based on hardware releases
- 08:43:44 [TabAtkins]
- 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 [astearns]
- ack fremy
- 08:43:59 [TabAtkins]
- plinss: Do you turn these heuristics off when MQs are involved?
- 08:44:01 [TabAtkins]
- myles: no
- 08:44:11 [TabAtkins]
- myles: But <meta viewport> does interact with this
- 08:44:28 [TabAtkins]
- myles: So if you have a webpage that is mobile-ready, that'll affect this algo
- 08:44:50 [TabAtkins]
- myles: So the algo is only strong on webpages that are getting shrunk; if they fit well it has minimal effects
- 08:45:17 [karl]
- RRSAgent, set logs public-visible
- 08:45:20 [TabAtkins]
- plinss: Overall concern is just that we should be encouraging authors to just make pages in general and use MQs .
- 08:45:46 [Rossen_]
- Rossen_ has joined #css
- 08:45:46 [TabAtkins]
- 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 [TabAtkins]
- 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 [astearns]
- ack tantek
- 08:46:34 [Zakim]
- tantek, you wanted to express concerns with changing algorithms based on hardware releases
- 08:46:35 [TabAtkins]
- myles: Users don't say "gee I wish this page used MQs" they say "I can't read NYT, this sucks"
- 08:46:49 [TabAtkins]
- tantek: So a few time syou mention hw releases meaning new algos.
- 08:47:10 [TabAtkins]
- tantek: I'm uncomfortable with algo changing with hw releases. That's not a standard.
- 08:47:18 [TabAtkins]
- tantek: I'd prefer something tha tusrvives hw releases.
- 08:47:35 [TabAtkins]
- 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 [TabAtkins]
- 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 [TabAtkins]
- 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]
- jeff has joined #css
- 08:49:31 [TabAtkins]
- TabAtkins: and note that myles wasn't originally intending to publish the algo at all, that was a dbaron request
- 08:49:47 [TabAtkins]
- tantek: I'm concerned that this'll be continuous reverse engineering.
- 08:50:00 [TabAtkins]
- myles: Yeah, when android ships another phone, they'll have to do the same sort of engineering.
- 08:50:10 [TabAtkins]
- hober: This is just acknolwedging reality
- 08:50:24 [TabAtkins]
- 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 [TabAtkins]
- 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 [TabAtkins]
- dbaron: so I'd rather have a spec that evolves over time to reflect that
- 08:51:09 [TabAtkins]
- myles: So the alternatives.
- 08:51:18 [TabAtkins]
- myles: One is a spec that changes all the time and is only good on one device, not great.
- 08:51:28 [TabAtkins]
- myles: Another is don't spec it at all, and have i tjust be magic.
- 08:51:35 [TabAtkins]
- myles: I think I've described a good middle ground.
- 08:51:44 [astearns]
- ack dbaron
- 08:52:01 [TabAtkins]
- dbaron: Commenting back on the plinss/myles convo
- 08:52:08 [TabAtkins]
- dbaron: I think using MQ as a signal is a bad idea.
- 08:52:29 [TabAtkins]
- 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 [TabAtkins]
- dbaron: So for this sort of thing, I think meta-viewport is a better signal.
- 08:52:55 [fantasai]
- I would prefer to not put more and more rendering instructions into HTML?
- 08:53:21 [TabAtkins]
- 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 [TabAtkins]
- myles: Yeah, not asking for you to pre-approve things you havne't seen.
- 08:53:42 [TabAtkins]
- RESOLVED: Add Myles as co-editor to CSS Size Adjust.
- 08:53:47 [karl]
- \o/ yeah!
- 08:54:02 [TabAtkins]
- astearns: And I think we have a general agreement ot specify text-size-adjust. Objedtions?
- 08:54:12 [TabAtkins]
- RESOLVED: Specify text-size-adjust more fully.
- 09:04:33 [drousso]
- drousso has joined #css
- 09:17:08 [dauwhe]
- dauwhe has joined #css
- 09:31:13 [drousso]
- drousso has joined #css
- 09:46:01 [skk]
- skk has joined #css
- 09:55:19 [dauwhe]
- dauwhe has joined #css
- 09:55:32 [projector]
- projector has joined #css
- 09:56:02 [Rossen]
- Rossen has joined #css
- 09:56:33 [shans]
- shans has joined #css
- 09:57:03 [sylvaing]
- sylvaing has joined #css
- 09:57:33 [leaverou]
- leaverou has joined #css
- 09:58:03 [plinss_]
- plinss_ has joined #css
- 10:14:39 [duga]
- duga has joined #css
- 10:16:11 [duga]
- duga has joined #css
- 10:24:28 [dauwhe]
- dauwhe has joined #css
- 10:51:09 [tantek]
- tantek has joined #css
- 11:16:26 [Zakim]
- Zakim has left #css
- 11:58:26 [dino]
- dino has joined #css
- 12:05:45 [karl]
- karl has joined #css
- 12:11:58 [xfq]
- xfq has joined #css
- 12:33:11 [flackr]
- flackr has joined #css
- 12:52:41 [futhark]
- futhark has joined #css
- 13:01:33 [mattwoodrow]
- mattwoodrow has joined #css
- 13:11:02 [innovati]
- innovati has joined #css
- 13:20:07 [myles]
- myles has joined #css
- 13:32:25 [birtles]
- birtles has joined #css
- 13:57:42 [futhark]
- futhark has joined #css
- 13:58:11 [drousso]
- drousso has joined #css
- 14:10:39 [innov4ti]
- innov4ti has joined #css
- 14:22:38 [dauwhe]
- dauwhe has joined #css
- 14:32:27 [futhark]
- futhark has joined #css
- 14:43:02 [lajava]
- lajava has joined #css
- 15:33:46 [foolip]
- こんにちは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 [foolip]
- fantasai florian TabAtkins ^
- 15:36:04 [foolip]
- Great, see you in the morning :)
- 15:45:30 [futhark]
- futhark has joined #css
- 16:23:05 [dgrogan]
- dgrogan has joined #css
- 16:28:22 [innovati]
- innovati has joined #css
- 18:42:09 [Savago]
- Savago has joined #css
- 19:37:54 [drousso]
- drousso has joined #css
- 19:39:23 [aja]
- aja has joined #css
- 20:23:22 [futhark]
- futhark has joined #css
- 20:59:24 [dino]
- dino has joined #css
- 21:16:18 [ericc]
- ericc has joined #css
- 21:20:15 [duga]
- duga has joined #css
- 21:22:12 [karl]
- karl has joined #css
- 21:22:57 [ericc]
- ericc has joined #css
- 21:52:26 [dauwhe]
- dauwhe has joined #css
- 21:53:12 [astearns]
- rrsagent, off
- 21:53:45 [dino]
- dino has joined #css
- 22:25:23 [mattwoodrow]
- mattwoodrow has joined #css
- 23:01:14 [SimonSapin]
- foolip: in what room is that?
- 23:11:05 [dauwhe]
- dauwhe has joined #css
- 23:11:54 [astearns]
- SimonSapin: we'll be in the CSS room (Navis-C)
- 23:12:38 [astearns]
- trackbot, start meeting
- 23:12:41 [trackbot]
- RRSAgent, make logs public
- 23:12:41 [Zakim]
- Zakim has joined #css
- 23:12:42 [trackbot]
- Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
- 23:12:42 [trackbot]
- Date: 16 September 2019
- 23:12:47 [astearns]
- rrsagent, this meeting spans midnight
- 23:33:36 [kzms2]
- kzms2 has joined #css
- 23:36:50 [karl]
- karl has joined #css
- 23:38:43 [ericc]
- ericc has joined #css
- 23:39:00 [drousso]
- drousso has joined #css
- 23:40:18 [skk]
- skk has joined #css
- 23:40:19 [anssik]
- anssik has joined #css
- 23:40:46 [dauwhe]
- dauwhe has joined #css
- 23:43:23 [birtles]
- birtles has joined #css
- 23:47:28 [drousso_]
- drousso_ has joined #css
- 23:47:34 [karl]
- karl has joined #css
- 23:48:33 [glenn]
- glenn has joined #css
- 23:49:31 [nmccully]
- nmccully has joined #css
- 23:51:11 [jihye]
- jihye has joined #css
- 23:59:37 [drousso]
- drousso has joined #css
- 00:03:26 [romain]
- romain has joined #css
- 00:03:28 [zcorpan]
- zcorpan has joined #css
- 00:03:50 [dino]
- dino has joined #css
- 00:04:24 [nigel]
- nigel has joined #css
- 00:04:26 [astearns]
- topic: testing
- 00:04:39 [aboxhall_]
- aboxhall_ has joined #css
- 00:04:39 [nigel]
- present+ Nigel_Megitt
- 00:05:05 [florian]
- present+ Florian Rivoal, Invited Expert
- 00:05:06 [stantonm]
- stantonm has joined #css
- 00:05:17 [astearns]
- presenting https://docs.google.com/presentation/d/1F1II3lx0krPBIqAzgU9YFIENC-UBEnZtN796hye_bWw/edit?usp=sharing
- 00:05:18 [zcorpan]
- present+
- 00:05:18 [birtles]
- scribenick: birtles
- 00:05:26 [zcorpan]
- present- Invited Expert
- 00:05:35 [mattwoodrow]
- mattwoodrow has joined #css
- 00:05:43 [oriol]
- present+
- 00:05:48 [astearns]
- +1 to wpt documentation improvements. It's much much better!
- 00:06:10 [florian]
- q+
- 00:06:20 [rachelandrew]
- present+ Rachel Andrew, Fronteers
- 00:06:23 [florian]
- q-
- 00:06:24 [AmeliaBR]
- AmeliaBR has joined #css
- 00:06:26 [xfq]
- xfq has joined #css
- 00:06:36 [xfq]
- present+
- 00:06:42 [fergal_daly]
- fergal_daly has joined #css
- 00:06:58 [TabAtkins]
- present+
- 00:07:06 [AmeliaBR]
- present+
- 00:08:01 [astearns]
- q+
- 00:08:15 [tantek]
- tantek has joined #css
- 00:08:23 [tantek]
- present+
- 00:08:23 [florian]
- q+
- 00:08:32 [duga]
- duga has joined #css
- 00:09:13 [astearns]
- ack fantasai
- 00:09:15 [emilio]
- q+
- 00:09:20 [smfr]
- smfr has joined #css
- 00:09:24 [SimonSapin]
- present+
- 00:09:24 [birtles]
- fantasai: thank you for updating the docs
- 00:09:27 [heycam]
- present+
- 00:09:28 [smfr]
- present+
- 00:09:28 [dbaron]
- present+
- 00:09:31 [smfr]
- q+
- 00:09:33 [majidvp]
- present+
- 00:09:42 [birtles]
- ... it's great to have everything up front
- 00:09:44 [iank_]
- present+
- 00:09:52 [birtles]
- ... it would be nice to have a navigation system like a tab bar or footer
- 00:09:57 [birtles]
- ... to connect them all
- 00:10:07 [birtles]
- ... it would be easier to get from wpt.fyi to the docs and back
- 00:10:20 [birtles]
- ... second comment: do we have any plans for testing printing? and paginated modes?
- 00:10:37 [rniwa]
- rniwa has joined #css
- 00:10:53 [futhark]
- futhark has joined #css
- 00:11:04 [birtles]
- jgraham: we have talked about it a bit
- 00:11:07 [myles]
- myles has joined #css
- 00:11:07 [zcorpan]
- q?
- 00:11:20 [birtles]
- fantasai: do we have any way of helping people find and run and report results for manual tests
- 00:11:31 [birtles]
- ... there are some things that are not automated and are unlikely to be automated in the near future
- 00:11:42 [jgraham]
- jgraham has joined #css
- 00:11:43 [birtles]
- foolip: I know Florian does a lot of manual tests
- 00:11:48 [birtles]
- ... the answer is no
- 00:11:58 [birtles]
- ... there is a manual runner on w3test.org but it doesn't work so well
- 00:12:01 [CSSWG_LogBot]
- CSSWG_LogBot has joined #css
- 00:12:04 [birtles]
- ... and it doesn't report results in the right format
- 00:12:12 [birtles]
- ... there are not so many building blocks missing
- 00:12:26 [birtles]
- fantasai: that helps close the gaps for the types of the tests for which we don't have infrastructure
- 00:12:31 [birtles]
- ... e.g. printing and media queries
- 00:12:37 [birtles]
- ... I don't know how we'll test media queries
- 00:12:39 [jgraham]
- present+
- 00:12:45 [birtles]
- ... someone should run those
- 00:12:51 [birtles]
- ... e.g. plugging in a monitor
- 00:13:06 [birtles]
- ... if we only run it once, the data will be old
- 00:13:12 [birtles]
- ... we need to be able to run it more frequently
- 00:13:24 [birtles]
- foolip: would it be acceptable if you have to use wpt to run the test?
- 00:13:28 [birtles]
- ... locally wpt run
- 00:13:50 [birtles]
- ... ./wpt run --manual would be less work than a website approach
- 00:14:00 [birtles]
- fantasai: it would be nice if you can load the test on a website
- 00:14:14 [birtles]
- ... but the important thing would be to find the manual tests and then compile a result
- 00:14:26 [birtles]
- ... if you can accept data from Peter's system into wpt reporting system
- 00:14:29 [birtles]
- ... that might be a way
- 00:14:39 [birtles]
- foolip: just converting them would be straightforward I guess
- 00:14:48 [birtles]
- ... but do you want to keep maintaining that?
- 00:14:57 [birtles]
- plinss: I would be happy for it to be replaced
- 00:15:09 [birtles]
- ... once its functions are covered
- 00:15:22 [birtles]
- ... it tracks what git revision of each test is used
- 00:15:34 [birtles]
- jgraham: perhaps we can follow up later
- 00:16:13 [birtles]
- fantasai: minimum requirement is to get a list of manual tests then provide a report of results
- 00:16:26 [birtles]
- foolip: would it be fine to get all the manual tests in a specific directory?
- 00:16:33 [birtles]
- fantasai: yes
- 00:16:52 [birtles]
- florian: if the system is designed so that you have to run all of them, that wouldn't be so convenient
- 00:17:04 [birtles]
- ... there are thousands of tests in writing-modes for example
- 00:17:16 [birtles]
- foolip: if there's no subdirectories then we can maybe use chunking
- 00:17:26 [birtles]
- jgraham: the requirements to run this probably need to be considered in more depth
- 00:17:39 [birtles]
- ... there are data model considerations with regards to wpt.fyi
- 00:17:46 [birtles]
- ... there are lots of technical details
- 00:18:09 [astearns]
- q?
- 00:18:15 [birtles]
- florian: I think it helps breaking the problem down because eventually we want to replace and retire Peter's system
- 00:18:25 [birtles]
- ... even working out how to display manual tests is an interesting problem
- 00:18:30 [birtles]
- ... there might be conflicting reports
- 00:18:35 [karl]
- karl has joined #css
- 00:18:48 [birtles]
- ... using an existing data source and then working out how to display them later
- 00:18:58 [majidvp]
- q+ to discuss scrolling test automation
- 00:19:00 [birtles]
- astearns: we do need to work out how to fix this
- 00:19:00 [zcorpan]
- ack astearns
- 00:19:12 [birtles]
- astearns: I want to second the joy at the improved documentation
- 00:19:22 [birtles]
- ... I went through the docs to submit a reftest recently and everything was there
- 00:19:36 [birtles]
- ... when I submitted a PR, however, something broken and I didn't know what to do
- 00:19:52 [birtles]
- ... I could see the test results, I submitted another patch and it passed
- 00:19:59 [birtles]
- ... but I don't know how to fix it the first time
- 00:20:15 [birtles]
- ... the first two checks were red and I didn't know what to do about it
- 00:20:20 [birtles]
- ... I didn't want to bother anytone
- 00:20:26 [birtles]
- s/anytone/anyone/
- 00:20:31 [birtles]
- foolip: please bother us
- 00:20:35 [birtles]
- ... we need to fix this
- 00:20:48 [birtles]
- jgraham: some of this have failed for reasons out of our control
- 00:20:52 [birtles]
- ... e.g. GitHub actions being beta
- 00:21:05 [birtles]
- ... sometimes it takes quite a bit of experience to work out what went wrong
- 00:21:14 [foolip]
- q?
- 00:21:22 [birtles]
- ... there are infrastructure problems but there are also things we can do better
- 00:21:35 [birtles]
- dbaron: is pinging you on #testing the way to reach you?
- 00:21:37 [birtles]
- jgraham: yes
- 00:21:42 [birtles]
- foolip: or on the PR
- 00:21:57 [birtles]
- jgraham: IRC is generally more likely to get attention
- 00:22:06 [birtles]
- ... can get lots on GitHub email
- 00:22:16 [birtles]
- zcorpan: it depends a bit on what it is
- 00:22:24 [birtles]
- ... if it's something you see repeatedly
- 00:22:30 [birtles]
- ... it might be a system bug we need to fix
- 00:22:37 [birtles]
- ... otherwise ping one of us on the PR / IRC
- 00:22:41 [astearns]
- ack florian
- 00:22:58 [birtles]
- florian: in addition to the manual testing, we need 2 more things to retire Peter's tool
- 00:23:07 [birtles]
- ... one is MUST tests vs SHOULD/MAY
- 00:23:14 [birtles]
- ... important for exiting CR
- 00:23:26 [birtles]
- ... the other is that wpt.fyi groups report by directory
- 00:23:39 [fremy]
- fremy has joined #css
- 00:23:39 [birtles]
- ... but using the metadata pulling results by spec not directory would be helpful
- 00:23:46 [birtles]
- ... then we can retire Peter's tool
- 00:23:55 [birtles]
- jgraham: we are working on associating labels with tests
- 00:24:00 [birtles]
- ... I think that would cover these cases
- 00:24:08 [xiaochengh]
- xiaochengh has joined #css
- 00:24:12 [birtles]
- ... if you want that information to be in the test files rather than in metadata
- 00:24:18 [birtles]
- ... then you could have a bot to check they are in sync
- 00:24:31 [birtles]
- florian: currently that data is in the data, the flags meta
- 00:24:37 [birtles]
- ... so we need to sync that with labels
- 00:24:47 [birtles]
- jgraham: that labelling system is quite limited but it is being worked on
- 00:24:56 [birtles]
- ... we could have a script to check they are synced
- 00:25:17 [birtles]
- foolip: if you can search for not labeled tests is that fine?
- 00:25:29 [zcorpan]
- q?
- 00:25:29 [birtles]
- florian: if there is a button to click that's better, but as long as it's do-able
- 00:25:38 [birtles]
- ... one more question about fuzzy tests
- 00:25:40 [astearns]
- zakim, close queue
- 00:25:40 [Zakim]
- ok, astearns, the speaker queue is closed
- 00:26:00 [birtles]
- ... for non-fuzzy reftests we often have problems where one side is don't with Ahem and one is not
- 00:26:12 [birtles]
- ... but the box is quite large...
- 00:26:20 [birtles]
- ... is that covered by fuzzy
- 00:26:36 [birtles]
- jgraham: there are two parameters in fuzzy reftests -- one is the total number of pixels you allow to difffer
- 00:26:46 [birtles]
- ... one is the amount of you allow in difference per color channel
- 00:27:04 [birtles]
- ... so in this case you would allow a very small range in difference per color channel
- 00:27:25 [birtles]
- ... 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_]
- Rossen_ has joined #css
- 00:27:55 [birtles]
- ... 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 [birtles]
- ... e.g. we know our form controls differ
- 00:28:06 [Rossen_]
- present+
- 00:28:20 [birtles]
- florian: for the color channel parameter, it sounds like what I want to do
- 00:28:27 [birtles]
- ... but getting the right numbers might be difficult
- 00:28:39 [birtles]
- ... if we can find a way to make that easier that would be good
- 00:28:45 [birtles]
- jgraham: the screenshot tool could do that
- 00:29:02 [birtles]
- dbaron: the gecko reftest failure tells you that -- the failure range
- 00:29:14 [birtles]
- ... makes it easy to know what numbers to use
- 00:29:37 [birtles]
- AmeliaBR: for SVG I have been planning to work around this for SVG reftests
- 00:29:44 [skk]
- present+
- 00:29:50 [birtles]
- ... by adding a stroke overline to cover the anti-aliased part
- 00:29:57 [birtles]
- ... not the ideal solution
- 00:30:14 [birtles]
- ... but you can block off the regions where you don't care about differences
- 00:30:23 [astearns]
- ack emilio
- 00:30:28 [birtles]
- emilio: thank you for all your work
- 00:30:50 [birtles]
- ... the tests that keep going to Gecko's internal test suite are crashtests
- 00:31:06 [birtles]
- ... is there any way we can convert them to wpt in the future
- 00:31:24 [birtles]
- jgraham: I think for crashtests the thinking is that it's normally a very browser-specific thing
- 00:31:31 [birtles]
- ... there might be cases where that's not true
- 00:31:38 [bkardell_]
- bkardell_ has joined #css
- 00:31:39 [birtles]
- ... if we think it's worth doing it's quite do-able
- 00:31:56 [birtles]
- emilio: I can try to see how many of the Gecko crashtests affect other browsers
- 00:32:23 [astearns]
- ack smfr
- 00:32:26 [birtles]
- smfr: thanks for all your hard work
- 00:32:36 [birtles]
- ... getting Safari's stuff working right is great
- 00:32:54 [birtles]
- ... 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 [birtles]
- foolip: if it fails in the middle we don't get results...
- 00:33:19 [inamori_]
- inamori_ has joined #css
- 00:33:34 [birtles]
- smfr: I'm interested in cases where a test doesn't not run... it should show up as a fail
- 00:33:46 [birtles]
- foolip: a missing test is better than a fail
- 00:33:59 [birtles]
- smfr: just following up on AmeliaBR's point
- 00:34:07 [karl]
- karl has joined #css
- 00:34:07 [birtles]
- ... sometimes there are differences we don't care about
- 00:34:18 [birtles]
- ... a number is not sufficient, sometimes you want to obscure the irrelevant part
- 00:34:35 [birtles]
- jgraham: the fuzzy thing is a useful thing, it works in Gecko
- 00:34:53 [birtles]
- ... and when running it locally it will spit out the numbers you need to annotate them
- 00:35:11 [birtles]
- dbaron: the fuzzy number notation is very useful when they are exact numbers
- 00:35:25 [birtles]
- ... since if you get any other kind of number you get an unexpected pass
- 00:35:29 [astearns]
- ack majidvp
- 00:35:29 [Zakim]
- majidvp, you wanted to discuss scrolling test automation
- 00:35:36 [birtles]
- majidvp: thank you for adding testdriver annotation
- 00:35:50 [birtles]
- ... for writing scrolling tests, we often need to inject input
- 00:35:51 [AmeliaBR]
- s/we don't care about/we do care about in a test with fuzzy parts/
- 00:36:16 [birtles]
- ... you support pointer actions, what about mouse
- 00:36:29 [birtles]
- foolip: if pointer actions supports it we can do it
- 00:36:47 [birtles]
- jgraham: if it's not in webdriver we can add a feature request for that
- 00:36:59 [birtles]
- topic: Timed Text
- 00:37:50 [birtles]
- nigel: Hi, I'm Nigeal
- 00:37:56 [birtles]
- s/Nigeal/Nigel/
- 00:38:07 [birtles]
- ... part of this group and the timed text group
- 00:38:34 [birtles]
- ... there are other members of the timed text group here
- 00:38:40 [florian]
- https://github.com/w3c/ttwg/issues/52
- 00:38:46 [nigel]
- -> https://github.com/w3c/ttwg/issues/52 Joint TTWG/CSS isses
- 00:38:49 [nigel]
- s/isses/issues
- 00:40:07 [birtles]
- nigel: I want to go through the issues in the order they're listed
- 00:40:43 [futhark]
- futhark has joined #css
- 00:41:53 [nigel]
- Topic: Supporting "not within an EM" at text-combine-upright and tts:textCombine for 縦中横 'tate-chu-yoko'
- 00:42:23 [nigel]
- -> https://github.com/w3c/tt-module-cjk-ext-1/issues/1
- 00:42:37 [zcorpan]
- zcorpan has joined #css
- 00:42:47 [smfr]
- smfr has joined #css
- 00:42:50 [birtles]
- ... This is about text-combine-upright, tatechuuyoko / 縦中横
- 00:42:52 [pal]
- pal has joined #css
- 00:43:02 [birtles]
- ... the request was to say not to put it in 1em
- 00:43:02 [zcorpan]
- zcorpan has joined #css
- 00:43:07 [birtles]
- ... to take up more than 1em
- 00:43:23 [koji]
- q+
- 00:43:34 [birtles]
- nmccully: the normal way of spacing these characters is that the first two kanji should be flush
- 00:43:47 [astearns]
- zakim, open queue
- 00:43:47 [Zakim]
- ok, astearns, the speaker queue is open
- 00:43:52 [astearns]
- q+ koji
- 00:44:00 [gkatsev]
- gkatsev has joined #css
- 00:44:02 [Rossen_]
- q?
- 00:44:14 [birtles]
- ... 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 [birtles]
- ... then the line won't be any further away than it is
- 00:44:34 [birtles]
- ...the other way is to scale the glyphs
- 00:44:54 [birtles]
- koji: this feature is being considered in writing modes level 3
- 00:44:56 [astearns]
- ack koji
- 00:45:05 [fantasai]
- 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 [birtles]
- ... but we didn't include it because it makes it more complicated particularly when ruby is included
- 00:45:18 [birtles]
- ... it complicates the spec and it's not clear how it should work
- 00:45:28 [birtles]
- ... and the author can work around using inline blocks
- 00:45:50 [birtles]
- ... the layout is slightly different from the optimized text-combine-upright but it's almost the same using an alternate flow
- 00:46:09 [birtles]
- nmccully: this is a common thing though so to reject it for the case of decoration being difficult
- 00:46:18 [birtles]
- ... makes it difficult for the 80~90% case
- 00:46:25 [birtles]
- ... by requiring authors to do a workaround
- 00:46:33 [birtles]
- ... it seems like a lot to ask for the non-decorated case
- 00:46:43 [birtles]
- myles: ruby has this concept over overhang too
- 00:46:48 [dbaron]
- I'd note 民國108年 is a good real example (and common in Taiwan) for the 3-digit case.
- 00:46:49 [birtles]
- ... and that's not controllable by css
- 00:46:58 [birtles]
- ... is this a similar thing that the browser should just do?
- 00:47:16 [birtles]
- fantasai: it's not a new CSS property, it's just a different way of doing text-combine
- 00:47:34 [birtles]
- florian: is this an author choice? Or the browser does the right thing thing?
- 00:47:37 [birtles]
- fantasai: an author choice
- 00:47:54 [birtles]
- AmeliaBR: the current spec gives a limit for how many characters to compress
- 00:48:06 [birtles]
- glenn: the question was "how does the author express a preference"?
- 00:48:19 [birtles]
- koji: they can use a line block to do this
- 00:48:21 [AmeliaBR]
- s/to compress/but then beyond that it goes to vertical, not horizontal overflow/
- 00:48:38 [birtles]
- nmccully: can you still get the same width of the line block doing that?
- 00:48:46 [AmeliaBR]
- 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 [birtles]
- ... or will there be some small space that messes up the layout?
- 00:49:17 [birtles]
- stantonm: there are two ways you could do it.. you could compress the font size
- 00:49:32 [xiaochengh]
- xiaochengh has joined #css
- 00:49:33 [birtles]
- myles: my question is this additive or a bug we're fixing?
- 00:49:47 [birtles]
- nmccully: the scaling is a less desired behavior from a typographer's point of view
- 00:49:55 [birtles]
- ... we've also tried to work out what the default should be
- 00:49:58 [fantasai]
- testcase:
- 00:49:58 [fantasai]
- 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 [birtles]
- ... most of the time you see this in dates
- 00:50:10 [birtles]
- ... and dates often use scaled glyphs
- 00:50:31 [birtles]
- ... 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 [fantasai]
- updated testcase:
- 00:50:44 [fantasai]
- 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 [birtles]
- ... for the Web the preference you currently have--biasing to make everything fit--it fine
- 00:51:01 [birtles]
- ... overhang is more of a print thing
- 00:51:17 [nigel]
- q?
- 00:51:44 [birtles]
- AmeliaBR: this suggested layout is going to affect your line-spacing?
- 00:52:31 [birtles]
- 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 [birtles]
- nmccully: so this shows it is possible in the browser
- 00:52:48 [birtles]
- florian: this example doesn't show where ruby goes
- 00:53:06 [birtles]
- pal: not scaling is very common practice
- 00:53:16 [birtles]
- ... in 100% of Japanese subtitles it doesn't scale
- 00:53:45 [birtles]
- 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 [birtles]
- koji: this is not too rare in publishing
- 00:53:56 [smfr]
- smfr has joined #css
- 00:54:00 [birtles]
- ... compression doesn't give good glyph shapes
- 00:54:05 [birtles]
- ... some authors prefer not to compress
- 00:54:11 [birtles]
- ... in a single page, authors don't compress
- 00:54:11 [dbaron]
- I wonder if that underline behavior is just the result of text-decoration-skip-inc
- 00:54:19 [dbaron]
- -ink
- 00:54:23 [birtles]
- ... but when the text has ruby or decorations, that do compress
- 00:54:34 [heycam]
- 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 [birtles]
- ... if they don't have decorations, they use inline-block, otherwise they use text-combine
- 00:54:52 [birtles]
- pal: I'd like an action item / next steps
- 00:55:00 [birtles]
- AmeliaBR: file an issue on the CSS repo
- 00:55:09 [birtles]
- fantasai: advanced writing modes level 4
- 00:55:23 [florian]
- s/advanced/against/
- 00:55:48 [birtles]
- nigel: also an action to go back to reporter and suggest the best practice we discussed
- 00:56:14 [fremy]
- fremy has joined #css
- 00:56:17 [birtles]
- pal: text combine covers 0% of use cases within the domain of subtitling
- 00:56:49 [birtles]
- 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]
- plh has joined #css
- 00:57:05 [nigel]
- rrsagent, pointer
- 00:57:05 [RRSAgent]
- See https://www.w3.org/2019/09/15-css-irc#T00-57-05
- 00:57:17 [birtles]
- AmeliaBR: if you can get pictures of actual typography that does those things, that would be wonderful
- 00:57:31 [birtles]
- pal: so ruby, emphasis on both sides
- 00:57:37 [birtles]
- florian: maybe background colors
- 00:57:49 [birtles]
- iank_: does it contribute to the scrollable overflow?
- 00:58:19 [birtles]
- myles: I think CSS should have facilities for this
- 00:58:30 [inamori_]
- inamori_ has joined #css
- 00:58:41 [birtles]
- nigel: moving on to issue 2983
- 00:58:47 [AmeliaBR]
- Agree that the basic feature request, for a new text-combine-upright value for a common typographic pattern, is strong
- 00:59:02 [fantasai]
- github:
- 00:59:04 [fantasai]
- github: https://github.com/w3c/csswg-drafts/issues/2983
- 00:59:05 [birtles]
- ... this is about CJK and supporting shearing
- 00:59:05 [nigel]
- github: https://github.com/w3c/csswg-drafts/issues/2983
- 00:59:16 [fantasai]
- github: none
- 00:59:22 [fantasai]
- Topic: Shearing Vertical Text
- 00:59:25 [fantasai]
- github: https://github.com/w3c/csswg-drafts/issues/2983
- 01:00:08 [bobbytung]
- bobbytung has joined #css
- 01:00:14 [birtles]
- pal: today there's the ability to specify slant on individual characters using oblique
- 01:00:16 [birtles]
- ... or italic
- 01:00:33 [birtles]
- ... sometimes it's useful to apply shear not on character-by-character but entire line
- 01:00:45 [birtles]
- ... that's desirable to apply alignment between ruby and base text
- 01:00:52 [birtles]
- ... it's subtle but really matters to folks that care
- 01:01:17 [birtles]
- ... separate issue about whether or not we should be able to specify the angle of shear per-character
- 01:01:25 [birtles]
- ... issue here is applying by the whole line
- 01:01:29 [karl]
- karl has joined #css
- 01:01:48 [birtles]
- nmccully: in print, it's not keeping the height/width of the line when you shear it
- 01:02:04 [birtles]
- ... you change the shape of the box of each character to a diamond
- 01:02:08 [birtles]
- ... it's call shatai in Japanese
- 01:02:14 [myles]
- https://helpx.adobe.com/ch_fr/indesign/using/formatting-cjk-characters.html
- 01:02:18 [myles]
- this is what Nat is talking about
- 01:02:20 [birtles]
- ... in subtitles has it become just a shear?
- 01:02:31 [birtles]
- pal: it seems to be just a one-dimensional thing in subtitles
- 01:02:45 [birtles]
- ... not sure if it's an artistic desire or technical limitation
- 01:02:52 [birtles]
- koji: the difference here is a position of the ruby, right?
- 01:02:55 [birtles]
- pal: yes
- 01:03:17 [birtles]
- koji: I'm not sure about this use case, but for me changing the position of the ruby looks to me
- 01:03:30 [birtles]
- ... shearing the individual characters looks better to me
- 01:03:50 [birtles]
- pal: on the thread some others seem to prefer shearing the whole line
- 01:04:05 [birtles]
- fantasai: for print we know they want the per-character approach
- 01:05:15 [jcraig]
- jcraig has joined #css
- 01:05:22 [birtles]
- ... so I suggest we propose that and take that to the subtitle group and see if that is acceptable
- 01:05:40 [birtles]
- ... it's possible that the request here for shearing the whole inline-block is just coming from technical limitations
- 01:05:55 [birtles]
- pal: I like the idea of going back and asking questions
- 01:06:17 [birtles]
- ... but the issue opened against ttml was specifically about not being able to shear the whole block
- 01:06:33 [birtles]
- fantasai: I thought the problem was that italics shears in the wrong direction
- 01:06:55 [birtles]
- koji: can you point to specific individual / issue so I can follow up
- 01:06:59 [florian]
- q+
- 01:07:10 [birtles]
- koji: I can't see any ruby in that issue
- 01:07:12 [fremy]
- fremy has joined #css
- 01:07:16 [Rossen__]
- Rossen__ has joined #css
- 01:07:16 [Rossen__]
- https://w3c.github.io/ttml2/index.html#style-attribute-shear
- 01:07:22 [HeWenli]
- HeWenli has joined #css
- 01:07:36 [AmeliaBR]
- text-combine-upright does look bad with individual character shear: https://github.com/w3c/ttml2/issues/784#issuecomment-390856934
- 01:07:48 [fantasai]
- https://github.com/w3c/ttml2/issues/784
- 01:07:49 [birtles]
- florian: you said we want to shear the entire line OR paragraph
- 01:07:53 [birtles]
- ... these are two things
- 01:08:05 [birtles]
- ... for the second option, CSS transforms will do it
- 01:08:17 [birtles]
- pal: ttml can do all three: character, line, paragraph
- 01:08:39 [birtles]
- florian: the difference with ruby is more subtle
- 01:08:50 [birtles]
- ... but the text combine upright case is more obviously different
- 01:09:06 [birtles]
- pal: the issue in 2983 shows a good example
- 01:10:02 [birtles]
- ... 2983 ends with a question I asked
- 01:10:23 [birtles]
- myles: any proposal for how the author would describe to the browser the effect they desire
- 01:10:29 [birtles]
- pal: yes there is a proposal there
- 01:10:34 [birtles]
- myles: so a new property?
- 01:10:49 [birtles]
- ... has anyone considered re-purposing the new syntax for font-style to describe the shearing?
- 01:10:55 [birtles]
- glenn: no I have not
- 01:11:26 [birtles]
- ... we introduced three new properties: shear (block), line-shear (per-line including tatechuuyoko), font-shear (glyph box by glyph box)
- 01:11:44 [birtles]
- myles: one option would be to have font-style: oblique -14deg does shear
- 01:11:53 [birtles]
- ... and if it looks bad it's a browser bug
- 01:12:08 [birtles]
- fantasai: I don't think it will look good if there is latin text involved
- 01:12:17 [birtles]
- myles: there's an issue in the agenda for that later today
- 01:12:33 [birtles]
- fantasai: I don't think we can mix this with the oblique/italic feature
- 01:13:16 [birtles]
- 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 [birtles]
- ... 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 [birtles]
- koji: I agree with myles and don't understand why specifying an angle doesn't work
- 01:14:10 [birtles]
- ???: because the fonts
- 01:14:17 [birtles]
- koji: what exactly doesn't work?
- 01:14:31 [birtles]
- myles: my proposal is that the font-style property does more than just font selection
- 01:14:41 [birtles]
- ... it does font selection as it does today and also does the transform as necessary
- 01:14:57 [birtles]
- pal: the way this was explained to me is that the desired effect was literally just shearing
- 01:15:14 [birtles]
- koji: we understand, but the point is there are other glyph shearing use cases
- 01:15:18 [birtles]
- ... that is what myles is proposing
- 01:15:42 [birtles]
- pal: we need to understand three distinct use cases: per block, per line, per character
- 01:15:51 [nigel]
- s/???: because the fonts/nigel: you're asking a lot of the implementation and reducing authoring flexibility
- 01:16:06 [birtles]
- koji: we have per block already, myles is proposing per-character
- 01:16:17 [birtles]
- ... we are wondering what is needed for line shearing
- 01:16:39 [birtles]
- fantasai: this example on the screen shows why we can't cover the line case with the same per-glyph approach
- 01:16:59 [birtles]
- ... the characters all shear in different directions when using font-style: oblique
- 01:17:13 [birtles]
- (example includes mixed CJK and vertical and horizontal latin)
- 01:17:20 [birtles]
- myles: yes, we want to discuss this later today
- 01:17:27 [jgraham]
- jgraham has left #css
- 01:17:29 [AmeliaBR]
- +1 for keeping this logically separate; too confusing when mixing latin and upright scripts
- 01:17:53 [birtles]
- nigel: I think we've understood the use case better, any proposal action?
- 01:18:06 [birtles]
- fantasai: CSS definitely needs to solve the per-character shearing
- 01:18:11 [birtles]
- ... block shearing is solved
- 01:18:31 [birtles]
- ... open question about if more is needed for line-shearing
- 01:18:47 [birtles]
- pal: for block shearing, transform shears the background too. Is that ok?
- 01:18:54 [birtles]
- AmeliaBR: you need a wrapper element if you want to avoid that
- 01:19:31 [birtles]
- pal: does the size change too for the block too?
- 01:19:41 [birtles]
- ... it doesn't so it extends beyond the background
- 01:19:59 [birtles]
- ... any chance of a shear property that affects block size?
- 01:20:04 [birtles]
- myles: transforms that affect layout?
- 01:20:05 [birtles]
- pal: yes
- 01:20:19 [birtles]
- AmeliaBR: it could be a dedicated block shear property
- 01:20:30 [futhark]
- futhark has joined #css
- 01:20:35 [birtles]
- florian: the general solution for transforms that affect layout is hard
- 01:20:43 [birtles]
- ... a limited use case could be ok
- 01:20:50 [fremy]
- fremy has joined #css
- 01:20:54 [birtles]
- pal: just reacting to the idea that block shearing is solved
- 01:21:29 [birtles]
- Topic: Aligning an aligned block of text within its container
- 01:21:38 [birtles]
- https://github.com/w3c/csswg-drafts/issues/1975
- 01:21:39 [fantasai]
- github: https://github.com/w3c/csswg-drafts/issues/1975
- 01:21:42 [futhark_]
- futhark_ has joined #css
- 01:21:42 [rniwa]
- rniwa has joined #css
- 01:21:53 [birtles]
- nigel: action was with us to check that the draft spec text was ok
- 01:21:58 [AmeliaBR]
- draft spec: https://drafts.csswg.org/css-text-4/#text-group-align-property
- 01:22:06 [birtles]
- pal: I haven't had a chance to look. What's the right way to test it?
- 01:22:14 [birtles]
- nigel: there's draft spec, but no tests
- 01:22:16 [duga]
- duga has joined #css
- 01:22:34 [birtles]
- ... what is the best thing is to do to create those tests
- 01:22:47 [birtles]
- ... we don't have any perspective on implementation
- 01:22:50 [birtles]
- florian: it's not implemented
- 01:23:27 [birtles]
- fantasai: to get it implemented, write tests, convince browsers to implement it, hire Igalia, implement it yourself
- 01:23:50 [birtles]
- florian: as far as the WG is concerned, if the spec is done, there's not much more we can do
- 01:23:56 [birtles]
- AmeliaBR: it would be great to have pictures in the spec
- 01:24:09 [birtles]
- ... if you are keen on the feature, adding pictures and use cases would help
- 01:24:28 [birtles]
- pal: so create a new PR with examples?
- 01:24:31 [birtles]
- all: yes
- 01:25:07 [kurosawa]
- kurosawa has joined #css
- 01:25:29 [birtles]
- topic: Images with layout information
- 01:25:39 [birtles]
- github: https://github.com/w3c/csswg-drafts/issues/4116
- 01:25:55 [birtles]
- myles: when we discussed this, we talked about annotating images with baseline information
- 01:26:02 [birtles]
- ... is there an image format for subtitles?
- 01:26:10 [birtles]
- nigel: same image format as elsewhere
- 01:26:25 [birtles]
- topic: create a display property value for visually hiding an element while making it available for AT
- 01:26:32 [birtles]
- github: https://github.com/w3c/csswg-drafts/issues/560
- 01:26:40 [birtles]
- nigel: this comes up a lot in subtitles and captions
- 01:26:55 [birtles]
- ... the desire to be able to make text available to the screenreader while not visually displaying it
- 01:27:17 [birtles]
- ... this is particularly important for subtitles because there is a video behind it which might be showing text, for example
- 01:27:32 [birtles]
- ... so we don't need a subtitle necessarily but we want to expose it to a screenreader
- 01:27:42 [birtles]
- ... there are hacks to do this
- 01:27:53 [birtles]
- ... perhaps a display property value
- 01:27:59 [birtles]
- fantasai: this exists in the speech module level 1
- 01:28:03 [birtles]
- ... property is speak
- 01:28:13 [birtles]
- ... initial is 'auto' which defers to display
- 01:28:29 [birtles]
- ... but not implemented it
- 01:28:33 [futhark]
- futhark has joined #css
- 01:28:36 [birtles]
- ... 'never' and 'always'
- 01:28:48 [birtles]
- AmeliaBR: display: none has so many other affects other than just hiding
- 01:29:01 [birtles]
- fantasai: we have a spec but no one is interested in implementing it
- 01:29:09 [birtles]
- nigel: the request is not to speak it
- 01:29:14 [birtles]
- ... it is to make it visible to the screenreader
- 01:29:23 [birtles]
- ... it might be presenting it in some other way
- 01:29:28 [birtles]
- AmeliaBR: braille display etc.
- 01:29:51 [birtles]
- Rossen__: you can use visibility: hidden
- 01:29:59 [birtles]
- ... and refer to it via aria-description etc.
- 01:30:05 [birtles]
- AmeliaBR: as the label of a different element
- 01:30:23 [birtles]
- nigel: if you're just labeling an element then the screenreader might just read that once
- 01:30:32 [birtles]
- ... but this is an element whose contents is live
- 01:30:36 [birtles]
- ... it needs to read it when it changes
- 01:30:52 [bobbytung]
- bobbytung has joined #css
- 01:31:00 [birtles]
- AmeliaBR: there are many demands this feature beyond the captioning use case
- 01:31:11 [birtles]
- ... I'm sure the accessibility people who come in after the break would be happy to talk about it
- 01:31:26 [birtles]
- nigel: perhaps we can cover it in that session
- 01:31:40 [futhark_]
- futhark_ has joined #css
- 01:32:18 [birtles]
- github: end topic
- 01:32:23 [birtles]
- github-bot: end topic
- 01:38:18 [mattwoodrow]
- mattwoodrow has joined #css
- 01:39:00 [bobbytung]
- bobbytung has joined #css
- 01:41:19 [smfr]
- smfr has joined #css
- 01:43:22 [drousso]
- drousso has joined #css
- 01:50:57 [kurosawa]
- kurosawa has joined #css
- 01:56:46 [IanPouncey]
- IanPouncey has joined #css
- 01:59:18 [romain]
- romain has joined #css
- 01:59:26 [Rossen__]
- Rossen__ has joined #css
- 02:01:27 [inamori_]
- inamori_ has joined #css
- 02:01:33 [leaverou_]
- leaverou_ has joined #css
- 02:01:55 [tink]
- tink has joined #css
- 02:02:00 [duga]
- duga has joined #css
- 02:02:14 [tink]
- present+ Léonie (tink)
- 02:02:26 [futhark]
- futhark has joined #css
- 02:02:51 [futhark]
- futhark has joined #css
- 02:03:02 [zcorpan]
- zcorpan has joined #css
- 02:05:08 [ZoeBijl]
- present+
- 02:06:06 [xfq]
- xfq has joined #css
- 02:06:38 [dauwhe_]
- dauwhe_ has joined #css
- 02:07:10 [ZoeBijl]
- present+ mck
- 02:07:37 [pal]
- pal has joined #css
- 02:07:41 [dauwhe_]
- present+
- 02:07:49 [bkardell_]
- present +
- 02:08:08 [jamesn]
- jamesn has joined #css
- 02:08:31 [Roy]
- Roy has joined #css
- 02:09:00 [IanPouncey]
- present+
- 02:09:12 [stantonm]
- stantonm has joined #css
- 02:09:59 [inamori_]
- inamori_ has joined #css
- 02:10:21 [fantasai]
- ScribeNick: fantasai
- 02:10:30 [fantasai]
- Topic: Accessibility-CSS Joint Meeting
- 02:10:37 [mhakkinen_]
- mhakkinen_ has joined #css
- 02:10:46 [Irfan]
- Irfan has joined #css
- 02:11:05 [achraf]
- achraf has joined #css
- 02:11:13 [Irfan]
- present+
- 02:11:16 [achraf]
- present+
- 02:11:29 [dlibby_]
- dlibby_ has joined #css
- 02:11:30 [bobbytung]
- bobbytung has joined #css
- 02:11:35 [fantasai]
- Janina: FYI but need support from CSS
- 02:11:45 [Matt_King_]
- Matt_King_ has joined #css
- 02:11:47 [fantasai]
- Janina: We have a lto of user requirements about using better for user style sheet things
- 02:11:59 [fantasai]
- Janina: Controlling animations was a need, can do , wasn't aware but that's great
- 02:11:59 [chrishall]
- chrishall has joined #css
- 02:12:09 [fantasai]
- Janina: But need to be able to control spacing between words and between punctuation
- 02:12:16 [fantasai]
- Janina: Can be done on user side, I believe?
- 02:12:25 [fantasai]
- Janina: Seems youhave to be an expert user, invoke the htings
- 02:12:39 [fantasai]
- Janina: Make that more usable, would appreciate CSSWG support on that
- 02:12:49 [fantasai]
- Janina: WCAG guidelines are quite regulatory
- 02:13:00 [fantasai]
- Janina: help to get technological solutions sorted
- 02:13:06 [fantasai]
- Janina: and built into browsers
- 02:13:19 [aboxhall_]
- present+
- 02:13:21 [AmeliaBR]
- (Better browser support for user style overrides would be wonderful, but yes, probably outside of our realm to specify.)
- 02:13:26 [fantasai]
- Janina: Cognitive and learnign disabilitys and low-vision requirements
- 02:13:35 [fantasai]
- Janina: Would it be reasonable to control flashing?
- 02:13:42 [Roy]
- present+
- 02:13:45 [fantasai]
- florian: There was a long list of things you might want to control in your requirements
- 02:13:56 [fantasai]
- florian: not sure we have solution for every single one, but many are things that authors can control
- 02:14:01 [fantasai]
- florian: and we do have notion of user style sheets
- 02:14:02 [joanie]
- joanie has joined #css
- 02:14:11 [fantasai]
- florian: this is a notion, doesn't have to be a style sheet written in CSS by programmers
- 02:14:22 [fantasai]
- florian: perfectly OK for User Agent to have a UI that sets these rules
- 02:14:29 [jemma]
- jemma has joined #css
- 02:14:30 [jcraig]
- q+
- 02:14:32 [fantasai]
- florian: cascade then says how the user prefs and author prefs interact
- 02:14:38 [jcraig]
- ack fl
- 02:14:43 [fantasai]
- florian: but usability of making settings is a UA issue
- 02:15:01 [fantasai]
- jcraig: For motion, have prefers-reduced-motion implemented across browses now
- 02:15:09 [fantasai]
- jcraig: media features and web pages can adapt to them
- 02:15:31 [fantasai]
- jcraig: that seems to be solved wrt CSSWG, but usabitiliy can improve
- 02:15:49 [fantasai]
- Janina: Audio, killing all sounds. Part of browser config
- 02:15:58 [fantasai]
- jcraig: want sounds on device but not pages?
- 02:16:06 [fantasai]
- janina: bubbling up out of ?
- 02:16:15 [fantasai]
- florian: we don't generate sounds in CSS generally, so don't have a way to turn off
- 02:16:19 [rniwa]
- rniwa has joined #css
- 02:16:26 [fantasai]
- myles: desktop browsers have ability to shut off sounds per tab
- 02:16:42 [fantasai]
- janina: spacing: interlinear, inter-word, punctuation
- 02:16:47 [fantasai]
- jcraig: letter-spacing available since CSS2.1
- 02:16:54 [astearns]
- s/?/COGA (cognitive)/
- 02:16:58 [fantasai]
- jcraig: not easy for users to define, but outside scope of CSSWG to solve
- 02:17:14 [fantasai]
- florian: spacing after punctuation specifically is not something we can control on author and user side
- 02:17:35 [fantasai]
- janina: request to have more space around punctuation
- 02:17:49 [tantek]
- sounds like a feature request
- 02:17:49 [dauwhe_]
- q+
- 02:18:12 [fantasai]
- fantasai: We do have word-spacing property, but nothing for spacing around punctuation
- 02:18:19 [fantasai]
- janina: can add?
- 02:18:25 [Rossen__]
- q?
- 02:18:35 [fantasai]
- 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 [fantasai]
- florian: spacing requirements are also quite dependent on language
- 02:19:01 [fantasai]
- florian: various conventions, requirements per language/writing-system
- 02:19:07 [fantasai]
- florian: so hard to make that work globally
- 02:19:43 [heycam]
- fantasai: that's language specific
- 02:20:03 [heycam]
- ... a lot of the learning dsiabilityies require -- I would require more spacing after phrases, or sentences, things that need linguistic analysis
- 02:20:08 [heycam]
- ... it's a bit difficult to solve on the CSS side
- 02:20:16 [jcraig]
- Myles mentioned text-spacing: punctuation
- 02:20:16 [heycam]
- ... but could be solved with CSS and a browwser extension maybe
- 02:20:28 [tantek]
- q?
- 02:20:29 [jcraig]
- ack jcr
- 02:20:38 [Jemma_]
- Jemma_ has joined #css
- 02:20:38 [fantasai]
- s/language specific/typographic mainly/
- 02:20:41 [astearns]
- ack dauwhe_
- 02:21:04 [smfr]
- smfr has joined #css
- 02:21:05 [fantasai]
- 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 [fantasai]
- Rossen__: We have one issue remaining from TTML
- 02:21:38 [fantasai]
- astearns: will cover after
- 02:21:52 [fantasai]
- janina: next issue, we agreed to do an Accessibility API Mappings with CSS
- 02:22:05 [dauwhe_]
- prince-text-replace: https://www.princexml.com/doc-refs/#prop-prince-text-replace
- 02:22:06 [fantasai]
- janina: some people volunteered to edit
- 02:22:08 [bobbytung]
- bobbytung has joined #css
- 02:22:13 [fantasai]
- janina: so will be sending a draft
- 02:22:31 [jcraig]
- Zoe Bijl and Joanie Diggs
- 02:22:32 [fantasai]
- janina: Joanie will bring a11y expertise
- 02:22:41 [fantasai]
- janina: Zoe will bring CSS knowledge
- 02:22:50 [fantasai]
- janina: Will specify how to standardize across OSes
- 02:22:59 [fantasai]
- janina: Unless questions about that, move on to next issues
- 02:23:32 [fantasai]
- jcraig: had issue about dynamic text size, which is CSS issue ??08
- 02:23:39 [fantasai]
- astearns: ok next issue...
- 02:23:47 [AmeliaBR]
- s/??08/3708/
- 02:23:50 [jcraig]
- issue-3708
- 02:23:50 [trackbot]
- Sorry, but issue-3708 does not exist.
- 02:23:50 [fantasai]
- Topic: Display property value for visually hiding element while making available to assistive tech
- 02:24:01 [fantasai]
- astearns: brought up by TTML also
- 02:24:18 [jcraig]
- https://github.com/w3c/csswg-drafts/issues/3708
- 02:24:24 [fantasai]
- astearns: question is how to move forward on this capability
- 02:24:29 [dino]
- dino has joined #css
- 02:24:30 [heycam]
- github: https://github.com/w3c/csswg-drafts/issues/3708
- 02:24:57 [fantasai]
- 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 [astearns]
- github: https://github.com/w3c/csswg-drafts/issues/560
- 02:25:06 [fantasai]
- AmeliaBR: or is text that is already obvious because of other visual cuse
- 02:25:08 [fantasai]
- s/cuse/cues/
- 02:25:19 [fantasai]
- AmeliaBR: so don't want to print the text, but want available to a11y
- 02:25:31 [fantasai]
- AmeliaBR: there are methods used by authors using absolute positioning or clip
- 02:25:47 [fantasai]
- AmeliaBR: intentionally picked by authors because not currently used as cues to screen readers to hide the text
- 02:25:53 [Jemma_]
- Jemma_ has left #css
- 02:25:54 [fantasai]
- AmeliaBR: so feature requests coming to ARIA and CSS
- 02:26:01 [fantasai]
- AmeliaBR: is to have a simple one property one attribute way to do this
- 02:26:07 [fantasai]
- AmeliaBR: there are ways in specs defined to do this
- 02:26:15 [jcraig]
- Example of what AmeliaBR is referencing: <p>Read <a href=“#”>more <span class=“a11y”>About widgets</span></a></p>
- 02:26:17 [fantasai]
- AmeliaBR: there's aria-hidden=false, originally specified to do this
- 02:26:25 [astearns]
- q?
- 02:26:26 [fantasai]
- AmeliaBR: there is the 'speak' property in CSS Speech module
- 02:26:34 [fantasai]
- https://www.w3.org/TR/css-speech/#speaking-props-speak
- 02:26:37 [jcraig]
- hidden=true aria-hidden=false
- 02:26:39 [leaverou]
- present+ leaverou
- 02:26:58 [fantasai]
- 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 [jcraig]
- aria-hidden=true was problematic for a variety of reasons
- 02:27:09 [fantasai]
- AmeliaBR: and saying 'display: none' or visually hidden but still available to AT
- 02:27:14 [fantasai]
- AmeliaBR: has never happened in borwsers
- 02:27:17 [jcraig]
- s/=true/=false/
- 02:27:19 [fantasai]
- AmeliaBR: so feature request is for specific way to do things
- 02:27:34 [fantasai]
- 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 [fantasai]
- AmeliaBR: visually-hidden styles can be misused by developers
- 02:27:53 [fantasai]
- AmeliaBR: who are only thinking about visually-able vs. blind users
- 02:28:03 [fantasai]
- AmeliaBR: missing a huge swath of people usign both AT and visual rendering
- 02:28:13 [fantasai]
- AmeliaBR: so argument that this is a hacky approach for a reason, shouldn't make it easier
- 02:28:26 [fantasai]
- AmeliaBR: but it is widely-used on the Web anyway, so argument for paving that cowpath
- 02:28:35 [fantasai]
- AmeliaBR: my recommendation is to go ahead with this
- 02:28:38 [fantasai]
- AmeliaBR: and do it in CSS
- 02:28:44 [fantasai]
- AmeliaBR: because sometimes visually-hidden content depends on MQ
- 02:28:49 [jcraig]
- q+ to remind the group that many (most?) screen reader users are not completely blind...
- 02:28:51 [fantasai]
- AmeliaBR: e.g. button might have icon and text on big screen
- 02:28:56 [fantasai]
- AmeliaBR: but on small screen only the icon
- 02:29:06 [fantasai]
- AmeliaBR: but want AT to be able to see that text
- 02:29:08 [florian]
- q+
- 02:29:13 [astearns]
- ack jcraig
- 02:29:14 [Zakim]
- jcraig, you wanted to remind the group that many (most?) screen reader users are not completely blind...
- 02:29:21 [fantasai]
- jcraig: I think this is valuable and needed
- 02:29:36 [fantasai]
- jcraig: but remind group that most screen reader users are not blind
- 02:29:46 [fantasai]
- jcraig: there are a lot of low-vision users
- 02:30:00 [fantasai]
- jcraig: ~ 1/5 are actually blind
- 02:30:12 [nigel]
- q+ to point out that for text to describe media content the solution has to work in an ARIA live context
- 02:30:17 [astearns]
- ack florian
- 02:30:21 [fantasai]
- astearns: Amelia's comment was that this is a bad assumption some authors make, shouldn't encourage
- 02:30:24 [tink]
- Q+
- 02:30:35 [fantasai]
- florian: the reason why neither ARIA attr or speak has been easy to implement
- 02:30:42 [fantasai]
- florian: is because AT works by reading plain text off the render tree
- 02:30:45 [fantasai]
- florian: this is the reality today
- 02:30:51 [fantasai]
- florian: can't ignore it
- 02:31:00 [fantasai]
- florian: but causes many problems
- 02:31:04 [fantasai]
- florian: exposing info to AT
- 02:31:11 [fantasai]
- florian: I hope this is merely current reality
- 02:31:16 [fantasai]
- florian: and not long-term goal we want to maintain
- 02:31:25 [fantasai]
- florian: because in that case many limitations
- 02:31:36 [fantasai]
- florian: there are many cases where we would want to work from DOM, not render tree
- 02:31:37 [r12a]
- r12a has joined #css
- 02:31:42 [fantasai]
- florian: because render tree has lost information that's in the DOM\
- 02:31:53 [fantasai]
- florian: I think we will see that problem in a number of use cases
- 02:32:12 [fantasai]
- florian: I would like us to not abandon idea that aria / display proposals
- 02:32:20 [astearns]
- ack nigel
- 02:32:20 [Zakim]
- 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 [fantasai]
- florian: I hope this is taken as a current situation, not a design goal, because otherwise many things cannot be solved
- 02:32:41 [fantasai]
- nigel: Some of the proposed solutions/hacks might not work for ARIA live environment
- 02:32:52 [fantasai]
- nigel: for ? put forward this morning, want something that describes content in a video
- 02:32:53 [jcraig]
- 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 [fantasai]
- nigel: gets read out during playback of video
- 02:33:02 [fantasai]
- nigel: want to use ARIA live region approach
- 02:33:05 [fantasai]
- nigel: and have AT notice that
- 02:33:13 [jcraig]
- s/live environment/live regions/
- 02:33:17 [florian]
- s$that aria / display proposals$that aria / speak proposals$
- 02:33:18 [fantasai]
- nigel: biggest gap we have is something that, following from florian's point, here is some text from render tree
- 02:33:25 [fantasai]
- nigel: don't actually paint pixesl for it, leave layout alone
- 02:33:36 [fantasai]
- nigel: atm visibility: hidden has effect that some screen readers don't read it out
- 02:33:42 [fantasai]
- nigel: I would separate visibilty from display
- 02:33:50 [fantasai]
- nigel: I would expect display: none to never feature in a display
- 02:33:55 [fantasai]
- nigel: but visibilty is not rich enough
- 02:34:14 [florian]
- fantasai: visibility hidden currently leave things in the layout tree
- 02:34:20 [florian]
- fantasai: so they take up space
- 02:34:27 [ZoeBijl]
- q+ to say that there are more assistive technologies than screen readers
- 02:34:29 [florian]
- fantasai: we probably want variant that doesn't
- 02:34:37 [fantasai]
- jcraig: technique used is positionign off-screen and clipping
- 02:34:42 [fantasai]
- nigel: want something more proper
- 02:34:43 [florian]
- s/variant/a variant/
- 02:34:44 [fantasai]
- astearns: and more simple
- 02:34:54 [astearns]
- ack tink
- 02:34:56 [fantasai]
- tink: I'm really strongly in favor of this proposal
- 02:35:03 [fantasai]
- tink: than existing methods, which cause alls orts of problems
- 02:35:17 [fantasai]
- tink: can confirm that visibility: hidden does get hidden from screen readers
- 02:35:26 [fantasai]
- tink: if we go ahead with an idea like this attribute
- 02:35:30 [fantasai]
- tink: what will we do with tab focus?
- 02:35:40 [fantasai]
- tink: techniqe that jcraig describes
- 02:35:46 [fantasai]
- tink: tab focus disappears off screen
- 02:35:55 [fantasai]
- tink: some renderers will screw up rendering as a result
- 02:36:01 [fantasai]
- tink: would there be some mechanism to get around that problem?
- 02:36:15 [fantasai]
- AmeliaBR: that's a very good argument for a proper bult-in feature
- 02:36:21 [fantasai]
- AmeliaBR: then browser knows to override hiding and make things visible
- 02:36:31 [fantasai]
- AmeliaBR: with current techniques, up to author to have a special focus rule
- 02:36:38 [fantasai]
- AmeliaBR: to handle that case
- 02:36:53 [fantasai]
- AmeliaBR: strong argument to have dedicated feature so browser knows why this style is being set, and to override
- 02:37:02 [fantasai]
- tink: so if was focusable content hidden, once it got focus would become visible
- 02:37:10 [fantasai]
- tink: makes visible, but if contents appear from off-screen, that would be quite disruptive
- 02:37:27 [fantasai]
- tink: is there a possibility to do it the other way around, take things outside of focusability?
- 02:37:32 [fantasai]
- AmeliaBR: that wouldn't help with skip links
- 02:37:45 [fantasai]
- tink: screenreaders have much better ways to navigate content
- 02:37:52 [fantasai]
- tink: skip links are mainly useful for sighted suers
- 02:37:58 [futhark]
- futhark has joined #css
- 02:38:02 [fantasai]
- s/sighted suers/sighted keyboard users/
- 02:38:08 [plh]
- plh has joined #css
- 02:38:11 [fantasai]
- florian: would be problem to make things visible without author expecting it
- 02:38:16 [fantasai]
- florian: likely to break things
- 02:38:21 [jamesn]
- q+
- 02:38:26 [fantasai]
- florian: would rather make it not visible, invoke HTML inert behavior
- 02:38:37 [fantasai]
- florian: author can pop things into visual space if they want
- 02:38:43 [Matt_King_]
- Matt_King_ has joined #css
- 02:38:45 [fantasai]
- AmeliaBR: or maybe two different values of a property, recognize different use cases
- 02:39:00 [fantasai]
- AmeliaBR: standard skip link that should become visible
- 02:39:05 [fantasai]
- AmeliaBR: and extra information for screen readers
- 02:39:08 [jcraig]
- q?
- 02:39:41 [jcraig]
- ack me
- 02:39:41 [Zakim]
- 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 [astearns]
- ack jcraig
- 02:39:57 [fantasai]
- jcraig: couple techniques mentioned, one seemed reasonable was HTML hidden=false
- 02:40:04 [fantasai]
- jcraig: aria-hidden=true
- 02:40:08 [fantasai]
- jcraig: or reverse of that rather
- 02:40:08 [nigel]
- q+ to reply
- 02:40:14 [fantasai]
- jcraig: webkit was the only browser to implement
- 02:40:24 [bobbytung]
- bobbytung has joined #css
- 02:40:27 [fantasai]
- jcraig: was very tricky, because webkit builds accessibiltiy tree off of render tree
- 02:40:34 [fantasai]
- jcraig: this was after fork from blink, so blink doesn't have
- 02:40:35 [Judy]
- Judy has joined #css
- 02:40:37 [fantasai]
- jcraig: firefox same thing
- 02:40:40 [fantasai]
- jcraig: so very challenging
- 02:40:42 [fantasai]
- jcraig: after noticing bugs
- 02:40:51 [fantasai]
- jcraig: decided to only allow this if every ancestor above was displayed
- 02:41:00 [fantasai]
- jcraig: so child node could be hidden, but not descendant
- 02:41:02 [Judy]
- present+ Judy
- 02:41:07 [fantasai]
- jcraig: not sure that's the right path, but is the one available atm
- 02:41:21 [fantasai]
- jcraig: technique in the ARIA spec, aria-hidden=false not recommended
- 02:41:23 [astearns]
- ack nigel
- 02:41:23 [Zakim]
- nigel, you wanted to reply
- 02:41:34 [fantasai]
- jcraig: hidden=true aria-hidden=false
- 02:41:58 [fantasai]
- nigel: interaction between attributes and CSS properties not clear in spec, and varies in implementations
- 02:42:11 [fantasai]
- nigel: there some weird stuff going on there
- 02:42:17 [fantasai]
- nigel: my conclusion was to ignore HTML hidden
- 02:42:31 [fantasai]
- jcraig: on WebKit side, implementation was hidden=true { display: none; }
- 02:42:48 [fantasai]
- Rossen__: Edge actually supports everything you said about computing aria and various permutations
- 02:42:59 [fantasai]
- Rossen__: there is an effort that was in EdgeHTML
- 02:43:13 [fantasai]
- Rossen__: have ongoing work in Chromium to add additional capabilities to handle that n Chromium-based browsers
- 02:43:18 [fantasai]
- Rossen__: not sure where Mozilla is
- 02:43:23 [fantasai]
- jcraig: no plans last I heard
- 02:43:37 [astearns]
- ack ZoeBijl
- 02:43:37 [Zakim]
- ZoeBijl, you wanted to say that there are more assistive technologies than screen readers
- 02:43:48 [fantasai]
- ZoeBijl: Want to remidne veryone that there are more AT than just screenreaders that might be affected by this stuff
- 02:44:00 [astearns]
- ack jamesn
- 02:44:16 [fantasai]
- ?: displaying something ...
- 02:44:26 [fantasai]
- ?: Issue of deliberately making things visible
- 02:44:28 [astearns]
- s/?/jamesn/
- 02:45:01 [fantasai]
- 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 [fantasai]
- jamesn: e.g. range control, can't increment/decrement unless native
- 02:45:17 [fantasai]
- jamesn: but can't sytle it properly
- 02:45:23 [fantasai]
- jamesn: so hide it, and display your own control over it
- 02:45:29 [smfr]
- smfr has joined #css
- 02:45:35 [fantasai]
- jamesn: common authoring technique right now, because can't make controls accessible on moble
- 02:45:49 [fantasai]
- jamesn: is one custom control for visual, and one hiden native control for interaction
- 02:45:58 [fantasai]
- jamesn: hidden using very low opacity so stll there
- 02:46:03 [fantasai]
- jamesn: you wnat it to not be inert in this case
- 02:46:24 [nigel]
- scribe: nigel
- 02:46:32 [nigel]
- fantasai: we've heard a lot of new info in this meeting
- 02:46:37 [florian]
- fantasai: we've heard a lot of new information
- 02:46:43 [nigel]
- .. next step is someone to draft a proposal for a new CSS property or value
- 02:46:43 [Matt_King]
- Matt_King has joined #css
- 02:46:46 [nigel]
- .. probably a property
- 02:46:51 [ericc_]
- ericc_ has joined #css
- 02:46:52 [jcraig]
- display value?
- 02:46:56 [nigel]
- .. that takes into account the use cases here and the various limitations
- 02:47:05 [nigel]
- .. I haven't heard a proposal yet.
- 02:47:15 [fantasai]
- astearns: https://github.com/w3c/csswg-drafts/issues/560
- 02:47:15 [nigel]
- astearns: Is there a specific CSS spec for this?
- 02:47:21 [nigel]
- s/spec/issue
- 02:47:31 [nigel]
- fantasai: We definitely don't want to use the display property for this.
- 02:47:34 [nigel]
- .. too many other effects.
- 02:47:45 [nigel]
- .. There is an existing property in the speech module called speak
- 02:47:53 [jcraig]
- q+
- 02:48:00 [nigel]
- .. which was intended for this use case but it doesn't address the issues of the render tree and focusability
- 02:48:13 [nigel]
- jcraig: I've evidence that it was never intended to address this
- 02:48:29 [HeWenli]
- HeWenli has joined #css
- 02:48:35 [zcorpan]
- zcorpan has joined #css
- 02:48:36 [nigel]
- .. it's well specced for DAISY
- 02:48:39 [fantasai]
- jcraig: css-speech is very well-specced for DAISY use case, not for screenreader
- 02:48:45 [nigel]
- scribe: fantasai
- 02:48:46 [astearns]
- ack jcraig
- 02:48:48 [jcraig]
- ack me
- 02:49:00 [fantasai]
- astearns: need a volunteer
- 02:49:23 [fantasai]
- astearns: lacking a volunteer, keep the issue open and periodically ping people
- 02:49:30 [fantasai]
- tink: can try to put words together but need someone on CSS side
- 02:49:34 [fantasai]
- AmeliaBR: I can help
- 02:49:42 [fantasai]
- ACTION: Amelia and tink to draft a proposal
- 02:49:43 [trackbot]
- Created ACTION-883 - And tink to draft a proposal [on Amelia Bellamy-Royds - due 2019-09-24].
- 02:49:48 [IanPouncey]
- I can also help.
- 02:49:50 [fantasai]
- astearns: and bkardell_
- 02:50:47 [fantasai]
- Topic: ???
- 02:50:52 [futhark]
- futhark has joined #css
- 02:51:01 [astearns]
- github: https://github.com/w3c/csswg-drafts/issues/3870
- 02:51:03 [fantasai]
- 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 [fantasai]
- krit: but I think this entire section shoudl be removed
- 02:51:14 [astearns]
- s/???/accessibility section in transforms
- 02:51:33 [Jemma_]
- Jemma_ has joined #css
- 02:51:40 [fantasai]
- krit: section introduces transform to the animate and set elements, both SMIL elements that refer to svg aniamtions
- 02:51:44 [fantasai]
- krit: in addition to what is in SVG already
- 02:51:50 [fantasai]
- krit: but there is no ? and no interest to implement
- 02:51:56 [fantasai]
- krit: so request to either defer or remove entirely
- 02:52:09 [fantasai]
- krit: if section gets removed, then there's nothing about motion in the spec anymore
- 02:52:26 [fantasai]
- AmeliaBR: issue is just asking you to add an accessibiltiy section?
- 02:52:33 [fantasai]
- krit: issue was about adding section about accessibility
- 02:52:45 [fantasai]
- krit: but we removed the section reference to motion, so no need for adding an accessibility section
- 02:53:13 [fantasai]
- AmeliaBR: one paragraph of animating transforms can be bad ?
- 02:53:23 [fantasai]
- fantasai: anything can be animated, width, margins, etc. do we add to every layout feature of CSS?
- 02:53:33 [fantasai]
- fantasai: I think better to keep in the animation section
- 02:54:04 [fantasai]
- AmeliaBR: so requesting to clsoe this issue as wontfix and follow up with getting it addressed in CSS Animations
- 02:54:14 [fantasai]
- krit: yes, but request woudl be to defer the entire feature
- 02:54:25 [fantasai]
- krit: if we want to do that, would suggest to try with SVGWG or SVGCG first
- 02:54:38 [dauwhe]
- dauwhe has joined #css
- 02:54:41 [fantasai]
- AmeliaBR: so other feature request is adding way to pause CSS Animations, which we don't currently have
- 02:54:44 [fantasai]
- krit: right
- 02:54:47 [dot-miniscule]
- dot-miniscule has joined #css
- 02:55:12 [IanPouncey]
- q+
- 02:55:24 [fantasai]
- AmeliaBR: Dont' see why this should be deferred to SVG, CSS Animations has ...
- 02:55:40 [fantasai]
- fantasai: do we need to discuss all this with A11y?
- 02:55:49 [fantasai]
- krit: need to close issue no change beause moving teh section
- 02:56:26 [fantasai]
- IanPouncey: comment about documenting a11y concerns
- 02:56:48 [fantasai]
- IanPouncey: while I don't have a particular problem in this case
- 02:57:00 [dauwhe_]
- dauwhe_ has joined #css
- 02:57:03 [fantasai]
- IanPouncey: just want to say the wya ppl use these documents is to find example they need and copy it directly
- 02:57:09 [tantek]
- I'm wondering if the request for the ability to "pause animation" also includes the ability to slow down the animation
- 02:57:10 [fantasai]
- IanPouncey: not going to look at different document
- 02:57:19 [fantasai]
- IanPouncey: in some cases we might want to have notes in multiple locations therefore
- 02:57:32 [fantasai]
- krit: would maybe put in boilerplate to add to every single module
- 02:58:01 [heycam]
- 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]
- fantasai: which is linked from propdef table
- 02:58:20 [fantasai]
- IanPouncey: happy to draft that note
- 02:58:41 [fantasai]
- 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 [fantasai]
- AmeliaBR: each spec item in the spec would be connected to the warning
- 02:59:17 [xfq]
- ack Ian
- 02:59:21 [fantasai]
- AmeliaBR: Proposal is wontfix on request to add a11y consideration section to css-transforms
- 02:59:29 [fantasai]
- AmeliaBR: for the remainder of the issue, request for pausing/stopping
- 02:59:38 [fantasai]
- AmeliaBR: that will be opened as new issue on Animations or Transitoins
- 02:59:59 [fantasai]
- krit: can only wontfix if remove the animation section
- 03:00:04 [fantasai]
- krit: so request is to remove animation section
- 03:00:24 [fantasai]
- krit: since feature that is added on top of SMIL and no interest form impelmenters and from community
- 03:00:33 [fantasai]
- astearns: so proposed to remove the section and wontfix the issue
- 03:00:42 [fantasai]
- AmeliaBR: can be moved to SVG Animations Level 2 which may or may not ever go anywhere
- 03:00:47 [fantasai]
- AmeliaBR: but that's where the text is lived
- 03:00:51 [fantasai]
- astearns: open a separate issue on that
- 03:00:57 [fantasai]
- astearns: for this particular issue, remove section and wontfix
- 03:01:19 [fantasai]
- RESOLVED: Remove section on animation and wontfix issue about paragraph about accessibility because no longer relevant
- 03:01:25 [fantasai]
- astearns: out of time
- 03:01:32 [astearns]
- topic: lunch
- 03:02:05 [fantasai]
- <br type=lunch>
- 03:02:29 [futhark]
- futhark has joined #css
- 03:12:06 [zcorpan]
- zcorpan has joined #css
- 03:12:51 [nigel]
- nigel has joined #css
- 03:13:51 [zcorpan]
- zcorpan has joined #css
- 03:14:18 [tantek]
- tantek has joined #css
- 03:19:53 [zcorpan]
- zcorpan has joined #css
- 03:19:55 [zcorpan]
- zcorpan has joined #css
- 03:26:24 [dauwhe]
- dauwhe has joined #css
- 03:27:32 [duga]
- duga has joined #css
- 03:30:08 [smfr]
- smfr has joined #css
- 03:35:32 [plh]
- plh has joined #css
- 03:37:26 [futhark]
- futhark has joined #css
- 03:39:35 [drousso]
- drousso has joined #css
- 03:52:18 [myles]
- myles has joined #css
- 03:52:41 [futhark]
- futhark has joined #css
- 03:56:35 [futhark]
- futhark has joined #css
- 03:56:39 [pal]
- pal has joined #css
- 03:57:16 [inamori_]
- inamori_ has joined #css
- 03:57:26 [ericc]
- ericc has joined #css
- 03:58:30 [smfr]
- smfr has joined #css
- 03:59:46 [dauwhe]
- dauwhe has joined #css
- 04:01:35 [DavidClarke]
- DavidClarke has joined #css
- 04:01:52 [DavidClarke]
- Present+
- 04:02:30 [rniwa]
- rniwa has joined #css
- 04:03:36 [addison]
- addison has joined #css
- 04:04:20 [futhark]
- futhark has joined #css
- 04:05:17 [nmccully]
- nmccully has joined #css
- 04:06:08 [duerst]
- duerst has joined #css
- 04:06:20 [zcorpan]
- zcorpan has joined #css
- 04:06:59 [bobbytung]
- bobbytung has joined #css
- 04:07:13 [stantonm]
- stantonm has joined #css
- 04:08:36 [dauwhe]
- dauwhe has joined #css
- 04:08:54 [Rossen__]
- Rossen__ has joined #css
- 04:09:17 [heycam]
- ScribeNick: heycam
- 04:09:26 [Bert]
- Bert has joined #css
- 04:09:40 [r12a]
- r12a has joined #css
- 04:09:43 [nigel]
- nigel has joined #css
- 04:10:33 [astearns]
- https://wiki.csswg.org/planning/tpac-2019#tuesday
- 04:11:04 [Matt_King]
- Matt_King has joined #css
- 04:12:49 [atsushi]
- atsushi has joined #css
- 04:12:56 [Matt_King]
- Matt_King has left #css
- 04:12:58 [heycam]
- Topic: canonicalization of :lang() selectors
- 04:13:04 [heycam]
- github: https://github.com/w3c/csswg-drafts/issues/4154
- 04:13:14 [heycam]
- florian: the :lang selector lets you select pieces of the DOM for styling based on the language
- 04:13:21 [heycam]
- ... it's alreay somehat smart, since lang tags are structured
- 04:13:24 [mattwoodrow]
- mattwoodrow has joined #css
- 04:13:32 [heycam]
- ... selecting zh, and the document saing zh-Hant, it will do the right thing and match it
- 04:13:36 [heycam]
- ... that logic is already built in
- 04:13:41 [kurosawa]
- kurosawa has joined #css
- 04:13:46 [heycam]
- ... the IANA maintains a registry of the langauges that exist and what they mean
- 04:13:47 [sanketj]
- sanketj has joined #css
- 04:13:48 [heycam]
- ... tags and subtags
- 04:14:02 [heycam]
- ... 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 [heycam]
- ... Cantonese used to be zh-yue. that is deprecated and replaced with yue
- 04:14:23 [heycam]
- ... the lang selector does not take that logic into account
- 04:14:42 [heycam]
- ... 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 [heycam]
- ... we may want to use the registry definitions of how to match
- 04:14:57 [heycam]
- ... I propose we do that
- 04:15:23 [heycam]
- addison: some tag canonicalization is defined by BCP 47 to consume some of the information in the registry
- 04:15:33 [xfq]
- xfq has joined #css
- 04:15:43 [heycam]
- ... 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 [heycam]
- florian: zh-yue is a macro language, zh is a macro language
- 04:16:12 [heycam]
- addison: there's a separate thing. previous to the current BCP 47, there was a mechanism for regsitring whole tags
- 04:16:19 [heycam]
- ... that's grandfathered now
- 04:16:24 [heycam]
- ... some of them match subtags, some don't
- 04:16:33 [heycam]
- ... [...] is replaced by xtg
- 04:16:46 [fremy]
- fremy has joined #css
- 04:17:09 [heycam]
- 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 [heycam]
- ... like zh-yue
- 04:17:28 [heycam]
- florian: the way I'm looking at this, there are variety of reasons for why certain langauges might be the same
- 04:17:36 [heycam]
- ... there is a defined canonicalization that handles some of them
- 04:17:51 [heycam]
- addison: for the BCP 47 canonicalization, that will do awy with the grandfathered ones and other strucutral weirdness
- 04:17:56 [heycam]
- florian: it won't deal with the two types of norwegian
- 04:18:13 [inamori_]
- inamori_ has joined #css
- 04:18:14 [heycam]
- ... this is a complicated topic with many weird variants
- 04:18:21 [heycam]
- addison: there's a subset there that's well defined
- 04:18:29 [heycam]
- ... there's a second set of rules, which are in CLDR
- 04:18:33 [heycam]
- ... UTF 35
- 04:18:46 [AmeliaBR]
- s/UTF/UTR/
- 04:18:50 [heycam]
- ... 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 [heycam]
- ... some of those may be of interest, but it's more complicated
- 04:19:03 [smfr]
- smfr has joined #css
- 04:19:08 [heycam]
- ... I don't want to pretend that doesn't exist, but they do
- 04:19:15 [heycam]
- florian: if you have a link, please drop it
- 04:19:30 [heycam]
- addison: defining matching, if you're just using BCP 47 "lookup" IINM
- 04:19:32 [heycam]
- florian: extended filtering
- 04:19:44 [heycam]
- ... the text for extended filtering says you should canonicalize
- 04:19:50 [heycam]
- addison: yes you should
- 04:19:56 [heycam]
- florian: thanks for bringing up that the topic is broader
- 04:20:08 [heycam]
- addison: if you do the minimum set, it'll make it the most predictable. the other aspects are worth studying
- 04:20:17 [heycam]
- ... there are some annoying corner cases in Chinese
- 04:20:27 [heycam]
- florian: I hear support for the current proposal, and complicatd problems to think about in addition to that
- 04:20:39 [heycam]
- 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 [heycam]
- florian: there is a PR for this
- 04:20:57 [heycam]
- addison: should we review that?
- 04:21:02 [fantasai]
- https://github.com/frivoal/csswg-drafts/commit/3cff5d844b6415ef30d3e2dac221f9479e0ec7aa
- 04:21:02 [heycam]
- florian: if you haven't I suggest you do
- 04:21:15 [heycam]
- AmeliaBR: the other question on the topic, do we have implementor commitments?
- 04:22:02 [heycam]
- r12a: the current text I'm looking at says "... must be converetd to x-lang form"
- 04:22:13 [heycam]
- ... that's a slightly different discussion from what you canonicalize it as
- 04:22:20 [heycam]
- ... zh-yue would become yue
- 04:22:24 [heycam]
- florian: I had that discussion on the list as well
- 04:22:35 [heycam]
- ... this is the right direction
- 04:22:49 [heycam]
- ... zh doens't match yue. so if you canonicalize both to x-lang format, it'll match
- 04:23:35 [xfq]
- xfq has joined #css
- 04:23:53 [heycam]
- florian: I raised this on the mailing list, and they agreed it was the right form to canonicalize it to
- 04:23:57 [heycam]
- addison: some people on the list did
- 04:24:07 [heycam]
- ... the challenge is taht this will bring you more promiscuous matching than the author may have intended
- 04:24:15 [heycam]
- ... it'll make Canontese match Mandarin Chinese in some cases
- 04:24:32 [heycam]
- florian: if you want to match Mandarin specifically that's also possible
- 04:24:40 [heycam]
- addison: normally Mandarin is tagged just as zh
- 04:24:51 [heycam]
- r12a: for all the macro languages there's usually a preferred language
- 04:24:58 [heycam]
- fantasai: if the author cares that much, they can put the information there
- 04:25:00 [Rossen__]
- q?
- 04:25:00 [heycam]
- addison: that's right
- 04:25:13 [duerst]
- q+
- 04:25:21 [heycam]
- ... you don't want to have them with a correctly tagged document, have the :lang match things they were [...]
- 04:25:26 [xfq]
- ack du
- 04:25:28 [dauwhe]
- dauwhe has joined #css
- 04:25:41 [heycam]
- duerst: that mailing list is no longer a WG
- 04:25:51 [addison]
- http://www.unicode.org/reports/tr35/#Canonical_Unicode_Locale_Identifiers
- 04:25:53 [heycam]
- ... so people can give you opinions and background knowledge, but no formal resolutions
- 04:26:01 [dino]
- dino has joined #css
- 04:26:01 [AmeliaBR]
- 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 [Rossen__]
- q?
- 04:26:23 [heycam]
- 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 [addison]
- http://www.unicode.org/reports/tr35/#Likely_Subtags
- 04:26:40 [heycam]
- ... it's possible to style Mandarin differently from Cantonese, Hakka, etc., but that's rare
- 04:26:57 [heycam]
- r12a: it's not just Chinese we're talking about
- 04:27:13 [heycam]
- ... there are other languages that have much more differentiation between the language depending on which of the subtags you choose
- 04:27:15 [AmeliaBR]
- q+ to suggest that this is better dealt with in the user agent stylesheet
- 04:27:25 [heycam]
- ... the point I watned to make was that we said that let's go ahead with the proposal at the moment
- 04:27:38 [heycam]
- ... looking at the issue, there was a proposal you wrote, I responded saying you had to modify that
- 04:27:43 [heycam]
- ... the PR doesn't say much
- 04:27:47 [heycam]
- ... not sure what the exact proposal is
- 04:27:55 [heycam]
- ... I think this information we're talking about now should also be part of that
- 04:28:16 [heycam]
- 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 [heycam]
- ... I'm just saying, just the canonicalization to x-lang form as defined by BCP 47
- 04:28:42 [heycam]
- ... and as supported by the mailing list that used to be the WG defining that document
- 04:28:53 [heycam]
- ... btu whichever way we go, including no change at all, has a risk of mismatching things in some cases
- 04:29:00 [heycam]
- addison: not all tags match all values, otherwise what's the point
- 04:29:04 [dbaron]
- s/WG defining/WG that used to define/
- 04:29:16 [heycam]
- ... the problem is to arrive at something that authors understand how to get the results they want
- 04:29:22 [heycam]
- ... we'll make some compromises, the question in which ones
- 04:29:37 [dauwhe_]
- dauwhe_ has joined #css
- 04:29:54 [heycam]
- 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 [heycam]
- ... I am sure there are style sheets that just use :lang(zh), and they'll expect it to match
- 04:30:46 [heycam]
- 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 [heycam]
- ... most of the matching algorithms are strict "remove from right" subtag matching
- 04:30:58 [heycam]
- ... to make it obvious what's happening
- 04:31:18 [heycam]
- ... 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 [heycam]
- ... since it's not obvious what's going to happen
- 04:31:40 [heycam]
- ... 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__]
- dauwhe__ has joined #css
- 04:31:47 [heycam]
- ... that's different than adding or subtracting subtags
- 04:32:00 [xfq]
- ack Ame
- 04:32:00 [Zakim]
- AmeliaBR, you wanted to suggest that this is better dealt with in the user agent stylesheet
- 04:32:04 [heycam]
- AmeliaBR: we covered a lot of what I was going to say, but witha different conclusion
- 04:32:13 [Judy]
- Judy has joined #css
- 04:32:19 [tantek]
- tantek has joined #css
- 04:32:23 [heycam]
- ... 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 [heycam]
- ...also don't want to break matching
- 04:32:40 [heycam]
- ... from the examples brought up, it's obvious that any canoniclization may end up breaking one site or the other
- 04:32:56 [heycam]
- ... 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 [heycam]
- ... at the UA style sheet, that can just be an advice to UAs to look up the BCP deprecation list
- 04:33:17 [heycam]
- ... then also included the deprecated synonmous
- 04:33:37 [heycam]
- .. that doesn't work for things like a style sheet that is coming from a library or CSS reset
- 04:33:40 [dlibby]
- dlibby has joined #css
- 04:33:50 [heycam]
- ... 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 [heycam]
- ... one approach that might address that use case is something like what we do with case insensitive selector matching
- 04:34:12 [duga]
- duga has joined #css
- 04:34:12 [heycam]
- ... a flag in the selector that means "this value or any synonms"
- 04:34:18 [tink]
- tink has left #css
- 04:34:22 [heycam]
- florian: so an opt in for canonicalization
- 04:34:27 [heycam]
- addison: there are three sets
- 04:34:42 [heycam]
- ... the grandfathered list is permanently fixed and has been for 10 years
- 04:34:51 [heycam]
- ... all those tags have explicit mappings, you can safely map them to modern equivalents or vv
- 04:35:15 [heycam]
- addison: individual subtags that ahve mappings, it's mostly about countries going out of business
- 04:35:26 [dino]
- dino has joined #css
- 04:35:31 [heycam]
- ... yiddish has two subtags, hebrew has two subtags, there's a canonical one
- 04:35:56 [heycam]
- .... the third thing is the x-lang thing, which is inconvenient
- 04:36:05 [heycam]
- ... because there's two ways to say things. with or without the enclosing subtag
- 04:36:18 [heycam]
- ... the canonicalization rule in BCP 47 says you can drop the primary langauge subtag and use the x-lang by itself
- 04:36:24 [heycam]
- ... it's permissible for implementations to do that
- 04:36:32 [heycam]
- ... I don't recall it says you can put it back
- 04:36:35 [heycam]
- florian: there are 2 sets of rules
- 04:36:47 [heycam]
- ... one that just strips it off. the other says when you're done stripping it off, put it back
- 04:36:55 [heycam]
- r12a: it says you could consider doing that
- 04:37:08 [heycam]
- addison: the first two are completely safe
- 04:37:10 [heycam]
- ... you want to do those
- 04:37:14 [heycam]
- ... for interop
- 04:37:19 [heycam]
- ... the x-lang thing, I think you can choose
- 04:37:26 [heycam]
- ... whether to put the enclosing subtag on
- 04:37:44 [heycam]
- ... 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 [r12a]
- https://r12a.github.io/app-subtags/
- 04:38:11 [heycam]
- r12a: Omani Arabic and Moroccan Arabic, which treat certain things differently, may have different font requirements
- 04:38:13 [Rossen_]
- Rossen_ has joined #css
- 04:38:27 [heycam]
- ... but they both resolve to "ar" if we follow this PR
- 04:38:31 [heycam]
- ... but that's used for standard Arabic
- 04:38:58 [zcorpan]
- zcorpan has joined #css
- 04:38:58 [heycam]
- florian: I think we're not ready to merge the PR
- 04:39:16 [heycam]
- ... 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 [heycam]
- ... action on me to find out if we can
- 04:39:28 [heycam]
- addison: this is an area that probably deserves better documentation from us
- 04:39:33 [heycam]
- ... we can go offline and make sure we get the right answer
- 04:39:46 [heycam]
- ... 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 [heycam]
- florian: one, figure it ouf if the safe subset exists as a standard operation
- 04:40:12 [heycam]
- ... two, if we do what I'm proposing, look at the affected languages and see if it's good for them
- 04:40:47 [fantasai]
- Topic: Breaking Rules at inline element boundaries
- 04:40:50 [fantasai]
- github: https://github.com/w3c/csswg-drafts/issues/3897
- 04:41:13 [heycam]
- fantasai: there was an issue raised about what happens when you have two inline elements that have different ine breaking rules
- 04:41:23 [heycam]
- ... 3 props control this. white-space, word-break, line-break
- 04:41:32 [heycam]
- ... looking at an example (in the GitHub issue)
- 04:41:54 [heycam]
- ... 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 [heycam]
- ... for white-space, the nearest common ancestor is used
- 04:42:28 [heycam]
- ... 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 [heycam]
- ... and every time that value changes you have to do another run, so impl wise it's a bit awkward
- 04:42:49 [heycam]
- ... there's been some discussion about what's the best behavior here
- 04:42:55 [heycam]
- ... I wanted to ask i18n if you have feedback on this issue
- 04:43:10 [heycam]
- ... and ask the WG if this proposal to leave this undefined for L3, give impl time to experiment
- 04:43:20 [heycam]
- ... doesn't seem to be a terribly high importance case to solve at the moment
- 04:43:55 [heycam]
- 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 [heycam]
- ... can you break between the spans or not
- 04:44:05 [heycam]
- ... current spec says yes, but it's hard-ish to implement
- 04:44:11 [heycam]
- .. if we need time to think about this, undefine it for a while, seems reasonable
- 04:44:18 [heycam]
- ... but that's the kind of case this brings to the surface
- 04:44:28 [heycam]
- Rossen: any objections to leaving it undefined?
- 04:44:35 [heycam]
- r12a: we should look at it as a group offline
- 04:44:48 [bobbytung]
- bobbytung has joined #css
- 04:44:52 [heycam]
- ... it's quite a long thread. I seem to remember someone brought up an example that didn't work
- 04:45:24 [heycam]
- nmccully: are there layout engines working on this that would benefit from the extra time?
- 04:45:35 [heycam]
- 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 [heycam]
- ... so impl wise it's awkward
- 04:45:47 [heycam]
- ... could be factorial if you're changing it every other letter in the line
- 04:45:55 [heycam]
- ... so there's some hesistancy to impl that given the current infrastructure
- 04:46:01 [heycam]
- ... but there doesn't seem to be great solutions
- 04:46:10 [heycam]
- ... some of the behaviours you'd get from doing an easy thing would be non-symmetrics
- 04:46:17 [heycam]
- ... you'd be switching slightly less if you use the current rule in the spec
- 04:46:29 [heycam]
- ... there's not a high pressure to solve this and get interop
- 04:46:32 [smfr]
- smfr has joined #css
- 04:46:33 [heycam]
- ... look at it again in L4
- 04:46:52 [heycam]
- myles: tangential comment, the general thing we're discussin is styling element boundaries
- 04:46:57 [heycam]
- ... this is something letter-spacing also does
- 04:47:04 [heycam]
- ... the spec says something that all browsers diagree ith
- 04:47:18 [heycam]
- ... 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 [heycam]
- fantasai: I think the spec is right on letter-spacing
- 04:47:45 [heycam]
- ???: I think it would be good to have a general way to handle this
- 04:48:00 [heycam]
- florian: we have a current generalized rule, that is general, and does the right thing, and is painful to impl
- 04:48:32 [fantasai]
- s/???/nigel/
- 04:48:43 [heycam]
- RESOLVED: It's undefined
- 04:49:10 [fantasai]
- https://github.com/w3c/csswg-drafts/issues/3481
- 04:50:16 [fantasai]
- https://github.com/w3c/csswg-drafts/issues/337
- 04:50:18 [heycam]
- RESOLVED: i.e., the presence of soft break opportunities between spans which change soft breaking opportunities is undefined
- 04:50:42 [heycam]
- Topic: Remove collapsible line breaks adjacent to word separators
- 04:50:43 [fantasai]
- Topic: Collapsible breaks adjacent to word separtors
- 04:50:46 [heycam]
- github: https://github.com/w3c/csswg-drafts/issues/3481
- 04:51:20 [heycam]
- 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 [heycam]
- ... including line breaks
- 04:51:42 [heycam]
- ... 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_]
- inamori_ has joined #css
- 04:51:51 [heycam]
- ... there are some rules for doing that based on character classes
- 04:52:04 [heycam]
- ... what we didn't consider thoroughly is languages that use a word separator that's not a space
- 04:52:11 [heycam]
- ... we do special case ZWSP, for Thai and other languages
- 04:52:16 [joanie]
- joanie has left #css
- 04:52:25 [zcorpan]
- zcorpan has joined #css
- 04:52:26 [heycam]
- ... but we don't have something similar for Ethiopic word space
- 04:52:32 [heycam]
- ... probably don't also want a regular space there
- 04:52:45 [heycam]
- ... proposal is when there's a word separator character adjacent to a line break, the line break just goes away
- 04:53:28 [smfr_]
- smfr_ has joined #css
- 04:53:33 [heycam]
- ... I think the characters that are affected here are Ogham space mark and Ethiopic word space and the Tibetan tsek
- 04:53:43 [heycam]
- AmeliaBR: does this map to something in Unicode? or do we need to maintain this list?
- 04:53:55 [koji]
- https://drafts.csswg.org/css-text-3/#word-separator
- 04:54:04 [heycam]
- r12a: I think there is something, not sure if it's fit for this purpose
- 04:54:15 [heycam]
- r12a: archaic scripts have other examples
- 04:54:21 [heycam]
- y
- 04:54:41 [heycam]
- fantasai: [reads definition in the spec right now for word-spacing]
- 04:54:50 [heycam]
- florian: we need to maintain a list
- 04:54:54 [heycam]
- myles: let's ask Unicode to do it
- 04:55:17 [heycam]
- ... if there is such a facility for these character lists, hard to believe it's specific for the web platform
- 04:55:26 [heycam]
- ... and not needed in text editors for example
- 04:55:36 [heycam]
- ... I don't think the web specs should maintain this list
- 04:55:44 [heycam]
- florian: I agree with part of your statement, should try to work this out with Unicode
- 04:55:55 [heycam]
- ... this one specifically maybe, but some are specifically web platform relatively
- 04:56:01 [heycam]
- ... since this is relevant to turning HTML markup into text
- 04:56:09 [heycam]
- myles: there are many different markup languages...
- 04:56:14 [heycam]
- fantasai: there are 2 questions
- 04:56:30 [heycam]
- ... if we want to do this, and then whether we maintain the list of if Unicode should
- 04:56:36 [heycam]
- addison: i think we want to do some research
- 04:56:43 [heycam]
- ... space or no space is a classic problem
- 04:56:53 [heycam]
- ... I would be surprised if there weren't something, but don't know off the top of my head
- 04:57:05 [plh]
- plh has joined #css
- 04:57:08 [heycam]
- ... would be happy to engage
- 04:57:33 [heycam]
- 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_]
- zcorpan_ has joined #css
- 04:57:41 [heycam]
- fantasai: looking at some of the stuff in css-text, weh ave a concept of word separateors
- 04:57:47 [heycam]
- ... and it includes a set of code points
- 04:57:53 [heycam]
- ... it excludes Ogham space mark
- 04:58:03 [heycam]
- ... since it would cause text to not join any more
- 04:58:20 [heycam]
- ... 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 [heycam]
- ... 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 [heycam]
- ... unbreaking lines is something that's been hard to explain to them
- 04:59:03 [heycam]
- myles: maybe we shouldn't be unbreaking them?
- 04:59:06 [heycam]
- fantasai: too late for that!
- 04:59:38 [heycam]
- addison: fwiw I've had to write this code in the past, and it's not any fun
- 04:59:48 [heycam]
- ... it maye have been individually solved but not written down
- 04:59:49 [fantasai]
- 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 [heycam]
- r12a: like with the other issues, we need to look in more detail
- 05:00:09 [heycam]
- ... the Tsek is a syllable separator, not the same as a word joiner
- 05:00:24 [heycam]
- ... 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 [heycam]
- fantasai: you wouldn't make the Tsek go away, just avoid the extra space going in there
- 05:01:24 [heycam]
- ACTION: i18n to look this issue of word separators next to newlines
- 05:01:25 [trackbot]
- Error finding 'i18n'. You can review and register nicknames at <https://www.w3.org/Style/CSS/Tracker/users>.
- 05:01:40 [addison]
- action: addison: ensure we respond to css 3481
- 05:01:40 [trackbot]
- Error finding 'addison'. You can review and register nicknames at <https://www.w3.org/Style/CSS/Tracker/users>.
- 05:04:53 [fantasai]
- Topic: ResizeObserver Device Pixel Border Box
- 05:04:57 [fantasai]
- ScribeNick: fantasai
- 05:05:47 [fantasai]
- chrishtr: device-pixel-border-box is the actual device pixel bounds of a canvas element
- 05:06:01 [fantasai]
- chrishtr: including pixel-snapping feature which is ued by browsers to avoid blurriness by snapping to pixel grid
- 05:06:08 [fantasai]
- chrishtr: fundamental problem with no complete solution
- 05:06:14 [fantasai]
- chrishtr: authors that use canvas
- 05:06:25 [fantasai]
- chrishtr: have no reliable method to determine on-screen pixel size of the canvase
- 05:06:35 [fantasai]
- chrishtr: if off by one pixel due to pixel-snapping, rounding, or other issue
- 05:06:41 [fantasai]
- chrishtr: will end up with wrong or blurry results
- 05:06:43 [atsushi_]
- atsushi_ has joined #css
- 05:06:44 [stantonm_]
- stantonm_ has joined #css
- 05:06:50 [fantasai]
- chrishtr: pixel-snapping is intentionally not specced to allow UAs to do their best
- 05:06:57 [sanketj]
- sanketj has joined #css
- 05:06:57 [fantasai]
- chrishtr: acocunt for varying rendering architecture
- 05:06:59 [fantasai]
- chrishtr: and evolution
- 05:07:07 [fantasai]
- chrishtr: so no way to reliably find this size
- 05:07:16 [fantasai]
- chrishtr: proposal is to add a box that observes device pixel border box
- 05:07:20 [fantasai]
- chrishtr: to ResizeObserver
- 05:07:25 [fantasai]
- chrishtr: which will notify if that box changes
- 05:07:43 [fantasai]
- chrishtr: will happen at similar timing as other ResizeObserver
- 05:07:46 [astearns]
- github: https://github.com/w3c/csswg-drafts/issues/3554
- 05:07:50 [fantasai]
- chrishtr: there were two main objections to adding this
- 05:07:57 [fantasai]
- chrishtr: one was raised by Jeff Gilbert
- 05:08:09 [fantasai]
- chrishtr: had a long discussion with him and Kem Russel, our WebGL expert (?)
- 05:08:16 [fantasai]
- chrishtr: have a compromise proposal that both of us agree to
- 05:08:22 [heycam]
- s/Kem Russel/Ken Russell/
- 05:08:24 [fantasai]
- chrishtr: objection he raised was that if you have a WebGL-centric application
- 05:08:34 [fantasai]
- chrishtr: e.g. full-screen game that uses WebAssembly and only DOM in minimal way
- 05:08:40 [fantasai]
- chrishtr: want to have a continuous requestAnimationFrame loop
- 05:08:43 [fantasai]
- chrishtr: drawing the canvas
- 05:08:49 [fantasai]
- chrishtr: in that model where you are canvas-centric
- 05:09:33 [zcorpan]
- zcorpan has joined #css
- 05:09:51 [fantasai]
- chrishtr: it still lives in a DOM shell or browser window that has a size
- 05:09:54 [fantasai]
- chrishtr: need to observe that size
- 05:09:59 [fantasai]
- chrishtr: where pixel snapping will work
- 05:10:05 [fantasai]
- chrishtr: but ... not in JS
- 05:10:14 [heycam]
- s/.../in Web Assembly/
- 05:10:21 [fantasai]
- chrishtr: most convenient to query device border box directly from canvas during rAF loop
- 05:10:29 [fantasai]
- chrishtr: rather than by observer
- 05:10:43 [fantasai]
- 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 [fantasai]
- chrishtr: in taht use case maybe it's OK
- 05:10:53 [fantasai]
- chrishtr: other use case, which I was most focused on
- 05:10:54 [bobbytung]
- bobbytung has joined #css
- 05:11:01 [fantasai]
- chrishtr: you have canvas element embedded in a DOM-centric website
- 05:11:09 [fantasai]
- chrishtr: maybe photo-app or ad or widget,
- 05:11:16 [fantasai]
- chrishtr: potential multi-actor scenario
- 05:11:19 [fantasai]
- chrishtr: want to avoid layout thrashing
- 05:11:26 [fantasai]
- chrishtr: cases for which ResizeObserver was designed
- 05:11:29 [Bert]
- Bert has left #css
- 05:11:31 [fantasai]
- chrishtr: this makes most sense
- 05:11:39 [fantasai]
- chrishtr: compromise proposal is that we just have both APIs
- 05:11:45 [fantasai]
- chrishtr: The End! :D
- 05:11:54 [inamori_]
- inamori_ has joined #css
- 05:12:00 [fantasai]
- jeff: ....
- 05:12:33 [fantasai]
- jgilbert: ... moving forward with both propsoals works out
- 05:12:41 [fantasai]
- jgilbert: having it be in ResizeObserver also makes sense
- 05:12:56 [fantasai]
- jgilbert: like you went over, there was some concerns about it covering espeically more easily some more trivial cases
- 05:13:03 [fantasai]
- jgilbert: having both lets people pick and choose appropriate API
- 05:13:13 [fantasai]
- jgilbert: default should be to use ResizeObserver, most reliable
- 05:13:25 [HeWenli]
- HeWenli has joined #css
- 05:13:29 [fantasai]
- jgilbert: kindof like getClientBOundingRect() , need to be careful if calling that often
- 05:13:32 [fantasai]
- jgilbert: maybe warn in UA
- 05:13:35 [fantasai]
- jgilbert: if called too often
- 05:13:47 [fantasai]
- jgilbert: but getDeviceClientRect() API alone ...
- 05:13:53 [fantasai]
- chrishtr: 2nd objection smfr raised
- 05:14:01 [fantasai]
- chrishtr: pixel-snapping requires more information than just layout in today's engines
- 05:14:05 [fantasai]
- chrishtr: in Chrome requires pre-paint step
- 05:14:09 [fantasai]
- chrishtr: in Safari requires paint
- 05:14:18 [fantasai]
- chrishtr: don't have solution to that problem
- 05:14:24 [fantasai]
- chrishtr: just note readback method for rAF
- 05:14:29 [fantasai]
- chrishtr: canvas.getThing
- 05:14:33 [fantasai]
- chrishtr: also has to run the same steps
- 05:14:40 [fantasai]
- Rossen_: but that's not blocking to accept the proposla
- 05:14:46 [fantasai]
- smfr: in some ways make sit worse
- 05:14:52 [fantasai]
- smfr: because 2 places we have to do this painting calculation
- 05:15:05 [fantasai]
- Rossen_: was asking if this second objection is blocking accepting the proposal
- 05:15:19 [fantasai]
- smfr: so to clarify the proposal is having API to return the box on canvas and also in ResizeObserver
- 05:15:26 [fantasai]
- smfr: I'm not a fan of doing partial paitn to get this info
- 05:15:40 [fantasai]
- smfr: I would expect for games , especially in full-screen, to position on ? boundaries
- 05:15:50 [fantasai]
- smfr: surprised if using fractional pixel positioning
- 05:16:01 [fantasai]
- jgilbert: for full-screen, unlikely, but for partial screen almost always get this
- 05:16:18 [fantasai]
- jgilbert: both on Windows and on Android, I believe, Windows will happily give you 1.6574 device pixel ratio
- 05:16:22 [fantasai]
- jgilbert: you just have to deal with it
- 05:16:30 [fantasai]
- jgilbert: you end up trying to reverse-engineer what pixel-snapping is to figure that out
- 05:16:50 [fantasai]
- 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 [fantasai]
- smfr: other case that's confusing is on our iPhone's that have retina displays
- 05:17:06 [fantasai]
- smfr: already 2.7? scaling factors
- 05:17:13 [fantasai]
- smfr: so can cause hairlines to disappear aetc.
- 05:17:18 [fantasai]
- smfr: seems like also on windows, too
- 05:17:29 [fantasai]
- smfr: getting pixel perfection, seems like OS is doing scaling behind your back, how can you expect it to work?
- 05:17:38 [fantasai]
- jgilbert: out of the box cases where if you play around with virtual scaling
- 05:17:52 [fantasai]
- jgilbert: on a Mac and play with scaling on a retina screen
- 05:17:56 [fantasai]
- jgilbert: no way to get 1-1 device pixel
- 05:18:11 [fantasai]
- myles: even worse, the default ratio is not 1-1 or 2-1
- 05:18:25 [fantasai]
- jgilbert: it really depends on how the OS is doing this sort of scaling
- 05:18:51 [fantasai]
- 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 [fantasai]
- jgilbert: can't get one to one
- 05:19:03 [fantasai]
- jgilbert: if can't get 1-1 in application, can still get moire effects
- 05:19:10 [fantasai]
- jgilbert: can't entirely eliminate scaling artifacts, but can do better
- 05:19:17 [fantasai]
- jgilbert: than naively try to grid on the screen and hope it looks good
- 05:19:35 [fantasai]
- mattwoodrow: difference is on Windows the scaling isn't hidden
- 05:19:48 [fantasai]
- mattwoodrow: can attempt to match
- 05:20:02 [fantasai]
- jgilbert: windows 10 implements scaling that llows 1-1 rendering, not virtual scaling as default
- 05:20:14 [fantasai]
- jgilbert: Mac doesn't expose effective scaling, just says 2x all the time
- 05:20:18 [fantasai]
- jgilbert: Android says 3x all the time
- 05:20:22 [Rossen_]
- q?
- 05:20:29 [fantasai]
- ??: regarldess of what operating systems do, if application renders pixel -perfect
- 05:20:35 [fantasai]
- ??: Result will be better than if it wasn't
- 05:20:41 [fantasai]
- ??: I think we agree on that
- 05:20:44 [plh]
- plh has joined #css
- 05:20:49 [rniwa]
- rniwa has joined #css
- 05:20:56 [fantasai]
- myles: if goal is to get hairlines, even if you get a little closer to hairline, can still disappear
- 05:21:09 [fantasai]
- ??: Display scaling might give you smoother color if checkerboard is pixel-perfect before the scaling
- 05:21:19 [fantasai]
- ??: and if you have checkerboard before scaling, then less smooth design
- 05:21:34 [fantasai]
- s/??/mstage/
- 05:21:41 [jgilbert]
- s/mstage/mstange/
- 05:21:50 [fantasai]
- mstange: still discussing value of getting an accurate box? what's status?
- 05:22:07 [fantasai]
- jgilbert: if we decide that we don't want to give ppl this box, then ?
- 05:22:23 [fantasai]
- 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 [fantasai]
- mstange: what we would need to do in Firefox to get this result
- 05:22:48 [fantasai]
- mstange: Firefox takes into account the full zoom, and takes into account CSS Transforms
- 05:23:11 [fantasai]
- mstange: space in which we snap is established by the closest non-animated transform or the root
- 05:23:24 [fantasai]
- mstange: we only know this info during painting
- 05:23:32 [fantasai]
- mstange: so would need to run more steps before giving info
- 05:23:49 [fantasai]
- smfr: this device border box would not be affected by transforms
- 05:23:56 [fantasai]
- smfr: so would have to do *special* calculation
- 05:24:03 [fantasai]
- jgilbert: 3D transforms no idea what to fee dback
- 05:24:07 [fantasai]
- jgilbert: pixel-snapped bounding box?
- 05:24:22 [fantasai]
- atotic: if you're doing transforms won't be pixel-perfect anyway, so don't worry about it
- 05:24:37 [fantasai]
- atotic: your'e also talking about implementation that you need to get this nformation during pre-painting
- 05:24:43 [fantasai]
- atotic: remember you had this information ??
- 05:24:54 [fantasai]
- atotic: Might be ok to deliver incorrect information and not have to paint
- 05:25:06 [fantasai]
- myles: there's a chance of you never get correct info
- 05:25:19 [mstange]
- s/closest non-animated transform/closest animated ancestor transform/
- 05:25:22 [fantasai]
- atotic: I think you want, once things have settled down want accurate box size
- 05:25:27 [fantasai]
- atotic: if animating, don't care so much
- 05:25:33 [inamori_]
- inamori_ has joined #css
- 05:25:47 [fantasai]
- jgilbert: deliver informmation lately
- 05:25:59 [fantasai]
- 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 [fantasai]
- jgilbert: be nice if we didn't immediately settle on a 1 frame late policy
- 05:26:14 [fantasai]
- jgilbert: matching what native APIs are able to do
- 05:26:24 [fantasai]
- jgilbert: don't want to suffer if dont' have to suffer on native
- 05:26:41 [fantasai]
- 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 [fantasai]
- myles: similarly, worried that we'd have to reverse-engineer chrome's pixel-snapping strategy
- 05:27:15 [fantasai]
- jgilbert: shouldn't have to do more normalziation than you do today, I think
- 05:27:29 [fantasai]
- jgilbert: if trying to use this to get anti-moire, in order to do this today have to ??
- 05:27:49 [fantasai]
- smfr: one frame late version also problem of which rectangle to trust
- 05:27:54 [fantasai]
- chrishtr: not late if layout occured
- 05:27:59 [fantasai]
- chrishtr: only late if you have a threaded animation
- 05:28:16 [fantasai]
- smfr: thought it would be late because we woudl collect info at paint time
- 05:28:23 [fantasai]
- chrishtr: I don't think we shoudl do that, disagree with atotic
- 05:28:28 [fantasai]
- chrishtr: think we can do it therefore we should
- 05:28:32 [fantasai]
- chrishtr: in cases where layout has occured
- 05:28:40 [fantasai]
- chrishtr: agree with point about threaded animations and not syncing with JS thread
- 05:29:03 [fantasai]
- 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 [fantasai]
- smfr: secondly because of physical mismatch, wouldn't have some user benefit
- 05:29:24 [fantasai]
- smfr: display is scaling anyway
- 05:29:32 [fantasai]
- smfr: can we get examples?
- 05:29:45 [fantasai]
- smfr: want to try on Apple devices, see what would happen if looks right
- 05:29:49 [fantasai]
- atotic: moire patter
- 05:30:07 [fantasai]
- atotic: if you're moving canvas around the screen, the moire is animated. looks really bad
- 05:30:11 [fantasai]
- smfr: please give us some tests
- 05:30:15 [fantasai]
- chrishtr: I think time is up?
- 05:30:27 [fantasai]
- chrishtr: propose to add the feature?
- 05:30:41 [fantasai]
- Rossen_: does the group feel there's enough merit to add this?
- 05:30:48 [fantasai]
- Rossen_: would be adding both APIs
- 05:30:52 [fantasai]
- Rossen_: is there any objection?
- 05:31:07 [fantasai]
- 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]
- karl has joined #css
- 05:31:30 [fantasai]
- fremy: you can agree with the API and just return some approximate result if you feel it's good enough
- 05:31:39 [fantasai]
- myles: your'e saying implement the API without implementing teh API
- 05:31:47 [fantasai]
- fremy: might not be useful on your device
- 05:31:53 [fantasai]
- fremy: but might be useful on Android
- 05:31:58 [fantasai]
- fremy: so just return the result
- 05:32:18 [fantasai]
- AmeliaBR: Not having an API is better than having API with bad results
- 05:32:45 [fantasai]
- AmeliaBR: if a particular browser has particular concerns about implementing the particular API
- 05:33:07 [jgilbert]
- 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 [jgilbert]
- ... I still need to size my box either way
- 05:33:42 [jgilbert]
- ... 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 [jgilbert]
- ... then I only need to write one code flow
- 05:34:10 [fantasai]
- AmeliaBR: might make sense, but have existing cases where you can't trust the API
- 05:34:19 [fantasai]
- florian: In general I agree with your statement, this doesn't seem to be such a case
- 05:34:25 [fantasai]
- Rossen_: I woudld like to end this topic
- 05:34:48 [fantasai]
- 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 [fantasai]
- Rossen_: any objections to having these APIs?
- 05:35:01 [fantasai]
- smfr: Can we wait until we ahve the examples?
- 05:35:11 [fantasai]
- astearns: I might object because seems like we need more data
- 05:35:21 [fantasai]
- astearns: so I will object on Safari's behalf
- 05:35:35 [fantasai]
- Rossen_: so back to you to get test cases, we'll discuss again on telecon
- 05:36:02 [fantasai]
- Topic: CSS Writing Modes Implementation Report and Open Issues
- 05:36:21 [florian]
- https://drafts.csswg.org/css-writing-modes-3/implementation-report-2019-08
- 05:36:32 [mstange]
- ScribeNick: mstange
- 05:37:01 [mstange]
- 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]
- sanketj has joined #css
- 05:37:27 [mstange]
- ... Out of about 1000 tests, about 14 failed and 24 others failed. (?)
- 05:37:29 [ericc]
- ericc has joined #css
- 05:37:37 [mstange]
- ... There will always be some tests that fail. We'll be fixing things forever.
- 05:37:48 [mstange]
- ... Have we done enough fixing already to move on?
- 05:38:03 [mstange]
- ... There is a number of issues that are marked in yellow, which are a not insignificant part of the remaining tests.
- 05:38:13 [mstange]
- ... They have some patches which are about to land in Gecko so that they will pass.
- 05:38:30 [mstange]
- ... Some tests could be split up into two tests, both of which will each pass in different browsers.
- 05:39:02 [bobbytung]
- bobbytung has joined #css
- 05:39:05 [mstange]
- ... There are a couple legitimate failures as well.
- 05:39:30 [mstange]
- iank_: Please don't remove tests that test intersections of features. Those tests are useful.
- 05:39:41 [mstange]
- florian: In this particular test, the two features are independent. The intersection is not tested.
- 05:40:26 [mstange]
- ... The test results are from current Chrome Canary.
- 05:40:39 [sanketj]
- sanketj has joined #css
- 05:40:42 [mstange]
- ... We have not done enough work on writing modes to never think about it again.
- 05:40:54 [mstange]
- ... But I don't think any problems are in areas we believe to be wrong in the spec.
- 05:41:06 [mstange]
- ... It's my opinion that we can move on despite those failures.
- 05:41:37 [xfq]
- 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 [Rossen_]
- https://github.com/w3c/csswg-drafts/issues?q=is%3Aopen+is%3Aissue+label%3Acss-writing-modes-3
- 05:41:44 [mstange]
- fantasai: There are some issues about things where the spec is unclear, and we should just do those clarifications.
- 05:42:13 [mstange]
- florian: All issues are about things that ought to be better defined. But we need help.
- 05:42:51 [mstange]
- fantasai: I think it would be better to address these issues before saying that writing mode L3 is done.
- 05:43:18 [mstange]
- dbaron: I've been uncomfortable with some of the things about intrinsic sizing.
- 05:43:42 [mstange]
- ... I think the third issue is more on the material and sizing than on the material and writing modes.
- 05:43:44 [rachelandrew_]
- rachelandrew_ has joined #css
- 05:44:13 [mstange]
- ... In response to being asked to implement something in Firefox, I ran into a list of conditions that was unclear.
- 05:44:21 [mstange]
- florian: Was this not partly answered by text that was restored?
- 05:44:33 [mstange]
- dbaron: I think this was after it was being restored.
- 05:45:07 [mstange]
- florian: fantasai discovered that some section had been lost and it was recovered in late August.
- 05:45:33 [mstange]
- 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 [mstange]
- dbaron: It is very hard to know what some of the terms mean in a specific context.
- 05:46:33 [mattwoodrow]
- mattwoodrow has joined #css
- 05:46:52 [mstange]
- 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 [mstange]
- florian: Can we address this in L4?
- 05:47:20 [mstange]
- 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 [mstange]
- astearns: How do we move writing modes forward?
- 05:47:54 [astearns]
- s/astearns/Rossen_ /
- 05:48:02 [mstange]
- ... 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]
- chris has joined #css
- 05:48:35 [mstange]
- fantasai: With the exception of some tweaks, Gecko seems to have implemented this just fine.
- 05:48:39 [zcorpan_]
- zcorpan_ has joined #css
- 05:48:57 [smfr]
- smfr has joined #css
- 05:50:07 [mstange]
- ... 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 [mstange]
- AmeliaBR: Given that fantasai has said that Gecko is right, are we ok with (?)
- 05:51:00 [mstange]
- 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 [mstange]
- 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 [AmeliaBR]
- s/are we ok with (?)/could dbaron suggest new text that describes that & addresses his issues (in time for publication)/
- 05:51:52 [mstange]
- 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 [mstange]
- 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 [mstange]
- dbaron: It would be nice to give an example where this list doesn't apply.
- 05:53:21 [mstange]
- fantasai: I don't know of one.
- 05:53:37 [mstange]
- dbaron: That's why I suggested stating in the spec that it always applies.
- 05:54:28 [inamori_]
- inamori_ has joined #css
- 05:54:45 [astearns]
- +1 koji
- 05:55:03 [mstange]
- Rossen_: The proposal was not to resolve the issues, it was to move them and retag them for L4.
- 05:55:33 [mstange]
- Rossen_: Any objects to retagging the three issues to level 4? Those are 4026 3095 and 2819.
- 05:55:44 [astearns]
- and they will need to be added/updated in the DOC
- 05:55:44 [mstange]
- No objections. We will move these issues to be tracked under L4.
- 05:55:52 [xfq]
- s/2819/2890/
- 05:56:07 [mstange]
- 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 [mstange]
- Rossen_: Are there any objections to move CSS writing mode Level 3 to PR?
- 05:56:19 [plh]
- plh has joined #css
- 05:56:24 [mstange]
- Rossen_: No objections, resolved.
- 05:56:32 [fantasai]
- 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 [mstange]
- RESOLVED: Move CSS Writing Modes L3 to PR.
- 05:56:38 [fantasai]
- have to use fallback size
- 05:57:37 [pal]
- pal has joined #css
- 05:58:05 [james]
- james has joined #css
- 05:58:05 [mstange]
- Topic: Remove font-variant @font-face descriptor from Fonts 3
- 05:58:12 [mstange]
- github: https://github.com/w3c/csswg-drafts/issues/2531
- 05:58:50 [mstange]
- myles: We have two text paths. In WebKit. The distinction which path to go to has to happen before font fallback.
- 05:59:23 [mstange]
- ... Sometimes we detect something too late and can't go back and re-do everything, so we just do our best.
- 05:59:47 [mstange]
- ... If this is not necessary for the web platform, let's remove it.
- 06:00:00 [mstange]
- fantasai: It does look like there is an implementation (faceless2 says it in the issue)
- 06:00:54 [mstange]
- ... 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 [mstange]
- myles: When is the deadline? It's been years.
- 06:01:19 [mstange]
- Rossen_: This is a non-verifiable implementation. How do we evaluate it?
- 06:02:00 [Rossen_]
- q?
- 06:02:25 [mstange]
- drott: We would support removing it because the semantics are unclear in some cases.
- 06:02:36 [mstange]
- heycam: We would also be fine with removing it. We haven't heard much demand from authors.
- 06:02:47 [mstange]
- ... In principle it seems like a useful thing, but we would be fine with removing it.
- 06:02:54 [mstange]
- Rossen_: Any objections to removing it?
- 06:02:59 [mstange]
- Rossen_: No objections.
- 06:03:08 [mstange]
- RESOLVED: Remove font-variant @font-face descriptor from Fonts 3
- 06:03:26 [mstange]
- Topic: mitigations for font based fingerprinting
- 06:03:31 [mstange]
- github: https://github.com/w3c/csswg-drafts/issues/4055
- 06:04:26 [mstange]
- chris: The issue is that you can pretty much identify individuals based on the set of installed fonts.
- 06:04:45 [mstange]
- ... 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 [AmeliaBR]
- s/spec/speak/
- 06:05:01 [foolip]
- fantasai, florian, TabAtkins: we're in the #testing meeting debating what your requirements actually are. can we interview you later?
- 06:05:08 [mstange]
- ... One proposal was to only report fonts that are the standard fonts for that platform.
- 06:05:19 [mstange]
- ... But this would cause you to re-download fonts you already have.
- 06:05:30 [mstange]
- ... This consumes unnecessary bandwidth.
- 06:05:54 [mstange]
- florian: On some OSes, even the set of default fonts can almost uniquely identify you.
- 06:06:05 [mstange]
- myles: It is impossible for the spec to describe the set of default fonts.
- 06:06:28 [mstange]
- ... 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 [mstange]
- 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 [mstange]
- chris: There is a strong web compat problem here. Things that used to work should not break.
- 06:08:07 [mstange]
- florian: When working means look pretty, there's a trade-off. When it means you cannot read it, it's different.
- 06:08:21 [mstange]
- myles: WebKit has been doing this for over a year. We discard user-installed fonts.
- 06:08:34 [mstange]
- florian: Mongolian without fonts is unreadable.
- 06:08:46 [mstange]
- ... When it is readable, removing the fonts breaks it.
- 06:08:50 [mstange]
- myles: It's a trade-off.
- 06:08:57 [mstange]
- heycam: How did you choose that list of fonts?
- 06:09:02 [mstange]
- myles: I commented on the issue.
- 06:09:02 [heycam]
- s/heycam/thomas/
- 06:09:36 [fantasai]
- 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 [mstange]
- 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 [fantasai]
- and which have less money to spend
- 06:10:11 [sanketj]
- sanketj has joined #css
- 06:10:50 [mstange]
- 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 [mstange]
- Rossen_: We will pause the discussion of this issue and unpause it after the break.
- 06:11:23 [mstange]
- Topic: Vertical text doesn't play nicely with font-style and font-stretch
- 06:11:39 [mstange]
- Topic: Dynamic text size
- 06:11:42 [heycam]
- github: https://github.com/w3c/csswg-drafts/issues/3708
- 06:12:13 [mstange]
- ???: For a long time we've had scalable fonts that are based on the Desktop Web.
- 06:12:26 [heycam]
- s/???/jcraig/
- 06:12:45 [smfr]
- smfr has joined #css
- 06:12:51 [mstange]
- jcraig: It took us a while to make it work on all extreme cases.
- 06:13:03 [mstange]
- ... We would like to support low vision users who have extremely large text sizes.
- 06:13:36 [mstange]
- ... Forcing such giant font sizes on web pages would make most web pages unreadable.
- 06:13:48 [mstange]
- ... We would like to have a way to opt in to larger font sizes.
- 06:13:57 [mstange]
- ... as an author.
- 06:14:22 [mstange]
- ... 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 [mstange]
- ... 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 [mstange]
- ... Right now there is no standard way to opt in to this that works across all browsers.
- 06:15:02 [mstange]
- ... Most browsers on mobile systems don't want to break their users' layout.
- 06:15:30 [mstange]
- ... We have examples where it would be very difficult or even impossible to achieve the intended layouts today.
- 06:16:26 [mstange]
- jcraig: [demo]
- 06:16:54 [mstange]
- ... I have applied iOS settings that render text extremely large and bold.
- 06:17:05 [mstange]
- ... I can show how different apps deal with this setting.
- 06:17:14 [mstange]
- ... Calendar switches to 3 or 2 column layouts.
- 06:17:32 [mstange]
- ... The Books app switches from a 2 column layout to a single column layout.
- 06:17:55 [fantasai]
- These are all very easy to do if you have flexbox/grid and correctly implement media queries in em units
- 06:18:16 [fantasai]
- or ch units
- 06:18:35 [mstange]
- ... In Mail, with larger font sizes, the title gets clipped but the email's time is preserved.
- 06:19:06 [mstange]
- 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 [mstange]
- ... Everything you've demonstrated here is totally possible with em and ch units in media queries.
- 06:19:19 [rniwa]
- rniwa has joined #css
- 06:19:37 [mstange]
- ... 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 [mstange]
- 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 [mstange]
- 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 [mstange]
- chris: People are rapidly going to find out that just copying this around will break them.
- 06:21:23 [inamori_]
- inamori_ has joined #css
- 06:21:41 [mstange]
- 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 [mstange]
- ... They haven't turned on these large fonts on their system.
- 06:22:17 [chris]
- fair point, retracted
- 06:23:14 [mstange]
- 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 [mstange]
- 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 [mstange]
- jcraig: That would get us some of the way.
- 06:24:07 [tantek]
- tantek has joined #css
- 06:24:26 [mstange]
- 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 [mstange]
- florian: You can't compare the font size and the viewport because the lengths have different units.
- 06:24:57 [mstange]
- ... The thing you call an opt in would also opt in the media queries to behave properly.
- 06:25:15 [mstange]
- ... Whichever opt-in we have needs to opt in both to behave how things were originally intended.
- 06:25:28 [AmeliaBR]
- `@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 [mstange]
- ???: If you have a user font size variable, you can use calc to obtain the right answer.
- 06:25:58 [heycam]
- s/???/fremy/
- 06:25:59 [mstange]
- fantasai: As an environment variable, it would work out.
- 06:26:34 [mstange]
- ... But (?) it would be multiple variables, not one variable.
- 06:26:42 [Mek]
- Mek has joined #css
- 06:26:43 [futhark]
- futhark has joined #css
- 06:26:53 [mstange]
- fantasai: The size of ch is dependent on the initial font, not on the font that is used.
- 06:27:29 [mstange]
- 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 [AmeliaBR]
- s/(?)/Firefox uses different font-sizes for different languages, so/
- 06:27:33 [fremy]
- fremy has joined #css
- 06:27:45 [mstange]
- florian: Is there reason to exclude media queries from the opt in?
- 06:27:54 [mstange]
- jcraig: It should not be excluded.
- 06:28:16 [mattwoodrow]
- mattwoodrow has joined #css
- 06:28:23 [mstange]
- fremy: You want to be able to opt in only parts of a web site.
- 06:28:46 [mstange]
- ... 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 [mstange]
- jcraig: The reverse is also true.
- 06:29:15 [mstange]
- 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 [mstange]
- fremy: You cannot say media queries behave differently for different parts of the same document.
- 06:30:00 [mstange]
- florian: Yes, if you put a responsive widget into a non-responsive website, then yes, your responsiveness is wasted.
- 06:32:15 [duga]
- duga has joined #css
- 06:32:35 [mstange]
- 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 [mstange]
- 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 [mstange]
- florian: If we can't make the existing media queries work, we maybe need to add more media queries.
- 06:34:26 [mstange]
- 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 [mstange]
- 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 [mstange]
- ... In order to get useful media queries, the opt in has to be outside of a property.
- 06:35:46 [mstange]
- ... 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 [plinss]
- q+
- 06:35:58 [mstange]
- ... Otherwise, the default size will be the legacy 16px.
- 06:36:20 [mstange]
- 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 [mstange]
- ... 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 [mstange]
- Rossen_: We need to work towards a resolution.
- 06:37:17 [Rossen_]
- q?
- 06:37:21 [Rossen_]
- ack plh
- 06:37:26 [Rossen_]
- ack plinss
- 06:37:46 [dino]
- dino has joined #css
- 06:37:51 [Rossen_]
- ack fantasai
- 06:37:52 [jcraig]
- Q+
- 06:37:52 [mstange]
- 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 [mstange]
- fantasai: I hate meta tags because you can't put them in a stylesheet and link them from everywhere.
- 06:38:29 [mstange]
- ... 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]
- smfr has joined #css
- 06:39:01 [dauwhe_]
- dauwhe_ has joined #css
- 06:39:15 [gsnedders]
- RRSAgent: make the minutes
- 06:39:15 [RRSAgent]
- I have made the request to generate https://www.w3.org/2019/09/15-css-minutes.html gsnedders
- 06:39:16 [mstange]
- ... And once the mode has been switched, font sizes and everything else can start working the way initially intended.
- 06:39:32 [florian]
- q+?
- 06:39:35 [mstange]
- ... These things all belong together so we should just tack on a meta tag.
- 06:39:49 [mstange]
- Rossen_: I do not hear agreement on exact technicalities.
- 06:40:39 [mstange]
- 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 [mstange]
- Rossen_: Objections on opting in to true user font sizes?
- 06:41:13 [mstange]
- jcraig: We (Apple) tried to do this without a mode switch, by default, and all 200 000 apps broke.
- 06:41:39 [mstange]
- ... Even with an opt-in switch, it took years for all first party apps to support this mode.
- 06:42:04 [mstange]
- 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 [mstange]
- 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 [mstange]
- ... 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 [mstange]
- ... It seems that most users will accept smaller fonts if it means that pages are not broken.
- 06:43:32 [zcorpan]
- zcorpan has joined #css
- 06:43:47 [mstange]
- plinss: I have no concerns with a user switch. I have concerns with adding a switch to the web platform.
- 06:44:11 [dauwhe]
- dauwhe has joined #css
- 06:44:18 [zcorpan]
- zcorpan has joined #css
- 06:44:38 [mstange]
- ... 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 [mstange]
- ... There is real costs to adding mode switches.
- 06:45:09 [mstange]
- myles: The resolution seems to be about intention, not implementation. Let's try to agree on that.
- 06:45:19 [mstange]
- Rossen_: Objections to having the option to have two font sizes?
- 06:45:23 [fantasai]
- s/two/true/
- 06:45:30 [futhark]
- futhark has joined #css
- 06:45:43 [mstange]
- RESOLVED: There should be a way to have true font sizes.
- 06:45:49 [karl]
- RRSAgent, make minutes
- 06:45:49 [RRSAgent]
- I have made the request to generate https://www.w3.org/2019/09/15-css-minutes.html karl
- 06:46:20 [futhark]
- futhark has joined #css
- 06:46:34 [nigel]
- nigel has joined #css
- 06:53:44 [nigel]
- nigel has joined #css
- 06:55:25 [atsushi]
- atsushi has joined #css
- 07:02:04 [rniwa]
- rniwa has joined #css
- 07:03:04 [dauwhe]
- dauwhe has joined #css
- 07:05:07 [dauwhe_]
- dauwhe_ has joined #css
- 07:05:28 [duga]
- duga has joined #css
- 07:06:02 [zcorpan]
- zcorpan has joined #css
- 07:06:02 [xfq]
- xfq has joined #css
- 07:06:09 [emilio]
- cmp: https://bugzilla.mozilla.org/show_bug.cgi?id=1252821
- 07:06:14 [futhark]
- futhark has joined #css
- 07:07:08 [Rossen_]
- Rossen_ has joined #css
- 07:07:16 [dino]
- dino has joined #css
- 07:07:45 [stantonm]
- stantonm has joined #css
- 07:08:07 [fremy]
- fremy has joined #css
- 07:08:54 [emilio]
- Topic: [css-fonts] Vertical text doesn't play nicely with font-style and font-stretch
- 07:09:01 [emilio]
- Github:https://github.com/w3c/csswg-drafts/issues/4044
- 07:09:04 [glenn]
- glenn has joined #css
- 07:11:18 [emilio]
- ??: CJK text differs from latin because of the multiple orientations
- 07:11:33 [emilio]
- .. because of that multiple features related to the line width become quite complex
- 07:11:59 [emilio]
- ... [explains example in the issue]
- 07:12:36 [emilio]
- ... depending on the glyph orientation glyphs get stretched in different directions
- 07:12:55 [emilio]
- ... as a user is backwards, as an implementor you need to poke at the internal characters
- 07:13:17 [emilio]
- ... while the feature is about stretching the whole line
- 07:13:30 [Ms2ger]
- Ms2ger has joined #css
- 07:13:37 [emilio]
- myles: this was discussed in OpenType and there was some discussion
- 07:14:13 [emilio]
- ... 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 [emilio]
- ... but it's pretty hard to set up
- 07:14:42 [emilio]
- ... so opentype would introduce a new axis
- 07:14:51 [emilio]
- ... vertical and horizontal width
- 07:15:18 [emilio]
- ... and the application would set the relevant vertical / horizontal axis depending on whether the glyph is upright or not
- 07:15:41 [emilio]
- ... no resolutions anywhere yet but need to move it together
- 07:16:53 [emilio]
- ... so we need font-face descriptor to say that it supports stretching in the vertical axis or not
- 07:17:20 [emilio]
- ... 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]
- sanketj has joined #css
- 07:17:51 [nmccully]
- s/??/nmccully
- 07:18:07 [emilio]
- ... the font-stretch property wouldn't change syntax, but it'd change behavior
- 07:18:22 [emilio]
- ... rotating the font in the appropriate direction
- 07:18:47 [emilio]
- ... which means that writing-mode and text-combine and such would also be inputs to the font selection algorithm
- 07:19:08 [emilio]
- ... because if it's vertical it'd need to download the font that can expand in the vertical axes
- 07:19:13 [emilio]
- ... thoughts?
- 07:19:19 [emilio]
- fantasai: sgtm
- 07:19:27 [emilio]
- leaverou: would the property change?
- 07:19:42 [emilio]
- myles: the property has no grammar change but has behavior change
- 07:19:58 [emilio]
- nmccully: you may need it for TCY
- 07:20:54 [emilio]
- 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 [emilio]
- ... everything I've said also applies to font-style (for the italic angle)
- 07:21:14 [emilio]
- koji: what's the syntax proposal?
- 07:21:29 [emilio]
- myles: [explains proposal in the issue]
- 07:22:03 [emilio]
- 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 [emilio]
- nmccully: Adobe has formed an opinion already and has a prototype
- 07:22:22 [heycam]
- q+
- 07:22:24 [dlibby]
- dlibby has joined #css
- 07:22:31 [xfq]
- xfq has joined #css
- 07:22:39 [emilio]
- koji: should it be physical or logical?
- 07:22:45 [emilio]
- fantasai: for font needs to be physical
- 07:22:47 [Rossen_]
- ack jcraig
- 07:22:50 [Rossen_]
- ack ?
- 07:23:14 [emilio]
- ... 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 [emilio]
- ... upright chars get "longer" in the vertical axes, the other keeps the same height but
- 07:24:14 [emilio]
- ... 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 [emilio]
- koji: so you're saying physical to line orientation not to glyph orientation
- 07:24:52 [emilio]
- 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]
- futhark has joined #css
- 07:25:32 [fantasai]
- koji: agree
- 07:25:36 [emilio]
- myles: [explains that in a different way]
- 07:25:40 [emilio]
- koji: agree
- 07:25:51 [emilio]
- ack heycam
- 07:26:13 [emilio]
- 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 [emilio]
- nmccully: the browser would have to know how each browser treats the font (regarding upright-ness)
- 07:26:57 [emilio]
- ... then go browser by browser and change fonts per rune
- 07:27:25 [emilio]
- heycam: so part of the issue is that browsers disagree on that, right? (fantasai mentioned punctuation before)
- 07:27:37 [emilio]
- fantasai: yeah, even by that is a per-codepoint thing
- 07:28:52 [emilio]
- 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 [emilio]
- ... way too much work to request on an author
- 07:29:17 [emilio]
- nmccully: it's mixing two things, whether something is sideways is not the author decision
- 07:29:36 [emilio]
- ... it's automated based in unicode-range
- 07:29:39 [zcorpan]
- zcorpan has joined #css
- 07:29:59 [emilio]
- heycam: Oh I assumed that authors would have expectations and browsers would be consistent
- 07:30:36 [emilio]
- fantasai: I think this is the right design, I think it works great for font-stretch
- 07:30:43 [emilio]
- ... for oblique and such it may not
- 07:31:07 [emilio]
- myles: there's another piece. Today if you say font-style: italic on vertical text you'll get weird stuff
- 07:31:13 [emilio]
- ... this proposal will fix that
- 07:31:23 [emilio]
- fantasai: don't we have a resolution on that?
- 07:31:37 [emilio]
- florian: I think hiroshi wanted to reopen that
- 07:31:50 [emilio]
- ... but didn't because nobody seemed to run into a spec
- 07:32:07 [emilio]
- Rossen_: would this change this resolution?
- 07:32:22 [emilio]
- florian: only if we apply it to font-style
- 07:32:45 [emilio]
- fantasai: I think we may have a font-stretch-vertical descriptor rather than stashing it on font-stretch
- 07:32:59 [emilio]
- ... but that's more bikeshedding and I generally agree with the proposal
- 07:33:06 [emilio]
- Rossen_: objections to adopt this?
- 07:33:23 [emilio]
- RESOLVED: Adopt the proposal for font-stretch
- 07:33:44 [emilio]
- Topic: end
- 07:34:33 [emilio]
- Topic: mitigations for font based fingerprinting
- 07:34:37 [duga]
- duga has joined #css
- 07:34:44 [emilio]
- github: https://github.com/w3c/csswg-drafts/issues/4055
- 07:35:25 [emilio]
- TabAtkins: [introduces the issue]
- 07:35:48 [emilio]
- TabAtkins: we expose a lot of PI data on the web
- 07:36:24 [emilio]
- ... even if you plug fonts we're probably not below the level where you cannot identify a single user
- 07:36:40 [emilio]
- ... to do that you probably need to do software rendering on canvas for example
- 07:37:00 [emilio]
- ... so unless somebody comes up with a list of stuff and data
- 07:37:08 [chris]
- chris has joined #css
- 07:37:16 [chris]
- present+
- 07:37:18 [emilio]
- ... I think we shouldn't do that
- 07:37:30 [emilio]
- ... a bit annoying from a PR standpoint to argue why it doesn't really matter but...
- 07:37:44 [emilio]
- myles: our goal is to remove all the sources of fingerprinting on the web
- 07:37:57 [emilio]
- ... we should reduce as much as possible
- 07:38:15 [emilio]
- TabAtkins: you cannot remove all of them
- 07:38:27 [emilio]
- ... no media queries, etc..
- 07:38:37 [smfr]
- smfr has joined #css
- 07:39:08 [emilio]
- TabAtkins: unless you could reduce it to 20 you haven't done anything
- 07:39:26 [emilio]
- myles: well you're closer to the goal
- 07:39:30 [emilio]
- [funny methafores]
- 07:39:42 [emilio]
- metaphors*
- 07:39:42 [Rossen_]
- q?
- 07:40:13 [emilio]
- TabAtkins: going from "individually identify someone" to "individually identify someone" does nothing
- 07:40:34 [emilio]
- ... there's a specific threshold we need to reach to do anything
- 07:40:45 [emilio]
- ... and nobody can
- 07:40:48 [emilio]
- myles: we'll try
- 07:41:16 [emilio]
- dino: I really believe we should ask the question for each feature of what the cost is
- 07:41:26 [emilio]
- ... I accept what TabAtkins says about the number of bits
- 07:41:49 [emilio]
- ... but it's this group's duty to do the cost of the feature vs. the privacy impact
- 07:42:02 [emilio]
- florian: cost is breaking the web for minority languages, benefit is not clear yet
- 07:42:33 [emilio]
- 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 [emilio]
- ... then happy to
- 07:43:24 [emilio]
- 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 [emilio]
- thomas: There's also ways to alert the user it's being fingerprinted
- 07:44:00 [Rossen_]
- q?
- 07:44:15 [emilio]
- nmccully: I'm hearing mostly that it's not the right fix. We shouldn't make it worse but...
- 07:45:09 [leaverou]
- q+
- 07:45:18 [emilio]
- 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 [Rossen_]
- ack leaverou
- 07:45:30 [emilio]
- ... so pros and cons seem clear here
- 07:45:37 [dino]
- emilio: I agree with myles
- 07:45:58 [emilio]
- leaverou: Lots of old sites rely on common fonts like Calibri or Cambria installed
- 07:46:07 [florian]
- q?
- 07:46:10 [florian]
- q+
- 07:46:12 [emilio]
- ... also there's a perf impact of always downloading the font since sites tend to use `local()`
- 07:46:30 [emilio]
- ???: Are we getting ahead of the game between standards and impls
- 07:46:36 [fantasai]
- s/???/glenn/
- 07:46:37 [dino]
- s/???/Glenn/
- 07:46:37 [emilio]
- myles: the spec can't do much here
- 07:47:12 [Rossen_]
- ack flackr
- 07:47:14 [emilio]
- myles: we are an standardization, we can't do more that saying in the spec that should have privacy considerations
- 07:47:16 [Rossen_]
- ack florian
- 07:47:24 [emilio]
- ... but browsers like Safari can and have gone further
- 07:47:55 [emilio]
- florian: so you mentioned that you investigated the amount of sites
- 07:48:04 [emilio]
- ... that broke or not
- 07:48:27 [emilio]
- ... if you're removing language support minority users can't use the web
- 07:48:36 [emilio]
- ... also bandwidth may be a concern
- 07:49:00 [emilio]
- ... I don't care if sites are slowly slower for californians
- 07:49:19 [emilio]
- myles: having philosophical discussions is not particularly useful
- 07:49:23 [dauwhe]
- dauwhe has joined #css
- 07:49:24 [emilio]
- ... we need a concrete proposal
- 07:49:32 [emilio]
- ... and there's nothing to resolve on until there's one
- 07:50:54 [emilio]
- ... the spec already says that a UA may or not scan al fonts in the system
- 07:51:01 [emilio]
- Rossen_: out of time
- 07:51:04 [emilio]
- Topic: end
- 07:51:32 [Rossen_]
- https://github.com/w3c/csswg-drafts/issues/3440#issuecomment-530702998
- 07:51:49 [emilio]
- topic: [css-text][css-sizing] When to/not to include preserved trailing spaces
- 07:51:57 [emilio]
- github: https://github.com/w3c/csswg-drafts/issues/3440#issuecomment-530702998
- 07:52:16 [emilio]
- fantasai: [summarizes situation]
- 07:52:29 [emilio]
- fantasai: proposal is to accept the proposal in https://github.com/w3c/csswg-drafts/issues/3440#issuecomment-530702998
- 07:52:41 [emilio]
- ... I think we should agenda
- 07:52:53 [emilio]
- s/agenda/resolve on that/
- 07:52:59 [emilio]
- florian: I think koji is ok with it now
- 07:53:02 [emilio]
- Rossen_: objections?
- 07:53:08 [emilio]
- RESOLVED: Accept the proposal in https://github.com/w3c/csswg-drafts/issues/3440#issuecomment-530702998
- 07:53:15 [emilio]
- Topic: end
- 07:53:38 [emilio]
- Topic: system-ui fonts
- 07:53:43 [emilio]
- GitHub: https://github.com/w3c/csswg-drafts/issues/4107
- 07:54:33 [fantasai]
- This is my position: https://github.com/w3c/csswg-drafts/issues/4107#issuecomment-525824422
- 07:54:53 [emilio]
- 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 [emilio]
- ... ?
- 07:55:05 [emilio]
- myles: I'd prefer the later
- 07:55:13 [fremy]
- @myles: does adding this as a keyword add a fingerprinting method? is it worth it? ;-)
- 07:55:13 [emilio]
- fantasai: (explains her position above)
- 07:55:54 [emilio]
- fantasai: tldr it makes sense to have system-ui keywords, but they should be exposed also behind an actual name
- 07:56:16 [emilio]
- myles: It's impossible for us to determine because the fonts are nice or because they're systemy
- 07:56:28 [emilio]
- Rossen_: how are you going to determine it?
- 07:56:29 [drousso]
- drousso has joined #css
- 07:56:57 [emilio]
- ... expose it with a proprietary name and you're done
- 07:57:07 [thomas]
- thomas has joined #css
- 07:57:28 [emilio]
- koji: I think regardless of exposing them via the name I think there's use case for the keywords
- 07:58:20 [emilio]
- 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 [Rossen_]
- q?
- 07:58:46 [emilio]
- ... but just font families is not the only thing that emulating the system
- 07:58:56 [emilio]
- s/that/for
- 07:59:22 [emilio]
- myles: but it's a required part of matching the system, regardless of the rest of the design
- 08:00:16 [emilio]
- 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 [emilio]
- dino: it may help authors in other systems too
- 08:01:22 [emilio]
- koji: we learned from system-ui that authors don't want the exact same font as the system
- 08:01:51 [emilio]
- ... on windows server a bunch of big pages didn't want the system font which was tahoma, they wanted segoe instead
- 08:02:08 [emilio]
- Rossen_: that's why when we released segoe we did it as a font not as a ui keyword
- 08:03:21 [emilio]
- 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 [emilio]
- myles: so ui-serif rather than system-ui-serif?
- 08:03:49 [emilio]
- florian: if that's the use case that sounds fine
- 08:04:17 [emilio]
- 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 [leaverou]
- q+
- 08:05:02 [emilio]
- myles: so it seems we're coalescing to add `ui-rounded`, `ui-serif`, `ui-monospace`, ...
- 08:05:21 [emilio]
- florian: I'd also also encourage apple to expose them by name
- 08:05:26 [emilio]
- nmccully: that seems useful
- 08:05:30 [emilio]
- myles: ok, we'll do both
- 08:05:48 [emilio]
- florian: less sure about *-rounded
- 08:06:23 [emilio]
- fantasai: what do we do for `ui-rounded` if there's no rounded font?
- 08:06:31 [emilio]
- ... maybe you have only arial and times?
- 08:06:44 [emilio]
- ... what do you fallback to?
- 08:06:56 [emilio]
- florian: I'd propose just for it not to match so it falls back to the next of the list
- 08:07:19 [emilio]
- leaverou: if we need more granularity to system ui fonts why mapping them to apple?
- 08:07:35 [emilio]
- ... why not system-ui-titletext?
- 08:07:59 [emilio]
- myles: when a platform has a different font for titletext we can consider that
- 08:08:21 [dlibby]
- dlibby has left #css
- 08:08:35 [emilio]
- RESOLVED: Add them with the `ui-` prefix and make them not match if they're not available
- 08:08:56 [emilio]
- topic: end
- 08:09:00 [fantasai]
- Also resolve that the WG encourages Apple to make their system fonts available under regular names :)
- 08:09:16 [emilio]
- Topic: Mathml
- 08:09:31 [bkardell_]
- https://mathml-refresh.github.io/mathml-core/
- 08:09:45 [emilio]
- bkardell_: just letting everybody know that the spec considerably complete, and so is our initial implementation
- 08:09:53 [emilio]
- bkardell_: lots of wpt, lots of answers in the spec
- 08:10:01 [emilio]
- ... total css proposals amount to for
- 08:10:07 [emilio]
- ... *four
- 08:10:14 [emilio]
- ... one of them is `display: math`
- 08:10:32 [emilio]
- ... other three is to display the information that you need to extend mathml
- 08:11:18 [emilio]
- ... 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 [emilio]
- 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 [emilio]
- Topic: ScrollTimeline
- 08:11:57 [lajava]
- lajava has joined #css
- 08:12:55 [zcorpan]
- zcorpan has joined #css
- 08:12:56 [emilio]
- 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 [emilio]
- ... so we got lots of feedback from devs that it's hard to compute the right offsets
- 08:13:37 [fantasai]
- basically, same problem as scroll-snap had in the beginning...
- 08:13:59 [emilio]
- ... 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 [emilio]
- majidvp: flackr has done a polyfill for that and the api
- 08:14:32 [nigel_]
- nigel_ has joined #css
- 08:14:44 [emilio]
- ... what we're proposing here is specifying offsets in terms of intersection observer semantics
- 08:14:44 [heycam]
- q+
- 08:15:17 [emilio]
- ... which is start and end of animation as intersection observer offsets
- 08:15:32 [emilio]
- ... just one-dimensional rather than two-dimensional
- 08:15:52 [emilio]
- majidvp: [goes through the proposal in https://github.com/WICG/scroll-animations/issues/51]
- 08:15:58 [emilio]
- github: https://github.com/WICG/scroll-animations/issues/51
- 08:16:50 [emilio]
- majidvp: we're also proposing a function-like syntax
- 08:17:08 [emilio]
- ... but let me show demos
- 08:18:58 [emilio]
- majidvp: [goes through https://flackr.github.io/scroll-timeline/demo/parallax/]
- 08:21:09 [inamori_]
- inamori_ has joined #css
- 08:21:42 [emilio]
- majidvp: [goes back to the proposed css syntax]
- 08:24:37 [dauwhe]
- dauwhe has joined #css
- 08:24:46 [emilio]
- ... there are some open questions like how to fix the circularity in the case layout moves the element while animation
- 08:25:00 [emilio]
- ... proposal is to freeze the offset when the animation starts
- 08:25:20 [heycam]
- q-
- 08:25:31 [emilio]
- ... also how intersections are computed and such
- 08:25:43 [emilio]
- ... these are open questions that we're trying to work through
- 08:25:48 [emilio]
- ... not proposing concrete solution
- 08:26:07 [emilio]
- ... happy to answer questions / feedback / concerns
- 08:26:27 [emilio]
- smfr: I like the way it generally looks, and I like the IntersectionObserver thing
- 08:26:33 [emilio]
- ... seems much more natural
- 08:26:34 [dlibby]
- dlibby has joined #css
- 08:27:04 [emilio]
- ... can you do something like a spinner that stops as soon as soon as you scroll away?
- 08:27:28 [emilio]
- majidvp: ScrollTimeline should not solve that, you need a trigger for that...
- 08:28:19 [emilio]
- ... 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 [emilio]
- iank_: you can polyfill that already with intersection observer, I think it's nice to keep it focused
- 08:29:05 [emilio]
- dino: I think this would be a simple addition now that we have the range to address this use case
- 08:29:37 [emilio]
- smfr: there's also the case where you stop the animation but let it run to complete a cycle
- 08:29:55 [emilio]
- ... so that it comes back into the viewport in a good position
- 08:30:01 [zcorpan]
- zcorpan has joined #css
- 08:30:13 [emilio]
- majidvp: may be addressable with the range
- 08:30:31 [zcorpan]
- zcorpan has joined #css
- 08:30:41 [emilio]
- smfr: another piece of feedback is that it seems that the css api is getting a bit out of control
- 08:30:48 [emilio]
- ... I'd be fine with just a JS api
- 08:31:10 [emilio]
- majidvp: that's the opposite of the last F2F discussion, but it's fine for me...
- 08:31:59 [heycam]
- heycam: the small additions to the Intersection Observer model, they sohuld just be added to Intersection Observer itself
- 08:32:05 [emilio]
- majidvp: I think they should be added to the spec even if they're not web-exposed.
- 08:32:23 [emilio]
- heycam: it'd be nice specially if you don't solve the time-based viewport-triggered animation
- 08:32:44 [emilio]
- majidvp: I _think_ you can compute that with the current IntersectionObserver given it provides the intersection area
- 08:33:28 [emilio]
- Rossen_: Looks awesome, what are you asking from us?
- 08:33:45 [emilio]
- majidvp: confirmation of general direction would be great
- 08:34:01 [emilio]
- ... may be nice to bring into csswg-drafts, though may not be that important
- 08:34:06 [emilio]
- Rossen_: I think we could do that
- 08:34:13 [emilio]
- smfr: where does web-animations live?
- 08:34:20 [emilio]
- birtles: CSS
- 08:34:36 [emilio]
- RESOLVED: moved scroll-timeline into csswg-drafts
- 08:34:44 [emilio]
- topic: end
- 08:35:07 [zcorpan]
- zcorpan has joined #css
- 08:35:28 [emilio]
- Topic: [css-text-4] Update on word boundaries, previously know as space expansion and discussed in Toronto (Florian) [i18n]
- 08:35:31 [florian]
- https://drafts.csswg.org/css-text-4/#word-boundaries
- 08:35:52 [emilio]
- florian: at the last f2f I presented a proposal to expand zero width spaces into ideographic spaces
- 08:35:57 [fremy]
- fremy has joined #css
- 08:36:08 [emilio]
- ... I got spec text after the group discussion
- 08:36:22 [emilio]
- ... Another request was to automatically insert them into the markup
- 08:36:35 [emilio]
- ... got review from fantasai and (less) i18n
- 08:37:06 [emilio]
- ... 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 [emilio]
- ... since you can use thai alphabet to write non-thai languages
- 08:37:51 [emilio]
- ... so the group wanted to be more explicit about line-breaking in thai, which is similar to the word boundary injection
- 08:38:07 [emilio]
- ... that's all in text-4, it'd be nice for you to review it
- 08:38:16 [emilio]
- ... will start to write text soon, may tweak naming
- 08:38:30 [emilio]
- ... fantasai was a bit skeptic about the automatic insertion
- 08:38:51 [emilio]
- ... about whether browsers will implement language-dependent analysis
- 08:39:19 [emilio]
- ... I think kindle did that, though kindle does have a bounded number of languages unlike browsers
- 08:39:46 [emilio]
- glenn: I'm with fantasai, don't do it, many business do this
- 08:40:05 [emilio]
- Topic: end
- 08:40:27 [emilio]
- Topic: republishing transforms CR
- 08:40:34 [smfr]
- smfr has joined #css
- 08:40:49 [emilio]
- krit: we got some editorial changes
- 08:41:01 [Rossen_]
- https://drafts.csswg.org/css-transforms/#CR20190214
- 08:41:25 [emilio]
- krit: I don't expect a lot more changes to the spec
- 08:41:39 [emilio]
- ... so I expec to be the last CR before the next step
- 08:42:01 [emilio]
- RESOLVED: publish CR of css-transforms
- 08:42:19 [emilio]
- Topic: Calc for table layout
- 08:42:27 [emilio]
- Github: https://github.com/w3c/csswg-drafts/issues/94
- 08:43:33 [emilio]
- xiaochengh: So the issue is what to do with percentages and calc
- 08:43:51 [emilio]
- ... spec says a bunch of stuff may be treated as auto
- 08:43:59 [fremy]
- "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 [emilio]
- ... I'm proposing changing the MAY into MUST
- 08:44:13 [emilio]
- ... it's pretty complicated if we don't treat it as auto
- 08:44:16 [fremy]
- q+
- 08:44:29 [emilio]
- ... second reason is that this is creating friction when implementing min() / max()
- 08:44:54 [emilio]
- ... calc() is complicated, but min() / max() make it a pretty hardly solvable problem
- 08:45:00 [emilio]
- ... so I propose to make this a MUST
- 08:45:21 [rego]
- rego has joined #css
- 08:45:28 [emilio]
- TabAtkins: this is what dbaron proposed back in the day
- 08:45:48 [emilio]
- ... and we punted min and max because of that
- 08:45:54 [emilio]
- heycam: implementation status?
- 08:46:08 [emilio]
- fremy: all browsers match the spec
- 08:46:26 [emilio]
- ... for normal table layout
- 08:46:38 [emilio]
- ... the algorithm just doesn't make it possible
- 08:47:09 [emilio]
- ... in fixed table layout there's one browser that supports percentages based on the size of the table
- 08:47:29 [emilio]
- ... as to the question of whether we should remove the behavior for normal table layout is fine
- 08:47:55 [emilio]
- ... for fixed layout it'd be nice to also remove it, but Chrome and Safari
- 08:48:18 [emilio]
- ... do respect it so it'd be nice to remove that
- 08:48:37 [emilio]
- ... or add to the spec that it is respected in fixed table layout and how, which should be straight-forward
- 08:48:49 [heycam]
- emilio: there's also the question of whether we should in presence of min and max ...
- 08:49:05 [heycam]
- ... Firefox uesd to treat calc(%) as auto
- 08:49:07 [heycam]
- ... we no longer do that
- 08:49:16 [heycam]
- ... but it raises the question of how min and max behave with only percentages
- 08:49:20 [heycam]
- ... I guess that's fine to resolve?
- 08:49:25 [heycam]
- TabAtkins: I don't want to special case min and max on type
- 08:49:29 [heycam]
- ... that's awkward
- 08:49:45 [heycam]
- ... having min and max work in some case if you have certain shapes of expression inside of it
- 08:50:17 [heycam]
- 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 [heycam]
- fremy: that sounds reasonable to me
- 08:50:43 [heycam]
- .... 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 [heycam]
- ... if you have min(10%, 20%), the computed value will be 10%, so you don't have the problem
- 08:50:58 [heycam]
- .... I would be in favour of that wording
- 08:51:45 [futhark]
- futhark has joined #css
- 08:52:30 [heycam]
- emilio: what about calc(10% + 0)?
- 08:52:35 [heycam]
- ... that's simplifies to 10% in all browsers
- 08:52:47 [heycam]
- Rossen: yes we've resolved that previously
- 08:53:28 [heycam]
- fremy: so what about fixed mode
- 08:53:47 [heycam]
- ... I assume it's probably fine to apply this rule to both?
- 08:53:48 [zcorpan]
- zcorpan has joined #css
- 08:54:02 [heycam]
- RESOLVED: Any math expression of a complex type is treated as auto. Simple typed things continue to work as today.
- 08:54:06 [emilio]
- TabAtkins: https://github.com/w3c/csswg-drafts/issues/3482#issuecomment-451590359
- 08:54:19 [heycam]
- zoe: no objections
- 08:55:27 [emilio]
- Topic: Hanging spaces cannot be scrollable overflow
- 08:55:30 [emilio]
- Github: https://github.com/w3c/csswg-drafts/issues/4297
- 08:56:12 [emilio]
- 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_]
- inamori_ has joined #css
- 08:56:42 [emilio]
- ... but on editable stuff you want to create scrollable overflow
- 08:57:02 [emilio]
- ... blink and webkit agree with me, gecko always treats it as ink overflow, edge always layout overflow
- 08:57:27 [emilio]
- ... proposed resolution is treat hanging spaces as ink overflow in general but layout overflow in editable context
- 08:57:38 [emilio]
- fremy: how did you test for editable context
- 08:58:11 [emilio]
- ... you may be testing a different `white-space` due to UA rules
- 08:58:57 [heycam]
- emilio: it feels weird to special case layout based on editable context, whatever that is
- 08:59:00 [heycam]
- Rossen: why?
- 08:59:15 [heycam]
- emilio: there's no good reason for the layout engine to know the editable state of the DOM
- 08:59:20 [heycam]
- ... in Gecko this all works via UA sheets
- 08:59:34 [heycam]
- ... we change a bunch of stuff when something becomes editable, but it's explained through CSS properties
- 08:59:40 [heycam]
- ... specifying something like this seems quite awkward
- 08:59:53 [heycam]
- florian: make it specific to contenteditable only, and not other kinds of editable, would be weird
- 09:00:03 [heycam]
- ... but if it's all kinds of editable, and good old fashioned textarea, ....
- 09:00:07 [leaverou_]
- But it can be detected with CSS selectors
- 09:00:12 [heycam]
- emilio: if you do that, I would prefer to have some kind of CSS value that causes this effect
- 09:00:25 [heycam]
- ... and specify in HTML or whever that contenteditable and textarea input have this in the UA sheet
- 09:00:40 [heycam]
- florian: if you are editing the content, you never want to not reach the content
- 09:00:56 [heycam]
- ... 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 [heycam]
- emilio: then the UA sheet can have an !important rule
- 09:01:22 [heycam]
- florian: if we define this how is it magical?
- 09:01:30 [heycam]
- emilio: what if it's something slotted into a contenteditable element?
- 09:01:31 [chris]
- chris has joined #css
- 09:01:47 [heycam]
- 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 [heycam]
- ... when you're editing text, it's nice to be able to see the text
- 09:02:12 [heycam]
- ... 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 [heycam]
- emilio: sure
- 09:02:26 [heycam]
- fantasai: it makes sense to allow the UA to make it scrollable overflow when that piece of text is editable
- 09:02:33 [heycam]
- ... how you got to that state, doesn't really matter
- 09:02:45 [heycam]
- emilio: why only when it's editable, and not selectable?
- 09:02:50 [heycam]
- ... the caret movement is pretty much the same
- 09:02:56 [heycam]
- ... don't know why those owuld be different
- 09:03:05 [heycam]
- fantasai: the characters are still there, you can select if you go frmo one line to the next
- 09:03:12 [heycam]
- ... but there's a higher priority on not introducing scrollbars
- 09:03:29 [heycam]
- emilio: can we confirm Chrome is doing what you claim it is?
- 09:03:54 [heycam]
- 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 [heycam]
- emilio: I know how to implement it, just doing want it defined in a magical way
- 09:04:14 [futhark]
- futhark has joined #css
- 09:04:55 [heycam]
- -- end --
- 09:05:04 [heycam]
- github-bot: end
- 09:05:04 [github-bot]
- heycam, Sorry, I don't understand that command. Try 'help'.
- 09:05:07 [heycam]
- github-bot: end topic
- 09:13:48 [nigel]
- nigel has joined #css
- 09:21:57 [ericc]
- ericc has joined #css
- 09:51:22 [projector]
- projector has joined #css
- 09:51:52 [Rossen]
- Rossen has joined #css
- 09:52:22 [shans]
- shans has joined #css
- 09:52:52 [sylvaing]
- sylvaing has joined #css
- 09:53:23 [leaverou]
- leaverou has joined #css
- 09:53:53 [plinss_]
- plinss_ has joined #css
- 10:03:48 [drousso]
- drousso has joined #css
- 10:17:55 [smfr]
- smfr has joined #css
- 11:30:40 [futhark]
- futhark has joined #css
- 11:37:45 [mattwoodrow]
- mattwoodrow has joined #css
- 11:53:19 [futhark]
- futhark has joined #css
- 12:02:43 [birtles]
- birtles has joined #css
- 12:06:17 [rniwa]
- rniwa has joined #css
- 12:13:09 [dauwhe]
- dauwhe has joined #css
- 12:16:05 [futhark]
- futhark has joined #css
- 12:46:17 [dino]
- dino has joined #css
- 12:51:08 [Rossen_]
- Rossen_ has joined #css
- 12:57:17 [futhark]
- futhark has joined #css
- 12:59:49 [karl]
- karl has joined #css
- 13:04:03 [Zakim]
- Zakim has left #css
- 13:27:24 [lajava]
- lajava has joined #css
- 13:50:58 [skk]
- skk has joined #css
- 13:52:38 [xfq]
- xfq has joined #css
- 14:22:38 [drousso]
- drousso has joined #css
- 14:42:44 [ericc]
- ericc has joined #css
- 14:58:04 [lajava]
- lajava has joined #css
- 15:03:58 [Tav]
- Tav has joined #css
- 15:19:02 [ed]
- ed has joined #css
- 19:19:35 [atsushi]
- atsushi has joined #css
- 20:58:16 [ericc]
- ericc has joined #css
- 21:36:41 [rachelandrew]
- rachelandrew has joined #css
- 21:36:41 [esprehn]
- esprehn has joined #css
- 21:44:07 [ericc]
- ericc has joined #css
- 21:51:21 [ericc]
- ericc has joined #css
- 22:00:23 [dauwhe]
- dauwhe has joined #css
- 22:15:31 [ericc]
- ericc has joined #css
- 22:37:40 [AmeliaBR]
- AmeliaBR has joined #css
- 00:03:10 [plh]
- plh has joined #css
- 00:03:20 [stantonm]
- stantonm has joined #css
- 00:03:25 [dauwhe]
- dauwhe has joined #css
- 00:05:54 [duga]
- duga has joined #css
- 00:09:26 [ericc]
- ericc has joined #css
- 00:09:57 [skk]
- skk has joined #css
- 00:11:59 [nigel]
- nigel has joined #css
- 00:15:41 [dauwhe]
- dauwhe has joined #css
- 00:25:04 [foolip]
- plinss plinss_ which of you should I message?
- 00:25:38 [plinss]
- either, but 'plinss' is always-on
- 00:28:50 [duga]
- duga has joined #css
- 00:31:04 [inamori_]
- inamori_ has joined #css
- 00:32:56 [drousso]
- drousso has joined #css
- 00:35:10 [kzms2]
- kzms2 has joined #css
- 00:35:45 [dauwhe]
- dauwhe has joined #css
- 00:35:46 [drousso_]
- drousso_ has joined #css
- 00:41:05 [dino]
- dino has joined #css
- 00:49:37 [duga]
- duga has joined #css
- 00:52:19 [birtles]
- birtles has joined #css
- 00:53:47 [mattwoodrow]
- mattwoodrow has joined #css
- 00:58:26 [tantek]
- tantek has joined #css
- 01:06:51 [drousso]
- drousso has joined #css
- 01:08:23 [drousso_]
- drousso_ has joined #css
- 01:09:09 [ericc]
- ericc has joined #css
- 01:13:25 [duga]
- duga has joined #css
- 01:19:30 [karl]
- karl has joined #css
- 01:20:31 [dauwhe]
- dauwhe has joined #css
- 01:23:28 [inamori_]
- inamori_ has joined #css
- 01:28:48 [plh]
- plh has joined #css
- 01:34:40 [drousso]
- drousso has joined #css
- 01:39:19 [atsushi]
- atsushi has joined #css
- 01:39:23 [karl]
- karl has joined #css
- 01:45:31 [plh]
- plh has joined #css
- 01:46:22 [skk]
- skk has joined #css
- 01:48:33 [ericc]
- ericc has joined #css
- 02:00:13 [dauwhe]
- dauwhe has joined #css
- 02:00:30 [duga]
- duga has joined #css
- 02:00:55 [rniwa]
- rniwa has joined #css
- 02:01:10 [jihye]
- jihye has joined #css
- 02:02:01 [zcorpan]
- zcorpan has joined #css
- 02:02:19 [dino]
- dino has joined #css
- 02:02:38 [anssik]
- anssik has joined #css
- 02:05:03 [tdresser]
- tdresser has joined #css
- 02:06:07 [karl]
- karl has joined #css
- 02:06:13 [myles]
- myles has joined #css
- 02:06:37 [Dongwoo]
- Dongwoo has joined #css
- 02:07:06 [nigel]
- nigel has joined #css
- 02:07:31 [dauwhe]
- dauwhe has joined #css
- 02:07:31 [Dongwoo]
- Dongwoo has joined #css
- 02:09:03 [skk]
- skk has joined #css
- 02:11:09 [AmeliaBR]
- AmeliaBR has joined #css
- 02:13:34 [foolip]
- fantasai: do you have a link to dbaron's clever gradient test, in plinss's harness?
- 02:13:50 [DavidClarke]
- DavidClarke has joined #css
- 02:13:58 [DavidClarke]
- DavidClarke has left #css
- 02:14:28 [fantasai]
- foolip: test at http://test.csswg.org/suites/css-backgrounds-3_dev/nightly-unstable/html4/box-shadow-blur-definition-001.htm
- 02:15:15 [fantasai]
- test harness results lists http://test.csswg.org/harness/results/css-backgrounds-3_dev/grouped/box-shadow-blur-definition-001/
- 02:15:41 [fantasai]
- detailed results http://test.csswg.org/harness/details/css-backgrounds-3_dev/box-shadow-blur-definition-001/
- 02:15:54 [fantasai]
- running the test http://test.csswg.org/harness/test/css-backgrounds-3_dev/single/box-shadow-blur-definition-001/format/html4/
- 02:17:02 [liam]
- middle stripe is yellow here like the page background
- 02:17:17 [fantasai]
- yellow o_O?
- 02:17:39 [liam]
- i.e. browser default (which i think i configured years ago)
- 02:18:37 [fantasai]
- liam, CSSWG test running assumes some things, specifically https://test.csswg.org/suites/css-backgrounds-3_dev/nightly-unstable/#common
- 02:18:55 [fantasai]
- one of those things is white background :)
- 02:19:15 [liam]
- ahm so it is
- 02:19:19 [liam]
- ok
- 02:19:38 [liam]
- although it also says, Tests should avoid relying on these assumptions unless necessary.
- 02:21:53 [liam]
- looks like the test passes now
- 02:22:38 [liam]
- (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 [foolip]
- fantasai: thanks!
- 02:40:10 [tdresser]
- tdresser has joined #css
- 02:53:02 [drousso_]
- drousso_ has joined #css
- 02:53:54 [tdresser]
- tdresser has joined #css
- 02:54:40 [inamori_]
- inamori_ has joined #css
- 03:04:38 [nigel]
- nigel has joined #css
- 03:09:08 [duga]
- duga has joined #css
- 03:10:00 [mattwoodrow]
- mattwoodrow has joined #css
- 03:10:37 [ericc]
- ericc has joined #css
- 03:13:06 [inamori_]
- inamori_ has joined #css
- 03:16:43 [atsushi]
- atsushi has joined #css
- 03:18:23 [dauwhe]
- dauwhe has joined #css
- 03:20:37 [ericc_]
- ericc_ has joined #css
- 03:28:48 [zcorpan]
- zcorpan has joined #css
- 03:34:06 [dauwhe]
- dauwhe has joined #css
- 03:34:44 [ericc]
- ericc has joined #css
- 03:35:31 [zcorpan]
- zcorpan has joined #css
- 03:40:02 [ericc]
- ericc has joined #css
- 03:44:39 [zcorpan]
- zcorpan has joined #css
- 03:49:56 [zcorpan]
- zcorpan has joined #css
- 03:50:36 [dauwhe]
- dauwhe has joined #css
- 03:53:41 [dauwhe]
- dauwhe has joined #css
- 03:56:42 [mattwoodrow]
- mattwoodrow has joined #css
- 03:58:31 [inamori_]
- inamori_ has joined #css
- 04:03:07 [dauwhe]
- dauwhe has joined #css
- 04:05:01 [sanketj]
- sanketj has joined #css
- 04:08:15 [inamori_]
- inamori_ has joined #css
- 04:18:39 [zcorpan]
- zcorpan has joined #css
- 04:19:52 [duga]
- duga has joined #css
- 04:22:10 [tantek]
- tantek has joined #css
- 04:22:17 [tdresser]
- tdresser has joined #css
- 04:22:39 [duga]
- duga has joined #css
- 04:24:07 [karl]
- karl has joined #css
- 04:24:52 [dauwhe]
- dauwhe has joined #css
- 04:29:53 [rego]
- rego has joined #css
- 04:30:24 [rniwa]
- rniwa has joined #css
- 04:30:44 [ericc_]
- ericc_ has joined #css
- 04:32:07 [nigel]
- nigel has joined #css
- 04:33:11 [myles]
- myles has joined #css
- 04:33:51 [plh]
- plh has joined #css
- 04:34:06 [drousso]
- drousso has joined #css
- 04:34:54 [dino]
- dino has joined #css
- 04:35:01 [bkardell_]
- bkardell_ has joined #css
- 04:36:02 [aboxhall_]
- aboxhall_ has joined #css
- 04:36:22 [rachelandrew_]
- rachelandrew_ has joined #css
- 04:37:22 [tdresser]
- tdresser has joined #css
- 04:37:47 [zcorpan]
- zcorpan has joined #css
- 04:37:49 [zcorpan]
- zcorpan has joined #css
- 04:42:06 [skk]
- skk has joined #css
- 04:46:55 [atsushi]
- atsushi has joined #css
- 04:50:59 [dauwhe_]
- dauwhe_ has joined #css
- 04:51:13 [karl]
- karl has joined #css
- 04:52:41 [dino]
- dino has joined #css
- 04:56:26 [inamori_]
- inamori_ has joined #css
- 05:09:03 [mattwoodrow]
- mattwoodrow has joined #css
- 05:11:15 [tdresser]
- tdresser has joined #css
- 05:19:14 [dino]
- dino has joined #css
- 05:20:06 [smfr]
- smfr has joined #css
- 05:24:15 [tdresser]
- tdresser has joined #css
- 05:24:34 [duga]
- duga has joined #css
- 05:26:54 [zcorpan]
- zcorpan has joined #css
- 05:27:32 [dauwhe]
- dauwhe has joined #css
- 05:27:55 [ericc]
- ericc has joined #css
- 05:28:57 [smfr]
- smfr has joined #css
- 05:29:26 [zcorpan_]
- zcorpan_ has joined #css
- 05:29:58 [myles]
- myles has joined #css
- 05:30:13 [nigel]
- nigel has joined #css
- 05:30:37 [rniwa]
- rniwa has joined #css
- 05:31:33 [drousso]
- drousso has joined #css
- 05:31:35 [fergal_daly]
- fergal_daly has joined #css
- 05:32:35 [zcorpan__]
- zcorpan__ has joined #css
- 05:33:03 [kzms2]
- kzms2 has joined #css
- 05:33:36 [gsnedders]
- 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]
- mattwoodrow has joined #css
- 05:33:46 [dauwhe_]
- dauwhe_ has joined #css
- 05:33:50 [gsnedders]
- css-tables is surprisingly high up there
- 05:34:17 [dino]
- dino has joined #css
- 05:34:34 [dino]
- dino has joined #css
- 05:36:22 [tantek]
- tantek has joined #css
- 05:36:44 [nigel_]
- nigel_ has joined #css
- 05:42:41 [skk]
- skk has joined #css
- 05:45:48 [atsushi]
- atsushi has joined #css
- 05:48:46 [astearns]
- gsnedders: is that number of 4/4 tests, or percentage of tests that are 4/4, or ??
- 05:51:16 [smfr]
- smfr has joined #css
- 05:51:19 [tdresser]
- tdresser has joined #css
- 05:54:09 [inamori_]
- inamori_ has joined #css
- 05:55:05 [skk]
- skk has joined #css
- 05:55:09 [gsnedders]
- astearns: percentage of tests that are 4/4
- 06:05:39 [liam]
- liam has joined #css
- 06:22:50 [mattwoodrow]
- mattwoodrow has joined #css
- 06:30:16 [duga]
- duga has joined #css
- 06:32:17 [rniwa]
- rniwa has joined #css
- 06:33:22 [dauwhe]
- dauwhe has joined #css
- 06:38:19 [myles]
- myles has joined #css
- 06:59:12 [plh]
- plh has joined #css
- 07:04:35 [nigel]
- nigel has joined #css
- 07:10:44 [myles]
- myles has joined #css
- 07:11:14 [myles]
- myles has joined #css
- 07:16:12 [tdresser]
- tdresser has joined #css
- 07:17:42 [Ms2ger]
- Ms2ger has joined #css
- 07:21:58 [nigel]
- nigel has joined #css
- 07:22:32 [nigel_]
- nigel_ has joined #css
- 07:23:03 [duga]
- duga has joined #css
- 07:24:02 [duga]
- duga has joined #css
- 07:24:07 [dauwhe]
- dauwhe has joined #css
- 07:27:28 [ericc]
- ericc has joined #css
- 07:27:47 [zcorpan]
- zcorpan has joined #css
- 07:28:09 [zcorpan]
- zcorpan has joined #css
- 07:31:12 [myles]
- myles has joined #css
- 07:31:50 [smfr]
- smfr has joined #css
- 07:31:51 [drousso]
- drousso has joined #css
- 07:31:59 [nigel]
- nigel has joined #css
- 07:32:04 [zcorpan]
- zcorpan has joined #css
- 07:32:15 [kereliuk]
- kereliuk has joined #css
- 07:33:21 [birtles]
- birtles has joined #css
- 07:33:30 [duga]
- duga has joined #css
- 07:33:47 [plinss_]
- plinss_ has joined #css
- 07:34:12 [plh]
- plh has joined #css
- 07:34:44 [emilio]
- emilio has joined #css
- 07:35:24 [dino]
- dino has joined #css
- 07:35:44 [tantek]
- tantek has joined #css
- 07:36:26 [skk]
- skk has joined #css
- 07:36:44 [smfr]
- smfr has joined #css
- 07:49:53 [foolip]
- RRSAgent: where are the logs?
- 07:49:53 [RRSAgent]
- I'm logging. Sorry, nothing found for 'where are the logs'
- 07:59:56 [plh]
- plh has joined #css
- 08:00:07 [nigel_]
- nigel_ has joined #css
- 08:00:23 [skk_]
- skk_ has joined #css
- 08:01:51 [tantek]
- RRSAgent, pointer?
- 08:01:51 [RRSAgent]
- See https://www.w3.org/2019/09/15-css-irc#T08-01-51
- 08:01:56 [tantek]
- foolip: ^^^
- 08:02:02 [tantek]
- RRSAgent, make logs public
- 08:04:53 [lajava]
- lajava has joined #css
- 08:06:14 [mattwoodrow]
- mattwoodrow has joined #css
- 08:19:11 [karl]
- karl has joined #css
- 08:23:52 [liam]
- liam has joined #css
- 08:25:18 [dauwhe]
- dauwhe has joined #css
- 08:27:05 [foolip]
- tantek: thanks!
- 08:28:29 [smfr]
- smfr has joined #css
- 08:30:39 [drousso]
- drousso has joined #css
- 08:30:46 [zcorpan]
- zcorpan has joined #css
- 08:30:57 [myles]
- myles has joined #css
- 08:31:04 [drousso]
- drousso has joined #css
- 08:31:25 [zcorpan]
- zcorpan has joined #css
- 08:33:06 [dino]
- dino has joined #css
- 08:34:36 [ericc]
- ericc has joined #css
- 08:35:01 [nigel_]
- nigel_ has joined #css
- 08:35:06 [dauwhe]
- dauwhe has joined #css
- 08:35:46 [nigel]
- nigel has joined #css
- 08:41:16 [luyan]
- luyan has joined #css
- 08:41:29 [luyan]
- aaaaa
- 08:44:11 [dauwhe]
- dauwhe has joined #css
- 08:45:50 [luyan]
- luyan has joined #css
- 08:46:18 [luyan]
- luyan has left #css
- 08:46:33 [skk]
- skk has joined #css
- 08:55:43 [TabAtkins]
- ...why is trackbot our only op?
- 08:57:19 [gsnedders]
- trackbot owns us.
- 08:57:19 [trackbot]
- Sorry, gsnedders, I don't understand 'trackbot owns us.'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.
- 08:57:34 [gsnedders]
- thanks trackbot.
- 08:57:36 [TabAtkins]
- trackbot is a comrade
- 08:57:36 [trackbot]
- Sorry, TabAtkins, I don't understand 'trackbot is a comrade'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.
- 09:07:43 [dauwhe]
- dauwhe has joined #css
- 09:12:27 [plh]
- plh has joined #css
- 09:15:45 [mattwoodrow]
- mattwoodrow has joined #css
- 09:31:45 [nigel]
- nigel has joined #css
- 09:54:00 [atsushi]
- atsushi has joined #css
- 10:05:51 [projector]
- projector has joined #css
- 10:06:21 [Rossen]
- Rossen has joined #css
- 10:06:51 [shans]
- shans has joined #css
- 10:07:21 [sylvaing]
- sylvaing has joined #css
- 10:07:51 [leaverou]
- leaverou has joined #css
- 10:08:22 [plinss_]
- plinss_ has joined #css
- 10:15:46 [plh]
- plh has joined #css
- 10:47:27 [plh]
- plh has joined #css
- 11:28:47 [tdresser]
- tdresser has joined #css
- 12:46:48 [plh]
- plh has joined #css
- 12:49:05 [karl]
- karl has joined #css
- 13:17:25 [tdresser]
- tdresser has joined #css
- 13:23:24 [dauwhe]
- dauwhe has joined #css
- 13:28:19 [antonp]
- antonp has joined #css
- 13:28:27 [tdresser]
- tdresser has joined #css
- 13:37:27 [tdresser]
- tdresser has joined #css
- 13:49:42 [dauwhe]
- dauwhe has joined #css
- 13:50:31 [innovati]
- innovati has joined #css
- 14:02:02 [tdresser]
- tdresser has joined #css
- 14:09:16 [projector]
- projector has joined #css
- 14:09:46 [Rossen]
- Rossen has joined #css
- 14:10:16 [shans]
- shans has joined #css
- 14:10:46 [sylvaing]
- sylvaing has joined #css
- 14:11:16 [leaverou]
- leaverou has joined #css
- 14:11:47 [plinss_]
- plinss_ has joined #css
- 14:13:19 [mattwoodrow]
- mattwoodrow has joined #css
- 14:46:44 [atsushi]
- atsushi has joined #css
- 15:29:59 [lajava]
- lajava has joined #css
- 15:56:05 [bdc]
- bdc has joined #css
- 16:19:51 [plh]
- plh has joined #css