- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 29 Jun 2022 19:29:01 -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.
=========================================
August F2F
----------
- Reminder to put on the wiki if you're attending, especially if
planning to be in person
Images 4
--------
- RESOLVED: Publish new WD of Images 4 (Issue #7043: Long overdue for
republishing)
CSS Contain
-----------
- RESOLVED: Change initial value of 'container-type' to "normal"
(Issue #7402: Rename container-type: none to normal)
- A new issue will be opened to discuss if there should be a blanket
restriction none/normal/auto in custom idents
CSSOM View
----------
- RESOLVED: Rename to checkVisibility() (Issue #7317: Rename
Element.isVisible to Element.isHidden?)
CSS Backgrounds
---------------
- Oriol will add specific cases to consider on issue #7103 (The shape
of box-shadow should be a circle for a box with border-radius:50%
and big spread) and then the group will take up the conversation
at the F2F where there's more time to spend.
CSS Variables
-------------
- RESOLVED: Start new draft of variables-2 and add custom units as
described here (Issue #7379: Custom units as simple
variable desugaring)
Selectors
---------
- masonf will discuss with the OpenUI group if the proposal in issue
#7319 (Add `:top-layer` pseudo class) should be a pseudo-class or
pseudo-element.
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2022Jun/0017.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins Bittner
David Baron
Mike Bremford
Oriol Brufau
Tantek Çelik
Elika Etemad
Simon Fraser
Mason Freed
Megan Gardner
Chris Harrelson
Brian Kardell
Brad Kemper
Jonatha Kew
Vladimir Levin
Chris Lilley
Peter Linss
Ben Mathwig
Khushal Sagar
Jen Simmons
Alan Stearns
Miriam Suzanne
Bramus Van Damme
Lea Verou
Scribe: fantasai
F2F in August
=============
astearns: Reminder f2f in about 4 weeks, please put your details into
the wiki
<fantasai> https://wiki.csswg.org/planning/nyc-2022
TabAtkins: It's very important that you let us know if you're
attending in-person
TabAtkins: We need to plan for food and stuff
<lea> Chris and I may not know if we can come until days before :(
<fantasai> Lea, that's okay. As long as not everyone does that ;)
Images 4
========
Scribe: TabAtkins
Scribe's scribe: fantasai
Long overdue for republishing
-----------------------------
github: https://github.com/w3c/csswg-drafts/issues/7043
fantasai: I haven't had time to review, but I'm happy to publish for
now and have any trouble brought up later
astearns: Objection to publishing WD?
RESOLVED: Publish new WD of Images 4
CSS Contain
===========
Rename container-type: none to normal
-------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7402
fantasai: Since we made style containment the default on every
element, the initial value of container-type is "none".
fantasai: Was wondering if we wanted to name that as "normal", which
would possibly let us shut off style containment later if
needed
fantasai: No strong opinion.
TabAtkins: I agree that renaming to normal works
miriam: Agree and also don't have strong opinion
astearns: In the issue antti said they weren't opposed to the change
astearns: But I think they were considering the case where we add
names to style containers
astearns: So we could put into the issue that we're okay with
considering it?
smfr: If there's more context, I can ping antti and get his response
astearns: My take is that it's not that container-type has nothing to
do with style containers, it's just that everything is a
style container, and the only thing container-type *is*
doing for style-only containers is letting you set a named
style container.
astearns: I think antti is thinking we've broken the connection to
the property entirely
astearns: Would be good to find out
astearns: Simon, do you want to ping antti and we resolve next week?
smfr: Believe he's on vacation so might not get a response by next
week
astearns: Alternately we could resolve now and let them bring up an
objection later if it's still there?
smfr: I think I'd prefer that this issue have enough context that
antti can read it and be sure he understands the issue
smfr: But with that, I think I'm okay with resolving and letting him
bring up an issue
fantasai: The two reasons are: 1) because style is a type of
container, saying "none" is disingenuous
fantasai: 2) we might want a way to turn off style container on an
element, and using "none no-style" is somewhat awkward.
"normal no-style" is more neutral
fantasai: We're also not allowed to use container-names of "none" and
we should keep that restriction, and also exclude "normal".
astearns: So proposed resolution is to change container-type's
initial value to "normal" ,but still resolve "none" as a
future value
<fantasai> +1
ntim: How about 'auto' instead of 'normal'?
fantasai: Could work, but 'auto' usually implies more magic
astearns: I slightly prefer normal over auto, but no great argument
either way
<TabAtkins> I'm lightly for "normal" for the reason fantasai gave
ntim: No strong preference, just a thought
astearns: So any objections to normal?
RESOLVED: Change initial value of 'container-type' to "normal"
fantasai: Tab suggested in IRC that we just blanket restrict none/
normal/auto in custom idents and I propose we do that.
astearns: Makes sense, but do we have those allowed in the past that
would cause compat issues?
fantasai: Possible but seems unlikely.
chrishtr: What does that mean?
TabAtkins: A custom-ident can never be keyword 'initial'; all global
keywords are restricted.
TabAtkins: we'd just add this to the list of keywords
<lea> +1
chrishtr: Could it break content?
TabAtkins: if people are currently using those names, yes
TabAtkins: but they are very generic, so it seems unlikely
TabAtkins: but we can check
astearns: We should open a new issue
<fantasai> -> https://github.com/w3c/csswg-drafts/issues/7431 for
custom-ident restriction
CSSOM View
==========
Rename Element.isVisible to Element.isHidden?
---------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7317
chrishtr: I think we're ready for the name. We had a vote up for the
last week
<vmpstr> +1
chrishtr: 9 votes for checkVisibility() and only a few on anything
else, suggest we resolve on that
astearns: Small number of votes but it was the clear winner
bkardell: Don't want to block, but all feel like less-bad rather than
good
bkardell: I gave some ideas in the thread but it doesn't seem to have
gone anywhere
bkardell: Seems worth to take at least one more beat to be sure we
consider that
astearns: That said, we've gone over this several times and solicited
better names several times
astearns: Your suggestions in particular I'm not fond of due to
spelling
astearns: Would think we'd've found a better term in the previous
discussions if one existed
bramus: If checkVisibility() is the name, what does it return?
chrishtr: Still true/false, true if visible
fantasai: Agree with bkardell that this name isn't amazing, but think
it's the best we have, and it doesn't have quite as much
confusing downside as isVisible/Hidden. Fine with going for
it since we don't have a better option and it's not too
overloaded of a term.
astearns: Suppose we could resolve this as "best of everything we
have so far", leaving it open for new suggestions but
closing it to all the ones we've considered.
chrishtr: I think we can just resolve.
<TabAtkins> +1 to just resolving, fine with this name
florian: Also not huge fan of the name but found others problematic.
florian: This one might not be lovely but it doesn't cause problems
astearns: brian did you want to block?
bkardell: Do not, it just didn't get much discussion.
bkardell: Like you said, we need to make progress. If people think we
won't do better, I support that.
astearns: So proposed resolution is checkVisibility()
RESOLVED: Rename to checkVisibility()
CSS Backgrounds
===============
The shape of box-shadow should be a circle for a box with
border-radius:50% and big spread
---------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7103
oriol: When you specify border-radius, the length is the corner
radius of the outer border edge
oriol: For inner edge we subtract the border width from that
oriol: Spread is the opposite
oriol: Initial value of spread is 0 tho, so this would make an
elliptical border radius have corners
oriol: Firefox has special case for spread radius of 0, keeping it
sharp. But 0.1 makes rounded corners
oriol: Suggest adding a correction term that gives sharp corners at 0
and continuously transforms to round.
oriol: So the issue: if you say border-radius:50% you get an ellipse.
oriol: If you have a shadow you probably also expect it will be an
ellipse.
oriol: Blink changed impl to match the spec, and people complained
their shadows were no longer circles.
oriol: Proposal in the issue is, instead of adding the spread
distance and subtracting a correction term, we could express
the border-radius as a % and then, for the shadow, we use the
same % but resolved agaisnt the size of the shadow
oriol: This seems to improve various cases, we have posted images in
the thread
oriol: Shadows look better, stay circular
<astearns> images in this comment:
https://github.com/w3c/csswg-drafts/issues/7103#issuecomment-1146870682
oriol: Downside is if you specify a length, and elemnet has circular
corners, shadow will have circular corners. New change will
instead make them elliptical if the box isn't square
oriol: Vlad suggested a variant where we only resolve to a % in one
axis, then keep the same aspect ratio for the corner
<vmpstr> it's kind of, sort of like nine-patching the border radius
<astearns> problem ellipse images in this comment:
https://github.com/w3c/csswg-drafts/issues/7103#issuecomment-1168157338
oriol: Problem is if the element is a full ellipse, you won't get an
ellipse shadow. Circles stay circles but in an ellipse you'll
get flat edges on the short axis.
oriol: I proposed another idea - we could say that for the shadow we
just add spread-distance to the border-radius
oriol: This would imply that for 0px you'd have rounded corners
oriol: But we'd also change the initial value for border-radius is
"none", which would stay sharp. Unsure about compat tho.
oriol: fantasai proposed interpolating between some radius formulas.
oriol: Various options, not sure which is best.
fantasai: Two ideas. One is the problem is largely around circular/
oval shapes. Many of those are done with %s.
fantasai: So we could say if the radius is a % we maintain it as a %
in the spread shape.
fantasai: Dunno if that really works since the other way to do a
circle is to do a huge px length and we scale it down.
fantasai: So it depends on how authors are specifying things.
fantasai: Another possibility is to interpolate based on how much of
a straight side we have.
fantasai: So if the straight side is longer than the radius, we use
existing formula which is good for rectangular shapes
fantasai: If straight side is 0 we use the % formula
fantasai: And between we can interpolate.
TabAtkins: I hadn't gone this deep before, I suspect I have opinions,
but would like to take up at a later call, maybe at F2F
fantasai: F2F sounds good, can draw stuff
astearns: Leading up to F2F, we should have a set of things to test
against
astearns: We absolutely need to fix the spec
astearns: I'm not sure that we need to have a fix that is good enough
for all the edge cases yet
fantasai: We have a bunch of examples currently, both working and not.
<TabAtkins> I suspect we might need to address this semantically at
the border-radius side with a keyword that does ellipse.
astearns: Can I ask Oriol to list out the cases to consider?
astearns: Summarizing them in the issue, and people can respond in
the issue.
astearns: We'll tag this for F2F and come back to it
<fantasai> https://drafts.csswg.org/css-backgrounds-3/spread-radius
fantasai: We also have this which we can update
CSS Variables
=============
scribe: fantasai
scribe's scribe: TabAtkins
Custom units as simple variable desugaring
------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7379
TabAtkins: A week or two ago Jonathan Neal had a suggestion in
Twitter, just doing on pre-processor side, about a way to
finally address custom units
TabAtkins: where you want to set some length and use multiples of it
TabAtkins: Used all over design systems, but doing today with
variables is awkward
TabAtkins: have to explicitly use a calc and multiply, quite a lot of
writing for what is ~3ch for pre-defined units
TabAtkins: Suggestion is to treat custom units just as variables
TabAtkins: so if have number with --unit, this is a variable reference
TabAtkins: triggers same stuff, but resolve it into the appropriate
calc
TabAtkins: so 3--unit would become calc(3 * var(--unit))
TabAtkins: can set up lengths with @property rule
TabAtkins: can have some control about whether absolute links are
resolved as time of use or ?? by setting as <length> or not
TabAtkins: Seems to solve most problems of custom units
TabAtkins: but doesn't prevent us from doing something more
complicated using registration
TabAtkins: later
TabAtkins: This allows more readable usage for design systems, not
complicated on implementation side
TabAtkins: One of our implementers was looking for implementations
problems and couldn't find any
TabAtkins: Thoughts?
<dbaron> +1, sounds simple and valuable
<florian> haven't spent much time thinking about it, but seems
reasonable (and terse)
astearns: faceless comment that they didn't find it particularly
readable
astearns: and hides complexity that maybe should be expressed
faceless: [...]
faceless: but no objection
bramus: Would allow ability to polyfill new units as well, e.g.
define --brm and use your new custom unit code to polyfill it
bramus: seems really nice
astearns: For browsers that do not support the new unit, what happens
when you use the custom property
bramus: Browser would support the real unit, which you have just made
your custom unit as an alias, and for browsers that don't
support it you can give them the fallback
TabAtkins: If we had ability to do parse-time rejection of declared
properties... but need JS for that
miriam: I think this would help solve cases where we would need to
remove units from a value, e.g. viewport width people want to
use them in a unitless place like line-height, but this
wouldn't help with that case, right?
TabAtkins: Right, that wouldn't help. What you need is the unit math
in the spec to be implemented.
jensimmons: I really love this, just wish the -- doesn't need to be
there
jensimmons: I do think it would be helpful to get some feedback, can
think of 2-3 people working on responsive typography be
good to get their feedback
jensimmons: they're using mix of absolute and relative sizing in
setting type sizes etc.
jensimmons: could be very powerful
TabAtkins: That's one of the major use cases, so would be great to
get their feedback
<lea> I love how general this is, +1 from me too
astearns: Sounds like this is something we should pursue
TabAtkins: Where to put it? Variables 1 is fairly mature, so suggest
starting Variables 2
astearns: Makes sense to me
<lea> +1 for variables-2
<fantasai> +1
astearns: Proposed resolution is to start variables-2, with this as
the feature to add
astearns: Any objections?
RESOLVED: Start new draft of variables-2 and add custom units as
described here
astearns: Let's keep this issue open for a little bit, so Jen you can
get some additional people to give feedback
Selectors
=========
Add `:top-layer` pseudo class
-----------------------------
github: https://github.com/w3c/csswg-drafts/issues/7319
masonf: I've been working on [missed]
masonf: We resolved to create :modal, for all things that are modal,
starting with modal dialog
masonf: Raised this issue for what's the pseudo-class for things in
the top layer
masonf: We need this so that pop-up can have different styling/
animations when it's in the top layer
masonf: There's a bit of a nuance, when animating in or out, will be
in top layer but not match the pseudo-class
masonf: so maybe need a pseudo-class that is more specific
masonf: but the question is whether to have such a pseudo-class, and
what should it be called
masonf: An alternative is to create a top-layer element in HTML, and
allow using structural pseudos
masonf: I'm relatively agnostic, thing any of these can work with
popup API
ntim: I'm quite against the :top-layer pseudo-class, as I mentioned
in the issue, I think it doesn't speak to what developers
generally want
ntim: For :modal, can describe what :modal is
ntim: But for :top-layer, can't really describe top-layer, doesn't
really speak to developer perspective, more of implementer
perspective
ntim: I think ?? helps a bit more, but concept of top layer itself is
very specific to browser engine worldview
ntim: I don't think it should exist in the current proposed way
ntim: It's also hard to describe what's the relation with the popup
API
ntim: Why open popup in the top layer ... it's not straightforward
for developers
masonf: You said you're against the whole thing, but your complaint
seems to be about the name, is your complaint the name or the
concept?
ntim: It's the name, but
ntim: the concept itself is also a hack
ntim: it's a hack by itself
masonf: Can you clarify?
masonf: top-layer is well-defined for fullscreen and modal, how is it
a hack?
ntim: In a way it's a well-defined concept, sure, but it only exists
because there's no way to display everything on top with z-index
ntim: that's the only reason it exists
ntim: it's a hack in that sense, it's a concept that only exists for
a certain thing
dbaron: Is your objection that you'd rather see separate
pseudo-classes for things that put things in the top layer,
if there's need for those pseudo-classes?
ntim: yes
astearns: We've had discussion about scoping things to particular UI
elements, and wanting to prefer more generic pseudos
ntim: If you want generic pseudo-classes, I think something that
speaks more to web developers, something like :open vs
:top-layer
ntim: Idk
masonf: Open is also very very overloaded, and can be confusing
masonf: top-layer is very descriptive, it's either in the top layer
or not
masonf: Agree it's a hack to get around z-index, but it's
well-defined whether it's in top layer or not
masonf: Could also create something specific like :open-popup, but if
we want to be more generic ...
chrishtr: Following pattern of :modal class, we want to describe
well-defined behaviors, what is the underlying UI state
that this is matching against?
chrishtr: In :modal, it's the modalness, can't interact with other
things
chrishtr: just need to come up with other names
chrishtr: Maybe make specific to the element?
astearns: It's a push me pull you
astearns: making something generic to the property that we're trying
to select
astearns: Works really well until we really need to distinguish
between the two different things that have this property
that never want to be styled together
astearns: unfortunately we go back and forth quite a bit
chrishtr: If developer wants to do that, they could combine attribute
selector with pseudo-classes, to distinguish between
different types of the element in the popup state
astearns: That's true
fantasai: Not trying to select the topmost item in the top layer, but
all of them, right?
masonf: Yes
fantasai: So if you have multiple dialogs and a popup in there,
they're all matched
masonf: Yeah, they're all in there. Suggestion by bramus for a
::top-layer pseudo-element that would let you select the
top-most one, but as a pseudo-class it gets them all
<bradk> :nth-layer(n) maybe?
fantasai: Okay also there was something about animation state and
popups, making this not match? Not sure what that is about.
masonf: It's somewhat peripheral, but for popups you can animate it
to show or hide. There's two stages - it gets put into the
top layer, and need a way to select when it's being shown,
and reverse when hidden.
masonf: Think that's very specific to the popup api
fantasai: Wouldn't you want to do that with the fullscreen or dialog
as well?
masonf: Yeah might be more general. Let's talk about top-layer first
though, if there's a transitional state we can discuss that
fantasai: So it sounds like you want to select top-layer and
topmost-layer?
masonf: I think it's needed for top layer, but I have heard requests
for topmost.
fantasai: Okay. I agree top layer isn't ideal term since it's
confuse-able with other things, but we can come up with
names.
fantasai: First question is just whether we want to add the pseudo at
all.
TabAtkins: I might have raised that
TabAtkins: Big deal is things that UA puts in top layer, and things
that CSS puts in top layer, still want to be distinct
TabAtkins: Need to have a discussion about it
TabAtkins: it's a complicated issue to get the UI right
ntim: Are there things CSS can put in the top layer? I think it's
just APIs like fullscreen right now
<masonf> https://open-ui.org/components/popup.proposal.alternatives#alternative-css-property
astearns: We are at time
astearns: Has OpenUI discussed pseudo-class vs pseudo-element?
masonf: We resolved on pseudo-class :top-layer
astearns: What about pseudo-element?
masonf: Can take it back to Open UI
astearns: ok, going to close for today, but can bring it back soon
Received on Wednesday, 29 June 2022 23:29:43 UTC