17:00:37 RRSAgent has joined #css 17:00:37 logging to https://www.w3.org/2019/02/26-css-irc 17:00:39 RRSAgent, make logs public 17:00:39 Zakim has joined #css 17:00:41 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 17:00:41 Date: 26 February 2019 17:01:45 present+ 17:01:54 futhark has joined #css 17:02:38 TabAtkins: Hi I’m here on 7th floor. Can you or someone let me in? 17:03:20 futhark has joined #css 17:09:01 AmeliaBR has joined #css 17:09:06 bgirard has joined #css 17:10:23 presenter has joined #css 17:12:06 skk has joined #css 17:14:42 myles_ has joined #css 17:15:03 scribenick: gregwhitworth 17:15:22 bdc has joined #css 17:15:48 rachelandrew has joined #css 17:15:49 https://g.co/hangout/google.com/csswg 17:16:38 xfq has joined #css 17:16:40 Topic: ResizeObserver device-pixel-border-box 17:16:46 Github: https://github.com/w3c/csswg-drafts/issues/3554 17:17:44 atotic: I've been working on the spec 17:18:10 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 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 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 atotic: device pixels are never rounded - there is no doubles or floating point, etc 17:19:41 jensimmons has joined #css 17:19:46 atotic: how we do this is by pixel snapping, there is no way for webdevs to determine this 17:20:14 atotic: pixel snapping depends on not only pixels but also position 17:20:34 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 atotic: currently the proposal will be that you will get device pixel inline and border size if its a canvas 17:21:10 fantasai: are you proposing to add it somewhere else 17:21:17 atotic: no 17:21:31 fantasai: so the only way to get this is to add the resizeObserver 17:21:36 atotic: yes 17:22:09 dholbert: does devicePixelRatio? 17:22:28 atotic: they get a bad pattern from hacking this because it can't do pixel snapping correctly 17:22:48 dbaron: under what conditions does Chrome change the device pixel backing size when it's repositioned? 17:23:43 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 present+ 17:24:20 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 dbaron: do you actually change the backing store 17:24:39 dbaron: the number of image pixels in the canvas 17:24:48 dbaron: I guess thats the height and width 17:25:22 dbaron: they want to change those the attrs based on the device pixel sizes 17:26:03 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 how is that different from a url background image? 17:26:27 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 " if the ratio is a nice even number then we don't get moar patterns - if we don't" 17:26:45 that bit 17:27:09 s/moar/moire/g 17:27:26 dbaron: bkardell_ is asking why don't you get moire pattern in background images 17:27:44 atotic: it will scale, but background image is fundamentally different 17:28:00 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 atotic: we probably do get them but you usually aren't doing hidpi background image or you can't tell 17:28:31 atotic: where they primarily have this issue is in the 3d context and they'll have patterns that look different 17:28:56 q+ 17:29:06 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 atotic: you will see artifacts - but they'll create 3 different images 17:29:43 So I understand the use case -- but I'm a little suspicious of making it -only, though. 17:29:57 iank_: within painting, we know where the pixel snapping is so we can account for it 17:30:10 atotic: also we're talking about every frame in video games, it happens a lot more 17:30:33 dbaron: I understand the usecase I just don't know if I like that it's canvas only 17:31:01 q+ 17:31:09 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 I'd have expected it to be implemented a different way, but okay... 17:31:21 atotic: if we find that it's useful in other areas it's easy to extend it 17:31:56 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 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 hober: we also saw that people still create the larger one 17:33:16 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 liam: checking the device pixel size, it seems easy to check every frame 17:33:54 ack me 17:34:00 liam: why would you not check it? 17:34:20 atotic: if you're a game developer maybe 17:34:21 q+ 17:34:51 frremy: If you want to draw a perfect line in your table you'll need to resnap it 17:35:00 fremy has joined #css 17:35:02 atotic: exactly, you need it or you add it to both specs 17:35:09 ack florian 17:35:23 q+ 17:35:28 florian: another thing - here we know what CSS & device pixel things and very easy to get confused 17:35:52 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 ack heycam 17:36:11 atotic: it would only happen on canvas - you would see inlineDevicePixel and blockDevicePixel 17:37:13 gregwhitworth, recaps the resolution from yesterday 17:37:28 heycam: before you were seeing a perf penalty - why not add a new box watching keyword? 17:37:43 heycam: you can still have the device pixel border box of another element 17:37:50 futhark has joined #css 17:37:56 bdc has joined #css 17:38:08 florian: but that was my point - if you make it broadly available they'll abuse it 17:38:21 florian: they'll think they want device pixels but they'll probably be incorrect 17:38:29 q+ 17:38:56 liam: to be clear, the only usecase this solves compared to RO plus having a method on canvas 17:38:56 q- 17:39:32 q- 17:39:56 q+ 17:40:00 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__ has joined #css 17:40:31 s/liam/emilio 17:40:56 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 Rossen: if you have a scale it's broken 17:42:45 ScribeScribe: Florian 17:42:48 gregwhitworth: I'm against adding this based on what smfr and liam said 17:43:00 atotic: it will be blurry anyways so it doesn't matter 17:43:06 s/liam/emilio again :D 17:43:39 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 gregwhitworth: so taking all web devs into account, this looks like a partial solution, not good enough 17:44:26 iank_: I'll need to ask Chris, but we may compute the transforms 17:44:40 atotic: resizeObserver doesn't watch transforms 17:44:48 smfr: then this is the wrong API to bolt this onto 17:45:13 atotic: ok, the hidpi with an ancestor that has a transform or something 17:45:42 atotic: that should still work because it will then get transformed 17:46:02 florian: then it's broken because the second you scale it's broken 17:46:09 florian: people will assume they can and it will fail 17:46:46 atotic: I thought one of the issues on the webplatform you don't want to expose zoom because it will break 17:46:58 heycam: this is different 17:47:13 s/this/pinch zooming and transforms on ancestors/ 17:47:17 atotic: we were talking about the pinch zoom of the page and they would end up with arbitrarily long page 17:47:26 florian: pinch zoom, leaving it out - but transform? 17:47:40 atotic: if we were going to do transforms, there will be a subset of these that should work 17:47:40 futhark has joined #css 17:47:53 atotic: we want this to be a size API not a quad API 17:48:52 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 atotic: RO itself does not work with transforms 17:49:06 present+ 17:49:23 fremy: If you're going to draw a canvas you're not trying to do a transform on top of that 17:49:30 fremy: transform is for animations 17:49:56 fremy: why would you intend to do this if you're focused on pixel perfect drawing 17:50:41 liam: I agree it doesn't make sense, it does make sense to center a canvas 17:50:56 florian: offset path will also impact this as it can change the position 17:51:10 bdc has joined #css 17:51:11 atotic: we're going to notify you when the border box changes 17:51:33 atotic: there's nothing that says we're not going to change on the transforms 17:51:49 dholbert: how integral is the movement of the subpixel 17:52:12 atotic: when you're moving it's blurry anyways, it's a video game 17:52:34 dholbert: I'm feeling like a static API is more desirable than an RO API 17:52:51 it is possible to make a subclass phase 2 of this that was specifically for observing that? 17:53:00 .. or something 17:53:22 dholbert: the canvas API makes sense to have this 17:53:31 atotic: but people want to get an observation 17:53:46 present+ 17:53:51 present+ 17:53:57 q+ 17:54:04 ack emilio 17:54:10 q- 17:54:12 tantek has joined #css 17:54:18 present+ 17:54:20 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 atotic: I thought of that - but you end up getting a bunch of ROs without knowing why 17:55:14 AmeliaBR: we have a way of adding device-pixel-border-box back? 17:55:48 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 AmeliaBR: maybe I don't care about those and you're adding a perf hit 17:56:31 smfr has joined #css 17:56:49 heycam: you can rename the type of the box, canvas-bitmap-box if you're worried about 17:57:06 atotic: it kind of locks us into watching the canvas only 17:57:27 fantasai: I think agree with atotic named canvas - so we shouldn't lock that down 17:57:53 s/named/about not naming specific to/ 17:58:20 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^: 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 atotic: it has a perf hit 17:59:00 smfr: if you drag to another screen would it fire 17:59:02 atotic: yes 17:59:25 smfr: it's not real device pixels, because your not taking transforms into account 17:59:49 chrishtr: its the dims of the texture of the backing store 17:59:58 smfr: what you just said is very impl specific 18:00:32 chrishtr: it's the CSS pixel size snapped and multiplied by the devicePixelRatio without taking into account transforms 18:00:43 chrishtr: it has to take into account zoom 18:00:47 smfr: ours doesn't 18:00:53 chrishtr: the spec says to 18:01:03 dholbert: doesn't it fire after layout? 18:01:05 mstensho has joined #css 18:01:05 atotic: yes 18:01:17 dholbert: so after layout 18:01:47 dholbert: it would need to be extended to take into account after the fact 18:02:02 liam: I don't think this a great fit 18:02:06 present+ 18:02:25 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 q+ 18:02:36 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 has joined #css 18:02:55 present+ 18:03:14 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 fantasai: it would be nice to not get the extra events unless I actually care about the device pixel border box 18:03:48 atotic: yes 18:03:59 fantasai: I think it should be the content box since that's what you're painting into 18:04:10 atotic: you could register to observer device-pixel-content-box 18:04:39 atotic: that was my original proposal 18:04:46 q+ 18:04:54 ack my 18:05:16 myles__: so in conjuction with what fantasai was saying then you need to know the pos and size. 18:05:30 fantasai: no only if those pixels change 18:05:52 gregwhitworth: that's already in the algo 18:06:00 fantasai: you can resize in result of pos, but it may not 18:06:28 ack fremy 18:06:41 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 (sounds like people were leaning towards registering for a separate box name rather than giving these notifications magically in some case) 18:07:09 iank_: we don't have webgl and a bunch of other APIs 18:07:11 fremy: oh ok 18:07:29 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 q+ 18:08:10 still doesn't deal with the issues about rectilinear transforms, offset-path, etc. 18:08:28 ack chrishtr 18:08:31 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 atotic: I think we have agreement to watch a seperate box? 18:09:13 zakim, close queue 18:09:13 ok, astearns, the speaker queue is closed 18:09:18 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 smfr: I think people will want it in other ways 18:09:38 ack smfr 18:09:57 s/in other ways/on other elements/ 18:10:32 futhark has joined #css 18:11:11 smfr: I was proposing this is the snapped content box multiplied by device pixel ratio 18:11:37 dbaron: but you all agree to ignore transforms? 18:11:51 chrishtr: because it should be a paint based situation for perf 18:11:58 dbaron: I don't think that's actually true 18:12:12 chrishtr: unless overflow it's almost post paint 18:12:29 krit: even SVG? 18:13:07 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 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 atotic: thank you 18:13:27 Ooh, "paint size" sounds good. 18:13:39 Topic: CSS properties should apply to some SVG properties as well 18:13:48 bdc has joined #css 18:14:15 chris has joined #css 18:14:20 present+ 18:14:34 AmeliaBR: I don't have a whole lot to update 18:14:39 AmeliaBR: in comparison to the telecon 18:15:19 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 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 AmeliaBR: the applies to in the definition is loosely defined 18:16:02 q? 18:16:08 rrsagent, here 18:16:08 See https://www.w3.org/2019/02/26-css-irc#T18-16-08 18:16:12 AmeliaBR: when you look at CSSOM for getCOmputedStyle it has nromative impacts on whether you return the computed or used style 18:16:28 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 AmeliaBR: In general I'd like to suggest that the applies to more rigorously defined which categories are used? 18:17:02 q+ 18:17:07 zakim, open queue 18:17:07 ok, astearns, the speaker queue is open 18:17:11 q+ 18:17:18 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 AmeliaBR: instead of using the term elements we can use rendering tree terminology, etc 18:17:55 AmeliaBR: also others mix elements and rendering tree words it's very incosistent 18:18:13 AmeliaBR: the SVG element the same element in different layout contexts may or may not have a CSS box 18:18:33 AmeliaBR: another thing for SVG - text content elements many text related props will apply to SVG Text but not all 18:18:41 AmeliaBR: because the actual text layout is different 18:19:02 AmeliaBR: it would be valuable to not have to re-analyze if it impacts SVG text, etc 18:19:12 fantasai: what are we trying to conclude 18:19:29 AmeliaBR: at this point it's just an update and they've been surprised that it has normative impact 18:19:38 s/impact/impact on getComputedStyle/ 18:19:48 AmeliaBR: should we somehow extract that, and make it informative and then define gcs in some other way 18:19:57 q? 18:20:01 q+ 18:20:05 AmeliaBR: if it's a normative impact then we need to be strict terms that are clearly defined 18:20:19 q+ 18:20:26 ack heycam 18:20:41 atotic has joined #css 18:20:48 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 heycam: maybe I missed an earlier discussion 18:21:18 present: krit 18:21:18 https://drafts.csswg.org/cssom/#resolved-value-special-case-property-like-height 18:21:29 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 and the next instance of the phrase "applies to" as well 18:21:41 AmeliaBR: that's where the applies to the normative impact 18:21:55 heycam: does CSSOM point to applies to 18:21:58 TabAtkins: yes 18:22:21 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 ack dbaron 18:22:29 q+ 18:22:41 dbaron: I think the spec for getComputedStyle is not yet where impl should change to match the spec 18:23:09 dbaron: maybe someone took a shortcut to point to applies to - but it's probably not an accurate definition 18:23:31 AmeliaBR: I'm not asking impl to match the CSSOM spec it's about spec consistency 18:23:45 AmeliaBR: but it's using a terminology that isn't explicitly defined elsewhere 18:23:48 mfreed has joined #css 18:23:54 futhark has joined #css 18:24:08 florian: also applies to it's not just a yes/no category - there has to be prose 18:24:22 ack florian 18:24:24 florian: I'd be in favor in keeping applies to somewhat wishywashy 18:24:34 florian: but also helping clarity for SVG is useful 18:24:50 ack krit 18:24:52 ack krit 18:24:54 q? 18:25:04 krit: besides that Applies TO we need to look at the prose, many text layout keep SVG in mind as well 18:25:21 krit: if there is anything that the SVG specs can do to help that would be good to know as well 18:25:32 krit: that would help interoperability between SVG/CSS very good as well 18:25:40 AmeliaBR: that's very good feedback as well 18:25:43 ack krit 18:25:58 AmeliaBR: I don't think we have them defined in one place, so we can improve that on our end 18:26:26 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 florian: this will probably be more than a blue box change but a prose change 18:26:51 q+ 18:27:18 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 ack florian 18:27:41 florian: it's a process question, these categories can be aware of - are they different between SVG1.1 & 2? 18:27:51 AmeliaBR: some of them have changed and some have been simplified 18:27:59 AmeliaBR: I think there are a couple new categories 18:28:09 There are changes in SVG2, mostly simpfilfications. 18:28:11 q+ 18:28:12 florian: it would be unfortunate if no spec can get to rec until SVG 2 does 18:28:33 florian: I don't want to gate everything on SVG getting to rec 18:28:50 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 q? 18:29:04 AmeliaBR: that covers the main topic of this issue 18:29:26 chris: The issue that florian raised is a quite large CSS one 18:29:43 chris: whenever a spec goes to rec but it has these refs to EDs etc 18:30:08 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 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 chris: there have been a few cases in SVG2 that are linking to SVG1.1, etc 18:31:33 chris: as for CSS, I think it shouldn't be too large of a problem - there is a last resort 18:31:46 q+ 18:32:11 ack chris 18:32:17 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 chris: we have some concepts for graphic elements and SVG1.1 has this stuff 18:32:47 krit: just one comment 18:32:58 krit: SVG2 categories are supposed to make things easier 18:33:23 ack krit 18:33:37 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 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 florian: that spec that references it can't go to rec either because they're dependant on it 18:34:55 krit: in those weird cases, sure link to 1.1 SVG 18:35:03 krit: most of the issues are text related 18:35:08 Rossen: ok, that sounds good 18:35:48 jensimmons has joined #css 18:36:03 AmeliaBR: we should open an issue into defining getComputedStyle further 18:36:19 ACTION AmeliaBR : Open an issue to define getComputedStyle 18:36:19 Created ACTION-876 - : open an issue to define getcomputedstyle [on Amelia Bellamy-Royds - due 2019-03-05]. 18:37:13 s/liam/emilio 18:41:53 github: https://github.com/w3c/csswg-drafts/issues/3414 18:42:01 github-bot, end topic 18:44:42 mstensho has joined #css 18:45:13 futhark has joined #css 18:49:55 smfr_ has joined #css 18:54:39 bdc has joined #css 18:55:24 I have a breakout room reserved for this afternoon 2-3, fyi for scheduling 18:55:29 AmeliaBR: And I got one 9-10 tomorrow morning 18:55:52 Thanks TabAtkins ! 18:56:24 jensimmons has joined #css 18:56:29 futhark has joined #css 18:57:48 xfq has joined #css 18:59:09 ScribeNick: fantasai 18:59:20 Topic: Shadow something 18:59:31 Topic: make clear that Shadow Parts for built-in elements should not be supported without standardization 18:59:36 github: https://github.com/w3c/csswg-drafts/issues/3674 19:00:20 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 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 has joined #css 19:01:16 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 heycam: I like that theis psec doesn't talk about built-in file controls 19:01:51 I fully agree with heycam 19:01:52 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 s/theis psec/the spsec/ 19:02:00 TabAtkins: I accept the change on behalf of fergal 19:02:27 heycam: Unless ppl have plans to start exposing things through ::part()...? 19:02:31 +1 19:02:49 rachelandrew has joined #css 19:02:53 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 AmeliaBR: Is the invalidity rule such that ::part() is always valid regardless of arg? 19:03:18 TabAtkins: As long as syntax matches what's syntactically allowed it's valid 19:03:34 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 AmeliaBR: Agree that ppl shouldn't ship experimental things until there's a standardization discussion 19:04:05 AmeliaBR: In some cases maybe we'll say, your datepicker is so specialized that you should have a prefixed part? 19:04:14 TabAtkins: Yeah, fine to do, because syntax space is wide open 19:04:32 RESOLVED: Add such a note -- no exposing parts of form controls without standardization 19:04:50 Topic: contain: style doesn't seem very suseful 19:04:56 s/suseful/useful/ 19:05:08 emilio: Very confused what use case contain: style is supposed to solve. 19:05:08 github: https://github.com/w3c/csswg-drafts/issues/3280 19:05:17 emilio: It's hard to implement. Very broken in the only implementation that's shipping. 19:05:33 emilio: I can't see any potential advantage except *maybe* update counters faster in the page? 19:05:34 q+ 19:05:38 emilio: But that's usually not a perf issue. 19:06:03 TabAtkins: My answer in the issue was that the 'contain' properties in general are to help isolate parts of your document 19:06:12 TabAtkins: perf wins are a benefit, esp layout 19:06:24 TabAtkins: But also helps you isolate parts of your document to make it easier to think about 19:06:45 TabAtkins: It covered the remaining thing that would leak out of a component 19:07:03 TabAtkins: Was a completion exercise in making an isolated component 19:07:21 emilio: Did we decide how counters work in CSS? Are they off DOM tree or flat treee? 19:07:29 TabAtkins: CSS works on flat tree as its "element tree" 19:07:38 TabAtkins: So counters are defined to work on flat tree 19:07:48 TabAtkins:... 19:07:50 emilio: Tests? 19:07:58 TabAtkins: Had some in past, lost them. before wpt 19:08:08 TabAtkins: Might pick up again when working on Lists 19:08:34 dbaron: Counters are part of generated content, thus box tree 19:08:54 TabAtkins: Mental model is that everything is elements, then we turn things into boxes, then we turn things into fragments 19:09:09 futhark has joined #css 19:09:19 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 ... so I think they do need to work on the flat tree 19:09:44 q? 19:09:45 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: Right. 19:10:16 futhark: I agree with emilio that there is not much to do with optimization for contain: style 19:10:17 ack futhark 19:10:27 futhark: One useful thing would be if we said that inheritance doesn't happen from 'contain: style' down 19:10:32 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 futhark: Then we can optimize for ? 19:11:02 futhark: If 'contain: style' meant that 'all: initial', then we could optimize getComputedStyle 19:11:14 futhark: Then it wouldn't rely on layout (???) 19:11:20 futhark: Then can do display locking 19:11:22 emilio: ... 19:11:40 TabAtkins: Contain property doesn't block things going into the subtree. It blocks things leaking out. 19:11:51 florian: It's the contain property, not the isolate property 19:11:54 q? 19:11:56 futhark has joined #css 19:12:36 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 TabAtkins: There's a bunch of parts of CSS where we have global names etc. 19:12:52 TabAtkins: Maybe we just rely on shadow DOM. 19:13:07 florian: Wanted to ask rego's pov , since he fixed a lot of bugs on 'contain: style' 19:13:26 emilio: It's very broken to the point that 'contain: style' toggling doesn't do anything dynamically 19:13:29 there are a few bugs https://github.com/w3c/csswg-drafts/issues/3280#issuecomment-452580469 19:13:36 emilio: Implementing it in Gecko is really hard, and I'd rather not ship something that's broekn. 19:13:53 emilio: My ask is drop it. 19:14:04 Rossen^: So what's your ask, Emilio? 19:14:14 presenter has joined #css 19:14:33 mfreed has joined #css 19:14:41 Rossen: So proposal here is to drop 'contain: style' from css-contain 19:14:46 futhark_ has joined #css 19:14:52 AmeliaBR: Is there any reason this couldn't be added back later, if it turns out to be useful? 19:15:28 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 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 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 TabAtkins: counters and quote property 19:16:44 emilio: The computed style doesn't change. 19:16:50 emilio: The counter values are not stored in computed styles 19:17:06 chrishtr: Does contain: layout say that counters...? 19:17:10 futhark has joined #css 19:17:13 emilio: Style is a bit of misnomer 19:17:40 chrishtr: Regardless of name, need to have this functionality to have complete perf 19:18:03 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 has joined #css 19:18:12 emilio: Not soemthing I've seen in a perf profile at all 19:18:29 chrishtr: But if you want to do things like async rendering or display locking 19:18:35 futhark has joined #css 19:18:40 chrishtr: you'd need this, just in case the content changed a counter 19:18:42 q+ 19:18:50 chrishtr: Whether it should be its own thing, idk 19:19:09 emilio: It's not something that happens frequently. It can have a layout effect across the page. 19:19:18 chrishtr: But unless you lock it, has an effect 19:19:22 emilio: It's same as changing content property 19:19:38 florian: But that doesn't affect outside the element 19:19:51 emilio: ... counters reset can change stuff across document 19:20:14 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 chrishtr: It's small but a real footgun? 19:20:33 emilio: That's fair, but we still don't have a great model for counters 19:20:49 emilio: Makes it seem like counters work in the style tree. 19:20:52 emilio: Which isn't true 19:21:00 futhark has joined #css 19:21:13 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 chrishtr: Agree we need tests 19:21:22 emilio: and a proper spec 19:21:38 dbaron: We had an interim agreement to add 'counter-set' 19:21:42 dbaron: we never added 19:21:48 TabAtkins: it's in a spec, it's in Lists 19:21:52 TabAtkins: just never past WD 19:21:59 emilio: ... spec, not in implementations 19:22:08 emilio: Even in Blink, renumbering lists 19:22:20 emilio: If element is display: contents; contain: strict; if you add a list item inside of it? 19:23:00 emilio: You have a
19:23:14 emilio: Right now if you change the div's display, it is buggy 19:23:25 TabAtkins: Our entire counters implementation has issues 19:23:42 eae: Spec is correct, but our impl is incorrect 19:23:51 emilio: Given state of impls, implementing 'contain: style' is not worth it 19:24:03 TabAtkins: Fact that built-in lists might be magical is a separate issues 19:24:20 emilio: If lists are magical, then we have another leak 19:24:32 dbaron: We have a patch to Gecko to use counters for lists, so might fix that 19:24:59 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 chrishtr: So I think we should add proper tests and fix things to not be sad 19:25:27 chrishtr: Then if that's the case, come back to you about this. 19:25:40 dholbert: Sounds like use case is lazily rendering the subtree 19:26:04 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 dholbert: They're quite rarely used 19:26:50 dholbert: Might be easier to just disable perf optimizations in cases where they're used rather than implementing 'contain: style' 19:27:03 q+ 19:27:23 ack futhark 19:27:34 futhark: I think Chris you had some thoughts... I'm confused about isolation vs containment 19:27:38 ack futhark 19:27:40 futhark: For perf, you probably want isolation 19:27:48 futhark: If you modify DOM outside something that's contaiend 19:28:02 futhark: It can affect sibling selectors that affect the contained subtree 19:28:09 emilio: Which can set 'contain' 19:28:22 TabAtkins: Nothing about contain is about isoaltion 19:28:39 TabAtkins: You can't have layout isolation 19:28:55 TabAtkins: You can't use percentage or auto or anything. It has to be 100% manually-specified or nothing. 19:29:15 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 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 chrishtr: needs investigation 19:29:58 chrishtr: Not only is 'contain: style' poorly implemented, the other contain modes while implemented corretly don't actually improve perf 19:30:04 q+ 19:30:18 ack me 19:30:31 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 emilio: contain can be dependent on DOM content sof an element 19:31:06 emilio: There are sleectors already that depend on contents of the element 19:31:27 chrishtr: ... 19:31:34 TabAtkins: You cannot have selectors that depend on style 19:31:42 TabAtkins: Filing an issue won't solve it. 19:31:46 TabAtkins: We can't do that. 19:31:58 q? 19:32:19 q- fr, fl 19:32:22 ack all the florians 19:32:28 florian: Mentioned about testing and things, at the moment we have reasonably extensive testing of normal counters 19:32:34 florian: If lists are fake counters, that's not tested separately 19:32:41 florian: I couldn't find tests for shadow DOM and display: contents 19:32:47 florian: BUt for normal counters, should be well-covered 19:32:50 q? 19:33:00 TabAtkins: Given large number of inconsistencies in lists from when I was testing them awhile back.... 19:33:07 florian: Checking for what ti's supposed to do to counters. 19:33:20 florian: If you toggle contain on/off, we don't have tests for that. 19:33:26 florian: But effect of contain on counters, we do have tests 19:33:36 TabAtkins: Thanks for test suites 19:33:41 florian: Thank gtalbot 19:34:15 Rossen: Hearing pushback from Mozilla 19:34:23 Rossen: Not hearing much from other vendors 19:34:30 Rossen: What do we want to do next? 19:34:33 fantasai: Rename it, obviously. 19:34:42 Rossen: Or we can drop it 19:34:50 emilio: Can we drop contain: style and if we decide it's a thing we want 19:34:59 smfr has joined #css 19:35:22 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: Might be able to slip it in, because unlikely to be dependent on leaking counters/quotes 19:36:07 TabAtkins: Quotes definitely rare. Unsure about counters. 19:36:19 emilio: ... 19:36:39 Rossen: We could try dropping style now, and see if counters surface as a prominent use case, then deal with it 19:36:54 TabAtkins: What do you think, Chris 19:37:15 chrishtr: Drop it from the spec, but leave it implemented in one browser? 19:37:19 TabAtkins: No, that'd be a spec violation 19:37:36 gregwhitworth: It's implemented and shipping in a browser, but it doesn't work 19:37:44 TabAtkins: It does for real counters, if you have no dynamic changes 19:38:19 hober: It's up to them what they ship in the browser. 19:38:41 Rossen: So would there be an objection to dropping 'contain: style'? 19:39:10 s/in the browser/in their browser. It's up to us what we have in the spec./ 19:39:15 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 emilio: The case of having 'contain: style' that spans across a list 19:39:24 futhark has joined #css 19:39:31 emilio: or counters inside a 'contain: style' subtree 19:39:38 emilio: Until Lists work that way, you're going to break something 19:39:56 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 chrishtr: What would likely happen is that we wouldn't remove the feature, we'd fix it 19:40:23 chrishtr: I'd rather fix it in Chrome and work through the spec issues than drop it 19:40:30 chrishtr: What we do with the spec in teh meantime 19:40:45 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 eae: So it might make sense to drop it for now 19:41:06 florian: If we drop now and add back later gets us to strict + stricter 19:41:13 florian: I'm not bikeshedding the stricter 19:41:27 emilio: We also want to ship containment 19:41:40 emilio: But we really don't want to implement 'contain: style' under the current state of affairs 19:41:48 emilio: Given it needs more work in specs and implsmentations 19:41:57 q+ 19:42:04 emilio: It would make sense not to block shipping containment on 'contain: style' 19:42:17 chrishtr: Was there a compat issue? 19:42:26 emilio: No, but we don't want to willfully violate the spec. 19:42:42 emilio: We don't want to parse a value and then not implement it 19:42:47 (That is in fact a violation of the CSS spec) 19:42:55 TabAtkins: Is it just about built-in lists or all counters/ 19:43:01 emilio: It's generally hard to implement in our counters implementation 19:43:12 ack Tab 19:43:13 TabAtkins: I'm wondering how difficult it is from doing a counter-reset on all possible counters? 19:43:38 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 dbaron: And then it's reasonable 19:43:51 emilio: And then dynamic changes, you'd have to reframe 19:44:04 dbaron: You'd have to reframe anywya 19:44:23 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 florian: Unless I missed something, counters have a definition problem. CSS 'contain: style' doesn't. 19:44:53 florian: There's a dependency, but I think implementation and spec being wrong is an overstatement 19:45:11 TabAtkins: Lists spec having bugs is adequate to say there's a spec problem. 19:45:28 futhark has joined #css 19:45:40 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 TabAtkins: ... 19:46:20 emilio: What would be the best way for Mozilla to ship contain: layout 19:46:32 florian: Could just not ship strict yet, then ... 19:46:52 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 q+ 19:47:16 neither contain:strict neither contain:content (as both include style) 19:47:30 ack fantasai 19:47:35 fantasai: I think the right way to go is to ship everything except the style value itself 19:47:44 ... and then at some future point, incorporate that into strict 19:47:53 ... 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 emilio: it would be nice if Blink didn't parse 'style' either, and we could do that change together later 19:48:36 florian: When you say don't do style, did you also mean change tehavior of strict later when we add it? 19:48:37 fantasai: yeah, we will eventually change the behavior 19:48:39 fantasai: Yes 19:48:53 chrishtr: You said it's not so easy to implement contain: style 19:48:57 chrishtr: How hard is it? 19:49:01 emilio: How hard is it? 19:49:09 chrishtr: Couple months of work? 19:49:13 emilio: It's work, that somebody needs to do 19:49:23 TabAtkins: Given taht I do have a direction for naming in the future 19:49:31 TabAtkins: I'm OK with dropping style for now 19:49:39 TabAtkins: Dropping from definition of strict, dropping as a value 19:49:51 TabAtkins: And then we add 'all' later, that does all 4 19:50:03 TabAtkins: Do that once our implementation is good enough to be meaningful for style 19:50:10 TabAtkins: And Mozilla can also fix 19:50:14 emilio: And add a bunch of tests :) 19:50:31 chrishtr: So what you're suggesting is to refactor spec so that easier to incrementally add in the future 19:50:43 TabAtkins: Right, drop 'style' and add it back in a future level of the spec 19:51:00 chrishtr: What if we do the other things you mention and leave style? 19:51:10 TabAtkins: Drop style containiment from strict and content? 19:51:24 dholbert: That would make us reject 'contain: style' but... 19:51:33 chrishtr: CSS parsers can ignroe keywords they don't understand? 19:51:48 florian: If you as an author writes 'contain: style size" it'll be lost 19:52:01 q? 19:52:04 florian: but if you write 'contain: size; contain: style size' then you just lose the second declaration keep the first 19:52:10 TabAtkins: Most of the time we recommend strict anyway 19:52:19 florian: Seems like least harmful way to do this 19:52:30 chrishtr: And then we'll fix our bugs and allow ppl to opt in 19:52:43 Rossen: Any objections? 19:53:01 RESOLVED: remove style containment from keywords that aren't 'style' 19:53:07 RESOLVED: mark 'style' at risk 19:53:58 RESOLVED: Republish CR of css-contain once edits are in 19:54:26 chris: Ping me when you have a DoC and file a transition request 19:55:29 Topic: :host-context 19:55:31 github: https://github.com/w3c/csswg-drafts/issues/1915 19:55:56 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 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 emilio: Handling DOM changes when host-context selectors are involved 19:56:53 emilio: Blink solves this by doing subtree restyles? 19:57:12 futhark: So in Blink we aggregate style info at the docuemnt scope for everything 19:57:22 futhark: we don't use subtree calc 19:57:29 futhark: We invalidate inside the shadow root 19:57:37 futhark: We use a flag for it 19:57:53 emilio: One of the nice things in our impl is that the style info inside the shadow root is contained 19:57:59 emilio: Blink wants to make such a change, too 19:58:10 emilio: So effectively it's similarly slow as /deep/ 19:58:18 emilio: Since I haven't seen anything in Bugzilla requesting it 19:58:27 emilio: And WebKit also hasn't implemented 19:58:29 emilio: So would like to drop 19:58:46 futhark: I don't have the usage numbers... 19:58:51 TabAtkins: We should see if it's used 19:58:59 futhark has joined #css 19:59:02 TabAtkins: It offers a useful functionality but if ppl aren't suing it, I"m fine with dropping it 19:59:12 Rossen: So, collect data, come back and based on this we can move forward 19:59:34 fantasai: So maybe flag for next F2F so we don't forget 19:59:40 Rossen: Hope to get to it before 19:59:49 Topic: end 19:59:53 futhark_ has joined #css 20:00:35 christr: When is transform breakout? 20:00:38 TabAtkins: 2-3pm 20:00:44
20:00:53 futhark has joined #css 20:02:46 plh has joined #css 20:37:44 mstensho has joined #css 20:41:24 bdc has joined #css 20:52:08 Karen has joined #css 21:03:43 futhark has joined #css 21:03:46 xfq has joined #css 21:04:08 jensimmons has joined #css 21:04:12 myles__ has joined #css 21:04:22 ScribeNick: myles__ 21:04:55 smfr has joined #css 21:06:11 Topic: High Constrast 21:06:17 s/Const/Con/ 21:06:24 bdc has joined #css 21:06:52 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 melanierichards: Let’s go over how it works on Windows! 21:07:13 melanierichards: also let’s make a proposal for how it might be standardized 21:07:50 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 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 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 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 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 melanierichards: Then there’s Windows High Contrast feature. 21:09:56 https://www.w3.org/TR/WCAG21/#contrast-minimum 21:10:04 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 has joined #css 21:10:12 Rossen: Demo of high contrast 21:10:55 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 Rossen: High contrast on windows is a system-wide accessibility setting 21:11:42 mattwoodrow has joined #css 21:11:56 Rossen: Doing a live demo is always fun. Let’s keep it positive and make sure everything works. 21:12:56 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 Rossen: Win32 apps will be forced into high contrast. 21:13:23 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_ has joined #css 21:14:41 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 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 Rossen: This is not supposed to be dark mode. 21:15:36 Rossen: Please hold questions to the end. 21:15:49 Rossen: Links are yellow, text is white, black is reduced down to black. 21:15:58 Rossen: YouTube! 21:16:39 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 Rossen: Bing search! 21:17:19 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 Rossen: Flickr is image rich. 21:17:56 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 Rossen: Switching to my remote machine in Redmond... 21:18:17 Rossen: Let’s let it connect. 21:18:24 Rossen: Let’s look at IE while it connects. 21:18:43 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 has joined #css 21:18:59 s/backlight/backplate/ 21:19:14 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 Rossen: Bing won’t be happy if we do this. 21:19:55 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 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 Rossen: The same thing can be achieved 21:21:21 Rossen: E.g. for Bing, this site takes advantage of the high contrast theme, same thing for Flickr. 21:21:39 Rossen: The highlights have text that is composed against an opaque background. 21:21:46 Rossen: That’s everything I wanted to demo. 21:22:02 Rossen: Let’s finish the deck before questions and answers. 21:22:19 Rossen: PowerPoint is in high contrast ofc because my machine is in High Contrast. 21:22:31 Rossen: I just created a theme for fun which has low contrast. And here it is! (It’s blue) 21:23:07 melanierichards: Shows a table to show a feature comparison 21:23:11 Table: Related OS/extension feature comparison 21:23:14 melanierichards: Inverted colors and high contrast are forced on user 21:23:31 Column headings: Dark Mode, Inverted Coors, Text Contrast, Inreas Contrast, High Contrast extension, High Contrast 21:23:49 Row headings: supported Platform, contrast "promise", Applies to, Modifieable by users, Forced to Web content, .... 21:23:51 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 Table: CSS Fetaures Comparision 21:24:10 Columns: prefers-color-scheme, prefers-contrast, inverted-colors, high-contrast 21:24:15 melanierichards: prefers-color-scheme: Here’s the color scheme this user prefers, please author make something that matches 21:24:32 Rows: Related browser/OS features, granularity of detection in Web content, expectations on author, additional info available to author, implementations 21:24:34 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 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 melanierichards: Inverted colors is a feature where we’re tartgetting activation for the feature rather than a couple difference points 21:25:36 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 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 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 melanierichards: We want a consistent web dev story. Maintiain existing styles for IE, as well as new styles for modern browsers 21:26:58 melanierichards: Authors are familiar with these. Authors can alias past styles and get the author styles for free 21:27:07 melanierichards: We created an explainer. MS Edge Explainers Repo. 21:27:30 https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/HighContrast/explainer.md 21:27:32 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 melanierichards: If anyone else wants to implement a similar feature, they can do it as well 21:27:52 melanierichards: high-contrast:active is a media query. 21:28:01 You can also detect white on black or black on white 21:28:24 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 q+ 21:28:41 melanierichards: This makes it good for tweaking. Authors can maintain this. 21:29:00 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 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 Rossen: We used to have fairly large percent of usage of high-contrast-adjust property. 21:30:13 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 has joined #css 21:30:47 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 Rossen: Facebook removed their use of it because the backplate was sufficient for them. 21:31:08 Rossen: Twitter was the same 21:31:55 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 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 Rossen: What I implemented in Edge is what they said was pretty optimal 21:33:35 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 has joined #css 21:33:39 Rossen: This is the story of high contrast. 21:34:15 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 has joined #css 21:34:51 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 q? 21:35:09 Rossen: Questions 21:35:12 q+ 21:35:13 ack fl 21:35:18 q+ 21:35:24 q+ 21:35:40 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 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 florian: Does it expose all of that? 21:36:42 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 As in, what's the summary of webdev use-cases? 21:36:48 Related CSSWG issue: https://github.com/w3c/csswg-drafts/issues/1286 21:36:58 florian: HOw do we make sure we don’t increase the contrast when the user wanted the opposite? 21:37:43 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 q- 21:38:44 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 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 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 Rossen: Sites that use high-contrast should use system colors 21:40:01 zakim, close queue 21:40:01 ok, astearns, the speaker queue is closed 21:40:03 fremy: yes 21:40:07 q? 21:40:30 Should we make the system colors work for platforms other than Windows...? 21:40:35 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 q+ 21:40:49 ack emilio 21:40:52 +1 to florian 21:40:59 emilio: This is great. 21:41:37 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 Rossen: Yes. We have env() already, maybe we can use that 21:42:18 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 Rossen: Currently, people fetch system colors and they ... 21:43:06 s/rather than something/rather than just doing something which might not match what what the user wanted/ 21:43:07 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 has joined #css 21:43:21 Rossen: you need the computed value of adjust before you get the rest of the style. 21:43:25 Rossen: Let’s take this offline. 21:43:28 emilio: ok 21:43:35 emilio: 👍 21:43:35 ack Am 21:44:47 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 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 Rossen: On Windows, we have “top light” which is the highlight color for links 21:46:05 Rossen: In edge, we support -ms-edge-top-light 21:46:12 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 Rossen: On Windows, this is available 21:46:28 Rossen: We didn’t not investigate Linux. I would love for someone to expand our knowledge on Linux 21:47:18 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 AmeliaBR: ... without using !important 21:47:56 https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/HighContrast/explainer.md 21:47:57 Rossen: I discuss this in the explainer. 21:48:25 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 q? 21:48:34 q+ 21:49:18 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 r overrides. 21:49:23 Rossen: I agree. 21:49:39 AmeliaBR: css-cascade and css-media-queries are involved. 21:49:41 ack smfr 21:50:18 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 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 This cascading thing sounds scary... 21:51:29 +1 to that 21:51:40 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 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 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 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 Rossen: Do we need a resolution to add this to the CSSWG charter as something we want to work on? 21:54:24 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 Rossen: Perhaps the backplate is something else, too. 21:54:49 q+ 21:55:26 Rossen: As we work on this, we’ll find the right spots and the righ teditors. 21:55:32 fantasai: I’m one of the editors. 21:55:37 Rossen: yes. 21:55:51 RESOLVED: Let’s look into high contrast support on the Web 21:56:22 Maybe s/high contrast/specific contrast/ since sometimes it's low contrast? 21:56:49 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 florian: The UA can automatically opt-in in these situations 21:57:43 Rossen: Sounds reasonable 21:58:05 fremy: Are you willing to simplify cascade changes to ease implementation burden? 21:58:21 Rossen: yes. I tried to in Chromium and it worked great 21:58:36 TabAtkins: The backplate looks just like captions. We can kill 2 birds with 1 stone 21:58:39 Rossen: Yes 21:59:28 Rossen: The reason I used this example is .... this is unreadable (points at unreadable text on the screen) 21:59:54 Rossen: but if you enable high contrast, now you know that it’s Snowy Eagles 22:00:01 Rossen: I’m going to stop while I’m ahead. 22:00:57 futhark has joined #css 22:01:14 We're continuing on UI topics here, on breakout topic in breakout, and then coming back to dark mode later. 22:02:46 bgirard has joined #css 22:04:13 github: https://github.com/w3c/csswg-drafts/issues/3344 22:04:16 zakim, reopen the queue 22:04:16 ok, xfq, the speaker queue is open 22:04:25 github: none 22:04:26 github: none 22:04:43 Topic: The computed value rules of user-select is problematic 22:04:51 github: https://github.com/w3c/csswg-drafts/issues/3344 22:05:50 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_ has joined #css 22:06:18 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 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 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 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 has joined #css 22:08:54 florian: I was on an agreement rollercoaster 22:09:31 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 florian: Now that it’s a value, you can apply that value to other things. 22:09:59 florian: Maybe you want to contain your selection to the body of content, so you don’t select UI 22:10:14 florian: Maybe we need selective inheritance. All values inherit, except “contain” 22:10:51 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 florian: It’s almost the same thing. 22:11:24 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 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 florian: it’s not inherited. If the value is auto, look at the parent. 22:12:26 koji: Blink already experienced that once before, but used value is easier for us, too 22:12:30 florian: okay 22:12:55 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 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 florian: Is it reasonable to assume webkit’s cooperation? 22:14:11 smfr has joined #css 22:14:25 smfr has joined #css 22:14:30 astearns: proposed resolution: auto computes to auto, but the used value does what it currently says auto computes to 22:15:16 smfr has joined #css 22:15:18 dholbert: This needs to be reflected in the used value, too 22:15:31 RESOLVED: auto computes to auto, but the used value does what it currently says auto computes to 22:15:56 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 emilio: UA rule, so it can be override it. 22:16:14 florian: We didn’t want it to be overridable 22:16:24 emilio: Gecko allows it to be overridden. But it’s fine 22:17:36 ScribeNick: heycam 22:17:41 Topic: appearance 22:17:51 github: 1324 22:18:08 florian: I can do a progress report 22:18:14 ... zcorpan elika and I discussed this 22:18:17 ... we reached an agreement 22:18:17 github: https://github.com/w3c/csswg-drafts/issues/3024 22:18:23 ... last time we appearaed to have opposing visiions 22:18:26 ... we no longer do 22:18:39 ... we've fixed the high level mechanics part of the spec based on that agreement 22:18:51 fremy has joined #css 22:18:58 ... and there remained the details about small exceptions/tweaeks for web compat on top of that general principle 22:19:08 ... the parts that haven't been made should be marked as open issues in the spec 22:19:17 ... afaik we now have a model that everyone agrees about 22:19:23 iank_: 2 sentence tldr? 22:19:41 florian: the appearance property with a gazillion values for expressing UA sheet is not what we're going to do 22:19:45 Spec https://drafts.csswg.org/css-ui-4/#appearance-switching 22:19:49 ... the model is based on auto/none, initial value none 22:19:57 ... UA sheets to auto on all elements that need special behavior 22:20:03 ... due to HTML semantics they'll look right 22:20:06 ... that's not sufficient for webcompat 22:20:11 ... maybe 6..12 values that are used by authors 22:20:22 ... most of them can be made to do the same thing as auto 22:20:33 ... we're not interested in allowing people to turn drop down menus into checkboxes 22:20:51 ... 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 fantasai: there were a a couple of values that will work on other elements 22:21:05 florian: like button 22:21:08 ... to buttonize an element 22:21:14 ... we have specified that 22:21:16 fantasai: and textfield 22:21:29 iank_: looks like zcorpan did a good job doing compat analysis based on our data 22:21:51 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 ... and both sides of that discussion is happy with the other 22:22:03 fantasai: you me francois and zcorpan 22:22:18 astearns: there were a few things remaining that should be spec issues? 22:22:24 florian: there are places in the spec with issue boxes already 22:22:30 ... details needed based on compat info 22:22:42 fantasai: we should at some point resolve and publish a draft 22:22:46 ... and continue filling in details 22:22:46 atrigent has joined #css 22:22:48 myles__ has joined #css 22:22:59 florian: I need to refresh my memory on the exact status of it all 22:23:13 fantasai: high level summary is: we have an appearance property, initial value is none 22:23:27 ... it has the values none | auto | button | textfield and a bunch of compat keywords that map to auto 22:23:32 ... UA sheet sets auto on most form controls 22:23:42 ... then there are some tweaks for compat from now on 22:23:52 astearns: that's in the ED now? 22:23:53 fantasai: yes 22:24:23 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 florian: as for publishing, we should do it after I apply the edits from the user-select dicsussions 22:24:47 ... I'll add those in then put a WD out 22:25:00 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 RESOLVED: Close this issue as addressed, then publish a new WD once pending edits for this spec are done. 22:25:54 zcorpan_++ 22:26:22 Topic: Outline around descendants 22:26:27 ScribeNick: fantasai 22:26:32 github: https://github.com/w3c/csswg-drafts/issues/2846 22:26:54 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 heycam: and we do get some compat issues from that 22:27:20 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 s/principle/principal/ 22:27:29 heycam: Different things happen 22:27:40 heycam: but the important difference is that no descendants contribute to the outline position or size 22:27:50 heycam: Definition fo outline in the spec is deliberately vauge so that UAs can do something fancy 22:27:52 q+ 22:28:05 heycam: but there is a suggestion that descendants should contribute to the outline 22:28:10 mstensho has joined #css 22:28:17 heycam: but I'm suggesting that we switch the suggestion to say that they should not 22:28:20 iank_: ... 22:28:53 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 iank_: but then there's the focus outline, when an element is focusable and you focus it 22:29:07 iank_: You might want to handle that a different way 22:29:11 q- since I was basically gonna bring up the focus outline side of things 22:29:15 1- 22:29:18 q- 22:29:25 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 florian: You can do whatever you want 22:29:39 florian: Intent is that browsers implement focus outline with that 22:29:51 florian: What UAs actually do, may be it's different 22:30:16 emilio: outline-style: auto not only changes shape of outline, but also uses the system focus outline style 22:30:28 emilio: Firefox does something weird on Linux, because bugs, but that's it 22:30:33 emilio: it should otherwise match the OS 22:30:55 emilio: Not just about channging shape but also style 22:31:17 gregwhitworth: was curious about removing descendants from outline 22:31:25 gregwhitworth: I don't want removing descendants from focus to be the default 22:31:27 iank_: I think we agree 22:31:39 iank_: the behavior that I think we want is for the outline property, it doesn't include descendants 22:31:43 iank_: but for focus outline it does 22:31:46 florian: Define focus outline 22:32:31 gregwhitworth: Rob Dotson and Alice Boxhall were thinking that it shouldn't follow descendants 22:32:34 gregwhitworth: but currently it does 22:32:44 iank_: Why for focus outline, by default, should it enclose descendants? 22:32:48 s/Dotson/Dobson/ 22:33:03 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 gregwhitworth: Many cases where Chrome's rendering looks weird e.g. in FB on Chrome 22:33:25 gregwhitworth: Other cases it looks weird 22:33:33 gregwhitworth: e.g. wrapping around weird pseudo-elements 22:33:57 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 gregwhitworth: That's happening because looping in descendants 22:34:16 iank_: You could have an alternate implementation that's just a bounding rect 22:34:20 gregwhitworth: I'd be more OK with that 22:34:24 bgirard has joined #css 22:34:31 gregwhitworth: Saying that these few sites, we no longer care about descendants, seems odd 22:34:44 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 iank_: thinking about simplifying and just doing the bounding box 22:35:02 iank_: Then the question is in that state, what's the best calculation? 22:35:03 q? 22:35:18 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 fremy: If you don't include abspos element, you aren't able to actually show the focus ring around the link 22:35:52 fremy: I'm curious if you can do it with one single rectangle 22:36:14 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 heycam: ... 22:36:18 myles__ has joined #css 22:36:25 q+ 22:36:42 can someone repeat what iank just said? 22:36:45 iank_: Splitting the discussion slightly, sounds like everyone would be fine if the non-auto outline style ... 22:37:02 iank_: sounds like we'd be fine with it not including descendants and just being the border box 22:37:09 [high contrast slides link] https://lists.w3.org/Archives/Public/www-archive/2019Feb/0000.html 22:37:13 florian: Want to clarify definitions 22:37:21 florian: The definition of focus outline that is in the issue that you refer to 22:37:30 florian: includes some cases of the proeprty-based outline 22:38:10 rachelandrew has joined #css 22:38:14 florian: In the issue now there is the definition of focus outline being either: 22:38:26 florian: a) the outline painted whichever way while the element is in focus or 22:38:31 florian: b) when the outline-style is auto 22:38:40 atotic: That's how it's implemented in Chrome atm 22:38:57 ack florian 22:39:02 florian: Alternate definition is "only outline when element is in focus" 22:39:10 Another definition woudl be only when it's non-auto... 22:39:22 q+ 22:39:24 gregwhitworth: You need to be focussed and outline 22:39:44 ack fantasai 22:39:56 fantasai: so this definition is a little weird, let's say I set an outline: solid purple on a link 22:40:13 fantasai: and the behaviour will change depending on whether we focus the link 22:40:45 futhark has joined #css 22:41:30 iank_: this is what we currently implement today 22:41:33 fantasai: we need a definition that doesn't do that 22:42:03 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 it is still a problem 22:42:20 q+ 22:42:31 jensimmons: outline: 0 no longer appears on CSS resets anymore 22:42:45 jensimmons: nor frameworks. Of course some people still do that but... 22:42:48 q+ 22:42:48 jensimmons: Word has gotten out, don't do that. Of course ppl still do it, but it's getting better 22:42:52 ack emilio 22:43:09 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 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 emilio: Then xidorn changed to only include in-flow elements 22:43:37 heycam: I think only for abspos 22:43:52 emilio: As far as I understand, one of the use cases we want to bring back... 22:44:02 emilio: Does Blink include auto flows in their descendant stuff? 22:44:07 s/auto flows/overflow/ 22:44:15 s/overflow/out-of-flow/ 22:44:30 atotic: It depends. Only if the outline is around the containing block 22:44:36 emilio: Ancestor containing block? 22:44:43 atotic: *emphatic shrug* 22:45:07 emilio: I agree thwith fantasai that having two different behaviors depending on whether focused or not is very weird. 22:45:14 emilio: Maybe take greg's advice to give authros control 22:45:36 atotic: Our behavior is OK because we don't do bounding box, if boxes are disjoint then they each get outlined 22:45:44 atotic: Now that merging boxes, less tolerable 22:45:52 florian: Two kinds of merging boxes 22:46:00 florian: One is when boxes are not next to each other, have a box around each 22:46:11 florian: Other is when they touch each other have either a non-rectangular outline that wraps both 22:46:17 florian: or boundign box 22:46:27 I'm not seeing Chrome wrap this abspos in focus: https://jsbin.com/muyemusofo/1/edit?html,css,output 22:46:32 florian: E.g. For Presto, if two fragments being outlined are not adjacent, you get two outlines 22:46:45 florian: but if they are adjacent, you get one non-rectangular outline around the whole shape 22:46:49 florian: There are nuances within this 22:47:04 emilio: I think we should come up with a consistent plan 22:47:06 q? 22:47:09 ack b 22:47:15 q+ 22:47:35 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 bkardell_: Will help when :focus-visible is implemented everywhere. Also :focus-visible-within 22:48:03 bkardell_: I've seen a lot of ppl make comments about confusion around outline 22:48:11 bkardell_: Maybe we should really have two properties 22:48:26 fantasai: or a switch between behaviors 22:48:34 q? 22:48:34 bkardell_: Using same thign for two purposes seems quite strange 22:48:46 bkardell_: We tell ppl don't use border, use outline for focus rectangles 22:48:50 bkardell_: So we could use borders 22:48:56 bkardell_: Maybe have a thing that's about focus rectangle 22:49:33 +1 to what fantasai just said (minuted below) 22:49:47 mstensho has joined #css 22:50:16 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: and other outline-style values give a more normalized outline shape, appropriate for extra "border" looking things 22:51:05 ack fl 22:51:23 q+ bkardell_ 22:51:32 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 florian: Other half is less clear. It's often used decoratively, but not strictly 22:51:42 q+ 22:51:53 florian: We can spec the auto style to be just the right thing for outline styles 22:52:00 florian: Maybe time will help 22:52:19 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 inline desc are wrapped https://output.jsbin.com/gimiwigije/1 22:52:29 florian: but we don't have that yet. And might take awhile for ppl to move over 22:52:31 q? 22:52:33 q+ 22:52:37 ack iank 22:52:59 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 fremy: I work on that, btw 22:53:15 gregwhitworth: melanierichards is also here 22:53:23 ack bk 22:53:37 bkardell_: It feels like we're not really serving the best use cases that we could 22:54:05 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 bkardell_: it's pretty hard 22:54:39 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 Are there specific examples of such "really beautiful design" where this is a challenge? 22:54:50 bkardell_: A lot of OSes have developed what I assume is glowy outlines 22:55:07 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 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 bkardell_: we could serve taht better and more appealing, then more likely ppl make accessibile things 22:55:44 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 ack greg 22:55:57 gregwhitworth: I 100% agree with bkardell_ 22:56:13 gregwhitworth: We are currently finishg up a study with 160 users on focus testing, for this reason 22:56:20 gregwhitworth: because we belive the one in Chromium is not sufficent 22:56:24 gregwhitworth: One issue is wht bkardell_ brought up 22:56:38 gregwhitworth: we also looked into prototyping always-visible outlines 22:56:43 gregwhitworth: to provide sufficient contrast 22:56:56 gregwhitworth: I saw emeyers' scenario of always wanting to ensure high contrast 22:57:11 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 gregwhitworth: so you can use a keywrod where youc an't sue the inversion value 22:57:28 gregwhitworth: It's just that it looks realy gross when you want a great design 22:57:33 gregwhitworth: two things taht came up out of that testing 22:57:44 gregwhitworth: one, doing a good focus rect in browser sucks 22:57:50 gregwhitworth: doesn't follow border radius is problematic 22:58:00 gregwhitworth: I had to hack with border outline and drop-shadow to get the right effect 22:58:09 gregwhitworth: I think we should tease out the pieces of following the rect 22:58:13 tantek does greg's expanding answer your question? 22:58:18 gregwhitworth: also want to have gradient 22:58:25 gregwhitworth: Similar to ... 22:58:43 gregwhitworth: In addition, emilio's proposal of whether or not you want to include descendants or not 22:58:51 gregwhitworth: will share more publicly once we have the report 22:58:57 emilio: what he said. 22:59:01 q? 22:59:06 q- 22:59:07 ack emilio 22:59:21 heycam: It think most important thing given distinction between focus outlines and decorative outlines 22:59:37 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 heycam: At the moment, we include all in-flow descendants 22:59:59 gregwhitworth: I have interop on all 3 browsers in Windows 23:00:15 [discussion about testing] 23:00:25 heycam: I only tested normal outlines, and definitely saw differences 23:00:33 emilio: Also Firefox only changed recently, might want to test Nightly 23:00:43 astearns: Sounds like we won't resovle anything right now, but we need to figure out interop 23:01:00 astearns: First thing to figure out as we go through these issues in addition 23:01:06 heycam: So next step is wait for this report? 23:01:20 ACTION: gregwhitworth open issues against outline on all the aforementioned issues 23:01:21 Created ACTION-877 - Open issues against outline on all the aforementioned issues [on Greg Whitworth - due 2019-03-05]. 23:01:32 astearns: Let's keep this issue on descendants and open more issues for the rest 23:01:38 astearns: OK that's it for this topic! 23:01:40 BREAK TIME 23:01:44
23:01:52 Topic: end 23:02:36 futhark has joined #css 23:05:49 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 tantek there are some screenshots in there if you poke around the thread and contemporary tweets with eric 23:12:54 myles__ has joined #css 23:20:31 futhark has joined #css 23:20:31 xfq has joined #css 23:21:53 mstensho has joined #css 23:36:29 ScribeNick: emilio 23:37:28 topic: drop navbeforescroll 23:37:32 github: https://github.com/w3c/csswg-drafts/issues/3401 23:37:36 fremy has joined #css 23:37:58 jihye: we have three events, navbeforescroll triggers when there's no visible focusable element in the scroll container 23:38:34 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 https://raw.githack.com/jihyerish/spatial-navigation/spatnav-behavior/demo/scroller/index.html 23:38:50 jihye: so we'd like to propose a new CSS property, spatial-navigation-behavior, see ^ for demo 23:39:08 jihye: this property is aimed to split scrolling and moving the focus behavior, to avoid scroll latency 23:39:10 bdc has joined #css 23:39:55 https://raw.githack.com/jihyerish/spatial-navigation/spatnav-behavior/demo/infinite-scroller/index.html 23:39:57 jihye: and it helps to implement the use-cases like infinite scrolling 23:40:28 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 has joined #css 23:41:01 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__ has joined #css 23:41:26 florian: initially we wanted to go with events only rather than declarative syntax, so people could experiment 23:41:55 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 eae: yeah, thanks for coming up with that proposal 23:42:25 florian: we've iterated quite a bit on naming, last proposal is spatial-navigation-action: auto / focus / scroll 23:42:37 florian: normal behavior is a combination of focus and scroll 23:42:53 florian: if you use focus, it'll just jumps across focusable elements 23:43:20 florian: instead of scrolling step by step, like auto 23:43:45 florian: scroll is the opposite, it will just scroll it and skip focusable elements inside 23:44:44 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 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 astearns: would it make sense to have three values with scroll noted like "maybe dropped" 23:45:45 jihye: maybe just add it later 23:46:07 smfr has joined #css 23:46:11 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 florian: if somebody finds a better name, then even better 23:46:54 bkardell_: so currently this demo works setting some DOM properties? 23:47:07 jihye: I showed two demos, which one? 23:47:21 bkardell_: let's take spatial-navigation-action? Is it just using a dom property in the demo? 23:47:28 gtalbot has joined #css 23:47:37 florian: the demo uses a polyfill? 23:47:42 s/?// 23:47:50 bkardell_: I was wondering how it was implemented, custom props? 23:47:57 jihye: yeah, it's a custom property 23:48:16 s/polyfill?/polyfill/ 23:48:30 RESOLVED: drop navbeforescroll and add `spatial-navigation-action` with at least two values 23:48:51 topic: end 23:49:13 topic: css-nav FPWD 23:49:31 astearns: there are any other implementors interested in this spec? 23:49:43 florian: other than google? 23:49:57 q+ 23:50:08 astearns: yeah, we have google and polyfill, but no more implementor interest 23:50:30 smfr: webkit has an implementation but it's not maintained. It was contributed by an external contributor 23:50:34 ack bk 23:51:02 bkardell_: so, when we met at TPAC, florian did mention that vivaldi wanted to ship the polyfill? 23:51:18 florian: that's right, we've talked with them about replacing their implementation with their jihye's polyfill 23:51:37 bkardell_: yeah, I don't think it counts as an implementation but we can get feedback 23:51:43 presenter has joined #css 23:52:15 astearns: I think a shipping polyfill we can write tests against is useful 23:52:27 emilio: but you can't test syntax or other implementation details with that 23:52:54 q+ 23:53:03 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 https://www.npmjs.com/package/spatial-navigation-polyfill 23:53:26 jihye: this polyfill is in npm and I plan to keep maintaining it so we can get some feedback from devs 23:54:00 ack fl 23:54:03 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 has left #css 23:55:12 astearns: comments? objections? 23:55:20 \o/ 23:55:24 RESOLVED: Publish FPWD of css-nav 23:56:48 Topic: distance function 23:56:50 github: https://github.com/w3c/csswg-drafts/issues/3384 23:56:53 jihye: I've been working on improving the distance function to move focus to the correct next target. 23:57:14 jihye: If you have any opinions it'd be useful, and I think it's the biggest issue 23:57:36 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 florian: jihye has done a lot of great work on that, which is strictly better than what's on the spec 23:58:16 q? 23:58:37 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 AmeliaBR: does the geometric calculation really need to be specified? 23:58:58 AmeliaBR: do any other thing depend on the result of the function? 23:59:32 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