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