- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 24 Jul 2018 19:09:26 -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.
=========================================
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