16:58:39 zakim, start meeting 16:58:39 inviting RRSAgent 16:58:39 logging to https://www.w3.org/2021/02/24-css-irc 16:58:42 RRSAgent, make logs Public 16:58:42 I have made the request, Zakim 16:58:43 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 16:59:05 present+ 16:59:09 present+ 16:59:10 present+ 16:59:13 ScribeNick: dael 16:59:16 present+ 16:59:55 present+ 17:00:54 present+ 17:01:04 present+ 17:01:42 present+ 17:01:46 astearns: We'll wait another minute or so 17:02:00 present+ 17:02:04 present+ 17:02:15 present+ 17:02:35 present+ 17:02:54 astearns: We should get started 17:03:02 astearns: Does anyone have any changes to the agenda? 17:03:06 Topic: [mediaqueries-5] duplication of `forced-colors: active` and `prefers-contrast: forced` 17:03:15 Github: https://github.com/w3c/csswg-drafts/issues/5433 17:03:15 * github-bot OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/5433 ([mediaqueries-5] duplication of `forced-colors: active` and `prefers-contrast: forced`). 17:03:38 alisonmaher: For a bit of context chromium has impl of prefers-contrast behind flag. Pretty sure FF does as well 17:04:08 In favor of 'prefers-contrast: forced'- https://github.com/w3c/csswg-drafts/issues/5433#issuecomment-716954048 17:04:13 Against 'prefers-contrast: forced'- https://github.com/w3c/csswg-drafts/issues/5433#issuecomment-716954108 17:04:14 alisonmaher: p-c:f is duplication of forced-colors MQ. Previously agreed to keep for compat. Do we want to keep p-c:f or not? Strong arguments on both. jcraig summarized them well ^ 17:04:34 present+ 17:04:44 present+ 17:04:49 alisonmaher: In favor is it shortens the MQ needed to match any combo of users and reduces likelyhoold that authors overlook users with a different color sceme than less or more 17:05:06 alisonmaher: against it doesn't add any additional benefit and removing provides more clarity to authors on which to use and how it works 17:05:06 q+ 17:05:06 * Zakim sees jcraig on the speaker queue 17:05:11 q+ 17:05:11 * Zakim sees jcraig, florian on the speaker queue 17:05:23 present+ 17:05:28 alisonmaher: I tend toward remove b/c simplifies and matches more to prefers color scheme approach which jsut matches to dark or light. 17:05:45 alisonmaher: Perhaps a middle ground where we remove but still capture the users, but not sure what that would look like. 17:05:45 q? 17:05:45 * Zakim sees jcraig, florian on the speaker queue 17:05:51 present+ 17:05:56 jcraig: Thanks alisonmaher for the summary 17:05:57 ack jcraig 17:05:57 * Zakim sees florian on the speaker queue 17:06:33 q+ 17:06:33 * Zakim sees florian, TabAtkins on the speaker queue 17:06:43 * TabAtkins jcraig is pretty quiet 17:06:47 jcraig: One piece not mentioned is there's an assumption that all forced-color users reglardless of match less or more want reduced complexity. I don't believe it's true. Don't have evidence, but don't think evidence exists. My hunch is these people customize and don't have a preference on complexity. Seems coorilation vs causation 17:07:15 ack florian 17:07:15 * Zakim sees TabAtkins on the speaker queue 17:07:15 jcraig: Suggestion alisonmaher mentioned about a way to match both, I don't think it's desirable b/c I don't know of need. Looked like dlibby commented along the same lines 17:07:24 florian: Thanks to alisonmaher and jcraig. 17:08:04 q- 17:08:04 * Zakim sees no one on the speaker queue 17:08:07 florian: I disagree with jcraig this is people tweaking colors b/c forced-colors changes the colors of your webpage and since you don't have full range of colors available a number of htings will break like gradients. force-color pallate is reduced 17:08:08 present+ 17:08:11 florian is saying exactly what i was going to 17:08:17 florian: b/c of that I thinkw e fall into needing reduced complexity 17:08:20 I agree with florian 17:08:22 dlibby's comment: https://github.com/w3c/csswg-drafts/issues/5433#issuecomment-780191074 17:08:52 florian: Otherwise, I think priority of consistency applies. For authors separation is nicer. Slightly shorter syntax is probably not worth it. Users, though, nice for the small set of users not to be forgotten 17:09:14 astearns: Any other comments? 17:09:17 [silence] 17:09:20 q? 17:09:20 * Zakim sees no one on the speaker queue 17:09:31 astearns: Proposal is remove the forced value for prefers-contrast 17:09:32 present+ 17:09:35 q+ 17:09:35 * Zakim sees jcraig on the speaker queue 17:09:50 s/prefers-contrast/prefers-contrast and de-link the two media queries/ 17:10:00 q? 17:10:01 * Zakim sees jcraig on the speaker queue 17:10:03 florian: I think we've made progress about where there's an issue. Not sure we agree on the solution 17:10:04 ack JaseW 17:10:04 * Zakim sees jcraig on the speaker queue 17:10:06 ack jcraig 17:10:06 * Zakim sees no one on the speaker queue 17:10:08 ack jcraig 17:10:08 * Zakim sees no one on the speaker queue 17:10:54 jcraig: On mac and iOS the underlying archetecture allows us to use increased contrast and other settings and would allow a really high contrast forced-colors in the future. Similar to MS. Issue we've seen in the past is b/c MS is only impl of forced-colors we don't know end result will match that exactly 17:11:08 jcraig: We don't have direct plans to do that, but I'd like to see it. 17:11:42 q+ 17:11:43 * Zakim sees Morgan on the speaker queue 17:11:43 q+ 17:11:43 * Zakim sees Morgan, TabAtkins on the speaker queue 17:11:48 jcraig: Leaving the forced-colors media feature open and extensible would allow us to better match varients across impl. Shoehorning into prefers-contrast limits that in the future. I think it would be good to leave extensible 17:12:09 Rossen_: Quick point, chrome is almost done so won't be only one I presume 17:12:17 jcraig: I'm talking platform, not browser 17:12:23 Rossen_: My bad. I thought you were talking about browser 17:12:26 ack Morgan 17:12:26 * Zakim sees TabAtkins on the speaker queue 17:12:40 * fantasai q+ 17:12:40 * Zakim sees TabAtkins, fantasai on the speaker queue 17:12:47 * jcraig thanks Morgan 17:12:54 ack TabAtkins 17:12:54 * Zakim sees fantasai on the speaker queue 17:12:54 Morgan: I have a follow up. FF has its own version of forced-colors that we allow on any platform. It's another impl same as MS one. There is another sort of platform impl there. 17:12:58 * fantasai q- 17:12:58 * Zakim sees no one on the speaker queue 17:13:33 TabAtkins: In jcraig earlier comment you seemed to say you should leave forced-colors more open. Do you think there's anything we could query for about forced colors beyond on or not? From our designs there wasn't anything you can conclude beyond on or not 17:13:51 q+ 17:13:51 * Zakim sees jcraig on the speaker queue 17:14:01 fantasai: And forced-color limits the pallate. You could have forced-color that's similar to increased contrast which keeps hue but turns the constrast way up 17:14:12 TabAtkins: I don't think that's consistent with idea of forced-colors as we have 17:14:15 present+ 17:14:18 fantasai: yeah, forced-contrast mode 17:14:20 ack jcraig 17:14:20 * Zakim sees no one on the speaker queue 17:14:34 s/way up/way up, but that would be a different feature/ 17:15:11 jcraig: Speculating on that question. Closest thing I'm aware of is closed captions have default colors and forced colors. Similar to user styles vs overwritten user styles where you can say if media doesn't spec the font then I want it to be in monospace. If it does spec leave as spec. And you can override author 17:15:32 q? 17:15:32 * Zakim sees no one on the speaker queue 17:15:35 q+ 17:15:35 * Zakim sees florian on the speaker queue 17:15:44 jcraig: Closest thing to speculate on is this mixed force-ness where you may say for caption blocks I want forced, but don't care about others. mixing of DOM and elements. All speculation 17:16:04 ack florian 17:16:04 * Zakim sees no one on the speaker queue 17:16:19 florian: I think today I'm the only one who explicitly was in favor of retaining it. I would like a sense of if I'm alone 17:16:28 TabAtkins: In IRC both fantasai and I said we think the same as you 17:16:31 fremy: And I did 17:16:54 astearns: My take is we have two separate opinions and neither side has conviced the other. My bias is remove until people can be all convinced it should be there 17:17:19 q+ 17:17:19 * Zakim sees dlibby on the speaker queue 17:17:21 fantasai: Would create compat problems. prefers-contrast is triggering...I guess can try, but if triggering on some cases but not other and we change it. Would be a minority of cases, I guess 17:17:27 Rossen_: Do you have data? 17:17:58 florian: My part it's logic but not data. I suspect MS is only party with data. We would want to look at the particular color schemes used by those with forced-colors which are neither high or low contrast 17:18:04 q+ 17:18:05 * Zakim sees dlibby, jcraig on the speaker queue 17:18:08 Rossen_: What about data of use removing it and looking for compat risk? 17:18:39 florian: That's future compat. If we do it one way and switch there are problems. If we remove it a small minority of users would have things worse if you follow my logic. 17:18:42 ack dlibby 17:18:42 * Zakim sees jcraig on the speaker queue 17:19:32 ack jcraig 17:19:32 * Zakim sees no one on the speaker queue 17:19:32 dlibby: Wanted to note we can gather data as we ship to understand impact. On compat point seems main motivation is for user and not web author. If seeing harm for users I think that's more of a concern than compat since those are the users who want these rules. But data of shipping without value could be useful 17:19:56 jcraig: I would agree if there's evidence. but florian said it was based on logic, sounded like speculative logic. 17:20:27 jcraig: Quoting dlibby from the issue, florian said MS would be one to know. dliby says [reads] 17:20:37 jcraig: It's about author and user benefit 17:20:43 q+ 17:20:43 * Zakim sees TabAtkins on the speaker queue 17:20:47 q+ 17:20:47 * Zakim sees TabAtkins, florian on the speaker queue 17:21:02 ack TabAtkins 17:21:02 * Zakim sees florian on the speaker queue 17:21:04 jcraig: And if this is larger problem in practice we can add, but removing is more difficult. It sounds like that comment is in favor or removing now. Fair dlibby ? 17:21:05 dlibby: Yes 17:21:13 agree with jcraig's last assessment 17:21:25 (and also the point TabAtkins is making now) 17:21:38 TabAtkins: Not to belabor too much. Idea about unclear author guidance, the point is there is explicit author guidance. ANyone with contrast preference you should reduce visual complexity. 17:21:44 dlibby from the issue: "We didn't get to this in the F2F last week, but I agree with the core of @cookiecrook's argument - I don't think there is strong evidence for the boolean form of prefers-contrast being used to reduce visual complexity, and would probably be difficult for authors to reason about (enhancement in service of respecting a user preference is much different from adjusting in response to forced changes to a page's appearance)." 17:22:10 * jcraig … "Also, if this does become a larger problem in practice, we would have the option of re-adding the value, whereas removing it would be more difficult. Another option (either now, or if the boolean usage ends up being problematic) would be always mapping forced colors mode to more or less, similar to what is done for prefers-color-scheme." 17:22:20 * cbiesinger speaking of f2f, are there minutes? I don't see them on the mailing list? 17:22:24 TabAtkins: Concern with add later is by then benefit of hey this is a new feature user guidance is lessened. Would be nice to have consistent story to say most of the time use prefers-contrast in bool and you can listen to more or less or system pallet, but for overall design bool works great 17:22:33 ..."As anecdata, I also ran across this blog post that expresses some of the same sentiments: 17:22:33 https://kilianvalkhof.com/2021/css-html/prefers-contrast-forced-is-a-mistake/ " 17:22:52 ack florian 17:22:52 * Zakim sees no one on the speaker queue 17:22:54 TabAtkins: If we decide we don't want it's not more problematic then adding in the future. Worst case we say it never matches. Not great, but we've had it before and cna shove in an appendix 17:23:33 florian: I did feel strongly against removing while we hadn't reached understanding about the question b/c felt bad to users was inappropriate. We do understand the disagreement now. Still feel strongly, but less bad about being overruled. 17:23:52 astearns: Can we get a resolution to remove the value and unlink the features and if there's user data in the future we can revisit 17:24:31 q+ 17:24:31 * Zakim sees jcraig on the speaker queue 17:24:31 regrets+ 17:24:43 fremy: Removing the value, we also mean if people enable the high contrast but set at middle contrast they won't match the MQ. That makes the feature useless. On windows I would jsut use MQ for forced-colors. Or I would have to dup the code. I'm not sure if value is nes but it makes sense. 17:25:06 fremy: Even if you treat the contrast as peole from Apple said, you want to remove complexity. You want same behavior when using forced colors 17:25:09 @media (prefers-contrast) or (forced-colors) 17:25:11 emilio: Can't you just not use or? 17:25:24 s/not// 17:25:31 q+ to mention these are different features 17:25:31 * Zakim sees jcraig on the speaker queue 17:25:42 fremy: True, but thing is devs won't test special case. They will assume prefers-contrast works. nobody will catch this tiny use case. That's the key of the issue 17:26:15 astearns: From my PoV, your particular case where someone used forced-colors to select with no contrast, I would prefer it did not match rpefers-constrast b/c there is no constrast. I think it's an argument to delink 17:26:44 fremy: Then maybe name is misleading. We want to use feature to reduce complexity, maybe name is wrong. Seems it would be unfortunate 17:26:46 ack jcraig 17:26:46 jcraig, you wanted to mention these are different features 17:26:48 * Zakim sees no one on the speaker queue 17:27:13 jcraig: Was going to say same. This is core of disagreement. Half the people think there's an association between people using forced colors in the window where it doesn't match but they still want less complexity 17:27:20 Alternate proposal: we drop (prefers-contrast) entirely for right now while we study the problem more and see if there's better things to do in the visual complexity sphere 17:27:27 "In my opinion, if CSS needs a media feature for prefers-reduced-complexity or prefers-improved-legibility, the working group should consider those separately." 17:27:33 jcraig: I get it, but I don't agree it's a match. I also suggested similar to your suggested fremy ^ 17:28:10 jcraig: The contrast features should be about constrast and forced-color should be about colors. I don't agree with a 100% corrilation 17:28:12 present+ myles 17:28:16 +1 to what james just said 17:28:17 fremy: What you said makes sense 17:28:30 astearns: TabAtkins suggestion in IRC I think we should consider separately 17:28:49 astearns: Prop: Removed the forced value 17:28:53 s/should be about constrast and forced-color should be about colors/should ONLY be about contrast and forced-colors should ONLY be about forcing colors 17:28:58 I agree with what James just said — the 100% association between the two isn't best. 17:29:03 s/should be about constrast and forced-color should be about colors/should ONLY be about contrast and forced-colors should ONLY be about forcing colors/ 17:29:08 jcraig, the reduction in complexity isn't because that's specifically requested. It's because in a reduced palette, you don't have the option to use intermediary colors and you *have to* make changes accordingly 17:29:12 +1 to what TabAtkins suggested 17:29:14 TabAtkins: That was jcraig suggestion and I was [missed]. Just aminutes correction 17:29:20 s/TabAtkins suggestion/jcraig suggestion/ 17:29:22 astearns: Will anyone object to removing it? 17:29:37 florian: Can we get a promise to collect data about the cases where it would be different? 17:29:42 fantasai: What data do you want? 17:29:56 q+ 17:29:56 * Zakim sees Morgan on the speaker queue 17:30:05 florian: Color schemes people use that would be neither high nor low and therefore would no longer match. So we can look and see if we made thigns better or worse 17:30:11 fantasai: Won't know unless you look at a page 17:30:31 ack Morgan 17:30:32 * Zakim sees no one on the speaker queue 17:30:35 TabAtkins: Since we have requirement that forced-color sheme opts into more or less, assuming there's a middle ground collecting data about it is would be valuble 17:30:46 planning on keeping (prefers-contrast: no-preference), i hope 17:30:54 of course 17:30:55 Morgan: Adding probes in FF which should detect browser and platform 17:30:58 astearns: Objections? 17:31:10 RESOLVED: Removed the forced value from prefers-contrast MQ 17:31:12 thanks Morgan 17:31:24 q+ 17:31:24 * Zakim sees jcraig on the speaker queue 17:31:26 astearns: TabAtkins proposal to drop prefers-constrast all together. Would get in way of collecting data 17:31:37 florian: Not necessarily. Collecting data about user settings, not sites 17:31:49 TabAtkins: Yeah, data isn't about if MQ is used, how categorization would work 17:32:11 astearns: I thought it would be useful to have to get set of people that have choosen a color scheme and have the MQ but missing out 17:32:23 ack jcraig 17:32:23 * Zakim sees no one on the speaker queue 17:32:29 q+ 17:32:29 * Zakim sees aja on the speaker queue 17:32:49 jcraig: Sounds like a windows argument. If we drop prefers-contrast can't impl apple contrast settings. They indecate a preference for more contrast. We have a beta impl for prefers-constrast:more in WK 17:33:36 TabAtkins: The prop is we drop temp while we think about problem space of constrast and visual complexity. We can bring right back when decide separate or don't need to think about visual complexity. It would be worse if we ship and then decide should be different. 17:34:14 jcraig: I don't think we've done this quickly. Has taken years to standardize prefers-constrast values. Just agreed less and more instead of high and low. Taken years b/c difference between Windows, and MacOS, and Android. 17:34:26 * fantasai q+ 17:34:26 * Zakim sees aja, fantasai on the speaker queue 17:34:37 might want to consider a way to SET prefers-contrast in user stylesheet 17:34:45 jcraig: Reduced complexity has higher association to prefers-reduced-transparency. I don't know we want to mix streams, but if you're associating should be reduced-transparency. Would object to removing 17:35:15 s/Would object to removing/Would object to removing prefers-contrast/ 17:35:19 * astearns media-query shortcuts needed! 17:35:39 * astearns s/shortcuts/shorthands/ 17:35:49 TabAtkins: they're all reasonably linked, sure. Concerned we have large set of prefers options and authors need 6 MQs to target when there's a potential most people can be well served by broader MQs. Let the specific ones exist, but I don't want 10 prefers queries that subtilly interact in ways that are confusing. 17:36:11 TabAtkins: Worried if we don't guard against it. Has taken a while, but it's because people talk slowly. WE can move quickly if we want 17:36:18 ack aja 17:36:18 * Zakim sees fantasai on the speaker queue 17:36:26 might want to consider a way to SET prefers-contrast in user stylesheet 17:36:40 astearns: [reads IRC comment] 17:37:04 fantasai: Can't really set in user stylesheet. Can in user preferences. We're not going to introduce cycle between MQ and properties 17:37:13 astearns: And users know how to set browser preferences much more 17:37:13 ack fantasai 17:37:13 * Zakim sees no one on the speaker queue 17:37:54 zakim, close queue 17:37:54 ok, astearns, the speaker queue is closed 17:38:03 fantasai: When you have a reduced pallate which happens when you have increased or reduced constrast or forced colors you have to make changes. yOu don't have intermediary colors. You have to remove things that require drawing these colors. 17:38:48 q+ 17:38:48 * Zakim whispers to florian that the speaker queue has been closed 17:38:54 fantasai: Applies with forced-color or change in constrat. Argument for prefers-constrast triggering isn't that they want to reduce visual clutter, it's that you have less colors and need to adapt. You can't use a subtile drop shadow. You need a solid border or nothing 17:39:16 fantasai: If someone wants a reduced visual complexity category, that's broder and separate. 17:39:19 s/pallate/palette 17:39:53 * tantek when you have a reduced palate you may want to go get tested for COVID-19 17:40:02 present+ 17:40:11 Proposal: (color-reduction: forced | optional) and that is `optional` when prefers-contrast is set to more or less 17:40:18 fantasai: Regards to prefers-constrast, if we want to try without forced value at first we could. But I agree with TabAtkins it means we can't teach it when forced-colors is on and you can loop it into same MQ. Authors won't get benefit of trigger on both. Forward compat issue won't be that huge b/c most people will fall under prefers-constrast. 17:40:37 fantasai: The people that do fall in will have a problem or won't and we can handle it later. But you don't get author benefit to teaching the grouping 17:40:59 astearns: I'd like to close the discssion for this meeting. TabAtkins if you want to continue the idea can you open a new issue on GH? 17:41:01 TabAtkins: Sure 17:41:08 Topic: [css-images-3] image-rendering:pixelated should not force "nearest neighbor" (or similar) when the scale factor is far from an integer (e.g. 150%) 17:41:09 * github-bot Successfully commented on https://github.com/w3c/csswg-drafts/issues/5433 and removed the "Agenda+" label 17:41:17 * jcraig thanks for your time discussing this everyone 17:41:18 zakim, open queue 17:41:18 ok, astearns, the speaker queue is open 17:41:18 github: https://github.com/w3c/csswg-drafts/issues/5837 17:41:18 * github-bot OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/5837 ([css-images-3] image-rendering:pixelated should not force "nearest neighbor" (or similar) when the scale factor is far from an integer (e.g. 150%)). 17:41:33 * astearns jcraig thanks for joining today 17:42:00 TabAtkins: image rendering prop controls how browses render when scalling. Smooth or pixelated. pixelated uses nearest neighbor. Great so long as scaling up by int multiple of size. 2.5 times as big it's terrible 17:42:23 TabAtkins: You don't get consistent line weight. Something could be 2 or 3 px depending on precise details. 17:42:47 TabAtkins: At least 2 people in this issue brought up the problem. Want to remain pixel-ness but don't want it to look bad. Minor smoothing okay. 17:42:55 * fantasai q+ 17:42:55 * Zakim sees fantasai on the speaker queue 17:43:08 TabAtkins: Prop is a value that does nearest neigbor scaling and use smooth scaling to close gap. 17:43:32 * astearns pixelated-remastered 17:43:36 Proposal makes sense to me. 17:43:39 TabAtkins: Use cases seemed reasonable. Canvas-based using pixel art and you don't want jaggies but you don't want to force canvas. You want to scale as you can 17:43:42 * fantasai did we conclude on the prefers-contrast: forced discussion? Didn't ppl want to ship something? 17:43:44 q+ 17:43:44 * Zakim sees fantasai, smfr on the speaker queue 17:43:50 TabAtkins: Reasonable to me. Happy to add if reasonable to others 17:44:10 fantasai: Overall makes sense. I think we should allow overshoot and scale down. If you're 2.8px might make sense 17:44:13 * astearns fantasai yes, we resolved to remove the forced value 17:44:21 * fantasai ok 17:44:25 ack smfr 17:44:25 * Zakim sees fantasai on the speaker queue 17:44:27 TabAtkins: Right. Should test, but we should scale to nearest multiple and then go up or down smooth 17:44:35 q+ 17:44:35 * Zakim sees fantasai, vmpstr on the speaker queue 17:44:36 smfr: Does image-render pixelated apply to canvas 17:44:38 * florian we concluded to remove the value, and that for now, we don't remove the whole feature, but tab can open an issue to further argue that we should 17:44:42 TabAtkins: It's supposed to. It's an image source 17:44:49 q+ 17:44:49 * Zakim sees fantasai, vmpstr, dholbert on the speaker queue 17:44:51 smfr: With houdini? That's only way to get it in 17:45:13 TabAtkins: canvas element is an image element. It's a replaced element with a raster display of content. Intended to be effected by image rendering 17:45:45 smfr: For a UA to impl it means painting image would be 2 step. pixelated and then nearest neighbor to desitnation. Has cost. Fine feature request, but additional cost 17:45:49 ack fantasai 17:45:49 * Zakim sees vmpstr, dholbert on the speaker queue 17:46:02 TabAtkins: I think you're right. Obj or a note about don't use too much 17:46:09 ack vmpstr 17:46:09 * Zakim sees dholbert on the speaker queue 17:46:13 smfr: Note in spec about perf is good 17:46:22 vmpstr: Suggesting to mandate an algo or allow a different? 17:46:48 TabAtkins: Pixelated madates nearest neigbor. This mandates to nearest int and use whatever smoothing 17:46:52 ack dholbert 17:46:52 * Zakim sees no one on the speaker queue 17:46:54 vmpstr: Yeah. This would add cost 17:47:07 generally people don't use pixelated unless they really want it, it's not the default 17:47:17 dholbert: I think we have this behavior in spec for scale of less than 1. You do default image scaling. nice to harmonize. 17:47:29 dholbert: Also, not clear. Is this prop for new value or change to pixelated 17:47:49 TabAtkins: Asked in thread. Authors thought different value. I proposed merge into default. I could go either 17:48:09 q+ 17:48:09 * Zakim sees jfkthame on the speaker queue 17:48:17 dholbert: If we did keep pure nearest neighbor, might be nice to remove <1 special case and have pixelated scaling separate. You can see as you spec 17:48:19 ack jfkthame 17:48:19 * Zakim sees no one on the speaker queue 17:48:56 jfkthame: My understanding of last comment in issue is the suggestion is this should be what pixelated does and true nearest neighbor would be new. That makes sense to me. This would be true pixelated and acutal nearest neighbor would be special 17:48:56 +1 jfkthame 17:49:15 astearns: Then you make current use of pixelated take the harder path 17:49:28 jfkthame: True, but I think it's the better result. Arguable 17:49:39 fantasai: I imagine it's not that common unless you want that effect 17:49:50 TabAtkins: You want for int. If you use it inbetween is variable. 17:50:09 TabAtkins: dholbert where are you seeing scale down? I'm looking at spec and there is no such difference between up and down 17:50:14 Comment jfkthame was referring to: “Personally, I agree with baking this into pixelated. Yes, pixelated should mean pixelated, but I don't think nearest neighbor interpolation with 150% scaling ratio looks pixelated: Squares that vary in size from 1*1 to 2*2 do not look like pixels. I think it would be better to add a new keyword nearest-neighbor, which means nearest neighbor.” 17:50:21 https://github.com/w3c/csswg-drafts/issues/5837#issuecomment-776951044 17:50:29 * smfr image-rendering does not appear to affect canvas 17:50:33 * dael thanks fantasai 17:50:51 dholbert: I haven't looked at spec for a couple years. It was there a few years ago. If it's been removed, that's great 17:50:58 TabAtkins: I'll research. not in current ED 17:51:04 astearns: Do you want resolution? 17:51:14 TabAtkins: Add this with caveats discussed in chat 17:51:24 fantasai: New value or adding into pixelated and nearest is new 17:51:43 TabAtkins: Also agree with jfkthame. If vmpstr and smfr don't think it would be problematic I would like to do that 17:51:58 astearns: Smoothing only nec for non-int values? 17:51:59 TabAtkins: Yea 17:52:00 s/is new/as new? I personally agree with jfkthame / 17:52:29 astearns: Prop: Bake the smoothing into non-int changes in current pixelated value. add a new value for nearest neighbor jaggedness 17:52:34 myles: Flip the names? 17:53:12 fantasai: I don't think so. Last commentor pointed out having a variety of squares doesn't look pixelated. You want each pixel same size. I think naming is better where pixelated is same size 17:53:18 astearns: Is that okay myles? 17:53:21 myles: No comment 17:53:31 s/squares/squares and rectangles representing source pixels/ 17:53:33 astearns: Objections? 17:53:48 RESOLVED: Bake the smoothing into non-int changes in current pixelated value. Add a new value for nearest neighbor jaggedness 17:53:57 Topic: [css-align-3] What is supposed to happen to abspos in an end-aligned scroll container? 17:53:57 * github-bot Successfully commented on https://github.com/w3c/csswg-drafts/issues/5837 and removed the "Agenda+" label 17:54:20 Topic: ?? 17:54:29 fantasai: Scrollsnap republish CR? 17:54:30 * dholbert TabAtkins see https://bugzilla.mozilla.org/show_bug.cgi?id=856337#c0 which references the behavior I described - ' nearest-neighbor upscaling and "auto" downscaling.' 17:54:33 https://lists.w3.org/Archives/Public/www-style/2021Feb/0013.html 17:54:40 fantasai: Some issues. Here's a status summary ^ 17:54:55 fantasai: If someone wants to insist on a test existing and will volunteer to write, happy to hold off. 17:55:02 * dholbert TabAtkins that bug-comment is from 8 years ago, so it's entirely possible the spec evolved/simplified since then :) 17:55:05 florian: CR-snapshot? 17:55:11 fantasai: Yes. Long time so should do one 17:55:38 astearns: Objections to republish CR-snapshot of scrollsnap? 17:55:40 * TabAtkins yes, it must have appeared and disappeared between the 2012 and 2019 /TR publications ^_^ 17:55:48 RESOLVED: republish CR-snapshot of scrollsnap 17:55:57 Topic: ???? 17:56:02 astearns: not hearing suggestions 17:56:04 https://github.com/w3c/csswg-drafts/issues/5971 17:56:04 * github-bot Because I don't want to spam github issues unnecessarily, I won't comment in that github issue unless you write "Github: | none" (or "Github issue: ..."/"Github topic: ..."). 17:56:23 Topic: [css-ruby] alternating sides for ruby-position 17:56:29 github: https://github.com/w3c/csswg-drafts/issues/5971 17:56:29 * github-bot OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/5971 ([css-ruby] alternating sides for ruby-position). 17:56:38 florian: 3 values, focus on over and under. Default is over 17:56:53 florian: If you have 1 layer it goes over. If 2 they both over and stack.If want one over one under need selector 17:57:16 florian: People sometimes want to stack, but majority is when you have 2 layers (3 almost not done) people want one on each side 17:57:28 florian: Separate selectors is annoying, esp given markup has anon boxes 17:57:49 florian: Prop is default value is auto or alternate which is over iwth 1, over and then under with 2, and continue alternating with more 17:58:04 myles: Didn't realize prop changing initial value. I think we have ruby in books which is scary. 17:58:11 * dholbert TabAtkins looks like https://lists.w3.org/Archives/Public/www-style/2014Sep/0384.html had the relevant resolution, "Allow nearest neighbor in both directions but allow browsers to do prettier in the down directions." I guess it was optional 17:58:15 myles: Separating changing initial value from the new propery is good 17:58:21 fantasai: Don't think you support multi-level 17:58:34 myles: Doesn't effect nested. Multi level ruby in same lement only? 17:58:36 fantasai: Yes. 17:58:56 myles: Then, now that I understand, if you tried to give this to use we would have longer ruby text on top 17:59:10 fantasai: Not sure, haven't loaded it. It's a separate issue from if you display on top or bottom 17:59:15 myles: General compat concern 17:59:31 fantasai: Yeah. If you don't support multi-level in same ruby structure 17:59:39 florian: Problem is same no matter if value 17:59:59 myles: If we impl multi level without this we would turn 1 level to 2. With this we would turn it into 1 level about and one below 18:00:06 s/about/above 18:00:14 florian: If I remember your current impl, yes 18:00:24 astearns: myles resolve or investigate? 18:00:33 myles: Okay resolve. If things explose come back 18:00:45 astearns: Add an alternate value which is the initial value 18:00:50 RESOLVED: Add an alternate value which is the initial value 18:00:55 topic: end 18:00:56 * github-bot Successfully commented on https://github.com/w3c/csswg-drafts/issues/5971 and removed the "Agenda+" label 18:00:59 \^_^/ 18:01:08 zakim, end meeting 18:01:08 As of this point the attendees have been dael, plinss, cbiesinger, vmpstr, dholbert, miriam, sanketj, Morgan, rachelandrew, dlibby, alisonmaher, fantasai, smfr, jfkthame, emilio, 18:01:12 ... fremy, faceless, chrishtr, GameMaker, myles, leaverou 18:01:12 RRSAgent, please draft minutes v2 18:01:12 I have made the request to generate https://www.w3.org/2021/02/24-css-minutes.html Zakim 18:01:14 I am happy to have been of service, astearns; please remember to excuse RRSAgent. Goodbye 18:01:16 * fantasai dael, did the tuesday minutes get through or should I try sending from gmail? 18:01:59 * dael fantasai sorry, yes they did. I just haven't had time to get them posted. 18:02:05 * fantasai np :) 18:02:17 * fantasai got a new email server, was hoping it would fix the problem so hopefully, hopefully it did 18:02:30 * dael here's hoping! 18:02:55 * fantasai will have another testcase with Thursday ;) 18:06:39 * cbiesinger fantasai / dael -- do you know if the f2f minutes will get posted at some point? 18:10:07 TabAtkins, looks like https://github.com/w3c/csswg-drafts/commit/c49faa3c0827aa2464e62a4215ac6a868e821411 is where the special downscaling behavior was removed for pixelated 18:11:35 TabAtkins, (I'm curious what the backstory was there - do you know where that change came from?) 18:15:44 TabAtkins, it looks like that commit was the day *before* the csswg resolution about downscaling allowing better behavior. I think that downscaling special-case just never made it into the spec, perhaps? 18:16:57 i.e. we went from "downscaling must use 'auto'", to "downscaling and upscaling must both use nearest-neighbor", to a CSSWG resolution that downscaling is *allowed* to do something better (but I don't think that last change made it into the spec) 18:17:22 (and that last resolution was in https://lists.w3.org/Archives/Public/www-style/2014Sep/0384.html , linked in an earlier /me above) 18:33:57 * dael cbiesinger, fantasai and I were just talking about it. I'm hoping to get the Tuesday minutes up today or tomorrow. fantasai has the Thursday minutes to proofread and I'm not sure what her timeline is. 18:38:36 * cbiesinger ah that's what you meant. thanks! 18:39:06 * dael no problem! 20:27:13 * fantasai RRSAgent, make minutes 20:27:13 I have made the request to generate https://www.w3.org/2021/02/24-css-minutes.html fantasai 20:27:36 s/Topic: ??/Topic: CSS Scroll Snap/ 20:28:12 * fantasai RRSAgent, make minutes 20:28:12 I have made the request to generate https://www.w3.org/2021/02/24-css-minutes.html fantasai 20:29:19 cbiesinger: planning to do it today 20:34:07 * fantasai files transition request for css-scroll-snap 21:01:41 fantasai: great thanks 21:24:45 cbiesinger: and done, just sent them over to Dael :) 21:31:41 perfect :) 22:43:13 dholbert: Yeah, I don't think the edit ever made it in. I'm doing it now. ^_^