- 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