01:20:35 innovati has joined #css 04:36:43 myles has joined #css 05:54:21 futhark has joined #css 07:01:36 sanketj has joined #css 07:25:17 andruud has joined #css 07:25:45 astearns has changed the topic to: TPAC agenda: https://github.com/w3c/csswg-drafts/projects/39 07:25:56 zakim, start meeting 07:25:56 RRSAgent, make logs Public 07:25:58 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 07:26:57 present+ 07:27:03 present+ 07:30:20 nigel has joined #css 07:31:16 present+ 07:32:33 romain has joined #css 07:32:40 present+ 07:34:45 oriol has joined #css 07:35:10 bkardell_ has joined #css 07:36:33 ydaniv has joined #css 07:36:41 present+ 07:39:21 Present+ 07:40:03 fremy has joined #css 07:40:14 present+ 07:40:51 present+ 07:43:02 mrobinson has joined #css 07:43:06 present+ 07:43:43 present+ 07:44:12 present+ 07:44:16 present+ 07:44:24 ScribeNick: emilio 07:44:33 present+ 07:44:39 nicole_ has joined #css 07:45:02 [introductions] 07:45:09 chris has joined #css 07:45:31 noamr has joined #css 07:45:43 present+ 07:45:47 Oriol Brufau, Igalia 07:46:00 TabAtkins, Google 07:46:04 Emilio, Mozilla 07:46:14 Chris Lilley, W3C 07:46:36 Bert has joined #css 07:46:36 François Remy, Invited Expert 07:46:39 The observers who are joining us: Munira Tursunova and Daniil Sakhapov - both Google Chrome. 07:46:53 Vladimir Levin, Google 07:47:06 Dominik Röttsches, Google 07:47:11 Rachel Andrew, Google Chrome 07:47:19 Rune, Google 07:47:21 Bramus, Google 07:47:27 Nicole Sullivan, Google 07:47:30 Martin Robinson, Igalia 07:47:42 Miriam Suzanne, Invited Expert 07:47:51 Bert Bos, W3C 07:48:22 Yehonatan Daniv, Wix 07:48:26 Romain Menke, Observer 07:49:21 projector has joined #css 07:49:51 leaverou has joined #css 07:50:12 q+ 07:50:22 Rossen has joined #css 07:50:24 github-bot, take up https://github.com/w3c/csswg-drafts/issues/9162 07:50:24 Topic: [css-page-3] Publish an updated WD 07:50:24 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/9162. 07:50:27 ack eeps 07:50:32 ack eeeps 07:50:47 myles has joined #css 07:50:50 chris: I had a look, seems fine 07:50:52 shans has joined #css 07:50:58 ... list of changes is not up to date 07:50:58 it's already published https://www.w3.org/TR/css-page-3/#changes 07:51:09 astearns: it's already done, fantasai did that last night 07:51:22 sylvaing has joined #css 07:51:25 https://www.w3.org/TR/2023/WD-css-page-3-20230914/ 07:51:35 chris: sec and privacy section should separated 07:51:44 present+ myles 07:51:48 s/should/should be 07:51:51 astearns: is that a requirement? 07:52:05 chris: the questionaire for horizontal review asks for those 07:53:26 astearns: proposed resolution is to publish an updated WD with updated privacy / sec sections at editors discretion? 07:53:26 chris: sounds fine 07:53:26 fantasai: it's already published 07:53:26 astearns: oh, thought that was the changes stuff 07:53:26 astearns: then close as done 07:53:58 github-bot: take up https://github.com/w3c/csswg-drafts/issues/9163 07:53:58 Topic: [css-gcpm-3] Publish an updated WD 07:53:58 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/9163. 07:54:00 astearns: this one also needs an updated changes section 07:54:12 chris: does it? 07:54:21 astearns: fantasai is not an editor of this one so yes 07:54:38 astearns: we can take a resolution to publish once the changes section is in place 07:54:42 current WD of gcpm is still https://www.w3.org/TR/2014/WD-css-gcpm-3-20140513/ 07:54:52 astearns: objections to that? 07:55:07 RESOLVED: Publish gcpm wd once the changes section is done 07:55:15 florian: q, is the editor able to do that? 07:55:17 chris: I can 07:55:33 ntim has joined #css 07:55:38 astearns: thanks! I wonder if somebody would volunteer for being an editor? 07:55:41 [crickets] 07:55:43 munira has joined #css 07:55:56 rachelandrew: is this generated content for paged media? 07:55:57 s/editor able/editor available/ 07:56:01 astearns: yes 07:56:14 RESOLVED: Add rachelandrew as an editor to gcpm 07:56:29 s/editor/co-editor 07:56:40 github-bot: take up https://github.com/w3c/csswg-drafts/issues/9317 07:56:41 Topic: [css-nesting-1] Relaxed nesting and var() 07:56:41 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/9317. 07:56:45 IRC nicks: Daniil Sakhapov's nick is sakhapov, Munira Tursunova is moonira 07:57:13 andruud: When implementing relaxed parsing for nesting 07:57:31 ... we hit this issue where if there's any var() function we ignore the grammar 07:57:41 ... so if you're unlucky with your child selector 07:58:23 ... and you can get O(n^2) behavior if you're very unlucky with the child selector name 07:58:23 q+ 07:58:23 ack chris 07:58:32 ... there are different ways to fix it but I think the easiest one is disallowing {} in non-custom declarations 07:58:39 ack dbaron 07:59:25 dbaron: If we say that our future constraint is that if we have braces in standard property values it has to be the whole value, that seems fine except for shorthands 07:59:32 ... so I wonder how likely we think that is 07:59:59 TabAtkins: we have no plans ever recorded to use {} in a property except for embedding properties in shorthands 08:00:19 dbaron: I'm ok with the constraint, I think in reality it might mean never use curly braces in values, but I think that's fine 08:00:28 TabAtkins: at least on the top level, yeah 08:00:54 TabAtkins: generally in support. The problem here is really uncommon 08:01:34 ... I think when it occurs is very undesirable, and it's a low impact change to make it desirable and fast 08:01:37 proposed resolution: if we ever allow {} in properties, it must be the whole value 08:01:41 s/desirable/reliable 08:02:10 TabAtkins: a notable part of this is, this will be recognized at the parsing level 08:02:41 fremy: the whole value means top level curly brackets right? 08:02:43 TabAtkins: yes 08:02:55 RESOLVED: if we ever allow {} in properties, it must be the whole value 08:03:04 cathiechen has joined #css 08:03:37 emilio: can we get a more specific resolution? The current one doesn't make it invalid w/ var() 08:03:49 TabAtkins: happy to do that 08:04:00 proposed resolution: And a non-conforming top-level {} invalidates the property even in the presence of a var() 08:04:51 emilio: does this apply to custom properties? 08:05:03 TabAtkins: no 08:05:10 emilio: but the same problem does apply right? 08:05:27 TabAtkins: yeah but it's harder to screw up there and people do put braces in those 08:05:56 emilio: is it weird that a parsing rule applies to some properties but not others 08:06:13 TabAtkins: it exists already 08:06:19 emilio: oh so you can't put a child ... 08:06:28 to trigger this for a custom prop, you need to write a rule that looks like `--foo:hover {...}` 08:06:39 TabAtkins: if you try to write the rule ^ it is already impossible to parse as a rule 08:06:46 TabAtkins: you have to respell it as --foo 08:06:52 emilio: Ok 08:06:53 s/--foo/:is(--foo) 08:07:26 emilio: we need to exclude some properties from that resolution? 08:07:53 TabAtkins: yes 08:07:57 proposed: And a non-conforming top-level {} invalidates non-custom properties even in the presence of a var() 08:08:19 miriam: objections? 08:08:21 RESOLVED: And a non-conforming top-level {} invalidates non-custom properties even in the presence of a var() 08:09:07 romain has joined #css 08:09:07 github-bot: take up https://github.com/w3c/csswg-drafts/issues/9301 08:09:07 Topic: URL encoding of CSS values 08:09:07 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/9301. 08:09:22 TabAtkins: basic question is what encodings are used by things in the platform to parse URLs 08:09:25 ... there's very little interop 08:10:18 ... but with the tests that show up right now it seems everybody uses utf-8 for @import 08:10:18 ... but in a stylesheet it uses whatever the stylesheet encoding is 08:10:18 ... annevk wants to make it explicit 08:10:49 andreubotella has joined #css 08:10:49 ... is everyone fine with that? 08:10:49 q? 08:10:49 ack TabAtkins 08:10:49 ... zcorpan mentions that firefox using utf-8 for all URLs 08:10:49 ... and seems to be fine with that 08:10:59 ... nobody is concerned about compat fallout 08:11:03 I would prefer to use UTF-8 always 08:11:06 q+ 08:11:08 ... nobody really uses non-ascii-compatible stuff 08:12:23 ... so really just a question of standardizing it 08:12:23 ack chris 08:12:23 ... two choices: all urls are utf-8, or @import utf-8 and sheet encoding for the rest 08:12:23 q+ 08:12:23 chris: I'd prefer utf-8 everywhere 08:12:23 emilio: +1 to that, seems better to be consistent 08:12:23 ack fremy 08:12:23 fremy: is that likely to create invalid files? 08:12:25 q+ to ask a silly question 08:12:26 ntim has joined #css 08:12:28 +1 to chris’s remark 08:12:30 emilio: wdym as invalid? 08:12:51 fremy: you may end up with content that is not parsable in the encoding 08:12:58 TabAtkins: fix is using utf-8 08:13:15 fremy: why do we bother to allow utf-8 if the file is in a different encoding 08:13:39 TabAtkins: it's not when you parse the file, it's about how you feed it to the url parser 08:13:59 ack myles 08:13:59 myles, you wanted to ask a silly question 08:14:11 myles: is the proposal that a stylesheet is in an encoding, you find a url and switch encoding? 08:14:32 TabAtkins: no, you parse as normal but you feed the url parser telling it that it's utf-8 08:14:41 IIUC this is for url-encoded bytes (%20 and so on) 08:14:43 ack dbaron 08:14:54 dbaron: there is a very old backwards compat behavior which is that URLs carry around the encoding of the document that contained them 08:15:20 ... so that when the network fetch happens you send the bytes to the server instead of a decoded version of them 08:15:43 ... ideally that should only happen when this backwards compat hack is required 08:15:55 ... and has been phased out generally to use utf-8 rather than that 08:16:41 myles: so you get a file, decode decode decode, some stylesheet has a URL and you need to go back and send those bytes rather than the decoded stuff? 08:17:00 dbaron: the new old way of doing it, not the old old way, is that you store the encoding of the thing in which you found the url along the url 08:17:17 ... purpose of that is that the server gets the same bytes as the document 08:17:41 ... which is a horrible hack to mimic the old old behavior 08:17:53 ... which was where the web just carried bytes around 08:18:24 myles: So the new old behavior is you round-trip (go bytes to encoding, and then when the request go back to bytes) 08:18:42 dbaron: yeah, and there's a migration away from that where we just send utf-8 to the server 08:18:58 ... not sure what the status of that migration is 08:19:10 ... clearly there's a difference between @import and other urls here 08:19:10 present+ 08:19:44 myles: so proposal at hand is you decode, see a url, then decode those bytes as utf-8? 08:20:09 TabAtkins: dbaron explained it better, when we put the url in the network stack we just stop carrying that encoding and always put it as utf-8 08:20:14 myles: perfect 08:20:22 dbaron: hope my memory about this is right 08:20:52 TabAtkins: proposal is for all urls we encode them as utf-8 when they go down the network stack in accordance with the url standard's recomendation 08:21:07 RESOLVED: for all urls we encode them as utf-8 when they go down the network stack 08:21:26 github-bot: take up https://github.com/w3c/csswg-drafts/issues/8959 08:21:26 Topic: UA stylesheets in CSS specs cause interop issues 08:21:26 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/8959. 08:21:57 TabAtkins: zcorpan pointed out that we have a bunch of UA sheet fragments scattered 08:22:16 ... it's inconsistent, unclear if they should be normative 08:22:22 ... and leads to interop issue 08:22:37 ... some people's preference is the html spec should have the ua sheet 08:22:43 Tab's proposal: https://github.com/w3c/csswg-drafts/issues/8959#issuecomment-1591609223 08:22:50 ... but we have different maturity levels 08:22:52 zcorpan's addition: https://github.com/w3c/csswg-drafts/issues/8959#issuecomment-1600346659 08:23:11 q+ 08:23:12 ... so my proposal is that all normative sheets should be normative, and when the spec is mature we move them to html 08:23:25 astearns: what level of maturity? 08:23:42 q+ 08:23:44 TabAtkins: we have some leeway there, so CR or earlier 08:23:49 +1 to TabAtkins's proposal, with the caveat we should perhaps check if all the existing ones were intended to be normative 08:23:52 ... if we have 2 impls 08:23:57 s/CR/CR exit/ 08:24:00 q? 08:24:03 miriam: there's some MUST vs not discussion 08:24:04 q+ 08:24:23 fantasai: this is only for the HTML stylesheet, not only for UA rules that apply to all elements 08:24:27 s/MUST vs not/MUST vs OUGHT/ 08:24:43 me not sure 08:24:55 q+ 08:25:02 s/OUGHT/SHOULD/ 08:25:02 fantasai: if you have global ::something styles they should not live in html because they're not html-specific right? 08:25:20 TabAtkins: they don't need to live in html but they should be marked as normative 08:25:31 ack vmpstr 08:25:40 vmpstr: So in view-transitions there's two different stylesheets, a static one and a dynamic one 08:25:47 ... updated based on some algorithm 08:26:00 ... there's no expectation that the dynamic one needs to go in the html spec 08:26:14 TabAtkins: yeah I don't think it'd be useful to pull it out of v-t 08:26:24 ack chris 08:26:25 ... having a centralized place makes it easier for both authors and vendors 08:27:35 q+ 08:27:35 chris: the problem we try to solve is having html and css wpts as different things and implementations disagreeing, and I don't think this solves it? 08:27:35 q+ 08:27:35 TabAtkins: I don't consider that our problem 08:27:44 ... the other suggestion of getting things marked as normative and centralized is the important 08:28:22 vmpstr, the VT stylesheets are not HTML-specific. That's why they don't belong in the HTML spec. 08:28:34 chris: just wanted to be clear that we can still have css tests and normative ua sheet bits in specs 08:28:45 we have a :root { view-transition-name: root }, but I guess that's not just html? 08:29:02 right, it'll apply to arbitrary XML for example 08:29:08 jfkthame has joined #css 08:29:12 ack futhark 08:29:14 Rendering DocBook, any other format 08:29:39 so should those then live in css? (or v-t I guess?) 08:30:10 makes sense I guess, but it seemed like having a centralized spot is good, but i don't know if there's anything that applies to all things 08:30:29 futhark: Just want to point out that there's a UA sheet in css-color-adjust that applies only to svg and should probably be moved to the svg spec 08:30:40 TabAtkins: maybe? no strong opinion on that 08:30:56 ack oriol 08:31:28 oriol: Wanted to highlight the last comment of the issue that would be great if the appendix mentioned if something in the rendering updates in html needs to do some magic with it (?) 08:32:05 oriol: so if it's something that should replace some magic in the html spec it should indicate that 08:32:08 TabAtkins: agreed 08:32:24 andreubotella: even after the spec is mature it'd be useful to keep that appendix 08:32:32 ... or a reference to the HTML spec 08:32:36 q? 08:32:45 ack andreubotella 08:32:51 ... for an implementation that comes later it'd be useful to know what to put in the UA sheet 08:32:58 ... for any potential new engines or what not 08:33:05 ack emilio 08:33:05 +1 to andreubotella but it should only be a reference. No maintaining normative text in two places 08:33:17 indeed 08:33:21 ack emilio 08:33:24 ack fantasai 08:33:24 fantasai, you wanted to say we shouldn't remove anythig from our specs until they've been properly published in their target location 08:33:42 fantasai: wanted to say that we should not remove anything from our spec until it lands in HTML / SVG 08:33:47 +1 to fantasai. No maintaining normative text in zero places 08:34:04 s/lands/lands (and is properly published)/ 08:34:51 proposed resolution: Go through specs that have UA sheets. Pull normative things to an appendix and clearly mark as normative. For those that pass CR criteria move to HTML spec leaving a reference to them 08:35:08 RESOLVED: Go through specs that have UA sheets. Pull normative things to an appendix and clearly mark as normative. For those that pass CR criteria move to HTML spec leaving a reference to them 08:35:26 github-bot: take up https://github.com/w3c/csswg-drafts/issues/8543 08:35:26 Topic: [css-images-3] clarification on metadata position in specific file formats 08:35:26 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/8543. 08:35:59 chris: we have a requirement for metadata to be placed before some image formats 08:35:59 s/pass CR criteria/pass CR criteria and apply to HTML elements specifically,/ 08:36:17 ... except in some formats that's invalid 08:36:44 q? 08:36:45 ... I propose the spec that says that if there is a choice in the image format then put that before 08:36:57 +1 08:37:08 q+ 08:37:14 Proposed: Only ask for metadata before if that's acceptable 08:37:18 ack florian 08:37:25 florian: what we proposed is clear for what authors are supposed to do 08:37:45 ntim_ has joined #css 08:37:49 ... the other one is a requirement for UAs to ignore metadata-after-data 08:37:59 ... so what's the proposal for that? 08:38:22 chris: that is a different issue, we have different behavior 08:38:35 ... e.g., webp metadata is ignored in some implementation 08:38:49 ... if you have a giant webp that rotates the image at the end it seems bad 08:39:08 florian: spec currently says SHOULD, should it be MUST? 08:39:10 chris: yes 08:39:27 Proposed: Only ask for metadata before the data if that's acceptable for a file format 08:39:56 Proposed: Don't require metadata at the start if the format doesn't allow it 08:40:03 WebP also apparently doesn't offer progressive decoding 08:40:19 RESOLVED: Don't require metadata at the start if the format doesn't allow it 08:40:43 Proposed: UAs must not honor metadata at the end of the file 08:40:46 proposed: ignore layout affecting metadata when it is after the data, even in file formats where there is no choice 08:41:05 myles: not sure if that's implementable 08:41:10 q+ 08:41:42 emilio: dbaron pointed out that webp doesn't support incremental decoding 08:41:57 myles: right, if no incremental decoding is fine to have metadata at the end 08:42:06 q+ 08:42:11 ... seems more of a quality of implementation issue 08:42:20 proposed: if you have started progressive rendering, you SHOULD ignore subsequent layout affecting metadata 08:42:22 ... I don't think ignoring the metadata should be a requirement 08:42:26 ack emilio 08:42:44 myles: I think I'm proposing no resolution at all 08:43:03 ... then we can outreach PhotoShop or something to prefer metadata at the front or what not 08:43:08 ack florian 08:43:32 florian: I don't have that strong opinion on whether ignoring metadata 08:43:41 ling_ has joined #css 08:43:49 ... but having a should and browsers doing different things is bad 08:44:08 myles: I think we should remove that should from the spec 08:44:08 ack dbaron 08:44:28 dbaron: it's probably worth having something like what astearns proposed 08:44:37 ... even if it's a may 08:45:06 myles: that's worse right? You end up with the wrong orientation in one browser but not the other 08:45:12 ... we probably want the same images to look the same once everything is loaded 08:45:31 astearns: Not certain it's a terrible thing to have different behavior here 08:45:44 ... you still get the image data and is flipping 08:46:00 dbaron: if we are going to switch the spec we should have the data on what different implementations do 08:46:15 s/spec/spec from must or should for one thing to its opposite/ 08:46:44 florian: what about text that say that if the UA can't ignore metadata it can't ignore it in some cases but not in other 08:47:08 ... I think I agree with myles that once the image loads it all should be the same 08:47:19 miriam: should we take this to the issue / or a different issue? 08:47:24 myles: sure 08:47:54 github-bot: take up about:blank 08:47:54 emilio, I can't comment on that because it doesn't look like a github issue to me. 08:48:02 github-bot: take up https://github.com/w3c/csswg-drafts/issues/9124 08:48:02 Topic: [css-align-3][css-position-3] Better interaction of auto insets and self-alignment properties? 08:48:02 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/9124. 08:48:38 miriam: this was discussed yesterday in the anchor-positioning breakout session 08:48:59 ... when both insets on an axis are auto we currently use the static positioning box 08:49:09 ... roughly where the element would've been 08:49:37 ... question is: when you change alignment via justify-/align-/place-self, should we zero those out? 08:49:53 ... or is it weird to change it based on alignment 08:50:33 ... the question is (1) is it web compatible to make this change, and (2) if it is, is there anyone who agrees with fantasai that we still shouldn't do it 08:50:48 florian: the implications take a while to process 08:51:05 miriam: when you set alignment should that refer to the static position box or the otherwise positioning context 08:51:47 And to be clear, for compat: currently, impls only respect the current spec (aligning in the staticpos rect) for a flex/grid parent. Other parent display types, it's not implemented yet, so doing *either* behavior is *potentially* a compat problem. 08:51:59 emilio: not sure if we can get to resolve this in 9 minutes 08:52:17 ack fantasai 08:52:17 fantasai, you wanted to explain this 08:52:47 arkanisk has joined #css 08:52:49 arkanisk has left #css 08:52:54 fantasai: [whiteboard time] 08:53:30 fantasai: you got the abspos cb, the regular cb, and then the child you position 08:53:50 ... right now with insets auto you stay within the regular cb 08:54:21 ... if you set insets to 0 then we don't care where this box lives, we lay it out inside the abspos cb and ignore everything else 08:54:57 ... question is when we go back to being auto 08:55:29 ... flex/grid pretend that you are aligned as the single kid 08:55:57 ... what TabAtkins and iank_ are saying is that if you set the alignment props to a value other than normal then we align to the abspos cb 08:56:04 ... you could think it as setting insets to 0 08:56:45 ... so question is, is that more intuitive that remaining in the regular cb (and thus you need to set insets to 0 to get positioned in your abspos cb) 08:57:10 ... that's the fundamental issue we're disagreeing on 08:57:29 q+ 08:57:37 ... the existing behavior on grid / flex is a compat constraint, though iank_ is willing to implement / ship this and see if it's not 08:58:15 ... the other thing is that alignment on block are not easy to emulate with anchor positioning 08:58:40 based on the explainer, slightly favoring auto-zeroing, I think 08:58:55 TabAtkins: the behavior you described for block is not what's in the spec 08:59:11 ... the spec is saying a 0-width behavior 08:59:18 fantasai: it's not, it's full-width 08:59:35 TabAtkins: so in this case if you did align-self: end would be higher than align-self: start 08:59:59 ... in an inline context you have 0-width, 1lh-height so you get that weird behavior for justify 09:00:24 ... my argument is that nobody implements this behavior for inline / block yet 09:00:31 ... so there's compat impact either way 09:00:46 tantek has joined #css 09:00:52 ... we don't believe there's compat impact on changing the grid / flex behavior 09:00:54 q? 09:00:59 ack TabAtkins 09:01:53 ... ignoring compat the argument is still that the behavior defined here is very limited and weird 09:01:53 q+ 09:01:53 ... we want to do less of this static positiony stuff 09:01:58 ... given its power is largely replaced by anchor positioning 09:02:10 q- 09:02:20 jamesn has joined #css 09:02:24 miriam: we're at time 09:02:46 astearns: we'll get compat data and come back 09:02:55 topic:
09:03:16 (returning at 11:30 CEST) 09:31:50 romain has joined #css 09:32:30 addison has joined #css 09:32:50 present+ Addison(I18N) 09:34:37 present+ 09:37:12 noamr has joined #css 09:38:42 ydaniv has joined #css 09:38:49 github-bot, take up https://github.com/w3c/csswg-drafts/issues/1282 09:38:49 Topic: [css-logical] Flow-relative syntax for `margin`-like shorthands 09:38:49 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/1282. 09:39:06 xfq has joined #css 09:40:30 present+ 09:40:30 present+ 09:40:30 cathiechen has joined #css 09:40:30 addison: This one we discussed last year at TPAC 09:40:30 mrobinson has joined #css 09:41:03 addison: called flow-relative syntax for margin-like shorthands 09:41:03 addison: But really it's about providing support for directionality by changing left/right to start/end in various properties 09:41:03 r12a has joined #css 09:41:03 addison: And allowing margin-like shorthands (the 4-direction props) to follow that 09:41:03 present+ 09:41:03 addison: We've been working with some CSSWG members on the steps necessary to do this in a generic fashion across CSS 09:41:03 ntim has joined #css 09:41:03 addison: There've been some action items outstanding, I think florian has one to enumerate the various props 09:41:36 addison: So this is a check-in to see how progress is going, see if we can encourage progress 09:41:36 addison: And make sure the larger WG remains aware. 09:41:36 q? 09:41:36 florian: Sorry to report I haven't progressed my Action Item 09:41:46 florian: But now that I'm not a board<->AB laiason I ahve a lot more time and plan to make progress. Sorry for not doing it so far. 09:42:22 addison: The more global thing - we've been having monthly calls, with Floriana nd Elika repping CSS, and others of us repping i18n. 09:42:41 addison: It's been productive (if inconveniently timed) call, and we've been handling issues 09:42:49 addison: If anyone wants to participate, please ping me to get notified. 09:42:55 addison: We welcome participation. 09:43:18 astearns: Besides the florian AI, any other progress on this issue? 09:43:25 addison: Any other concerns? Otherwise we can move on. 09:43:37 github-bot, take up https://github.com/w3c/csswg-drafts/issues/8914 09:43:37 Topic: [css-fonts] It should be possible to slant glyphs to the left for italics/oblique 09:43:37 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/8914. 09:43:59 addison: This is an observation from gap analysis, maybe let Richard intro this 09:44:01 q+ 09:44:18 r12a: I think florian expanded the qs and info significantly. I'll do a brief intro then pass it. 09:44:19 q- 09:44:58 https://github.com/w3c/csswg-drafts/issues/8914#issuecomment-1649678597 09:44:58 q+ florian 09:44:58 q+ 09:44:58 r12a: If you follow that link, you'll see a picture which'll help follow 09:45:34 r12a: there are orthographies aroudn the world where if you italicize, in some cases, or definitly oblique text, it doesn't lean to the right it leans to the left - generally the reading direction of that script 09:45:34 r12a: the way the spec addresses this is problematic atm 09:45:34 r12a: if there's an italic font available, the browsers tend to switch to that automatically 09:45:39 r12a: But the italics available don't necessarilly lean to the left, they'll usually lean ot the right 09:45:50 r12a: So if this font is substituted you don't get what you expect 09:46:00 (btw, I18N+CSS meeting calendar entry: https://www.w3.org/events/meetings/d737b1d9-bb00-4b14-9507-0338465ee8ed/20230926T220000/) 09:46:09 r12a: So it seems we need to separate more clearly the separation between italic and oblique, and allow you to insist on oblique 09:46:16 q+ 09:46:17 r12a: italicization isn't the same as oblique anyway 09:46:28 r12a: in a script like cyrillic the letterforms are very different 09:47:09 r12a: so that's another reason not to munge together italics and oblique 09:47:17 https://github.com/w3c/csswg-drafts/issues/8914#issuecomment-1651137267 09:47:17 ack florian 09:47:17 florian: for full details of what i'll be talking about, this is the original comment 09:47:17 florian: a few points to make fixes in the spec 09:47:20 florian: overall it seems the spec is trying to say that falling from italic to oblique is a thing but the reverse isn't, which is reasonable 09:47:20 florian: but ambiguous 09:47:35 florian: there are some places taht seem to suggest they're talking about falling back from oblique to italic, we shoudl clarify 09:47:52 florian: Also there's some bit that takes the closest available angle, it should take sign into account 09:48:02 florian: Choosing the wrong direction because it's a clsoer angle seems bad 09:48:16 florian: Also synthesizing italics is problematic. If you synthesize, you generate oblique for it 09:48:22 florian: We have a control to say *no* synthesis 09:49:11 florian: But the way this is written, it suggests tha tif you turn it off, it'll turn off *oblique* synthesis as well. 09:49:11 florian: And that's bad. Oblique synthesis is easy and reasonable - real oblique can be slightly better but it's very close, unlike synthetic italic. 09:49:11 thinks these should be separate issues, going forward 09:49:14 q+ 09:49:16 florian: So ahving the same control turn off both italic and oblique synthesis seems bad. 09:49:19 q? 09:49:28 florian: So I think we need to at least not disable oblique synthesis when turning off italic synthesis. 09:49:39 florian: And *maybe* we need a way to control oblique synthesis, unsure that's needed. 09:50:03 florian: Anothe rissue, a variable font can have a numeric axis for oblique 09:50:14 florian: But for non-variable fonts we don't know the lean direction 09:50:24 florian: Might be useful to have in @font-face a way to indicate the lean direction 09:50:31 florian: So browsers can know what it has and give the right one 09:50:46 florian: If we want to give authors this choice, we need to give that info to browsers. 09:51:03 ack chris 09:51:04 astearns: This is a great list of issues; after this meeting we shoudl split these up 09:51:15 chris: some of this wording about italic and oblique dates back to css1 09:51:31 chris: it's trying desperately to ensure it's different from normal text, no thought about i18n or good typography 09:51:38 chris: So I think some of that wording can just be backed off 09:52:01 chris: For closest angle, I think has an easy fix; find the closest angle of the desired lean direction. 09:52:14 astearns: fantasai suggests we resolve on that 09:52:29 scribe+ 09:52:39 TabAtkins: Should we still pick the wrong direction if you only have one direction? 09:52:54 drott: We already ahve italic-left vs right control tho 09:53:36 chris: For varaible fonts, yes. This is for non-variable 09:53:36 myles: Chris talked about users pref 09:53:43 myles: Does the angle actually have semantic meaning? 09:53:43 myles: If we pick the wrong angle, does that change the semantic meaning of the text, or does it just look ugly? 09:53:43 We have control `oblique n deg` which can be positive or negative. 09:53:43 chris: I think it's actually *wrong*, not just ugly 09:53:55 chris: If some text leans left and suddenly some leans right it just looks horrible 09:54:03 myles: Do these langs have a concept of italics historically? 09:54:25 r12a: Two african scripts in recent use, didn't have italics until font designers started working with them 09:54:32 For italic font-style, we don't have a way to express which direction it should go. 09:54:44 r12a: They asked the speakers what direction it should lean, and they clearly said it should lean left 09:55:16 r12a: n'ko [i think i got the name right] 09:55:16 r12a: For hebrew and some extent arabic, it's a personal choice 09:55:49 r12a: Some people prefer left, some prefer right 09:55:49 q? 09:55:49 myles: So my q is if fonts exist that are in the correct direction, why not use that? 09:56:12 r12a: There's very limited support, N'Ko has like 4, and 2 aren't complete. Noto has just developed a new font based on this discussion. 09:56:23 ack myles 09:56:28 r12a: For Hebrew there are fonts that lean both ways 09:56:45 r12a: that's where florian's suggestion of being able to select a font based on lean direction comes from 09:57:36 myles: So sometimes it's personal pref, but sometimes it's valid linguistically 09:57:39 fantasai: I'm not sure I understand 09:57:56 fantasai: If author requests a slant of -12deg, why would give it a +5deg slant? If you had an option of -20deg or whatever 09:58:09 myles: Say numbers again? 09:58:11 the relevant part of the spec: https://drafts.csswg.org/css-fonts-4/#ex-ascending-oblique-13 09:58:54 astearns: I think the proposed resolution is, when searching for the nearest angle, find the angle in the same direction first, then find nearest angle in any direction if there's nothing. 09:59:36 myles: The spec does that 09:59:36 myles: If you request positive, it'll search the positives first, etc 09:59:37 drott: So question is if you want to cross 0 or not 10:00:17 astearns: In case where sign of the angle is ... is it better to switch the sign or find the closest on that side 10:00:20 myles: I thought richard just said neither is semantic 10:00:34 r12a: correct, but i also said N'Ko speakers would be happy with the wrong lean 10:00:40 q+ 10:00:52 r12a: hebrew speakers would prefer one direction, but would be okay with either better than nothing 10:01:01 chris: The comparison isn't against nothing, it's against synthesis 10:01:09 chris: Not clear that wrong direction si better than synthetic 10:02:34 r12a: If you said you wanted an oblique font, the impls will switch to an italic font if needed, and you can't control the direction of that. That jump can be problematic. 10:02:34 r12a: So part of the discussion is if you want oblique you should be able to keep it 10:02:34 astearns: We already have preserving the sign, if possible 10:02:34 astearns: Coudl open a separat eissue of if there's anything different to do when the choice would change sign 10:02:34 astearns: Then we can go to the rest of the issue about italic vs oblique 10:02:51 wolfgang has joined #css 10:02:52 ack florian 10:02:59 florian: Even if direction is a pref and both would be fine, issue is the doc is unlikely to be a single font 10:03:04 q+ 10:03:04 q- 10:03:04 q? 10:03:24 florian: If you have, say, bold italic in the middle of non-bold italic, and you have one font but not the other so you synthesize, if the direction clashes it'll look horrible 10:04:09 florian: Whether you want to switch to another font that you know leans the right way, or synthesize, dunno. But switching direction can be very unacceptable, depending on context. 10:04:09 q? 10:04:09 ack drott 10:04:09 ack drott 10:04:40 drott: how important do you find it to be that this is synthetic or not? 10:04:40 drott: Is you main focus on matching, or synthesizing? 10:04:40 drott: I think our synthesization doesn't take angle into account 10:04:58 drott: So q is if angle should key into our choice to synthesize 10:05:14 r12a: I don't think that's part of what i'm requesting, I was assuming you could set an oblique angle 10:05:23 lea has joined #css 10:05:23 drott: So you're more interested in font matching than synthesis? 10:05:25 present+ 10:05:39 r12a: I think so, I'm not a CSS font expert. I'm interested in users getting the behavior they want, leaning left or right. 10:05:42 s/other so you synthesize/you would need to either synthesize or fallback to a font family that does can lean the right way. 10:05:50 drott: But you'd expect authors to bring fonts for that? 10:06:21 astearns: For my clarification, when you said synthesis only uses one angle, is it only one direction too? Or can it go left and right? 10:06:25 s/it'll look horrible/it'll look horrible, possibly into unreadable territory as letters colide and overlap 10:06:25 drott: I'd have to check. 10:06:37 myles: We have a hardcoded angle with a fixed direction. 10:06:59 myles: the way the spec phrases synthesis is, in your family you ahve fonts, and if the browser wants to add more, it can do it. as many as they want. 10:07:17 myles: So the spec is phrased as if the fonts are not created in response to request, they're just *there* 10:07:29 s/ahve/have/ 10:07:38 present+ wolfgang 10:07:44 astearns: Ah so my udn erstanding of richard's concern is that browsers should have synthetic oblique for both left and right. At least those two, even if there's only one angle in each direction. 10:07:47 myles: I think that's reasonable. 10:08:00 myles: Digging deeper, users don't care about synthesis they just want it to look right 10:08:11 myles: From impl, synthesis and selection are very different. 10:08:16 s/udn erstanding/understanding/ 10:08:22 myles: If there's a font with the right angle, everyone gets the right answer. 10:08:38 myles: Remaining question is if there isn't a correct-direction font we *could* synthesize a good one. 10:08:52 myles: But right now the spec doesn't have must-level requirements for synthesis at all. 10:09:14 myles: But I think the spec should *at least* have a should-level note suggesting that if you synthesize, we should have two directions. 10:10:21 myles: At most a should-level, not must, given the lack of requirement around synthesis right now. 10:10:34 r12a: You can set negative angle and get synthesis correct in some browsers 10:10:36 myles: Really? 10:11:16 r12a: You shouldn't necessarily automatically fall back to a font of *any* type, if you actually want to specify an oblique 10:11:53 myles: In our impl, those have to be the same, for mechanical reasons, oblique and italic have to be treated the same. 10:12:02 myles: I agree philosophically it's wrong, our impl just constrains us. 10:12:15 q+ 10:12:23 ack drott 10:12:49 drott: What I'm gathering is that about fallback, you won't want to fallback in the wrong direction. That's not currently in the matching algo. 10:13:04 drott: So that brings us back to the "should we cross 0" in fallback. 10:13:18 drott: The algo currently prefers the correct lean but will change direction if needed. 10:13:30 astearns: That's a seaprate issue we'll discuss in the future, seeing if there's anything else here we can resolve on. 10:13:49 astearns: So back to Myles' suggestion about a note saying browsers should synthesize oblique in both directions 10:14:22 fantasai: I would go further and say *if* the browser is synthesizing, it *must* have both directions. Not sure why we'd allow unidirection if you're synthesizing in the first place. 10:14:40 drott: We don't have an internal API for that. I can see the utility of it. 10:14:43 drott: I think it's acceptable. 10:15:06 astearns: So the value of a note is showing our interest in it being ipmlemented. But not requiring it due to underllying tech stack. 10:15:24 fantasai: can't put MUST into notes 10:15:33 astearns: Right, not using 2119 10:15:51 TabAtkins: counter-proposal is, normatively state "if you synthesize, you must synthesize both directions" 10:16:02 TabAtkins: the main concern was that sythesis was an optional feature, right? 10:16:13 astearns: And drott didn't want it to be must because currently they can't synthesize both directions 10:16:14 q+ to ask if there shouldn't be a way to ask left or right leaning, instead of a precise angle. 10:16:23 s/ipmlemented/implemented/ 10:16:29 astearns: So I was sticking with a note to express our preference. 10:16:41 myles: Might be able to compromise here, start with less strict req. 10:17:06 myles: I expect we'll implement it, no reason not to. And then we can upgrade to a requirement later. 10:17:10 ack Bert 10:17:10 Bert, you wanted to ask if there shouldn't be a way to ask left or right leaning, instead of a precise angle. 10:17:13 q? 10:17:15 fantasai: I'm fine with SHOULD for now, cranked to MUST later. 10:17:25 s/I expect we'll implement it/I expect everyone will implement it/ 10:17:28 Bert: In most cases I really just carea bout left vs right, can I avoid specifying a number? 10:17:33 q+ 10:17:35 astearns: I like the idea but it shoudl be a separate issue 10:18:01 ack florian 10:18:01 s/carea bout/care about/ 10:18:17 florian: I'd filed that in a bunch of bullets, agree to file it. It was convenient to centralize them for a bit, let's split them out. 10:18:21 s/shoudl/should/ 10:18:44 astearns: First, action florian to split out bullets into separate issues. 10:18:59 fantasai: Agree should file separate issues, don't think that should block us from discussing. 10:19:19 astearns: Right, dont' think we have a conclusion on that topic (just specify lean direction) but think we can go back to the synthetic q 10:19:40 s/dont'/don't/ 10:19:46 myles: proposed resolution is *if* a browser does synthesis of oblique, there SHOULD be at least two synthesized fonts, one in each direction 10:19:53 yes, lgtm 10:20:01 astearns: objections? 10:20:25 (maybe could be simplified to "SHOULD be at least one synthesized font in each direction", but doesn't matter to me) 10:20:45 RESOLVED; *if* a browser does synthesis of oblique, there SHOULD be at least one synthesized font in each direction 10:21:12 astearns: so, fallback for oblique 10:21:38 florian: Depending on which part of the spec you read it either says oblique->italic is not a thing, or suggests it's okay. I think we should remove the part that suggests it's okay. 10:21:50 q+ 10:21:59 florian: I think there's a part that talks about picking a font for the closest angle, that doesn't seem to differentiate betwen italic and oblique 10:21:59 q+ 10:22:10 drott: I'd be in favor of seaprating italic to oblique, but that's a breaking change 10:22:19 florian: From italic to oblique, yes, but from oblique to italic? 10:22:22 myles: For us yes 10:22:28 s/seaprating/separating/ 10:22:35 drott: Similar to what myles says, we don't make an internal distinction between oblique and italic 10:23:23 fantasai: Worth pointing out the spec currently says, in the space where things are more precise, it runs thru all the obliques in the positive direction, then the italics, then the obliques and italics in the negative. 10:23:29 myles: I wrote that on purpose to achieve this. 10:23:40 fantasai: I don't think we want to change this but might want to give some control over this. 10:23:46 astearns: Q for i18n folks. 10:24:14 astearns: If author specifies oblique in positive direction, is it acceptable to get italic in positive direction, or would be better to get oblique in negative direction? 10:24:30 jfkthame: Neither one 10:24:35 q+ 10:24:36 tantek has joined #css 10:24:40 fantasai: My intuition is matching the slant is more than letterform 10:24:41 agree with fantasai 10:24:42 present+ 10:24:46 ack drott 10:24:46 q- 10:24:59 r12a: don't understand why you'd go for a negative oblique if you asked for positive 10:25:32 ack jfkthame 10:25:35 myles: The reason I wrote it this way is if you are using a weird font that leans the wrong way, and the user asks for italic, you want it leaning the wrong way rather than nothing. 10:26:04 jfkthame: Agree that we shouldn't fall back to italic when oblique is requested. I know it's what we currently do but we shoudl change it, better to synthesize oblique than fallback to italic 10:26:17 jfkthame: Also think we should synthesize a slant rather than choose a wrong lean. 10:26:19 +1 to jfkthame 10:26:21 q- 10:26:28 q+ 10:26:31 astearns: Is it possible to resolve to remove the italic fallback? 10:26:35 q? 10:26:37 florian: q for jfkthame 10:26:41 s/florian/fantasai/ 10:27:00 fantasai: If you don't have synthesis enabled, better to fall back to wrong-direction lean, or upright? 10:27:19 s/wrong-direction lean/matching-direction italic/ 10:27:25 jfkthame: I think if you don't have synthesis enabled, you'd end up with 10:28:24 jfkthame: you'd get the same font you would have got, without synthesis. so no fallback from oblique to italic, not across zero. so font-matching rules would determine what font you get 10:28:33 TabAtkins: So given elika's question, you'd get upright? 10:28:34 ack florian 10:28:35 jfkthame: yes 10:28:54 florian: I think i agree with jfkthame if the browser is capable of synthesis. In a browser that isn't i'm less sure. 10:29:06 florian: I agree that if you ahve synthesis, getting italic rather than synthetic oblique is weird. 10:29:08 q+ 10:29:14 florian: But if you can't get synthesis it gets murky 10:29:21 jfkthame: Is there any browser that does no synthesis. 10:29:38 florian: Dunno but Myles was mentioning it being optional and that seems important. 10:30:03 myles: Biggest argument for fallback between oblique and italic. First is just software design, currently hard. 10:30:05 myles: other is compat 10:30:11 s/ahve/have/ 10:30:25 myles: For us to do it, we'd have to run an experiment (in Firefox?) to implement the new behaior and see if there's complaints 10:30:44 s/behaior/behavior/ 10:30:59 Agree 10:31:02 fantasai: My take is that, on the web, given the wide variety of environs, preserving that there is a slant is probably important in some cases, so having it fallback to italic if you don't have oblique *and* can't synthesize is reasonable default. 10:31:06 ^ 10:31:23 fantasai: Might want to allow turning that off and say "italic only" or "oblique only", but by default having them fallback to each other makes for a more robust behavior. 10:31:58 myles: My point about compat is if the author happened to always be right, then no need to fallback. only when author gets it wrong does it matter. 10:32:26 florian: if choice is fallback to italic *or* synthesize oblique, I think synthesize oblique is preferable. fallback to italic is fine if there's no other option. 10:32:31 florian: And I think that preserves compat reasonable 10:32:32 q? 10:32:36 ack myles 10:32:37 q- 10:32:53 s/that preserves compat reasonable/that preserves reasonable compat 10:33:15 astearns: I think we're done for the moment, should split out the issues and take them bit by bit. Sound okay? 10:33:24 +1 10:33:44 github-bot, take up https://github.com/w3c/csswg-drafts/issues/6770 10:33:45 Topic: [css-fonts-5] How to add new generic font families 10:33:45 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/6770. 10:34:09 addison: Another checkin, we've been discussing potentially more generics to support writing/typography traditions in other parts of the world 10:34:33 addison: Beyond the existing standard set, to let people use named generics rather than requriing authors to hunt for specific font names 10:34:42 addison: We've discussed this in our meetings 10:34:49 florian: Status update is same as last time 10:34:55 florian: Status: complicated 10:35:23 andreubotella has joined #css 10:35:36 addison: So partly the status is, mutually trying to gather examples of generic styles that can't just be mentally mapped to the existing generics, where not having the distinction would impair the reading of the doc. 10:35:48 q+ 10:35:52 addison: r12a compiled a doc of langs with stylistic differences that don't fall into the existing buckets 10:37:08 s/requriing/requiring/ 10:37:08 https://www.w3.org/International/articles/typography/fontstyles.en 10:37:08 addison: Where maybe having named generic would be useful for authors to say what they want and get the desired behavior. 10:37:08 addison: Challenge is that since they're usually narrowly script-specific, what happens for `nastaliq` in Chinese? 10:37:08 q+ 10:37:08 addison: And also how would CSS encode additional generics, without exploding the set. 10:37:08 ack florian 10:37:08 florian: One challenge was, for these things that are only relevant to a subset of unicode, what does it mean for the rest. 10:38:18 florian: The other is i18n have compiled a list of groupings, but within this there's a gradient of "essential" to "common but authors would survive without it" and everything between. 10:38:18 q? 10:38:18 q+ 10:38:18 q+ 10:38:18 florian: So it's a question where the CSSWG wants to place the bar, doing the research to show the distinction is important enouh requires research 10:38:31 florian: Looking thru books/etc to see that it's a style you need that would not just be visually jarring without, but actually be misunderstood 10:38:31 s/enouh/enough/ 10:38:44 florian: I think elika had a criteria that if we find fonts in the first group it's undeniable we need them, because it causes misunderstandings 10:38:54 qq+ to point to an existing resolution re "the rest" 10:38:56 florian: But that research is hard. Should probably only be done if we want to be that strict. 10:39:19 q+ 10:39:20 florian: If we're okay with less strict criteria - visually jarring, even if not causing misunderstanding - finding fonts over that bar is much easier 10:39:56 florian: So where CSS wants the bar will affect how we'll do research 10:39:56 ack chris 10:39:56 chris, you wanted to react to florian to point to an existing resolution re "the rest" 10:39:56 https://github.com/w3c/csswg-drafts/issues/4442#issuecomment-561913410 10:41:01 chris: We ahve an existing resolution on what to do if they don't apply to the script 10:41:01 chris: It's in the spec, they just don't do anything 10:41:01 ack drott 10:41:01 q? 10:41:01 drott: I think florian's comment was good, about criteria 10:41:01 q- chris 10:41:01 q- i think chris said what i was going to say 10:41:01 q- 10:41:01 drott: I brought up some ipml questions about what to apply 10:41:01 s/ahve/have/ 10:41:01 drott: For existing generics we usually have UIs and user prefs to apply them. 10:41:01 drott: If we add a bunch, we'd have to expand that UI, and that could confuse users. 10:41:34 drott: If we don't add UI, can we agree on the criteria? 10:41:41 drott: Finding good fonts that recognize the distinctions... 10:41:41 drott: We have trouble finding them consistently 10:41:51 q? 10:41:52 drott: So what are good candidates? Can we agree on how fonts map to the keywords? 10:42:07 florian: I wonder, if for those values, we can start a registry of known fonts that map to the style 10:42:11 q- 10:42:17 florian: I don't think blessing some fonts in the spec is fair to font vendors 10:43:38 florian: But a list of "all these fonts are known to be okay for nastaliq" is okay, UAs can draw from this when picking up from the OS 10:43:38 drott: If the OS doesn't have it, what do we do? 10:43:38 florian: fallback 10:43:38 Maybe such a list could be in a more editable document that's linked from the spec? 10:43:38 astearns: That's relevant to the previous issue, you have to define a fallback for anything we add 10:43:38 q+ to ask if there is a specific proposal 10:43:38 astearns: So we're stuck on finding a criteria. 10:43:38 dbaron, https://www.w3.org/2023/Process-20230612/#registries 10:43:38 astearns: Probably not a good idea to take the most important one and derive a criteria from that? 10:43:41 florian: i18n has done research and found a bunch that are relevant 10:43:48 q+ to ask if we like the "generic prefix" proposal for new generics 10:44:26 q+ to ask if a new feature would be appropriate 10:44:30 q+ 10:44:52 q? 10:45:03 florian: maybe we just take i18n's advice directly? 10:45:15 myles: is there a specific proposal? Not quite sure what we're talking about 10:45:19 myles: The spec already has pictures of example fonts for many generic famlies 10:45:31 myles: I don't think we need another document listing more examples 10:45:37 myles: i think the pictures in the spec are good enough 10:45:39 s/famlies/families/ 10:45:45 florian: Maybe we just take i18n's advice directly and start from their recs 10:45:45 myles: Is there a specific proposal? 10:46:04 chris: So there's 3 ways to go. 10:46:10 chris: One is we add a small, select number of generics. 10:46:11 ack myles 10:46:11 myles, you wanted to ask if there is a specific proposal 10:46:14 ack chris 10:46:14 chris, you wanted to ask if we like the "generic prefix" proposal for new generics 10:46:26 chris: Two is there's a bunch, possibly hundreds. As soon we find a distinction in a writing system, we add them. 10:46:28 q++ chris 10:46:34 ack + 10:46:36 chris: Three is generics are bad, we add these three and then never again. 10:46:59 myles: iirc there's a GH issue, and it resolved that 1 and 3 are bad, so that leaves 2. 10:47:08 myles: We've already solved "what does nastaliq mean in Chinese?' 10:47:17 myles: If i18n says a bunch of families are useful, let's do it 10:47:33 ack chris 10:47:43 chris: so there was a proposal that if we add new generics we add a prefix or something 10:47:46 chris: problem at the moment is they look like normal font names 10:47:54 q? 10:47:57 q+ 10:48:29 chris: I think the grouping is ugly but more scalable. 10:48:39 chris: like `generic(nastaliq)` 10:48:44 q- 10:48:59 q- 10:48:59 myles: Don't think I have an opinion, except that if we do have a grouping mechanism it should be a function rather than a prefix. 10:49:10 chris: So that's what I was on the q for, to ask if we want the generic syntax. 10:49:25 ack fantasai 10:49:25 fantasai, you wanted to comment on complete generics vs incomplete generics 10:49:27 astearns: So should we resolve on adding new font families via generic syntax? 10:49:40 fantasai: I think we should add a new syntax, but only for incomplete generics. 10:49:58 fantasai: complete is one that applies to every writing system, it is an endpoint for fallback 10:50:08 fantasai: monospace, serif, sans-serif are those 10:50:17 chris: There's not just examples, they're the only ones 10:50:24 fantasai: No we have system-ui, etc 10:50:35 chris: No we have a resolution that *those three* always match, the others might fail 10:50:50 chris: So the "complete" distinction already exists 10:50:57 romain has joined #css 10:51:09 myles: Two very similar things 10:51:41 florian: One is "things that always match across all of unicode, and will never fallback past" 10:51:55 florian: Then the UI ones which are defined across unicode but might not exist, they can fallback 10:52:19 chris: Yeah I think that's the distinction. 10:52:34 astearns: So back to generic functional syntax 10:53:04 myles: I think if we add a function, the dfn should not be "every generic font family after Sep 14 2023" 10:53:09 myles: I think it should be somethin like what elika gave, based off the meaning 10:53:32 +1 Chris, that's exactly what I meant 10:53:33 chris: What about names already defined that would fail the criteria? 10:53:43 myles: We'd keep them for compat but also allow them in generic() 10:53:47 (Chris suggested fangsong -> generic(fangsong)) 10:53:58 myles++ 10:54:17 myles: So the rule for what gets `generic(foo)` and which gets `foo` is based off of something meaningful, not just date added 10:54:49 fantasai: I think the distinction should be if the font is defined across all writing systems, or is specific to one writing system 10:54:51 myles: think that's reasoanble 10:55:22 proposed resolution: add `generic(...)` function, whose values will be the set of fonts that are generic but script-specific 10:55:35 +1 10:55:37 s/fonts/generic fonts/ 10:55:48 chris: So that means ui-rounded doesn't get it, it applies across all of Unicode 10:56:05 myles: Don't have an opinion, sounds fine 10:56:12 fantasai: of the existing generics, only want would go into generic() is fangsong 10:56:17 wolfgang has joined #css 10:56:41 astearns: Objections? 10:57:01 +1 to proposed 10:57:06 myles: And the reason we're doing this is so that i18n can add a bunch of generic families. Please give us that list 10:57:20 ACTION i18n: Propose script-specific generics 10:57:29 RESOLVED: Add a generic() function, for generic font famlies that are not defined across all of unicode 10:57:42 florian: Earlier Myles said 3 options, add a few, add a bunch, add nothing 10:58:13 myles: that was chris 10:58:13 s/famlies/families/ 10:58:13 florian: Ah, I think you said "add a few" and "add nothing" was bad was established 10:58:13 florian: I thought it wasn't established yet. Want to reconfirm that "add a bunch" is fine. 10:58:44 +1 to a bunch 10:58:44 florian: So are we indeed in the situation that we're okay to add a bunch? 10:58:44 astearns: Any concerns about adding a bunch of script-specific generic font families? 10:58:58 myles: I think I wrote a set of criteria a few years ago 10:59:07 myles: There have to *be* at least two fonts that exist that can map to this keyword 10:59:30 myles: And generic families are only useful for installed fonts, so there has to be popular OSes with an example of that font. 10:59:35 q+ 10:59:39 TabAtkins: I like those rules 10:59:43 ack florian 10:59:52 ack addison 11:00:03 fantasai: or installed with language packs 11:00:15 addison: Particularly for small lang communities, who often require installing their fonts, if people, to use their language, install some fonts, and use the necessary generics. 11:00:52 myles: If everyone is installing a particular font, then content can just name that font 11:01:07
11:01:15 github-bot, end topic 11:13:00 littledan_ has joined #css 12:09:20 eeeps has joined #css 12:12:36 eeeps has joined #css 12:19:48 resume at half past 12:20:28 [just waking up in PDT] I think there is a joint meeting with the WHATWG in ten minutes. Both the WHATWG and CSSWG have their own Zoom rooms. Which will one will the joint meeting be in? 12:21:02 I think CSS, since I think it's in the CSS room 12:21:07 ty! 12:21:51 atomasevich has joined #css 12:28:43 flackr has joined #css 12:28:46 hopefully the meeting room will be able to rejoin the video call easily... 12:30:38 romain has joined #css 12:31:23 past has joined #css 12:32:30 lea has joined #css 12:32:30 khush has joined #css 12:32:32 present+ 12:32:39 present+ 12:32:44 present+ 12:32:52 present+ 12:32:53 present+ 12:32:56 present+ 12:33:14 zcorpan has joined #css 12:33:14 fserb has joined #css 12:33:21 nigel has joined #css 12:33:25 noamr has joined #css 12:33:26 present+ 12:33:29 present+ 12:33:40 alisonmaher has joined #css 12:33:49 hsivonen has joined #css 12:33:55 Topic suggestion from josepharhar: https://github.com/whatwg/meta/issues/284#issuecomment-1719211428 12:34:14 present+ 12:34:23 present+ 12:34:45 jarhar has joined #css 12:34:51 andreubotella has joined #css 12:34:54 annevk has joined #css 12:35:04 ydaniv has joined #css 12:35:10 ntim has joined #css 12:35:43 una has joined #css 12:35:43 scribenick: fantasai 12:35:47 mrobinson has joined #css 12:36:04 Topic: Reordering Children 12:36:04 https://github.com/whatwg/dom/issues/891 12:36:13 Updated agenda: https://github.com/whatwg/meta/issues/284 12:36:22 github: https://github.com/whatwg/dom/issues/891 12:36:37 Section: Topics for the joint session with CSSWG 12:36:39 present+ 12:36:47 present+ 12:37:00 cabanier has joined #css 12:37:36 Bert has left #css 12:37:36 will the scribed notes be posted somewhere? Looks like the tool can't post them on the html issue. 12:37:38 we will need to do it manually 12:37:45 Mu-An has joined #css 12:37:45 jarhar: Opened the issue awhile ago due to request from frameworks to move elements around in DOM tree without losing their state 12:37:52 ... state can be selection inside nested element, e.g. where cursor is 12:37:53 myles has joined #css 12:37:59 ... state of iframe, might not want it to reload 12:38:08 cathiechen has joined #css 12:38:09 masonf has joined #css 12:38:14 ... I received feedback from ryosuke about how this might be hard or impossible to implement due to security etc 12:38:25 present+ 12:38:26 ... discussing with framework, narrowed it down to just reordering child nodes within parent 12:38:28 present+ 12:38:34 ... then failed to get use cases from frameworks that were compelling 12:38:41 present+ 12:38:43 ... however, there was renewed interest, due to some CSS discussion 12:38:48 (It feels to me like many of those "losing state" things are bugs...) 12:38:57 ... personally not entirely up to date on crossover with CSS 12:39:29 fremy has joined #css 12:39:33 q+ 12:39:36 scribe+ 12:39:37 q+ 12:39:38 present+ 12:39:40 ack fantasai 12:39:42 saschanaz has joined #css 12:39:47 q- 12:40:04 fantasai: The reason it was brought up from CSSWG side is we see people using 'order' prop to reorder elements when it's not just for visual tweaks, but rather for actual inherent ordering (sorting/etc) 12:40:19 fantasai: We've cautioned authors agaisnt doing that, as it causes visual order and the tab/navigation/readng order to diverge 12:40:42 s/agaisnt/against/ 12:40:42 fantasai: This is the *purpose* of the 'order' property, having things show up visually after things that they are sourcely before. Happens with images and headings, for example. 12:40:58 fantasai: So 'order' was designed to solve this case where you *want* them to diverge. 12:41:27 fantasai: Now we're discussing tracking that together with navigation order, for cases where the visual order changes based on an MQ and you actually want things to shift around for all interaction modes. 12:41:34 fantasai: This makes 'order' even more tempting to use, for things that it's not appropriate for. 12:41:48 fantasai: Reasons to use 'order' is 1) it's really easy, selector + 'order' property is nice 12:41:57 fantasai: 2) it's fast, since it's at the layout level, no dom changes 12:42:20 q+ 12:42:31 fantasai: So to give authors tools that are convenient for doing this thing, which they *should* be doing in the DOM itself, we wanted to ask for an API that would allow convenient/easy/relatively performant child reordering 12:42:37 ack emilio 12:42:38 fantasai: So they can use this mechanism instead of the 'order' property 12:42:47 emilio: Regarding losing state stuff 12:42:53 [missed] 12:43:03 jarhar: iframes is the most important 12:43:07 s/jarhar/noamr/ 12:43:09 jarhar: number two is video and audio 12:43:10 s/jarhar/noamr/ 12:43:17 noamr: I've encountered this problem in my career 12:43:30 noamr: trying to keep iframes alive while changing what's going on in the page 12:43:31 s/[missed]/is this just for iframe, or other elements/ 12:43:43 noamr: All kinds of CSS hacks with Grid, just so that iframes and videos don't reload 12:43:53 noamr: feedback from HTMLMax, this is #1 problem they have right now 12:44:01 q+ 12:44:01 noamr: Also say that reordering doesn't just [missed] 12:44:04 Also focus state is another thing lost during reordering 12:44:06 s/HTMLMax/HTMLx/ 12:44:12 noamr: You have something you can do in Grid, then you have to insert another element in the middle 12:44:19 s/HTMLx/HTMX 12:44:23 noamr: Reordering solves half the problem here 12:44:38 noamr: where problem is losing state while they're in the same document, removing adding within the same ?? 12:44:48 s/[missed]/cut it, it's not just reordering/ 12:44:50 zcorpan: For video, problem is that ?? doesn't reload 12:45:01 zcorpan: maybe we could change HTML to not reparse the video if you re-insert somewhere else 12:45:03 q? 12:45:12 s/??/it pauses the video, it / 12:45:16 s/reparse/pause/ 12:45:18 q+ 12:45:22 noamr: videos and iframes etc, defined separately for each element, side-effects of being reloaded 12:45:25 ack noamr 12:45:28 noamr: before anything currently observable by user 12:45:36 noamr: if you did it really fast when remove and add 12:45:42 noamr: [drifts off] 12:45:55 noamr: Rather than trying to solve reordering 12:46:12 q+ 12:46:12 q+ 12:46:33 fserb: Quick clarification, someone mentioned iframe 12:46:36 ack fserb 12:46:37 fserb: I remember this issue 12:46:46 fserb: this had to do with reordering within parent, not reparenting right? 12:46:52 fserb: not sure HTMLx case is just reordering 12:47:02 emilio: Right now the only way to reorder is reparenting. 12:47:08 emilio: need to remove re-insert, even if same parent 12:47:20 q- as emilio answered my q 12:47:23 q- 12:47:24 fserb: reparenting without reordering vs just rearranging within the same parent 12:47:32 fserb: one has more security implications than the other 12:48:15 present+ 12:48:15 emilio: It's in the reparenting case, presumably make the reordering API automated (?) 12:48:15 (I don't think waiting a microtask works. You could then poke at the iframe element when it's in an unexpected state.) 12:48:15 emilio: I think what zcorpan was saying is we can make the reloading async enough that by the time we check, like if you post ?? or something along those lines to be unloaded 12:48:18 emilio: what images do for loading 12:48:19 present+ 12:48:25 emilio: can check, am I in the same DOM tree 12:48:32 emilio: if nothing, then don't need to load 12:48:35 q+ 12:48:41 emilio: seems like a nice solution if we can get away with it 12:48:43 q+ 12:48:48 emilio: and would fix the main case 12:48:54 annevk: dont' think that will work for iframe 12:49:02 annevk: when you remove it, will be in a different state 12:49:09 annevk: thinks it's still associated with the document? 12:49:50 emilio: in Gecko already kinda sync 12:49:50 annevk: part of the stuff that happens is async 12:49:50 emilio: maybe on removal, yeah 12:49:50 annevk: if browser context is still alive, don't think necessarilly [missed] 12:49:53 emilio: Actually reorder iframe, or display: none 12:50:01 q- 12:50:04 emilio: in Gecko can end up with very similar side-effects 12:50:13 emilio: we have code to prevent XXX from happening 12:50:24 emilio: it might not be impossible 12:50:30 smaug: That's just about layout 12:50:45 smaug: but about browser context and re-creating ??, history behavior 12:50:55 smaug: what happens when you next time load the page 12:50:57 smaug: which iframe should load, in what place? 12:51:10 annevk: if browsing context doesn't ??? synchronously 12:51:20 annevk: not just removal, but also other state doesn't get updated in the same way 12:51:39 ????: Might have to do some kind of off-and-on thing 12:51:47 s/????/noamr/ 12:51:50 ????: or do something synchronous if accessing content through the window 12:51:58 s/????/noamr/ 12:52:01 ack emilio 12:52:08 emilio: Might be more complicated, but for media? 12:52:12 noamr: media is more reasonable 12:52:19 s/noamr/annevk/ 12:52:25 annevk: Problem with iframe removal is that it touches global state as well 12:52:33 annevk: also window getter is impacted 12:52:49 annevk: that global side-effect, changing that requires care 12:52:55 emilio: both for reordering and reparsing 12:53:13 annevk: when you don't remove and insert, but use move semantic 12:53:18 q- 12:53:19 annevk: you would have to account for ?? somehow 12:53:37 emilio: Fixing reordering with the same parent, maybe? 12:53:41 +1 12:53:41 annevk: fair 12:54:05 astearns: Please track the gaps in the minutes in IRC, the sound is not great in the room. 12:54:23 s/reordering/reordering more generally, rather than only / 12:54:27 emilio is saying everything I was going to, that I think we should try to support moving frames/nodes without reloading. https://github.com/whatwg/dom/issues/808#issuecomment-1343420267 12:54:32 astearns: It seems to me that, aside from interaction or implications of reordering things and how things we consider about order property, not sure the connection with CSS is all that strong at this point? 12:55:10 s/??/global state/ 12:55:10 q? 12:55:10 s/Fixing reordering with the same parent, maybe?/Fixing reparenting more generally seems nicer than fixing reordering within the same parent/ 12:55:10 astearns: and if there is any CSS connection we do need to tease at, let's tak about that 12:55:10 panos: [time check] 12:55:10 ack lea 12:55:10 q+ 12:55:10 lea: [too much echo] 12:55:35 lea: I suspect that a core reason why devs use 'order' is not just these issues, but ????? which allows manipulation in a lot of ways 12:55:45 lea: so adding a DOM method will help, but not entirely fix this 12:55:53 ack fantasai 12:55:58 scribe+ 12:56:02 peterv has joined #css 12:56:08 q+ 12:56:21 s/lea: [too much echo]/Stepping back from the low level issues for a moment, while adding a DOM method to reorder in one go is definitely worthwhile and I strongly identify with the problems mentioned with doing it today, so huge +1 there, however.../ 12:56:36 fantasai: I was going to raise the point than just fixing the insert + removal wouldn't solve the problem because you still have the usability problem that reordering things removing and insert is not easier 12:56:40 s/Stepping/lea: Stepping/ 12:56:41 q+ 12:56:59 fantasai: you can't go to a css author and give it a big script 12:57:21 ack zcorpan 12:57:23 s/I suspect that a core reason why devs use 'order' is not just these issues, but ????? which allows manipulation in a lot of ways/I suspect another core reason devs do it via the order property is that it's inherently reactive, so inherently easier and can be manipulated in a variety of ways, some of which are much harder to do with JS./ 12:57:28 zcorpan: basically what fantasai said 12:57:28 ... we need to come up with a thing of similar complexity to the order property 12:57:45 zcorpan: iframe and video issues need to be solved for seamless reordering to work 12:57:49 s/so adding a DOM method will help, but not entirely fix this/ If that hypothesis is correct, adding a DOM method will help, but won't fix this entirely./ 12:57:51 q+ 12:57:55 zcorpan: but even if we do solve, the need for convenient reordering that's not 'order' is still there 12:58:03 s/.../fantasai^:/ 12:58:06 ack flackr 12:58:23 flackr: One of the connections I thought this had with CSS is, we have a lot of state associated with having a rendered state 12:58:31 flackr: doesn't get removed until 'display: none' is applied 12:58:43 flackr: this is not synchronous, but on next render opportunity, which allows DOM changes 12:58:58 flackr: so I think there's a bit of disconnect between need for continuity and async updates 12:59:12 emilio: in all browsers when remove an element from DOM, you remove the layout box synchronously 12:59:23 ack emilio 12:59:36 emilio: Solving the ?? thing, adding a reordering API is trivial 12:59:44 I think there are also good reasons that some of these things *don't* go away when something is display:none 12:59:45 emilio: can be defined very easily 12:59:49 s/??/reparenting 12:59:50 emilio: trying to fix the latter without former is complicated 12:59:54 q? 12:59:58 q+ 13:00:02 +1 to what emilio just said 13:00:08 ack zcorpan 13:00:14 zcorpan: Just wanted to bring up again, discussed at some earlier HTML meeting another solution to this problem 13:00:58 zcorpan: which wouldn't require removal and reparenting, which is just to add an attribute or something to add the semantic order 13:00:58 zcorpan: similar to hidden attribute 13:00:58 zcorpan: it's not exposed to users 13:00:58 zcorpan: that's an option we could consider, and that would remove the blocker for iframe 13:00:58 q+ 13:01:12 zcorpan: you could spec how it's exposed to AT 13:01:15 ack florian 13:01:24 florian: wouldn't that be problematic during a long transitoin period? 13:01:35 florian: if you have a bit of JS to move around, it either works or doesn't but things are in place 13:01:38 florian: you can detect that 13:01:56 florian: if attribute, some browsers will honor and legacy won't 13:01:58 florian: and you can't tell 13:02:20 zcorpan: could reparent, but live with not doing iframe 13:02:23 zcorpan: or abuse order property 13:02:38 zcorpan: there's no perfect polyfill 13:02:47 florian: but is the failure easily detectable? 13:02:55 several: IDL feature check 13:03:03 astearns: Suggest we move onto next issue 13:03:08 Topic: CSS Layers via 13:03:17 https://github.com/whatwg/html/issues/7540 13:03:22 present+ 13:03:25 s/detect that/detect that from the javascript that's trying to do it/ 13:03:30 miriam: WHATWG issue, and also a PR of that 13:03:48 https://github.com/whatwg/html/pull/7658 13:03:57 miriam: Need a bit more filled otu 13:04:12 miriam: don't know if this needs a lot of discussion, but this issue touches 4 spec and I'm only editor of 1 13:04:17 miriam: need help with moving forward 13:04:54 miriam: issue is, we added Cascade Layers 13:04:54 miriam: we wanted to import style sheets into a layer, added in CSS 13:04:54 miriam: authors have asked to be able to do in element 13:05:27 miriam: for that to work, authors also need a way for the import to fail if import can't be layered 13:05:27 miriam: Only way to do that with a new attribute in HTML is if we do something in media attriute 13:05:27 miriam: which is the only attribute that can stop the load 13:05:27 q+ 13:05:27 miriam: in CSS we no longer just have media condition for @import 13:05:33 miriam: we have import conditions which include supports() and media 13:05:45 miriam: so suggestion was to expand media to allow supports queries as well as media queries 13:05:57 miriam: allow authors to query for layers support 13:06:03 miriam: and also [missed] 13:06:08 miriam: we could use same attribute in future 13:06:17 miriam: we seem to come to same conclusion every time we check 13:06:22 miriam: but hard to move the specs forward on that together 13:07:01 miriam: Maybe need volunteers to help me move things forward 13:07:01 miriam: and also review 13:07:01 miriam: know of 2 issues open on CSSOM related to this 13:07:06 miriam: how do we move this forward? Authors are requesting 13:07:16 ack fantasai 13:07:18 q? 13:07:19 fantasai: the type attribute can also cause the load to fail 13:07:27 ack bramus 13:07:36 q+ 13:07:38 bramus: wanted to point out that if media condition fails, the file will be loaded, but will not apply 13:07:45 ack zcorpan 13:07:51 q+ 13:07:52 q+ 13:07:53 zcorpan: wanted to volunteer to help with the HTML thing 13:08:00 https://github.com/whatwg/html/pull/7658 13:08:13 ack hsivonen 13:08:24 q+ 13:08:29 hsivonen: Could it use a new rel keyword maybe? that would also fail to load in older browsers 13:08:47 hsivonen: could it use something like rel=stylesheet-layer so it doesn't load in older browsers? 13:09:15 q+ 13:09:16 zcorpan: is @import solution the same? having it in media seems OK to me 13:09:58 nicole_ has joined #css 13:09:58 annevk: long term syntax, seems annoying that always have to write stylesheet-layer plus an additional layer attribute 13:09:58 miriam: this would just be adding supports queries in media attribute 13:10:03 miriam: just for now during transition, you want to make it fail in old 13:10:08 miriam: so not adding layering in both places 13:10:15 ack emilio 13:10:28 emilio: Simliar to what Bramus mentioned, like to make sure that media conditoins 13:10:32 emilio: they're usually ?? 13:10:37 s/??/mutable/ 13:10:50 scribe+ 13:10:53 emilio: we should make sure we don't require downloading the resource 13:11:02 emilio: if the supports condition can never match 13:11:10 q? 13:11:20 s/we should/ but the same isn't true for @supports so we should/ 13:11:21 annevk: [asks for clarification] 13:11:28 emilio: they always load, but don't apply 13:11:31 emilio: and people rely on that 13:11:45 emilio: there are async loaders that set media to a non-matching value 13:11:49 emilio: and then change it later once it loads 13:11:58 hober: in browser with runtime feature flags 13:12:01 hober: [missed] 13:12:16 emilio: I think so, but way ???? works, because need to parse stylesheet 13:12:22 annevk: mediaqueries can [drifts off] 13:12:29 annevk: can the support thing match? 13:12:31 I agree that changing runtime feature flags during the life of a page is a good way to break assumptions that pages make! 13:12:33 various yeah 13:12:37 I would expect authors need to reload the page after flipping some flags on/off 13:12:45 [too quiet[ 13:12:48 emilio: you want to branch on whether the support parses 13:13:08 emilio: make it like imports 13:13:13 [mics are not picking up enough] 13:13:25 emilio: it would be consistent with @import 13:13:27 ack fantasai 13:13:27 fantasai, you wanted to suggest addressing bramus's comment 13:14:04 fantasai: I want us to address bramus's comment that if you have a @supports query that doesn't match you don't load the resource. Different from media queries. Can we resolve on that? 13:14:08 emilio: That's what I was trying to do. 13:14:10 fantasai: first off, I wanted to address bramus' comment, for supports() if it doesn't match it doesn't load the resource and media does 13:14:33 -> https://www.w3.org/TR/css-cascade-5/#at-import 13:14:44 -> https://www.w3.org/TR/css-cascade-5/#conditional-import 13:14:56 TabAtkins: [explains the spec] 13:15:32 noamr: already don't load the resource specwise 13:15:37 noamr: I think that doesn't need to change 13:15:41 q? 13:15:43 emilio: it does, and people depend on it 13:16:22 noamr: I think media and supports should be separate attributes 13:16:30 noamr: we decide not to load on supports 13:16:52 astearns: you're suggesting ??? 13:17:07 annevk: I think there was agreement on supports, but not ???? 13:17:17 astearns: proposed that if supports doesn't match, we don't load the stylesheet 13:17:22 s/on supports/not to load on supports/ 13:17:31 miriam: but we still don't have a cap on how to set supports 13:17:32 data:text/html, 13:17:36 q+ 13:17:48 astearns: any concerns with the proposed resolution? 13:17:56 fserb: If this changes behavior, how does it help with backwards compat? 13:18:00 annevk: this is the new feature 13:18:20 fserb: but browser that don't understand supports will still load 13:18:27 annevk: but they also won't apply the stylesheet 13:18:29 annevk: All browsers alert `data:text/html,` 13:18:53 zcorpan: they'd load in legacy browsers 13:18:56 q- 13:18:56 emilio: it's not amazing 13:19:01 q- 13:19:02 emilio: load but don't apply 13:19:26 fserb: so default behavior right now is if media query doesn't apply, loads but doesn't apply 13:19:30 annevk: loading is an open question... 13:19:50 q+ 13:20:01 [objections?] 13:20:03 q? 13:20:04 (There are other fun reasons to load non-matching media, such as (1) user loads a page (2) user goes offline (say, to disconnect from the network and connect ot a printer) and (3) user prints the page and needs the print stylesheet. ) 13:20:15 RESOLVED: if the supports query doesn't match on a don't load the stylesheet 13:20:25 ack fantasai 13:20:26 fantasai, you wanted to react to fantasai 13:20:49 q+ 13:21:26 fantasai: would parameters in the MIME type help here? 13:21:29 fantasai: I wanted to suggest: is passing parameters in the mime type a reasonable way to assign the name? 13:21:36 s/name/layer name/ 13:21:36 qq+ 13:21:44 zcorpan: type attribute is optional 13:22:15 zcorpan: would have to type it out 13:22:46 ack lea 13:22:47 lea, you wanted to react to fantasai 13:22:47 s/it out/out the type, which is lots of typing/ 13:22:54 lea: [missed] 13:23:13 lea: from architectural point of view, has a lot of uses not just CSS 13:23:26 lea: so not great to add an attribute specific to stylesheets 13:23:29 s/[missed]/two things here, one is ?? and the other is how to pass the layer name to CSS/ 13:24:05 q+ 13:24:05 lea: is there a way to add support for this in a more generic way, that would be useful to other formats? 13:24:05 q+ 13:24:05 +1 lea this was one of my concerns also 13:24:05 q? 13:25:39 ack zcorpan 13:25:39 zcorpan: rel attribute already adds the stylesheet, we can branch there 13:25:39 zcorpan: don't think there's an issue with layer attribute. We also have color attribute on meta 13:25:39 zcorpan: only applies for theme-color etc. 13:25:39 lea: this is a problem in HTML, that it's a mistake to overload one element for diverse usecases 13:25:39 lea: when we add an attribute, it's there regardless of the value of other attributes 13:25:39 lea: it would be good if we had foresight to limit 13:25:39 annevk: HTML editors might disagree with this position 13:25:39 annevk: what zcorpan said matches our position 13:26:13 annevk: already has a bunch of uses with different attributes 13:26:13 annevk: it's been fine 13:26:13 annevk: in theory, I understand what you're saying 13:26:17 annevk: but in practice you need to think about what makes things easy to write, easy to read 13:26:25 annevk: you can already tell from the context that this is about stylesheets 13:26:32 annevk: if you go for something too generic, it becomes less understandable 13:26:37 lea: there's also discoverability problem 13:27:16 hober: but that's regardless 13:27:16 noamr: it's consistent with how has been 13:27:16 noamr: e.g. preload, it hasn't been that bad 13:27:16 annevk: also limited number of elements in the 13:27:20 hober: can't add new elements in the 13:27:37 annevk: [gives examples of uses and splitting out] 13:27:51 q? 13:27:55 annevk: if you had different problems, you'd have pre-load element, etc. 13:28:00 ack khush 13:28:14 khush: if we add support for this 13:28:20 q- 13:28:20 khush: [something] 13:28:52 khush: maybe that's what authors do right now? 13:28:52 khush: check in JS and then add link if supported 13:28:52 fantasai: we want this to be declarative 13:28:52 s/[something]/until support for supports is around, you can conditionally load with javascript/ 13:29:24 khush: you can't use supports() right now to solve the existing problem 13:29:31 khush: existing browsers will ignore supports() and fetch the resource anyway 13:29:31 khush: can't see how adding supports() fixes the problem 13:29:33 q+ 13:29:49 astearns: [???] 13:30:27 khush: has layer= already shipped? 13:30:27 [missed the answer] 13:30:27 annevk: Stylesheet load doesn't apply, media fails to parse so stylesheet doesn't apply 13:30:27 yes 13:30:27 s/[missed the answer]/no 13:30:27 annevk: there would be loading impact, but not visual impact 13:30:58 khush: if I put this in the media attribute, media would be ignored 13:30:58 cathiechen has joined #css 13:30:58 annevk: if media attriute value is parsed, and based on whether returns true or false, you apply the stylesheet 13:31:00 hober: it's equivalent to writing an MQ that never matches 13:31:19 [some meandering] 13:31:39 [coments about perf during transition period] 13:31:47 khush: JS seems trivial enough 13:31:56 doing stuff in JS also has loading impact. Would prevent the resource from being discovered early. 13:31:57 khush: to make it not load 13:32:22 q- 13:32:33 [can't hear] 13:32:33 q? 13:32:33 q? 13:32:35 q- lea 13:32:35 q- 13:32:37 ack lea 13:32:41 type="type/css;layer=name" could work? 13:32:56 maybe less convenient to ype than layer="name" 13:32:57 I think it'd be awkward to bring type back 13:33:00 We just got rid of it 13:33:24 yea type parameters are parameters about the type, not content parameters 13:33:26 astearns: zcorpan will work with miriam on doing all the stuff we just talked about 13:33:28 q+ 13:33:52 I think we'll probably want content parameters going forward somehow or other... e.g. discussing for SVG 13:34:00 bramus: layer attribute, we have similar request for @scope 13:34:12 ack bramus 13:34:16 bramus: so something to keep in the back of the mind while thinking about this for layers specifically 13:34:16 dino has joined #css 13:34:18 https://github.com/whatwg/html/issues/9315 13:34:21 github-bot, take up https://github.com/whatwg/html/issues/9315 13:34:21 astearns, I can't comment on that github issue because it's not in a repository I'm allowed to comment on, which are: w3c/csswg-drafts w3c/fxtf-drafts w3c/css-houdini-drafts w3c/svgwg web-platform-tests/wpt WICG/animation-worklet WICG/construct-stylesheets WICG/scroll-animations WICG/custom-state-pseudo-class. 13:34:44 Topic: First Render Event 13:34:50 fantasai: we could add other attributes, depending on the need, it's not clear there's a generic scheme here 13:34:57 https://github.com/whatwg/html/issues/9315 13:34:59 noamr: CSS View Transitions 13:35:10 noamr: what happens is initial document starts a transition, captures elements 13:35:18 noamr: second document becomes active, captures elements 13:35:24 noamr: then we animate between the two states 13:35:40 noamr: can do when animation is purely in CSS 13:35:48 noamr: but if using Web Animations API or other JS for the animation 13:35:59 noamr: then we need a hook in the new page that we're going to render now 13:36:07 noamr: and there has been a view transition from the previous document 13:36:21 noamr: allow to hook into its promises, like you can when you call a same-page view transition 13:36:32 noamr: suggestion was "reveal" event or "readytorender" 13:36:40 noamr: this event is fired always before first render opportunity after navigation 13:36:46 related csswg issue: https://github.com/w3c/csswg-drafts/issues/8805#issuecomment-1640688426 13:36:48 noamr: so initial load after all elements render unblocked 13:36:58 noamr: or when restored from ?? which are not initial load of live document 13:37:06 s/??/bfcache/ 13:37:13 noamr: wanted to emphasizes this event is not about painting or dispaying frames 13:37:13 q? 13:37:20 noamr: some concerns about showing cached frames from bfcache 13:37:37 noamr: this is about best render opportunity, want to know before the next render opportunity after navigation -- either initial navigation or pre-render restore 13:37:40 s/best/next/ 13:37:45 noamr: also in issue, how this would work 13:38:00 noamr: event would have a viewTransition attribute which is null if no transition 13:38:12 smaug: if only about first rendering opportunity then why ??? 13:38:29 s/???/can't you use rAF callback/ 13:38:40 noamr: viewTransition object, there's no convenient way to expose in rAF callback 13:38:45 noamr: we'd have to put it on the document or something 13:38:59 s/viewTransition object/we want to expose the viewTransition object/ 13:39:03 noamr: We reduce ?? like RAF to know when the next render opportunity is 13:39:14 noamr: then we have the promises 13:39:28 noamr: why I was afraid of that a bit is, people forget to do bfcache-specific things 13:39:39 noamr: you'd request animation frame in the head, and it would work for initial load 13:39:48 noamr: but you'd forget to do it on cache restore 13:39:56 noamr: so to work this consistently, you'd have to do it in two places 13:40:07 noamr: want to avoid that by saying there's an event, this is the only way to access the viewTransition 13:40:19 noamr: and it's guaranteed to happen any time you might have a VT 13:40:25 noamr: other way could work, but more error-prone 13:40:27 q+ 13:40:34 ack khush 13:40:47 [missed] 13:41:03 khush: another question came up, if pages marked up styesheets or resources that are render-blocking 13:41:14 khush: you fire event when those time out, or when render opportunity starts 13:41:17 khush: no strong preference 13:41:29 khush: main condition is it has to fire before first rAF 13:41:56 astearns: proper conclusion from your remarks is, we need a new event because timing is different from rAF (requestAnimationFrame)? 13:42:08 khush: not obvious otherwise how to find the first rAF in the bfcache 13:42:24 annevk: [something about cachced already] 13:42:28 annevk: wouldn't know ... 13:42:44 smaug: out of bfcache, you might not have a render opportunity 13:42:47 smaug: so might not get this 13:42:54 smaug: ?? is always guaranteed to fire before... 13:42:59 noamr: it might not have rendering need 13:43:11 noamr: in the ??? part of HTML, there's a render opportunity, if nothing happens exist 13:43:16 noamr: but before you can render if you want to 13:44:00 zcorpan: couldn't follow the problem you raised 13:44:00 noamr: can be when we know there's going to be a render opportunity or once it has arrived 13:44:04 noamr: but this is subtle, and for our use case it doesn't matter 13:44:13 zcorpan: seems to me having the same time as ???? 13:44:22 s/????/raf/ 13:44:22 annevk: the other one would give the page an additoinal timing 13:44:32 noamr: this is a timing you can polyfill today 13:44:39 annevk: the first one, the second one is first rAF 13:44:50 zcorpan: other callbacks before rAF 13:45:00 [missed] 13:45:02 q+ 13:45:06 zcorpan: rAF timing 13:45:13 noamr: we want it before all of those, before focus and all that events 13:45:19 zcorpan: so first step in rendering 13:45:29 noamr: yes, before everything else. This is about how ot render kind of thing 13:45:43 smaug: in Firefox, we would enter ?? if we know we probably will call the callbacks 13:45:52 smaug: if there's nothing to update in layout 13:46:08 smaug: our implementations might not match exactly 13:46:29 noamr: I think this is in favor of doing it earlier, in same task as page hide, document not render blocked 13:46:38 noamr: load event of last render blocking element 13:46:45 spec for "update the rendering" in html https://html.spec.whatwg.org/multipage/webappapis.html#update-the-rendering 13:46:49 ack ydaniv 13:47:04 ydaniv: Looking at the comment, seems discussion is from implementers point of view 13:47:21 ydaniv: but from authors' point of view, how does that event ... how can that give me any guarantee about state of what's rendered in the new document? 13:47:30 ydaniv: that it's actually showing what I want to transition to? 13:47:36 ydaniv: maybe extermely partial and whole transition will look bad 13:47:50 khush: separate issue after this one about that problem, which is what state the DOM is in 13:47:56 khush: and if author control that 13:48:10 astearns: hearing that new event is better for authors because linked to this feature 13:48:15 [too quiet] 13:48:39 ydaniv: But what does that timing guarantee for developers? is this the right stage? 13:48:45 ydaniv: not that, it’s wondering whether this new event is giving the right information tot he author 13:48:55 noamr: open a new website, then you have a loader 13:49:01 noamr: loader waits for everything, all resources 13:49:05 s/noamr/ydaniv/ 13:49:16 noamr: if we eliminate this view transition, then does the new event give me enough guarantee that [missed] 13:49:20 s/noamr/ydaniv/ 13:49:25 ydaniv: state is something I can get a transition? 13:49:41 khush: problem in this issue is, browser at some point will decide to start rendering 13:49:58 khush: this hook is for you to learn when that decision has been made and being able to know what DOM looks like at that point 13:50:06 q+ 13:50:08 khush: as for how long the browser decided to wait, that is a separate problem 13:50:14 ack noamr 13:51:05 noamr: does help you here, you get the event, and can look at DOM that will render 13:51:05 noamr: can make changes, e.g. hide something 13:51:05 noamr: powerful tool on top of render-blocking and structuring the transition 13:51:38 noamr: you can do in JS much more complicated things than you can do in CSS 13:51:38 astearns: What do we want to conclude here? 13:52:11 noamr: want to know if any objections with where this is going 13:52:11 noamr: speak on details in the issue 13:52:11 noamr: wanted to know if OK with general direction 13:52:11 smaug: I think we can continue on details 13:52:21 smaug: curious about plans for implementations 13:52:25 smaug: are you expecting to wait for ?? to happen before you paint? 13:52:30 smaug: that might affect user behavior 13:53:12 smaug: in a way that's an implementation detail, but also user-visible 13:53:12 ack fantasai 13:53:12 q? 13:53:12 fantasai: I hear we have decent agreement on this event. 13:53:12 fantasai: Two options on timing, there seems to be a preference between them. Do we want to capture it? 13:53:46 s/this/having this/ 13:53:46 noamr: Option is firing event when we know we're going to have a rendering opportunity 13:53:46 noamr: vs firing *at* the rendering opportunity 13:53:46 noamr: the preference was for the second one 13:53:46 q+ 13:53:46 noamr: but it has pros and cons, and I don't think we resolved on which one 13:53:49 noamr: but we can discuss in the issue 13:53:52 ack khush 13:54:20 khush: pretty sure in Chrome's impl if you go back to bfcache page, you have to render a new thing 13:54:33 khush: we have cached rendering that we could go back to 13:54:41 khush: this implies that we have a no-op 13:54:50 [too quiet] 13:55:01 khush: I'm pretty sure in Chrome's impl a BFCache page has to be rendered in one frame 13:55:02 smaug: think expected behavior should be specified, you may get a paint or not 13:55:04 discussion about bfcache case 13:55:14 astearns: so cautious go-ahead for continuing this route 13:55:40 Topic: Render Blocking 13:56:09 Topic: Select List 13:56:16 github: https://github.com/w3c/csswg-drafts/issues/9284 13:56:28 jarhar: Joey from Google 13:56:42 romain has joined #css 13:56:44 jarhar: in Open UI we've been working on new HTML element called , intended to be more customizable select 13:56:59 jarhar: ran into issue of wanting render one piece of user markup in two different places at the same time 13:57:06 jarhar: and make them independently styleable 13:58:12 Selectlist element explainer for more context: https://open-ui.org/components/selectlist/ 13:58:50 jarhar: this is an example of a select list, one of the common desires is adding icons for each item 13:58:59 jarhar: so you can use an option, and see the button 13:59:07 jarhar: entire contents of option, not just text 13:59:18 jarhar: do this with 13:59:25 jarhar: currently implemented via cloneNode() 13:59:35 jarhar: replace content with selected option 14:00:14 jarhar: chose this solution because not much better option 14:00:14 jarhar: considered shadow DOM, but hard to style 14:00:14 jarhar: considered requiring authors to add script, but want declarative 14:00:14 jarhar: several others 14:00:26 jarhar: I mentioned styling differently, here's another example 14:00:31 jarhar: button renders content differently from options in the list box 14:00:39 jarhar: shows symbol, not the text 14:00:53 jarhar: accomplished with CSS rule that sets text to 'display: none' but only when inside selectoption element 14:00:59 jarhar: wanted to ask if CSS has a better way to do this 14:01:13 jarhar: cloning the user DOM into another part of HTML spec is unusual, there's no precedent 14:01:19 jarhar: concerned might be error-prone 14:01:25 annevk: also creates synchronization issues 14:01:30 annevk: HTML elements are expected to be ??? 14:01:39 s/???/live/ 14:01:39 annevk: you'd have to clone, and gets very messy very quickly 14:01:39 s/???/live/ 14:01:44 annevk: wanted to have two sets of render ??? 14:01:57 q+ 14:01:58 TabAtkins: only one spot in the DOM, but render twice 14:02:06 jarhar: idk what part of rendering or which tree this might exist in 14:02:16 s/???/boxes/ 14:02:18 jarhar: [something about Shadow DOM] 14:02:34 q+ 14:02:34 jarhar: Here's the problem, if anyone wnats to comment in the CSSWG issue we opened, that would be helpful 14:02:47 ack TabAtkins 14:02:50 ack TabAtkins 14:02:52 ack bkardell_ 14:02:52 bkardell_: Similar thing [fades out] 14:02:58 cna't hear brian 14:03:06 s/cna't/can't 14:03:13 s/[fades out]/have been requested 14:03:50 bkardell_: this has been asked for in several ways at different times 14:03:53 jarhar can you stop presenting so we can see people? 14:03:56 bkardell_: e.g. elements() in CSS 14:04:09 bkardell_: issue on Open UI 616, cgives use cases and rationale 14:04:27 bkardell_: March 2021 HTML 6607 asking for an element like but called for similar needs 14:04:33 bkardell_: clear desire for something like this 14:04:47 astearns: then let's leave this as Yes, we want to do this 14:04:51 astearns: ask CSSWG to review 14:05:23 alisonmaher has joined #css 14:05:31 Topic: Render Blocing 14:05:36 s/cing/cking/ 14:06:06 https://github.com/whatwg/html/issues/9332 14:06:07 khush: lots of discussion on the issue, summary in the issue 14:06:13 https://github.com/whatwg/html/issues/9332#issuecomment-1716016698 14:06:37 khush: transitions look at the DOM and ... need to know what the size/psoition of each element is 14:06:45 khush: for that to happen, the element needs to be in the DOM 14:07:30 khush: since most browsers do incremental rendering, each with their own heuristics 14:08:07 khush: if browser considers the elements, they will not all be there, major interop issue 14:08:07 khush: in HTML spec, we added concept of "these are important, and must be visible before rendering" 14:08:10 khush: then can time out 14:08:10 khush: we've done this for script, done it for stylesheets 14:08:10 khush: missing for parsing 14:08:10 khush: we want to allow dev to say, you probably want to parse these elements before rendering 14:08:10 khush: question came up wrt full blocking, or partial 14:08:14 khush: should API shape... more performant if partially 14:08:22 khush: but could still require full HTML parse 14:09:35 khush: another issue is, how do you identify which elements are blocking 14:09:35 khush: some suggestions about HTML attributes, and another about using CSS 14:09:35 khush: if HTML attribute, the browser can check if it's parsed the elements 14:09:35 khush: if computed style, then you need to run the cascade 14:09:35 khush: I really want to emphasize, although render-blocking comes with timeout 14:09:35 khush: it's a powerful feature, and very aggressive 14:09:35 khush: so needs to have an aggressive timeout 14:10:09 khush: even if HTML has been fetched, gives consistent vie wof how much HTML to parse 14:10:09 khush: next issue is when to apply, spec will allow the UA to choose 14:10:14 khush: e.g. when switching tabs, might be more aggressive on timeout to give more responsive feeling 14:10:23 khush: always, you are not guaranteed, because of timeout 14:10:41 khush: link at end of issue with proposed syntax 14:10:41 proposed syntax: https://github.com/WICG/view-transitions/blob/link-proposal/document-render-blocking.md#blocking-element-id 14:10:47 khush: suggesting new value to rel attribute for links 14:11:03 khush: declaring elements I want to parse before render unblocked 14:11:13 khush: and give IDs of elements you care about 14:11:29 khush: already a blocking attribute on link element to say what state you want it to block 14:11:39 khush: currently only render is possible, but can add more blocking 14:11:51 khush: what I look for here is, what capability should be added 14:11:58 khush: secondly, does approach look reasonable 14:12:03 khush: if not any alternative suggestions? 14:12:07 q+ 14:12:17 Example from issue: 14:12:17 14:12:21 14:12:27 ack fantasai 14:13:45 fantasai: was wondering if there are some resources where, might not want to block generally, but would need for the view transition to look right 14:13:53 fantasai: e.g. large focus image on the page 14:14:05 khush: Considering have blocking=transition, which would block transition but not render generally 14:14:28 ack zcorpan 14:14:40 zcorpan: I agree with the direction wrt render-blocking on element 14:15:07 zcorpan: discussed some other options today, but they're complicated to implement 14:15:13 zcorpan: specifying a list of elements seems like a good solution 14:15:22 zcorpan: if browser is allowed to time out sooner at its discretion 14:15:28 zcorpan: Not sure I like the syntax, seems a bit verbose 14:15:28 q+ 14:16:19 zcorpan: is media attribute needed for this? or just got it for free 14:16:19 astearns: you might want the media, for the case where you've got a view transition and you know in CSS that you're not going to apply because 'prefers-reduced-motion' is in place 14:16:23 astearns: don't want to block in that case 14:16:46 zcorpan: in that case the browser also knows the prefers-reduced-motion preference, can block view transitions completely 14:16:59 astearns: view transition definitely won't happen, but blocking will happen because browser doesn't know yet that view transition won't happen 14:17:12 khush: this particular case of prefers-reduced-motion might not be best example 14:17:12 khush: because likely both are same-origin 14:17:58 khush: so we didn't start the transition on the old page 14:17:58 khush: but because API is irrespective of view transitions 14:17:58 khush: maybe depending on [missed], those cases are where media query would be useful 14:17:58 ack noamr 14:17:59 noamr: classic case is mobile vs desktop 14:18:14 noamr: another, for prefers-reduced-motion, don't want to stop all transitions. E.g. fades are OK 14:18:25 noamr: prefers-reduced-motion doesn't mean no animation at all 14:18:41 noamr: wrt choice of link, mental model is it's like anchor in the page that you can scroll to 14:18:48 noamr: but instead of scrolling to it, you're waiting for it 14:20:07 noamr: this is your virtual fold, expect that place to happen and render-block it 14:20:14 zcorpan: question, are developers happy with using the ID attribute on all of the elements, or do they want to use selectors to specify which elements should be render-blocking? 14:20:17 khush: I haven't heard enough of a push for it 14:20:26 khush: using selectors means you have to run style cascade 14:20:35 khush: haven't heard desire to extent that it would be worth the tradeoff 14:20:55 noamr: don't have to specify all the elements, just one place that's after all the things you want included 14:21:02 noamr: just defining your virtual fold 14:21:53 astearns: that would be ideal case, but probably cases where there will be elements with these IDs, but not sure what order they'll come in 14:21:54 zcorpan: does it stop blocking on end tag or start tag? 14:21:54 noamr: end tag 14:21:54 zcorpan: that seems like the right one 14:22:03 kbabbitt has joined #css 14:22:10 ack fantasai 14:22:11 s/noamr/khush 14:23:02 fantasai: I think this is pretty reasonable. When you select an element you select all of its contents 14:23:08 ... so I think it'd be easy to use in most cases 14:23:16 annevk has joined #css 14:23:17 ... I'm curious about external resources 14:23:28 khush: for resources like stylesheets, can already block on those 14:23:39 khush: for images, a bit controversial to block on images 14:23:41 q+ 14:23:49 khush: when first added to Blink, no limitation, but explicitly limited to stylesheets 14:23:56 khush: because devs might not make the best tradeoff if possible on images 14:24:08 khush: secondly, the image cases is also interesting in that, when you're doing a specific element 14:24:11 khush: you need the element to be parsed 14:24:29 khush: but during transition because it's live, as image is fetched it automatically fades in 14:24:33 khush: so less urgent need to block on images 14:24:43 q- 14:24:50 khush: more inclined to say, case by case, if someone really wants to block on image content we can add that, but very cautiously 14:25:04 annevk: what happens when ?? gets parsed? 14:25:11 s/??/end tag/ 14:25:11 s/??/end tag/ 14:25:38 noamr: in spec terms, when you see that link thing, linked element is render-blocked, and once you see the end tag then it's no longer render-blocking 14:26:07 noamr: no different than render-blocking link rel=stylesheet 14:26:25 ... 14:26:28 annevk: no way to look into that currently 14:27:37 [poking around] 14:27:42 q? 14:27:59 astearns: I like the proposal, particularly with the aggressive timeouts to prevent content being inaccessible if things go wrong 14:28:03 q+ 14:28:05 khush: a couple more things we were thinking about 14:28:09 ack khush 14:28:30 khush: one aspect, once the body tag has been parsed - HTML has "until we insert body you can add render-blocking link elements, you can't add anything but you can remove stuff" 14:28:41 khush: so authors can customize 14:28:50 khush: once done parsing, can't add anything 14:29:04 khush: second thing, if element fails to be found, then page stuck until timeout 14:29:24 khush: how can we make it obvious to author that they messed up, and one idea was to skip the transition so you notice 14:29:27 q+ 14:30:14 ack hsivonen 14:30:14 zcorpan: visual punishment. I like it. 14:30:14 q? 14:30:14 hsivonen: does that mean that any element whose ID is mentioned has to have its end tag recorded? 14:30:47 annevk: that's what's being proposed, yes 14:30:58 hsivonen: there are like 6 elements and 1 svg element that might have perf implications of how much more traffic there will be between parser and rest of engine 14:31:05 hsivonen: if these need to be recorded just in case 14:31:12 hsivonen: instead of parser knowing which end tags need to be recorded 14:31:19 annevk: I'm also uncomfortable about exposing end tag timing 14:31:36 annevk: [missed] 14:31:50 khush: I think in this case, interally you can set in the parser, I care about when you parse the end tag 14:31:55 Not quite decided that we don't want that: https://github.com/WICG/webcomponents/issues/809 14:32:06 s/[missed]/we decided not to do this for custom elements/ 14:32:07 khush: until you're still looing for elements, parsers will tell you whether it's done or not 14:32:21 khush: no callback or script callback or anything like that 14:32:24 annevk: that is true, can optimize 14:32:35 khush: expose to script? 14:32:49 khush: can try it out and see if any perf implications 14:33:08 smaug: if you create elements (statically?) authors need to optimize 14:33:14 smaug: any extra call... need to be careful here 14:33:28 noamr: wrt end tags, thing about this event is that it needs to happen at some time after the end tag has been reached 14:33:45 noamr: can even spec happens when parser yields, happens if has reached 14:33:55 noamr: rather than exposing end tags problem 14:34:01 q+ 14:34:05 smaug: when you're parsing inner HTML, then you need to always [...] end tags 14:34:16 astearns: out of time 14:34:23 astearns: seems parser performance is highest concern 14:34:29 astearns: work through details and come back 14:34:32 astearns: break time! 14:34:42
14:34:46 ack khush 14:46:04 https://i.imgur.com/G7Su2Ss.png 14:56:19 noamr has joined #css 14:58:06 munira has joined #css 14:58:09 futhark has joined #css 14:58:13 bramus has joined #css 14:58:15 drott has joined #css 14:58:16 rachelandrew has joined #css 14:58:18 Dongwoo has joined #css 14:58:24 brandon has joined #css 14:58:26 una has joined #css 14:58:26 devsnek has joined #css 14:58:26 emilio has joined #css 14:58:26 sakhapov has joined #css 14:58:26 TabAtkins has joined #css 14:58:29 nicole has joined #css 14:58:30 dbaron has joined #css 14:58:32 cabanier has joined #css 14:58:37 foolip has joined #css 14:58:41 dandclark has joined #css 14:58:46 chrishtr has joined #css 14:58:49 jbroman has joined #css 14:58:56 astearns has joined #css 14:59:03 vmpstr has joined #css 14:59:04 oriol has joined #css 14:59:08 iank_ has joined #css 14:59:08 hayato has joined #css 14:59:09 gregwhitworth has joined #css 14:59:10 sangwhan has joined #css 14:59:19 jyasskin has joined #css 15:04:30 andreubotella has joined #css 15:05:18 zcorpan has joined #css 15:06:44 romain has joined #css 15:06:48 jensimmons has joined #css 15:08:17 khush has joined #css 15:08:31 present+ 15:08:38 present+ 15:09:09 ScribeNick: TabAtkins 15:09:50 https://github.com/w3c/csswg-drafts/issues/8960 15:09:50 github-bot, take up https://github.com/w3c/csswg-drafts/issues/8960 15:09:50 Topic: [css-view-transitions-2] Syntax for customizing transitions based on their type 15:09:50 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/8960. 15:11:02 Summary: https://github.com/w3c/csswg-drafts/issues/8960#issuecomment-1708702647 15:11:02 noamr: I posted a summary content for where we've gotten to and what the proposal is 15:11:02 noamr: We also gave a summary in general of VT yesterday 15:11:02 noamr: This is a continuation from the f2f a few months ago 15:12:06 noamr: With a single document with many VTs possible - think of a spotify that can slide-transition between main pages, and a different between a played song where it expands 15:12:06 noamr: So we want a way to say "don't take everything from the page that can transition", but rather name the type of transition and pick and choose which elements go with what 15:12:48 noamr: So far the way to do it is modifying the DOM: put a class on that you use in a selector to set v-t-name 15:12:48 mrobinso has joined #css 15:12:48 noamr: Some issues, using DOM as ephemeral state for something that's entirely style 15:12:48 noamr: Plus when we go later in cross-document, we want a declarative way to do this 15:12:51 noamr: So we want a notion of cross-frame transitions that's embedded into CSS rather than a general-purpose JS mechanism. 15:13:04 noamr: Proposed syntax is something that looks and feels like class names 15:13:40 noamr: We'd pass it together with the v-t 15:13:40 noamr: Currently it only accepts one parameter, the update callback 15:13:40 noamr: We suggest another parameter, a list of a transition types 15:13:42 noamr: like "slide" or "reverse-slide", etc 15:14:21 noamr: And then have a pseudo-class on whatever's scoping the transition (currently, always ), and that matches based on which transition types are activated 15:14:34 noamr: I want to present the alternative we consdiered, too 15:14:44 ydaniv has joined #css 15:14:44 noamr: Which was to qualify the pseudo-elements that are created 15:15:03 noamr: We thought that wasn't enough, since the transition type also affects which elements are picked for the transition, not just which pseudo-elements are created. 15:15:18 noamr: The more advanced alternative is we qualify pseudo-element names too. 15:15:24 noamr: That's possible, but felt limiting. 15:15:37 noamr: Perhaps you want to hide something in the page while the transition is going on, it' snot necessarily participating in the transition. 15:15:53 lea has joined #css 15:15:54 q? 15:15:54 noamr: So we felt there's not much reason to avoid our preferred solution, and the other ways are all limited. 15:15:59 present+ 15:16:01 +1, this sounds good 15:16:56 TabAtkins: i like this idea, and sounds reasonable. official cases brought up with things that don't participate makes sense 15:17:01 q+ 15:17:21 ack khush 15:17:25 khush: I prefer "type" over class names 15:17:28 +1 15:17:40 q+ 15:17:41 khush: because there's another feature request where people want to apply styles to some pseudos 15:18:07 khush: right now you can either do all ::v-t-group() or one with a particular name, can't do just some in a group 15:18:12 q+ 15:18:12 khush: Second is "and" vs "or" 15:18:22 khush: keeping the same syntax as proposed here seems good 15:18:27 ack fantasai 15:18:48 fantasai: I agree with khushal that using classes seems tied into html classes, seems confusing. "type" seems fine. 15:19:02 lea: https://github.com/w3c/csswg-drafts/issues/8960 15:19:14 fantasai: Another q, when you specify multiple names in the pseudo-class, is that "and" or "or". If it's "or" you should use a comma. 15:19:18 fantasai: Overall a good approach. 15:19:20 ack noamr 15:19:34 noamr: I thought "types" were a bit [missed], it describes something nominal 15:19:40 noamr: But im' fine with that 15:19:57 noamr: For "and" vs "or", we thought of spaces meanin "and" and commas meaning "or" 15:20:09 sounds good 15:20:45 +! 15:20:48 s/!/1/ 15:20:51 TabAtkins: Other option is we just do neither and rely on selector syntax to handle and/or 15:21:03 TabAtkins: Depends on how common we think selecting on multiple names will be 15:21:07 q+ 15:21:12 astearns: That would also be more compatible with future development 15:21:17 noamr: Yeah, that's a possibility 15:21:25 vmpstr: Comment about the name 15:21:26 ... It's a reallllly long pseudo-class name, let's not make people type out that much for simple booleans :) 15:21:43 vmpstr: I prefer "class" over "type" specifically because I think there's a possibility of using this in other contexts like web animations 15:21:51 could think of and/or as a future extension to solve that pain :) 15:21:57 vmpstr: This would be able to set a number of additional classes that last for some duration 15:22:22 vmpstr: In this case the pseudo-class name would have to be in there, so it's not tied to VT 15:22:40 vmpstr: But if it's specifically "class"... I'm not particularly tied to it but it invokes CSS classes which is what this acts like. 15:22:58 TabAtkins: This is basically an automatically-managed class 15:23:06 TabAtkins: browser is adding/removing for you 15:23:17 ack ydaniv 15:23:23 ack vmpstr 15:23:33 YehonatanDaniv: The direction is good, if we had a list of types/classes/whatever, I think doing "and" would be more productive 15:23:53 YehonatanDaniv: But in general having a list of types, this covers the need 15:24:16 romain has joined #css 15:24:19 present+ 15:24:33 astearns: I had an instinctual yuck against using space/comma to indicate and/or 15:24:46 astearns: Any strong reason to not use `and` and `or` keywords? 15:25:02 noamr: No particular reason, jsut consistency with selectors. But that would be consistent with MQs, so. 15:25:40 noamr: Another idea was to borrow the class selector syntax, so `.page.slide, .foo-slide` 15:26:00 astearns: How much do you think we can resolve on today? 15:26:18 q? 15:26:21 noamr: I'd like to say that we'll decide on the name and the and/or syntax later, but the general idea is good. 15:26:32 We use commas to mean "or" in several places in functional pseudo-class syntax 15:26:37 astearns: I'd like to add a specific syntax in the spec if possible 15:27:01 astearns: If people have concerns about what we chose, they can raise issues. 15:27:12 noamr: I suggest to resolve for now on "type" and not having and/or syntax yet 15:27:22 noamr: Since selectors can already do and/or for now. 15:28:17 khush: If we resolve on this now, will this break if someone makes a VT type named "and"? 15:28:52 TabAtkins: No, since we'll currently be allowing only one name. In the future if we allow and/or internally, it'll be written ":v-t-type(and and foo)`, which is perfectly unambiguous (to a machine) 15:28:53 q+ 15:29:07 fantasai: we use commas all over selector syntax to mean "or" 15:29:29 +1 15:29:29 fantasai: So even if we decide to add boolean keywords later, we'd probably still want commas for consistency with tons of things 15:29:42 fantasai: So I think we should adopt that in the first iteration as well 15:29:49 ack fantasai 15:29:49 +1, it is very natural 15:29:54 ack ydaniv 15:29:58 and the "and" selector behavior is shorter 15:30:09 YehonatanDaniv: So if I get this right, I can specify a few tpes in the startViewTransition() call 15:30:47 TabAtkins: They'll all apply 15:31:08 noamr: So elika do you want space for "and"? 15:31:15 fantasai: I'm fine with that, I mainly just care about commas for "or" 15:31:40 TabAtkins: and might inhibit future syntax design 15:31:56 s/and might/"and" might/ 15:32:10 astearns: So it sounds like we have consensus on adding a list of types to VT 15:32:11 khush: yes 15:32:20 astearns: and add exapmles for referring to them 15:32:46 astearns: Objections to list of types? 15:33:23 vmpstr: Are we specifically calling these "types"? 15:33:37 fantasai: For the argument we can say "names", editorially we can call them type names or class names or wahtever. 15:33:45 noamr: Yeah because the name wouldn't occur in CSS 15:34:09 we use the word "names" as the parameter name in CSS, and that word does not appear in CSS 15:34:10 dino has joined #css 15:34:21 sorry, we use the word "names" as the parameter name in JS, and that word does not appear in CSS 15:34:24 s/name in CSS/name in JS/ 15:34:26 PROPOSED: Add a 'names' argument to startViewTransition that takes a list of CSS identifiers, allow them to match against a pseudo-class which accepts a comma-separated (or) list of view transition names to match 15:34:33 s/to match/during which it matches/ 15:35:01 vmpstr: So clarifying the syntax, there's a distinction between adding the second param to sVT(), which is different from Noam's comment that has a dict 15:35:22 noamr: We'r enot proposing a second param, we want sVT() to accept *either* a callback or an options bag 15:35:30 The options will be a callback and the names 15:36:01 dbaron: Is there a reason not to do a callback followed by an options bag? 15:36:26 noamr: This is an API design more from Jake; we don't think the update callback is the obvious first param, it was just the only one earlier. 15:36:32 dbaron: That makes sense. 15:36:59 zcorpan: Slight concern with "names" as the name. We already have view-transition-name 15:36:59 that's a good point 15:37:30 TabAtkins: I propose that we resolve on the name of the option in two weeks, when we next meet 15:37:49 PROPOSED: Add a 'TBD' argument to startViewTransition that takes a list of CSS identifiers, allow them to match against a pseudo-class which accepts a comma-separated (or) list of view transition names during which it matches 15:38:06 TabAtkins: What's the pseudoclass called? 15:38:11 RESOLVED: Add a 'TBD' argument to startViewTransition that takes a list of CSS identifiers, allow them to match against a pseudo-class which accepts a comma-separated (or) list of view transition names during which it matches 15:38:11 noamr: :active-view-transition() 15:38:57 https://github.com/w3c/csswg-drafts/issues/8048 15:39:00 noamr: And we wait for "and" semantic later if needed 15:39:13 github-bot, take up https://github.com/w3c/csswg-drafts/issues/8048 15:39:13 Topic: [css-view-transitions-2] Declarative opt-in for cross-document navigations 15:39:13 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/8048. 15:39:22 https://github.com/w3c/csswg-drafts/issues/8048#issuecomment-1716035713 15:39:44 noamr: Same as previous, I posted a comment that summarized current thinking and has some HAQs 15:39:52 noamr: this is about cross-document VT 15:40:04 noamr: the way we look at this, it's a conditional dependency 15:40:24 noamr: An if() statement that's called twice, once when you leave the old doc, and once when you're ready to render the new doc 15:40:44 noamr: when this event happens we want to check the conditions are met 15:40:48 noamr: Some are environmental, like from MQ or supports, others are conditions about navigation itself 15:41:02 noamr: Sematnically this could mean "are we moving from 'play' page to 'song' page" 15:41:06 leaverou_ has joined #css 15:41:25 noamr: If conditions are met we want to start the VT, as if we were in JS. On the old page that means capturing the state of the old document and magically passing it along to the new one. 15:41:44 noamr: So on the new page if we successfully opted in, we start the VT with the stuff we captured from the old doc 15:41:55 noamr: And w'ell pass the transition types that we just talked about 15:42:09 noamr: So if going between a playlist and song page, this is an "expand" transition 15:42:25 noamr: So these are ways to declaratively map what VT is taking place 15:42:35 noamr: We're thinking of the whole thing as a transition behavior that's activated from a navigation 15:42:36 lea_ has joined #css 15:42:47 noamr: As we decided in last f2f we wanted a new at-rule 15:42:52 noamr: Currently called @navigation 15:43:02 noamr: First cross-document thing in CSS, exciting 15:43:13 noamr: Details all in the comment 15:43:22 noamr: We qualify the navigation in some way 15:43:33 noamr: Inside of it we ahve descriptors, like font descriptors. 15:43:40 lea_ has joined #css 15:43:46 noamr: view-transition-behavior, and which type names are passed along 15:44:06 lea_ has joined #css 15:44:16 noamr: There was a q from elika yesterday why we went with a name like "same-origin", or why it has to be urls 15:44:22 noamr: We really dug into this quite deep 15:44:35 noamr: The first proposal in this sapce was we parse both docs, and they each declare what type they are 15:45:11 noamr: Doc A could say it's "playlist" and doc b could say it's "song", but that's complicated, you have to know what the new page is before you can unload the old page, which is too hard to do right 15:45:22 Dingwei has joined #css 15:45:24 noamr: Second option was controller based 15:45:32 noamr: To decide based on what link was clicked 15:45:50 noamr: Too limiting, sometimes you click the back button. Sometimes you want a transition from a `location.href` mutation 15:45:56 noamr: So clicking is too limiting 15:46:01 noamr: All we ahve left is URLs 15:46:11 noamr: They're the one thing we're guaranteed to have in cross-document navigation 15:46:27 noamr: So we qualify these by URLs, it's the only thing we can do as far as we can tell. 15:46:46 noamr: Reason why we put same-origin there by default is we dno't support cross-origin or same-site yet, for various reasons. 15:47:04 noamr: We wanted, for the reader, for it to be clear that this is a same-origin navigation. Later it's expandable to various things like urlpattern 15:47:13 noamr: Or qualifying with back/reload/etc navigation types 15:47:22 noamr: We were asked for what kinds of things we expect to see in the future 15:47:43 noamr: We expect same things that exist in Navigation API. Type, URL, and incoming/outgoing url 15:47:50 noamr: So anything that could go into startViewTransition() could go here 15:48:02 noamr: Names of types go into sVT(), so they go here. Future args also go here. 15:48:30 noamr: If we do anything like mixins it'll reflect here 15:48:41 (Unsure what is meant by "mixins" here but I dont' think it's important) 15:48:51 noamr: We also have something called "navigation" here, pretty general 15:49:09 noamr: We didn't think building into @supports or anything was appropriate 15:49:18 noamr: Also questions about and/or here 15:49:25 noamr: Okay to not resolve that yet, just general behavior. 15:50:18 noamr: If our vision of declarative nav transitions makes sense, even if we don't resolve on details now, just want to validate that the syntax is extendable in this way 15:50:18 astearns: Just as a scoping thing, I think it's great to look at future extensions of the syntax, so thanks for htat 15:50:26 astearns: All you're asking for resolution on for now is @navigation with those descriptors, and only same-origin? 15:50:43 noamr: Just the same-origin descriptor, and the vt class names that we just resolved on 15:50:54 noamr: For more behavior, we'll wait to resolve those generally 15:51:10 q+ 15:51:14 ack fantasai 15:51:28 fantasai: I think we do need to have a good sense of the whole package and decide this looks good in general 15:51:50 q+ 15:51:59 fantasai: Just don't want us to decide on something, ship it, and then it looks awkward or doesn't actually expand as we needed. 15:52:09 fantasai: So just want to make sure this is what we want to do 15:52:22 fantasai: I have concerns with urlpatterns. Generally we're opaque to what url you actually are. 15:52:31 fantasai: Some features where we're breaking that 15:52:45 fantasai: But for something like this, you need full regex to capture these 15:52:47 q+ 15:52:52 fantasai: Like for a blog, recognizing a date in the url, etc 15:52:59 URL patterns contain regular expressions 15:53:00 fantasai: And that won't work for websites with random ids 15:53:20 fantasai: I understand th eproblems with pages defining their own classes; I don't have a great answer 15:53:28 astearns: Noam's response is that urlpatterns do contain regexes 15:54:00 TabAtkins: URL patterns are being developed elsewhere for a lot of other use cases, we just need a subet 15:54:04 TabAtkins: I think it's fine 15:54:20 TabAtkins: While I also agree it's probably a bit awkward, it seems like the best way forward afaict 15:54:34 astearns: And whether or not that's correct, I think we can shoehorn *something* that does this matching between URLs into this at-rule later 15:54:38 andreubotella has joined #css 15:54:49 TabAtkins: current extensability plan in the comment seems reasonable 15:54:57 ack eeeps 15:55:11 eeeps: Is there time to wait for *anything* from the second doc? Like an http header, or an early ? 15:55:19 eeeps: Or is there just no way to keep the outgoing doc alive 15:55:37 noamr: We can keep it alive for a bit, and this can be a future extension to the rendering model 15:55:57 noamr: But we don't want to rely on it for how transitions are defined. It's kinda an advanced, complicated addition to the web platform. 15:56:04 noamr: It's like prerendering but more 15:56:19 noamr: So actually quite complicated to do right and cross-browser 15:56:29 noamr: So don't want to rely on it for now. Can be a future UX enhancement. 15:56:50 eeeps: So the incoming URL really is the only thing you can rely on from the incoming page, so far 15:56:52 noamr: correct 15:57:02 astearns: And this can be a future discussion since we're not resolving on that bit today 15:57:04 ack zcorpan 15:57:11 zcorpan: syntax q about urlpattern 15:57:27 zcorpan: I think it's a string? URLs can conflict with CSS syntax. 15:57:49 q+ 15:57:57 TabAtkins: absolutely. Never want to repeat the unqouted URL mistake again 15:57:58 TabAtkins: Oh yeah we're never repeating the "unquoted urls" problem again, I didn't notice that. 15:58:07 ack noamr 15:58:10 ack fantasai 15:58:10 fantasai, you wanted to comment on the classifying links idea 15:58:27 fantasai: you mentioned the idea of changing the transition based on which link you clicked. that sounds like something people might want 15:58:40 fantasai: would be something to consider, i guess would override this general routing 15:59:09 fantasai: Also, I think it would be more udnerstandable if this wasn't named generically "@navigation". Would be clearer what it's for, wouldn't have to repeat "view-transition" in each thing. 15:59:36 noamr: Yeah, qualifying a transition by the "controller" (link clicked) is osmething we lik ein general, it's just a different feature 15:59:38 and more clearly a separate namespace as e.g. 'view-transition-name' 15:59:49 noamr: So you can cusotmize by URL and by "last-active" link (Bramus' term) 15:59:57 noamr: I think those can be taken separately without conflict, we're on the sam epage 16:00:10 noamr: Reason I wanted to call it @navigation, two reasons but not integral 16:00:33 noamr: First it's a qualified navigation, not a qualified VT. Sounds wierd to say "same origin view transition" 16:00:44 noamr: Also sounds a bit funky to have "view transtion between these url patterns" 16:01:18 noamr: Also we envision this being general navigation customization later. If you want to hold the page for a little bit while loading the new one, that's a generic feautre, not VT-specific. 16:01:32 noamr: Also if we want to disallow UA transitions, this is a good way to do it. 16:01:41 noamr: Like swipe UI 16:01:50 noamr: So that's why we think a generic name is better 16:01:58 ack khush 16:01:59 noamr: But we're also okay with saying "don't try to solve those future cases yet" 16:02:00 I think disabling UA transitions fits fine into an @view-transitions or @page-transitions rule 16:02:13 khush: Right now you say "same-origin" 16:02:32 khush: If you later have urls, "same-origin" is the same as a very general URL 16:02:35 I kind of like @page-transitions 16:02:44 q+ 16:02:58 khush: I think I convinced mysefl against this, never mind 16:03:02 I kind of do too, except now I'm wondering if that might conflict with paged media page turn transitions :) 16:03:10 if we ever go there 16:03:24 khush: Also, the old document can be held, until you have a response header that says the navigation will be successful 16:03:29 could do @nav-transition 16:03:37 khush: that's the extent of info we have for now that we can provide to the old document 16:03:38 (we already abbreviation navigation to nav in the nav-properties) 16:03:46 I don't like @page-transition because it sounds like it's related to @page 16:03:54 ack noamr 16:03:54 agree, zcorpan 16:04:04 noamr: Some name bikesheds in IRC 16:04:24 noamr: Suggestion was "@page-transition", we have a "pageTransition" event in JS that is exactly this sort of thing. 16:04:39 noamr: But elika mentioned something about wanting to do a paged-media transition at some point, I'm not sure I udnerstand that. 16:04:58 zcorpan: Yeah but the existing @page is what clashes 16:04:58 we already have named pages in pagd media, so actually defining classes of transitions would be pretty straightforward... 16:05:05 astearns: REason to not use @view-transition? 16:05:22 noamr: Just think this is qualifying the navigation, not the view-transition. 16:05:47 zcorpan: You can do a view-transition without a nav, but this only does navigation VTs. So just "@view-transition" seems incorrect 16:05:49 that makes sense 16:06:05 miriam: Is there a chance in the future that all VTs could be controlled here? 16:06:29 noamr: For @auto-view-transition, I think it could maybe be trigger by the Navigation API automatially 16:06:32 @auto-view-transition-on-navigation 16:07:29 noamr: One thing is we can call it @view-transition or @auto-view-transition, and then call the descriptor `trigger`, with values "navigation" or "none" 16:08:10 astearns: I think we have objections to @navigation, and anything with @page-* 16:08:26 astearns: We have @view-transitions or @auto-view-transitions 16:08:28 astearns: Other options? 16:08:31 khush: Why the "auto"? 16:08:37 q+ 16:08:53 ack bramus 16:08:54 noamr: To make it clear this doesn't control VTs in general, specifically only those that are auto-created by the UA. 16:09:13 bramus: At the previous f2f I floated @config, it's super generic and could maybe apply here. 16:09:33 @view-transition { trigger: navigation; ... } seems ok 16:09:49 +1 16:09:50 TabAtkins: One of the objections to @navigation was it was too generic, so going even more generic seems unlikely to work 16:10:07 @view-transition same-origin { trigger: navigation; ... } 16:10:19 @view-transition { trigger: navigation } 16:10:26 @view-transition same-origin { trigger: navigation } 16:11:10 if it's not triggered by navigation, does same-origin still make sense? 16:11:10 noamr: Another thing we put to the side is we want this rule to be nestable in MQ 16:11:10 the other keyword trigger takes is "none". 16:11:10 TabAtkins: The moment a navigation happens is when you figure out when it happens 16:11:14 TabAtkins: having it be conditional on MQ makes sense 16:11:33 astearns: I think that's neough bikeshedding for today. Suggest we resovle on Noam's proposal in IRC, we can bikeshed later. 16:11:48 astearns: Any objection to `@view-transition same-origin { trigger: navigation | none; }` 16:12:02 RESOLVED: Accept the final syntax proposal. 16:12:44 fantasai: Wondering if the prelude and trigger should swap places. Unsure what `trigger: none` would do. 16:12:58 astearns: In interest of time, I suggest opening an issue for that. 16:13:03 none would do nothing 16:13:22 github-bot, take up https://github.com/w3c/csswg-drafts/issues/9155 16:13:22 Topic: [css-view-transitions-2] Abort transition if the navigation takes too long 16:13:22 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/9155. 16:13:32 khush: This came up during TAG review 16:13:51 khush: If you click the link, and it spins for 5s, do you really want a transition or do you just want to display the page directly? 16:13:59 khush: Interesting question. 16:14:27 khush: Proposal is, when you initiate nav the browser starts timing. If the render time crosses a threshold, browser SHOULD consider aborting the transition. 16:14:36 khush: So how specific should we be in the normative text of the spec? 16:14:58 q+ 16:15:04 khush: We ahve some text about browser-provided transitions being skipped, but doesn't say in what conditions the browser should provide that or skip non-browser transitions 16:15:13 romain_ has joined #css 16:15:23 khush: Should we just say "browser MAY" and then informatively list some exapmles? 16:15:28 yes 16:15:39 khush: So first resolution is to cancel transition if it's taking too long 16:15:44 ack zcorpan 16:15:58 zcorpan: I think you should normatively say "UA MAY skip the VT for any reason" and then ahve examples 16:16:14 zcorpan: I don't think we should try to foresee all possible reasons for canceling 16:16:22 +1 16:16:28 khush: I'm happy with that 16:16:54 astearns: Do we need a MUST for delay? 16:17:17 TabAtkins: I think like font timeouts it's fine as a quality-of-implementation issue 16:17:27 astearns: So resolution is "may skip for any reason", with a list of examples. 16:18:00 RESOLVED: Specify that UAs MAY skip a VT for any reason, give an informative list of examples where they might do so (taking too long, etc) 16:18:11 github-bot, take up https://github.com/w3c/csswg-drafts/issues/9276 16:18:12 Topic: [css-view-transitions-1] Using plus-darker if prefers-color-scheme: dark 16:18:12 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/9276. 16:18:33 vmpstr: In VT spec we use the plus-lighter blending mode to combine the old and new snapshots 16:18:52 vmpstr: This basically ensures that if the images are the same they'll look the same as you crossfade opacity 16:19:03 vmpstr: If they're not the same, they'll tend to be somewhat lighter than the source images 16:19:17 vmpstr: That looks fine in light mode, but in dark mode they can end up a lot brighter than expected 16:19:35 https://github.com/w3c/fxtf-drafts/issues/447#issuecomment-1699293766 16:19:36 vmpstr: So we propose using the MQ in the issue - if the color scheme pref is dark, use plus-darker instead 16:19:50 vmpstr: dbaron has put an issue in the chat about changing the formula for plus-darker 16:20:11 vmpstr: This MQ for preferring dark doesn't need to be repsected by the site, so it might make things dark on a light page 16:20:28 vmpstr: I think that's fine, the user prefers that the page look darker and we're making the transition image darker. 16:20:29 q+ 16:20:37 vmpstr: But in general I don't think we can detect what the page is doing 16:20:40 q+ 16:20:44 ack emilio 16:20:53 emilio: You can kinda detect what the page is doing if you look at the used color-scheme property, right? 16:20:59 +1 16:21:03 +1 16:21:18 emilio: All pages that respect prefers-color-scheme might not use the or set color-scheme on the root, but I hope most do 16:21:35 q+ 16:21:36 astearns: So if the MQ and the color-scheme are dark? 16:21:49 emilio: You can set the used color-scheme to be different from the prefers color-scheme 16:22:00 emilio: But the color-scheme already takes the preference into account 16:22:00 ack fremy 16:22:15 fremy: I think this could also be done per element 16:22:40 fremy: If you have part of your site that's light theme, might want to use plus-lighter on that element while plus-darker on the dark rest of the page 16:22:48 fremy: So I think using color-scheme is the better way, per element 16:23:00 fremy: It ensures authors are using color-scheme, and it gives them control over what it applies to 16:23:02 ack khush 16:23:32 khush: Want to echo point from Vlad, even if page isn't respecting user's color scheme it still makes sense to use plus-darker bc it's what the author is preferring 16:24:02 khush: So even if the page didn't respect color-scheme we'd respect the author pref 16:24:21 khush: So maybe it should be an OR - if user pref is dark, *or* the element's color-scheme is dark, use plusdarker 16:24:35 fremy: Unsure if that's good, if authors can't control... 16:24:43 vmpstr: Authors can control which blending mode to use, this is just the default 16:24:57 s/can control/can control with the pseudos/ 16:25:26 fremy: Probably also depend son how strong a difference the visual change is 16:25:36 fremy: If it's a subtle difference it doesn't matter as much vs being very visible 16:26:24 astearns: One option is to punt for now, since plus-darker isn't interoperable and we need people to use VT to see if it makes a huge diff with color-scheme anyway. We can also see if authors are overriding default just for color-scheme. 16:26:28 astearns: So maybe we wait and find out 16:26:42 q+ 16:26:42 vmpstr: I think I'd prefer to at least respect the color-scheme for now 16:27:08 vmpstr: I think i've reconsidered using the MQ. color-scheme seems like a strong signal that the page is indeed using a dark color scheme 16:27:13 vmpstr: So using that as the default makes sense, I think 16:27:17 ack eeeps 16:27:37 eeeps: So to udnerstand the problem, in theory if you could interpolate the pixel values you wouldn't need to look at color scheme? 16:28:09 vmpstr: Issue is in order to cross-fade, if they're the same image you don't want it to look different. So you need a blending mode that's one of the pluses 16:28:19 vmpstr: So plus-lighter is one of these, but it tends to lean lighter. 16:28:34 ack dbaron 16:29:00 dbaron: This is probably the sort of somewhat-subtle thing where even if devs see it and think it looks a little funny, they're not necessarily gonna know how to fix it 16:29:05 dbaron: So I'm a little skeptical of the "wait and see" suggestion. 16:29:14 dbaron: Think even if they don't do it a lot it's not a strong signal against. 16:29:17 ack fantasai 16:30:10 fantasai: I think we should do this based only on color-scheme not on MQ. 16:30:10 fantasai: And on the color-scheme of the element originating the VT, consistently for the entire tree. 16:30:10 q+ 16:30:10 fantasai: So I propose we add a new keyword to blending mode that does this 16:30:15 s/keyword/keyword (plus-auto)/ 16:30:28 TabAtkins: I disagree that we should do it on the element originating the transition 16:30:28 +1 16:30:43 ... as a benefit this could be implemented just with the light-dark() function we resolved a bit ago 16:30:56 khush: what's that? 16:31:24 TabAtkins: light-dark() returns one of two values if either is light or dark 16:31:27 fantasai: that's a color 16:31:33 TabAtkins: sure, light-dark-value() :) 16:32:32 khush: So say I have a funciton that picks one of these two values, what element does it come from? 16:32:52 khush: Here it would come from th epseudo-element, which inherits from the originating element. 16:33:11 mmmm that's not right at all 16:33:11 khush: But we can copy the color-scheme from the transitioning element to the pseudo and get it work correctly 16:33:12 that's correct 16:33:55 astearns: So proposed resolution is we copy the element's color-scheme to its ::view-transition-group 16:34:10 fremy: What happens if the initial page was light mode and next is dark mode? 16:34:14 s/color-scheme/used color-scheme value/ 16:34:19 khush: It takes the latest value, we ahve that with a lot of values already 16:34:30 astearns: objections? 16:34:55 RESOLVED: Copy the element's used color-scheme value to its ::view-transition-group 16:35:13 vmpstr: We also need to use this color-scheme to set the blend mode 16:35:26 mix-blend-mode: light-dark(plus-lighter, plus-darker) 16:35:35 s/light-dark/light-dark-value/ 16:36:15 PROPOSED: mix-blend-mode on ::view-transition-group takes light-dark-value(plus-lighter, plus-darker) 16:37:17 proposed: ::view-transition-group uses plus-lighter or plus-darker, based on the color-scheme 16:37:24 (mechanism TBD) 16:37:48 RESOLVED: ::view-transition-group uses plus-lighter or plus-darker, based on the color-scheme (mechanism TBD) 16:37:51 github-bot, end topic 16:55:44 myles has joined #css 17:02:01 futhark has left #css 17:05:58 myles has joined #css 18:12:24 Ian has joined #css 18:12:26 Ian has left #css 19:02:30 jfkthame has joined #css 20:10:20 jfkthame has joined #css 20:50:42 jfkthame_ has joined #css 21:45:21 jfkthame_ has joined #css 23:20:23 jfkthame_ has joined #css