17:00:37 <RRSAgent> RRSAgent has joined #css
17:00:37 <RRSAgent> logging to https://www.w3.org/2019/02/26-css-irc
17:00:39 <trackbot> RRSAgent, make logs public
17:00:39 <Zakim> Zakim has joined #css
17:00:41 <trackbot> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
17:00:41 <trackbot> Date: 26 February 2019
17:01:45 <dauwhe> present+
17:01:54 <futhark> futhark has joined #css
17:02:38 <svoisen> TabAtkins: Hi I’m here on 7th floor. Can you or someone let me in?
17:03:20 <futhark> futhark has joined #css
17:09:01 <AmeliaBR> AmeliaBR has joined #css
17:09:06 <bgirard> bgirard has joined #css
17:10:23 <presenter> presenter has joined #css
17:12:06 <skk> skk has joined #css
17:14:42 <myles_> myles_ has joined #css
17:15:03 <gregwhitworth> scribenick: gregwhitworth
17:15:22 <bdc> bdc has joined #css
17:15:48 <rachelandrew> rachelandrew has joined #css
17:15:49 <TabAtkins> https://g.co/hangout/google.com/csswg
17:16:38 <xfq> xfq has joined #css
17:16:40 <gregwhitworth> Topic: ResizeObserver device-pixel-border-box
17:16:46 <gregwhitworth> Github: https://github.com/w3c/csswg-drafts/issues/3554
17:17:44 <gregwhitworth> atotic: I've been working on the spec
17:18:10 <gregwhitworth> atotic: the graphics team came to me - the problem they have is a way to determine the device pixel size of canvas
17:18:27 <gregwhitworth> atotic: why do they need to do this - the reason why they need to do this - is there is no way to do this
17:19:14 <gregwhitworth> atotic: the way the devs do hidpi in canvas it has CSS Pixels and what they do is they create the bitmap size they create the canvas in physical pixels it gets shrunk to CSS pixels so they can draw really fine hairlines
17:19:30 <gregwhitworth> atotic: device pixels are never rounded - there is no doubles or floating point, etc
17:19:41 <jensimmons> jensimmons has joined #css
17:19:46 <gregwhitworth> atotic: how we do this is by pixel snapping, there is no way for webdevs to determine this
17:20:14 <gregwhitworth> atotic: pixel snapping depends on not only pixels but also position
17:20:34 <gregwhitworth> atotic: I asked to add it to canvas, and they said sure but they also need to be notified when its resize
17:20:57 <gregwhitworth> atotic: currently the proposal will be that you will get device pixel inline and border size if its a canvas
17:21:10 <gregwhitworth> fantasai: are you proposing to add it somewhere else
17:21:17 <gregwhitworth> atotic: no
17:21:31 <gregwhitworth> fantasai: so the only way to get this is to add the resizeObserver
17:21:36 <gregwhitworth> atotic: yes
17:22:09 <gregwhitworth> dholbert: does devicePixelRatio?
17:22:28 <gregwhitworth> atotic: they get a bad pattern from hacking this because it can't do pixel snapping correctly
17:22:48 <gregwhitworth> dbaron: under what conditions does Chrome change the device pixel backing size when it's repositioned?
17:23:43 <gregwhitworth> dbaron: atotic is saying that, if you make a subpixel change in the top coordinate of a canvas, if it's 100.25 px tall
17:24:10 <bkardell_> present+
17:24:20 <gregwhitworth> dbaron: and it's top is positioned at a pixel aligned position it would round to 100, if it's further down it will be 101
17:24:29 <gregwhitworth> dbaron: do you actually change the backing store
17:24:39 <gregwhitworth> dbaron: the number of image pixels in the canvas
17:24:48 <gregwhitworth> dbaron: I guess thats the height and width
17:25:22 <gregwhitworth> dbaron: they want to change those the attrs based on the device pixel sizes
17:26:03 <gregwhitworth> atotic: the developer determines the size of the backing store, what Chrome does it will copy that bitmap to the CSS size of the canvas, if the ratio is a nice even number then we don't get moar patterns - if we don't
17:26:24 <bkardell_> how is that different from a url background image?
17:26:27 <gregwhitworth> atotic: there is a CSS size which can be fractional - but there is also the real bitmap to paint the canvas and that bitmap is in physical pixels
17:26:43 <bkardell_> " if the ratio is a nice even number then we don't get moar patterns - if we don't"
17:26:45 <bkardell_> that bit
17:27:09 <TabAtkins> s/moar/moire/g
17:27:26 <gregwhitworth> dbaron: bkardell_ is asking why don't you get moire pattern in background images
17:27:44 <gregwhitworth> atotic: it will scale, but background image is fundamentally different
17:28:00 <bkardell_> I can unmute and talk, I just dont want to interupt and don't knwo if this is enough to warrant a q
17:28:12 <gregwhitworth> atotic: we probably do get them but you usually aren't doing hidpi background image or you can't tell
17:28:31 <gregwhitworth> atotic: where they primarily have this issue is in the 3d context and they'll have patterns that look different
17:28:56 <AmeliaBR> q+
17:29:06 <gregwhitworth> bkardell_: the act of painting a thing on a canvas - the bitmap comes from an image and we rescale the image - it shoudln't matter who creates this image?
17:29:38 <gregwhitworth> atotic: you will see artifacts - but they'll create 3 different images
17:29:43 <dbaron> So I understand the use case -- but I'm a little suspicious of making it <canvas>-only, though.
17:29:57 <gregwhitworth> iank_: within painting, we know where the pixel snapping is so we can account for it
17:30:10 <gregwhitworth> atotic: also we're talking about every frame in video games, it happens a lot more
17:30:33 <gregwhitworth> dbaron: I understand the usecase I just don't know if I like that it's canvas only
17:31:01 <florian> q+
17:31:09 <gregwhitworth> atotic: I agree, but there is a performance penalty to calculate them and most people don't care about this except in a canvas context
17:31:17 <dbaron> I'd have expected it to be implemented a different way, but okay...
17:31:21 <gregwhitworth> atotic: if we find that it's useful in other areas it's easy to extend it
17:31:56 <gregwhitworth> AmeliaBR: if this is a canvas thing - why are we doing this here. Especially since this is a really hacky way to do it
17:32:21 <gregwhitworth> atotic: from what I understand from the history, there was a hidpi way in which to do this but the other standard didn't go anywhere
17:32:50 <gregwhitworth> hober: we also saw that people still create the larger one
17:33:16 <gregwhitworth> atotic: I agree RO is an odd place but the dimensions change if you move around you still need to be notified
17:33:52 <gregwhitworth> liam: checking the device pixel size, it seems easy to check every frame
17:33:54 <AmeliaBR> ack me
17:34:00 <gregwhitworth> liam: why would you not check it?
17:34:20 <gregwhitworth> atotic: if you're a game developer maybe
17:34:21 <heycam> q+
17:34:51 <gregwhitworth> frremy: If you want to draw a perfect line in your table you'll need to resnap it
17:35:00 <fremy> fremy has joined #css
17:35:02 <gregwhitworth> atotic: exactly, you need it or you add it to both specs
17:35:09 <heycam> ack florian
17:35:23 <emilio> q+
17:35:28 <gregwhitworth> florian: another thing - here we know what CSS & device pixel things and very easy to get confused
17:35:52 <gregwhitworth> florian: I don't know exactly what we want to add so let's not add it to too many places because it will get misused
17:36:09 <emilio> ack heycam
17:36:11 <gregwhitworth> atotic: it would only happen on canvas - you would see inlineDevicePixel and blockDevicePixel
17:37:13 <Rossen> gregwhitworth, recaps the resolution from yesterday
17:37:28 <gregwhitworth> heycam: before you were seeing a perf penalty - why not add a new box watching keyword?
17:37:43 <gregwhitworth> heycam: you can still have the device pixel border box of another element
17:37:50 <futhark> futhark has joined #css
17:37:56 <bdc> bdc has joined #css
17:38:08 <gregwhitworth> florian: but that was my point - if you make it broadly available they'll abuse it
17:38:21 <gregwhitworth> florian: they'll think they want device pixels but they'll probably be incorrect
17:38:29 <bkardell_> q+
17:38:56 <gregwhitworth> liam: to be clear, the only usecase this solves compared to RO plus having a method on canvas
17:38:56 <bkardell_> q-
17:39:32 <florian> q-
17:39:56 <dholbert> q+
17:40:00 <gregwhitworth> liam: this canvas snapping happens during painting or layout? If it happens at painting you wouldn't want to wait for painting to be done
17:40:11 <myles__> myles__ has joined #css
17:40:31 <emilio> s/liam/emilio
17:40:56 <gregwhitworth> smfr: the only way to really know this you is to do it at painting you have to take transforms into account
17:41:08 <gregwhitworth> Rossen: if you have a scale it's broken
17:42:45 <florian> ScribeScribe: Florian
17:42:48 <gregwhitworth> gregwhitworth: I'm against adding this based on what smfr and liam said
17:43:00 <gregwhitworth> atotic: it will be blurry anyways so it doesn't matter
17:43:06 <emilio> s/liam/emilio again :D
17:43:39 <florian> gregwhitworth: in your use case, you may be right, but if we add this, there may be people who want to use it in the more general case that includes tranforms
17:44:02 <florian> gregwhitworth: so taking all web devs into account, this looks like a partial solution, not good enough
17:44:26 <gregwhitworth> iank_: I'll need to ask Chris, but we may compute the transforms
17:44:40 <gregwhitworth> atotic: resizeObserver doesn't watch transforms
17:44:48 <gregwhitworth> smfr: then this is the wrong API to bolt this onto
17:45:13 <gregwhitworth> atotic: ok, the hidpi with an ancestor that has a transform or something
17:45:42 <gregwhitworth> atotic: that should still work because it will then get transformed
17:46:02 <gregwhitworth> florian: then it's broken because the second you scale it's broken
17:46:09 <gregwhitworth> florian: people will assume they can and it will fail
17:46:46 <gregwhitworth> atotic: I thought one of the issues on the webplatform you don't want to expose zoom because it will break
17:46:58 <gregwhitworth> heycam: this is different
17:47:13 <heycam> s/this/pinch zooming and transforms on ancestors/
17:47:17 <gregwhitworth> atotic: we were talking about the pinch zoom of the page and they would end up with arbitrarily long page
17:47:26 <gregwhitworth> florian: pinch zoom, leaving it out - but transform?
17:47:40 <gregwhitworth> atotic: if we were going to do transforms, there will be a subset of these that should work
17:47:40 <futhark> futhark has joined #css
17:47:53 <gregwhitworth> atotic: we want this to be a size API not a quad API
17:48:52 <florian> gregwhitworth: I feel this is a chrome only perspective, safari and Firefox don't seem up to it. Should we go back to the github issue?
17:48:55 <gregwhitworth> atotic: RO itself does not work with transforms
17:49:06 <skk> present+
17:49:23 <gregwhitworth> fremy: If you're going to draw a canvas you're not trying to do a transform on top of that
17:49:30 <gregwhitworth> fremy: transform is for animations
17:49:56 <gregwhitworth> fremy: why would you intend to do this if you're focused on pixel perfect drawing
17:50:41 <gregwhitworth> liam: I agree it doesn't make sense, it does make sense to center a canvas
17:50:56 <gregwhitworth> florian: offset path will also impact this as it can change the position
17:51:10 <bdc> bdc has joined #css
17:51:11 <gregwhitworth> atotic: we're going to notify you when the border box changes
17:51:33 <gregwhitworth> atotic: there's nothing that says we're not going to change on the transforms
17:51:49 <gregwhitworth> dholbert: how integral is the movement of the subpixel
17:52:12 <gregwhitworth> atotic: when you're moving it's blurry anyways, it's a video game
17:52:34 <gregwhitworth> dholbert: I'm feeling like a static API is more desirable than an RO API
17:52:51 <bkardell_> it is possible to make a subclass phase 2 of this that was specifically for observing that?
17:53:00 <bkardell_> .. or something
17:53:22 <gregwhitworth> dholbert: the canvas API makes sense to have this
17:53:31 <gregwhitworth> atotic: but people want to get an observation
17:53:46 <heycam> present+
17:53:51 <eae> present+
17:53:57 <fremy> q+
17:54:04 <emilio> ack emilio
17:54:10 <dholbert> q-
17:54:12 <tantek> tantek has joined #css
17:54:18 <tantek> present+
17:54:20 <gregwhitworth> AmeliaBR: is it reasonable to trigger RO on something may have changed even if the sizes haven't changed - they then can do a canvas pixel
17:54:45 <gregwhitworth> atotic: I thought of that - but you end up getting a bunch of ROs without knowing why
17:55:14 <gregwhitworth> AmeliaBR: we have a way of adding device-pixel-border-box back?
17:55:48 <gregwhitworth> atotic: where most observers they look at the border box or content box, what is this box and creates a larger turbelance
17:56:15 <gregwhitworth> AmeliaBR: maybe I don't care about those and you're adding a perf hit
17:56:31 <smfr> smfr has joined #css
17:56:49 <gregwhitworth> heycam: you can rename the type of the box, canvas-bitmap-box if you're worried about
17:57:06 <gregwhitworth> atotic: it kind of locks us into watching the canvas only
17:57:27 <gregwhitworth> fantasai: I think agree with atotic named canvas - so we shouldn't lock that down
17:57:53 <fantasai> s/named/about not naming specific to/
17:58:20 <gregwhitworth> smfr: we simply snap device scale factor - if you're inside the scale transform we don't snap all the time, so we do need to go outside of layout a bit.
17:58:24 <fantasai> fantasai^: because there might be other elements in the future where we want to use it, and we should be able to just re-use the same thing for those cases
17:58:30 <gregwhitworth> atotic: it has a perf hit
17:59:00 <gregwhitworth> smfr: if you drag to another screen would it fire
17:59:02 <gregwhitworth> atotic: yes
17:59:25 <gregwhitworth> smfr: it's not real device pixels, because your not taking transforms into account
17:59:49 <gregwhitworth> chrishtr: its the dims of the texture of the backing store
17:59:58 <gregwhitworth> smfr: what you just said is very impl specific
18:00:32 <gregwhitworth> chrishtr: it's the CSS pixel size snapped and multiplied by the devicePixelRatio without taking into account transforms
18:00:43 <gregwhitworth> chrishtr: it has to take into account zoom
18:00:47 <gregwhitworth> smfr: ours doesn't
18:00:53 <gregwhitworth> chrishtr: the spec says to
18:01:03 <gregwhitworth> dholbert: doesn't it fire after layout?
18:01:05 <mstensho> mstensho has joined #css
18:01:05 <gregwhitworth> atotic: yes
18:01:17 <gregwhitworth> dholbert: so after layout
18:01:47 <gregwhitworth> dholbert: it would need to be extended to take into account after the fact
18:02:02 <gregwhitworth> liam: I don't think this a great fit
18:02:06 <melanierichards> present+
18:02:25 <gregwhitworth> iank_: it's where all other resizes are triggered, it's actually bad to try to keep it in sync with RO
18:02:30 <myles__> q+
18:02:36 <dbaron> So about 20 minutes ago there was a suggestion to take this back to the github issue... is there something we're actually going to resolve on here?
18:02:40 <hyojin> hyojin has joined #css
18:02:55 <hyojin> present+
18:03:14 <gregwhitworth> fantasai: one thing to note if we have a RO if your 100 CSS pixels and I move it to the hidpi screen it's still 100 CSS pixels. And it's a canvas specific issue
18:03:34 <gregwhitworth> fantasai: it would be nice to not get the extra events unless I actually care about the device pixel border box
18:03:48 <gregwhitworth> atotic: yes
18:03:59 <gregwhitworth> fantasai: I think it should be the content box since that's what you're painting into
18:04:10 <dbaron> atotic: you could register to observer device-pixel-content-box
18:04:39 <gregwhitworth> atotic: that was my original proposal
18:04:46 <chrishtr> q+
18:04:54 <xfq> ack my
18:05:16 <gregwhitworth> myles__: so in conjuction with what fantasai was saying then you need to know the pos and size.
18:05:30 <gregwhitworth> fantasai: no only if those pixels change
18:05:52 <florian> gregwhitworth: that's already in the algo
18:06:00 <gregwhitworth> fantasai: you can resize in result of pos, but it may not
18:06:28 <Rossen> ack fremy
18:06:41 <gregwhitworth> fremy: I think it's going to be tricky in a sense, for the usecase your using - have you considered the paint() API?
18:06:57 <dbaron> (sounds like people were leaning towards registering for a separate box name rather than giving these notifications magically in some case)
18:07:09 <gregwhitworth> iank_: we don't have webgl and a bunch of other APIs
18:07:11 <gregwhitworth> fremy: oh ok
18:07:29 <fantasai> Proposal: Register for changes to devicePixelContentBox, get back sizes in device pixels, throws an error if registered on anything other than a canvas element, fires whenever device pixel size changes whether due to change in screen resolution, element position, or element resizing. Does not fire if device pixel size does not change.
18:07:44 <smfr> q+
18:08:10 <dbaron> still doesn't deal with the issues about rectilinear transforms, offset-path, etc.
18:08:28 <Rossen> ack chrishtr
18:08:31 <gregwhitworth> chrishtr: I just wanted to follow up on explicitly defining the API, in the CSS paint worklet callback you can see the device pixel backing size. It helps devs to dinstinguish between the two and can discover it. I think it would be useful to distinguish
18:08:39 <gregwhitworth> atotic: I think we have agreement to watch a seperate box?
18:09:13 <astearns> zakim, close queue
18:09:13 <Zakim> ok, astearns, the speaker queue is closed
18:09:18 <gregwhitworth> smfr: I just want to say that I don't think canvas is the only one, I think other situations may care about the same thing
18:09:33 <gregwhitworth> smfr: I think people will want it in other ways
18:09:38 <astearns> ack smfr
18:09:57 <smfr> s/in other ways/on other elements/
18:10:32 <futhark> futhark has joined #css
18:11:11 <gregwhitworth> smfr: I was proposing this is the snapped content box multiplied by device pixel ratio
18:11:37 <gregwhitworth> dbaron: but you all agree to ignore transforms?
18:11:51 <gregwhitworth> chrishtr: because it should be a paint based situation for perf
18:11:58 <gregwhitworth> dbaron: I don't think that's actually true
18:12:12 <gregwhitworth> chrishtr: unless overflow it's almost post paint
18:12:29 <gregwhitworth> krit: even SVG?
18:13:07 <AmeliaBR> I like the connection with Paint API. Even comes with a nice name, "paint size": https://drafts.css-houdini.org/css-paint-api/#paintsize
18:13:14 <gregwhitworth> Rossen: my proposed closing of the issue - let's bring the proposal back to github and then bring it back and we can resolve then
18:13:16 <gregwhitworth> atotic: thank you
18:13:27 <TabAtkins> Ooh, "paint size" sounds good.
18:13:39 <gregwhitworth> Topic: CSS properties should apply to some SVG properties as well
18:13:48 <bdc> bdc has joined #css
18:14:15 <chris> chris has joined #css
18:14:20 <chris> present+
18:14:34 <gregwhitworth> AmeliaBR: I don't have a whole lot to update
18:14:39 <gregwhitworth> AmeliaBR: in comparison to the telecon
18:15:19 <gregwhitworth> AmeliaBR: the issue came up because we want an easier way for defining what applies to SVG instead of having to update every time a new CSS prop is added
18:15:38 <gregwhitworth> AmeliaBR: having to update the spec to say, "hey this also works" - some specs do this but it's not at all consistent
18:15:47 <gregwhitworth> AmeliaBR: the applies to in the definition is loosely defined
18:16:02 <Rossen> q?
18:16:08 <chris> rrsagent, here
18:16:08 <RRSAgent> See https://www.w3.org/2019/02/26-css-irc#T18-16-08
18:16:12 <gregwhitworth> AmeliaBR: when you look at CSSOM for getCOmputedStyle it has nromative impacts on whether you return the computed or used style
18:16:28 <gregwhitworth> AmeliaBR: I think this issue got added to the F2F that I would come with a pretty proposal but that hasn't happened
18:16:50 <gregwhitworth> AmeliaBR: In general I'd like to suggest that the applies to more rigorously defined which categories are used?
18:17:02 <heycam> q+
18:17:07 <astearns> zakim, open queue
18:17:07 <Zakim> ok, astearns, the speaker queue is open
18:17:11 <heycam> q+
18:17:18 <gregwhitworth> AmeliaBR: as far as how it works on SVG side is, it shows all elements but is it ALL elements considering SVG?
18:17:38 <gregwhitworth> AmeliaBR: instead of using the term elements we can use rendering tree terminology, etc
18:17:55 <gregwhitworth> AmeliaBR: also others mix elements and rendering tree words it's very incosistent
18:18:13 <gregwhitworth> AmeliaBR: the SVG element the same element in different layout contexts may or may not have a CSS box
18:18:33 <gregwhitworth> AmeliaBR: another thing for SVG - text content elements many text related props will apply to SVG Text but not all
18:18:41 <gregwhitworth> AmeliaBR: because the actual text layout is different
18:19:02 <gregwhitworth> AmeliaBR: it would be valuable to not have to re-analyze if it impacts SVG text, etc
18:19:12 <gregwhitworth> fantasai: what are we trying to conclude
18:19:29 <gregwhitworth> AmeliaBR: at this point it's just an update and they've been surprised that it has normative impact
18:19:38 <fantasai> s/impact/impact on getComputedStyle/
18:19:48 <gregwhitworth> AmeliaBR: should we somehow extract that, and make it informative and then define gcs in some other way
18:19:57 <Rossen> q?
18:20:01 <dbaron> q+
18:20:05 <gregwhitworth> AmeliaBR: if it's a normative impact then we need to be strict terms that are clearly defined
18:20:19 <florian> q+
18:20:26 <Rossen> ack heycam
18:20:41 <atotic> atotic has joined #css
18:20:48 <gregwhitworth> heycam: I guess I am one of those people that applies to has normative impact, I always thought it was an informative information and prose would define it
18:20:57 <gregwhitworth> heycam: maybe I missed an earlier discussion
18:21:18 <krit> present: krit
18:21:18 <TabAtkins> https://drafts.csswg.org/cssom/#resolved-value-special-case-property-like-height
18:21:29 <gregwhitworth> AmeliaBR: the summary, getComputedStyle for many props it doesn't return the computed style that gets inherited such as % or auto only pixel value
18:21:31 <TabAtkins> and the next instance of the phrase "applies to" as well
18:21:41 <gregwhitworth> AmeliaBR: that's where the applies to the normative impact
18:21:55 <gregwhitworth> heycam: does CSSOM point to applies to
18:21:58 <gregwhitworth> TabAtkins: yes
18:22:21 <gregwhitworth> TabAtkins: but none of us knew this - so maybe we fix that definition. None of our applies to are not written as though they're normative
18:22:23 <Rossen> ack dbaron
18:22:29 <krit> q+
18:22:41 <gregwhitworth> dbaron: I think the spec for getComputedStyle is not yet where impl should change to match the spec
18:23:09 <gregwhitworth> dbaron: maybe someone took a shortcut to point to applies to - but it's probably not an accurate definition
18:23:31 <gregwhitworth> AmeliaBR: I'm not asking impl to match the CSSOM spec it's about spec consistency
18:23:45 <gregwhitworth> AmeliaBR: but it's using a terminology that isn't explicitly defined elsewhere
18:23:48 <mfreed> mfreed has joined #css
18:23:54 <futhark> futhark has joined #css
18:24:08 <gregwhitworth> florian: also applies to it's not just a yes/no category - there has to be prose
18:24:22 <Rossen> ack florian
18:24:24 <gregwhitworth> florian: I'd be in favor in keeping applies to somewhat wishywashy
18:24:34 <gregwhitworth> florian: but also helping clarity for SVG is useful
18:24:50 <astearns> ack krit
18:24:52 <Rossen> ack krit
18:24:54 <chris> q?
18:25:04 <gregwhitworth> krit: besides that Applies TO we need to look at the prose, many text layout keep SVG in mind as well
18:25:21 <gregwhitworth> krit: if there is anything that the SVG specs can do to help that would be good to know as well
18:25:32 <gregwhitworth> krit: that would help interoperability between SVG/CSS very good as well
18:25:40 <gregwhitworth> AmeliaBR: that's very good feedback as well
18:25:43 <krit> ack krit
18:25:58 <gregwhitworth> AmeliaBR: I don't think we have them defined in one place, so we can improve that on our end
18:26:26 <gregwhitworth> AmeliaBR: so then it's kind of - the current specs it'll be a massive review and giant PR to make sure we do have clear defs for what applies to SVG and how
18:26:37 <gregwhitworth> florian: this will probably be more than a blue box change but a prose change
18:26:51 <florian> q+
18:27:18 <gregwhitworth> AmeliaBR: then moving forward, try to think about how it works on SVG, feel free to reach out. We've discussed content, contain, etc. but the questions need to be asked
18:27:24 <Rossen> ack florian
18:27:41 <gregwhitworth> florian: it's a process question, these categories can be aware of - are they different between SVG1.1 & 2?
18:27:51 <gregwhitworth> AmeliaBR: some of them have changed and some have been simplified
18:27:59 <gregwhitworth> AmeliaBR: I think there are a couple new categories
18:28:09 <chris> There are changes in SVG2, mostly simpfilfications.
18:28:11 <chris> q+
18:28:12 <gregwhitworth> florian: it would be unfortunate if no spec can get to rec until SVG 2 does
18:28:33 <gregwhitworth> florian: I don't want to gate everything on SVG getting to rec
18:28:50 <gregwhitworth> AmeliaBR: most will be in SVG 1.1 already but the SVG editors need to make sure those defs are in one place
18:29:02 <chris> q?
18:29:04 <gregwhitworth> AmeliaBR: that covers the main topic of this issue
18:29:26 <gregwhitworth> chris: The issue that florian raised is a quite large CSS one
18:29:43 <gregwhitworth> chris: whenever a spec goes to rec but it has these refs to EDs etc
18:30:08 <gregwhitworth> chris: we have a highly intertwined set of specs and it's really hard - and SVG doesn't really change this but adds
18:30:52 <gregwhitworth> florian: the problem is we have the bedrock of CSS2.1, at times it's more convenient to link to newer things because it has more things and it kind of makes it possible, but SVG is outside of that bedrock
18:31:11 <gregwhitworth> chris: there have been a few cases in SVG2 that are linking to SVG1.1, etc
18:31:33 <gregwhitworth> chris: as for CSS, I think it shouldn't be too large of a problem - there is a last resort
18:31:46 <krit> q+
18:32:11 <Rossen> ack chris
18:32:17 <gregwhitworth> florian: if it's a generic ref SVG then that's fine, but if we're starting to add 3 paragraphs prose about SVG that don't exist then you need to implement it and get that to rec and have a hard dependency.
18:32:38 <gregwhitworth> chris: we have some concepts for graphic elements and SVG1.1 has this stuff
18:32:47 <gregwhitworth> krit: just one comment
18:32:58 <gregwhitworth> krit: SVG2 categories are supposed to make things easier
18:33:23 <Rossen> ack krit
18:33:37 <gregwhitworth> krit: but if you would like to link to 1.1 that's fine for normative reference as long as it's defined what happens to the content in SVG we don't care if it's 1.1 or 2
18:34:24 <gregwhitworth> AmeliaBR: if there isn't something in there, then you can add some examples that says you don't have to implement and give branches
18:34:45 <gregwhitworth> florian: that spec that references it can't go to rec either because they're dependant on it
18:34:55 <gregwhitworth> krit: in those weird cases, sure link to 1.1 SVG
18:35:03 <gregwhitworth> krit: most of the issues are text related
18:35:08 <gregwhitworth> Rossen: ok, that sounds good
18:35:48 <jensimmons> jensimmons has joined #css
18:36:03 <gregwhitworth> AmeliaBR: we should open an issue into defining getComputedStyle further
18:36:19 <gregwhitworth> ACTION AmeliaBR : Open an issue to define getComputedStyle
18:36:19 <trackbot> Created ACTION-876 - : open an issue to define getcomputedstyle [on Amelia Bellamy-Royds - due 2019-03-05].
18:37:13 <gregwhitworth> s/liam/emilio
18:41:53 <AmeliaBR> github: https://github.com/w3c/csswg-drafts/issues/3414
18:42:01 <AmeliaBR> github-bot, end topic
18:44:42 <mstensho> mstensho has joined #css
18:45:13 <futhark> futhark has joined #css
18:49:55 <smfr_> smfr_ has joined #css
18:54:39 <bdc> bdc has joined #css
18:55:24 <TabAtkins> I have a breakout room reserved for this afternoon 2-3, fyi for scheduling
18:55:29 <TabAtkins> AmeliaBR: And I got one 9-10 tomorrow morning
18:55:52 <AmeliaBR> Thanks TabAtkins !
18:56:24 <jensimmons> jensimmons has joined #css
18:56:29 <futhark> futhark has joined #css
18:57:48 <xfq> xfq has joined #css
18:59:09 <fantasai> ScribeNick: fantasai
18:59:20 <fantasai> Topic: Shadow something
18:59:31 <emilio> Topic: make clear that Shadow Parts for built-in elements should not be supported without standardization
18:59:36 <emilio> github: https://github.com/w3c/csswg-drafts/issues/3674
19:00:20 <fantasai> heycam: This is a small request, we had a request internally to make it clear that the ::part pseudo-element is not a kind of free-for-all extension point for engines to expose parts of built-in form control elements
19:00:41 <fantasai> heycam: There was soem concern in the past that engines were happy to expose parts of form controls through pseudo-elements, and of course that's a big compat problem for us, maybe others
19:00:53 <smfr> smfr has joined #css
19:01:16 <fantasai> heycam: We don't want to repeat with env(), which also takes an ident, and we ended upw ith things being implemented that we then had to implement and then spec afterwards, which is the reverse of the standards process.
19:01:26 <fantasai> heycam: I like that theis psec doesn't talk about built-in file controls
19:01:51 <florian> I fully agree with heycam
19:01:52 <fantasai> heycam: But it's an attractive bit of syntax for exposing this stuff, so we'd appreciate a note in the spec that this isn't to be used to expose parts of standard form controls until we go through the normal standards process
19:01:59 <Rossen> s/theis psec/the spsec/
19:02:00 <fantasai> TabAtkins: I accept the change on behalf of fergal
19:02:27 <fantasai> heycam: Unless ppl have plans to start exposing things through ::part()...?
19:02:31 <tantek> +1
19:02:49 <rachelandrew> rachelandrew has joined #css
19:02:53 <fantasai> AmeliaBR: Questions from authoring side. One of big complaitns with all fo the custom pseudo-elements was that it messed up your selector and you had to have separate ruels for every browser
19:03:09 <fantasai> AmeliaBR: Is the invalidity rule such that ::part() is always valid regardless of arg?
19:03:18 <fantasai> TabAtkins: As long as syntax matches what's syntactically allowed it's valid
19:03:34 <fantasai> AmeliaBR: So if someone watned to test out a prefixed part, it'll be a nicer flow for authors to build on
19:03:47 <fantasai> AmeliaBR: Agree that ppl shouldn't ship experimental things until there's a standardization discussion
19:04:05 <fantasai> AmeliaBR: In some cases maybe we'll say, your datepicker is so specialized that you should have a prefixed part?
19:04:14 <fantasai> TabAtkins: Yeah, fine to do, because syntax space is wide open
19:04:32 <fantasai> RESOLVED: Add such a note -- no exposing parts of form controls without standardization
19:04:50 <fantasai> Topic: contain: style doesn't seem very suseful
19:04:56 <fantasai> s/suseful/useful/
19:05:08 <fantasai> emilio: Very confused what use case contain: style is supposed to solve.
19:05:08 <astearns> github: https://github.com/w3c/csswg-drafts/issues/3280
19:05:17 <fantasai> emilio: It's hard to implement. Very broken in the only implementation that's shipping.
19:05:33 <fantasai> emilio: I can't see any potential advantage except *maybe* update counters faster in the page?
19:05:34 <futhark> q+
19:05:38 <fantasai> emilio: But that's usually not a perf issue.
19:06:03 <fantasai> TabAtkins: My answer in the issue was that the 'contain' properties in general are to help isolate parts of your document
19:06:12 <fantasai> TabAtkins: perf wins are a benefit, esp layout
19:06:24 <fantasai> TabAtkins: But also helps you isolate parts of your document to make it easier to think about
19:06:45 <fantasai> TabAtkins: It covered the remaining thing that would leak out of a component
19:07:03 <fantasai> TabAtkins: Was a completion exercise in making an isolated component
19:07:21 <fantasai> emilio: Did we decide how counters work in CSS? Are they off DOM tree or flat treee?
19:07:29 <fantasai> TabAtkins: CSS works on flat tree as its "element tree"
19:07:38 <fantasai> TabAtkins: So counters are defined to work on flat tree
19:07:48 <fantasai> TabAtkins:...
19:07:50 <fantasai> emilio: Tests?
19:07:58 <fantasai> TabAtkins: Had some in past, lost them. before wpt
19:08:08 <fantasai> TabAtkins: Might pick up again when working on Lists
19:08:34 <fantasai> dbaron: Counters are part of generated content, thus box tree
19:08:54 <fantasai> TabAtkins: Mental model is that everything is elements, then we turn things into boxes, then we turn things into fragments
19:09:09 <futhark> futhark has joined #css
19:09:19 <heycam> fantasai: if we had counters working on the not flat tree, then I don't know that list numbering would make much sense, if part of your component was reordering items in a list
19:09:25 <heycam> ... so I think they do need to work on the flat tree
19:09:44 <astearns> q?
19:09:45 <fantasai> TabAtkins: If you take an ol, give it a shadow tree, rearrange items, numbering should reflect final display, not original ol.
19:09:49 <fantasai> fantasai: Right.
19:10:16 <fantasai> futhark: I agree with emilio that there is not much to do with optimization for contain: style
19:10:17 <Rossen> ack futhark
19:10:27 <fantasai> futhark: One useful thing would be if we said that inheritance doesn't happen from 'contain: style' down
19:10:32 <dbaron> At the time we implemented ::before and ::after as part of the box tree, the specs were still pushing towards allowing multiple CSS presentations of a single document.
19:10:34 <fantasai> futhark: Then we can optimize for ?
19:11:02 <fantasai> futhark: If 'contain: style' meant that 'all: initial', then we could optimize getComputedStyle
19:11:14 <fantasai> futhark: Then it wouldn't rely on layout (???)
19:11:20 <fantasai> futhark: Then can do display locking
19:11:22 <fantasai> emilio: ...
19:11:40 <fantasai> TabAtkins: Contain property doesn't block things going into the subtree. It blocks things leaking out.
19:11:51 <fantasai> florian: It's the contain property, not the isolate property
19:11:54 <Rossen> q?
19:11:56 <futhark> futhark has joined #css
19:12:36 <fantasai> TabAtkins: If it ends up being that we don't want to impelment 'contain: style ' across browsers, we can drop it. It just, it's part of my vision for what 'contain' was about. Last piece necessary to create a seal around the subtree
19:12:45 <fantasai> TabAtkins: There's a bunch of parts of CSS where we have global names etc.
19:12:52 <fantasai> TabAtkins: Maybe we just rely on shadow DOM.
19:13:07 <fantasai> florian: Wanted to ask rego's pov , since he fixed a lot of bugs  on 'contain: style'
19:13:26 <fantasai> emilio: It's very broken to the point that 'contain: style' toggling doesn't do anything dynamically
19:13:29 <rego> there are a few bugs https://github.com/w3c/csswg-drafts/issues/3280#issuecomment-452580469
19:13:36 <fantasai> emilio: Implementing it in Gecko is really hard, and I'd rather not ship something that's broekn.
19:13:53 <fantasai> emilio: My ask is drop it.
19:14:04 <fantasai> Rossen^: So what's your ask, Emilio?
19:14:14 <presenter> presenter has joined #css
19:14:33 <mfreed> mfreed has joined #css
19:14:41 <fantasai> Rossen: So proposal here is to drop 'contain: style' from css-contain
19:14:46 <futhark_> futhark_ has joined #css
19:14:52 <fantasai> AmeliaBR: Is there any reason this couldn't be added back later, if it turns out to be useful?
19:15:28 <fantasai> florian: Yes and no. It's easy to add stuff. But there's 'contain: strict' which is all of the contains. If we add a new one, then it woudldn't just be an addition but a change.
19:15:41 <fantasai> florian: So we'd have to add a new keyword for all of the contains that includes the new type of containment
19:16:27 <fantasai> chrishtr: If property changes on an element on 'contain: style', and we don't have 'contain: style', is it possible to dirty something else?
19:16:34 <fantasai> TabAtkins: counters and quote property
19:16:44 <fantasai> emilio: The computed style doesn't change.
19:16:50 <fantasai> emilio: The counter values are not stored in computed styles
19:17:06 <fantasai> chrishtr: Does contain: layout say that counters...?
19:17:10 <futhark> futhark has joined #css
19:17:13 <fantasai> emilio: Style is a bit of misnomer
19:17:40 <fantasai> chrishtr: Regardless of name, need to have this functionality to have complete perf
19:18:03 <fantasai> emilio: My point is that changing counters is not something that is typically a perf bottleneck. Not like changing height, which has lots of effects throughout the doc
19:18:03 <futhark> futhark has joined #css
19:18:12 <fantasai> emilio: Not soemthing I've seen in a perf profile at all
19:18:29 <fantasai> chrishtr: But if you want to do things like async rendering or display locking
19:18:35 <futhark> futhark has joined #css
19:18:40 <fantasai> chrishtr: you'd need this, just in case the content changed a counter
19:18:42 <futhark> q+
19:18:50 <fantasai> chrishtr: Whether it should be its own thing, idk
19:19:09 <fantasai> emilio: It's not something that happens frequently. It can have a layout effect across the page.
19:19:18 <fantasai> chrishtr: But unless you lock it, has an effect
19:19:22 <fantasai> emilio: It's same as changing content property
19:19:38 <fantasai> florian: But that doesn't affect outside the element
19:19:51 <fantasai> emilio: ... counters reset can change stuff across document
19:20:14 <fantasai> chrishtr: Point of containment is that you can reason about the relationship of work between stuff in the contained subtree fvs rest of document
19:20:22 <fantasai> chrishtr: It's small but a real footgun?
19:20:33 <fantasai> emilio: That's fair, but we still don't have a great model for counters
19:20:49 <fantasai> emilio: Makes it seem like counters work in the style tree.
19:20:52 <fantasai> emilio: Which isn't true
19:21:00 <futhark> futhark has joined #css
19:21:13 <fantasai> emilio: We need tests for like shadow DOM, need tests for display: contents, for all these edge cases which change how counters are affected by style containment
19:21:18 <fantasai> chrishtr: Agree we need tests
19:21:22 <fantasai> emilio: and a proper spec
19:21:38 <fantasai> dbaron: We had an interim agreement to add 'counter-set'
19:21:42 <fantasai> dbaron: we never added
19:21:48 <fantasai> TabAtkins: it's in a spec, it's in Lists
19:21:52 <fantasai> TabAtkins: just never past WD
19:21:59 <fantasai> emilio: ... spec, not in implementations
19:22:08 <fantasai> emilio: Even in Blink, renumbering lists
19:22:20 <fantasai> emilio: If element is display: contents; contain: strict; if you add a list item inside of it?
19:23:00 <fantasai> emilio: You have a <ol><div style="contain: strict"><li></div></ol>
19:23:14 <fantasai> emilio: Right now if you change the div's display, it is buggy
19:23:25 <fantasai> TabAtkins: Our entire counters implementation has issues
19:23:42 <fantasai> eae: Spec is correct, but our impl is incorrect
19:23:51 <fantasai> emilio: Given state of impls, implementing 'contain: style' is not worth it
19:24:03 <fantasai> TabAtkins: Fact that built-in lists might be magical is a separate issues
19:24:20 <fantasai> emilio: If lists are magical, then we have another leak
19:24:32 <fantasai> dbaron: We have a patch to Gecko to use counters for lists, so might fix that
19:24:59 <fantasai> chrishtr: Sounds like all the browsers are sad, and I think we agree that there is a real footgun even if a small one
19:25:14 <fantasai> chrishtr: So I think we should add proper tests and fix things to not be sad
19:25:27 <fantasai> chrishtr: Then if that's the case, come back to you about this.
19:25:40 <fantasai> dholbert: Sounds like use case is lazily rendering the subtree
19:26:04 <fantasai> dholbert: If counters and quotes are the only things that would have an effect, maybe implementations can just add checks for those properties
19:26:14 <fantasai> dholbert: They're quite rarely used
19:26:50 <fantasai> dholbert: Might be easier to just disable perf optimizations in cases where they're used rather than implementing 'contain: style'
19:27:03 <gregwhitworth> q+
19:27:23 <astearns> ack futhark
19:27:34 <fantasai> futhark: I think Chris you had some thoughts... I'm confused about isolation vs containment
19:27:38 <Rossen> ack futhark
19:27:40 <fantasai> futhark: For perf, you probably want isolation
19:27:48 <fantasai> futhark: If you modify DOM outside something that's contaiend
19:28:02 <fantasai> futhark: It can affect sibling selectors that affect the contained subtree
19:28:09 <fantasai> emilio: Which can set 'contain'
19:28:22 <fantasai> TabAtkins: Nothing about contain is about isoaltion
19:28:39 <fantasai> TabAtkins: You can't have layout isolation
19:28:55 <fantasai> TabAtkins: You can't use percentage or auto or anything. It has to be 100% manually-specified or nothing.
19:29:15 <fantasai> TabAtkins: You have a subree that you can ignore when changes happen inside it. That's the use case we're designing for
19:29:37 <fantasai> chrishtr: Points about % sizing and isolation vs something else is a complicated subject, and the more you go twards one end the more you lose use cases  or perf
19:29:43 <fantasai> chrishtr: needs investigation
19:29:58 <fantasai> chrishtr: Not only is 'contain: style' poorly implemented, the other contain modes while implemented corretly don't actually improve perf
19:30:04 <florian> q+
19:30:18 <gregwhitworth> ack me
19:30:31 <fantasai> emilio: Even though containment is designed to ignore a subtree, you can still have e.g. :empty { contain: strict } and that div's contained but you insert a child in that div, and you are no longer contained
19:30:56 <fantasai> emilio: contain can be dependent on DOM content sof an element
19:31:06 <fantasai> emilio: There are sleectors already that depend on contents of the element
19:31:27 <fantasai> chrishtr: ...
19:31:34 <fantasai> TabAtkins: You cannot have selectors that depend on style
19:31:42 <fantasai> TabAtkins: Filing an issue won't solve it.
19:31:46 <fantasai> TabAtkins: We can't do that.
19:31:58 <Rossen> q?
19:32:19 <xfq> q- fr, fl
19:32:22 <Rossen> ack all the florians
19:32:28 <fantasai> florian: Mentioned about testing and things, at the moment we have reasonably extensive testing of normal counters
19:32:34 <fantasai> florian: If lists are fake counters, that's not tested separately
19:32:41 <fantasai> florian: I couldn't find tests for shadow DOM and display: contents
19:32:47 <fantasai> florian: BUt for normal counters, should be well-covered
19:32:50 <Rossen> q?
19:33:00 <fantasai> TabAtkins: Given large number of inconsistencies in lists from when I was testing them awhile back....
19:33:07 <fantasai> florian: Checking for what ti's supposed to do to counters.
19:33:20 <fantasai> florian: If you toggle contain on/off, we don't have tests for that.
19:33:26 <fantasai> florian: But effect of contain on counters, we do have tests
19:33:36 <fantasai> TabAtkins: Thanks for test suites
19:33:41 <fantasai> florian: Thank gtalbot
19:34:15 <fantasai> Rossen: Hearing pushback from Mozilla
19:34:23 <fantasai> Rossen: Not hearing much from other vendors
19:34:30 <fantasai> Rossen: What do we want to do next?
19:34:33 <fantasai> fantasai: Rename it, obviously.
19:34:42 <fantasai> Rossen: Or we can drop it
19:34:50 <fantasai> emilio: Can we drop contain: style and if we decide it's a thing we want
19:34:59 <smfr> smfr has joined #css
19:35:22 <fantasai> TabAtkins: Drop style now, figure it out later, decide what to do about 'strict' and whether to make it stricter or add a stricter value?
19:35:56 <fantasai> fantasai: Might be able to slip it in, because unlikely to be dependent on leaking counters/quotes
19:36:07 <fantasai> TabAtkins: Quotes definitely rare. Unsure about counters.
19:36:19 <fantasai> emilio: ...
19:36:39 <fantasai> Rossen: We could try dropping style now, and see if counters surface as a prominent use case, then deal with it
19:36:54 <fantasai> TabAtkins: What do you think, Chris
19:37:15 <fantasai> chrishtr: Drop it from the spec, but leave it implemented in one browser?
19:37:19 <fantasai> TabAtkins: No, that'd be a spec violation
19:37:36 <fantasai> gregwhitworth: It's implemented and shipping in a browser, but it doesn't work
19:37:44 <fantasai> TabAtkins: It does for real counters, if you have no dynamic changes
19:38:19 <fantasai> hober: It's up to them what they ship in the browser.
19:38:41 <fantasai> Rossen: So would there be an objection to dropping 'contain: style'?
19:39:10 <hober> s/in the browser/in their browser. It's up to us what we have in the spec./
19:39:15 <fantasai> emilio: My point for dropping it now is that it's the same kind of risky change to change Blink's lists to use real counters as it would be to drop 'style' / implement later
19:39:23 <fantasai> emilio: The case of having 'contain: style' that spans across a list
19:39:24 <futhark> futhark has joined #css
19:39:31 <fantasai> emilio: or counters inside a 'contain: style' subtree
19:39:38 <fantasai> emilio: Until Lists work that way, you're going to break something
19:39:56 <fantasai> TabAtkins: If our counter impl is already broken and weird, so it probably doesn't matter if we leave the code in?
19:40:11 <fantasai> chrishtr: What would likely happen is that we wouldn't remove the feature, we'd fix it
19:40:23 <fantasai> chrishtr: I'd rather fix it in Chrome and work through the spec issues than drop it
19:40:30 <fantasai> chrishtr: What we do with the spec in teh meantime
19:40:45 <fantasai> eae: It's something we really want to do in Blink, and we do realize that the current state of thing where e.g. Lists don't work that way
19:40:54 <fantasai> eae: So it might make sense to drop it for now
19:41:06 <fantasai> florian: If we drop now and add back later gets us to strict + stricter
19:41:13 <fantasai> florian: I'm not bikeshedding the stricter
19:41:27 <fantasai> emilio: We also want to ship containment
19:41:40 <fantasai> emilio: But we really don't want to implement 'contain: style' under the current state of affairs
19:41:48 <fantasai> emilio: Given it needs more work in specs and implsmentations
19:41:57 <TabAtkins> q+
19:42:04 <fantasai> emilio: It would make sense not to block shipping containment on 'contain: style'
19:42:17 <fantasai> chrishtr: Was there a compat issue?
19:42:26 <fantasai> emilio: No, but we don't want to willfully violate the spec.
19:42:42 <fantasai> emilio: We don't want to parse a value and then not implement it
19:42:47 <fantasai> (That is in fact a violation of the CSS spec)
19:42:55 <fantasai> TabAtkins: Is it just about built-in lists or all counters/
19:43:01 <fantasai> emilio: It's generally hard to implement in our counters implementation
19:43:12 <xfq> ack Tab
19:43:13 <fantasai> TabAtkins: I'm wondering how difficult it is from doing a counter-reset on all possible counters?
19:43:38 <fantasai> dbaron: I think in our counters implementation, the right thing to do is just create a new counter-manager for an element that has 'contain: style'
19:43:42 <fantasai> dbaron: And then it's reasonable
19:43:51 <fantasai> emilio: And then dynamic changes, you'd have to reframe
19:44:04 <fantasai> dbaron: You'd have to reframe anywya
19:44:23 <fantasai> TabAtkins: You can make it as slow as you want to change 'contain'. It's not a use case to flip it dynamically.
19:44:38 <fantasai> florian: Unless I missed something, counters have a definition problem. CSS 'contain: style' doesn't.
19:44:53 <fantasai> florian: There's a dependency, but I think implementation and spec being wrong is an overstatement
19:45:11 <fantasai> TabAtkins: Lists spec having bugs is adequate to say there's a spec problem.
19:45:28 <futhark> futhark has joined #css
19:45:40 <fantasai> florian: My point is, if there's a problem with the contain spec there needs to be an issue so I can fix it. But there isn't.
19:45:47 <fantasai> TabAtkins: ...
19:46:20 <fantasai> emilio: What would be the best way for Mozilla to ship contain: layout
19:46:32 <fantasai> florian: Could just not ship strict yet, then ...
19:46:52 <fantasai> TabAtkins: People are reasonably encouraged to turn on strict, so technically the right way to do it, but don't think it's good advice
19:46:55 <fantasai> q+
19:47:16 <rego> neither contain:strict neither contain:content (as both include style)
19:47:30 <xfq> ack fantasai
19:47:35 <heycam> fantasai: I think the right way to go is to ship everything except the style value itself
19:47:44 <heycam> ... and then at some future point, incorporate that into strict
19:47:53 <heycam> ... in the majority of cases it's not going to have an effect, so I don't think it's something to be too worried about
19:48:13 <fantasai> emilio: it would be nice if Blink didn't parse 'style' either, and we could do that change together later
19:48:36 <fantasai> florian: When you say don't do style, did you also mean change tehavior of strict later when we add it?
19:48:37 <heycam> fantasai: yeah, we will eventually change the behavior
19:48:39 <fantasai> fantasai: Yes
19:48:53 <fantasai> chrishtr: You said it's not so easy to implement contain: style
19:48:57 <fantasai> chrishtr: How hard is it?
19:49:01 <fantasai> emilio: How hard is it?
19:49:09 <fantasai> chrishtr: Couple months of work?
19:49:13 <fantasai> emilio: It's work, that somebody needs to do
19:49:23 <fantasai> TabAtkins: Given taht I do have a direction for naming in the future
19:49:31 <fantasai> TabAtkins: I'm OK with dropping style for now
19:49:39 <fantasai> TabAtkins: Dropping from definition of strict, dropping as a value
19:49:51 <fantasai> TabAtkins: And then we add 'all' later, that does all 4
19:50:03 <fantasai> TabAtkins: Do that once our implementation is good enough to be meaningful for style
19:50:10 <fantasai> TabAtkins: And Mozilla can also fix
19:50:14 <fantasai> emilio: And add a bunch of tests :)
19:50:31 <fantasai> chrishtr: So what you're suggesting is to refactor spec so that easier to incrementally add in the future
19:50:43 <fantasai> TabAtkins: Right, drop 'style' and add it back in a future level of the spec
19:51:00 <fantasai> chrishtr: What if we do the other things you mention and leave style?
19:51:10 <fantasai> TabAtkins: Drop style containiment from strict and content?
19:51:24 <fantasai> dholbert: That would make us reject 'contain: style' but...
19:51:33 <fantasai> chrishtr: CSS parsers can ignroe keywords they don't understand?
19:51:48 <fantasai> florian: If you as an author writes 'contain: style size" it'll be lost
19:52:01 <Rossen> q?
19:52:04 <fantasai> florian: but if you write 'contain: size; contain: style size' then you just lose the second declaration keep the first
19:52:10 <fantasai> TabAtkins: Most of the time we recommend strict anyway
19:52:19 <fantasai> florian: Seems like least harmful way to do this
19:52:30 <fantasai> chrishtr: And then we'll fix our bugs and allow ppl to opt in
19:52:43 <fantasai> Rossen: Any objections?
19:53:01 <fantasai> RESOLVED: remove style containment from keywords that aren't 'style'
19:53:07 <fantasai> RESOLVED: mark 'style' at risk
19:53:58 <fantasai> RESOLVED: Republish CR of css-contain once edits are in
19:54:26 <fantasai> chris: Ping me when you have a DoC and file a transition request
19:55:29 <emilio> Topic: :host-context
19:55:31 <emilio> github: https://github.com/w3c/csswg-drafts/issues/1915
19:55:56 <fantasai> emilio: When looking into this stuff, what I didn't implement which Apple also doesn't, is because it's really slow
19:56:29 <fantasai> emilio: Reason why it's really slow is that for every class change, you either need to store everything for the whoel docuemnt, or you need to look at every shadow root that has a host context selector, and go through all the shadow roots inside your subtree to check if they have a relevant host-context rule...
19:56:40 <fantasai> emilio: Handling DOM changes when host-context selectors are involved
19:56:53 <fantasai> emilio: Blink solves this by doing subtree restyles?
19:57:12 <fantasai> futhark: So in Blink we aggregate style info at the docuemnt scope for everything
19:57:22 <fantasai> futhark: we don't use subtree calc
19:57:29 <fantasai> futhark: We invalidate inside the shadow root
19:57:37 <fantasai> futhark: We use a flag for it
19:57:53 <fantasai> emilio: One of the nice things in our impl is that the style info inside the shadow root is contained
19:57:59 <fantasai> emilio: Blink wants to make such a change, too
19:58:10 <fantasai> emilio: So effectively it's similarly slow as /deep/
19:58:18 <fantasai> emilio: Since I haven't seen anything in Bugzilla requesting it
19:58:27 <fantasai> emilio: And WebKit also hasn't implemented
19:58:29 <fantasai> emilio: So would like to drop
19:58:46 <fantasai> futhark: I don't have the usage numbers...
19:58:51 <fantasai> TabAtkins: We should see if it's used
19:58:59 <futhark> futhark has joined #css
19:59:02 <fantasai> TabAtkins: It offers a useful functionality but if ppl aren't suing it, I"m fine with dropping it
19:59:12 <fantasai> Rossen: So, collect data, come back and based on this we can move forward
19:59:34 <fantasai> fantasai: So maybe flag for next F2F so we don't forget
19:59:40 <fantasai> Rossen: Hope to get to it before
19:59:49 <fantasai> Topic: end
19:59:53 <futhark_> futhark_ has joined #css
20:00:35 <fantasai> christr: When is transform breakout?
20:00:38 <fantasai> TabAtkins: 2-3pm
20:00:44 <fantasai> <br type=lunch>
20:00:53 <futhark> futhark has joined #css
20:02:46 <plh> plh has joined #css
20:37:44 <mstensho> mstensho has joined #css
20:41:24 <bdc> bdc has joined #css
20:52:08 <Karen> Karen has joined #css
21:03:43 <futhark> futhark has joined #css
21:03:46 <xfq> xfq has joined #css
21:04:08 <jensimmons> jensimmons has joined #css
21:04:12 <myles__> myles__ has joined #css
21:04:22 <myles__> ScribeNick: myles__
21:04:55 <smfr> smfr has joined #css
21:06:11 <fantasai> Topic: High Constrast
21:06:17 <fantasai> s/Const/Con/
21:06:24 <bdc> bdc has joined #css
21:06:52 <myles__> melanierichards: We’ve been talking through OS and browser features and how they relate to user preference media queries in lvl 5 spec. We support high contrast in Windows Ease of Access. How does it fit with standards?
21:06:59 <myles__> melanierichards: Let’s go over how it works on Windows!
21:07:13 <myles__> melanierichards: also let’s make a proposal for how it might be standardized
21:07:50 <myles__> melanierichards: Dark Mode, or other color schemes that are set on the OS level. The suer can select a certain theme. This is mostly art directed on the side of the OS or the app that wants to support it. There’s not granular control from the user over these colors
21:08:22 <myles__> melanierichards: We also have inverted colors on various platforms. It’s a heavy-handed filter across the OS. Includes app and web. Some apps may do some smart things. This doesn’t change the contrast story
21:08:40 <myles__> melanierichards: We also have high contrast text, which is an experimental feature on android. This sets all text to white or black. This doesn’t change the background.
21:09:06 <myles__> melanierichards: There’s also “increase contrast” on macOS and iOS for UI bits It’s somewhere inbetween medium contrast and high contrast
21:09:34 <myles__> melanierichards: There’s a Chrome extension that does high contrast. There are a few strategies. 1. Something similar to Windows high contrast: Yellow on black, 2. Greyscale 3. Something similar to macOS and iOS
21:09:41 <myles__> melanierichards: Then there’s Windows High Contrast feature.
21:09:56 <xfq> https://www.w3.org/TR/WCAG21/#contrast-minimum
21:10:04 <myles__> melanierichards: Here, the user can select a preset theme, or create a new theme, and have that part of everything on the OS. Apps support it within app content.
21:10:08 <plh> plh has joined #css
21:10:12 <myles__> Rossen: Demo of high contrast
21:10:55 <myles__> Rossen: I’m just going to minimize this for a second and make sure we are connecting and I’m going to let this thing
21:11:20 <myles__> Rossen: High contrast on windows is a system-wide accessibility setting
21:11:42 <mattwoodrow> mattwoodrow has joined #css
21:11:56 <myles__> Rossen: Doing a live demo is always fun. Let’s keep it positive and make sure everything works.
21:12:56 <myles__> Rossen: High Contrast is a predefined theme of system colors that apply to the entire shell as well as any applications that care to implement it. All first-party applications in Microsoft implement it both in UI and in the content layer,a nd there’s a large number of 3rd party applications that opt in
21:13:03 <myles__> Rossen: Win32 apps will be forced into high contrast.
21:13:23 <myles__> Rossen: Let’s apply high contrast. Everything needs a refresh. The shell needs to repaint all the different applications, and the shell itself.
21:13:53 <plh_> plh_ has joined #css
21:14:41 <myles__> Rossen: Twitter has no modifications at all, and Edge simply does the right thing on Twitter’s website. On the UI, all the colors are stripped down to the theme that is defined. All the text is white, all the hyperlinks are yellow, selected text is black on turquoise, buttons have .... etc. etc.
21:15:26 <myles__> Rossen: Limited palette of colors that apply everywhere. The promise of accessibility high contrast is that no matter what user preferences are set... some people want low contrast .... This is all driven on user preference. The default theme is black in Windows, but this is not dark mode.
21:15:31 <myles__> Rossen: This is not supposed to be dark mode.
21:15:36 <myles__> Rossen: Please hold questions to the end.
21:15:49 <myles__> Rossen: Links are yellow, text is white, black is reduced down to black.
21:15:58 <myles__> Rossen: YouTube!
21:16:39 <myles__> Rossen: The one thing we do in Edge is, besides mapping to all the proper system colors for high contrast, we also guarantee that behind every piece of text that we render, we have a background that uses the system background color. This is a feature we call “backlight”
21:16:45 <myles__> Rossen: Bing search!
21:17:19 <myles__> Rossen: The web authors take advantage of high contrast. Here’s an image that’s 2D canvas that renders a map using different color schemes using the fact that it’s in high contrast. The experience is richer.
21:17:27 <myles__> Rossen: Flickr is image rich.
21:17:56 <myles__> Rossen: If I mouse-over any images, there’s text that describes the image and the author, etc. Behind every piece of text we guarantee there is a background against the foreground with those same system colors
21:18:07 <myles__> Rossen: Switching to my remote machine in Redmond...
21:18:17 <myles__> Rossen: Let’s let it connect.
21:18:24 <myles__> Rossen: Let’s look at IE while it connects.
21:18:43 <myles__> Rossen: Our first implemention: I wasn’t involved. They didn’t know how to handle background images, for text on top of images.
21:18:46 <bgirard> bgirard has joined #css
21:18:59 <astearns> s/backlight/backplate/
21:19:14 <myles__> Rossen: So they just got rid of all background images, that will guarantee high contrast. Which was true for text... but as sites became more and more dependent on images, made sites unrecognizable.
21:19:33 <myles__> Rossen: Bing won’t be happy if we do this.
21:19:55 <myles__> Rossen: Firefox takes good advantage of high contrast. They have a setting that says “in high contrast, use the system colors” and they will map everything but the link colors to high contrast.
21:20:41 <myles__> Rossen: Last but not least, I don’t have the Chrome extension, but I have a prototype on my dev box where I implemented the same level of support for high contrast as Chromium as a proof of concept to see what it would take.
21:21:01 <myles__> Rossen: The same thing can be achieved
21:21:21 <myles__> Rossen: E.g. for Bing, this site takes advantage of the high contrast theme, same thing for Flickr.
21:21:39 <myles__> Rossen: The highlights have text that is composed against an opaque background.
21:21:46 <myles__> Rossen: That’s everything I wanted to demo.
21:22:02 <myles__> Rossen: Let’s finish the deck before questions and answers.
21:22:19 <myles__> Rossen: PowerPoint is in high contrast ofc because my machine is in High Contrast.
21:22:31 <myles__> Rossen: I just created a theme for fun which has low contrast. And here it is! (It’s blue)
21:23:07 <myles__> melanierichards: Shows a table to show a feature comparison
21:23:11 <fantasai> Table: Related OS/extension feature comparison
21:23:14 <myles__> melanierichards: Inverted colors and high contrast are forced on user
21:23:31 <fantasai> Column headings: Dark Mode, Inverted Coors, Text Contrast, Inreas Contrast, High Contrast extension, High Contrast
21:23:49 <fantasai> Row headings: supported Platform, contrast "promise", Applies to, Modifieable by users, Forced to Web content, ....
21:23:51 <myles__> Everything else uses a user preference. Not too much modification by users. For other features, like selection of theme, manageability by the user is in Windows High Contrast. We can apply a theme that is along the entire spectrum of contrast
21:23:57 <fantasai> Table: CSS Fetaures Comparision
21:24:10 <fantasai> Columns: prefers-color-scheme, prefers-contrast, inverted-colors, high-contrast
21:24:15 <myles__> melanierichards: prefers-color-scheme: Here’s the color scheme this user prefers, please author make something that matches
21:24:32 <fantasai> Rows: Related browser/OS features, granularity of detection in Web content, expectations on author, additional info available to author, implementations
21:24:34 <myles__> melanierichards: prefers-contrast: just low and high. There’s an issue from Apple to introduce an “increased” keyword for an intermediary level
21:24:50 <myles__> melanierichards: We might want to provide guidance to authors for which ratios to use, if they want to match the user preferences
21:25:06 <myles__> melanierichards: Inverted colors is a feature where we’re tartgetting activation for the feature rather than a couple difference points
21:25:36 <myles__> melanierichards: based on the way w’ere targeting inverted colors and high contrast, high contrast would be a good for the feature itself. A few reasons. The user can do many things with it. It’s not just a color scheme or just high contrast
21:26:04 <myles__> melanierichards: It’s like everything together. We expect most of the time it’s just going to work. Authors should just tweak a few simple things. Similar to inverted colors b/c a user preference is the highest directive. It’s forced onto web content.
21:26:32 <myles__> melanierichards: High contrast as an Ease of Access feature, it’s on 4% of installations. This means it’s the most popular assistive technology, by a large margin
21:26:47 <myles__> melanierichards: We want a consistent web dev story. Maintiain existing styles for IE, as well as new styles for modern browsers
21:26:58 <myles__> melanierichards: Authors are familiar with these. Authors can alias past styles and get the author styles for free
21:27:07 <myles__> melanierichards: We created an explainer. MS Edge Explainers Repo.
21:27:30 <astearns> https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/HighContrast/explainer.md
21:27:32 <myles__> melanierichards: We want to start the conversation about targeting high contrast. It explains how it works in Edge today, and what we can bring forward to allow all users on Windows to get this goodness
21:27:45 <myles__> melanierichards: If anyone else wants to implement a similar feature, they can do it as well
21:27:52 <myles__> melanierichards: high-contrast:active is a media query.
21:28:01 <myles__> You can also detect white on black or black on white
21:28:24 <myles__> melanierichards: authors can also make adjustments on various places by setting high-contrast-adjust:none on certain elements and adding back styles based on system colors
21:28:35 <florian> q+
21:28:41 <myles__> melanierichards: This makes it good for tweaking. Authors can maintain this.
21:29:00 <myles__> melanierichards: Somethign we dont’ have today is author control over the text backplate that is drawn behind text. We thing authors might want to adjust: corner radius, opacity, et.c
21:29:38 <myles__> Rossen: Two things that came up based on data from current usage: High contrast is by far the most used ability-improving feature on Windows today, compared to any other assistive technology
21:29:55 <myles__> Rossen: We used to have fairly large percent of usage of high-contrast-adjust property.
21:30:13 <myles__> Rossen: It was for a particular element or selector, i don’t want you to adjust the styles of this sub tree, i can handle it
21:30:27 <mstensho> mstensho has joined #css
21:30:47 <myles__> Rossen: That was a pretty high percentage. But it went almost to 0 after we added the backplate. Authors said that authors didn’t need to deal with getting the system colors, instead they just let the browser do it.
21:31:02 <myles__> Rossen: Facebook removed their use of it because the backplate was sufficient for them.
21:31:08 <myles__> Rossen: Twitter was the same
21:31:55 <myles__> Rossen: The explainer, as we wrote it, was meant to capture the stature quo of what we have in Edge. All of our learnings and design of how we implemented everything. It goes through the way we apply styles in the cascade, how we override colors using the system colors, and how we ensure readability by calculating the bounds of any flow of text.
21:32:38 <myles__> Rossen: For this part I spend time, we have a research team that researches the cognitive process of reading, so I spent some time with them researching the backplate. How much padding, how much opacity, how much space to add between paragraphs, etc.
21:32:52 <myles__> Rossen: What I implemented in Edge is what they said was pretty optimal
21:33:35 <myles__> Rossen: But, high-contrast-backplate as an addressable thing that’s stylable with opacity or corner-radius, or padding... the padding isnt’ random, it’s based on fonts... that became an interesting feature that we can try to improve upon.
21:33:39 <Karen> Karen has joined #css
21:33:39 <myles__> Rossen: This is the story of high contrast.
21:34:15 <myles__> Rossen: I wanted to raise the awareness of what it is in Windows, how we implemented it, why it works, what the guarantees are, how it works with color schemes, filters, or features that targeting contrast, how are they similar and different.
21:34:28 <fremy> fremy has joined #css
21:34:51 <myles__> Rossen: High contrast improves readability. Or guarantee. Also, decreasing cognitive overload from all the different borders, colors, and everything you can have. Strips the colors, provides increased readability overall.
21:35:09 <xfq> q?
21:35:09 <myles__> Rossen: Questions
21:35:12 <emilio> q+
21:35:13 <xfq> ack fl
21:35:18 <AmeliaBR>  q+
21:35:24 <smfr> q+
21:35:40 <myles__> Florian: I was worried about taking the problems one by one, and resulting int 5 different things. Thanks for looking at it from that angle.
21:36:08 <myles__> florian: For high contrast specifically, I understand how it works and why it’s useful, I’m more concerned about the media query itself because this feature can do anything and everything
21:36:19 <myles__> florian: Does it expose all of that?
21:36:42 <myles__> florian: I don’t know how we would expose more information... how that you said you’re doing it well enough, maybe we don’t need a media query at all.
21:36:48 <tantek> As in, what's the summary of webdev use-cases?
21:36:48 <xfq> Related CSSWG issue: https://github.com/w3c/csswg-drafts/issues/1286
21:36:58 <myles__> florian: HOw do we make sure we don’t increase the contrast when the user wanted the opposite?
21:37:43 <myles__> Rossen: I won’t defend the name. The original author thought it was for high contrast. If I wanted to rename it today, I would have picked something else... maybe not enforced-colors .... biggest benefit is about readability everywhere. Reducing cognitive load. I don’t’ know a good name.
21:37:45 <florian> q-
21:38:44 <myles__> Rossen: The additional part where people can take advantage of it is with canvas example. People can query for high contrast and take completely different experiences with it. In this case it’s canvas.
21:39:14 <myles__> Rossen: We need to be able to give the signal and say “the user has chosen high contrast (or whatever we call it) and this is their preference and we’re going to honor it, because the user has the highest rank in the order of preferences)
21:39:49 <myles__> florian: Some users use this for dyslexia. Some users use it for other purposes. How do we make sure it turns out correctly?
21:39:58 <myles__> Rossen: Sites that use high-contrast should use system colors
21:40:01 <astearns> zakim, close queue
21:40:01 <Zakim> ok, astearns, the speaker queue is closed
21:40:03 <myles__> fremy: yes
21:40:07 <astearns> q?
21:40:30 <dbaron> Should we make the system colors work for platforms other than Windows...?
21:40:35 <myles__> florian: We need 2 things: 1) The author has all the information they need to do the right thing, rather than something, and 2) we need to not trick users into thinking this is just for high contrast
21:40:35 <florian> q+
21:40:49 <xfq> ack emilio
21:40:52 <fantasai> +1 to florian
21:40:59 <myles__> emilio: This is great.
21:41:37 <myles__> emilio: How does the adjust property work in Edge? Before applying any property, you need to know the adjust value, so you need to do a pre-pass to figure out what the adjust value is?
21:41:46 <myles__> Rossen: Yes. We have env() already, maybe we can use that
21:42:18 <myles__> Rossen: It should be as simple as: If I want to adjust, I will use system values, you give me the values, if they change, you go and re-apply them for me.
21:42:26 <myles__> Rossen: Currently, people fetch system colors and they ...
21:43:06 <florian> s/rather than something/rather than just doing something which might not match what what the user wanted/
21:43:07 <myles__> emilio: When you’re doing the cascade, if you need to know the value of the adjust property in order to determine the value of allt eh other properties. This requires a 2-pass style resolve.
21:43:20 <gtalbot> gtalbot has joined #css
21:43:21 <myles__> Rossen: you need the computed value of adjust before you get the rest of the style.
21:43:25 <myles__> Rossen: Let’s take this offline.
21:43:28 <myles__> emilio: ok
21:43:35 <myles__> emilio: 👍
21:43:35 <xfq> ack Am
21:44:47 <myles__> AmeliaBR: System colors are deprecated. There’s also one missing. I like the idea of doing it with environment variables, and I assume there’s some way to listen for when environment variables change, which can then help you with canvas drawing with system colors
21:45:39 <myles__> Rossen: That is all true. In fact, in Chromium on Mac, I immediately ran into an issue that I couldn’t compile because i couldnt’ find API to get the highlight link color, I found one option but it turned out to be wrong
21:45:51 <myles__> Rossen: On Windows, we have “top light” which is the highlight color for links
21:46:05 <myles__> Rossen: In edge, we support -ms-edge-top-light
21:46:12 <heycam> In Gecko internally we have a keyword for default hyperlink colors, but maybe we need to add a new system color for this?
21:46:16 <myles__> Rossen: On Windows, this is available
21:46:28 <myles__> Rossen: We didn’t not investigate Linux. I would love for someone to expand our knowledge on Linux
21:47:18 <myles__> AmeliaBR: The other part of what Edge that isn’t represented in standard CSS: The cascade order bit. I don’t know how they implementation works, but high-contrast can be implemented as user styles that override author styles, except when it’s in the @media rule. We don’t have any existing example of those. We’d need to specify how it works
21:47:28 <myles__> AmeliaBR: ... without using !important
21:47:56 <Rossen> https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/HighContrast/explainer.md
21:47:57 <myles__> Rossen: I discuss this in the explainer.
21:48:25 <myles__> Rossen: It is currently not well-defined by the cascade. If there are bits that need to be implemented, we’ll have to look through those.
21:48:29 <fremy> q?
21:48:34 <fremy> q+
21:49:18 <myles__> AmeliaBR: This is something you want not just for high-contrast mode, but for many of the media rules that are testing ... well it depends because some of the accessibility features operate at a CSS cascade leve and some operate at a filter level. But at a CSS cascade level, we’re going to want the same cascade order, but if you detect the feature and tweaking it, that needs to override the browse
21:49:19 <myles__> r overrides.
21:49:23 <myles__> Rossen: I agree.
21:49:39 <myles__> AmeliaBR: css-cascade and css-media-queries are involved.
21:49:41 <xfq> ack smfr
21:50:18 <myles__> smfr: When you start messing with page colors, one thing you often see is authors have baked colors into their images that are similar colors. Instead of alpha .pngs, images have white backgrounds. Have you thought about this problem?
21:51:11 <myles__> gregwhitworth: I wrote a blog post about this. Those 4% of users, Google is a big site that added it. Fundamentally, this allows people to use the content. If authors go back and want to use SVG, that’s okay, but this is about UX, not design. It’s a solution that can be solved.
21:51:20 <dbaron> This cascading thing sounds scary...
21:51:29 <astearns> +1 to that
21:51:40 <myles__> melanierichards: One of the authoring practices that we see.. YouTube uses it for ..... There are other instances where you might target the high contrast feature...
21:52:06 <myles__> melanierichards: One authoring practice that is great in YouTube in icons is using currentColor in fills in SVG. Doesn’t require anything to opt-into high contrast.
21:52:47 <myles__> fremy: There are a couple of ideas. If we use black on white, we can special case, but it’s a lot of special cases. We don’t bother. If you really care as an author, you can fix it. Impossible to get it right 100% of the time.
21:53:35 <myles__> Rossen: This is the first time we have officially introduced Windows High Contrast feature (even though it was mentioned in a bunch of places in media queries spec)
21:53:48 <myles__> Rossen: Do we need a resolution to add this to the CSSWG charter as something we want to work on?
21:54:24 <myles__> Rossen: We’ve already touched on a number of points where this isn’t just relevant to media queries, it’s also cascade and environment variables.
21:54:40 <myles__> Rossen: Perhaps the backplate is something else, too.
21:54:49 <TabAtkins> q+
21:55:26 <myles__> Rossen: As we work on this, we’ll find the right spots and the righ teditors.
21:55:32 <myles__> fantasai: I’m one of the editors.
21:55:37 <myles__> Rossen: yes.
21:55:51 <myles__> RESOLVED: Let’s look into high contrast support on the Web
21:56:22 <fantasai> Maybe s/high contrast/specific contrast/ since sometimes it's low contrast?
21:56:49 <myles__> florian: There are some related topics that weren’t included. Night mode, and boosting contrast when you go outdoors. We have some things to address that, but it overlaps with some of this.
21:57:40 <myles__> florian: The UA can automatically opt-in in these situations
21:57:43 <myles__> Rossen: Sounds reasonable
21:58:05 <myles__> fremy: Are you willing to simplify cascade changes to ease implementation burden?
21:58:21 <myles__> Rossen: yes. I tried to in Chromium and it worked great
21:58:36 <myles__> TabAtkins: The backplate looks just like captions. We can kill 2 birds with 1 stone
21:58:39 <myles__> Rossen: Yes
21:59:28 <myles__> Rossen: The reason I used this example is .... this is unreadable (points at unreadable text on the screen)
21:59:54 <myles__> Rossen: but if you enable high contrast, now you know that it’s Snowy Eagles
22:00:01 <myles__> Rossen: I’m going to stop while I’m ahead.
22:00:57 <futhark> futhark has joined #css
22:01:14 <fantasai> We're continuing on UI topics here, on breakout topic in breakout, and then coming back to dark mode later.
22:02:46 <bgirard> bgirard has joined #css
22:04:13 <emilio> github: https://github.com/w3c/csswg-drafts/issues/3344
22:04:16 <xfq> zakim, reopen the queue
22:04:16 <Zakim> ok, xfq, the speaker queue is open
22:04:25 <myles__> github: none
22:04:26 <emilio> github: none
22:04:43 <myles__> Topic: The computed value rules of user-select is problematic
22:04:51 <emilio> github: https://github.com/w3c/csswg-drafts/issues/3344
22:05:50 <myles__> emilio: user-select is messy. It’s inherited in some engines, but not in others. It has different initial values in some. I wanted to make it less insane, but the spec specifies that the initial value of the property si different depending on the element, which is not great.
22:05:59 <futhark_> futhark_ has joined #css
22:06:18 <myles__> emilio: Depending on whether the element is editable or not, the initial value is different. I like when my initial styles are all shared.
22:06:39 <myles__> emilio: There is an unspecified value, but it computes to something at computed value times, was to support user-select:contain, IIRC
22:07:28 <myles__> emilio: I don’t want the computed value to be differ depending on which element the style applies to. We should do something closer to what Gecko does, which is close to WebKit and Blink. The initial value is auto, and once you specify it, that inherits down the tree
22:08:27 <myles__> emilio: Proposal is to make it non-inherited. Initial value is auto, and auto behaves differently depending on which element it applies to at used-value time
22:08:49 <mstensho> mstensho has joined #css
22:08:54 <myles__> florian: I was on an agreement rollercoaster
22:09:31 <myles__> florian: user-select:contain, only Edge exposes as a value, but all browsers have as a behavior. This is how selection works when you’re in an editable element. Selection can’t escape that element. All browsers do that. In Edge, that’s explained by the user-select:contain
22:09:43 <myles__> florian: Now that it’s a value, you can apply that value to other things.
22:09:59 <myles__> florian: Maybe you want to contain your selection to the body of content, so you don’t select UI
22:10:14 <myles__> florian: Maybe we need selective inheritance. All values inherit, except “contain”
22:10:51 <myles__> florian: Propagation would work this way. So the child of contain should be something else, but otherwise things inherit normally. At computed-value time this would be easier. If from an implementor point of view at used-value time is simpler, okay
22:11:01 <myles__> florian: It’s almost the same thing.
22:11:24 <myles__> florian: To support user-select:all, you might have to implement it anyway. The user difference is inexistant. Is it simpler in other engines?
22:11:55 <myles__> emilio: The current spec says “the property is reset in certain places, the property is not inherited, all values except contain effectively inherit, so you end up needing to change all engines to copy-on-write, which WebKit, blink, and Gecko do
22:12:10 <myles__> florian: it’s not inherited. If the value is auto, look at the parent.
22:12:26 <myles__> koji: Blink already experienced that once before, but used value is easier for us, too
22:12:30 <myles__> florian: okay
22:12:55 <myles__> emilio: Using this at computed value time means it breaks style system optimizations that assume non-inherited styles change, don’t need to restyle children.
22:13:13 <myles__> emilio: Also, given the initial value depends on the element it applies to, you no longer have a canonical initial value representation. Used value is better
22:13:28 <myles__> florian: Is it reasonable to assume webkit’s cooperation?
22:14:11 <smfr> smfr has joined #css
22:14:25 <smfr> smfr has joined #css
22:14:30 <myles__> astearns: proposed resolution: auto computes to auto, but the used value does what it currently says auto computes to
22:15:16 <smfr> smfr has joined #css
22:15:18 <myles__> dholbert: This needs to be reflected in the used value, too
22:15:31 <myles__> RESOLVED: auto computes to auto, but the used value does what it currently says auto computes to
22:15:56 <myles__> florian: There is some more magic here. Currently, on editable elements, the computed value is always contain, regardless. Should we keep it at computed value time or used?
22:16:03 <myles__> emilio: UA rule, so it can be override it.
22:16:14 <myles__> florian: We didn’t want it to be overridable
22:16:24 <myles__> emilio: Gecko allows it to be overridden. But it’s fine
22:17:36 <heycam> ScribeNick: heycam
22:17:41 <heycam> Topic: appearance
22:17:51 <heycam> github: 1324
22:18:08 <heycam> florian: I can do a progress report
22:18:14 <heycam> ... zcorpan elika and I discussed this
22:18:17 <heycam> ... we reached an agreement
22:18:17 <astearns> github: https://github.com/w3c/csswg-drafts/issues/3024
22:18:23 <heycam> ... last time we appearaed to have opposing visiions
22:18:26 <heycam> ... we no longer do
22:18:39 <heycam> ... we've fixed the high level mechanics part of the spec based on that agreement
22:18:51 <fremy> fremy has joined #css
22:18:58 <heycam> ... and there remained the details about small exceptions/tweaeks for web compat on top of that general principle
22:19:08 <heycam> ... the parts that haven't been made should be marked as open issues in the spec
22:19:17 <heycam> ... afaik we now have a model that everyone agrees about
22:19:23 <heycam> iank_: 2 sentence tldr?
22:19:41 <heycam> florian: the appearance property with a gazillion values for expressing UA sheet is not what we're going to do
22:19:45 <fantasai> Spec https://drafts.csswg.org/css-ui-4/#appearance-switching
22:19:49 <heycam> ... the model is based on auto/none, initial value none
22:19:57 <heycam> ... UA sheets to auto on all elements that need special behavior
22:20:03 <heycam> ... due to HTML semantics they'll look right
22:20:06 <heycam> ... that's not sufficient for webcompat
22:20:11 <heycam> ... maybe 6..12 values that are used by authors
22:20:22 <heycam> ... most of them can be made to do the same thing as auto
22:20:33 <heycam> ... we're not interested in allowing people to turn drop down menus into checkboxes
22:20:51 <heycam> ... if you use any of the non-none values on a form control, it will be its normal self, with a few special exceptions
22:21:02 <heycam> fantasai: there were a a couple of values that will work on other elements
22:21:05 <heycam> florian: like button
22:21:08 <heycam> ... to buttonize an element
22:21:14 <heycam> ... we have specified that
22:21:16 <heycam> fantasai: and textfield
22:21:29 <heycam> iank_: looks like zcorpan did a good job doing compat analysis based on our data
22:21:51 <heycam> florian: we're kind of close to the high level model we had previously, but the details that are necessary for web compat is mostly coming from zcorpan
22:21:58 <heycam> ... and both sides of that discussion is happy with the other
22:22:03 <heycam> fantasai: you me francois and zcorpan
22:22:18 <heycam> astearns: there were a few things remaining that should be spec issues?
22:22:24 <heycam> florian: there are places in the spec with issue boxes already
22:22:30 <heycam> ... details needed based on compat info
22:22:42 <heycam> fantasai: we should at some point resolve and publish a draft
22:22:46 <heycam> ... and continue filling in details
22:22:46 <atrigent> atrigent has joined #css
22:22:48 <myles__> myles__ has joined #css
22:22:59 <heycam> florian: I need to refresh my memory on the exact status of it all
22:23:13 <heycam> fantasai: high level summary is: we have an appearance property, initial value is none
22:23:27 <heycam> ... it has the values none | auto | button | textfield and a bunch of compat keywords that map to auto
22:23:32 <heycam> ... UA sheet sets auto on most form controls
22:23:42 <heycam> ... then there are some tweaks for compat from now on
22:23:52 <heycam> astearns: that's in the ED now?
22:23:53 <heycam> fantasai: yes
22:24:23 <heycam> astearns: sounds like we can close this issue as addressed in the draft, and publish a draft, and open new issues for specific things
22:24:39 <heycam> florian: as for publishing, we should do it after I apply the edits from the user-select dicsussions
22:24:47 <heycam> ... I'll add those in then put a WD out
22:25:00 <heycam> astearns: so let's resolve now to resolve this issue with what's in the draft and with an intent to publish after the edits
22:25:38 <heycam> RESOLVED: Close this issue as addressed, then publish a new WD once pending edits for this spec are done.
22:25:54 <heycam> zcorpan_++
22:26:22 <fantasai> Topic: Outline around descendants
22:26:27 <fantasai> ScribeNick: fantasai
22:26:32 <astearns> github: https://github.com/w3c/csswg-drafts/issues/2846
22:26:54 <fantasai> heycam: A little whiel ago I bourgh tup the fact that in Gecko we include a lot of descendant boxes when rendering outlines
22:26:59 <fantasai> heycam: and we do get some compat issues from that
22:27:20 <fantasai> heycam: because essentially in Blink and WebKit, and I didn' trecently test Edge, outline only is derived from the position and size of that element's principle box
22:27:23 <fantasai> s/principle/principal/
22:27:29 <fantasai> heycam: Different things happen
22:27:40 <fantasai> heycam: but the important difference is that no descendants contribute to the outline position or size
22:27:50 <fantasai> heycam: Definition fo outline in the spec is deliberately vauge so that UAs can do something fancy
22:27:52 <fremy> q+
22:28:05 <fantasai> heycam: but there is a suggestion that descendants should contribute to the outline
22:28:10 <mstensho> mstensho has joined #css
22:28:17 <fantasai> heycam: but I'm suggesting that we switch the suggestion to say that they should not
22:28:20 <fantasai> iank_: ...
22:28:53 <fantasai> iank_: The tl;dr is that there's the outline proeprty which renders one way, and e agree that it shouldn't include descendants
22:29:02 <fantasai> iank_: but then there's the focus outline, when an element is focusable and you focus it
22:29:07 <fantasai> iank_: You might want to handle that a different way
22:29:11 <fremy> q- since I was basically gonna bring up the focus outline side of things
22:29:15 <fremy> 1-
22:29:18 <fremy> q-
22:29:25 <fantasai> florian: The spec view of the problem is that there's an outline -style called auto, which allows you to be crazier in how you do your outline
22:29:29 <fantasai> florian: You can do whatever you want
22:29:39 <fantasai> florian: Intent is that browsers implement focus outline with that
22:29:51 <fantasai> florian: What UAs actually do, may be it's different
22:30:16 <fantasai> emilio: outline-style: auto not only changes shape of outline, but also uses the system focus outline style
22:30:28 <fantasai> emilio: Firefox does something weird on Linux, because bugs, but that's it
22:30:33 <fantasai> emilio: it should otherwise match the OS
22:30:55 <fantasai> emilio: Not just about channging shape but also style
22:31:17 <fantasai> gregwhitworth: was curious about removing descendants from outline
22:31:25 <fantasai> gregwhitworth: I don't want removing descendants from focus to be the default
22:31:27 <fantasai> iank_: I think we agree
22:31:39 <fantasai> iank_: the behavior that I think we want is for the outline property, it doesn't include descendants
22:31:43 <fantasai> iank_: but for focus outline it does
22:31:46 <fantasai> florian: Define focus outline
22:32:31 <fantasai> gregwhitworth: Rob Dotson and Alice Boxhall were thinking that it shouldn't follow descendants
22:32:34 <fantasai> gregwhitworth: but currently it does
22:32:44 <fantasai> iank_: Why for focus outline, by default, should it enclose descendants?
22:32:48 <astearns> s/Dotson/Dobson/
22:33:03 <fantasai> gregwhitworth: Because the scenarios where it's a problem, I can find just as many where not enclosing is also a problem
22:33:18 <fantasai> gregwhitworth: Many cases where Chrome's rendering looks weird e.g. in FB on Chrome
22:33:25 <fantasai> gregwhitworth: Other cases it looks weird
22:33:33 <fantasai> gregwhitworth: e.g. wrapping around weird pseudo-elements
22:33:57 <fantasai> iank_: Would it change your opinion if it didn't have the weird squiggle and just had a bounding rect (instead of non-rectangular shape)
22:34:04 <fantasai> gregwhitworth: That's happening because looping in descendants
22:34:16 <fantasai> iank_: You could have an alternate implementation that's just a bounding rect
22:34:20 <fantasai> gregwhitworth: I'd be more OK with that
22:34:24 <bgirard> bgirard has joined #css
22:34:31 <fantasai> gregwhitworth: Saying that these few sites, we no longer care about descendants, seems odd
22:34:44 <fantasai> iank_: We need to check with Alice and Rob, but there disn't seem to be a use case for non-rectangular focus outline
22:34:52 <fantasai> iank_: thinking about simplifying and just doing the bounding box
22:35:02 <fantasai> iank_: Then the question is in that state, what's the best calculation?
22:35:03 <astearns> q?
22:35:18 <fantasai> fremy: Reason why important for focus outline to include descendants, e.g. if you have inline links and a position absolute element
22:35:42 <fantasai> fremy: If you don't include abspos element, you aren't able to actually show the focus ring around the link
22:35:52 <fantasai> fremy: I'm curious if you can do it with one single rectangle
22:36:14 <fantasai> fremy: because if the link element is in one part of the page but the abspos item that is the clickable target is elsewhere, there's a large rectangle around the page
22:36:18 <fantasai> heycam: ...
22:36:18 <myles__> myles__ has joined #css
22:36:25 <florian> q+
22:36:42 <bkardell_> can someone repeat what iank just said?
22:36:45 <fantasai> iank_: Splitting the discussion slightly, sounds like everyone would be fine if the non-auto outline style ...
22:37:02 <fantasai> iank_: sounds like we'd be fine with it not including descendants and just being the border box
22:37:09 <Rossen> [high contrast slides link] https://lists.w3.org/Archives/Public/www-archive/2019Feb/0000.html
22:37:13 <fantasai> florian: Want to clarify definitions
22:37:21 <fantasai> florian: The definition of focus outline that is in the issue that you refer to
22:37:30 <fantasai> florian: includes some cases of the proeprty-based outline
22:38:10 <rachelandrew> rachelandrew has joined #css
22:38:14 <fantasai> florian: In the issue now there is the definition of focus outline being either:
22:38:26 <fantasai> florian: a) the outline painted whichever way while the element is in focus or
22:38:31 <fantasai> florian: b) when the outline-style is auto
22:38:40 <fantasai> atotic: That's how it's implemented in Chrome atm
22:38:57 <astearns> ack florian
22:39:02 <fantasai> florian: Alternate definition is "only outline when element is in focus"
22:39:10 <fantasai> Another definition woudl be only when it's non-auto...
22:39:22 <emilio> q+
22:39:24 <fantasai> gregwhitworth: You need to be focussed and outline
22:39:44 <xfq> ack fantasai
22:39:56 <emilio> fantasai: so this definition is a little weird, let's say I set an outline: solid purple on a link
22:40:13 <emilio> fantasai: and the behaviour will change depending on whether we focus the link
22:40:45 <futhark> futhark has joined #css
22:41:30 <emilio> iank_: this is what we currently implement today
22:41:33 <emilio> fantasai: we need a definition that doesn't do that
22:42:03 <fantasai> fantasai: same outline derived from the same style rule shouldn't behave differently when I focus the element and then go back to behaving different when it's unfocus
22:42:13 <bkardell_> it is still a problem
22:42:20 <bkardell_> q+
22:42:31 <emilio> jensimmons: outline: 0 no longer appears on CSS resets anymore
22:42:45 <emilio> jensimmons: nor frameworks. Of course some people still do that but...
22:42:48 <florian> q+
22:42:48 <fantasai> jensimmons: Word has gotten out, don't do that. Of course ppl still do it, but it's getting better
22:42:52 <xfq> ack emilio
22:43:09 <fantasai> emilio: I'm a bit confused. Firefox used to conditionally include both in-flow and out-of-flow descendants for all kinds of outlines
22:43:11 <tantek> for the record, that was fixed in Eric Meyer's CSS Reset back in 2011: https://meyerweb.com/eric/tools/css/reset/
22:43:20 <fantasai> emilio: Then xidorn changed to only include in-flow elements
22:43:37 <fantasai> heycam: I think only for abspos
22:43:52 <fantasai> emilio: As far as I understand, one of the use cases we want to bring back...
22:44:02 <fantasai> emilio: Does Blink include auto flows in their descendant stuff?
22:44:07 <fantasai> s/auto flows/overflow/
22:44:15 <fantasai> s/overflow/out-of-flow/
22:44:30 <fantasai> atotic: It depends. Only if the outline is around the containing block
22:44:36 <fantasai> emilio: Ancestor containing block?
22:44:43 <fantasai> atotic: *emphatic shrug*
22:45:07 <fantasai> emilio: I agree thwith fantasai that having two different behaviors depending on whether focused or not is very weird.
22:45:14 <fantasai> emilio: Maybe take greg's advice to give authros control
22:45:36 <fantasai> atotic: Our behavior is OK because we don't do bounding box, if boxes are disjoint then they each get outlined
22:45:44 <fantasai> atotic: Now that merging boxes, less tolerable
22:45:52 <fantasai> florian: Two kinds of merging boxes
22:46:00 <fantasai> florian: One is when boxes are not next to each other, have a box around each
22:46:11 <fantasai> florian: Other is when they touch each other have either a non-rectangular outline that wraps both
22:46:17 <fantasai> florian: or boundign box
22:46:27 <gregwhitworth> I'm not seeing Chrome wrap this abspos in focus: https://jsbin.com/muyemusofo/1/edit?html,css,output
22:46:32 <fantasai> florian: E.g. For Presto, if two fragments being outlined are not adjacent, you get two outlines
22:46:45 <fantasai> florian: but if they are adjacent, you get one non-rectangular outline around the whole shape
22:46:49 <fantasai> florian: There are nuances within this
22:47:04 <fantasai> emilio: I think we should come up with a consistent plan
22:47:06 <florian> q?
22:47:09 <xfq> ack b
22:47:15 <iank_> q+
22:47:35 <fantasai> bkardell_: I think it is still a pretty significant problem that part of the reason historically that developers couldn't tap into the right thing to say whether you even should draw the outline because didn't have :focus-ring
22:47:53 <fantasai> bkardell_: Will help when :focus-visible is implemented everywhere. Also :focus-visible-within
22:48:03 <fantasai> bkardell_: I've seen a lot of ppl make comments about confusion around outline
22:48:11 <fantasai> bkardell_: Maybe we should really have two properties
22:48:26 <fantasai> fantasai: or a switch between behaviors
22:48:34 <fremy> q?
22:48:34 <fantasai> bkardell_: Using same thign for two purposes seems quite strange
22:48:46 <fantasai> bkardell_: We tell ppl don't use border, use outline for focus rectangles
22:48:50 <fantasai> bkardell_: So we could use borders
22:48:56 <fantasai> bkardell_: Maybe have a thing that's about focus rectangle
22:49:33 <fremy> +1 to what fantasai just said (minuted below)
22:49:47 <mstensho> mstensho has joined #css
22:50:16 <fantasai> fantasai: I think there was a proposal at some point to have 'outline-style: auto' be the one intended for focus rings, which has the special behaviors of going around descendants or being non-rectangular or whatever (up to UA)
22:50:37 <fantasai> fantasai: and other outline-style values give a more normalized outline shape, appropriate for extra "border" looking things
22:51:05 <xfq> ack fl
22:51:23 <astearns> q+ bkardell_
22:51:32 <fantasai> florian: We have half of this. When outline-style is auto, it's reasoanble to  assume this is being used for focus. I don't think ppl use it for decorative styles
22:51:41 <fantasai> florian: Other half is less clear. It's often used decoratively, but not strictly
22:51:42 <gregwhitworth> q+
22:51:53 <fantasai> florian: We can spec the auto style to be just the right thing for outline styles
22:52:00 <fantasai> florian: Maybe time will help
22:52:19 <fantasai> florian: When we get around finalizing spec and implementation, once we have multipel borders or gradients within borders, maybe ppl will use those instead of outliens
22:52:25 <gregwhitworth> inline desc are wrapped https://output.jsbin.com/gimiwigije/1
22:52:29 <fantasai> florian: but we don't have that yet. And might take awhile for ppl to move over
22:52:31 <fremy> q?
22:52:33 <emilio> q+
22:52:37 <xfq> ack iank
22:52:59 <fantasai> iank_: The otehr thing is for accessibility sue case, we don't ahve the right people in the room, so it will be a lot of tiem with our a11y experts to not break a11y in this space
22:53:04 <fantasai> fremy: I work on that, btw
22:53:15 <fantasai> gregwhitworth: melanierichards is also here
22:53:23 <xfq> ack bk
22:53:37 <fantasai> bkardell_: It feels like we're not really serving the best use cases that we could
22:54:05 <fantasai> bkardell_: Alice and I have talked around about this, just recently Eric Meyer was doing some stuff at An Event Apart, talking about his frustrations about how to make thigns that are both beautiful and accessible
22:54:09 <fantasai> bkardell_: it's pretty hard
22:54:39 <fantasai> bkardell_: You don't have a lot of control over what outlines can look like just with outline, and if you have a really beautiful design, you end up having to do a lot of design specifically for the outline as well
22:54:50 <tantek> Are there specific examples of such "really beautiful design" where this is a challenge?
22:54:50 <fantasai> bkardell_: A lot of OSes have developed what I assume is glowy outlines
22:55:07 <fantasai> bkardell_: an advantage is that there's a light path and a dark path, and you'll be able to see at least one of them
22:55:20 <fantasai> bkardell_: so when he was working on that, we came up with a hack to make multi-colored pseudo-border outlines that don't affet layout
22:55:32 <fantasai> bkardell_: we could serve taht better and more appealing, then more likely ppl make accessibile things
22:55:44 <fantasai> bkardell_: as Alice says, I assume devs want to do the right thing, just if we make it harder they're less likely to
22:55:50 <xfq> ack greg
22:55:57 <fantasai> gregwhitworth: I 100% agree with bkardell_
22:56:13 <fantasai> gregwhitworth: We are currently finishg up a study with 160 users on focus testing, for this reason
22:56:20 <fantasai> gregwhitworth: because we belive the one in Chromium is not sufficent
22:56:24 <fantasai> gregwhitworth: One issue is wht bkardell_ brought up
22:56:38 <fantasai> gregwhitworth: we also looked into prototyping always-visible outlines
22:56:43 <fantasai> gregwhitworth: to provide sufficient contrast
22:56:56 <fantasai> gregwhitworth: I saw emeyers' scenario of always wanting to ensure high contrast
22:57:11 <fantasai> gregwhitworth: What's interesting is that Mozilla has a property that they propsed eyars ago to effectively provide an inversion color as a color keyword
22:57:20 <fantasai> gregwhitworth: so you can use a keywrod where youc an't sue the inversion value
22:57:28 <fantasai> gregwhitworth: It's just that it looks realy gross when you want a great design
22:57:33 <fantasai> gregwhitworth: two things taht came up out of that testing
22:57:44 <fantasai> gregwhitworth: one, doing a good focus rect in browser sucks
22:57:50 <fantasai> gregwhitworth: doesn't follow border radius is problematic
22:58:00 <fantasai> gregwhitworth: I had to hack with border outline and drop-shadow to get the right effect
22:58:09 <fantasai> gregwhitworth: I think we should tease out the pieces of following the rect
22:58:13 <bkardell_> tantek does greg's expanding answer your question?
22:58:18 <fantasai> gregwhitworth: also want to have gradient
22:58:25 <fantasai> gregwhitworth: Similar to ...
22:58:43 <fantasai> gregwhitworth: In addition, emilio's proposal of whether or not you want to include descendants or not
22:58:51 <fantasai> gregwhitworth: will share more publicly once we have the report
22:58:57 <fantasai> emilio: what he said.
22:59:01 <xfq> q?
22:59:06 <emilio> q-
22:59:07 <xfq> ack emilio
22:59:21 <fantasai> heycam: It think most important thing given distinction between focus outlines and decorative outlines
22:59:37 <fantasai> heycam: We should write down which particular descendants get included, because that's the particular difference betwen FF and other browsers that's an issue for us
22:59:47 <fantasai> heycam: At the moment, we include all in-flow descendants
22:59:59 <fantasai> gregwhitworth: I have interop on all 3 browsers in Windows
23:00:15 <fantasai> [discussion about testing]
23:00:25 <fantasai> heycam: I only tested normal outlines, and definitely saw differences
23:00:33 <fantasai> emilio: Also Firefox only changed recently, might want to test Nightly
23:00:43 <fantasai> astearns: Sounds like we won't resovle anything right now, but we need to figure out interop
23:01:00 <fantasai> astearns: First thing to figure out as we go through these issues in addition
23:01:06 <fantasai> heycam: So next step is wait for this report?
23:01:20 <fantasai> ACTION: gregwhitworth open issues against outline on all the aforementioned issues
23:01:21 <trackbot> Created ACTION-877 - Open issues against outline on all the aforementioned issues [on Greg Whitworth - due 2019-03-05].
23:01:32 <fantasai> astearns: Let's keep this issue on descendants and open more issues for the rest
23:01:38 <fantasai> astearns: OK that's it for this topic!
23:01:40 <fantasai> BREAK TIME
23:01:44 <fantasai> <br type=tea>
23:01:52 <fantasai> Topic: end
23:02:36 <futhark> futhark has joined #css
23:05:49 <bkardell_> tantek, we can collect some if you want. I agree it would be helpful to have things to look at.  Here is part of the thread, idk how many of the things linked to still look as they did or anything https://twitter.com/meyerweb/status/1082743466524901381
23:07:05 <bkardell_> tantek there are some screenshots in there if you poke around the thread and contemporary tweets with eric
23:12:54 <myles__> myles__ has joined #css
23:20:31 <futhark> futhark has joined #css
23:20:31 <xfq> xfq has joined #css
23:21:53 <mstensho> mstensho has joined #css
23:36:29 <emilio> ScribeNick: emilio
23:37:28 <astearns> topic: drop navbeforescroll
23:37:32 <astearns> github: https://github.com/w3c/csswg-drafts/issues/3401
23:37:36 <fremy> fremy has joined #css
23:37:58 <emilio> jihye: we have three events, navbeforescroll triggers when there's no visible focusable element in the scroll container
23:38:34 <emilio> jihye: it has some perf issues so we want to drop it, but there are some use cases like moving the focus directly using arrow keys or focusing the non-visible content in the scroll container
23:38:40 <jihye> https://raw.githack.com/jihyerish/spatial-navigation/spatnav-behavior/demo/scroller/index.html
23:38:50 <emilio> jihye: so we'd like to propose a new CSS property, spatial-navigation-behavior, see ^ for demo
23:39:08 <emilio> jihye: this property is aimed to split scrolling and moving the focus behavior, to avoid scroll latency
23:39:10 <bdc> bdc has joined #css
23:39:55 <jihye> https://raw.githack.com/jihyerish/spatial-navigation/spatnav-behavior/demo/infinite-scroller/index.html
23:39:57 <emilio> jihye: and it helps to implement the use-cases like infinite scrolling
23:40:28 <emilio> jihye: we have to decide exact naming and values, and I wanted to gather opinion about whether the new property is reasonable
23:40:46 <rachelandrew> rachelandrew has joined #css
23:41:01 <emilio> eae: I think it's a very good idea, and it helps to avoid preventing composited scrolling, so I'm very happy to see you're moving in this direction
23:41:01 <myles__> myles__ has joined #css
23:41:26 <emilio> florian: initially we wanted to go with events only rather than declarative syntax, so people could experiment
23:41:55 <emilio> florian: but given the only use-case for this event can be done declaratively, and it solves the perf issue that concerned google, it sounds like a good idea
23:42:05 <emilio> eae: yeah, thanks for coming up with that proposal
23:42:25 <emilio> florian: we've iterated quite a bit on naming, last proposal is spatial-navigation-action: auto / focus / scroll
23:42:37 <emilio> florian: normal behavior is a combination of focus and scroll
23:42:53 <emilio> florian: if you use focus, it'll just jumps across focusable elements
23:43:20 <emilio> florian: instead of scrolling step by step, like auto
23:43:45 <emilio> florian: scroll is the opposite, it will just scroll it and skip focusable elements inside
23:44:44 <emilio> florian: so for example if you have a focusable scroller with focusable things in it, in which you're not strongly interested (like a twitter feed in the page), you could use the scroll value to avoid going into focusing the descendants until you focus one of them
23:45:09 <emilio> florian: we didn't feel strongly that we needed `scroll`, but having it now helps the bike-shedding for names and such
23:45:36 <emilio> astearns: would it make sense to have three values with scroll noted like "maybe dropped"
23:45:45 <emilio> jihye: maybe just add it later
23:46:07 <smfr> smfr has joined #css
23:46:11 <emilio> astearns: since the value helped you, maybe better either leaving it out and noting that it might be added, or the opposite
23:46:24 <emilio> florian: if somebody finds a better name, then even better
23:46:54 <emilio> bkardell_: so currently this demo works setting some DOM properties?
23:47:07 <emilio> jihye: I showed two demos, which one?
23:47:21 <emilio> bkardell_: let's take spatial-navigation-action? Is it just using a dom property in the demo?
23:47:28 <gtalbot> gtalbot has joined #css
23:47:37 <emilio> florian: the demo uses a polyfill?
23:47:42 <emilio> s/?//
23:47:50 <emilio> bkardell_: I was wondering how it was implemented, custom props?
23:47:57 <emilio> jihye: yeah, it's a custom property
23:48:16 <florian> s/polyfill?/polyfill/
23:48:30 <emilio> RESOLVED: drop navbeforescroll and add `spatial-navigation-action` with at least two values
23:48:51 <astearns> topic: end
23:49:13 <emilio> topic: css-nav FPWD
23:49:31 <emilio> astearns: there are any other implementors interested in this spec?
23:49:43 <emilio> florian: other than google?
23:49:57 <bkardell_> q+
23:50:08 <emilio> astearns: yeah, we have google and polyfill, but no more implementor interest
23:50:30 <emilio> smfr: webkit has an implementation but it's not maintained. It was contributed by an external contributor
23:50:34 <xfq> ack bk
23:51:02 <emilio> bkardell_: so, when we met at TPAC, florian did mention that vivaldi wanted to ship the polyfill?
23:51:18 <emilio> florian: that's right, we've talked with them about replacing their implementation with their jihye's polyfill
23:51:37 <emilio> bkardell_: yeah, I don't think it counts as an implementation but we can get feedback
23:51:43 <presenter> presenter has joined #css
23:52:15 <emilio> astearns: I think a shipping polyfill we can write tests against is useful
23:52:27 <emilio> emilio: but you can't test syntax or other implementation details with that
23:52:54 <florian> q+
23:53:03 <emilio> bkardell_: yeah, didn't mean implementation for any official thing, but it's useful to have the feedback, so we're looking to get more good users and getting dev feedback
23:53:18 <xfq> https://www.npmjs.com/package/spatial-navigation-polyfill
23:53:26 <emilio> jihye: this polyfill is in npm and I plan to keep maintaining it so we can get some feedback from devs
23:54:00 <xfq> ack fl
23:54:03 <emilio> myles_: WebKit's implementation is fully incompatible with this spec, it's pretty old. We are interested in updating it to match this spec, but it's pretty low priority
23:54:10 <gtalbot> gtalbot has left #css
23:55:12 <emilio> astearns: comments? objections?
23:55:20 <xfq> \o/
23:55:24 <emilio> RESOLVED: Publish FPWD of css-nav
23:56:48 <florian> Topic: distance function
23:56:50 <florian> github: https://github.com/w3c/csswg-drafts/issues/3384
23:56:53 <emilio> jihye: I've been working on improving the distance function to move focus to the correct next target.
23:57:14 <emilio> jihye: If you have any opinions it'd be useful, and I think it's the biggest issue
23:57:36 <emilio> florian: this is the heuristic part of the model, to guess which element is the right next target to move focus too
23:57:59 <emilio> florian: jihye has done a lot of great work on that, which is strictly better than what's on the spec
23:58:16 <AmeliaBR> q?
23:58:37 <emilio> florian: I think we could get some other round with UX and what not, but we should probably roll it in and try to get it into the spec
23:58:47 <emilio> AmeliaBR: does the geometric calculation really need to be specified?
23:58:58 <emilio> AmeliaBR: do any other thing depend on the result of the function?
23:59:32 <emilio> florian: not other properties, but we don't want a magical perfect heuristic, just a good enough heuristic where authors can take controls if the heuristic goes wrong