- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 27 Apr 2022 19:21: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.
=========================================
Will Change 1
-------------
- RESOLVED: Republish Will Change 1 as CRD (Issue #7177: Republish)
CSS Paint API
-------------
- RESOLVED: Add CanvasFilter to PaintRenderingContext2D (Houdini
Issue #1056: Add CanvasFilters to PaintRenderingContext2D)
Backgrounds 4
-------------
- RESOLVED: Remove <1d-image> from <image> for now, open a separate
issue to discuss it (Issue #2532: Issues with listifying
border-color)
CSS Values
----------
- RESOLVED: NaN escaping calc() tree is coerced to zero (Issue #7067:
Make top-level NaN be invalid at computed value time
instead of ∞)
Selectors
---------
- There was discussion around what would be referenced by the
proposed :modal pseudo-class (Issue #6965: Add :modal-dialog
pseudo-class). If it's things appearing on the top of the page,
:top-layer may be a more appropriate name.
- Concern was expressed about if the :modal name was going to be too
broad for an initial pseudo-class and if the property should
start specific and then create a generic as more use cases
develop. Alternatively, a broader name would allow clearer
combination with other pseudo-classes and future extension
without creating a lot of pseudo-classes.
- Discussion will continue on github and the group will continue to
engage with the OpenUI group on this topic.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2022Apr/0012.html
Present:
Rachel Andrew
Adam Argyle
Tab Atkins Bittner
David Baron
Oriol Brufau
Tantek Çelik
Daniel Clark
Emilio Cobos Álvarez
Elika Etemad
Robert Flack
Mason Freed
Chris Harrelson
Brian Kardell
Ian Kilpatrick
Vladimir Levin
Peter Linss
Alison Maher
Tim Nguyen
Alan Stearns
Miriam Suzanne
Lea Verou
Sebastian Zartner
Scribe: fantasai
Administrative
==============
astearns: Changes to agenda?
chrishtr: Would like to get to #9
astearns: OK, I put further down in agenda because nobody responded
in the issue
astearns: in the future, please add comment!
<chrishtr> By item 9 I meant https://github.com/w3c/csswg-drafts/issues/6965,
just double checking.
Will Change 1
=============
Republish
---------
github: https://github.com/w3c/csswg-drafts/issues/7177#issuecomment-1106662858
astearns: Resolution to republish CR?
TabAtkins: sure, yes, republish
astearns: Any additional changes we should make sure to get in?
TabAtkins: I don't know of any pending resolutions
TabAtkins: One feature request, otherwise only editorial stuff
astearns: Proposed resolution to republish Will Change 1 as CRD
astearns: objections?
RESOLVED: Republish Will Change 1 as CRD
CSS Paint API
=============
Add CanvasFilters to PaintRenderingContext2D
--------------------------------------------
github: https://github.com/w3c/css-houdini-drafts/issues/1056
iank: PaintRenderingContext2D implemented subset of
CanvasRenderingContext2D
iank: removed things that don't make sense in a paint worklet, e.g.
dom apis and text
iank: One oversight, probably mine, was that we didn't add the
CanvasFilters APIs
iank: allows to set e.g. filter blur 2px
iank: We've been shipping this, people have been using it
iank: it's part of CanvasRenderingContext2D standard
iank: so just want to add this interface to PaintRenderingContext2D
astearns: Any concerns with adding CanvasFilters?
astearns: There are other implementations of Paint API?
iank: Only prototype implementations
iank: so I believe that WebKit at one point had a prototype
implementation, also one in servo
iank: but that obviously not moving forward atm
iank: we're the only folks shipping atm
astearns: Might wait for smfr's input, but I'm OK adding to spec and
if necessary reopen issue
<TabAtkins> +1
<flackr> +1
fantasai: sgtm
RESOLVED: Add CanvasFilter to PaintRenderingContext2D
CSS Backgrounds 4
=================
Scribe: TabAtkins
Issues with listifying border-color
-----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2532
sebastian: Several years ago we resolved to add stripes() to let you
define several border colors
sebastian: Idea was to allow this to be used in other contexts, so we
introduced <1d-image> to Images 4.
sebastian: Now the feature is mostly complete; there's a PR ready for
the specs.
sebastian: fantasai asked what to do with <1d-image> in 2d contexts
sebastian: Idea was to also allow it in other 2d contexts, so adding
<1d-image> to the <image> type
sebastian: fantasai wasn't sure how that should be done. One idea was
to add a new function for 2d stripes
sebastian: But the idea was that we could have linear-gradient(...,
stripes())
<lea> Can someone link to the PR we are discussing?
<fantasai> PR https://github.com/w3c/csswg-drafts/pull/7029
fantasai: The original proposal is that we allow stripes() in 2d
contexts, and default it to "down" (like a linear gradient)
fantasai: I don't think it's that useful (you often want something
else), and it's not worth the testing/impl cost of doing it
for the limited case
fantasai: So if we *do* want the ability to do stripes()-like in 2d,
we should have that addressed specifically with a proper 2d
striping image, not this limited-direction 1d image
fantasai: Think it's more confusing than helpful otherwise
lea: Agree there's not much use in 1d-image in 2d contexts, primarily
debugging
lea: Note tho that we do have 0d images (colors)
lea: So feels a little odd we can use 0d and 2d, but not 1d
lea: Also don't think we should add a new 2d stripes function; the
gradients functions are already used for stripes and could use
stripes() for their gradient line
fantasai: I don't agree that lack of 1d is confusing
fantasai: 0d is fine - you don't need any additional params to make
it work
fantasai: 1d needs additional params - we have to *set* the direction
fantasai: For putting it in linear-stripes(), I don't think nesting
the functions is easier to read. I think it's better to
have a linear-stripes() or whatever, that's more like how
we do functions normally
sebastian: But we could use it for all the gradients
fantasai: Right, a linear-stripes(), radial-stripes(),
conic-stripes(), that's just the same first arg as the
gradient function but takes the stripes arguments after
fantasai: syntaxes are perfectly analogous
lea: Agree nesting isn't great, but reusing means you get all the
gradient controls for free
fantasai: Right, we'll just copy the first argument.
lea: Do you suggest we abstract it to a separate type? otherwise we
have to keep it in sync manually
fantasai: They're in the same module, we can do whatever we need.
This is editorial, we can do that if we need.
TabAtkins: We already have that problem for the repeating variants as
well
astearns: So I'm hearing two options - nested stripe() in gradient(),
or a separate gradient()
lea: One slightly weak argument - if we can use stripe as a gradient
line, authors can use a single variable for both borders and
backgrounds
astearns: You could put the args in a variable and then use them in
both
lea: You can but it's awkward, same as putting color args in a
variable so you can modify the alpha. Awkward
sebastian: We could also have a keyword that interprets the following
args as stripes
fantasai: Or just add a new function name
sebastian: But then we'd have to add 6 new functions
fantasai: That's not meaningfully different. We already have 2x3
variants of gradients, if they want stripes we can do
another set
<iank> Additional functions aren't particularly expensive from an
implementation POV.
lea: Note that what I was proposing was speccing the gradient line as
a 1d image, not as stripes() specifically
lea: I do think it's a little weird if we have a bunch of 1d images
that we can't use as a gradient line, since the gradient lie is
conceptually a 1d image itself
fantasai: I don't think of the gradient as being a generic 1d image
stretching function. It's for making gradients, which it
does. If we need different functions that do different
things, we can do that.
fantasai: If you wanna do something complicated you can use the
gradient functions, if you want stripes you can do stripes()
lea: This isn't mutually exclusive either
fantasai: I think we're bikeshedding syntax now, I just don't want
the 1d-as-2d to be in the initial PR
sebastian: So maybe leave that out for now, and only define it for
border and outline, which is the initial use-case
sebastian: can discuss 2d contexts in a separate issue
lea: Fine with not accepting, just need to define what happens
fantasai: Invalid
lea: Okay, that lets us change it in the future
astearns: So proposed resolution is to remove the stripes() as
<image> for now
<fantasai> Literally, that's what falls out of the spec if we don't
add it to <image>
astearns: Objections?
RESOLVED: Remove <1d-image> from <image> for now, open a separate
issue to discuss it
CSS Values
==========
scribe: fantasai
scribe's scribe: TabAtkins
Make top-level NaN be invalid at computed value time instead of ∞
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7067
TabAtkins: last week we discussed behavior of censoring NaNs when
they escape calc()
TabAtkins: previously specced as infinity
TabAtkins: discussion seemed to conclude that censoring to zero would
be acceptable
TabAtkins: Since then, comments in issue supporting that
interpretation, for a variety of good reasons
TabAtkins: This works well enough for my purposes, so suggest to
resolve that NaN resolves to zero when escaping a calc()
tree
iank: can you elaborate more?
iank: Inside a calc() tree, if you've got something relatively nested
that has 0/0 or something that will be a NaN
iank: is that where it is coerced to zero?
iank: or will it propagate up
TabAtkins: it propagates up, infecting most of the tree following
IEEE rules
TabAtkins: almost the same as JS also
TabAtkins: as soon as you escape the top-level function, properties
don't know how to deal, so turn it into zero
iank: ok, thanks
<tantek> sounds reasonable
<lea> +1
RESOLVED: NaN escaping calc() tree is coerced to zero
Selectors
=========
Add :modal-dialog pseudo-class
------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6965
chrishtr: We discussed whether or not to have pseudo class to have
styling of dialogs when open and modal
chrishtr: everyone in thread seems to agree
chrishtr: Questions raised about putting things in the top layer
otherwise
chrishtr: think we should put that aside
chrishtr: for this specific use case, styling open modal dialogs,
pseudo-class makes sense
chrishtr: Also question of should there be a generic pseudo-class for
top-layer
chrishtr: Don't think makes sense for a lot of things
chrishtr: First, very generic
chrishtr: Second, ???
chrishtr: Third, not necessarily even top
chrishtr: so :modal-dialog or :modal seems best
chrishtr: This would be similar to existing :fullscreen pseudo-class
chrishtr: If we have popups or tooltips, we can add pseudo-classes
for those as well
astearns: Tantek in IRC wanted to know if this was discussed in the
OpenUI group
masonf: Yes, we've discussed this a lot, and also talking about a
similar pseudo-class for pop-ups
masonf: It seemed to me at the beginning to have a single
pseudo-class for the top layer, though I see the points
raised here
masonf: and discussed in OpenUI
<tantek> I don't have a strong/informed opinion either way, just
making sure that sync-up had occurred and there was some
degree of mutual consensus
masonf: Concern that as we add more and more things to top layer,
will have more and more such pseudo classes
masonf: but maybe that's OK
<tantek> thanks masonf
emilio: I wanted to say that for popups, may even make sense to just
use :modal as well, if we're not going with :modal-dialog
chrishtr: That was one of the reasons suggested to use :modal rather
than :modal-dialog
chrishtr: for things that are truly :modal, can add to its semantics
ntim: I think it's easy to implement, but I don't see the appeal of
adding :modal pseudo-class because you can technically use the
[open] attribute to target the state
ntim: It's very rare for a developer to trigger the same dialog in
both modal and non-modal state
TabAtkins: Part of issue was needed to expose to UA style sheet, and
if exposing to UA stylesheet might as well expose to
authors as well
astearns: Why not use [open]?
<tantek> +1 TabAtkins to expose "modal" to the UA stylesheet
TabAtkins: Only tells whether opened or not, not whether open modally
TabAtkins: and we need to add UA stylesheet rules specific to modal
case
<argyle> https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/renderer/core/html/resources/html.css;l=1400;bpv=1
ntim: [missed]
masonf: 2 things, to the last point we did discuss also the open
attribute for popup and decided it was a bad pattern, so
moving to pseudo classes for all of these
masonf: also because we're going down the road to make specific
pseudo-classes per type of thing that goes into top layer,
would vote against :modal
masonf: :popup:modal vs :popup:not(:modal) is weird
masonf: I think we should give a more specific name to dialog
argyle: I like the idea of a single name
argyle: why not :top-layer
argyle: sounds like what it is
<tantek> I'd tend to agree with masonf's reasoning, and there's the
risk that authors using a general :modal for just dialogs
would errantly apply to future "modal" things and perhaps
constrain our future compat
argyle: Top Layer holds a pseudo version of these, but dom node is
somewhere in the tree, and pseudo-class is on the new magical
one, so I think that's an interesting distinction here
argyle: if we do expose this pseudo-class, what *can't* be styled on
it? z-index tricks? top layer's job is to manage order
argyle: I think we're just talking about the name now
argyle: but what can't be put there is the question I'd like to ask
astearns: Since we're not close to agreeing on the name yet, let's
push out question of what will apply to the pseudo for this
TabAtkins: That does have a simple answer, actually. Pseudo-classes
don't have restrictions
TabAtkins: what modal dialogs might pay attention to is a different
question
masonf: That said, what TabAtkins said is technically true, but we
need to resolve first on whether the pseudo-class applies
only to dialogs or can also apply to other things
astearns: I thought last comment, you thought it wouldn't apply to
anything else, that wouldn't be other things in the future
masonf: There are 2 approaches, one is to make a generic pseudo that
would apply to things, e.g. popup, that goes in top layer
masonf: One, to make a general pseudo
masonf: Two, make a specific pseudo for each type of thing
masonf: talked about fullscreen, then modal dialogs, then popups
masonf: Thread has been going to different names to different things,
but need to resolve that
TabAtkins: Just want to agree with Mason, thread leaned towards
separate things for each thing in the future, because not
sure about extensibility question, and going generic early
can be a problem because can write selectors that are too
generic
TabAtkins: so I think individual pseudo-classes is a better approach
TabAtkins: For example, a future thing wanting to target its
modal-ness might want a functional pseudo-class
<tantek> +1 specific names for each thing
<chrishtr> +1 to individual cases
TabAtkins: For this thing, better to design specifically for modal
dialog case
bkardell: So, I've been in a number of conversations about this, and
I quickly scanned through the issue because some of the
conversation around do we actually need a pseudo-class hit
on for me
bkardell: I don't think we've discussed if we can use media query for
this?
bkardell: Could have media query for top layer, when top layer is
shown and relevant, then can just use regular selectors
bkardell: Any reason that's a bad idea?
fantasai: I think you want to know *which* element is in the top layer
fantasai: Say you have five videos on the page, and one is full
screen, you wanna know which one it is, but MQ can just
tell you that *something* is full screen, not which one
fantasai: Same to dialogs
fantasai: My q was for... "modal" isn't about being in the top layer,
it's about being modal and not accessing other things
fantasai: I'd prefer we not confuse this with "being in the top
layer" concept
astearns: So that sounds like a vote for a specific :modal-dialog,
rather than :modal or :top-layer
fantasai: Dunno about :modal but no to :top-layer
<ydaniv> +1 potentially there could be more than one dialog (:
emilio: Related to what fantasai said, multiple modal dialogs can be
open at the same time, and only one is interactable at a
given time
emilio: but UA style sheet is styling all of them
emilio: not just the last dialog opened in this way
emilio: so already a bit of distinction, that all dialogs open with
openModal, they are in top layer but not necessarily ???
<bkardell> 'active-modal'
TabAtkins: I don't think she's saying that opening nested modals that
it wouldn't apply to stuff under the stack
<TabAtkins> Basically it's still opened "as modal", even if
technically we're in a mode allowing interaction with a
nested thing now
astearns: I think what I'm hearing is a growing consensus for a
pseudo that targets the dialog specifically not its
top-layer-ness
astearns: and for something that notes that it's a modal dialog, not
some other modal or top-layer thing
astearns: sounds like we want to choose :modal-dialog?
masonf: I think pseudo should only apply to dialog, and only to the
top layer
masonf: So if three opened into top layer, only top one is modal in
the sense that can interact with it, but all match the pseudo
class
<lea> dialog:modal-dialog is a bit clumsy
<TabAtkins> lea, don't do that then. `:modal-dialog` is sufficient
<bkardell> the top top top layer one :)
fantasai: I don't think "modal" means the top active one, it means
mutually exclusive, top one happens to be active
plinss: We have other pseudo-classes :active
plinss: Could make a combo of states to get a full description
plinss: Also, pseudo-classes are supposed to represent state
plinss: I'm not thrilled with :modal-dialog if can go in and out of
being a dialog
plinss: If it can't change the state of being a dialog, then don't
see why pseudo-class
emilio: Discussing whether :modal or :modal-dialog
<lea> +1 to plinss
<bkardell> :modal and :modal:active is what plinss is suggesting?
<fantasai> +1 to plinss
TabAtkins: Argument against that is we're not certain that other
things that can be modal would match this pseudo-class
TabAtkins: and concerned that people would write :modal without
specifying dialog:modal, and in future might break pages
if we extend to other things
plinss: Solve it with education
TabAtkins: Solve right now with a restrictive name
<masonf> +1 to tabatkins. Clear naming is the best documentation.
astearns: If in the future, have multiple things, where can have
multiple thing, we can add :modal
plinss: I would hate to get to a point where we have :modal-foo
:modal-bar :modal-baz, if we have concept of modalness, let's
have that be the pseudo-class
<bkardell> +1 to what plinss just said
<lea> another +1 to what plinss just said
plinss: If need to distinguish, use other selectors to make more
specific
astearns: OpenUI didn't want to do that
plinss: They might be utilitarian about that. If the thing you care
about is being in top layer, have a pseudo-class for that. If
care about being modal, have a pseudo-class for that. Don't
conflate things, not have one pseudo-class for everything.
Let's have one pseudo-class for each thing
plinss: not one pseudo class for being modal and top layer and dialog
all at once
<TabAtkins> I've already made my argument against this exact thing
and don't think it would be useful to repeat myself again
* tantek waits for what masonf will say, however, we can always add
:modal later, whereas if we add it now and authors use it
with the assumption that it means dialog then it prevents us
from using it more generically (basically the argument Tab &
made earlier in chat)
emilio: All top-layer dialogs are modal, so for dialogs they are
interchangeable, but for popups it would not be
emilio: I don't know, I just wanted to say that we can choose a more
specific name, and if need generalize can always alias
pseudo-classes
emilio: We've done this in the past with prefixes and stuff
emilio: parse :modal-dialog same as :modal in the future
emilio: But again, I don't care too much about the name. I would be
fine with :modal
<TabAtkins> (I'm just fine with a profusion of :modal-* things in the
future *if we end up with that*; it's really not an issue
whether authors spell their selectors `dialog:modal` or
`:modal-dialog`.)
<TabAtkins> (But *if we end up with that*, yes, we can just add
:modal at that point.)
masonf: +1 to what emilio said
masonf: Popups can be shown, or not shown, or in the top layer
masonf: dialogs are modal and top layer at the same time
masonf: So seems we're veering towards more generic pseudo-class
masonf: if we're choosing one of those two, let's go with top-layer
since that would apply to pop-ups and then we can reuse it
plinss: Guarantee that dialog not modal?
TabAtkins: modalness and toplayerness are tied together for dialog,
but potentially not for other things
plinss: Maybe form of dialog that can be in the top layer but not
modal, right?
masonf: then pseudo class should be :top-layer
<argyle> +1 :top-layer
<lea> +1 :top-layer and keeping concepts decoupled
plinss: But that's my argument against conflating these things. Just
because you expect to be :modal and :top-layer at the same
time, don't have pseudo that means both at the same time
masonf: If want to go that route with :modal, then let's have :modal
and :top-layer, so both would apply to dialog and can re-use
those concepts for other things like popups
plinss: That was precisely my point
plinss: different pseudo-class for different states
<TabAtkins> My big point here is that any generic design is making
some big assumptions about what will be useful in the
future, and what sort of things we'll design in the
future. There are zero guarantees here!
<bkardell> can we just take that back to openui, I feel like this is
reasonable and people will be good with it
masonf: I'm OK with either one
<TabAtkins> Let's backfill as needed in the future and just solve the
narrow cases now, in a way that doesn't *block* good
backfill names.
chrishtr: I think you made a good point that pseudo-classes should
have a single meaning, and should be clear
chrishtr: I think ?? meets that bar, don't think :top-layer is
immediately needed atm, so I suggest we attempt to resolve
on :modal for now
emilio: I agree on trying to go for :modal for now, because that's
what we need for UA style sheet
emilio: also now I think about it, nothing preventing you from
calling fullscreen on a dialog element
emilio: so that would create a dialog that's top layer, but not modal
emilio: ...
<chrishtr> good point about fullscreen
<chrishtr> :modal is good I think
<masonf> That would match :fullscreen
<chrishtr> Modal is a very clear UI concept
<chrishtr> same with fullscreen - it's also very clear as a UI
concept (and state)
emilio: Seems we need a selector for modal dialogs, at least for UA
stylesheet. If we want to expose for authors, that's great.
emilio: if we want :top-layer in future, that's fine, but different
issue
emilio: so think I'm with chris here
<argyle> i dont think a dialog can go fullscreen
<masonf> Modal is not super clear to developers. On popup, we're
constantly discussing why there isn't a modal popup.
<masonf> argyle you're right, it's prohibited by spec.
<TabAtkins> I just don't like genericizing from 1 example.
<fantasai> +1 to :modal given argument lately
astearns: So back to just :modal, but some people on IRC that were
really happy with :top-layer version, anyone want to speak
against :modal
TabAtkins: I'm still against :modal by itself, don't want to block
future use of :modal, by choosing overly generic name now
<tantek> +1 TabAtkins let's not genericize from a single example.
Premature abstraction and all that.
<argyle> +1 to :top-layer, not sure about :modal
masonf: +1 to TabAtkins
masonf: Already confusion with popup
plinss: I don't think an overly generic name is overly generic if we
constrain its meaning to what it really means
plinss: if we have :modal, it describes modalness, period.
plinss: It is generic, and maybe we only have one use for it now, but
we know when we have a future use of it
<chrishtr> +1 to plinss
<masonf> https://github.com/openui/open-ui/issues/325
TabAtkins: People will use it for that one thing now, and it will be
a problem now
TabAtkins: Tantek points out :hover only applied to links, and when
started applying to everything was a problem
<tantek> I guarantee web authors will be lazy and not bother to scope
:modal to only dialogs to start with.
<TabAtkins> yup to tantek
fantasai: This is different from :hover, because in that case we had
:hover restricted to one element even though hovering could
apply to any element, and when we expanded to allow all
elements it was a problem
<chrishtr> Good point fantasai
<tantek> I also agree with fantasai's distinction of the two cases
fantasai: but here we're proposing :modal to apply to *all things*
that are modal, which happens to currently only be one thing
fantsasai: It will never apply to other things that exist now,
because none of them are modal
fantasai: it might apply to new things in the future that are modal,
that's it
fantasai: so it's a different situation
<TabAtkins> Note that "being in the top layer" is *not* what we need
for the UA stylesheet, so it wouldn't solve the original
problem.
<emilio> argyle: you're right:
https://fullscreen.spec.whatwg.org/#dom-element-requestfullscreen
has a "not dialog" check
<TabAtkins> Oh weird that fullscreen specifically avoids that
masonf: It sounds like we're going towards a generic concept, dialogs
have both modalness and toplayerness
masonf: posted concept about modalness being a spectrum, but
toplayerness is binary
masonf: if we need one, we should use top layer
astearns: Way out of time, take it back to the issue, but I think
this was productive discussion.
Received on Wednesday, 27 April 2022 23:22:03 UTC