IRC log of css on 2025-08-21
Timestamps are in UTC.
- 07:19:34 [RRSAgent]
- RRSAgent has joined #css
- 07:19:38 [RRSAgent]
- logging to https://www.w3.org/2025/08/21-css-irc
- 07:19:38 [TabAtkins]
- fantasai: some constraints. a circle shoudl shadow a circle, a square shoudl shadow a square
- 07:19:38 [Zakim]
- RRSAgent, make logs Public
- 07:19:39 [Zakim]
- Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
- 07:19:42 [TabAtkins]
- fantasai: and third, there's continuity between the two
- 07:19:48 [TabAtkins]
- fantasai: after that it's just, what looks good
- 07:19:49 [fantasai]
- https://people.igalia.com/obrufau/testcases/shadow-radius/
- 07:19:54 [TabAtkins]
- fantasai: oriol made a pile of test cases
- 07:20:08 [TabAtkins]
- fantasai: as long as your new formula looks at least as good as what else we've tried, i'm happy to change the spec
- 07:20:22 [TabAtkins]
- fantasai: but yeah, a box with sligihtly rounded corners should continue to look like slightly rounded
- 07:20:40 [TabAtkins]
- fantasai: so my suggestion is to take the test case page, add your formula to it, and if it looks good we can resolve on it
- 07:20:57 [TabAtkins]
- astearns: you opened with "no reasoning beyond it looks good" and that is indeed why we resolve don the current
- 07:21:10 [TabAtkins]
- astearns: so applying your algo and comparing to the testcase page is probably the way to go
- 07:21:16 [TabAtkins]
- noamr: okay, that explains the reasoning
- 07:21:25 [TabAtkins]
- astearns: it took us a while to get to this, and if you ahve a better algo, i'm all for it
- 07:21:39 [TabAtkins]
- noamr: yeah, i think i do, and it also looks good with the various corner shape
- 07:21:51 [fantasai]
- scribe+
- 07:22:20 [fantasai]
- noamr: I have some good tests for weird shapes internally
- 07:22:36 [oriol]
- q+
- 07:22:39 [oriol]
- q+
- 07:22:45 [astearns]
- ack oriol
- 07:23:10 [fantasai]
- fantasai_: It's fine as long as squares are squares and circles are circles and in between is in between in a nice-looking way
- 07:23:12 [oriol]
- <div style="width: 200px; height: 40px; background: cyan; border-radius: 100px / 20px; box-shadow: 0 0 0 50px blue; margin: 80px; corner-shape: superellipse(0.99999)"></div>
- 07:23:26 [fantasai]
- oriol: Here's a testcase, I'm testing in Canary
- 07:23:41 [fantasai]
- oriol: I would expect the shadow and top/bottom be (?) so I don't think I understand what you are proposing
- 07:24:18 [fantasai]
- fantasai: Send a patch to Oriol so we can look at the testcases
- 07:24:26 [fantasai]
- fantasai: Then we can look into it
- 07:25:03 [fantasai]
- Topic: Selectors
- 07:25:07 [github-bot]
- Subtopic: [css-selectors-4] CSS reflection of HTML parsing state
- 07:25:40 [TabAtkins]
- noamr: this is part of making navigation smoother and more declarative, rather than with manual JS
- 07:25:49 [TabAtkins]
- noamr: specifically, streaming navigation and same-doc navigation
- 07:26:01 [TabAtkins]
- noamr: part of that is desire to expose better states of the parser
- 07:26:11 [TabAtkins]
- noamr: in this case, it's about elements that are opened but not yet done parsing
- 07:26:29 [TabAtkins]
- noamr: while you're streaming html, you might open an <article> with a lot of text, it's starting to display but there's still content streaming in
- 07:26:44 [TabAtkins]
- noamr: some issues in the past with wanting an element to only appear when it's done, or have some indication
- 07:26:54 [TabAtkins]
- noamr: this is a very specific thing in the html parser spec
- 07:27:10 [emilio]
- q+
- 07:27:13 [TabAtkins]
- noamr: so the idea's pretty simple, a pseudo-class for whether an element is still open
- 07:27:22 [astearns]
- ack fantasai
- 07:27:22 [Zakim]
- fantasai, you wanted to ask if this should be distict from whether stuff is loaded
- 07:27:31 [TabAtkins]
- fantasai: are the use-cases different from those for querying an elemetn is loaded?
- 07:27:35 [TabAtkins]
- noamr: like an image?
- 07:27:35 [kizu]
- kizu has joined #css
- 07:27:42 [TabAtkins]
- fantasai: any element, you want parsed and all its resources loaded
- 07:27:50 [TabAtkins]
- fantasai: do you want a query distinct from that? parsed and not yet loaded?
- 07:27:59 [kizu]
- present+
- 07:27:59 [TabAtkins]
- noamr: a lot of things can be parsed and dont' have laoded resources
- 07:28:05 [TabAtkins]
- fantasai: yeah, those'll be done loading immediately
- 07:28:12 [ChrisL]
- present+
- 07:28:12 [TabAtkins]
- fantasai: but for something that has loaded stuff, do you need to distinguish?
- 07:28:29 [TabAtkins]
- noamr: unsure. it's a level of granularity down. don't mind starting from something a little more general like :loaded
- 07:28:34 [TabAtkins]
- noamr: and then taking it down if needed
- 07:28:52 [TabAtkins]
- noamr: if you think aobut containers, or things parsed in a chunked way, often the sub resources arne't loaded, lots of child elements
- 07:29:04 [TabAtkins]
- noamr: does "loaded" mean all the hcildren are loaded?
- 07:29:11 [TabAtkins]
- fantasai: is that what you want?
- 07:29:24 [TabAtkins]
- fantasai: specifically, what's the use-case you're trying to solve
- 07:29:31 [lea]
- present+
- 07:29:40 [TabAtkins]
- noamr: people want to control their progressive loading experience better. articles coming in, but don't want it to show while it's mid-loading
- 07:29:52 [TabAtkins]
- noamr: want to either indicate it's loading, or make it invisible until it's loaded
- 07:30:12 [TabAtkins]
- astearns: looking thru web components issue, i don't see any discussion about the current :loaded trigger we have
- 07:30:25 [TabAtkins]
- astearns: i think it woudl be good to see if our existing :loaded selector woudl be sufficient
- 07:30:54 [TabAtkins]
- fantasai: so q is, rather than using a new selector, is it good to reuse the existing selector?
- 07:31:03 [TabAtkins]
- fantasai: if you haven't thought about this yet, coudl be worth thinking about
- 07:31:11 [TabAtkins]
- fantasai: so do users *want* to distinguish between parsed and loaded?
- 07:31:13 [astearns]
- ack emilio
- 07:31:34 [TabAtkins]
- emilio: to impl this, you need add a [??] notification that elements have loaded, which some elements alreayd have
- 07:31:42 [ydaniv]
- this one is somewhat related, https://github.com/w3c/csswg-drafts/issues/8175
- 07:31:49 [TabAtkins]
- emilio: when previously discussed, i think there were perf constraints with doing this for all elements
- 07:32:18 [TabAtkins]
- emilio: there's a similar thing with... like having this pseudo-class - presumably if element is empty this'll never apply, only while getting chidlren
- 07:32:27 [TabAtkins]
- emilio: i'm a bit concerned about the number of style changes it adds to page loads
- 07:32:28 [TabAtkins]
- q+
- 07:32:40 [TabAtkins]
- emilio: like :has(:loading) suddenly invalidates constantly
- 07:32:54 [fantasai]
- s/loading/parsing/
- 07:33:01 [TabAtkins]
- emilio: my udnerstanding is in the past, blink folks objected to the more general idea here
- 07:33:03 [TabAtkins]
- emilio: in the html discussions
- 07:33:13 [TabAtkins]
- noamr: that was a JS thing, this is a style thing
- 07:33:28 [TabAtkins]
- emilio: at least for us, the "children are done" thing is an extra operation the parser send to the dom
- 07:33:36 [TabAtkins]
- emilio: i think rn we only use that for select and textarea, maybe two or three more
- 07:33:54 [TabAtkins]
- noamr: from chromium perspective, we do that- it's expensive, but we can do it based on existing selectors
- 07:34:05 [TabAtkins]
- emilio: there could be a stylesheet loading in flight, don't think you can do it conditionally
- 07:34:21 [TabAtkins]
- emilio: just saying, this has been dsicussed in the past. doesn't necessarily block, but would be good to have more feedback
- 07:34:31 [TabAtkins]
- emilio: but my udnerstanding is our parser folks wouldn't be very happy with this
- 07:34:43 [TabAtkins]
- noamr: i'll check, i have more parser knowledge than i did a year ago, not too concerned
- 07:34:53 [matthieud]
- matthieud has joined #css
- 07:34:55 [TabAtkins]
- noamr: when we added blocking for link rel=expect, similar thing
- 07:34:59 [TabAtkins]
- emilio: yeah, that's conditional tho
- 07:34:59 [andreubotella]
- andreubotella has joined #css
- 07:35:12 [TabAtkins]
- emilio: something that might be interesting is restricting this to elements the page cares about
- 07:35:28 [TabAtkins]
- emilio: so that might be good to investigate. you usually care about just one or two elements, not all sub-children
- 07:35:31 [TabAtkins]
- emilio: just like a main article
- 07:35:43 [TabAtkins]
- emilio: would be good to get some hint from the page about what elemens i care about
- 07:35:46 [astearns]
- ack TabAtkins
- 07:35:54 [emilio]
- TabAtkins: was going to suggest exactly that
- 07:36:03 [emilio]
- ... it's not a state we care about for ~all elements
- 07:36:09 [emilio]
- ... so maybe we can opt in at the markup level
- 07:36:34 [emilio]
- ... with an attribute or so, which would opt into the pseudo class
- 07:36:44 [emilio]
- ... that'd make me happier with reusing :loading/:loading
- 07:36:58 [emilio]
- ... usually that's a thing that applies more to images / videos
- 07:37:11 [emilio]
- ... but if it's just a handful of articles you have marked or so it seems fine
- 07:37:32 [TabAtkins]
- github-bot, take up https://github.com/w3c/csswg-drafts/issues/12579
- 07:37:32 [github-bot]
- Topic: [css-selectors-4] CSS reflection of "patching"
- 07:37:32 [github-bot]
- OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12579.
- 07:38:04 [noamr]
- noamr has joined #css
- 07:38:17 [TabAtkins]
- noamr: anothe rintro topic
- 07:38:26 [TabAtkins]
- noamr: working with the whatwg on a new ability we're calling "patching"
- 07:38:35 [TabAtkins]
- noamr: letting you stream content into an element while or after it's loaded
- 07:38:48 [TabAtkins]
- noamr: letting you pull in some html and direct it into an element. in JS or declaratively
- 07:39:04 [TabAtkins]
- noamr: like HTML with a <select> on top, the content is loaded dynamically
- 07:39:11 [TabAtkins]
- noamr: the options can load in later via a <template>
- 07:39:22 [TabAtkins]
- noamr: or a <script> it's bing discussed
- 07:39:34 [TabAtkins]
- noamr: and some indicator that the contents go into an existing element, via an ID or something
- 07:39:41 [astearns]
- q+
- 07:39:50 [TabAtkins]
- noamr: people obvs do this in JS a lot today, React server-side rendering
- 07:40:00 [TabAtkins]
- noamr: we also want to reflect this in style, React has a spinner
- 07:40:09 [TabAtkins]
- noamr: parts that will load later on, you want to indicate in rendering somehow
- 07:40:23 [TabAtkins]
- noamr: so this is opted in, a patchable element will have a special attribute
- 07:40:33 [TabAtkins]
- noamr: and when something is patching it's clear, not all the elements on the page
- 07:40:50 [TabAtkins]
- noamr: so the use-case style-wise is a loading indicator
- 07:41:03 [TabAtkins]
- noamr: graying out an element, enabling a spinner, something like that
- 07:41:17 [TabAtkins]
- noamr: maybe could also tie into loading/loaded
- 07:41:30 [TabAtkins]
- noamr: not wanting to reoslve, just talking about ti
- 07:41:34 [TabAtkins]
- astearns: have some questions
- 07:41:41 [TabAtkins]
- astearns: your example has bare text for the laoding state
- 07:41:53 [TabAtkins]
- astearns: that i assume that text will be styled, or can have elements that will be repalced
- 07:42:02 [TabAtkins]
- astearns: so you alraedy have a way of styling osme loading indicators
- 07:42:31 [TabAtkins]
- astearns: so if we already have a way of - the template's not applied yet. what's the use-case for distinguishing between "tempalte's not applied" and "template has been applied but still loading"
- 07:42:39 [astearns]
- ack astearns
- 07:42:46 [TabAtkins]
- noamr: i'd say similar to indicating any timeline in the start or middle. pending, loading, or done
- 07:43:19 [TabAtkins]
- astearns: I'd like to see some more fleshed-out examples of what someone might want to do from style for these pending and patching states
- 07:43:25 [TabAtkins]
- astearns: not against it, just not sure it's completely motivated
- 07:43:36 [TabAtkins]
- emilio: for imperative patching, "pending" doesn't exist, yeah?
- 07:43:38 [TabAtkins]
- noamr: right
- 07:43:49 [TabAtkins]
- emilio: is there a use for distinguishing between pending and patching?
- 07:43:59 [TabAtkins]
- noamr: just more convenience, can check if you have a loading indicator
- 07:44:05 [TabAtkins]
- emilio: not sure i udnerstand
- 07:44:23 [TabAtkins]
- emilio: just not sure when you'd want to dsitinguish between "patch not applied" and "patch has just begun applying"
- 07:44:44 [TabAtkins]
- noamr: before it's applied, you want to show the placeholder content; different thatn partially streamed content
- 07:44:55 [TabAtkins]
- emilio: okay, would like to see what author use-cases would benefit
- 07:45:13 [TabAtkins]
- noamr: it's not novel here, frameworks do it. Suspense library exposes this
- 07:45:39 [TabAtkins]
- astearns: i could see some better skeleton loading, where as things are pending you get a skeleton, as they patch in some skeleton remains while it happens...
- 07:45:56 [TabAtkins]
- noamr: i can make more demos
- 07:46:07 [TabAtkins]
- astearns: and some motivation for why it's in css, rather than just relying on js
- 07:46:41 [ydaniv]
- q+
- 07:46:45 [TabAtkins]
- TabAtkins: part of the feature is a declarative version, where you leave open your html response and later drop in a <template>. no js involved at all
- 07:47:21 [TabAtkins]
- noamr: for perf reasons and bug reasons, the direction is to keep things as declarative as possible
- 07:47:32 [TabAtkins]
- noamr: similar to event triggers, good to know ahead of time that an event will trigger something
- 07:47:32 [astearns]
- ack ydaniv
- 07:47:51 [TabAtkins]
- ydaniv: i wanna stress what noam is trying to do and giv emore emphasis to this need
- 07:48:01 [TabAtkins]
- ydaniv: the web looks now like ti's very flakey, comapred to native apps
- 07:48:13 [TabAtkins]
- ydaniv: when people try to build apps that load in async and want it robust
- 07:48:44 [TabAtkins]
- ydaniv: so the time we're talking about is before JS ran, the initial server response is important to get right and look right
- 07:49:14 [fantasai]
- Topic: shapes
- 07:49:22 [TabAtkins]
- github-bot, take up https://github.com/w3c/csswg-drafts/issues/11623
- 07:49:22 [github-bot]
- Topic: [css-borders-4] corner-shape initial value ("round") is strange in some cases (e.g. bevel)
- 07:49:22 [github-bot]
- OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11623.
- 07:50:05 [fantasai]
- s/Topic: [css-selectors-4]/Subtopic: [css-selectors-4]/
- 07:50:07 [TabAtkins]
- noamr: this was originally aobut confusion with "round" being initial value for corner shapes
- 07:50:21 [TabAtkins]
- noamr: but we resolved on that. the resolution led us to have a shorthand that includes both border-radius and corner-shape
- 07:50:36 [TabAtkins]
- noamr: which is supposedly more coherent to read, becuase it doesn't default to round
- 07:50:46 [TabAtkins]
- noamr: you specify the corner shape, then the radiuses
- 07:51:01 [noamr]
- https://github.com/web-platform-tests/wpt/blob/9a533af8ca6f850effb6df5d6ce7bfaacecb971d/css/css-borders/corner-shape/corners-valid.html
- 07:51:04 [TabAtkins]
- noamr: i impld behind a flag in chrome
- 07:51:23 [TabAtkins]
- noamr: there were a couple things to reoslve on. do we like this?
- 07:51:35 [TabAtkins]
- noamr: and whether it should be 'corner' or 'corners'
- 07:52:04 [TabAtkins]
- noamr: so the syntax is, you always need a shape and one or two radiuses
- 07:52:18 [TabAtkins]
- noamr: you can have 1-4 repetitions, slash-separated
- 07:52:29 [TabAtkins]
- noamr: standard corner copying rule
- 07:52:49 [TabAtkins]
- normal means radius 0
- 07:53:12 [moonira]
- moonira has joined #css
- 07:53:24 [lea]
- q?
- 07:53:26 [lea]
- q+
- 07:53:53 [SebastianZ]
- +1 on the suggested syntax
- 07:53:56 [astearns]
- ack lea
- 07:54:08 [kbabbitt]
- q+
- 07:54:09 [TabAtkins]
- lea: why do we need a shorthand that sets everything? why is that desirable? why not us e the longhand in this case?
- 07:54:13 [SebastianZ]
- q+
- 07:54:32 [TabAtkins]
- lea: these can get confusing to read, like border-radius with all of its values. like border shorthands can't do different borders on each side
- 07:54:40 [TabAtkins]
- lea: you use longhands if you try to do everything
- 07:54:54 [TabAtkins]
- lea: shorthands that try to do everything get confusing, even people here probably make mistakes
- 07:55:17 [fantasai]
- border-radius: <length-percentage [0,∞]>{1,4} [ / <length-percentage [0,∞]>{1,4} ]?
- 07:55:53 [TabAtkins]
- TabAtkins: I'm not sure I udnerstand what's confusing here...
- 07:56:03 [astearns]
- https://github.com/web-platform-tests/wpt/blob/9a533af8ca6f850effb6df5d6ce7bfaacecb971d/css/css-borders/corner-shape/corners-valid.html
- 07:56:34 [TabAtkins]
- lea: like, line 15, do we want to encourage this?
- 07:56:47 [noamr]
- notch 10px / squircle 30% 10px / 1rem bevel / 2px round
- 07:56:54 [lea]
- notch 10px / squircle 30% 10px / 1rem bevel / 2px round", "10px notch / 30% 10px squircle / 1rem bevel / 2px round
- 07:56:55 [astearns]
- ack fantasai
- 07:57:04 [lea]
- corners: normal / superellipse(-0.5) 30% 10px / 10px 1rem notch", "normal / 30% 10px superellipse(-0.5) / 10px 1rem notch;
- 07:57:10 [TabAtkins]
- fantasai: i pasted the border-radius syntax into IRC. want to emphasize that this pattern is inconsistent with that one
- 07:57:26 [astearns]
- lea note that there are two string values from the lines you pasted
- 07:57:29 [TabAtkins]
- fantasai: border-radius takes the values for every corner in sequence, 1-4, then the slash doesn't separate the sides, but to seaprate x/y coords.
- 07:57:40 [lea]
- q+
- 07:57:43 [TabAtkins]
- fantasai: that allows you to specify one value and have it repeated up to 4 times, and can do it independently in x/y
- 07:58:00 [TabAtkins]
- fantasai: if we follow that pattern in the corners shorthand, the corner-shape values woudlnt' be split up by slashes
- 07:58:03 [SebastianZ]
- reverting my +1 :)
- 07:58:09 [TabAtkins]
- fantasai: slash only disambiguates x/y in border-radius
- 07:58:25 [TabAtkins]
- fantasai: most time, people just want to say the shape once and then give the border radiuses
- 07:58:35 [TabAtkins]
- fantasai: not repeat the corner just because radius is changing
- 07:58:47 [TabAtkins]
- fantasai: following the pattern of border-radius would make this easier
- 07:59:12 [fantasai]
- corners: <'corner-shape'> || <'border-radius'>
- 07:59:29 [TabAtkins]
- fantasai: i think that would be pretty straightforward and reduce repetition
- 07:59:46 [TabAtkins]
- noamr: then you can't have different corner shapes
- 07:59:55 [TabAtkins]
- fantasai: you can, corner-shape takes four values
- 08:00:04 [astearns]
- q+
- 08:00:50 [TabAtkins]
- line 15 would be: notch squricle bevel round 10px 30% 10px 1rem 2px / 0 10px 0 0
- 08:01:16 [astearns]
- ack kbabbitt
- 08:01:23 [TabAtkins]
- line 15 would be: notch squricle bevel round 10px 30% 10px 1rem 2px / 10px 10px 1rem 2px
- 08:01:40 [TabAtkins]
- kbabbitt: I think it was mentioned that the shapes were a required part, our usual pattern is that values not specified are inferred as defautls
- 08:01:50 [TabAtkins]
- kbabbitt: i think if we take elika's suggestion that's the behavior that would fall out of it
- 08:02:00 [TabAtkins]
- noamr: that wouldn't fix the issue this was posted for, then
- 08:02:07 [TabAtkins]
- noamr: the issue is that people were confused "round" is the default
- 08:02:17 [florian]
- q?
- 08:02:22 [florian]
- q+
- 08:02:25 [TabAtkins]
- noamr: with a round default, people would still be confused
- 08:02:38 [TabAtkins]
- kbabbitt: so it's justa bout requiring explicitness to avoid confusion?
- 08:02:45 [TabAtkins]
- noamr: that, plus ergonomics for putting them together
- 08:02:50 [astearns]
- ack SebastianZ
- 08:03:07 [TabAtkins]
- SebastianZ: elika's syntax is what jskuhn suggested
- 08:03:25 [TabAtkins]
- SebastianZ: would we really want to just let the shape be defined there? or should we alway srequire radius as well
- 08:03:35 [TabAtkins]
- noamr: if radius goes to zero the shape doesn't do anything
- 08:03:44 [TabAtkins]
- fantasai: no, you can make them both optional, it's fine
- 08:03:58 [astearns]
- ack lea
- 08:04:06 [TabAtkins]
- fantasai: author can be doing more specific things later, just relying on the reset behavior. i do this with borders a lot. no reason not to make it optional
- 08:04:20 [TabAtkins]
- lea: yeah, fantasai's point about slashes working different is great. we shoudl be consistent
- 08:04:30 [SebastianZ]
- s/jskuhn/jsnkuhn/
- 08:04:31 [TabAtkins]
- lea: that said, i'm not sure expanded border-radius was godo i nthe first place
- 08:04:43 [TabAtkins]
- lea: if someone want to set all corners to same value, we should ahve a propery that does
- 08:05:06 [TabAtkins]
- TabAtkins: you can, `corners: 5px round`
- 08:05:07 [fantasai]
- TabAtkins: you can just say 'corners: round 10px'
- 08:05:17 [TabAtkins]
- lea: i'm not sure we *want* to allow the shorthand to set everything
- 08:05:33 [TabAtkins]
- lea: shorthands are about reduction of knowledge. a microsyntax makes things harder
- 08:05:40 [romain]
- +1
- 08:05:42 [TabAtkins]
- lea: experience shows authors don't use shorthands above a certain level of complexity
- 08:05:47 [SebastianZ]
- q+
- 08:05:53 [TabAtkins]
- lea: I find it's pretty low, too. authors don't even use background shorthand fully.
- 08:05:56 [astearns]
- q-
- 08:06:08 [TabAtkins]
- lea: if we want people to set top-left corner shape together with its size, we can have a property for that
- 08:06:18 [TabAtkins]
- lea: or block-start corners, etc
- 08:06:26 [TabAtkins]
- lea: I dont' think we should stuff everything into a complex shorthand
- 08:06:27 [TabAtkins]
- q+
- 08:06:32 [astearns]
- ack florian
- 08:06:43 [TabAtkins]
- florian: I kinda agree people will mostly use shorthands for simple things
- 08:06:54 [TabAtkins]
- florian: but with border-radius you already have the options, following the pattern is fine
- 08:07:01 [TabAtkins]
- florian: you'll always have the longhands
- 08:07:13 [TabAtkins]
- florian: but we already have a few reasonable syntaxes, and it's consistent with border-radius
- 08:07:22 [TabAtkins]
- florian: not a fan of border-radius, but would like to keep it going.
- 08:07:43 [TabAtkins]
- florian: also, earlier you said people found it confusing the default is round, is that because they didn't realize that with 0 it's square anyway?
- 08:08:07 [TabAtkins]
- noamr: part was just trying to use corner-shape for a bevel, and saying "my corner is round just because I give it a radius"...
- 08:08:45 [TabAtkins]
- noamr: round being the default is more historical than intentional
- 08:09:24 [TabAtkins]
- noamr: it's also slightly more convenient feature-detection wise to set 'corners', can use border-radius by itself for a round version then 'corners' for a better one
- 08:09:43 [fantasai]
- TabAtkins: I don't think we need to justify having a shorthand
- 08:10:10 [TabAtkins]
- SebastianZ: their argument was, when you don't apply border-radius, the shape is square
- 08:10:16 [TabAtkins]
- SebastianZ: so an initial "round" value was confusing
- 08:10:23 [astearns]
- ack fantasai
- 08:10:50 [TabAtkins]
- fantasai: I don't think... there are cases in shorthands where we default to something other than initial value, but only with very good reason, because other values are implying a different value
- 08:11:00 [TabAtkins]
- fantasai: not the case here, if you have radiuses, round is the right thing to default to
- 08:11:17 [TabAtkins]
- fantasai: because if border-radius creates rounded, but 'corners' defaults to bevel, that's confusing
- 08:11:36 [TabAtkins]
- fantasai: the previous shorthand syntax proposal required you to repeat your corner shape on each corner, if you want different radiuses
- 08:11:48 [TabAtkins]
- fantasai: but if we switch to the one that matches border-radisu, you don't have to do that
- 08:12:22 [TabAtkins]
- fantasai: that's why we designed border-radius the way we did
- 08:12:23 [astearns]
- ack SebastianZ
- 08:12:47 [TabAtkins]
- SebastianZ: Lea already brought up a good point. I think in addition to corners, we should have shorthand for the different corners. we have that for corner-shape and border-radius
- 08:13:04 [TabAtkins]
- fantasai: agree
- 08:13:30 [TabAtkins]
- noamr: just another 16 properties (corner + sides * logical)
- 08:13:43 [TabAtkins]
- florian: do we care about the memory cost of all these shorthands?
- 08:13:53 [TabAtkins]
- emilio: long hands matter, shorthands not as much
- 08:14:09 [astearns]
- ack TabAtkins
- 08:14:22 [fantasai]
- TabAtkins: I agree that complicated shorthand sare bad, but this is not a complicated shorthand itself,
- 08:14:31 [fantasai]
- TabAtkins: It just invokes existing shorthands by combining them with ||
- 08:14:37 [fantasai]
- TabAtkins: This is the simplest thing we can do
- 08:14:43 [lea]
- q+
- 08:14:51 [fantasai]
- TabAtkins: Just because longhands are complicated ...
- 08:14:57 [fantasai]
- TabAtkins: Having more limited shorthand is not good
- 08:15:08 [astearns]
- ack lea
- 08:15:16 [fantasai]
- TabAtkins: We only skip the ability to represent values in a shorthand if it's really untenable
- 08:15:20 [noamr]
- noamr has joined #css
- 08:15:27 [SebastianZ]
- q+ on naming the shorthand(s)
- 08:15:28 [TabAtkins]
- lea: it's not a design goal to expose the complexity of all long hands. borders all allow setting individual values per corner
- 08:15:37 [TabAtkins]
- lea: but we don't allow setting everything in the shorthand
- 08:15:57 [fantasai]
- TabAtkins: Agree, but syntax for 'border' shorthand intentionally doesn't put all 4 things together
- 08:16:06 [fantasai]
- lea: What we're doing here is very similar
- 08:16:18 [fantasai]
- lea: If we design 'border' today, we would enable setting all the values
- 08:16:51 [astearns]
- ack fantasai
- 08:17:00 [lea]
- s/lea: If we design 'border' today, we would enable setting all the values/lea: it's as if we were designing `border` today and trying to make it set separate color, width, style values for each side/
- 08:17:05 [TabAtkins]
- fantasai: I agree with Tab
- 08:17:19 [TabAtkins]
- fantasai: if we dont' have a compelling reason to disable the ability to represent all the longhands, we try to make it possible
- 08:17:32 [TabAtkins]
- fantasai: and this is a case where if you want to do the simple things, it is very simple. it's *possible* to do the complex things.
- 08:17:37 [kbabbitt]
- +1
- 08:17:43 [TabAtkins]
- fantasai: it's fine if 90% of the time you just use the simple version, that's what shorthands are for
- 08:17:51 [TabAtkins]
- fantasai: doens't mean we should blocka syntax that allows all the values
- 08:18:11 [fantasai]
- PROPOSED: corners: <'corner-shape'> || <'border-radius'>
- 08:18:13 [TabAtkins]
- astearns: can we resolve to use the new proposed syntax?
- 08:18:43 [TabAtkins]
- astearns: any more discussion about the syntax? if we have the shorthand at all, sounds like this should be the syntax.
- 08:18:45 [florian]
- +1
- 08:18:46 [TabAtkins]
- astearns: objections?
- 08:18:50 [fantasai]
- RESOLVED: corners: <'corner-shape'> || <'border-radius'>
- 08:19:24 [fantasai]
- PROPOSED: Add corners-* shorthands as longhands of corners
- 08:19:26 [TabAtkins]
- astearns: now, should we add shorthands for all the corner variations, to match border-radius
- 08:19:45 [kbabbitt]
- q+
- 08:19:53 [astearns]
- ack kbabbitt
- 08:19:56 [TabAtkins]
- kbabbitt: not an objection, just clarifying request
- 08:20:08 [TabAtkins]
- kbabbitt: sounds like a tuple for each corner
- 08:20:12 [fantasai]
- RESOLVED: Add corners-* shorthands as longhands of corners, parallel to border-*-radius/corner-*-shape
- 08:20:40 [diekus]
- diekus has joined #css
- 08:20:56 [astearns]
- ack SebastianZ
- 08:20:56 [Zakim]
- SebastianZ, you wanted to comment on naming the shorthand(s)
- 08:21:03 [lea]
- q+
- 08:21:04 [TabAtkins]
- SebastianZ: I had a pragmatic reason for renaming to 'corner' rather rthan 'corners'
- 08:21:14 [TabAtkins]
- SebastianZ: tool completion is usually alphabetic
- 08:21:33 [astearns]
- we’re modeling after border-radius, not border-radii…
- 08:21:35 [TabAtkins]
- SebastianZ: i think shorthands will be used more than longhands, but 'corners' sorts after 'corner-'
- 08:21:42 [astearns]
- ack lea
- 08:21:50 [TabAtkins]
- lea: we don't usually design around tooling, tooling can change more easily than css
- 08:22:05 [TabAtkins]
- lea: that said, the one reason I can think of for naming it corner is it follows the prefixing practice
- 08:22:14 [noamr]
- q+
- 08:22:17 [TabAtkins]
- lea: but also, seeing "corner: ..." in a stylesheet looks a little werid
- 08:22:25 [TabAtkins]
- lea: there's some precedent, "columns" vs "column-width"
- 08:22:30 [astearns]
- ack noamr
- 08:22:31 [florian]
- q+
- 08:23:04 [TabAtkins]
- noamr: why I suggested corners before is, unlike border/background, you don't have a concept of "a" corner. You dont' say "what corner does it have", you say "what corners does it have". unlike "what border does it have"
- 08:23:12 [TabAtkins]
- noamr: so it just works better in English I think
- 08:23:30 [astearns]
- ack florian
- 08:24:05 [TabAtkins]
- florian: for short shorthand, 'corners' is okay either way. for the mid shorthands, the resolution says 'corners-top-left', sounds bad. want to go singular for that
- 08:24:13 [fantasai]
- PROPOSED: s/corners-*/corner-*/ on the shorthand
- 08:24:24 [fantasai]
- PROPOSED: s/corners-*/corner-*/ on the long shorthands
- 08:24:25 [astearns]
- ack fantasai
- 08:24:25 [Zakim]
- fantasai, you wanted to ask wrt the shorthands
- 08:24:26 [TabAtkins]
- florian: in some cases singular is obvious, in some it's arguable, but it's definitely not correct to be plural everywhere
- 08:25:15 [fantasai]
- astearns: border-radius, not border-radii
- 08:25:23 [fantasai]
- TabAtkins: People don't talk about border-radii of the box
- 08:25:35 [TabAtkins]
- s/border-radii/border-radiuses/
- 08:26:01 [fantasai]
- fantasai: Should we resolve on the long shorthand?
- 08:26:06 [fantasai]
- fantasai: since they're singular
- 08:26:14 [fantasai]
- florian: We well have the mid shorthands, for two corners each
- 08:26:29 [TabAtkins]
- SebastianZ: we should be consistent across the shorthands
- 08:26:30 [fantasai]
- SebastianZ: We should be consistent across the shorthands, regarding the naming
- 08:26:50 [fantasai]
- TabAtkins: do you mean all of them, or all of the mid shorthands
- 08:26:58 [TabAtkins]
- astearns: all of them
- 08:27:16 [kbabbitt]
- +1 to singular in all the shorthands
- 08:27:16 [TabAtkins]
- noamr: i'm convinced consistency is more important than English practice here
- 08:27:29 [TabAtkins]
- astearns: sound slike consensus for 'corner' in all cases
- 08:27:32 [TabAtkins]
- astearns: objections?
- 08:27:46 [TabAtkins]
- RESOLVED: Use 'corner' and 'corner-*' for all
- 08:27:54 [fantasai]
- I was ambivalent, but I'm convinced by the "one vs two vs four" of shorthand
- 08:28:26 [TabAtkins]
- lea: the tag principle does stress consistency, but says other things can take precedence
- 08:28:42 [TabAtkins]
- fantasai: I was ambivalent until we started talking about the longer shorthands
- 08:28:51 [TabAtkins]
- fantasai: corners-top-left only sets one corner, but corners-top is setting two
- 08:29:01 [TabAtkins]
- fantasai: corner-top-left and corners-top is confusing
- 08:29:36 [lea]
- q+
- 08:29:42 [astearns]
- ack fantasai
- 08:29:42 [Zakim]
- fantasai, you wanted to respond to lea
- 08:29:42 [TabAtkins]
- fantasai: both singular or both plural is fine. but corner-top-left is just kinda weird anyway
- 08:30:00 [ydaniv]
- q+
- 08:30:00 [TabAtkins]
- lea: have we considered having a singular when setting one corner and a plural when setting multiple?
- 08:30:14 [TabAtkins]
- astearns: yes, we just discussed that. I agree it's too confusing
- 08:30:16 [astearns]
- ack ydaniv
- 08:30:16 [TabAtkins]
- TabAtkins: agreed
- 08:30:26 [TabAtkins]
- ydaniv: some people look at it like 'corners' is a namespace
- 08:30:46 [TabAtkins]
- ydaniv: corners-top-left is like corners.topLeft
- 08:30:51 [fantasai]
- s/corner-to-left is just kinda weird anyway/but corner-top-left and corners-top, where one is plural and the other not, is going to be confusing for authors/
- 08:30:54 [TabAtkins]
- ydaniv: so it's not that weird to some people
- 08:31:04 [florian]
- q?
- 08:31:32 [TabAtkins]
- florian: also note that a large fraction of the population doens't have native plurals
- 08:31:46 [TabAtkins]
- florian: if you have to already intuit English grammar when programming, not impossible, but one more thing to remember
- 08:31:49 [fantasai]
- s/confusing for authors/confusing for authors, and corners-top-left where we're pluralizing a singular is also weird/
- 08:32:16 [fantasai]
- +1 wrt i18n
- 08:32:31 [TabAtkins]
- astearns: cutting bikeshedding short. if someone thinks having two words for the shorthands is something to do, we can discuss it later
- 08:32:38 [TabAtkins]
- astearns: break time
- 08:32:44 [TabAtkins]
- github-bot, end topic
- 08:48:33 [alisonmaher]
- alisonmaher has joined #css
- 08:48:37 [ydaniv]
- ydaniv has joined #css
- 08:48:41 [ydaniv]
- scribe+
- 08:48:46 [github-bot]
- Topic: Reconsider <An+B># for :heading
- 08:49:01 [kizu]
- kizu has joined #css
- 08:49:26 [ydaniv]
- TabAtkins: some context, what whatwg was doing regarding heading level
- 08:49:42 [ydaniv]
- ... this issue is about design of functional form of heading()
- 08:49:55 [ydaniv]
- ... per spec it takes a comma separated list of An+B
- 08:50:02 [ydaniv]
- ... Ana wanted to simplify this
- 08:50:08 [fantasai]
- s/Ana/Anne
- 08:50:15 [ydaniv]
- ... wanted An+B
- 08:50:30 [ydaniv]
- ... I pushed back and suggested to do comma separated integers
- 08:50:37 [ydaniv]
- ... some discussion back and forth
- 08:50:52 [ydaniv]
- ... Anne is pushing back on pseudo classes for some reason
- 08:50:57 [kbabbitt]
- q+
- 08:51:04 [ydaniv]
- ... my suggestion is to do comma separated integers
- 08:51:11 [fantasai]
- s/pseudo classes/comma-separated lists/
- 08:51:12 [astearns]
- ack lea
- 08:51:15 [astearns]
- ack kbabbitt
- 08:51:23 [ydaniv]
- kbabbitt: wanted more details on the discussion
- 08:51:30 [ydaniv]
- ... it allows now 6 levels in HTML
- 08:51:47 [ydaniv]
- ... is this allowing more levels? or disassocating from HTML?
- 08:51:50 [ydaniv]
- TabAtkins: both
- 08:51:56 [SebastianZ]
- q+
- 08:52:07 [ydaniv]
- ... use generic tag and have it not rely on tag name
- 08:52:18 [ydaniv]
- ... but also to allow more levels, arbitrary number of levels
- 08:52:27 [TabAtkins]
- s/arbitrary/not arbitrary/
- 08:52:30 [astearns]
- ack SebastianZ
- 08:52:55 [ydaniv]
- SebastianZ: should it be restricted to just 9? or more?
- 08:53:09 [ydaniv]
- TabAtkins: the pseudo class should allow you any number
- 08:53:11 [astearns]
- ack fantasai
- 08:53:11 [Zakim]
- fantasai, you wanted to respond
- 08:53:21 [noamr]
- noamr has joined #css
- 08:53:24 [ydaniv]
- fantasai: we can allow any number
- 08:53:30 [florian]
- q+
- 08:53:45 [ydaniv]
- ... we aren't going to limit it
- 08:53:50 [astearns]
- ack florian
- 08:53:50 [ydaniv]
- ... syntax is optimized for it
- 08:54:12 [noamr]
- q+
- 08:54:27 [ydaniv]
- florian: I have a hard time for allowing these patterns
- 08:54:37 [SebastianZ]
- q+
- 08:54:40 [ydaniv]
- ... would rather have comma separated to be simpler
- 08:54:44 [astearns]
- ack noamr
- 08:55:05 [ydaniv]
- noamr: there is presedence for comma separated
- 08:55:34 [fantasai]
- s/presedence/precedence/
- 08:56:02 [ydaniv]
- ... when you have list items, you don't know how many are going to be, and relationship is linear
- 08:56:05 [oriol]
- q+
- 08:56:15 [astearns]
- ack SebastianZ
- 08:56:22 [diekus]
- diekus has joined #css
- 08:56:33 [ydaniv]
- SebastianZ: quick idea, maybe introduce keywords>
- 08:56:41 [ydaniv]
- s/>/?/
- 08:56:49 [astearns]
- ack oriol
- 08:56:50 [fantasai]
- SebastianZ: e.g. "1 to 6"
- 08:56:52 [ydaniv]
- oriol: no strong opinion
- 08:56:58 [TabAtkins]
- If you want *all* headings, that's `:heading`. if you want several but not all, `:heading(1, 2, 3, 4, 5)` isn't bad to write
- 08:57:14 [ydaniv]
- ... however, if we go with list the stack should be using logical OR or AND
- 08:57:30 [fantasai]
- TabAtkins: Not possible to have something be both heading 1 and heading 2,
- 08:57:35 [fantasai]
- TabAtkins: so only one possible interpretation
- 08:57:39 [ydaniv]
- florian: I think we should go with list of integers, just to clarify
- 08:58:07 [lea]
- Q?
- 08:58:26 [ydaniv]
- SebastianZ: advocate for using just numbers, but allow patterns?
- 08:58:34 [ydaniv]
- florian: not object but seems unnecessary
- 08:58:45 [ydaniv]
- fantasai: Agree with florian, we shouldn't bother
- 08:58:46 [kbabbitt]
- +1 to florian
- 08:58:53 [ydaniv]
- +1 to florian
- 08:58:58 [TabAtkins]
- +1
- 08:59:05 [ydaniv]
- PROPOSED: use comma separated integers
- 08:59:08 [lea]
- Q+
- 08:59:10 [ydaniv]
- astearns: other comments?
- 08:59:43 [ydaniv]
- lea: the An+B case is one of the comlex cases, something that also come with nth-child case
- 08:59:43 [astearns]
- ack lea
- 09:00:00 [ydaniv]
- ... and authors have to write all sorts of weird things
- 09:00:16 [ydaniv]
- ... so instead of just commas is to allow ranges from a to b
- 09:00:35 [ydaniv]
- TabAtkins: argument against is because the set is finite then allow just specifying it
- 09:01:02 [ydaniv]
- lea: in this case yes, because it's finite
- 09:01:10 [ydaniv]
- ... in other cases ranges are more desirable
- 09:01:21 [ydaniv]
- ... then we can also fix it here and fix all
- 09:01:22 [florian]
- q+
- 09:01:25 [astearns]
- ack fantasai
- 09:01:37 [ydaniv]
- fantasai: don't disagree, but think this is not the place to fix it
- 09:01:48 [ydaniv]
- lea: it's already limited to integers
- 09:01:50 [SebastianZ]
- lea See https://github.com/w3c/csswg-drafts/issues/4140
- 09:01:56 [kizu]
- To crosslink stuff, SebastianZ's issue about ranges: https://github.com/w3c/csswg-drafts/issues/4140
- 09:02:37 [ydaniv]
- lea: I agree we should simplify, but think we also need ranges
- 09:03:12 [TabAtkins]
- fantasai: people don't do repeating patterns on hierarchical section levels
- 09:03:22 [ydaniv]
- astearns: we're not going to discuss ranges for this issue
- 09:03:35 [ydaniv]
- ... was brought up before, but not for this one
- 09:04:01 [ydaniv]
- florian: I think choice should be either list of integers, or straight to An+B as a list
- 09:04:09 [ydaniv]
- ... I think there's one impl. in ladybird?
- 09:04:31 [ydaniv]
- ... if we haven't specced or implemented anything then <missed>
- 09:04:47 [ydaniv]
- ... if it's done already then, I'm ok with list of integers
- 09:05:18 [emilio]
- q+
- 09:05:19 [florian]
- s/f we haven't specced or implemented anything then <missed>/f we hdn't specced or implemented anything then I'd to list of integers
- 09:05:24 [ydaniv]
- astearns: we have 2 options? currently has a list of An+B, we can leave like that or change to list of integers
- 09:05:27 [astearns]
- ack florian
- 09:05:34 [astearns]
- ack emilio
- 09:05:48 [ydaniv]
- emilio: we can change have way
- 09:06:01 [florian]
- s/if it's done already then, I'm ok with list of integers/given that it's already implemmented in a few places, I'm ok with list of An+Bs
- 09:06:04 [ydaniv]
- ... I don't think having a list of integers is the only thing we could do
- 09:06:29 [ydaniv]
- astearns: hearing slight preference to list of integers
- 09:06:37 [ydaniv]
- emilio: might save a couple of bytes
- 09:06:59 [ydaniv]
- SebastianZ: once we discuss the issue about ranges and come to a solution on that
- 09:07:07 [ydaniv]
- ... I would apply that to all the other places
- 09:07:15 [ydaniv]
- florian: but that remains open regardless
- 09:07:23 [ydaniv]
- ... we're still open to doing that
- 09:07:31 [astearns]
- 1) list of An+B 2) list of integers
- 09:07:34 [TabAtkins]
- 2
- 09:07:35 [ydaniv]
- astearns: let's draw a poll
- 09:07:37 [fantasai]
- 2, but also ok with 1
- 09:07:37 [kbabbitt]
- 2
- 09:07:41 [lea]
- 2
- 09:07:43 [andruud]
- 2
- 09:07:46 [astearns]
- no preference
- 09:07:48 [emilio]
- weak preference for 1, also fine with 1
- 09:07:49 [SebastianZ]
- No preference
- 09:07:49 [diekus]
- 2
- 09:07:51 [oriol]
- abstain
- 09:07:51 [emilio]
- with 2*
- 09:07:53 [alisonmaher]
- No preference
- 09:07:59 [kizu]
- 2
- 09:08:06 [ydaniv]
- 2
- 09:08:18 [florian]
- ok either way
- 09:09:00 [ydaniv]
- proposed resolution: change spec to list of integers
- 09:09:02 [moonira]
- moonira has joined #css
- 09:09:04 [ydaniv]
- astearns: objections?
- 09:09:19 [ydaniv]
- RESOLVED: change spec to list of integers
- 09:10:02 [ydaniv]
- github-bot, take up https://github.com/w3c/csswg-drafts/issues/10258
- 09:10:02 [github-bot]
- Topic: [css-anchor-position][other] Handling popover default styles
- 09:10:02 [github-bot]
- OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10258.
- 09:10:26 [astearns]
- astearns has changed the topic to: https://github.com/orgs/w3c/projects/209/views/1
- 09:11:02 [ydaniv]
- TabAtkins: quick intro, popovers and dialogs in general have some default styling that centers them
- 09:11:16 [ydaniv]
- ... in both they're positioned elements and uses auto margins to do the centering
- 09:11:29 [ydaniv]
- ... this is not consistent when you need to have anchor pos
- 09:11:44 [ydaniv]
- ... and you should be able to easily use anchor positioning
- 09:11:51 [ydaniv]
- ... it trips authors up
- 09:12:01 [ydaniv]
- ... so fantasai and I tried to find a solution
- 09:12:43 [ydaniv]
- ... we think we have it, adding a new alignment value called dialog, which either centers or acts as "normal"
- 09:13:07 [ydaniv]
- ... this lets you overide default stuff from UA
- 09:13:20 [ydaniv]
- ... only thing is that you have to use a special keyword which is strange
- 09:13:23 [fantasai]
- Tab is summarizing https://github.com/w3c/csswg-drafts/issues/10258#issuecomment-3099281092
- 09:13:37 [ydaniv]
- ... use case for it is that it's generic enough for exposing
- 09:13:54 [ydaniv]
- ... had a few objections about this, lea had some
- 09:14:04 [ydaniv]
- ... we discussed this previously
- 09:14:31 [ydaniv]
- ... yesterday iank_ said we could auto coarse margins to 0 if popover uses anchor pos
- 09:14:48 [ydaniv]
- ... I really disagree because it's purely magical and canot be done other way
- 09:15:01 [ydaniv]
- ... it pevernts authors from setting their own margins
- 09:15:21 [ydaniv]
- ... also note that iank_ expresed some concern about compat for changing this
- 09:15:50 [ydaniv]
- ... talked about this internally, there's stuff we could do, perhaps ignore compat for now
- 09:16:11 [ydaniv]
- ... opening for discussion, hoping we can add the alignment value, this is my preference
- 09:16:12 [astearns]
- ack fantasai
- 09:17:20 [ydaniv]
- fantasai: one thing about the margin 0-ing, with alignment don't need to fir content if it's auto
- 09:17:31 [ydaniv]
- ... but with the margin 0-ing won't work
- 09:17:37 [ydaniv]
- s/fir/fit/
- 09:17:59 [ydaniv]
- astearns: other comments?
- 09:18:15 [ydaniv]
- fantasai: a 3rd option would be to recast the way anchor position area works
- 09:18:41 [lea]
- q?
- 09:18:41 [ydaniv]
- ... instead of setting the alignment value to something magical, to make margin auto to be something magical
- 09:18:46 [fantasai]
- s/margin/inset
- 09:19:10 [ydaniv]
- TabAtkins: would prefere to minimize magic as much as possible
- 09:19:12 [ydaniv]
- lea: agree
- 09:19:44 [ydaniv]
- TabAtkins: we already have some behavior switching, but we already have precedence
- 09:20:05 [lea]
- q+
- 09:20:12 [fantasai]
- Proposed changes to the UA default stylesheet
- 09:20:14 [fantasai]
- [popover] { position: fixed; place-self: dialog; /* new */ /* deleted X inset: 0; X width: fit-content; X height: fit-content; X margin: auto; */ border: solid; padding: 0.25em; overflow: auto; color: CanvasText; background-color: Canvas;
- 09:20:15 [astearns]
- ack lea
- 09:20:18 [fantasai]
- }
- 09:20:39 [ydaniv]
- lea: been a while, we have this conditional branching if you're using anchor pos you have normal, otherwise center
- 09:20:41 [fantasai]
- -> https://github.com/w3c/csswg-drafts/issues/10258#issuecomment-3099281092
- 09:20:44 [ydaniv]
- ... it's still a black box
- 09:21:05 [ydaniv]
- ... could we break out some of the magic? allow in separate properties? maybe special case just for margins?
- 09:22:10 [ydaniv]
- TabAtkins: I argued against a general form of that
- 09:22:11 [lea]
- s/allow in separate properties? maybe special case just for margins?/e.g. a conditional around whether an element is anchored? Possibly only allowed in margin for now? At least then there is a path for making it more general later, whereas a keyword that encapsulates all the magic has no such path/
- 09:22:24 [ydaniv]
- ... just using anchor pos for that is interwoven with other features
- 09:22:43 [lea]
- q?
- 09:22:45 [lea]
- q+
- 09:22:48 [ydaniv]
- ... doing something so core to layout would be a large distinction on how we do it
- 09:23:01 [ydaniv]
- ... having a specific keyword for specific case it ok here
- 09:23:20 [ydaniv]
- ... a more generic for would make it so complex to where it's possible to use, so may not be worth doing
- 09:23:26 [astearns]
- ack fantasai
- 09:23:43 [ydaniv]
- fantasai: there's too many things that are affected
- 09:23:56 [ydaniv]
- ... don't think there are more use cases
- 09:24:51 [astearns]
- ack lea
- 09:24:53 [ydaniv]
- ... mostly trying to fix the badly designed defaults, if authors were doing it they wouldn't write this badly
- 09:25:11 [ydaniv]
- lea: not suggesting we add new deps. there are solutions that involve different synrtax
- 09:25:25 [ydaniv]
- ... this is part of the UA stylesheets, so ergonomics is part of the concern
- 09:25:38 [TabAtkins]
- s/is part/is not part/
- 09:26:04 [ydaniv]
- ... special casing a syntax that could be come more general
- 09:26:23 [lea]
- scribe+
- 09:26:59 [lea]
- lea: means we don't have to maintain this magic keyword forever, we have a path to a more general feature for down the line
- 09:27:16 [emilio]
- scribe+
- 09:27:17 [astearns]
- ack fantasai
- 09:27:17 [Zakim]
- fantasai, you wanted to say we should avoid designing something overcomplicated and overgeneral for a very specific problem
- 09:27:22 [lea]
- lea: it's conceivable that authors or the UA stylesheet will want to branch depending on whether an element is anchored
- 09:27:27 [emilio]
- fantasai: trying to spend the time effort to define a generic syntax
- 09:27:30 [emilio]
- ... is not worth doing
- 09:27:32 [lea]
- q+
- 09:27:46 [emilio]
- ... not worth doing now that we need this for compat now
- 09:27:56 [emilio]
- ... I don't see us generalizing this
- 09:28:02 [emilio]
- ... we have one thing for a very niche problem
- 09:28:05 [lea]
- lea: in that case, is it possible to restrict this value to the UA stylesheet so we don't have to maintain it forever? It seems of very limited utility to authors
- 09:28:07 [astearns]
- ack lea
- 09:28:33 [emilio]
- lea: that way later we can swap it in without having to worry about webcompat
- 09:28:59 [emilio]
- fantasai: it's a keyword, if we want it to make it compute to something else later we can
- 09:29:13 [emilio]
- astearns: might be on lea's side here, is there any problem with restricting it to UA sheet
- 09:29:16 [lea]
- q+
- 09:29:25 [emilio]
- ... it's a bit harder to implement but seems it'd be better for authors
- 09:29:42 [emilio]
- fantasai: I think the easiest way is to compute to normal or center depending on whether you're author positioned?
- 09:29:56 [emilio]
- ... not sure how easy to implement would that be
- 09:30:01 [emilio]
- ... it's not a complicated behavior tho
- 09:30:15 [emilio]
- ... its be centered if you're not anchor positioned otherwise normal
- 09:30:17 [lea]
- lea: there are other cases where we want to not expose certain values to authors and only allow them in the UA stylesheet, e.g. allowing authors to set `overlay: none` without setting overlay in general, so having a way to do this seems useful beyond this
- 09:30:18 [astearns]
- ack lea
- 09:30:22 [emilio]
- ... which itself behaves differently when anchor positioned
- 09:30:54 [emilio]
- q+
- 09:31:12 [astearns]
- ack emilio
- 09:31:34 [fantasai]
- emilio: Lea that's different, because they can set it, it just won't have an effect because it gets by a declaration in the UA !important origin
- 09:31:35 [TabAtkins]
- emilio: that's different. authors can set it, it's just overriden by the UA !important rule
- 09:31:55 [fantasai]
- emilio: You can set 'overlay: auto', and it'll create a declaration, it just won't have an effect
- 09:32:19 [emilio]
- fantasai: I really think we're spending a lot of time trying to overgeneralize here
- 09:32:30 [emilio]
- ... this is just trying to fix a very specific problem
- 09:32:53 [lea]
- q?
- 09:33:03 [emilio]
- ... we're certainly not going to move forward on anchor pos if we can't solve this and we don't get to the other issues
- 09:33:13 [emilio]
- TabAtkins: yeah it might also be useful for authors
- 09:33:23 [emilio]
- astearns: what's the current proposal
- 09:33:37 [emilio]
- TabAtkins: dialog, open to other names
- 09:34:09 [emilio]
- astearns: so proposal is to add a dialog value to alignment properties that computes to normal or center
- 09:34:13 [emilio]
- emilio: computes or behaves as?
- 09:34:19 [emilio]
- astearns: computes does more hiding
- 09:34:23 [lea]
- perhaps a better name could improve on how weird and overfit this feels
- 09:34:29 [fantasai]
- emilio: How many properties are we talking about here?
- 09:34:36 [lea]
- +1 astearns
- 09:35:06 [emilio]
- fantasai: align/justify-self and it'd depend on position / position-anchor, and maybe the inset properties
- 09:35:21 [emilio]
- TabAtkins: right we have a breakout on what "using anchor positioning" really means
- 09:35:32 [fantasai]
- emilio: I think it would be easier to make it behaves as
- 09:35:49 [fantasai]
- emilio: that doesn't add lots of inter-property dependencies that we may have trouble with
- 09:36:01 [fantasai]
- emilio: If depends on just one property is easy, six can get tangled
- 09:36:25 [fantasai]
- astearns: OK, can we resolve to add a 'dialog' value, name tb bikeshed, behaves as 'normal' or 'center' depending on layout mode
- 09:36:34 [fantasai]
- astearns: details TBD
- 09:37:00 [fantasai]
- fantasai: and use it for [popover] as described in https://github.com/w3c/csswg-drafts/issues/10258#issuecomment-3099281092
- 09:37:26 [fantasai]
- RESOLVED: Add 'dialog' value for align/justify-self, behaving as normal or center as appropriate, and rewrite [popover] UA styles per https://github.com/w3c/csswg-drafts/issues/10258#issuecomment-3099281092
- 09:37:41 [emilio]
- github-bot: take up https://github.com/w3c/csswg-drafts/issues/12607
- 09:37:42 [github-bot]
- Topic: [css-position][css-anchor-position] Splitting Scrollable Containing Blocks
- 09:37:42 [github-bot]
- OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12607.
- 09:37:47 [emilio]
- fantasai: [whiteboard time]
- 09:37:58 [emilio]
- fantasai: we have several different concepts of containing blocks
- 09:38:21 [emilio]
- ... position: fixed is the viewport, outside of the scrollable area
- 09:38:37 [emilio]
- ... position: absolute positions relative to the ICB
- 09:39:00 [emilio]
- ... for a scroll container we have the ICB behavior
- 09:39:15 [emilio]
- ... you can't get the fixed behavior unless you attach it to a wrapper around the scroll container
- 09:39:31 [emilio]
- ... when we were discussing anchor pos, and your anchor is towards the bottom
- 09:39:42 [emilio]
- ... the bottom of the icb is up there
- 09:39:59 [emilio]
- ... we floor it at the anchor which ends up with a containing block rect which is zero-height
- 09:40:34 [emilio]
- ... what you want is to create the nine-grid to create the thing to the whole scrollable area
- 09:40:55 [emilio]
- ... and we resolved to do that (use a representation of the 'in-flow scrollable area')
- 09:41:09 [emilio]
- ... for other scroll containers we don't have the ability to switch to the scrollport itself
- 09:41:16 [emilio]
- ... for anchor positioning this is particularly important
- 09:41:18 [emilio]
- q+
- 09:41:23 [emilio]
- ... because you want to trigger fallback
- 09:41:30 [emilio]
- ... so we need some kind of distinction
- 09:41:58 [emilio]
- ... there are other use cases for this outside of anchor pos, it's just a more pressing issue with it because of fallback
- 09:42:46 [emilio]
- ... so tab and i discussed syntactic switches, for {scrollport, icb-equivalent-thing, in-flow-scrollable-area}
- 09:43:03 [emilio]
- ... in order to allow the author to distinguish this we need new syntax
- 09:43:15 [emilio]
- ... we automatically decide on this for anchor pos
- 09:43:33 [emilio]
- ... would be nice to allow authors to change it, also we can't for other absposes r/n
- 09:43:56 [emilio]
- ... our proposal is to split `position` into three: `position-type: static/relative/sticky/absolute`
- 09:44:32 [astearns]
- q+
- 09:44:58 [emilio]
- ... `position-attachment: auto | local | fixed | scroll;` (local is icb, fixed is scrollport, scroll is in-flow-scrollable-area)
- 09:45:16 [astearns]
- (all of these details are in the first comment in the issue)
- 09:45:30 [emilio]
- ... `position-container: nearest | furthest | <custom-ident>;`
- 09:45:42 [SebastianZ]
- q+
- 09:46:23 [emilio]
- ... `nearest` gets you to nearest positioned element (abspos behavior), farthest is root (except when transformed) (fixedpos behavior)
- 09:46:53 [emilio]
- ... `position: absolute` would expand to `absolute auto nearest`
- 09:47:19 [emilio]
- ... `auto` behaves as `local` or `scroll` depending on whether you're anchor positioned
- 09:47:41 [emilio]
- ... `position: fixed` would expand to `absolute fixed farthest`
- 09:47:53 [emilio]
- ... that's the outline of the proposal
- 09:48:05 [astearns]
- ack emilio
- 09:48:16 [TabAtkins]
- emilio: I wanted dto double-check some eof the shorthand expansions, but I think it looks reasonable overall
- 09:48:31 [TabAtkins]
- emilio: if you have position-attachment:scroll and your CB isn't a scroll container...
- 09:48:45 [TabAtkins]
- fantasai: the attachment values only change things for scroll containers. any other element, it does nothing
- 09:48:58 [TabAtkins]
- emilio: i'd probably start without the container custom-ident, seems a bit complex
- 09:49:09 [TabAtkins]
- fantasai: yeah, that's just from another issue. don't need it in the syntax right this moment
- 09:49:25 [TabAtkins]
- emilio: and presumably these are paired..
- 09:49:34 [TabAtkins]
- emilio: position-attachment and container are useless unless you specify pos:absolute
- 09:49:45 [TabAtkins]
- emilio: but no reason to do them with position:relative
- 09:51:02 [ydaniv]
- emilio: I find it weird that position:fixed expands to container
- 09:51:09 [ydaniv]
- ... breaks my mental model
- 09:52:24 [TabAtkins]
- emilio: my mental model of position-fixed is about the container rather than attachment, but that's because in impl we parent it to a box outside the root scroller
- 09:52:37 [TabAtkins]
- emilio: if we impl this proposal we might change internally how we do pos:fixed to match this
- 09:52:41 [TabAtkins]
- emilio: in general this makes sense tho
- 09:52:49 [TabAtkins]
- emilio: probably want to leave out the custom ident stuff for now
- 09:53:06 [TabAtkins]
- SebastianZ: [somewhat missed]
- 09:53:15 [TabAtkins]
- emilio: you have the root scroller, it's a box outside of that which is the viewport
- 09:53:22 [TabAtkins]
- emilio: we parent a fixpos to that "box"
- 09:53:32 [TabAtkins]
- emilio: this changes it to instead attach to the scroller itself
- 09:53:38 [TabAtkins]
- emilio: rather than a pretend ancestor
- 09:53:51 [TabAtkins]
- q+
- 09:54:00 [emilio]
- astearns: Couple things
- 09:54:14 [emilio]
- ... you've raised the posibility of this isn't implementable because of the shorthandifying
- 09:54:21 [emilio]
- ... iank_ says it's not so bad
- 09:54:52 [emilio]
- ... but I don't think it addresses the issues we've hit in the past when shorthandifying
- 09:55:03 [fantasai]
- s/not so bad/not so bad to avoid shorthanding/
- 09:55:03 [emilio]
- TabAtkins: ian wants to not shorthandify, and says that is not so bad
- 09:55:23 [fantasai]
- s/... iank_/TabAtkins: iank_
- 09:56:14 [emilio]
- astearns: the other thing is that ian suggested for position container we could have just `auto | <custom-ident>`, but if we don't have the `<custom-ident>` we could leave that right?
- 09:56:18 [astearns]
- ack astearns
- 09:56:20 [emilio]
- fantasai: it's useful to attach to the root regardless
- 09:56:31 [emilio]
- TabAtkins: being able to be at the root without being fixed
- 09:56:45 [astearns]
- ack SebastianZ
- 09:57:01 [emilio]
- ... is useful for anchor pos to be in the top layer
- 09:57:08 [emilio]
- emilio: but the top layer doesn't scroll with the document right?
- 09:57:12 [emilio]
- q+
- 09:57:27 [emilio]
- SebastianZ: I think this could also solve changing the sticky position container
- 09:57:45 [emilio]
- ... regarding the default position-container is weird, is there an auto?
- 09:58:03 [emilio]
- fantasai: you don't need that. Assuming we can shorthandify then the expansion takes care of selecting the right default
- 09:58:31 [emilio]
- ... we could make it auto, but it'd be nice to be consistent
- 09:58:50 [emilio]
- emilio: you don't really need to shorthandify, and you could still not have auto
- 09:59:09 [emilio]
- ... you'd omit the default
- 09:59:14 [fantasai]
- s/consistent/avoid automagic where possible/
- 09:59:34 [emilio]
- SebastianZ: re. nearest and farthest I was thinking viewport. For fixed positioned it's the viewport
- 09:59:41 [emilio]
- fantasai: you can get trapped by a transform
- 09:59:44 [emilio]
- SebastianZ: fair
- 09:59:44 [bramus]
- q+
- 09:59:58 [emilio]
- SebastianZ: regarding custom-ident you'd need a separate property for that
- 10:00:14 [emilio]
- fantasai: yeah that'd be nice if we go down that path, and we'd need a separate
- 10:00:24 [emilio]
- SebastianZ: why custom-ident and not dashed-ident?
- 10:00:31 [emilio]
- fantasai: that's what we meant, should be dashed-ident
- 10:00:44 [emilio]
- SebastianZ: finally do we want to extend position shorthand?
- 10:00:51 [emilio]
- fantasai: yeah it should take the combination of all keywords
- 10:01:10 [astearns]
- ack TabAtkins
- 10:01:15 [emilio]
- TabAtkins: assuming that we can't shorthandify for a moment
- 10:01:31 [emilio]
- ... we could add an auto value that keys off the position property
- 10:01:51 [emilio]
- ... so position would remain as is, but `position-{container,attachment}` would have an auto value
- 10:02:32 [emilio]
- ... which would choose the right default
- 10:02:44 [emilio]
- emilio: I thought not shorthandifying would just expand the position syntax
- 10:02:48 [astearns]
- zakim, close queue
- 10:02:48 [Zakim]
- ok, astearns, the speaker queue is closed
- 10:03:03 [emilio]
- TabAtkins: while I agree having the shorthand would be more ideal, I agree with iank_ that not shorthanding would be not as bad
- 10:03:13 [astearns]
- ack emilio
- 10:03:29 [TabAtkins]
- emilio: want to confirm whether fixpos behavior includes the scrollbars gutters
- 10:03:37 [TabAtkins]
- emilio: rn we have weird inconsistent beahvior
- 10:03:41 [TabAtkins]
- emilio: should be sorted out
- 10:03:49 [TabAtkins]
- emilio: assuming mostly what pos:fixed is doing...
- 10:03:56 [TabAtkins]
- fantasai: should probably just match position:fixed yeah
- 10:04:03 [TabAtkins]
- bramus: issue 8099 is concerned with that
- 10:04:11 [TabAtkins]
- bramus: effect of scrollbar-gutter on the viewport
- 10:04:12 [fantasai]
- -> https://github.com/w3c/csswg-drafts/issues/8099
- 10:04:17 [TabAtkins]
- emilio: regarding shorthand vs not
- 10:04:29 [TabAtkins]
- emilio: imagine we would expand 'position' longhand to just contain these extra values
- 10:04:37 [TabAtkins]
- fantasai: they have to cascade and interact
- 10:05:04 [TabAtkins]
- TabAtkins: you misunderstand, Emilio proposed putting the entire syntax into 'position'
- 10:05:09 [TabAtkins]
- emilio: yeah, I think I kinda prefer that
- 10:05:16 [TabAtkins]
- fantasai: so we'd have these "conceptual" longhands
- 10:05:24 [TabAtkins]
- emilio: yeah, like display-inside vs outside
- 10:05:37 [astearns]
- ack bramus
- 10:05:40 [TabAtkins]
- fantasai: yeah that sounds better than independent properties that cascade badly
- 10:05:46 [TabAtkins]
- bramus: also wanted to point to issue 7475
- 10:05:48 [emilio]
- bramus: I also wanted to point to 7475
- 10:06:16 [emilio]
- ... flackr filed it to give authors an option to where to pos-fix your elements
- 10:06:21 [emilio]
- ... would this solve it?
- 10:06:51 [emilio]
- fantasai: it's a different thing
- 10:07:11 [emilio]
- ... but if we fix that it could be part of these properties
- 10:07:52 [emilio]
- fantasai: I'd be ok with proposing the syntax model without the longhands, just all into position for now, then decide if we can/want to split it
- 10:08:20 [emilio]
- ... so just the `position` syntax without the longhands
- 10:08:25 [fantasai]
- Proposal would be `position: <type> || <attachment> || <container>`
- 10:08:31 [fantasai]
- without the longhands possible
- 10:08:37 [emilio]
- astearns: I'd be uncomfortable resolving on it r/n, let's take it back to the issue
- 10:09:11 [emilio]
- Topic: lunch
- 10:09:12 [TabAtkins]
- github-bot, end topic
- 10:10:16 [dmangal]
- dmangal has joined #css
- 10:32:48 [kbabbitt]
- kbabbitt has joined #css
- 11:02:04 [fantasai]
- Topic: Image Animation
- 11:02:06 [fantasai]
- scribe+
- 11:02:25 [alisonmaher]
- alisonmaher has joined #css
- 11:03:03 [SebastianZ]
- SebastianZ has joined #css
- 11:03:18 [github-bot]
- Topic: [css-images] Disabling image animation
- 11:03:25 [florian]
- https://webplatform.design/talks/image-animation
- 11:03:37 [ydaniv]
- ydaniv has joined #css
- 11:03:41 [ydaniv]
- present+
- 11:03:57 [fantasai]
- florian: Image animation on the web needs some control
- 11:04:13 [fantasai]
- florian: Animated images, there are GIFs, APNG, WebP, etc. Not specific to a format.
- 11:04:16 [ChrisL]
- present+
- 11:04:22 [fantasai]
- florian: These are everywhere and here to stay
- 11:04:51 [fantasai]
- florian: Not just Geocities, but people love animated memes
- 11:05:02 [fantasai]
- s/memes/memes and emojis/
- 11:05:09 [fantasai]
- florian: OSmetimes used for animated icons
- 11:05:11 [kizu]
- kizu has joined #css
- 11:05:28 [fantasai]
- florian: Diagrams can be animated, or maybe you have animated backgrounds
- 11:05:37 [fantasai]
- florian: In many cases even user-generated content
- 11:05:59 [fantasai]
- florian: Typically embedded with <IMG>
- 11:06:11 [fantasai]
- florian: However, uncontrollable animations are a WCAG violation
- 11:06:45 [fantasai]
- florian: can trigger motion sensitivities, cause attention problems, or generally be annoying
- 11:07:01 [fantasai]
- florian: UAs have a pref to turn all animations off, unconditionally, everywhere -- but sometimes you want them
- 11:07:21 [fantasai]
- florian: Authors need to accommodate for user needs/preference, but doing that depends on the use of the animation
- 11:07:35 [fantasai]
- florian: Disabling animated background vs animated meme vs contentful image, differs
- 11:07:49 [fantasai]
- florian: Then there's question of is it new content, old content, user-generated content, etc.
- 11:08:12 [fantasai]
- florian: Authors do care: see stack overflow, reddit, polls by Lea, etc.
- 11:08:28 [fantasai]
- florian: There are some workarounds, but not perfect
- 11:08:39 [lea]
- present+
- 11:08:48 [fantasai]
- florian: Can do server-side to create set of frames and convert to mp4, but this is expensive
- 11:08:59 [fantasai]
- florian: clients side, but then only possible same-origin
- 11:09:21 [fantasai]
- s/clients side/client side extraction into <canvas>/
- 11:09:42 [fantasai]
- florian: in any case, these are complicated options
- 11:09:56 [fantasai]
- florian: Very simple solution would be 'image-animation: normal | pased | running'
- 11:10:09 [fantasai]
- florian: Put it on the root depending on prefers-reduced-motion, and let it inherit
- 11:10:20 [fantasai]
- florian: then select the ones you want to enable and flip it to 'running'
- 11:10:31 [fantasai]
- florian: "prefers-reduced-motion" isn't "never-animate"
- 11:10:40 [fantasai]
- florian: so, e.g. could be running on focus or hover
- 11:10:55 [fantasai]
- florian: (but then focusability of images is an issue)
- 11:11:36 [fantasai]
- florian: But for images with meaningful content, authors likely want to provie play/pause controls
- 11:11:59 [fantasai]
- lea: One idea is to allow images in <video>. This doesn't require any new API surface. Just a video with no audio track.
- 11:12:27 [fantasai]
- lea: Allowing images in <video> give syou full playback control, have a JS API to control, can enable looping, disable autoplay, even adjust speed
- 11:12:45 [fantasai]
- lea: Designed to be extensible, so will benefit from future extensions
- 11:12:52 [fantasai]
- lea: Proposed to WHATWG, initial reactions are promising
- 11:13:12 [fantasai]
- lea: But doesn't solve everything because a lot of existing content and infrastructure that uses <IMG>
- 11:13:32 [fantasai]
- lea: and also controlling via selectors is not possible
- 11:13:44 [fantasai]
- lea: So another idea is what if adding control attributes to <img>
- 11:14:04 [fantasai]
- lea: Can have same element as before (<img>), and tailor the UI to images rather than video
- 11:14:32 [fantasai]
- lea: But then we have to introduce new API surface, and awkward interface for boolean attributes that is opposite default of <video>
- 11:14:51 [fantasai]
- lea: Also can't respond to media queries
- 11:14:55 [fantasai]
- lea: or use selectors to control
- 11:15:16 [fantasai]
- lea: One idea is very high-level solution, to add a 'controlled' value to image-animation
- 11:15:42 [fantasai]
- florian: If we have the CSS property we discussed earlier, and we have images in <video>, and we have <img> + CAS, we are solved
- 11:15:48 [fantasai]
- florian: but CAS is specifiction right now
- 11:15:55 [fantasai]
- florian: Setting up <img> for controls is also not easy
- 11:16:00 [fantasai]
- florian: May or may not fly, so what else?
- 11:16:12 [fantasai]
- florian: So 'controlled' is a solution
- 11:16:38 [fantasai]
- florian: For background images etc. no effect, but for content <img>, would provide a play/pause controls *if* it's an animatable image
- 11:17:02 [fantasai]
- florian: responds to selectors, media queries, can work on older sites and user-generated content
- 11:17:19 [fantasai]
- florian: But if down the line we have images with controls, interactions between the two might be odd, and weird layering of things
- 11:17:39 [fantasai]
- lea: Another option is to expose lowlevel primitives, so authors can do it
- 11:17:50 [fantasai]
- lea: If you want control over playback, use a video
- 11:18:10 [fantasai]
- lea: but could also expose low-level primitives like an image::overlay pseudo-element to paint stuff over the image
- 11:18:22 [fantasai]
- lea: or img:static to target non-animated images from animated ones
- 11:18:56 [fantasai]
- lea: or connect into CSS Animations machinery, e.g. animation triggers
- 11:19:18 [fantasai]
- lea: These would be more useful more broadly
- 11:19:35 [fantasai]
- lea: We do have general tendency of generalizing, e.g. can play audio in <video>
- 11:19:43 [fantasai]
- lea: so unifying image is along these lines
- 11:19:50 [fantasai]
- lea: But simple things would not be easy with primitives
- 11:20:06 [fantasai]
- lea: and you can mess up author interactions, e.g. forget to put tabindex to make it focusable
- 11:20:14 [fantasai]
- lea: would be handled automatically if we had a controls attributes
- 11:20:51 [fantasai]
- lea: For CSS images, could have image-frame() to extract frames. But ocntrol over playback is tricky
- 11:21:17 [fantasai]
- lea: and e.g. pausing all images, you would need ability to style them all, which is not so simple for e.g. background imgaes
- 11:22:10 [fantasai]
- lea: Suppose if we went down the @image path for determining image tweaks, calling it with image(src options-name).
- 11:22:15 [fantasai]
- lea: Then you could attach animation controls.
- 11:23:01 [fantasai]
- lea: Or maybe we could hook up image animations to animation properties by using an image-animation() function to "name" the animation in animation-name and control it with animation-play-state
- 11:23:14 [fantasai]
- lea: But then everything becomes a list, it's maybe a bit awkward.
- 11:23:26 [fantasai]
- lea: Anyway, these are the thoughts.
- 11:23:38 [fantasai]
- florian: What we are most likely to pursue is what everyone else is interested in
- 11:23:46 [fantasai]
- florian: But images in video definitely given response in WHATWG
- 11:24:02 [fantasai]
- florian: But we are also considering proposing image-animation property for CSS
- 11:24:26 [fantasai]
- florian: Independently of that, whether Cascading Attribute Sheets becomes a thing, might determine the next steps
- 11:24:40 [fantasai]
- florian: But anyway, let us know which ideas you're interested in
- 11:24:53 [fantasai]
- lea: wrt resolutions, maybe just "we want to solve the problem"...
- 11:24:55 [SebastianZ]
- q+
- 11:24:56 [ydaniv]
- q+
- 11:25:06 [astearns]
- zakim, open queue
- 11:25:06 [Zakim]
- ok, astearns, the speaker queue is open
- 11:25:16 [fantasai]
- ydaniv: All of this is awesome. Lots of good ideas.
- 11:25:39 [fantasai]
- ydaniv: Currently animated images is a child that nobody wants, because it hurts performance so much
- 11:25:46 [lea]
- qq+ to reply to ydaniv
- 11:25:54 [fantasai]
- ydaniv: Animated images are very eager. Can cause everything on the page to freeze.
- 11:26:10 [astearns]
- q+ SebastianZ
- 11:26:22 [fantasai]
- ydaniv: That's one of the biggest issues, so maybe going through the medium direction and somehow make them streamable...
- 11:26:44 [fantasai]
- florian: Is the heaviness due to inefficiency of image format and it overhwelms the page or ....?
- 11:27:16 [fantasai]
- ydaniv: sometimes ppl make an animated sequence from a video, and then put it into ??
- 11:27:17 [astearns]
- ack lea
- 11:27:17 [Zakim]
- lea, you wanted to react to bramus to reply to ydaniv
- 11:27:43 [fantasai]
- lea: A lot of animated images are inserted by users *because* they're animated
- 11:27:51 [fantasai]
- lea: Unsure if webP is as inefficient as e.g. GIF
- 11:28:17 [astearns]
- ack SebastianZ
- 11:28:18 [lea]
- s/*because* they're animated/*because* they loop and autoplay. Once websites have control over this, it could remove one of the motivations for using gifs/
- 11:28:19 [fantasai]
- ydaniv: Issue about hooking video playback to animations, so allowing for animated images, people would be very happy
- 11:28:37 [fantasai]
- SebastianZ: Reporter of the issue related to this is one of the Firebug contributors
- 11:28:48 [fantasai]
- SebastianZ: Wrt animations, good idea to allow users to get some control over the animations
- 11:28:56 [fantasai]
- SebastianZ: Presented solutions are not necessarily exclusive
- 11:29:18 [lea]
- q+
- 11:29:24 [fantasai]
- SebastianZ: One thing I was missing in the presentation was the idea of having a param for the url() functions to control it
- 11:29:50 [emilio]
- q+
- 11:29:57 [fantasai]
- SebastianZ: e.g. to extract one frame from the image
- 11:30:09 [fantasai]
- lea: Mdia fragments are about getting a subresource
- 11:30:10 [astearns]
- ack lea
- 11:30:20 [fantasai]
- lea: extracting one frame might be seen as that, but playback control isn't
- 11:30:30 [fantasai]
- lea: Also, media frags isn't under charter atm...
- 11:30:45 [astearns]
- ack emilio
- 11:30:59 [fantasai]
- emilio: I see a lot less problems with the video approach
- 11:31:08 [fantasai]
- emilio: Making that apply to the CSS images is a bit more complicated
- 11:31:41 [fantasai]
- emilio: wrt pseudos, e.g. adding ::overlay would be OK if you only do for HTML images, not CSS images
- 11:31:44 [fantasai]
- emilio: ...
- 11:32:06 [fantasai]
- florian: In theory youc could have longhands for image-animation, but I think it woudl be rare to want to animate e.g. border but not background
- 11:32:40 [fantasai]
- emilio: Some precedent for having a property affect both content and style images
- 11:33:01 [romain]
- romain has joined #css
- 11:33:05 [fantasai]
- emilio: pseudo-element stuffs eems too limited to me
- 11:33:18 [fantasai]
- emilio: Controlling email animations would be helpful maybe
- 11:33:44 [fantasai]
- florian: the parts we're reasonably confident about are image-animation and <vedo>
- 11:33:58 [fantasai]
- florian: everything else, all of them can sort-of solve it, but different tradeoffs
- 11:34:03 [fantasai]
- florian: I like tihs one is the easiest
- 11:34:18 [fantasai]
- florian: but from layering, maybe it's the worst and other thing is better -- but then not responding ot MQ
- 11:35:03 [fantasai]
- florian: full of tradeoffs for the rest, unsure
- 11:35:04 [SebastianZ]
- q+
- 11:35:26 [fantasai]
- [missed]
- 11:35:33 [fantasai]
- lea: we have tools for timeline controls
- 11:35:45 [fantasai]
- emilio: track of time that's not continueous... feels more exploratory
- 11:35:49 [astearns]
- ack SebastianZ
- 11:36:07 [fantasai]
- SebastianZ: Not totally convinced imgae-animation is right, because it's affects all CSS images
- 11:36:28 [fantasai]
- florian: Only a problem if you have multiple animations you want to control independently
- 11:36:35 [ydaniv]
- ydaniv has joined #css
- 11:36:37 [fantasai]
- florian: I'm not convinced, seems theoretical
- 11:36:40 [lea]
- s/lea: we have tools for timeline controls/lea: one question is do we design this very simple image-animation property, or do we find some way to hook into CSS animations and make use of all the elaborate playback controls we have for them?/
- 11:36:42 [ydaniv]
- q?
- 11:36:45 [ydaniv]
- q+
- 11:36:48 [fantasai]
- florian: We could expand into longhands if becomes necessary
- 11:36:51 [astearns]
- zakim, close queue
- 11:36:51 [Zakim]
- ok, astearns, the speaker queue is closed
- 11:37:04 [fantasai]
- florian: if you have multiple images you want to control independently...
- 11:37:14 [fantasai]
- emilio: Never got this issue with image-orientation
- 11:37:29 [fantasai]
- ydaniv: wrt loading, if we put this in CSS it doesn't affect loading of the images
- 11:37:39 [fantasai]
- ydaniv: would be nice to say "load this images, but only load the first frame"
- 11:37:59 [fantasai]
- florian: I think this would be possible if you go through the the HTML route
- 11:38:34 [astearns]
- fantasai: agree with florian you’re unlikely to want to independently control …
- 11:38:58 [fantasai]
- fantasai: if we really need to do that, put parameters into image()
- 11:39:09 [fantasai]
- fantasai: HTML only every produces one image per element
- 11:39:21 [fantasai]
- astearns: roposed to resolve ot solve this problem
- 11:39:27 [fantasai]
- RESOLVED: Try to solve this problem
- 11:39:46 [fantasai]
- astearns: Where should people contribute into?
- 11:40:09 [fantasai]
- florian: This is an old issue that discusses the issue, and proposal being discussed is similar to this idea
- 11:41:02 [fantasai]
- Topic: Process
- 11:41:03 [TabAtkins]
- github-bot: end topic
- 11:41:09 [TabAtkins]
- Topic: process update
- 11:41:13 [TabAtkins]
- florian: short heads up
- 11:41:18 [TabAtkins]
- florian: process 2025 went live on Monday
- 11:41:21 [TabAtkins]
- florian: not a revolution
- 11:41:24 [TabAtkins]
- florian: ther'es a changes section
- 11:41:33 [TabAtkins]
- florian: from a WG perspective, Proposed Rec no longer exists
- 11:41:40 [TabAtkins]
- florian: criteria for CR -> Rec didn't change
- 11:41:45 [TabAtkins]
- florian: there's just no intermediate step
- 11:42:02 [TabAtkins]
- florian: PR -> Rec was AC voting, now they'll just vote on the CR trying to go to Rec
- 11:42:17 [TabAtkins]
- florian: there's some nuances about going from CRD to Rec, that's allowed as long as it's only editorial changes
- 11:42:30 [TabAtkins]
- florian: so that's the only main update
- 11:42:34 [astearns]
- zakim, open queue
- 11:42:34 [Zakim]
- ok, astearns, the speaker queue is open
- 11:43:02 [TabAtkins]
- Topic: auto publishing
- 11:43:23 [TabAtkins]
- ChrisL: most groups at w3c use auto-publishing
- 11:43:34 [TabAtkins]
- ChrisL: once they merge a PR it triggers a GitHub action and auto-publishes
- 11:43:39 [TabAtkins]
- ChrisL: for the classes of spec that it's allowed
- 11:43:45 [TabAtkins]
- ChrisL: we dont' do that, and that's now unusual
- 11:43:57 [TabAtkins]
- ChrisL: we also have some embarrassing cases like "spec last updated in 2013"
- 11:44:14 [TabAtkins]
- ChrisL: or people taking Flexbox /TR as authorative because it's 7 years out of date
- 11:44:21 [astearns]
- ack ydaniv
- 11:44:25 [TabAtkins]
- ChrisL: so I propose we auto-publish specs in the appropriate classes
- 11:44:26 [astearns]
- ack fantasai
- 11:44:34 [TabAtkins]
- fantasai: I think we need to do this on a document-by-document basis
- 11:44:42 [TabAtkins]
- fantasai: a number of specs in a messy state that shouldn't be auto-pubbed
- 11:44:43 [astearns]
- q+
- 11:44:54 [TabAtkins]
- fantasai: possible we want to pause auto-updates while we re-hash and enable later
- 11:45:03 [TabAtkins]
- fantasai: as long as we can do that, sounds okay
- 11:45:39 [fantasai]
- TabAtkins: could put it into GitHub actions
- 11:45:45 [fantasai]
- TabAtkins: file listing which specs are auto-published
- 11:45:57 [TabAtkins]
- astearns: we'd only need to do this for specs getting updated, anyway. won't autopub until PR
- 11:46:03 [TabAtkins]
- astearns: well, no, not the case, we refactor things sometimes
- 11:46:04 [florian]
- q+
- 11:46:07 [TabAtkins]
- astearns: so better to have a master list
- 11:46:07 [astearns]
- ack astearns
- 11:46:17 [TabAtkins]
- ChrisL: yeah we regularly do small wide-ranging editorial changes
- 11:46:17 [SebastianZ]
- q+
- 11:46:18 [astearns]
- ack florian
- 11:46:18 [andreubotella]
- andreubotella has joined #css
- 11:46:25 [TabAtkins]
- florian: this seems generally useful, with elika's caveat
- 11:46:37 [TabAtkins]
- florian: if we don't have that we'd have to change the way we work and only do work in PRs
- 11:46:42 [TabAtkins]
- florian: that would be uncomfortable
- 11:46:48 [TabAtkins]
- florian: so without the ability we'd probably have mistakes
- 11:47:08 [TabAtkins]
- florian: having a single repo probably means everything that's auto-published gets repubbed every time
- 11:47:13 [TabAtkins]
- florian: might be annoying
- 11:47:23 [TabAtkins]
- astearns: Chris, is it smart enough?
- 11:47:40 [TabAtkins]
- ChrisL: It usually triggers on "Bikeshed file has changed"...
- 11:47:56 [TabAtkins]
- fantasai: florian means, because we're a monorepo, doe supdating something else cause Flexbox to repub.
- 11:48:17 [TabAtkins]
- TabAtkins: you can tell what paths are changed in a commit, it's doable
- 11:48:32 [TabAtkins]
- fantasai: so turning on auto-publishing, with configuration
- 11:48:34 [SebastianZ]
- q-
- 11:48:41 [TabAtkins]
- fantasai: and it autopubs if that directory changes, not anything in the repo
- 11:48:53 [TabAtkins]
- fantasai: and if we set that up, default them to off with some turned on
- 11:49:12 [TabAtkins]
- fantasai: a lot of specs that i dont' want autopub yet, but will have them synced next publication
- 11:49:23 [TabAtkins]
- ChrisL: one change if an see, normally when I publish I update the Changes list
- 11:49:37 [TabAtkins]
- ChrisL: with auto-publish you don't necessarily do that, you just say "since last CR snapshots" or something
- 11:49:44 [TabAtkins]
- ChrisL: rather than specifically since "last publication"
- 11:50:07 [TabAtkins]
- astearns: by default that's what will happen, but it would be up to editor discretion to make a new section on significant milestones
- 11:50:16 [TabAtkins]
- ChrisL: right, just clarifying I don't expect people to start a new subsection for each pub
- 11:50:28 [TabAtkins]
- fantasai: for CRs, I think natural milestone is the snapshot
- 11:50:32 [TabAtkins]
- fantasai: for WDs not so much
- 11:50:45 [TabAtkins]
- fantasai: but can have editors decide on it
- 11:50:49 [TabAtkins]
- fantasai: can have WD snapshots
- 11:51:02 [TabAtkins]
- astearns: so this would be turned on for WDs and CRDs?
- 11:51:06 [TabAtkins]
- ChrisL: yes.
- 11:51:15 [TabAtkins]
- ChrisL: fpwd and crs and rec can't be auto-pubbed anyway
- 11:51:19 [TabAtkins]
- astearns: and that's all we've got now
- 11:51:27 [TabAtkins]
- ChrisL: I've been talking about other groups and PRs
- 11:51:31 [TabAtkins]
- ChrisL: our specs aren't edited like that
- 11:51:43 [TabAtkins]
- ChrisL: I don't know if we want to revisit it or not
- 11:51:48 [TabAtkins]
- ChrisL: I'd want to see how the tooling can work
- 11:52:01 [TabAtkins]
- TabAtkins: I'm confident we don't need to, we can just rely on commits
- 11:52:07 [fantasai]
- PROPOSED: Allow individual specs to opt into autopublishing WD or CRD, make sure we don't republish everything anytime one thing changes.
- 11:52:20 [TabAtkins]
- ChrisL: okay, don't want to change our work mode then if we dont' need to
- 11:53:00 [ChrisL]
- https://github.com/WebAudio/web-midi-api/blob/gh-pages/.github/workflows/auto-publish.yml
- 11:53:01 [TabAtkins]
- SebastianZ: what about Notes?
- 11:53:06 [TabAtkins]
- fantasai: we can put Notes in there
- 11:53:15 [TabAtkins]
- astearns: it would be good to autopub Notes too
- 11:53:26 [TabAtkins]
- astearns: objections to the proposed resolution?
- 11:53:28 [fantasai]
- RESOLVED: Allow individual specs to opt into autopublishing WD or CRD or NOTEs, make sure we don't republish everything anytime one thing changes.
- 11:53:40 [TabAtkins]
- fantasai: if you're making big changes and think they need review, turn off autopub
- 11:53:51 [TabAtkins]
- astearns: we'll get some new processes in place to adapt to this
- 11:54:17 [TabAtkins]
- TabAtkins: how easy is it to unpublish?
- 11:54:28 [TabAtkins]
- fantasai: just revert and republish
- 11:54:38 [TabAtkins]
- ChrisL: as long as it's within the same (GMT) day, they only keep the latest version
- 11:54:56 [fantasai]
- s/just revert/if it's still the same day, you can revert
- 11:55:03 [TabAtkins]
- Topic: explainers workshop
- 11:55:18 [TabAtkins]
- fantasai: raise hand if you've written an explainer for a CSS feature
- 11:55:40 [TabAtkins]
- fantasai: if all your explainers are in the CSSWG repo
- 11:55:59 [TabAtkins]
- fantasai: you can stop
- 11:56:06 [TabAtkins]
- fantasai: I fyou have explainers elsewhere, how many?
- 11:56:10 [bramus]
- There’s about to be one 😅
- 11:56:15 [bramus]
- (see next topic)
- 11:56:16 [TabAtkins]
- [answers]
- 11:56:28 [bkardell]
- I have a few things that could be considered explainers, maybe 2
- 11:57:36 [kbabbitt]
- one of my 2 is in need of significant changes after discussion yesterday
- 11:57:36 [TabAtkins]
- fantasai: we should spend the next few minutes moving the explainer into csswg
- 11:57:47 [TabAtkins]
- florian: what if the spec didn't end up existing?
- 11:58:13 [TabAtkins]
- fantasai: it can still go in the repo
- 11:58:19 [TabAtkins]
- TabAtkins: an "unknown spec" folder
- 11:58:29 [TabAtkins]
- ydaniv: I complained about this to Tab a few years ago
- 11:58:37 [ChrisL]
- rrsagent, make minutes
- 11:58:38 [RRSAgent]
- I have made the request to generate https://www.w3.org/2025/08/21-css-minutes.html ChrisL
- 11:58:49 [TabAtkins]
- florian: why just explainers and not tentative specs?
- 11:58:55 [TabAtkins]
- fantasai: they should be in the repo, right?
- 11:59:27 [TabAtkins]
- florian: no, I have a bunch of things in my personal repo. tab too. do we really want all of those in our repo?
- 11:59:41 [TabAtkins]
- ydaniv: some specs live outside for a while before they're eventually accepted
- 12:00:00 [TabAtkins]
- astearns: I have a suggestion. Let's start a thread on the private list so people can post "here are my explainers"
- 12:00:07 [TabAtkins]
- astearns: we can discuss which ones need to go into the repo and where
- 12:00:12 [TabAtkins]
- astearns: hash it out between ourselves
- 12:00:19 [TabAtkins]
- astearns: we can use the info in the thread to hold each other accountable
- 12:00:23 [TabAtkins]
- fantasai: sounds good
- 12:01:00 [TabAtkins]
- fantasai: note that anything we've discussed at all, needs to be in the repo or else it'll disappear. that's a process requirement you helped approve
- 12:01:20 [TabAtkins]
- florian: the req isn't for a w3c URL. random Google docs, not stable. blog or another gh repo, more stable.
- 12:01:20 [fantasai]
- s/approve/draft/
- 12:01:28 [TabAtkins]
- astearns: i'll help collect information and hold people accountable.
- 12:01:47 [florian]
- > Materials referenced from discussions and necessary to understand them should be available at a stable URL, at a level of confidentiality no stricter than the discussion minutes.
- 12:01:51 [TabAtkins]
- Topic: CSS parser extensions
- 12:02:47 [TabAtkins]
- bramus: warning, not a browser engineer, i'm in devrel. sometimes a strength, how to implement isn't my problem.
- 12:02:56 [TabAtkins]
- bramus: so just want to start a cconvo
- 12:03:04 [TabAtkins]
- bramus: you have a new CSS feature, you have a shipping timeline
- 12:03:18 [TabAtkins]
- bramus: one browser first, and some delay until the last major browser
- 12:03:30 [TabAtkins]
- bramus: there's a clear cut at the last browser shipping
- 12:03:36 [TabAtkins]
- bramus: before that it's not cross-browser, not "baseline"
- 12:03:47 [TabAtkins]
- bramus: terminology being used now is "baseline newly available"
- 12:03:59 [TabAtkins]
- bramus: another cut is 2.5 years later, becomes "baseline widely available"
- 12:04:25 [TabAtkins]
- bramus: first part (first to last impl) can be totally variable. but most authors wait for "widely available" before adopting
- 12:04:49 [TabAtkins]
- bramus: how devrel currently deal with this, is we talk about progressive enhancement
- 12:04:56 [TabAtkins]
- bramus: sometimes this is easy, like text-wrap:pretty
- 12:05:01 [TabAtkins]
- bramus: if it doesn't work, nothing bad happens
- 12:05:18 [TabAtkins]
- bramus: sometimes more difficult, like scroll-driven animations
- 12:05:27 [TabAtkins]
- bramus: hard to convince some people that these are enhancements
- 12:05:44 [TabAtkins]
- bramus: hard to convince it's worth implementing when your c-suite can't see a feature on their iphone
- 12:05:58 [TabAtkins]
- bramus: next is, we can do polyfills
- 12:06:15 [TabAtkins]
- bramus: prereqs are complex.
- 12:06:15 [bkardell]
- present+
- 12:06:27 [TabAtkins]
- bramus: authors want a CSS feature to totally replace an existing script they're using
- 12:06:30 [TabAtkins]
- bramus: so not two codepaths
- 12:06:41 [TabAtkins]
- bramus: polyfill should be small, should be unobtrusive
- 12:06:45 [TabAtkins]
- bramus: and should be feature-complete
- 12:06:54 [TabAtkins]
- bramus: some things can't really be polyfilled, just mimicced
- 12:07:06 [TabAtkins]
- bramus: like top-layer can be z-index, but not perfect
- 12:07:18 [TabAtkins]
- bramus: so, hard to do. polyfill is really hard
- 12:07:23 [TabAtkins]
- bramus: quote from pwalton
- 12:07:41 [TabAtkins]
- bramus: if you're not familiar, let me walk thru it
- 12:07:49 [TabAtkins]
- bramus: to polyfill, the CSS parser discards what it doesn't know
- 12:07:56 [TabAtkins]
- bramus: this is a CSS superpower, but here it's against us
- 12:08:07 [TabAtkins]
- bramus: [shows some invalid properties]
- 12:08:24 [TabAtkins]
- bramus: if you want to polyfill this, you need 3 steps
- 12:08:31 [TabAtkins]
- bramus: 1) gather all styles 2) parse them 3) apply them
- 12:08:34 [TabAtkins]
- bramus: all much harder than it seems
- 12:08:51 [TabAtkins]
- bramus: 1) many sources where styles can live. document stylesheet, adopted stylesheets, styles ttribute
- 12:08:55 [TabAtkins]
- bramus: watch for mutations
- 12:09:06 [TabAtkins]
- bramus: and imports, as Brian says
- 12:09:15 [TabAtkins]
- bramus: 2) after gathering, parse. need to deal with cors
- 12:09:19 [TabAtkins]
- bramus: then tokenize and parse
- 12:09:27 [TabAtkins]
- bramus: silly, because UA already did this, but you need to do it again
- 12:09:36 [TabAtkins]
- bramus: and if you wrote a polyfill, need to ensure your parser logic is up to date
- 12:09:49 [TabAtkins]
- bramus: when @layer introduced, need to make sure you parser understand it. Nesting, same
- 12:10:00 [TabAtkins]
- bramus: so as an author of a polyfill, once you publish it you're responsible to keep it up to date
- 12:10:03 [TabAtkins]
- bramus: people don't do this
- 12:10:13 [TabAtkins]
- bramus: 3) then apply the styles. write your own cascade
- 12:10:27 [TabAtkins]
- bramus: listeners, to make sure MQs work, and style queries
- 12:10:34 [TabAtkins]
- bramus: so much reinvention
- 12:10:41 [TabAtkins]
- bramus: so that's the problem
- 12:10:45 [TabAtkins]
- bramus: enter parser extensions
- 12:11:00 [TabAtkins]
- bramus: we should keep the CSS parser discarding what it doesn't udnerstand
- 12:11:09 [TabAtkins]
- bramus: but absurd for polyfill authors to write their own parser/etc
- 12:11:15 [astearns]
- has anyone used the devtools protocol to do all this (since devtools does appear to keep invalid declarations at hand?)
- 12:11:20 [TabAtkins]
- bramus: thinking of CSS.parser JS interface
- 12:11:25 [TabAtkins]
- bramus: here's a braindump
- 12:11:38 [TabAtkins]
- bramus: CSS.parser.registerSyntax(), .registerKeyword(), etc
- 12:11:47 [TabAtkins]
- bramus: once registered, how to they compute?
- 12:11:55 [TabAtkins]
- bramus: what happens when an element is matched and unmatched?
- 12:11:59 [TabAtkins]
- bramus: some examples
- 12:12:21 [TabAtkins]
- bramus: [shows a code example for a `random` keyword, that becomes a number
- 12:12:46 [florian]
- q?
- 12:12:47 [TabAtkins]
- bramus: catching and invalidation ensures it evaluates correctly
- 12:12:51 [TabAtkins]
- q+
- 12:13:01 [TabAtkins]
- bramus: [another example, of light-dark() polyfill]
- 12:13:32 [lea]
- q+
- 12:13:40 [TabAtkins]
- bramus: [another example, of at-rule polyfill]
- 12:14:11 [TabAtkins]
- bramus: [and of a property polyfill]
- 12:14:43 [TabAtkins]
- bramus: [another scroll-timeline polyfill example]
- 12:14:51 [astearns]
- q+
- 12:14:58 [lea]
- q-
- 12:14:59 [lea]
- q+
- 12:15:02 [TabAtkins]
- bramus: say we have something like this. I think it would help authors a lot
- 12:15:09 [TabAtkins]
- bramus: great for polyfill authors
- 12:15:18 [TabAtkins]
- bramus: more reliable and much faster
- 12:15:26 [TabAtkins]
- bramus: anchor pos polyfill, 85% of the codebase was just parsing and targeting
- 12:15:35 [TabAtkins]
- bramus: using this would make it 1/6 the size
- 12:15:45 [TabAtkins]
- bramus: polyfills will be more performant too, and robust
- 12:15:59 [TabAtkins]
- bramus: speaking from xp, scroll-timeline polyfill, half the issues are parsing issues
- 12:16:13 [TabAtkins]
- bramus: benefit for regular CSS authors (not polyfill authors) is polyfills are drop-in
- 12:16:25 [TabAtkins]
- bramus: no need to write special syntax, they just use it as-is
- 12:16:32 [TabAtkins]
- bramus: they'll work as if done natively
- 12:16:43 [TabAtkins]
- bramus: so if you ask getComputedStyle().size, it can show up
- 12:16:48 [TabAtkins]
- bramus: that's the idea, at least
- 12:17:08 [TabAtkins]
- bramus: and benefits for impls, allows faster adoption, prototype in the browser, get early feedback from authors
- 12:17:43 [TabAtkins]
- bramus: back to the support timeline, can move the adoption from "widely available" to "first shipped", maybe even before
- 12:17:48 [TabAtkins]
- bramus: of course there are risks and caveats
- 12:17:52 [TabAtkins]
- bramus: need to carefully think about timing
- 12:17:59 [TabAtkins]
- bramus: don't execute blocking JS in the middle of layout
- 12:18:13 [TabAtkins]
- bramus: flackr thought maybe model it after intersection observer
- 12:18:24 [TabAtkins]
- bramus: also don't want SmooshGate, early polyfill poisoning a name
- 12:18:33 [TabAtkins]
- bramus: thought is polyfill wins even if the feature is supported
- 12:18:49 [TabAtkins]
- bramus: this also needs buy-in from all browsers
- 12:18:59 [TabAtkins]
- bramus: if not everyone adopts it, it's not useful for the purpose
- 12:19:09 [TabAtkins]
- bramus: and not all features can be polyfilled, of course
- 12:19:20 [TabAtkins]
- bramus: VTs wouldn't be doable well. but a lot can be
- 12:19:29 [emilio]
- q+
- 12:19:30 [oriol]
- q+
- 12:19:31 [SebastianZ]
- q+
- 12:19:44 [astearns]
- ack TabAtkins
- 12:19:55 [emilio]
- TabAtkins: chatted with bramus about this either
- 12:20:09 [emilio]
- ... most where all things map really well to existing / upcoming custom specs
- 12:20:27 [bkardell]
- q+
- 12:20:30 [emilio]
- ... e.g. all the polyfilled values can be treated after the hook can be a custom js function
- 12:20:33 [romain]
- q+
- 12:20:51 [emilio]
- ... mixing as well, it's a native-looking syntax that could call into JS
- 12:21:00 [emilio]
- ... custom supports / custom media queries...
- 12:21:09 [andreubotella]
- andreubotella has joined #css
- 12:21:14 [andreubotella]
- q?
- 12:21:22 [emilio]
- ... anything can be done with some of these custom CSS, there's more complexity when JS is involved
- 12:21:29 [emilio]
- ... but that is workable
- 12:21:41 [emilio]
- ... I want to make sure that we make it inconvenient to conditionally load these
- 12:21:50 [emilio]
- ... smooshgate is really frustrating
- 12:22:05 [emilio]
- ... [provides context for smooshgate]
- 12:22:13 [bramus]
- https://developer.chrome.com/blog/smooshgate
- 12:22:42 [bkardell]
- https://www.w3.org/2001/tag/doc/polyfills/
- 12:22:45 [emilio]
- ... we need to make it inconvenient to load the polyfill conditionally
- 12:23:02 [emilio]
- ... as long as we can make that happen I think this is a more convenient approach for custom stuff
- 12:23:19 [emilio]
- ... encouraging us to hook the JS backed versions of things
- 12:23:23 [astearns]
- ack astearns
- 12:23:32 [emilio]
- ... but generally +1
- 12:23:37 [flackr]
- flackr has joined #css
- 12:23:38 [TabAtkins]
- astearns: i'm skeptical there will be a way to disallow conditional loading these things
- 12:23:47 [flackr]
- present+
- 12:23:49 [TabAtkins]
- astearns: I note that a lot of the collecting/parsing is already present in custom props
- 12:24:16 [TabAtkins]
- astearns: if we said the only way to use these is custom props that mimics the new feature, and to turn it off requires removing the prefix, that's a way of guaranteeing we don't get into smooshgate
- 12:24:24 [astearns]
- ack lea
- 12:24:32 [ydaniv]
- q+
- 12:24:39 [TabAtkins]
- lea: huge +1 to making this easier. tried to write polyfills in the past, can attest all the problems are true, maybe even worse than stated
- 12:24:47 [TabAtkins]
- lea: i'm also skeptical of conditional loading
- 12:25:01 [TabAtkins]
- lea: you *want* to use the native impls for a variety of reasons, it's more performant/correct/accessible
- 12:25:02 [ydaniv]
- +1111 to lea
- 12:25:16 [TabAtkins]
- lea: so I think telling authors to not do it won't work. authors can always do CSS.supports()
- 12:25:21 [TabAtkins]
- (I do have some ideas.)
- 12:25:32 [TabAtkins]
- lea: but also, SmooshGate is a bit of an isolated incident
- 12:25:48 [TabAtkins]
- lea: timing is a big issue for me. if you have to register before CSS runs or you lose them, that's an issue
- 12:25:54 [TabAtkins]
- lea: JS is often loaded async
- 12:26:02 [TabAtkins]
- (my ideas also address that, lol)
- 12:26:03 [ntim]
- I'm skeptical of anything that touches the syntax space of native keywords/values/properties. I'd much rather have folks use custom properties and associate custom behaviors to them... For custom values, maybe there's something around functions that could be used
- 12:26:05 [andreubotella]
- q+
- 12:26:07 [TabAtkins]
- lea: presumably browsers have to parse it all anyway
- 12:26:17 [TabAtkins]
- lea: what if you had access to the structure thru a parallel CSSOM?
- 12:26:21 [TabAtkins]
- lea: just throwing out ideas
- 12:26:24 [astearns]
- zakim, close queue
- 12:26:24 [Zakim]
- ok, astearns, the speaker queue is closed
- 12:26:35 [TabAtkins]
- lea: I do like the idea of teaching parser new tricks
- 12:26:54 [TabAtkins]
- lea: it looks like teaching tricks and doing invalidation, etc, are all coupled. makes it a big piece of work. can we decouple?
- 12:27:16 [TabAtkins]
- lea: first, parsing. invalidation in a different primitive - requests for a style observer
- 12:27:27 [TabAtkins]
- lea: what if we could solve that, then polyfill authors could observe property changes?
- 12:27:43 [TabAtkins]
- lea: all of these improve polyfills individually, dont' need to wait for the whole api
- 12:27:59 [TabAtkins]
- lea: similarly, selector matching etc are all needed individually
- 12:28:11 [TabAtkins]
- astearns: I've closed the queue due to over time box, but let's drain queue
- 12:28:12 [astearns]
- ack emilio
- 12:28:46 [TabAtkins]
- emilio: the two big concerns that come to mind are, if you run it from the parser (you kinda need to know what's registered to not discard it), that means you need to wait on Js execution ot parse CSS on the page
- 12:28:50 [TabAtkins]
- emilio: seems like a non-goal to me
- 12:29:04 [TabAtkins]
- emilio: browsers aggressively parse on seeing CSS in markup today
- 12:29:20 [TabAtkins]
- bramus: the logic that was mentioned - onMatch, compute to... not run as part of parsing
- 12:29:27 [TabAtkins]
- bramus: what you need in parsing is the name
- 12:29:32 [TabAtkins]
- emilio: right, need to register the name somehow
- 12:29:46 [TabAtkins]
- bramus: yeah, registration needs to be done way up front somehow
- 12:29:58 [ntim]
- +1 to emilio's concerns
- 12:29:58 [TabAtkins]
- emilio: but you still need to download the registration script ahead of time
- 12:30:05 [TabAtkins]
- emilio: so I think the registration needs to move to css
- 12:30:34 [TabAtkins]
- TabAtkins: that's my exact idea btw - also helps make conditional loading more difficult
- 12:30:51 [TabAtkins]
- emilio: yeah. declaration needs to be independent, stylesheets are shared across documents
- 12:31:08 [TabAtkins]
- bramus: yeah, Tab had similar feedback
- 12:31:18 [TabAtkins]
- emilio: the other stuff seems workable
- 12:31:27 [TabAtkins]
- emilio: tricky to get to a good state, but doable
- 12:31:30 [astearns]
- ack oriol
- 12:31:31 [TabAtkins]
- emilio: agree with the difficulties
- 12:31:39 [TabAtkins]
- oriol: I agree it could be useful
- 12:31:59 [TabAtkins]
- oriol: my concerns, one is - you were just giving an idea, not a specific syntax, but there are properties who compute based on other properties
- 12:32:04 [TabAtkins]
- oriol: or other info like elements is replaced
- 12:32:12 [TabAtkins]
- oriol: you need to resolve these all in a certain way, a certain order
- 12:32:14 [TabAtkins]
- oriol: it's complex
- 12:32:30 [TabAtkins]
- oriol: even if we design an API that could cover this, I worry in the future we might add something not covered well
- 12:32:43 [TabAtkins]
- oriol: adding the polyfill system is a lot of work - if we do it, it should keep working
- 12:32:53 [TabAtkins]
- oriol: second is, in general terms, worry about perf
- 12:33:02 [ntim]
- +1 about perf concerns
- 12:33:17 [TabAtkins]
- oriol: the SmooshGate problem, I understand it. if the browser supports a property having to keep using a polyfill, that's a little sad
- 12:33:21 [lea]
- it's common for polyfills to be slower, that's _why_ they fall back to the native implementation
- 12:33:33 [lea]
- as long as they are faster than a corresponding JS API, we're good
- 12:33:35 [TabAtkins]
- bramus: yeah, the concerns being listed, performance, not painted us into a corner; we def need to think about these
- 12:33:36 [astearns]
- ack SebastianZ
- 12:33:46 [SebastianZ]
- https://drafts.css-houdini.org/css-parser-api/
- 12:33:55 [TabAtkins]
- SebastianZ: Bramus obviously mapped out the CSS parser API, already in the Houdini repo
- 12:33:59 [TabAtkins]
- TabAtkins: not really, is empty
- 12:34:00 [ntim]
- There's a potential for perf concerns even in cases where no extension is registered
- 12:34:07 [TabAtkins]
- SebastianZ: I do like the idea, but am concerned about perf
- 12:34:27 [TabAtkins]
- SebastianZ: when you have several polyfills, they all have to load/parse/etc everything
- 12:34:34 [TabAtkins]
- SebastianZ: so perf wise it would be much better to have it in the browser
- 12:34:40 [andreubotella]
- q-
- 12:34:47 [TabAtkins]
- bramus: yeah, would allow multiple polyfills to load at the same time, and one could depend on another
- 12:34:59 [TabAtkins]
- SebastianZ: it would also always be up to date with browser syntax
- 12:35:22 [TabAtkins]
- SebastianZ: regarding inclusion of polyfill, maybe that could be handled by providing an MQ attribute for scripts?
- 12:35:29 [TabAtkins]
- SebastianZ: so you could query if a feature is already available in browser?
- 12:35:36 [ydaniv]
- ydaniv has joined #css
- 12:35:57 [TabAtkins]
- TabAtkins: that's @supports?
- 12:36:04 [TabAtkins]
- SebastianZ: Yes, but to control conditional loading of the scrip titself
- 12:36:22 [TabAtkins]
- bramus: maybe also should explore Workers. But logic often needs certain Dom elements
- 12:36:27 [astearns]
- ack bkardell
- 12:36:27 [TabAtkins]
- bramus: kinda difficult
- 12:36:31 [bkardell]
- Just a few notes: We talked briefly about adding an UnknownProperty/Value idea for values at least in 2011 https://lists.w3.org/Archives/Public/www-style/2011Jul/0469.html - Still like that idea too... I recall because I was building a polyfill system and frustrated by this and it's an instigator of what got me into standards, etc - and I think a lot of the driver for we wound up with general rules about "custom things" and Houdini.. Also
- 12:36:31 [bkardell]
- wanted to note the TAG finding I linked above
- 12:36:35 [TabAtkins]
- bkardell: I typed some comments
- 12:36:51 [TabAtkins]
- bkardell: we talked about it back in 2011 when I was building a polyfill
- 12:37:15 [TabAtkins]
- bkardell: this led to some ideas that turned into all our custom things, and Houdini
- 12:37:27 [dmangal]
- dmangal has joined #css
- 12:37:38 [TabAtkins]
- bkardell: we've had a lot more history and precedent and thought, and think Houdini chose some first topics poorly
- 12:37:45 [TabAtkins]
- bkardell: I think this is still a problem tho
- 12:37:51 [TabAtkins]
- bkardell: I also point to the TAG finding, above
- 12:37:54 [astearns]
- ack romain
- 12:38:06 [TabAtkins]
- romain: thanks for raising, also interested
- 12:38:16 [TabAtkins]
- romain: some things I noticed, parsing/cascade is an issue, but also individual issues
- 12:38:26 [TabAtkins]
- romain: 'size' is relatively simple, just a keyworde or number
- 12:38:43 [TabAtkins]
- romain: but complex values like RCS, those should already be parsed by the browser
- 12:39:07 [TabAtkins]
- romain: a concern, then, is the API made of low-level things, you have forward-compat issues
- 12:39:12 [TabAtkins]
- romain: you cna't reinvent too much
- 12:39:29 [TabAtkins]
- romain: like with Nesting, parsing details changed. tokenizer sometimes changes. not exposed API right now, have some freedom, but if it's exposed it has to be stable
- 12:39:40 [astearns]
- ack ydaniv
- 12:39:40 [TabAtkins]
- romain: but I am excited about thi
- 12:39:56 [TabAtkins]
- ydaniv: i'll avoid repeating things.
- 12:40:03 [TabAtkins]
- ydaniv: but I think it is important to use the native thing when it exists
- 12:40:21 [TabAtkins]
- ydaniv: you can check with @supports, can be nice it put the condition into HTML also
- 12:40:33 [TabAtkins]
- bramus: one thing you can already do is put CSS.supports() in JS
- 12:40:49 [TabAtkins]
- bramus: one thing I haven't covered, maybe there's a list being tracked for which properties/functions/etc have been registered
- 12:40:58 [TabAtkins]
- bramus: so you can load something only if it's not already registered
- 12:41:18 [TabAtkins]
- bramus: but yeah, we want to discourage conditional loading unless it's certain it matches
- 12:41:30 [TabAtkins]
- astearns: so every polyfill should have wpt results :p
- 12:41:38 [TabAtkins]
- bramus: wpt does have support for loading a polyfill!
- 12:41:56 [TabAtkins]
- astearns: we should close the discussion
- 12:42:03 [ntim]
- I'm not excited about allowing expanding the native syntax space
- 12:42:08 [TabAtkins]
- bramus: maybe a resolution to explore the problem?
- 12:42:40 [TabAtkins]
- astearns: given the scattered reservations about every part of the presentation, don't think we can take a resolution today. but i'm excited
- 12:43:01 [fantasai]
- TabAtkins: There's somebody objecting to every part of it right now
- 12:43:21 [TabAtkins]
- bramus: thanks!
- 12:43:35 [TabAtkins]
- astearns: break until top of the hour, then breakout sessions.
- 12:56:39 [iank_]
- emilio - you've got at least 2 issues.
- 12:57:47 [iank_]
- 1. The canvas in the initial render shouldn't have any aspect-ratio, and it just has an intrinsic-size which it falls back to.
- 12:58:44 [iank_]
- eh maybe 1 isn't true.
- 12:58:49 [iank_]
- i'd need to look.
- 12:59:06 [iank_]
- but resolving the percent height is very strange.
- 12:59:35 [iank_]
- its changing the definiteness of the flex-item between passes.
- 12:59:39 [iank_]
- (somehow)
- 13:00:30 [emilio]
- iank_: https://bug1965480.bmoattachments.org/attachment.cgi?id=9508468 resizes in chrome too, fwiw
- 13:01:36 [kizu]
- kizu has joined #css
- 13:02:12 [dholbert]
- dholbert has joined #css
- 13:02:33 [ydaniv]
- ydaniv has joined #css
- 13:02:34 [iank_]
- emilio - i think in that case the definiteness is changing.
- 13:02:57 [dholbert]
- present+
- 13:03:52 [iank_]
- (the measure is taking into account the line-box height, then the percentage resolves to the height of the containing-block in the next pass)
- 13:04:25 [TabAtkins]
- (we'll use #houdini for the breakout again)
- 13:04:27 [fantasai]
- fantasai has joined #css
- 13:05:12 [kbabbitt]
- can the side conversation move out of the room? I can't tell what's going on
- 13:06:21 [fantasai]
- Topic: Layout
- 13:06:27 [github-bot]
- Subtopic: [css-anchor-position] Invalidation of last successful position option in cases not in the spec
- 13:07:00 [astearns]
- fantasai: please use #houdini
- 13:07:31 [TabAtkins]
- lol
- 13:07:31 [fantasai]
- Topic: Pointer Animations
- 13:08:17 [andreubotella]
- andreubotella has joined #css
- 13:08:33 [astearns]
- github-bot, subtopic https://github.com/w3c/csswg-drafts/issues/12396
- 13:08:33 [github-bot]
- Subtopic: [pointer-animations-1] Use padding edges as timeline range for pointer timelines
- 13:08:33 [github-bot]
- OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12396.
- 13:08:45 [kbabbitt]
- scribe+ kbabbitt
- 13:08:59 [kbabbitt]
- ydaniv: pointer animations is now an ED
- 13:09:03 [ydaniv]
- https://drafts.csswg.org/pointer-animations-1/
- 13:09:06 [kbabbitt]
- ... link ^
- 13:09:21 [kbabbitt]
- ... basically the gist is that it adds pointer timelines
- 13:09:31 [kbabbitt]
- ... biulding on top of existing idea of view timeline for scroll animations
- 13:09:42 [kbabbitt]
- ... but making ranges and other ideas more relevant for effects specific to pointer animatinos
- 13:09:48 [kbabbitt]
- ... so the 3 issues we have here are
- 13:10:00 [kbabbitt]
- ... around creating the timeline, the ranges, and the interpolation for the timeline
- 13:10:12 [kbabbitt]
- ... basically properties which help you specify and control these aspects
- 13:10:29 [kbabbitt]
- ... the spec is there, everything is there, but I wanted to flesh out the most concrete issues from the spec
- 13:10:35 [kbabbitt]
- ... and have them discussed in the group
- 13:10:46 [kbabbitt]
- ... could just present and have people comment on issues so we can resolve or reach better design
- 13:10:49 [kbabbitt]
- .... and move forward to WD
- 13:10:59 [kbabbitt]
- ... first issue is about how we define the timeline
- 13:11:10 [kbabbitt]
- ... for scroll animations your full timeline is always the full sroll of your scroll container
- 13:11:23 [kbabbitt]
- ... with pointer timelines your timeline can be either an element, in this case the issue is about using padding edges
- 13:11:29 [kbabbitt]
- ... of the principal box of that element
- 13:11:41 [kbabbitt]
- ... so if the timeline could be either an element or the root
- 13:11:44 [kbabbitt]
- ... root means entire viewport
- 13:11:51 [kbabbitt]
- ... if it's an element then use the principal box of that element
- 13:11:56 [kbabbitt]
- ... using same concept as pointer events
- 13:12:03 [kbabbitt]
- ... as in offset x and offset y of pointer events
- 13:12:06 [kbabbitt]
- ... specified in cssom view 1
- 13:12:11 [flackr]
- q+
- 13:12:14 [kbabbitt]
- ... using the padding edge, start, and end for entire timeline
- 13:12:25 [kbabbitt]
- ... this is alrady in the spec, this is the formal proposal
- 13:12:37 [astearns]
- zakim, open queue
- 13:12:37 [Zakim]
- ok, astearns, the speaker queue is open
- 13:12:42 [kbabbitt]
- flackr: why do we use the padding edges?
- 13:12:53 [kbabbitt]
- ... isnt' it typical to give offsets from border box edges?
- 13:13:00 [kbabbitt]
- ydaniv: this is to be consistent wuith pointer events
- 13:13:01 [astearns]
- https://www.w3.org/TR/cssom-view-1/#dom-mouseevent-offsetx uses padding edge
- 13:13:02 [kbabbitt]
- flackr: ok
- 13:13:10 [kbabbitt]
- ydaniv: pointer-events also use padding edges, we use same model
- 13:13:11 [SebastianZ]
- q+
- 13:13:22 [kbabbitt]
- ... I have it in the issue, I think it's offset-x and offset-y
- 13:13:25 [kbabbitt]
- flackr: looking at it now
- 13:13:26 [dmangal8]
- dmangal8 has joined #css
- 13:13:41 [kbabbitt]
- ydaniv: if someone needs to polyfill this, for example WIX is doing now, this just keeps working as is
- 13:13:53 [kbabbitt]
- ... of course there are some discrepanciew there because I think webkit ignore borders
- 13:14:04 [Ragvesh]
- Ragvesh has joined #css
- 13:14:04 [kbabbitt]
- ... I think other browsers .. there's some discrepancies but this is in the spec
- 13:14:34 [kbabbitt]
- flackr: what about on the root? would it be relative to viewport or document origin which would be way above the otp of viewport?
- 13:14:42 [kbabbitt]
- ydaniv: root uses the viewport
- 13:14:46 [kbabbitt]
- flackr: or both
- 13:14:50 [kbabbitt]
- ... for pointer events and pointer animations
- 13:14:54 [kbabbitt]
- s/or both/for both/
- 13:15:10 [kbabbitt]
- ydaniv: for pointer-events, if you take from the event
- 13:15:16 [kbabbitt]
- .... you also have an ability to take viewport from event
- 13:15:20 [kbabbitt]
- ... x and y relative to viewport
- 13:15:24 [kbabbitt]
- flackr: yes but that's a different property
- 13:15:38 [kbabbitt]
- ydaniv: yes, in case of using root as subject of the timeline, it uses
- 13:15:43 [kbabbitt]
- flackr: I think screen x and screen y
- 13:15:45 [kbabbitt]
- ydaniv: could be
- 13:15:58 [kbabbitt]
- ... again going exactly with what pointer-events do today
- 13:16:03 [kbabbitt]
- astearns: screen x and screen y is relative to screen
- 13:16:09 [kbabbitt]
- ... client x and client y are relative to viewport
- 13:16:14 [kbabbitt]
- ydaniv: yeah so client x and client y i this case
- 13:16:23 [kbabbitt]
- ... either that or offset also is aliased by x and y
- 13:16:27 [kbabbitt]
- astearns: client is aliased by x and y
- 13:16:39 [kbabbitt]
- astearns: flackr, any follow up?
- 13:16:42 [kbabbitt]
- flackr: no that's fine
- 13:16:46 [astearns]
- ack SebastianZ
- 13:16:49 [kbabbitt]
- SebastianZ: I see it's in the issue but want to iterate on that
- 13:17:00 [kbabbitt]
- ... I think it makes sense to have them applying to pdding edges
- 13:17:08 [kbabbitt]
- ... but we could extend to other edges if necessary via new prop
- 13:17:22 [kbabbitt]
- ydaniv: yes idea is to default to same as pointer-events, could also add another property if you want to choose another box
- 13:17:27 [kbabbitt]
- ... that can be separate issue to extend spec
- 13:17:34 [kbabbitt]
- astearns: lacking particular use cases it wouldn't have to be in first version
- 13:17:35 [kbabbitt]
- ydaniv: yeah
- 13:17:41 [kbabbitt]
- SebastianZ: sounds like we could resolve on that?
- 13:18:03 [kbabbitt]
- astearns: Proposed resolution is that the pointer-event timeline uses the padding edges by default to match pointer events
- 13:18:15 [kbabbitt]
- flackr: Is the implication here that 0-100% for the range of animation is the padding box?
- 13:18:33 [kbabbitt]
- ... when you make a pointer animation for an element, this decision we're making implies that top left position of animation is the padding box edge
- 13:18:44 [kbabbitt]
- ... is the idea that by default pointer animation maps to padding box?
- 13:18:54 [kbabbitt]
- SebastianZ: padding box is frame for pointer animation timeline
- 13:19:05 [kbabbitt]
- flackr: ok, just wantd to clarify
- 13:19:07 [kbabbitt]
- ... numbers themselves don't matter much once you get through timeline conversion
- 13:19:12 [kbabbitt]
- ... this is about basically pointer animation
- 13:19:15 [kbabbitt]
- ydaniv: thi sis the full timeline
- 13:19:25 [kbabbitt]
- flackr: one thing that's confusing about this is it doesn't match hover by default
- 13:19:28 [kbabbitt]
- astearns: ah
- 13:19:31 [kbabbitt]
- ... what box does hover use?
- 13:19:34 [kbabbitt]
- flackr: border box I believe
- 13:19:48 [kbabbitt]
- ydaniv: I think that's okay because hover is used for completely different effects
- 13:19:52 [kbabbitt]
- ... more important to be consistent with pointer events
- 13:19:57 [kbabbitt]
- flackr: don't know if iI'd say that's true
- 13:20:02 [kbabbitt]
- ... you still get pointer events even over border box
- 13:20:08 [kbabbitt]
- ... they would just have negative offset X and Y
- 13:20:17 [kbabbitt]
- ... but it's still the target of the event so a dev handling those events would still see them
- 13:20:25 [kbabbitt]
- ydaniv: ok
- 13:20:37 [bramus]
- can confirm that :hover uses the border-box
- 13:20:43 [kbabbitt]
- astearns: can you handle negative and more than 100 values in pointer animation?
- 13:20:52 [kbabbitt]
- flackr: we do this in view timeline already
- 13:20:58 [kbabbitt]
- ... default range of view timeline is cover range
- 13:21:04 [kbabbitt]
- ... but you can create animations that extend beyond element's cover range
- 13:21:09 [kbabbitt]
- ydaniv: ranges yes but full timeline
- 13:21:14 [kbabbitt]
- flackr: it's still active outside cover trange
- 13:21:19 [kbabbitt]
- ... so it has negatives in view timeline
- 13:21:27 [kbabbitt]
- SebastianZ: just tested it is the border box for hovering
- 13:21:43 [kbabbitt]
- bramus: for view time line you can indeed go outside cover range
- 13:21:48 [kbabbitt]
- ... for scroll time do we allow?
- 13:21:54 [kbabbitt]
- flackr: there is no such thing as negative scroll offset
- 13:21:59 [kbabbitt]
- bramus: in blink yes but in webkit?
- 13:22:09 [kbabbitt]
- flackr: it wouldn't be exposed but we would still want timeline to be active in that case
- 13:22:23 [kbabbitt]
- ... I think there's more of a dev expectation for this to match event targeting and hover than offset x and offset y
- 13:22:28 [kbabbitt]
- ... I could be mistaken
- 13:22:35 [kbabbitt]
- ydaniv: very different family of effects
- 13:22:44 [kbabbitt]
- ... like micro interactions and full blown pointer animations
- 13:22:52 [kbabbitt]
- ... usually for hover you have just simple translations
- 13:23:11 [kbabbitt]
- flackr: what I'm worred about is dev adding effect on hover and assuming that when hover is active pointer animation is also active
- 13:23:20 [kbabbitt]
- bramus: I would also expect pointer timing to be active when I start hovering element from border
- 13:23:38 [kbabbitt]
- astearns: you had mentioned ydaniv that one of your considerations was that you would want to be able to polyfill this using mouse events
- 13:23:40 [kbabbitt]
- ydaniv: yes
- 13:24:02 [kbabbitt]
- astearns: if we decided timeline range was over border box, it would still have mouse events you could handle, would just have negative and >100 values you would have to adjust to fit this other extent
- 13:24:03 [kbabbitt]
- ydaniv: yes
- 13:24:14 [kbabbitt]
- ... there's a bunch of inconsistencies and bugs between browsers regarding pointer events
- 13:24:25 [kbabbitt]
- ... most of them only surface when you use synthetic events for pointer events
- 13:24:33 [kbabbitt]
- ... some in chrome some in webkit
- 13:24:47 [kbabbitt]
- ... I guess that I can surface all of those maybe we can also try to fix them as we start to ship this
- 13:25:00 [kbabbitt]
- ... so once people try to polyfill this, they also have more consistent way to polyfill this
- 13:25:13 [kbabbitt]
- astearns: just wanted to make sure it would be possible, author expectations trump polyfill expectations
- 13:25:22 [kbabbitt]
- ydaniv: maybe this requires more research to see if it can be properly polyfilled
- 13:25:30 [kbabbitt]
- astearns: we could resolve that pointer progress timeline usees border box
- 13:25:34 [kbabbitt]
- ... and then you could do that research
- 13:25:47 [kbabbitt]
- ... or we could leave this wihtout resolution until you've done that research
- 13:26:04 [kbabbitt]
- ydaniv: I'm good either way, this is still early stage
- 13:26:08 [kbabbitt]
- SebastianZ: I would vote for border box
- 13:26:22 [kbabbitt]
- ydaniv: we can start with border box and if I find there's a big issue with polyfilling we can raise discussion again
- 13:26:45 [kbabbitt]
- astearns: I would expect research to include both polyfilling and working through use cases to show author expectation for this or that effect is satisfied or not by using border box
- 13:26:59 [kbabbitt]
- ... so we have a proposed resolution to define the pointer progress timeline to use the border box extent
- 13:27:02 [kbabbitt]
- ... objections?
- 13:27:13 [kbabbitt]
- RESOLVED: Pointer progress timeline uses the border box extent
- 13:27:26 [astearns]
- github-bot, subtopic https://github.com/w3c/csswg-drafts/issues/12471
- 13:27:26 [github-bot]
- Subtopic: [pointer-animations-1] Animation range centering
- 13:27:26 [github-bot]
- OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12471.
- 13:27:39 [kbabbitt]
- ydaniv: second issue is about a new concept for range centering
- 13:27:47 [kbabbitt]
- ... that is very common for pointer effects, pointer animations
- 13:28:03 [kbabbitt]
- ... because usually the effects timeline goes from 1 to 0 in 50% progress and then back to 1
- 13:28:07 [kbabbitt]
- ... or -1 to 0 and then to 1
- 13:28:22 [kbabbitt]
- ... so you have sort of symmetry or reverse symmetry in the effects usually
- 13:28:32 [kbabbitt]
- ... and what you usually want to do is specify where is the focal point of the effect
- 13:28:36 [kbabbitt]
- ... where is the 50% progress of the timeline
- 13:28:45 [kbabbitt]
- ... so that the effect gets sync'ed to that 50% progress
- 13:28:57 [kbabbitt]
- ... and so the order of operations is that you have the full timeline and then you center it
- 13:29:02 [kbabbitt]
- ... and then you apply the ranges
- 13:29:05 [kbabbitt]
- ... which is the next topic
- 13:29:09 [kbabbitt]
- ... this is first about centering
- 13:29:18 [kbabbitt]
- ... what pointer animations introduce is first that animation range center
- 13:29:23 [SebastianZ]
- q+
- 13:29:24 [kbabbitt]
- ... subproperty that allows you to center the range
- 13:29:28 [kbabbitt]
- ... or define center of timeline
- 13:29:39 [kbabbitt]
- ... and that by default is relative to the source of the timeline
- 13:29:42 [kbabbitt]
- ... element or viewport
- 13:29:51 [kbabbitt]
- ... but you can also specify that this is done relative to target element of animation
- 13:30:02 [kbabbitt]
- ... so you have a length-percentage to define the centering and also a keyword to say source or target
- 13:30:10 [kbabbitt]
- ... this is also very common to pointer animations
- 13:30:16 [kbabbitt]
- ... where you could have 1 element that defines range
- 13:30:18 [kbabbitt]
- ... say a whole section
- 13:30:22 [kbabbitt]
- ... could take full viewport
- 13:30:28 [kbabbitt]
- ... and you want the timeline to span the entire section
- 13:30:37 [kbabbitt]
- ... but you want the effect on let's say 1 image in that section
- 13:30:48 [kbabbitt]
- ... you want effect to center when pointer is centered on that image
- 13:30:53 [kbabbitt]
- ... but have 100% span entirety of section
- 13:30:55 [kbabbitt]
- ... or to other side
- 13:31:08 [flackr]
- q+
- 13:31:09 [kbabbitt]
- ... so this is basically the proposal
- 13:31:17 [kbabbitt]
- ... to add this to the spec and add animation-range-centered property
- 13:31:24 [kbabbitt]
- ... which takes length-percentage and keyword source or target
- 13:31:27 [kbabbitt]
- ... defaults to source
- 13:31:32 [kbabbitt]
- ... the length-percentage defaults t 50%
- 13:31:40 [kbabbitt]
- ... so if you omit this it just uses the middle point of the timeline
- 13:31:47 [kbabbitt]
- ... and you can just say target and it will use center of target
- 13:31:49 [astearns]
- ack SebastianZ
- 13:31:59 [kbabbitt]
- SebastianZ: thinking about that I was actually thinking about an origin
- 13:32:03 [kbabbitt]
- ... like we have for transform-origin
- 13:32:15 [kbabbitt]
- ... so it would basically be the same but I would name it like animation-range-origin
- 13:32:20 [kbabbitt]
- ... and mimic something like transform-origin
- 13:32:37 [kbabbitt]
- ... my idea was to reuse the position data type
- 13:32:43 [kbabbitt]
- ydaniv: the thing is we specify where the 50% progress goes
- 13:32:49 [kbabbitt]
- ... where do we have 50% progress
- 13:32:53 [kbabbitt]
- ... we already have range-start and range end
- 13:32:55 [kbabbitt]
- ... adding range origin
- 13:33:04 [kbabbitt]
- SebastianZ; yes, range origin will just say where you put the origin of your range
- 13:33:07 [kbabbitt]
- ... could be negative
- 13:33:11 [kbabbitt]
- ydaniv: it's not 0, oit
- 13:33:15 [kbabbitt]
- ... 's 50%
- 13:33:23 [kbabbitt]
- ... though we have symmetry, sometimes reversed symmetry
- 13:33:28 [kbabbitt]
- SebastianZ: still inclined to call it origin
- 13:33:32 [kbabbitt]
- ydaniv: open to bikeshedding
- 13:33:39 [kbabbitt]
- SebastianZ; maybe another name pointing out focal point of animation
- 13:33:45 [kbabbitt]
- ... then use position value for that
- 13:33:50 [kbabbitt]
- ... and keyword for saying source or target
- 13:33:56 [kbabbitt]
- astearns: I have reservations about both of those ideas
- 13:33:58 [astearns]
- ack flackr
- 13:34:04 [kbabbitt]
- flackr: question also a concern
- 13:34:16 [kbabbitt]
- ... if you have a target that's not 50%, is the animation you get asymmetric?
- 13:34:17 [dmangal8]
- dmangal8 has left #css
- 13:34:20 [kbabbitt]
- ... faster on one side slower on other?
- 13:34:24 [kbabbitt]
- ydaniv: something that you then control with ranges
- 13:34:28 [dmangal]
- dmangal has joined #css
- 13:34:31 [kbabbitt]
- flackr: but what if I don't set any ranges?
- 13:34:38 [kbabbitt]
- ... centering implies that you're shifting
- 13:34:44 [kbabbitt]
- ydaniv: depends on default pf ranges. tjat
- 13:34:48 [kbabbitt]
- ... 's next issue
- 13:34:58 [kbabbitt]
- ... if we use fit range by default, it will take full size of timeline and just shift it
- 13:35:00 [kbabbitt]
- ... you'll still have
- 13:35:06 [kbabbitt]
- flackr: so they still move at same rate on either side of target
- 13:35:15 [kbabbitt]
- ydaniv: yes, different values different ranges to keep interpolation similar on both suides
- 13:35:21 [kbabbitt]
- ... there's another one that allows you to squish it
- 13:35:26 [kbabbitt]
- flackr: ok I;ll have to think about it more
- 13:35:38 [kbabbitt]
- ... concern is, if you have a single pointer timeline A< and its being used by 2 elements B and C
- 13:35:43 [kbabbitt]
- ... and you specify that the center is the target
- 13:35:53 [kbabbitt]
- ... then you've set up a situtation where the current time is different for both elements/
- 13:36:05 [kbabbitt]
- ... it feels as if you're putting a propertuy in thetimeline that belongs on the animating target
- 13:36:11 [kbabbitt]
- ydaniv: no, centering goes on animating target
- 13:36:17 [kbabbitt]
- flackr: oh I see, animation range center ok
- 13:36:24 [kbabbitt]
- ... ok I understand now other issue you mentioned
- 13:36:31 [kbabbitt]
- ... this is setting range usedby that animation
- 13:36:39 [kbabbitt]
- ... to be based around that target's position with respect to pointer animation
- 13:36:43 [kbabbitt]
- ydaniv: think about a list of cards
- 13:36:56 [kbabbitt]
- ... and all of them use
- 13:37:05 [kbabbitt]
- ... viewport or container as timeline
- 13:37:11 [kbabbitt]
- ... each one of them you want to rotate around Y
- 13:37:21 [kbabbitt]
- ... and you want each of them to rotate according to position of the pointer
- 13:37:27 [kbabbitt]
- ... around that container
- 13:37:39 [kbabbitt]
- ... but each should center when the pointer reaches their own center
- 13:37:49 [kbabbitt]
- ... then they all have the same effect, same animation, same ranges
- 13:37:52 [kbabbitt]
- ... it just works
- 13:38:03 [kbabbitt]
- ... as you hover across them, they all turn towards you or away depending on effect
- 13:38:09 [kbabbitt]
- ... as you go on center of each, each completely faces you
- 13:38:11 [kbabbitt]
- ... just works out
- 13:38:18 [kbabbitt]
- ... this is how pointer effects usually are created
- 13:38:30 [kbabbitt]
- astearns: thanks for that. are there other timelines that have this center concept?
- 13:38:30 [kbabbitt]
- ydaniv: no
- 13:38:39 [kbabbitt]
- astearns: this is new for pointer timelines
- 13:38:46 [kbabbitt]
- flackr: this wouldn't have a meaning for other timelines which is okay I guess
- 13:38:56 [kbabbitt]
- SebastianZ: astearns you raised concerns about my point/
- 13:39:06 [kbabbitt]
- astearns: set of position values used for background positioning
- 13:39:08 [kbabbitt]
- ... have detractors
- 13:39:14 [kbabbitt]
- ... there are people who don't like them
- 13:39:29 [kbabbitt]
- ... I think this is much simpler since we're only talking about a single distance along a known range
- 13:39:47 [kbabbitt]
- ... I think it's simpler and better to use a single length-percentage than to reuse position values
- 13:39:58 [kbabbitt]
- flackr: the other thing I though tmight be worth mentioning in context of origin discussoin
- 13:40:02 [kbabbitt]
- ... we don't have to limit animations to 0-100%
- 13:40:08 [kbabbitt]
- ... we could say that setting this origin property is the 0 point
- 13:40:18 [kbabbitt]
- ... but the animation range goes negative to positive
- 13:40:25 [kbabbitt]
- SebastianZ: did we already take a photo?
- 13:40:45 [kbabbitt]
- [referring to previous discussion]
- 13:41:12 [kbabbitt]
- ydaniv: idea was to map this to existing ... the way keyframes and animations work today
- 13:41:26 [kbabbitt]
- ... and still be able to specify these effects in intuitive form
- 13:41:31 [kbabbitt]
- ... and still allow centyering
- 13:41:36 [kbabbitt]
- flackr: would 0% being the center be more intuitive?
- 13:41:44 [kbabbitt]
- ... we've already allowed keyframes outside 0-100% for view timelines
- 13:41:52 [kbabbitt]
- ... because you specify these things relative to offsets of the element
- 13:42:04 [kbabbitt]
- ... and you can't guarantee that uathor doesn't specify things outside that range so we've allowed it to work
- 13:42:16 [kbabbitt]
- ... this could be a case where it makes sense to embrace this, you can have n egative % on keyframes
- 13:42:18 [kbabbitt]
- ydaniv: could work for soe effects
- 13:42:26 [kbabbitt]
- ... have to specify what happens wen you go below 0
- 13:42:32 [kbabbitt]
- ... rotation maybe you wnt ot go to -1
- 13:42:40 [kbabbitt]
- ... other effects you want to mirror what you do
- 13:42:41 [kbabbitt]
- ... for example opacity
- 13:42:45 [kbabbitt]
- .. go back to 0 again
- 13:42:47 [kbabbitt]
- ... depends on effect
- 13:42:50 [kbabbitt]
- astearns: something you specify on ranges
- 13:42:55 [antonp]
- antonp has joined #css
- 13:42:59 [kbabbitt]
- ydaniv: this is specifyed on ranges and then you need to create an effect
- 13:43:16 [kbabbitt]
- ... if 0% is the center, for each effect you need to specify how going below 0 effects it
- 13:43:19 [kbabbitt]
- flackr: you'd have a -100% keyfrome or something like htat
- 13:43:29 [kbabbitt]
- ydaniv: yes and you'd have very specific effects taht aren't resuable
- 13:43:33 [kbabbitt]
- flackr: wouldn't make sense on time based animations
- 13:43:45 [kbabbitt]
- ... there are other future animations where values below 0 make a lot of sense
- 13:43:51 [kbabbitt]
- ... didn't want design to be constrained to only thinking about 0-100%
- 13:43:56 [kbabbitt]
- ... we can allow for negative values
- 13:44:01 [kbabbitt]
- ... if that's more intuitive we should consider
- 13:44:04 [kbabbitt]
- ydaniv: ok
- 13:44:15 [kbabbitt]
- ... also in the spec there's a proposal written how to write this in a shorthand
- 13:44:20 [kbabbitt]
- ... so it would look something like
- 13:44:28 [kbabbitt]
- ... the at keyword for example
- 13:44:28 [ydaniv]
- animation-range: cover at 50% target;
- 13:44:36 [kbabbitt]
- ... so you could have ^
- 13:44:46 [kbabbitt]
- ... taken this from syntax of gradients
- 13:44:54 [kbabbitt]
- flackr: I do like making it part of the animation range
- 13:44:56 [kbabbitt]
- ... property
- 13:45:07 [kbabbitt]
- ... because then at least it's not a property that only applies to pointer animations
- 13:45:14 [kbabbitt]
- ... even though the values only make sense for pointer animations
- 13:45:27 [ydaniv]
- q?
- 13:45:34 [kbabbitt]
- SebastianZ: still thinking about how this works and what use cases are
- 13:45:50 [kbabbitt]
- ... I'm currently implementing the area for the animation being the adding box
- 13:45:52 [kbabbitt]
- ydaniv: or border box
- 13:45:57 [kbabbitt]
- SebastianZ: or border box
- 13:46:13 [kbabbitt]
- ... and you have two different animation axis right?
- 13:46:14 [kbabbitt]
- ydaniv: yes
- 13:46:23 [kbabbitt]
- SebastianZ: so we're talking about animation range center right now
- 13:46:27 [kbabbitt]
- ... what are use cases for those?
- 13:46:33 [kbabbitt]
- ... we have 0% of the animation range when ???
- 13:46:46 [kbabbitt]
- ydaniv: [missed]
- 13:46:53 [kbabbitt]
- SebastianZ: what are use cases for changing cetner of animation range?
- 13:46:59 [kbabbitt]
- ydaniv: most use cases require centering
- 13:47:05 [kbabbitt]
- SebastianZ: like a parallax effect for example?
- 13:47:11 [kbabbitt]
- ydaniv: yes sometimes referred to as mouse parallax
- 13:47:19 [kbabbitt]
- ... a lot of the effect is that you have something like a card element
- 13:47:22 [kbabbitt]
- ... then it rotates with the pointer
- 13:47:34 [kbabbitt]
- ... so you want it to completely face you and not be rotated at all when you're centered on the card
- 13:47:42 [kbabbitt]
- ... sometimes you wat timeline to be card itself, sometimes container or entire viewport
- 13:47:51 [kbabbitt]
- ... and you still want to see effect ragartless of where you are
- 13:48:02 [kbabbitt]
- ... still wnt to keep center of effect which is 0deg rotation in this case
- 13:48:07 [kbabbitt]
- ... when pointer is cetnered on animation target
- 13:48:21 [kbabbitt]
- astearns; I think SebastianZ was asking when do you want that center to be somehwere other than center of target or source?
- 13:48:27 [kbabbitt]
- ydaniv: it's almost always the center
- 13:48:37 [kbabbitt]
- ... if it's the target then you would say just "at target" I guess
- 13:48:50 [kbabbitt]
- ... most use cases are switching between center of timeline itself, source of timeline, or animationtarget
- 13:49:00 [kbabbitt]
- ... could be a bunch of elements and you don't want each one to 0 independently
- 13:49:07 [kbabbitt]
- ... you want them to feel like a lot of elements that work together
- 13:49:13 [kbabbitt]
- ... all of them 0 when you're in center of timeline
- 13:49:17 [kbabbitt]
- ... mostly to switch between target and source
- 13:49:29 [kbabbitt]
- ... and I allowed option to also specify different place if you have some special case
- 13:49:36 [kbabbitt]
- ... I could just say just keyword source or target
- 13:49:46 [kbabbitt]
- ... but then maybe you have some considerations specific to your effect
- 13:49:52 [kbabbitt]
- ... you want to just move it around
- 13:50:00 [kbabbitt]
- SebastianZ: what I have inmind as use case is letting element follow mouse pointer
- 13:50:06 [kbabbitt]
- ... while hovering an element for example
- 13:50:12 [kbabbitt]
- ... can that already be achieved with current approach?
- 13:50:14 [kbabbitt]
- ydaniv: yes
- 13:50:21 [kbabbitt]
- ... if you want element to follow mouse?
- 13:50:32 [kbabbitt]
- ... in original issue, I can link the original issue with explainer
- 13:50:38 [kbabbitt]
- ... that has this
- 13:50:42 [kbabbitt]
- ... an example here
- 13:50:48 [ydaniv]
- https://github.com/issues/created?issue=w3c%7Ccsswg-drafts%7C10574
- 13:51:01 [kbabbitt]
- ... ^ bad link sorry
- 13:51:03 [ydaniv]
- https://github.com/w3c/csswg-drafts/issues/10574
- 13:51:05 [kbabbitt]
- ... ^ this one is better
- 13:51:13 [kbabbitt]
- ... if you scroll down you'll see an example
- 13:51:23 [kbabbitt]
- ... simple example of having an element trace pointer position
- 13:51:31 [kbabbitt]
- ... so you need 2 timelines and I'm using animation composition
- 13:51:42 [kbabbitt]
- ... to place them together
- 13:51:51 [kbabbitt]
- flackr: it's essentially a timeline for each axis with a transform in that axis
- 13:51:52 [kbabbitt]
- ydaniv: yes
- 13:52:05 [kbabbitt]
- ... so if in this case it could be cover at target cover at target
- 13:52:08 [kbabbitt]
- ... the ranges
- 13:52:44 [kbabbitt]
- SebastianZ: and it wouldn't necessarily have to be ?? in the example you have
- 13:52:49 [kbabbitt]
- ... not necessary to have 50% keyframe
- 13:53:10 [kbabbitt]
- ydaniv: yes, it's necessary to specify the ... if 50% computes to 0
- 13:53:23 [kbabbitt]
- ... it comes out naturally from the math could remove explicit 50% keyframe
- 13:53:23 [astearns]
- s/??/50%/
- 13:53:26 [kbabbitt]
- ... could make this even shorter
- 13:53:43 [flackr]
- q+
- 13:54:01 [astearns]
- ack flackr
- 13:54:06 [kbabbitt]
- flackr: I didn't mean to derail this conversation, now that I understand proposal, I think it's workable
- 13:54:13 [kbabbitt]
- ... we could start with that and update if we came up with something better
- 13:54:18 [kbabbitt]
- ydaniv: ok
- 13:54:27 [kbabbitt]
- flackr: and if you can work it in to animation range I'd prefer that over new property
- 13:54:38 [kbabbitt]
- ... you mentioned having an animation range syntax but this could be a follow-up proposal
- 13:54:46 [kbabbitt]
- SebastianZ: would be great to see a prototype of how it plays together
- 13:54:54 [kbabbitt]
- ... still hard to imagine all the different pieces working together
- 13:55:13 [kbabbitt]
- ... coud be possible if you created some kind of polyfill to write this out or did you already?
- 13:55:18 [kbabbitt]
- ydaniv: yes we shipped this to users at WIX
- 13:55:27 [kbabbitt]
- ... currently everything is centered to target, use entire viewport for timeline
- 13:55:31 [kbabbitt]
- ... this is default we use for all effects
- 13:55:38 [kbabbitt]
- ... exactly what designers and product manager wanted
- 13:55:42 [kbabbitt]
- ... everybotyu's happy no complaints
- 13:55:47 [kbabbitt]
- astearns: you haven't impl'd target?
- 13:55:52 [kbabbitt]
- ydaniv: no jsut the target, everything using target
- 13:56:01 [kbabbitt]
- ydaniv: everything using viewport as timeline centered to animation target
- 13:56:08 [kbabbitt]
- SebastianZ: do you have demos for your impl?
- 13:56:15 [kbabbitt]
- ydaniv: yes showed them in the explainer
- 13:56:20 [kbabbitt]
- ... this was already presented
- 13:56:27 [flackr]
- https://github.com/w3c/csswg-drafts/issues/10574
- 13:56:34 [kbabbitt]
- flackr: there's demos at that link
- 13:56:57 [kbabbitt]
- astearns: I am a little concerned about center as the property name here
- 13:57:06 [kbabbitt]
- ... but I'm not entirely sure what would replace it. maybe basis?
- 13:57:15 [kbabbitt]
- ... because you're choosing a reference
- 13:57:28 [kbabbitt]
- ... from which the length-percentage is applied
- 13:57:32 [kbabbitt]
- ... in order to select a single point
- 13:57:38 [kbabbitt]
- ... on the timeline
- 13:57:41 [kbabbitt]
- ... I don't know what to call that
- 13:57:46 [kbabbitt]
- ydaniv: ok but it's just bikeshedding?
- 13:57:59 [kbabbitt]
- astearns: yes. functionality in thjis makes sense to me, I just think it could probably have a better name
- 13:58:11 [kbabbitt]
- ydaniv: ok I think after I present next issue we can think about bikeshedding stuff
- 13:58:18 [kbabbitt]
- ... but basically idea is something workable?
- 13:58:20 [kbabbitt]
- astearns: I think so
- 13:58:25 [kbabbitt]
- [agreement from flackr and SebastianZ]
- 13:58:41 [kbabbitt]
- astearns: Proposal is to add property named animation-range-center for now that takes either a length-percentage or a keyword or both
- 13:58:44 [kbabbitt]
- ydaniv: yes
- 13:58:52 [kbabbitt]
- flackr: or has an initial value that means nothing right
- 13:59:04 [kbabbitt]
- ydaniv: accept the spec as-is and bikeshed
- 13:59:04 [kbabbitt]
- astearns: spec as is what is default value?
- 13:59:06 [kbabbitt]
- ydaniv: I think source 50%
- 13:59:10 [kbabbitt]
- ... use what you have on timeline
- 13:59:18 [kbabbitt]
- SebastianZ: it's normal, and normal is 50% of animation's active interval
- 13:59:23 [kbabbitt]
- flackr: normal was part i was looking for
- 13:59:29 [kbabbitt]
- ... don't know what it means for other timelines yet
- 13:59:42 [dmangal]
- present+
- 13:59:44 [kbabbitt]
- astearns: Proposed resolution: Add this property with syntax described here and normal as default value
- 13:59:50 [kbabbitt]
- ... all to be bikeshedded if needed
- 13:59:52 [kbabbitt]
- ... objections?
- 14:00:00 [kbabbitt]
- RESOLVED: Add this property with syntax described here and normal as default value
- 14:00:06 [kbabbitt]
- flackr: I think this concept might be applicable to view timelines
- 14:00:11 [kbabbitt]
- ... will have to think about it
- 14:00:17 [kbabbitt]
- ... or scroll view timelines
- 14:00:28 [kbabbitt]
- ydaniv: with all scroll animations we impl'd they were based on view timelines
- 14:00:37 [kbabbitt]
- ... wanted to have user be able to see where their 50% is
- 14:00:45 [kbabbitt]
- ... which is the original thing they put in the layout without the effect
- 14:01:01 [kbabbitt]
- SebastianZ: if it can be applied to other timelines maybe it should be moved to more generral spec
- 14:01:03 [kbabbitt]
- ydaniv: yes
- 14:01:04 [astearns]
- github-bot, subtopic https://github.com/w3c/csswg-drafts/issues/12507
- 14:01:04 [github-bot]
- Subtopic: [pointer-animations-1] Pointer timeline ranges
- 14:01:04 [github-bot]
- OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12507.
- 14:01:36 [kbabbitt]
- ydaniv: pointer animations, considering what I said about effects usually used for pointer animations
- 14:01:41 [kbabbitt]
- ... require something different
- 14:01:47 [kbabbitt]
- ... no concept of entyr and exit for pointer animations
- 14:01:57 [kbabbitt]
- ... in the issue itself I listed drawings
- 14:02:02 [kbabbitt]
- ... and listed the 4 suggested ranges
- 14:02:14 [kbabbitt]
- ... which is basically everything I could think of that we could possibly want to have
- 14:02:21 [kbabbitt]
- ... open to suggestions, thjis is what I started with in spec
- 14:02:27 [kbabbitt]
- ... I put labels, what is viewport timeline and target
- 14:02:40 [kbabbitt]
- ... outer one is viewport, all these examples use an element as timeline, and then target element
- 14:02:47 [kbabbitt]
- ... so ranges I suggested are: fill
- 14:03:04 [kbabbitt]
- ... just use the 0 as startinh edge of timeine, 100% as end edge of timeline
- 14:03:15 [kbabbitt]
- ... and if you specify a center that is not the normal center, not the source 50%
- 14:03:24 [kbabbitt]
- ... then it would squish
- 14:03:24 [kbabbitt]
- ... the interpolation
- 14:03:27 [kbabbitt]
- ... between 50 and 0 and 50 and 100
- 14:03:30 [kbabbitt]
- ... just fill that space
- 14:03:39 [flackr]
- q+
- 14:03:45 [kbabbitt]
- ... concept of this name is somewhat taken from object-fit
- 14:03:56 [kbabbitt]
- astearns: coming from discussion earlier, fill is the version that does squish portions of the timeline
- 14:03:59 [astearns]
- ack flackr
- 14:04:00 [kbabbitt]
- ... but the only one
- 14:04:18 [kbabbitt]
- flackr: do you have examples where fill or cover which both change the rate of progression
- 14:04:22 [kbabbitt]
- ... are desirable
- 14:04:32 [kbabbitt]
- ... in my mind, I only imagined fit as the thing everyone would want
- 14:04:41 [kbabbitt]
- ydaniv: I didn't cover the rest of them, but we used only cover
- 14:04:51 [kbabbitt]
- ... so that you always get a timeline covering the whole possible area
- 14:05:15 [kbabbitt]
- astearns: clarification: cover does not change the rate of progression, it only changes the effective range where th eanimation happens?
- 14:05:30 [kbabbitt]
- flackr: if you have multiple targets and one results in cover being larger than the other the rate of animation is different between the targets
- 14:05:36 [kbabbitt]
- ... for a single animation the rate is constant
- 14:05:43 [kbabbitt]
- astearns; but it can cjhange between different subjects
- 14:06:06 [kbabbitt]
- ydaniv; depends on the effect you want. if you want a lot of elements in different places to act together then maybe you'd use different range
- 14:06:07 [kbabbitt]
- ... but what we shipped to users was just cover
- 14:06:14 [kbabbitt]
- ... which was mostly what everyone wanted
- 14:06:17 [kbabbitt]
- ... there were no complaints
- 14:06:24 [kbabbitt]
- ... it could change if you use the viewport as your timeline
- 14:06:41 [kbabbitt]
- ... then as you scroll and then move your pointer it does change the interpolation range
- 14:06:50 [kbabbitt]
- ... because suddenly one end is closer to yout 50% point
- 14:06:57 [kbabbitt]
- ... and at another point of the scroll it could be another end
- 14:07:02 [kbabbitt]
- ... so it does change interpolation as you scroll
- 14:07:10 [kbabbitt]
- ... but all these effects used delaued timeline
- 14:07:16 [kbabbitt]
- ... with transitoins and polyfill it doesn't jump
- 14:07:42 [kbabbitt]
- ... visually
- 14:07:50 [kbabbitt]
- ... you scroll and of course when you scroll the browser stll doesn't update pointer position until you move pointer
- 14:08:00 [kbabbitt]
- ... and then range needs to be recalculated
- 14:08:12 [kbabbitt]
- ... and you get transition effect to new position
- 14:08:19 [kbabbitt]
- .... these cases where you have ... it couldf be also if timeline is an element and it's fixedpos
- 14:08:36 [kbabbitt]
- flackr: with fit, this requires that the rate of progression is different on either side of the midpoint
- 14:08:41 [kbabbitt]
- ... currently the way animation-range works
- 14:08:45 [kbabbitt]
- ydaniv: with cover it's not
- 14:08:54 [kbabbitt]
- ... with cover it's always mirrored
- 14:09:10 [kbabbitt]
- flackr: with fill, this is not currently supported by the calcs we do for animation-range
- 14:09:20 [kbabbitt]
- ... the way animation range is applied is we calc a start time and duration for animation
- 14:09:29 [kbabbitt]
- ... and it's linearprogression throughout times between start and duration
- 14:09:36 [kbabbitt]
- ... so this will require some sort of transformation step
- 14:09:41 [kbabbitt]
- ... for how we map animation timeline into progress
- 14:09:47 [kbabbitt]
- ... tajht I guess needs to be added to web animations
- 14:09:56 [kbabbitt]
- ... not to say it can't be done but adds complexity
- 14:09:59 [kbabbitt]
- ... mayube avoid for now
- 14:10:02 [kbabbitt]
- ydaniv: we could avoid
- 14:10:05 [kbabbitt]
- ... not sure I have use cases for that
- 14:10:13 [kbabbitt]
- ... mor necessary ones are the other 3. or fit and cover
- 14:10:16 [kbabbitt]
- ... we could start with that
- 14:10:22 [kbabbitt]
- flackr: that also maps to image sizing
- 14:10:32 [kbabbitt]
- ... we don't have a version of image sizing with asummetric scaling
- 14:10:39 [kbabbitt]
- ydaniv: maps to stretching but not automagic
- 14:10:48 [kbabbitt]
- ... I'm fine with dropping it for first version
- 14:11:00 [kbabbitt]
- flackr: that reminds me of why I was thinking diff scales could be problematic
- 14:11:20 [kbabbitt]
- ... if we apply cover ... cover applies per-axis
- 14:11:26 [kbabbitt]
- ... becuse those are independend pointer timelines
- 14:11:28 [kbabbitt]
- ydaniv: yes
- 14:11:45 [kbabbitt]
- flackr: so you can end up with one ofyour axes changing faster than the other if you were trying to coordinate an effect between those 2 things
- 14:11:53 [kbabbitt]
- ... I assume in practice it hasn't been a problem?
- 14:12:06 [kbabbitt]
- ... for example ifyour taget element is centered horizontally but is vertically near bottom of viewport
- 14:12:16 [kbabbitt]
- ... whje you move pointer horizontally yuou preogress quickly through horizontal effect
- 14:12:21 [kbabbitt]
- ... but vertical effect will be slower apparently
- 14:12:23 [kbabbitt]
- ydaniv: that's ok
- 14:12:42 [kbabbitt]
- ... as long as I control centering of both of them it's expected that effect is porportional to that range
- 14:12:46 [kbabbitt]
- ... because that's what you asked for
- 14:12:56 [kbabbitt]
- ... if you don't want that to change according to position, you'd need to use a container
- 14:13:08 [kbabbitt]
- ... and then that would say, the rate of change would be static
- 14:13:13 [kbabbitt]
- ... not as if they used entire viewport
- 14:13:19 [kbabbitt]
- ... and as you scroll you get different interpolations
- 14:13:20 [kbabbitt]
- flackr: ok
- 14:13:36 [kbabbitt]
- ydaniv: for what we shjipped we used the viewport ,nobody complained
- 14:13:42 [kbabbitt]
- ... agree there are many use cases fo rjust a container
- 14:13:48 [kbabbitt]
- ... certain point where timeline activates
- 14:13:52 [kbabbitt]
- ... don't have visual distinction
- 14:13:56 [kbabbitt]
- ... depends on your design
- 14:14:09 [kbabbitt]
- astearns: are we arriving at a proposed resolution that we accept only the fit and cover ?
- 14:14:12 [kbabbitt]
- ydaniv: and contain?
- 14:14:14 [flackr]
- q+
- 14:14:35 [kbabbitt]
- ... not sure if it's really about use cases for it, but contain is like instead of using farthest as reference point, search for closest edge
- 14:14:38 [kbabbitt]
- ... and then mirrors that
- 14:14:40 [astearns]
- ack flackr
- 14:14:48 [kbabbitt]
- flackr: the last point, not objecting
- 14:14:55 [kbabbitt]
- ... this is basically the equivalent of animation-duration
- 14:15:06 [kbabbitt]
- ... would it make sense to put these keywords on animation-duration instead?
- 14:15:16 [kbabbitt]
- ... what this is calculating is the duration of the animation
- 14:15:23 [kbabbitt]
- astearns: what does animation-duration currently take?
- 14:15:26 [kbabbitt]
- flackr: auto or <time>
- 14:15:28 [kbabbitt]
- astearns: ok
- 14:15:33 [kbabbitt]
- ydaniv: one problem I wanted to raise
- 14:15:38 [kbabbitt]
- ... proposal has something like 3 options
- 14:15:49 [kbabbitt]
- ... as I wrote this issue, I realized this doesn't really map well with start and end range
- 14:15:53 [kbabbitt]
- ... more of a range span
- 14:16:00 [kbabbitt]
- ... because you don't want to set this independently for start and end
- 14:16:11 [kbabbitt]
- ... silly to have cover 0% and then contain 100%
- 14:16:22 [kbabbitt]
- ... it's more of just give me a span
- 14:16:29 [kbabbitt]
- ... so maybe the solution would be to move this somehow into duration
- 14:16:40 [kbabbitt]
- flackr: I understand it may sound awkward, but that is what it is calculating
- 14:16:52 [kbabbitt]
- ... we should also consider how this would interact with a specified value for range start instead of range center
- 14:17:08 [kbabbitt]
- ... if I have a range start specified, it might also make sense to have a duration that fits to different meanings
- 14:17:23 [kbabbitt]
- ydaniv: one option in the proposal is maybe instead of cover and contain, use farthest and closest
- 14:17:28 [kbabbitt]
- ... but again I don't find it very useful
- 14:17:34 [kbabbitt]
- ... will also cause squishing of timeline
- 14:17:42 [kbabbitt]
- astearns: only if you don't use symmetrical ??
- 14:17:52 [astearns]
- s/??/start and ends/
- 14:17:54 [kbabbitt]
- ydaniv: and I'd rather have one word like range span to alway srestrict using something
- 14:18:01 [kbabbitt]
- ... that controls the entire timeline, like both ranges
- 14:18:13 [kbabbitt]
- ... so instead of whole timeline, emerging pattern is, you have span and centering
- 14:18:27 [kbabbitt]
- astearns: you say emerging pattern, others would say not following convention
- 14:18:38 [kbabbitt]
- flackr: it's just that the thing this span is calculating is the length of the animation
- 14:18:48 [kbabbitt]
- ... it is duration and it feels we should avoid an additional property
- 14:18:53 [kbabbitt]
- ... and maybe add values to duration property
- 14:18:58 [kbabbitt]
- ... keywords sound fine to me, cover and contain
- 14:19:09 [kbabbitt]
- ... those have a lot of value and do map to analagous concepts
- 14:19:20 [kbabbitt]
- astearns: I like this direction but would like to see how it all fits with what we have now
- 14:19:26 [kbabbitt]
- ... and have the meanings of these keywords defined for other timelines
- 14:19:34 [kbabbitt]
- flackr: and for specifying start or end instead of center
- 14:19:47 [kbabbitt]
- ... because essentially you're setting up 2 of 3 constraints on an animation and calculating the third
- 14:20:00 [kbabbitt]
- astearns: would it be oka to take this back to issue and see if it can beshoehorned into duration?
- 14:20:02 [kbabbitt]
- ydaniv: sure
- 14:20:20 [kbabbitt]
- astearns: then let's do that but I am much happier with my undestanding of pointert animations given this discussion, thank you
- 14:20:41 [ydaniv]
- scribe+
- 14:20:50 [astearns]
- github-bot, topic: https://github.com/w3c/csswg-drafts/issues/12376
- 14:20:50 [github-bot]
- astearns, Sorry, I don't understand that command. Try 'help'.
- 14:20:59 [astearns]
- github-bot, take up https://github.com/w3c/csswg-drafts/issues/12376
- 14:21:00 [github-bot]
- Topic: [css-sizing-3][css-values-4] Define `width` and `height` CSS values for SVG Elements in a mapping
- 14:21:00 [github-bot]
- OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12376.
- 14:21:04 [dmangal]
- q+
- 14:22:02 [astearns]
- ack dmangal
- 14:22:10 [ydaniv]
- dmangal: in SVG we allow width and height to be allowed
- 14:23:12 [ydaniv]
- ... these properties can take certain values, like pixels or relative values, or special keywords
- 14:23:22 [ydaniv]
- ... these values are already defined in SVG or CSS spec
- 14:23:44 [ydaniv]
- ... however there are values in form of viewport units and certain CSS keywords that depend on box model
- 14:24:02 [ydaniv]
- ... the spec is ambiguous about how to treat them
- 14:24:14 [ydaniv]
- ... so how to resolve is not clear
- 14:24:26 [ydaniv]
- ... the CSS spec requires resolving to ICB
- 14:24:33 [ydaniv]
- ... but SVG don't form that
- 14:24:53 [ydaniv]
- ... for same reason the min/max content keywords are also ambiguous
- 14:25:09 [ydaniv]
- ... we started conversations, that these should be resolved on ICB if available
- 14:25:53 [ydaniv]
- ... and for content based values would resolve on box model, we recommend to resolve to auto
- 14:26:12 [ydaniv]
- ... with defined behavior in SVG spec
- 14:26:32 [ydaniv]
- ... we want opinion on that proposal, if possible to have mapping of these values to properties in SVG spec
- 14:26:34 [kbabbitt]
- s/resolved on ICB if available/resolved on ICB if available, or browser viewport if ICB is not available/
- 14:26:50 [ydaniv]
- astearns: let's take viewport units first
- 14:27:00 [ydaniv]
- ... it seems there's general agreement in the issue
- 14:27:14 [ydaniv]
- SebastianZ: browsers seem to agree
- 14:27:19 [ydaniv]
- astearns: except for FF
- 14:27:47 [ydaniv]
- kbabbitt: they agree when these units are applied on the outmost SVG element, and we ask to specify these on the inner SVG elements
- 14:28:18 [ydaniv]
- dmangal: if the ICB is available the viewport units are resolved to that
- 14:28:21 [flackr]
- q+
- 14:28:24 [ydaniv]
- SebastianZ: sounds doable
- 14:28:28 [astearns]
- ack flackr
- 14:28:42 [ydaniv]
- flackr: what does it mean for ICB not to be available?
- 14:28:58 [ydaniv]
- dmangal: ICBs available can generate box model, and SVG elements don't have them
- 14:29:21 [ydaniv]
- flackr: inner SVG elements do have an element that initiates that block
- 14:29:40 [ydaniv]
- ... conceptually they still have an ICB, just don't live in a world where this box exists
- 14:30:06 [ydaniv]
- dmangal: initial proposal is that to use the ICB from inner elements got negative feedback from browsers
- 14:30:17 [ydaniv]
- ... instead they want to always use the viewport for resolution
- 14:30:40 [ydaniv]
- astearns: for anything other than the outermost SVG element
- 14:30:42 [ydaniv]
- dmangal: yes
- 14:30:58 [ydaniv]
- flackr: the ones that use the innermost of the SVG?
- 14:31:05 [ydaniv]
- dmangal: in the current proposal no
- 14:32:06 [ydaniv]
- flackr: as an analogy, if you make an iframe the vh unit inside it refer to the viewport
- 14:32:26 [ydaniv]
- astearns: everything in the iframe respects the box model
- 14:33:02 [ydaniv]
- flackr: I like the context
- 14:33:08 [dholbert]
- s/like/lack/
- 14:33:14 [ydaniv]
- astearns: wondering whether we should try again
- 14:33:28 [ydaniv]
- ... there is supposed to be a recharted WG to deal with bugs in SVG
- 14:33:40 [ydaniv]
- ... and this seems like a bug to me that they could spend time on fixing
- 14:33:47 [dholbert]
- (I've got similar confusion/concerns to flackr FWIW, but am also lacking context about why we can't just use the ICB for the iframe & how the ICB might not be defined)
- 14:34:52 [ydaniv]
- astearns: not pleased that we spec this just because current behavior is bad
- 14:35:15 [ydaniv]
- astearns: dmangal do you have more feedback?
- 14:35:47 [ydaniv]
- dmangal: one feedback to resolve against the ancestor's ICB
- 14:35:55 [ydaniv]
- ... in SVG case that would be the root SVG element
- 14:36:11 [ydaniv]
- ... the other proposal we got to resolve against the nearest element which is creating the viewport
- 14:37:22 [ydaniv]
- ... the first proposal was disliked because viewport units would be no different than percentages
- 14:37:39 [ydaniv]
- ... and second one was diliked because browsers don't currently do that
- 14:37:57 [ydaniv]
- astearns: don't accept either of those feedbacks
- 14:38:09 [flackr]
- q+
- 14:38:57 [ydaniv]
- ... if browers are currently managing at doing something with outermost SVG it wouldn't be that hard for doing it on inner SVG elements
- 14:39:03 [astearns]
- ack flackr
- 14:39:26 [ydaniv]
- flackr: I agree with astearns but also SVG have viewport definition that could establish a viewport that different than percentage resolution
- 14:39:47 [ydaniv]
- ... if we did resolved against the viewport of the SVG element , where would it won't match its size it would have a meaning
- 14:40:07 [ydaniv]
- ... agree it's better to have something, even it's the same value, to be more sensible
- 14:40:17 [astearns]
- s/feedbacks/feedbacks. viewport units being the same as percentages is better than viewport units having different behavoir based on the SVG hierarchy/
- 14:40:49 [ydaniv]
- astearns: let's not resolve on anything regarding viewport units, and move on
- 14:41:15 [ydaniv]
- ... proposal for content units is to resovle to auto
- 14:41:37 [ydaniv]
- dmangal: the auto behavior is specifyed in spec
- 14:42:00 [ydaniv]
- ... for SVG is to default to 100%
- 14:42:17 [ydaniv]
- ... for image tag is to default to intrinsic image size
- 14:42:22 [flackr]
- q+
- 14:42:35 [ydaniv]
- ... for all other elements it should default to 0
- 14:42:38 [astearns]
- ack flackr
- 14:42:50 [ydaniv]
- flackr: does the SVG document have intrinsic size as well?
- 14:43:16 [ydaniv]
- dmangal: the outermost SVG can have a size
- 14:43:28 [ydaniv]
- ... other define their size using the width/height properties
- 14:43:47 [ydaniv]
- flackr: when you specify auto, would it make sense to follow the image's conventions?
- 14:44:28 [ydaniv]
- dmangal: for elements like rect or other SVG elements we won't be referencing anything
- 14:44:54 [ydaniv]
- ... for image tag we take intrinsic sizes when auto is used
- 14:45:19 [ydaniv]
- ... but for other SVG elements we take the intrinsic is their portion of the size
- 14:45:53 [ydaniv]
- flackr: for SVG we would use the known size, and if not known then , what would it be? maybe 0?
- 14:46:10 [astearns]
- SVG definition of auto: https://www.w3.org/TR/SVG2/geometry.html#Sizing
- 14:46:19 [ydaniv]
- dmangal: in SVG case we use the width and height attributes
- 14:46:40 [ydaniv]
- ... would that cause a kind of confusion when we define their size?
- 14:46:54 [ydaniv]
- flackr: that would make sense for using intrisic size
- 14:47:07 [ydaniv]
- s/intrisic/intrinsic/
- 14:47:35 [ydaniv]
- flackr: I was thinking of viewbox for also providing the intrisic size
- 14:47:40 [ydaniv]
- dmangal: yes,
- 14:47:49 [ydaniv]
- flackr: we could have multiple fallbacks
- 14:47:52 [ydaniv]
- dmangal: Ok
- 14:48:56 [ydaniv]
- dholbert: for viewbox and intrinsic size it wouldn't good for many cases where they have ridicules values
- 14:49:07 [ydaniv]
- flackr: I think these are sensible
- 14:49:14 [ydaniv]
- dholbert: not necessarily
- 14:49:27 [ydaniv]
- ... in default we render 300x100
- 14:49:39 [ydaniv]
- ... there are edge cases, but not in specs
- 14:49:42 [astearns]
- dholbert: the viewbox is only reliable as a source of aspect ratio
- 14:49:54 [ydaniv]
- flackr: what happens when it's referenced by img elemnt?
- 14:50:07 [ydaniv]
- dholbert: we render the default 300x100
- 14:50:42 [ydaniv]
- ... I think there cases that we might resolved image to be size of the viewport when we don't have another fallback
- 14:50:55 [ydaniv]
- ... but in common fallback we use the 300x100 pixels
- 14:51:14 [ydaniv]
- ... we do use the viewbox to distinguish the aspect-ratio, but not for intrinsic size
- 14:51:34 [ydaniv]
- ... long story short, recommend against using viewbox for intrinsic size
- 14:52:00 [ydaniv]
- flackr: I know that many SVG editing tools have meaningful viewbox
- 14:52:16 [ydaniv]
- dholbert: usually that would be the coordinates space
- 14:52:40 [ydaniv]
- ... but when you export it's not good as defaults
- 14:53:23 [astearns]
- ydaniv: dholbert is correct. when designers export, they may just unknowingly export their huge design canvas
- 14:53:24 [kbabbitt]
- q+
- 14:53:44 [ydaniv]
- flackr: I'm convinced
- 14:53:54 [ydaniv]
- ... doesn't make value to use that
- 14:53:56 [astearns]
- ack kbabbitt
- 14:54:26 [ydaniv]
- kbabbitt: the proposal here is to treat CSS units that are content dependent as if they were auto
- 14:54:36 [ydaniv]
- ... does that make sense?
- 14:54:48 [ydaniv]
- astearns: makes some sense to me
- 14:55:00 [flackr]
- +1 makes sense to me to
- 14:55:12 [ydaniv]
- ... in particular that if SVG does get a better sense that they get that defintion if it's available to them
- 14:55:24 [ydaniv]
- ... sounds more flexible than 100%
- 14:55:34 [ydaniv]
- kbabbitt: that what the SVG spe currently says
- 14:55:53 [Ragvesh]
- Ragvesh has joined #css
- 14:55:58 [ydaniv]
- ... if there is no concept of content dependent units then treat it as auto
- 14:56:10 [ydaniv]
- ... and then we defer to what auto means in that concept
- 14:56:41 [flackr]
- q+
- 14:56:50 [ydaniv]
- astearns: proposed resolution: content dependent units resolve to SVG's definition of auto
- 14:56:56 [astearns]
- ack flackr
- 14:57:11 [ydaniv]
- flackr: one calrification, only for inner SVG elements?
- 14:57:47 [ydaniv]
- astearns: only for inner elements that don't participate in box model
- 14:58:29 [ydaniv]
- dholbert: just making sure there isn't anything other in the SVG spec
- 14:58:43 [astearns]
- https://www.w3.org/TR/SVG2/geometry.html#Sizing
- 14:58:56 [ydaniv]
- dmangal: you mentioned that in the SVG spec that auto has different meaning for different elements
- 14:59:16 [ydaniv]
- astearns: right, and dholbert was asking if this resolution applies only to some properties and not others?
- 14:59:26 [ydaniv]
- ... should we apply it only to widht and height?
- 14:59:38 [ydaniv]
- dmangal: yes, this is just for width and height
- 14:59:45 [ydaniv]
- astearns: fine let's scope it for that
- 15:00:03 [dmangal]
- q-
- 15:00:09 [astearns]
- proposed resolution: content dependent units used in width and height for inner SVG elements resolve to SVG's definition of auto
- 15:02:01 [astearns]
- RESOLVED: content dependent units used in width and height for inner SVG elements resolve to SVG's definition of auto
- 15:02:30 [astearns]
- topic: end
- 15:02:44 [dmangal]
- present-
- 15:45:19 [antonp]
- antonp has joined #css
- 16:06:02 [github-bot]
- github-bot has joined #css
- 16:56:14 [jamesn]
- jamesn has joined #css
- 17:00:26 [Adam_Page]
- Adam_Page has joined #css
- 17:03:07 [Zakim]
- Zakim has left #css
- 18:04:07 [Penny]
- Penny has joined #css
- 18:22:15 [una]
- una has joined #css
- 20:26:30 [antonp]
- antonp has joined #css
- 22:40:54 [ntim]
- ntim has joined #css