- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 4 Jun 2020 19:15:22 -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. ========================================= Publications of WDs recently ---------------------------- - The working group will update the wording for publishing a WD without a resolution from requiring exact wording to be approved to having appropriate review for the wording. CSS Color --------- - RESOLVED: Use vs in color-contrast function (Issue #5087: color-contrast needs another comma) CSS Color Adjust ---------------- - RESOLVED: Remove the special case of background images on input elements wrt forced colors (Issue #4917: Why special-casing background-image for inputs?) CSS Inline ---------- - RESOLVED: Publish css-inline - This publication will include the draft ideas for line-box-contain (Issue #3199) though the issue will stay open until all details are agreed upon. - RESOLVED: Rename initial-letters to initial-letter (Issue #862: Should `initial-letter` be plural?) - RESOLVED: Atomic inline initial letter size as regular atomic inlines, except for auto sizes being calculated using the initial letter algorithm (Issue #3231: Sizing atomic inlines as initial letters) - RESOLVED: shape-margin and shape-outside apply to initial letter wrapped inline boxes, modifying or replacing the shape of the glyph (Issue #5117: shape-margin on initial-letters-wrap: first) Media Queries ------------- - RESOLVED: Add definitions for paged and continuous media to MQ4 (Issue #5091: Define Media Groups: continuous vs paged, etc.) - RESOLVED: No change to @media width/height (Issue #4713: CSS media query width and window.innerWidth may not be equal) ===== FULL MINUTES BELOW ====== Agenda: https://lists.w3.org/Archives/Public/www-style/2020Jun/0006.html Present: Rossen Atanassov Tab Atkins David Baron Amelia Bellamy-Royds Mike Bremford Elika Etemad Megan Gardner Chris Harrelson Daniel Holbert Dean Jackson Brian Kardell Chris Lilley Peter Linss Stanton Marcum Myles Maxfield Cameron McCormack Devin Rousso Jen Simmons Alan Stearns Miriam Suzanne Lea Verou Regrets: Dave Cramer Simon Fraser Dael Jackson Adam Jolicoeur Cassondra Roberts Scribe: heycam Publications of WDs recently ---------------------------- Rossen: I want to draw attention to text about our WD process, how we go about publishing drafts Rossen: as well as recognize the fact that these three specs were already published, don't have specific resolutions on publishing these WDs Rossen: at least not all of them Rossen: but we do have resolutions for all of the edits Rossen: These are css-contain-2, css-overflow-3, and mediaqueries-5 Rossen: All republished as WDs Rossen: Most of the edits in those are editorial Rossen: astearns and I looked over the publications and they looked good for us Rossen: I wanted to bring this up for the awareness of the WG <fantasai> https://wiki.csswg.org/spec/publish <fantasai> "For WD if there are only non-controversial editorial changes and/or substantive changes whose exact wording was approved by the WG, there is no requirement to get an explicit WG resolution. The decision URL is this wiki page, and you can publish using Echidna." Rossen: In the past we have made a lot of effort to lighten up the process of WD publication Rossen: and make it easier for editors to push WD updates Rossen: There is a part of our current documentation that seems a bit over-constrained Rossen: and that is the part which reads "substantive changes whose exact wording was approved by the WG" Rossen: This is a little too strong Rossen: We have to go and rubber stamp all of the edits Rossen: I don't know that we need "exact wording" in this sentence Rossen: and I propose we drop that and leave it as substantive changes are approved by the WG fantasai: I'm OK with this a long as the wording is approved by one other person than the person who made the edits fantasai: I think it's important to get review fantasai: so another WG member, or the person raising the issue <astearns> perhaps we could go to a PR-with-review workflow for substantive edits? <fantasai> not interested in juggling PRs Rossen: That seems to be part of the PR review. Is that enough? astearns: We don't do PRs astearns: I think it would be great if we did fantasai: We sometimes do PRs, if it's likely to need changes fantasai: but usually we push changes and ask for review astearns: I think we should change the wiki wording to remove "exact wording", and make it part of the editor's task to get appropriate review chris: I agree with what Alan said, and just edited the wiki to remove "exact wording" fantasai: I would like the exact wording to be reviewed by someone other than the person who made the edit chris: Does that mean going to PRs and reviews for every change? fantasai: No fantasai: If you're going to publish to /TR, someone should have looked at the changes fantasai: Without a regular PR process used everywhere else, leaving it up to the editor to get appropriate review fantasai: Going over exact wording in a meeting like this isn't useful fantasai: not suggesting that fantasai: just that someone else reviews it astearns: "appropriate review" fantasai: ok <dialog> positioning should be describable in CSS ================================================= github: https://github.com/w3c/csswg-drafts/issues/4645 Rossen: Is Simon, Tab or Elika able to handle this one? Rossen: or emilio if he's on the call Rossen: Not hearing anything, if nobody can take this issue, we'll push it off to next week <TabAtkins> yeah let's move on for the moment CSS Color ========= color-contrast needs another comma ---------------------------------- github: https://github.com/w3c/csswg-drafts/issues/5087 leaverou: I can take this leaverou: Right now we have the color-contrast function accepting a bg color and a list of fg colors leaverou: Supposed to choose the most contrasting color leaverou: The first is space separated, the rest are comma separated leaverou: Makes it looks like the two are grouped together leaverou: So this is a syntax issue, how do we make sure the first color stands out, and the comma separated ones are grouped together leaverou: One proposal is to use a comma, like in gradients leaverou: Another is to use a keyword like "versus" or "on" or "over" leaverou: Another is to use a slash. A problem with that is inconsistent with other CSS, without parentheses or something, the slash has a different precedence compared to backgrounds chris: One other thing is that the first element is typically a background, but doesn't have to be leaverou: Right if you reverse the colors you still get the same result florian: In terms of keywords, "against" might work to avoid indicating which is fg or bg chris: I also liked "vs" chris: That would be my first choice <TabAtkins> I'm fine with "vs" or a plain comma. <florian> "vs" works for me AmeliaBR: For keywords, another could be "from" AmeliaBR: choosing a contrasting color from the list after AmeliaBR: Syntax wise I prefer slash, but the concern about all the new color functions consistently using slash to separate the alpha value might be an issue leaverou: That's not a problem, grid-row/column uses slash like this leaverou: but if you have slashes and commas at the same level leaverou: If you have color / color+, it looks like the first two colors are grouped AmeliaBR: I don't think that's an issue or really consistent <AmeliaBR> `color-contrast(wheat / tan, sienna)` leaverou: Is there precedent for the opposite? TabAtkins: It is true that all the places we mix slash and comma, that slash is subordinate to the comma TabAtkins: Don't think that's necessarily a problem, but I'm fine with using a keyword here TabAtkins: if we explicitly want to keep slash as a weaker precedence leaverou: Also there's an option of using a function jensimmons: I hear people saying they like "vs", but I really don't jensimmons: it doesn't feel expected from the PoV of authors jensimmons: I appreciate the consistency argument. Is there another symbol we can use? <dino> (not so firm) vote for not using the / to avoid this inconsistent grouping/alternate issue, but i like / more than vs leaverou: What about a function, that definitely makes the grouping obvious AmeliaBR: Most cases that means having triple nested parentheses Rossen: What about the "from" keyword? Rossen: Sounds fairly intuitive florian: If we're going with a keyword, I like vs better leaverou: I like against and vs better than from <fantasai> +1 to leaverou argyle: [...] <chris> vs for me too <AmeliaBR> `color-contrast(var(--fg) from #002, #ffa)` `color-contrast(var(--fg) vs #002, #ffa)` myles: Sounds like there's not agreement on keywords jensimmons: I really don't like it fantasai: There's keywords in gradients leaverou: I think the ship has sailed argyle: I like keywords but against I like against, but it feels very English leaverou: To me keywords read like natural language which I think is something to strive for leaverou: keywords the precedence is still not completely clear <astearns> prefers keywords to most magic-punctuation syntax myles: I'm not sure that's something to strive for myles: I don't think it'd be a good idea for properties to be full English sentences Rossen: We also have a resolution to allow commas everywhere! myles: I don't think we do, I posted about that last week AmeliaBR: I think also, while discussing this, important to remember how this function works AmeliaBR: which I wasn't thinking of when I suggested keywords AmeliaBR: but you're picking a value from the list, contrasting it against the first value AmeliaBR: It's the list you're picking from argyle: It sounds nice when you put it that way <faceless2> I think a keyword over /, I can't get past the precedence issue. commas just seem naturally lower priority than slash Rossen: Are we more leaning towards using "against"? Rossen: If we used versus would it be abbreviated? florian: I hope so Rossen: We don't use abbreviations anywhere else? plinss: Only every unit type TabAtkins: "vs" is pretty universal dbaron: Except in the legal system in the US, where it's "v"! chris: Let's go with vs leaverou: I'm fine with vs Rossen: Any objections to adding vs to the color-contrast function? dino: Can someone type an example? <AmeliaBR> ``color-contrast(var(--fg) vs #002, #ffa)` <Rossen> color-contrast(wheat vs tan, sienna, var(--myAccent), #d2691e) <leaverou> color-contrast(wheat vs tan, sienna, var(--myAccent), #d2691e) <TabAtkins> color-contrast(wheat vs tan, #00ff00, var(--foo)) <heycam> really feels that "vs" looks lower precedence than commas here RESOLVED: Use vs in color-contrast function CSS Color Adjust ================ Why special-casing background-image for inputs? ----------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/4917 Rossen: This issue is calling out some special casing that was added for bg images on input elements Rossen: for the purposes of forced colors Rossen: and this was a legacy behavior that was carried forward over the years and not really necessary any more Rossen: Since we have the backplate, which is used to guarantee contrast where needed Rossen: Just commented earlier on the issue earlier, I'm completely fine with removing it from the spec and closing the issue Rossen: unless anyone has any reason why we shouldn't Rossen: Any objections to removing the special casing and closing the issue? RESOLVED: Remove the special case of background images on input elements wrt forced colors <fantasai> https://github.com/w3c/csswg-drafts/issues/3199#issuecomment-634368358 CSS Inline ========== Draft line-box-contain proposal ------------------------------- github: https://github.com/w3c/csswg-drafts/issues/3199 fantasai: This is the main one we've discussed a bunch about drafting alternate models for line layout fantasai: Some of the ideas are captured in the draft fantasai: Do we want to publish with them in the draft? fantasai: It's not in any way final, question is just whether we want a placeholder in there to solicit discussion on the ideas florian: Agree it's not final, but it's worth leaving in to get extra review dbaron: I think it's mostly reasonable, though there's a sentence in there I don't understand dbaron: "half-leading is inserted inside the content box edges rather than overlapping the pbm areas" fantasai: I can remove that sentence fantasai: If you wanted a line height that's less than 1, somehow we have to reduce the size of the box that we're considering for the height of the line fantasai: Otherwise it would increase the height of the line box fantasai: There's needs to be a reduction at least on the margin fantasai: somewhere we need to reduce the size dbaron: I guess there's 2 questions. One is what you said makes it sound like you want line height to change where the pbm go dbaron: When half leading would be negative fantasai: Yes fantasai: That's one option fantasai: but we could also not do that. It's not critical, I can remove it from the draft for now, but we should discuss at some point fantasai: Other option is to reduce the margin box dbaron: I think it might be good to move into an issue dbaron: Might be good to remove that part, but otherwise I'm fine with publishing with this in Rossen: Any other reasons to hold back publishing? <fantasai> baseline-source: auto | first | last fantasai: We also added a baseline-source property for #861 fantasai: The syntax wasn't resolved yet fantasai: We also added a leading-trim proposal, which again is not anywhere near final, but it's tracking the discussion we've had in the past fantasai: Then I pulled in a bunch of CSS 2.1 with florian's help, so we have some line height calculations defined in this draft. No changes, just imported text florian: Just to clarify, the 2.1 changes we're talking about (actually 2.2) we resolved florian: they've been reverted along with every other edit to CSS 2 as part of a temporary clean up florian: The wording we had resolved on and applied to CSS 2 is not present anywhere if we don't publish it here florian: so I'm strongly in favor of publishing it <fantasai> Summary of the changes we didn't quite resolve on at https://lists.w3.org/Archives/Member/w3c-css-wg/2020AprJun/0137.html Rossen: Any objections, to this and publishing inline? fantasai: Issue needs to remain open fantasai: The issue on adding a new model for line height calculations. The issue isn't closed yet, despite publishing <fantasai> all changes at https://drafts.csswg.org/css-inline-3/#changes <dbaron> In 3.5 "Leading Control" I'd change "the ascend and descent font metrics" to change "ascend" to "ascent" RESOLVED: Publish css-inline Should `initial-letter` be plural? ---------------------------------- https://github.com/w3c/csswg-drafts/issues/862 jensimmons: Originally this property was defined as initial-letter, then debated that it should be plural, since it can apply to more than the first "letter" jensimmons: Could apply to a group of letters, include punctuation jensimmons: We went down a road of whether this is the right name jensimmons: Don't seem to come up with a better name jensimmons: but we did resolve to switch to initial-letters a while ago, I think July 2018 jensimmons: then we've lived with that, writing spec and syntax using the plural version jensimmons: We're discussing today whether to go back to the singular jensimmons: For me, I wrote here in a comment that it's confusing jensimmons: first-letters will trip up authors jensimmons: I've not come up with a better name for initial-letter. As I've lived with it being plural, I've hated it. Would like to revert it florian: Ideally we'd have a verb of some kind, but can't come up with the right one florian: The pluralization doesn't really help with anything florian: I agree it would trip up people Rossen: There's a linked issue with some better naming option discussion Rossen: Opening with "should it be drop-cap, initial-cap, ..." fantasai: That discussion didn't make any progress fantasai: I agree we should revert to initial-letter <faceless2> +1 to reverting this. Rossen: Not hearing other opposing opinions AmeliaBR: What's the state of implementations? myles: We support it without the s faceless2: We have an s but we can drop it RESOLVED: Rename initial-letters to initial-letter Sizing atomic inlines as initial letters ---------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/3231 fantasai: An atomic inline is something like an image or an inline-block fantasai: Wasn't a lot of clarity on it, committed a bunch of changes saying the size as they do in normal circumstances unless it's an auto size, when we use the initial letter sizing algorithm <fantasai> https://github.com/w3c/csswg-drafts/commit/7f135bedb7e7732e2ca042efd906a1e51d171cf9 fantasai: Auto sizing is special, but everything else is normally as for atomic inlines fantasai: Wanted to run this past the WG florian: It's a change from being vague? or some other definition? fantasai: From being vague faceless2: We're trying to do this right now. Seems to be a good idea, looks like it will work Rossen: Any other opinions or objections? RESOLVED: Atomic inline initial letter size as regular atomic inlines, except for auto sizes being calculated using the initial letter algorithm shape-margin on initial-letters-wrap: first ------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/5117 fantasai: We resolved to allow shape-margin that wraps around the glyph, and wraps all the lines around the shape fantasai: The other values of initial-letter. One is first, which pulls the first line in and wraps it fantasai: The suggestion was if we apply a shape margin to all lines when wrapping to the glyph shape, shouldn't you also allow it when wrapping the first line to it fantasai: Proposal is to make shape-margin apply whenever you are wrapping to the glyph shape <jensimmons> +1 from me to this Rossen: Currently it's defined only to apply to floats fantasai: We should probably update to say it also applies to initial letter boxes fantasai: then define exactly how that works in initial-letter-wrap <astearns> +1 from me dbaron: Presumably you want the same wording that you have for 'all'? dbaron: [reads some spec text] <dbaron> What I read was "If the value of shape-outside is not none, shape-outside is used instead of the glyph outline. In both cases, shape-margin is applied to expand the outline." <dbaron> ... from https://drafts.csswg.org/css-inline-3/#valdef-initial-letters-wrap-all fantasai: Makes sense to me. Apply shape-outside and shape-margin, and use that as a replacement of the glyph shape faceless2: I agree that makes sense <florian> +1 RESOLVED: shape-margin and shape-outside apply to initial letter wrapped inline boxes, modifying or replacing the shape of the glyph Media Queries ============= Define Media Groups: continuous vs paged, etc. ---------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/5019 florian: A while back we discussed that media groups weren't defined anywhere but CSS 2, and defined vaguely florian: Concluded they're not actually used anywhere, except a few props saying they apply to all media groups florian: fantasai found one other place where we use this, which is wrt fixed positioning, where we have a different behavior between paged and continuous behavior florian: I think it does make sense to have a normative definition of this, MQs is probably a place for this. florian: I propose we inline the definition where block-overflow is florian: I would be inclined to say that for things that are fully scrolling without pages are continuous, and everything else as paged dbaron: I'd be inclined to say that the advertisement in the airport case [details missed] is not paged florian: I agree it's a bit weird florian: In practice it doesn't matter much. It's just going to be used for fixed pos, in a scrolling media it's going to be fixed, and in paged it will be replicated on pages florian: so with neither paging not scrolling, it doesn't really matter stantonm: Our default mode is paginated, but there's an option to switch to scrolling. So I think this makes sense Rossen: Hearing mostly support dbaron: The thing I'm thinking about is that in the future, things that have neither pagination nor scrolling seem more similar to continuous than paginated dbaron: if we're going to add any future distinctions on this florian: My intuition goes the other way. But I don't think it makes a normative difference right now dbaron: Don't feel strongly fantasai: Defaulting to continuous sounds better since people are mostly designing for continuous fantasai: The one that makes me concerned is things that are both continuous and paged florian: If you have pages, and fixed pos, I would expect the thing to be on each pages florian: The fact that some pages might be longer and have scrollbars doesn't invalidate that Rossen: You'll add both continuous and paged media definitions to overflow? florian: This is just terminology. I will tie this into the definition over overflow-block Rossen: in MQ4? fantasai: Given we're importing up from CSS 2 ... florian: We're importing words that didn't have a precise definition fantasai: MQ4 makes sense Rossen: This will restart CR? florian: We need to do a republication soon folding in a few issues florian: Not going for republication just yet, but will in a few weeks RESOLVED: Add definitions for paged and continuous media to MQ4 CSS media query width and window.innerWidth may not be equal ------------------------------------------------------------ github: https://github.com/w3c/csswg-drafts/issues/4713 florian: MQs lets you test the width (and height) florian: of a page, and the MQ works in terms of floating point numbers florian: There is also window.innerWidth, which relates to the same dimension, but it's an integer florian: the fact that they're different is weird florian: If you test the MQ against a value against the window.innerWidth you may get surprising results florian: A strict equality MQ could fail florian: In practice min-/max- is better. But this is odd, not sure what to do about that Rossen: This is when you use window.matchMedia() with a value from window.innerWidth? <Rossen> "window.matchMedia('(width > window.InnerWidth)') << this is a problem dbaron: I think one thing that could be done is to propose an API that is better than window.innerWidth, and returns the float values Rossen: I guess the questions that is MQ-scoped, is there anything we should be looking at doing for the MQ width or not? florian: I would like to not change it. But given I don't know how/ whether to solve it... florian: so would rather go in dbaron's direction florian: rather than change MQs to work on integers Rossen: The usage of @media width is very high Rossen: making a change would be very disruptive, don't think we have that option Rossen: any objections to not change @media width/height? RESOLVED: No change to @media width/height
Received on Thursday, 4 June 2020 23:16:06 UTC