W3C home > Mailing lists > Public > www-style@w3.org > June 2020

[CSSWG] Minutes Telecon 2020-06-03 [css-color-5] [css-color-adjust] [css-inline] [mediaqueries]

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 4 Jun 2020 19:15:22 -0400
Message-ID: <CADhPm3u65mG4dyCMh6VaQyEjyu7gbAHQfZPynreYBMCMP6+oJg@mail.gmail.com>
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

This archive was generated by hypermail 2.4.0 : Thursday, 4 June 2020 23:16:07 UTC