W3C home > Mailing lists > Public > www-style@w3.org > April 2022

[CSSWG] Minutes Telecon 2022-04-27 [css-will-change-1] [css-paint-api] [css-backgrounds-4] [css-values] [selectors]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 27 Apr 2022 19:21:22 -0400
Message-ID: <CADhPm3sdrOzy_O6ROm1V9peDqYT08WYzs=bazUG3MYfNMrxvYA@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.
=========================================


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

This archive was generated by hypermail 2.4.0 : Wednesday, 27 April 2022 23:22:05 UTC