- From: Dael Jackson <daelcss@gmail.com>
- Date: Sun, 16 Aug 2020 07:54:47 -0400
- To: www-style@w3.org
========================================= These are the official CSSWG minutes. Unless you're correcting the minutes, Please respond by starting a new thread with an appropriate subject line. ========================================= Media Queries ------------- - Reviewed issue wrt various interpretations of high contrast preferences, particularly as summarized in this comment, and discussed pros and cons of various approaches. https://github.com/w3c/csswg-drafts/issues/2943#issuecomment-665453076 - Since some of the people interested weren't able to attend the call discussion will continue on github until there's a telecon where everyone can discuss. - RESOLVED: No change: spec won't define contrast thresholds for automatically calculating prefers-contrast from forced colors palette (Issue #5224: prefers-contrast: infer contrast preference from forced colors) - RESOLVED: prefers-reduced-data remains binary (Issue #4833: Should "prefers-reduced-data" be binary or not) - RESOLVED: remove light-level (Issue #5359: redundant media feature) CSS 2 ----- - RESOLVED: Sections entirely replaced by RECs are marked with obsoletion notices, recommending the REC ===== FULL MINUTES BELOW ====== Agenda: https://wiki.csswg.org/planning/virtual-summer-2020#thursday Scribe: fantasai Media Queries ============= `prefers-contrast: high` media feature vs macOS/iOS increased contrast ---------------------------------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/2943#issuecomment-665453076 florian: Whole issue is very long, so added a comment yesterday summarizing the state of discussion florian: We have a prefers-contrast media query florian: as specced today, prefers-contrast: no-preference | low | high | forced florian: We also have a forced-colors MQ florian: in order to make it possible to do a very common thing, we have included forced keyword into prefers-contrast as well florian: regardless of whether contrast preference for low or high or something else, generally desired to reduce visual complexity florian: so having low/high/forced on the same media feature makes possible to do @media (prefers-contrast) florian: That's why forced is in there florian: but this issue is not about forced, it's about the rest of the media features florian: We have low and high florian: and high is the tricky bit florian: MacOS has "increased contrast" which doesn't do white vs black etc. florian: it increase contrast, but not extremely so florian: People from Apple believe 'high' describes extreme contrast, and want a different keyword for that Rossen: What is increasing contrast? florian: It's a content-aware thing that will use more contrasty colors and adds borders florian: but doesn't do such extreme transformation of colors as forced-colors mode florian: screenshot at https://github.com/w3c/csswg-drafts/issues/2943#issuecomment-665387408 florian: With that said, current spec actually does not limit 'high' to extreme version florian: the way it is described would include the way Apple / Gmail do high contrast mode florian: But maybe we need to distinguish between higher and extreme contrast florian: Note that we are not discussing forced mode florian: but a *non-forced* preference for higher contrast florian: and distinguishing between "somewhat high" and "extremely high" contrast preferences florian: One way minimalistic way to make it more palatable to Apple is to rename 'high' to 'increase' florian: So maybe matching the name a bit better would help make clear that spec categorizes both as the same keyword florian: but maybe there's a need to distinguish between the two florian: However florian: In many cases you don't want to distinguish florian: author wants to create one mode for higher-contrast preferences florian: not two florian: and writing (prefers-contrast: high) and (prefers-contrast: increase) is unwieldy <fantasai> which, incidentally, makes it less likely that the author will get it right myles: We'd like for James Craig to be present for discussion, and he's on vacation this week astearns: Would it be OK to discuss a bit and not resolve? astearns: OK, we'll defer resolving, but let's see how far we get gregwhitworth: I actually just turned this on to play with it gregwhitworth: Terminology aside, the end goal is still trying to achieve the same thing gregwhitworth: They obviously don't go to the same extreme lengths as high-contrast gregwhitworth: but to the author of a website, the goal for the end-user is the same gregwhitworth: I want to see more of the content, I want it to stand out gregwhitworth: Although e.g. Yahoo doesn't override due to that, if I was an author, it would show me user wants increased or high contrast gregwhitworth: I don't think it's a different setting, just different approach gregwhitworth: you're trying to segment content to improve legibility florian: I agree with gregwhitworth florian: I'm not convinced that we should have a way to distinguish two levels of high contrast florian: and even if we do, we shouldn't require authors to always distinguish florian: One way to solve this is to keep the spec as-is, as per gregwhitworth's argument, they are different implementations of the same goal florian: An alternative, calling 3[B], is to have two levels of high contrast, mapped to two keywords florian: but inspired by how we dealt with color-gamut, if you match the "extreme high" value, you also match "somewhat high" value florian: Another possibility is to split into two MQ, one for prefers-high-contrast and one for prefers-low-contrast florian: can ignore levels by using as boolean florian: But it's more syntax, more typing florian: and lose the "has contrast preferences" syntax of (prefers-contrast) florian: So that's a summary of the issue and where we're at fantasai: I agree that we should choose a syntax that makes it easy to not distinguish between levels of high so that authors can do that easily and correctly fantasai: 3B is my favorite fantasai: also, increase vs increased is hard to remember. How about "more" and "less" melanierichards: I think whichever syntax we go with, with keyword-based approach, makes it unclear from MQ how authors should respond to the query melanierichards: what is low enough? what is high enough? melanierichards: Will have authors respond to preference in variable ways melanierichards: e.g. prefers-reduced-motion, authors interpret as turning off all motion melanierichards: so can have very blunt responses <gregwhitworth> valid point melanierichards melanierichards: Would be nice to see precise contrast ratios in the syntax florian: Do you feel users might have a common preference for a contrast ratio of 8 vs 12? melanierichards: That level can come from ?? melanierichards: Could look like WCAG increased contrast levels perhaps melanierichards: but difference between someone who needs a little bit of a boost vs extremely high contrast <AmeliaBR> I don't think exact ratios are necessarily helpful, but `increased` vs `maximum` is a reasonable description of the MacOS setting vs the default WHCM themes astearns: Ratios would allow authors to do math melanierichards: Also allows programmatic styling florian: That would be a different thing florian: This is a query, you get a yes or no florian: if we want the number as a thing to do math on, should be an environment variable astearns: I was meaning comparisons. you can decide at what level to respond florian: Hooking into WCAG is tricky also florian: because levels of contrast are different depending on the size of the text florian: MQ is too blunt to explore that kind of thing florian: and we don't want to expose users to a bunch of sliders florian: for body vs heading text etc. florian: doesn't seem practical florian: but if you want to effectively use as numbers, ? <gregwhitworth> florian: you can specify the keyword to be that of a contrast ratio that is above x:y <gregwhitworth> florian: and then potentially have some concrete tests of something that allow for an OS to map it accordingly. EG: What I see from MacOS it doesn't really impact text especially within the UA itself and as such could possibly not meet a contrast ratio of text but may for borders, etc <gregwhitworth> florian: worth exploring Rossen: Whole topic of contrast and effective use through intended and various purpose Rossen: is a long and deep one Rossen: goes far beyond specifying a few colors in response to an MQ Rossen: In general, we should aim to provide capabilities to authors to continue to improve contrast Rossen: I also sort of sympathize with notion of involving at the very least Alice and James <hober> maybe we can do this on the next APAC-timed CSS telecon? <astearns> which is next week Rossen: but again, we may or may not end up with something as simple as higher vs lower Rossen: Working with our own researches, contrast can be achieved in different ways to improve legibility Rossen: don't necessarily need contrast ratios in some bounds Rossen: can use various properties of color space to do that Rossen: I think it's a great discussion, don't want to resolve on anything at this point florian: One more thing, I'd like to add florian: Value in keeping it simple florian: in part to make it easy for authors to understand what is going on florian: and also a11y features which are not purely about a11y tend to get better usage and better response from authors florian: Preference for light on dark and dark on light flipping automatically on time of day, e.g. florian: possible that UA could hook higher contrast mode when outside in bright light, lower in dark room or something like that florian: There is nuance, but also value in simplicity astearns: Tess suggested taking up on APAC call, happens to be next week, so hopefully Alice and James can join us prefers-contrast: infer contrast preference from forced colors -------------------------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/5224 florian: When you have forced colors florian: When the user has said "I want this foreground color and that background color" florian: There is guidance that if the UA knows if that combination is high contrast, should match (prefers-contrast: high) florian: and if combo is low contrast, should match (prefers-contrast: low) florian: Question is what's the thresholds florian: We have a known set of colors here from the user, so we can calculate the ratio florian: maybe we want interop among browsers? florian: One possibility is to hook into WCAG levels florian: but WCAG is AAA is about high contrast enough to be readable, not very high contrast florian: and WCAG AA is reasonably high contrast florian: If we want a number, I suspect these aren't the ones we want fantasai: I propose leaving this up to the UA, to allow experimentation and let browsers figure out the good answers fantasai: Maybe revisit a few years in the future. Rossen: I say, yes, definitely the browser should do this Rossen: wrt what are the ratios Rossen: there are some guidelines, e.g. Microsoft has some guidelines for contrast ratios in all of our products Rossen: Fairly in line with WCAG Rossen: However we decide on the precise values, I don't believe we're the group for deciding that Rossen: Not sure it's the browsers themselves, but some combination of a11y WG or WCAG as well as some of the companies who own a11y guidelines Rossen: Together should be able to figure it out Rossen: I also agree, let's not have specific numbers fantasai: Propose closing no change, we will not define here. Maybe in 3-5 years we can revisit. Rossen: Maybe referencing other things like WCAG florian: I don't think WCAG is appropriate reference, it's guideline for general contrast, not high contrast RESOLVED: no change: spec won't define contrast thresholds for automatically calculating prefers-contrast from forced colors Should "prefers-reduced-data" be binary or not ---------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/4833#issuecomment-663555808 argyle: This is about preference for reducing data argyle: Can be expressed in headers argyle: and this feature exposes as MQ argyle: .. argyle: Can see what Chrome plans to reduce argyle: Goal is to send less bits over the wire to users that have that set florian: Currently it's a binary preference florian: Earlier we wondered if it needs to have multiple levels florian: State today, the JS API being proposed along with this, there are only two levels florian: So should only have two levels for now florian: This feature can be used as boolean, so if we want to add more values later can florian: but current proposal is to close as no change, leave as a binary argyle: OSes don't have degrees, just binary switch argyle: can expand later if needed smfr: More levels is more fingerprinting surface smfr: Apple already have concerns about this smfr: allows targeting people on low-bandwidth, which is often poorer community e.g. florian: There is a privacy fingerprinting warning issue in the spec about this, and it is visible in the spec astearns: So consensus seems to be keep binary for now RESOLVED: prefers-reduced-data remains binary redundant media feature ----------------------- github: https://github.com/w3c/csswg-drafts/issues/5359 florian: Talked about contrast a lot already, fact that we have prefers-contrast is established florian: and forced-colors is established as well florian: and also have prefers-color-scheme to pick between light and dark florian: so this has settled down a lot compared to earlier florian: What we did have early on was a light-level feature with 'washed | dim | normal' florian: to help with LCD screen outdoors or dark room, allow switching color scheme and/or contrast to improve readability florian: outdoors on e-ink doesn't end up washed, for example florian: That as intent of MQ florian: But I think we don't need this anymore florian: UA could respond to this via existing prefers-contrast / prefers-color-scheme florian: so I don't think we need this thing anymore chris: I'm of two minds for this. chris: On one hand, that's not the only uses of this feature chris: but there's a light levels API that gives you info on lux / etc. chris: which allows adjusting the overall system gamma chris: so I think this is not useful, and we should let those use cases be solved by the API TabAtkins: MQ in general aren't useful for fine gradation, they're broad categories TabAtkins: That said, in agreement with Florian TabAtkins: If we specify that UA should provide ability to map light levels to contrast levels TabAtkins: happy to assume that florian: I would like to remove this MQ and add some notes to other MQ "don't forget, you can respond to these environmental situations using this MQ" <fantasai> +1 RESOLVED: remove light-level <br duration=10min> CSS 2 ===== scribe: emilio CSS 2 Editing ------------- fantasai: CSS2 is published a while ago, and we try to maintain it because there are sections of it which haven't been replaced fantasai: There are erratas that aren't in CR queue fantasai: At one point we resolved that we'd annotate every css2 section that has been superseded with a note pointing to where the work is happening fantasai: Open issue is whether to remove the css2 section and leave only the note. fantasai: I think we should not remove that text. Some people disagree chris: Why wouldn't you? fantasai: That'd be creating a different spec effectively fantasai: Removing the spec and putting references to something else chris: I get it but nobody is using css2 as an implementation target chris: and if we have a section replaced by a recommendation chris: It seems bad maintaining also another spec text that people can link to and not realize that they shouldn't even read that chris: For something like color where color3 is solidly there as a replacement I think there's a downside to leave the existing text chris: Those specs still exist if people want to know what was there fantasai: I want to clarify that the agreement wasn't to put a note at the top of the spec, but a note in every section / subsection fantasai: so you're not going to miss it florian: I agree with chris, even if the two levels agree with each other. If there are normative differences, spending the effort of making L2 agree with following levels, if the following level is at L3 florian: For the color example, what is the point of figuring out what the changes to css2 are needed to make it agree with color3? gsnedders: I have no intention of spending my time doing that kind of thing florian: line-height and inline-size calculations are a different case florian: Level 2 has wrong stuff florian: Level 3 has fixes and also new features that aren't yet done florian: So I think maintaining l2 with those fixes is useful astearns: I think it'd be useful to keep the conversation about the sections that are fully replaced astearns: I propose hiding the text from the spec with a `<details>`, along with a note, so hopefully it's hidden and so on gsnedders: Why's it useful? astearns: Other than links, I don't think it's particularly useful astearns: it's a compromise solution fremy: I was going to mention, removing text from the spec may also break other anchors in the spec gsnedders: Hopefully now with css2 in bikeshed we can get cross-spec refs and have correct anchors faceless2: We built an implementation from scratch over the last few years, and found css2.1 extremely useful faceless2: It's lacking some changes and some detail faceless2: but it's a great overview faceless2: Different modules are useful for maintenance but it's useful as a reference when you're coding faceless2: It'd be a shame to lose that faceless2: It'd be great to have notes like "this has been largely revised" faceless2: Seems easier than tweaking the spec TabAtkins: Knowing it's wrong, it scares me that people learn from css2 faceless2: By all means do fix the errors :) fantasai: I don't think we've added the notes we agreed to add gsnedders: We have conflicting resolutions gsnedders: Problem is stuff like syntax where there have been substantive changes to l2 behavior and retrofitting them is a lot of work gsnedders: wrt it being a learning resource, I agree with TabAtkins but I think we're failing to produce the right onboarding stuff to help people get their feet on the ground gsnedders: it doesn't have to be detailed, but just a general overview TabAtkins: Wish I had the time to get an authoring overview fantasai: That was what the snapshot was supposed to do, but hasn't <fremy> fwiw, I agree that maintaining the text seems hurtful <fremy> this is different from keeping the text, in my opinion chris: So I'd like to avoid the situation by which by being css2 editor you become editor of every other spec fantasai: No, should be responsibility of other specs to file issues against CSS2 if changes are necessary. fantasai: But I don't think we should chop text out of css2 fantasai: It's a single spec. By all means annotate it, but I think taking pieces out of it is an unhelpful violation of the integrity of css2 florian: I think what we don't want is to publish a new version of CSS2 with normative text that is known to be wrong and for which there's a REC replacement florian: but it's also not worth putting too much work on the CSS2 spec editor florian: so making it informative either in a <details> or as informative, pointing to the right place... florian: seems better than either publishing things that are wrong or blocking on edits that nobody wants to do <tantek> would be ok with marking whole sections OBSOLETE instead of removing them <tantek> eventually all of CSS2 will be marked OBSOLETE and we can obsolete the entire REC <tantek> this preserves IP commitments fantasai: I'd mention that removing text may have patent implications fantasai: I think we can put references to new stuff fantasai: but I don't think removing text is good. It's done, if there are bits we have replaced we can point to them, etc fantasai: I'd object to removing the text TabAtkins: We can move it to somewhere where it where it doesn't seem text (?) <AmeliaBR> Strongly in favour of marking individual sections as replaced, with links to new. Strongly against republishing CSS 2.1 with large chunks removed. Not sure about CSS 2.2 gsnedders: Is fantasai's suggestion that in CSS2 we change the text so that implementors must either implement CSS2.1 as it went to REC in 2011 or implement the text in L3? fantasai: I think that'd be acceptable <tantek> that's an artificial dichotomy, we really should mark the CSS2 text obsolete at a minimum <tantek> we usually refined the feature for interop gsnedders: So if we want L3 to be a superset of L2 we need to allow the CSS2 behavior in CSS3 fantasai: In terms of features L3 is a superset of CSS2, but in a given feature behavior is usually a subset because we refine the feature fantasai: the goal is that a CSS3 implementation would be conformant to CSS2, but not that a CSS2 implementation is conformant to L3 <tantek> I kinda disagree saying may impl CSS2 where we have a CSS3 REC gsnedders: What do we want to do about syntax? we first said that L2 would have its own notion of syntax fantasai: I think we should just apply what you just said, we recommend implementing css3-syntax, instead of L2 gsnedders: So you must implement one of these two, and you should implement L3? florian: Similar concern for line-height. We should fix L2 because it's just wrong fantasai: Agreed there's a set of things we should fix gsnedders: So we should make syntax informative because we don't have a REC <JonathanNeal> Syntactically, I was under the impression that CSS3 does have breaking changes (if that relates to CSS v2 being conformant to v3). Specifically, that an identifier can start with two-dashes. https://www.w3.org/TR/CSS22/syndata.html#tokenization <gsnedders> JonathanNeal: yes, L3 Syntax is incompatible L2 tantek: I get fantasai's IP concerns, also links tantak: but the situation where we have an entire CSS3 REC tantak: We should mark the CSS2 version as obsolete tantak: We leave the text there, but you should go implement this REC tantak: If there are bugs to fix or the replacement is not a REC that's a different situation tantak: but let's make obsolete the sections replaced by a REC fantasai: Marking things obsolete doesn't mark them non-normative fantasai: you can mark things obsolete but they still have to be allowed, if you forbid something then implementing it isn't covered under the patent policy tantek: obsolete is "we're specifying this normatively but you shouldn't implement this", unlike deprecated fantasai: Right, but you still need to allow it tantek: By marking it obsolete you don't have to say you MAY florian: But you can't say you MUST NOT <fantasai> the patent policy only covers things which are normative parts of the text <fantasai> they can be optional <fantasai> but they can't be MUST NOT <fantasai> obsolete stuff falls under a MAY, actually <fantasai> deprecated stuff is MUST implement (but don't use) <fantasai> obsolete stuff is MAY implement tantek: So proposal from me is mark obsolete and point to replacement <tantek> links to old identifiers etc TabAtkins: We still haven't answered on who's benefiting about leaving the old text? faceless2: [points at himself] :) tantek: We would break links TabAtkins: Lots of ways to not break them florian: We can't remove text TabAtkins: You can move it to a different section so that people don't accidentally implement stuff from it <tantek> I'm happy to see what proposals TabAtkins has for maintaining links etc. fantasai: There's going to be a very noticeable warning on every section and subsection, nobody is going to get confused astearns: Also lower editor effort TabAtkins: It's a one time effort TabAtkins: I am not a lawyer but adding a text that says don't implement it ... florian: Can't do that fantasai: We can recommend implementing this other thing, but can't ask not to implement <tantek> obsoleting sections is a better path to obsoleting the whole spec tantek: From the point of view of the final spec, it should be an obsolete recommendation, marking sections obsolete seems less churn to get to the final state [tantek describes final state as being a complete document which is marked as obsolete, not reduced to a ToC] <fantasai> +1 to Tantek's point <tantek> Goal is to obsolete all of CSS2.1 as a whole gsnedders: Do we want long term a definition of level 2? We have no current normative definition of L1, which is defined in the snapshot which is a note thus informative <tantek> ^ that's a separate topic gsnedders: Gonna have a discussion about the wording, to only allow two behaviors and not let anything happen fantasai: We need wording sufficiently discouraging florian: Something simple like "This section is obsolete, and has been superseded by <place>" <tantek> we don't need to say anything extra about "may" or "allowed" about the thing that is obsolete <tantek> please re-use REC-level obsoletion text, don't invent new obsoletion text tantek: Let's keep it short, let's reuse ^^ tantek: We can wordsmith the specific recommendation, but let's reuse the obsoletion text * fantasai reserves judgment on the exact text pending seeing the exact text, as it might not be appropriate for per-section notes... * gsnedders is still a bit unhappy with this RESOLVED: Sections entirely replaced by RECs are marked with obsoletion notices, recommending the REC
Received on Sunday, 16 August 2020 11:55:39 UTC