W3C home > Mailing lists > Public > www-style@w3.org > July 2018

[CSSWG] Minutes Sydney F2F 2018-07-04 Part V: Selectors 4, CSSOM, CSS Nesting, [selectors-4] [cssom] [css-nesting]

From: Dael Jackson <daelcss@gmail.com>
Date: Tue, 24 Jul 2018 19:09:26 -0400
Message-ID: <CADhPm3tXZ+qptz3dWucZQWD3euxLkfVyQWMprXZhjeyDGESR-w@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.
=========================================


Selectors 4
-----------

  - There were seven options for naming the 0 specificity alternative
      to :matches()
      1. :is()
      2. :matches() + replace existing :matches() with :is()
      3. :if()
      4. :also()
      5. :where()
      6. :selects()
      7. :also() + replace existing :matches() with :is()
  - The group narrowed the list to options 3 & 5 (:if and :where) but
      were evenly divided and will seek more opinions to decide
      between those options

CSSOM
-----

  - RESOLVED: All shorthands must show up in getComputedStyle (Issue
              #2529)

CSS Nesting
-----------

  - RESOLVED: Add css-nesting as an ED, Tab Atkins as editor, file
              issues until people are overall kinda happy with what
              it's like before we consider FPWD

CSS Values & Units
------------------

  - RESOLVED: Specified values are serialized as keywords if specified
              as keywords and percentages if specified as percentages
              (Issue #2274)
  - RESOLVED: For <bg-position>, preserve keywords where we can,
              center turns to top 50%, and where we need to add a
              keyword use top/left, where we add an offset, use
              percentages. (Issue #2274)
  - RESOLVED: For computed values of <bg-position> and <position>,
              they are always two <length-percentage> values. (Issue
              #2274)

===== FULL MINUTES BELOW ======

Agenda: https://wiki.csswg.org/planning/sydney-2018#schedule

Scribe: florian

Selectors 4
===========

Bikeshed the 0 specificity alternative to :matches()
----------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/2143#issuecomment-360586470

  ericwilligers: [projets the issue]
  fantasai: If we have :not() and :is(), they should have the same
            specificity, otherwise it's confusing
  ericwilligers: :matches has changed specificity recently
  fantasai: That's out of scope here, it's a slight adjustment

  ericwilligers: :when() was time based, so I proposed :where(),
                 haven't heard back
  astearns: Does anyone have problem with :where() ?
  leaverou: :has does that avoid the problems that :is() has?
  fantasai: Because :is() and :not() need to be opposite
  leaverou: How about having :is-not() be the opposite of :is()
  all: Noooo

  frremy: :where() works for me
  ericwilligers: :has() to combine well with :not()
  leaverou: Why can't we change :matches()? it has shipped, but nobody
            uses it yet

  astearns: We've discussed doing it several time, and failed to reach
            consensus
  fantasai: leaverou propose to just change the specificity of
            :matches(), and add a new one for the other specificity
  frremy: Why use the :matches() name at all, it's a bad name
  leaverou: We're stuck with it anyway
  fantasai: I want a short list so that we can think about it

  [fantasai scans down the list of suggestions, eliminating any
   for which there is no support from anyone]
  [List:
      1. :is()
      2. :matches() + replace existing :matches() with :is()
      3. :if()
      4. :also()
      5. :where()
      6. :selects()
      7. :also() + replace existing :matches() with :is()
  ]

  leaverou: Would you object to :is() if it did what :matches()
            currently does, and :match() is the 0 specificity one?
  fantasai: No, I would not
  leaverou: What if we just have one, with an argument for specificity
  fantasai: Too confusing

  shane: :where() makes sense for people who have used SQL, but for
         others it is confusing, and seems to involve position
  leaverou: I find SQL readable, but that's because it's a full
            sentence, which isn't the case in css
  fantasai: I like 2 and 4
  frremy: :and() means nothing to me, all selectors already imply that
  fantasai: Agreed, also confusing because opposite sides of “and” are
            equivalent, but :also() doesn't have that implication since
            it begins a subsidiary clause
  leaverou: In favor of :also()

  dbaron: We have an HTML element called <select>, probably bad to use
          :select()
  Rossen: Let's start removing
  Rossen: Kill :select()
  ericwilligers: I think we can also kill :if
  Rossen: :if() would need an :else()
  frremy: Why?

  leaverou: I'd like 7 (:also())

  [discussion of :any(), which was a subset of :matches()]
  frremy: :matches() was called that way because the DOM API is called
          that
  fantasai: Actually, it's very old, original :matches() proposal was
            from hixie a long time ago, before :any()
  <dbaron> I implemented :-moz-any() in Gecko in 2010 in
           https://bugzilla.mozilla.org/show_bug.cgi?id=544834
  ericwilligers: It has been in webkit for a long time
  astearns: How much web content uses :matches?
  iank: Not a lot, looking at usecounter
  ericwilligers: usecounter may be wrong

  Rossen: Is either 2 or 7 an option? they involve changing :matches.
          webkit people, can we do that?
  myles: We could
  myles: We would be moderately interested in updating, but it's low
         priority
  dino: Why ?
  fantasai: Because a well-named proposal otherwise is :is(), but it is
            bad if it's specificity doesn't match :not()
  fantasai: So we could change :matches() to be the 0 specificity one,
            freeing the room for :is() to do what :matches() does now
  leaverou: Maybe we can resolve on that in parts

  fantasai: Removing option 1
  fantasai: The web compat impact of 2 and 7 are different
  ericwilligers: Does anyone want 2?
  fantasai: Removing 2
  [lots of people]: I don't like also.
  [lots of people]: [lots of jokes]

  leaverou: What's wrong with :also ?
  dbaron: :also comes after something, but it doesn't come after
          anything particular
  <dbaron> The thing I was talking about was called a "simple
           selector" in CSS 2, a "sequence of simple selectors" in
           selectors-3, and a "compound selector" in selectors-4.
  Rossen: Agreed (with a pun)

  ericwilligers: :where() implies position OR situation
  fantasai: Does :where() not have the same problem as :also()?
  fantasai: :matches() does not have that problem
  frremy: I prefer :where() and :if(), and :if() makes a lot of sense
          when you read it
  astearns: :if() clashes with JS?
  [lots of people]: It doesn't
  [lots of people]: :if() calls for :else()
  [lots of people]: It doesn't

  philipwalton: Was the reason for doing this that the specificity was
                bad, or to give control over specificity? [answer:
                latter] It seems like a pseudo-class isn't the right
                tool for that, but I guess that's the right tool for
                the job.

  heycam: One option was to have a specificity parameter in :matches()
  astearns: We have agreed that renaming :matches() is not necessary to
            solve this
  astearns: We rejected some of the options, we should make a smaller
            list of plausible

  fantasai: We should make a strawpoll, and then call for objections
            on the most popular
  fantasai: :if() gets 7 votes
  fantasai: :also() gets 1.5votes
  fantasai: :where() gets 7 votes

  astearns: Objections to :if() ?
  astearns: Objections to :where() ?
  leaverou, fantasai, iank: strong reservations

  astearns: I am not declaring consensus
  astearns: We will ask outsiders about :if() vs :where()

CSSOM
=====

getComputedStyles and shorthands
--------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/2529

  emilio: FF and Edge only support getComputedStyle() on shorthands
          that used to be longhands, Blink supports more
  emilio: Shorthands in the computed style object are exposed as
          properties
  emilio: I want to know what people want. Fine with changing, but
          it's work
  ericwilligers: If it was a longhand, it would serialize
  TabAtkins: It needs to, for compat
  emilio: There are bugs on the grid shorthands
  emilio: People have argued various ways.

  TabAtkins: This is an obvious forward compat mistake
  TabAtkins: All properties from now on should support it
  TabAtkins: and if we can, all the legacy shorthands should as well,
             when a value can be constructed if it's not a a webcompat
             problem
  TabAtkins: which doesn't seem to be the case
  dbaron: If it's not possible to represent, then we have to go for
          empty string
  TabAtkins: That's fine
  <TabAtkins> It's still forward-compatible; adding a new property to
              the shorthand will never make it, by *default*, stop
              serializing

  emilio: There's also the question of computed values vs resolved
          values
  heycam: It would be very weird if the longhands resolved but the
          shorthands didn't, so we should match
  heycam: Edge is the only other browser not doing it. So Edge?
  emilio: Edge, are you OK with doing it? the only ones you have on
          top of used-to-be-longhands are grid properties.
  Rossen: I don't believe I've seen compat issues. I am reluctant to
          write a bunch of code for something that's not needed.
  TabAtkins: Going forward, we need to.
  TabAtkins: For legacy props, it wouldn't be the end of the world if
             we didn't do it, but it would be inconsistent and
             unfortunate.
  emilio: It can be done quite easily for lots of properties
  Florian: Can we resolve to do on all, even if priorities means it
           might take a while
  Rossen: We need consistency, so let's have it everywhere.

  RESOLVED: All shorthands must show up in getComputedStyles

  xidorn: I wonder if you should see the shorthands in the iterator
  xidorn: I think there's a usecase for copying computed values from
          one element to another, and they just iterate through
  myles: This should be a separate issue.

getComputedStyle() on elements not in the flat tree
  -------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/1964

  emilio: frremy added that, but we already resolved
  frremy: it's a bot bug, nothing to talk about
  <emilio> Was resolved on
https://github.com/w3c/csswg-drafts/issues/1548#issuecomment-380383455

Consider disallowing NULL code points in stylesheets
----------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/2757

  TabAtkins: [trying to find the original bug]
  Rossen: What's left to do?
  Florian: For TabAtkins to argue his case against our previous
           almost-consensus

CSS Nesting
===========

Request to pick up the css-nesting proposal
-------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/2701

  TabAtkins: We tried to discuss that a while back, but didn't have
             time to conclude. Should we rediscuss, or re-resolve

  myles: I want an overview
  <TabAtkins> https://tabatkins.github.io/specs/css-nesting/
  TabAtkins: Nesting style rules is a common request, and a feature of
             every CSS pre-processor in existence
  TabAtkins: and one of their most popular feature
  TabAtkins: Makes stylesheets much easier to maintain
  TabAtkins: It is purely syntactic sugar, but is worth covering
             because of the huge demand
  TabAtkins: The way they're done in preprocessors are ambiguous with
             properties wrt parsing
  TabAtkins: My propose spec disambiguate with by using &
  TabAtkins: You can use & at the front, and if you want it elsewhere,
             you can use @nest to keep things unambiguous
  <TabAtkins> a:hover ....
  TabAtkins: The above looks like a "a" property with a "hover" value
  TabAtkins: CSS parsing only requires a finite amount of lookahead,
             and we'd like to keep it that way
  * fantasai thinks this is looking pretty messy

  leaverou: Isn't it only a problem when the tag selector is the first
            part of the selector? We could only require in that case?
  TabAtkins: I don't like that because it's not obvious, and hard to
             teach
  fantasai: You could pick a random character to start every rule with,
            to be consistent
  TabAtkins: Yes, that's what "@nest" do
  frremy: replace @nest with &
  <TabAtkins> & &.foo {...}{
  TabAtkins: It's ambiguous
  Florian: I don't like it, @nest is nicer
  leaverou: That would be hard to read
  <frremy> &:hover
  <frremy> & > span > &
  frremy: you only include it if needed
  * fantasai thinks this is a good argument for >> descendant
             combinator
  <TabAtkins> & span:not(&) {...}
  TabAtkins: other bad example ^
  <frremy> (I was convinced by the clarification that the & can be
           replaced more than one in the selector, which I didn't know)

  heycam: Can we require starting with a combinator (and use an
          explicit descendant combinator)
  TabAtkins: Doesn't solve it for & in the middle
  fantasai: If you use @nest, use it everywhere. If you think that's
            too verbose, choose a different disambiguator.
            Alternating between using @nest and not is not great
  TabAtkins: Too verbose
  heycam: @nest introduces a block?
  leaverou: ????
  TabAtkins: Very hard to express in grammars
  TabAtkins: In the most common cases, stating with an ampersand is
             short, which is important
  fantasai: Use something shorter than @nest
  Florian, fantasai: how about naked @
  <leaverou> fantasai, or naked & to introduce a nested block? /* just
             throwing ideas! */

  myles: We don't have to bikeshed the syntax if we're just talking
         about adopting the module
  astearns: Objections?
  frremy: Does it need to be a new module?
  florian: No, but it's nice that way

  astearns: Objections?
  fantasai: ED is fine, want to bikeshed the syntax before FPWD
  fantasai: Seems like nobody is really happy with the spec as-is

  xidorn: No objection, but my concern is that it expands in some
          cases into :matches() like things
  xidorn: and that's hard to optimize
  TabAtkins: You can expand them out fully
  emilio: How about the OM?
  TabAtkins: Not expanded in the OM, rules get a .childRules object
  xidorn: That makes it hard
  xidorn: because of the combinatorial explosion
  florian: We still have to deal with that in preprocessor generated
           stylesheets

scribe: fantasai

  astearns: Hearing no objections to starting work on the module.
            Hearing a lot of issues against it.
  astearns: Anyone else interested in helping Tab?

  RESOLVED: Add css-nesting as an ED, Tab Atkins as editor, file
            issues until people are overall kinda happy with what it's
            like before we consider FPWD

  <TabAtkins> The preprocessor features that are :matches()-equivalent
              explode combinatorially, so the preprocessors trim what
              they generate. In the common case, nesting expands
              merely multiplicatively , so they fully expand; so you
              are already *parsing* a fully-expanded set of selectors.

CSS Values & Units
==================

serialization of <position>
---------------------------
  github: https://github.com/w3c/csswg-drafts/issues/2274

  <ericwilligers> "<position> is always serialized as 2 or 4 values."
                  or "Neither component may be omitted when
                  serializing."
  ericwilligers: I think we've completely resolved serialization of
                 <position>
  fantasai: We already resolved that <bg-position> should serialize
            same as <position>
  <ericwilligers> How exactly does "left 10% center" serialize?
  fantasai: Need to resolve that keywords are serialized out in
            specified value if originally specified as keywords (and
            not otherwise)
  emilio: In which order?
  ericwilligers: Horizontal first
  emilio: And always both
  ericwilligers: Yes

  dbaron: It feels like this is saying you have to remember the syntax
          level, but you don't preserve the number of values in the
          syntax
  dbaron: But you preserve the keywords
  ericwilligers: ...
  ericwilligers: We're talking about specified values only atm
  ericwilligers: Edge sometimes serializes as percentages rather than
                 keywords
  ericwilligers: For certain properties
  Issue comment:
https://github.com/w3c/csswg-drafts/issues/2274#issuecomment-402330108
  <ericwilligers> Existing spec: "If only one value is specified, the
                  second value is assumed to be center." "The
                  canonical order when serializing is the horizontal
                  component followed by the vertical component."
  <ericwilligers> https://drafts.csswg.org/css-values/#position
  <ericwilligers>
https://drafts.csswg.org/css-backgrounds-3/#propdef-background-position

  astearns: Any objections to specifying that specified values are
            serialized as keywords if specified as keyword sand
            percentages if specified as percentages?

  RESOLVED: specified values are serialized as keywords if specified
            as keyword sand percentages if specified as percentages

scribe: heycam

  <dbaron> There was a discussion about 'left 1% center" which is
           apparently no longer a valid <position> but is a
           <bg-position>.

  ericwilligers: If 3 values are specified, we'll need to turn into 4
                 values
  ericwilligers: : "left 10% bottom" -> "left 10% bottom 0%"
  ericwilligers: "left 10% 20%" -> "left 10% top 20%"
  fantasai: If we need a keyword we use top or left, if we need an
            offset we add a percentage
  ericwilligers: Plus a weird case for center
  ericwilligers: We can convert 3 values to 4 values by converting
                 "center" to "top 50%", "bottom" to "bottom 0%", and
                 "20%" to "top 20%"

  astearns: And there's text in Shapes that does everything you said,
            except that shapes will convert bottom to top 100%
  ericwilligers: We've resolved to remove that text, but I can reuse it
  astearns: I don't mind if it stays as bottom or converts to top

  fantasai: So left 10% bottom 0% would stay as is, but left 10%
            bottom would become left 10% top 90%?
  astearns: Yes
  fantasai: If we're preserving the keyword in the case we have the
            offset, may as well when we don't too
  emilio: Does everyone support 3 values on background-position?
  fantasai: Yes
  astearns: We ripped it out everywhere we could, but had to leave it
            there
  emilio: ok, I'm fine with that

  RESOLVED: For <bg-position>, preserve keywords where we can, center
            turns to top 50%, and where we need to add a keyword use
            top/left, where we add an offset, use percentages.

  ericwilligers: Earlier talking about computed values, I was
                 incorrect to say we never give keywords. We do
                 sometimes!
  ericwilligers: But I don't think we should
  ericwilligers: I propose for computed values, it's always
                 <length-percentage>
  Rossen: or calc()
  astearns: So for computed values of <bg-position> and <position>,
            they are always two <length-percentage> values
  astearns: no keywords, calc() if needed

  RESOLVED: For computed values of <bg-position> and <position>, they
            are always two <length-percentage> values.
Received on Tuesday, 24 July 2018 23:10:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:11 UTC