W3C home > Mailing lists > Public > www-style@w3.org > March 2019

[CSSWG] Minutes San Francisco F2F 2019-02-25 Part IV: Selectors, Pseudo Elements, URL modifiers for image loading [css-selectors] [css-pseudo]

From: Dael Jackson <daelcss@gmail.com>
Date: Tue, 26 Mar 2019 22:28:26 +0300
Message-ID: <CADhPm3sWY6Mgu8QL-tcL4X0_xbxPtS56A_VnFo=sZKL+wO5pKg@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.


  - RESOLVED: Drop individual invalid selectors from selector lists in
              *all* selector functions that take such lists, *except*
              for :not() (Issue #3264: Let :is() have better
              error-recovery behavior than normal Selectors)
  - RESOLVED: Open up a new WICG project for this selector and it's
              sub-issues. (Issue #2296: Selectors for textish and
              buttonish elements)
  - RESOLVED: Push this out to Level 5 (Issue #397: <label> elements)


  - RESOLVED: Return null provisionally and open a TAG review issue.
              (Issue #3603: Should Element.pseudo("unknown") be an
              error or return null?))
  - Issue #2960 (New generated content pseudo :between/:separator)
      seemed to be a small use case of a larger problem of developers
      looking to style things on the page that don't exist in the
      content. The group will continue to think on this broader issue.

URL modifiers for image loading

  - RESOLVED: Unknown <url-modifier>s get silently ignored (rather
              than invalidating the function).
  - The group will look to solve several issues (#1603, #2095, #2994,
      #3659) around image loading by aligning CSS's support with
      HTML's image loading support, via url modifiers.


Agenda: https://wiki.csswg.org/planning/sf-2019

Scribe: TabAtkins


Error recovery for :is() and :not()
  github: https://github.com/w3c/csswg-drafts/issues/3264

  ewilligers: We resolved we'd like to have error-recovery for :is()
              and :where(), but unsure about :not().
  ewilligers: I have use-cases showing that :not() is used frequently,
              so we probably don't want to change the meaning.
  ewilligers: Do we want :nth-child() or :nth-last-child() have
  fantasai: :nth-child() should probably have the same error-recovery
            as :is()

  fantasai: I think it would make more sense with compound, not
            complex selectors
  fantasai: The big question for :nth-child() was compound vs complex
  fantasai: people want :nth-child(An+B of <selector>)
  fantasai: If dropping support for combinators makes it easier,
            would be good to get it implemented faster. Things like
            zebra-striping non-hidden rows is a major use case that's
            not currently solved otherwise.
  ewilligers: I think webkit already shipped complex selectors in
  dydz: I'm looking in the WK code

  fantasai: Emilio asked why we need selectors in :nth-child()
  fantasai: Say we have a list of items, I want to color their
            backgrounds alternately
  fantasai: But some of them are hidden; they're display:none
  fantasai: Counting is based on sibling list. If you hide 3rd one,
            2nd and 4th will both have the same color
  fantasai: So want to count after filtering
  emilio: Whew, that's gonna be slow. We have a lot of caching already
          to make :nth-of-type() fast.

  ewilligers: I confirmed that Safari supports :nth-child(even of
  fantasai: My main concern is if other impls are more likely to
            implement without complex selectors, getting even
            compound-selector interop would still be great.
  emilio: I think impl-wise, not supporting complex selectors is
  TabAtkins: Unless we recursively pass down the compound-only
             restriction into :is()/etc, you're at full power anyway.
  fantasai: Maybe that's reasonable to have that sort of restriction.
  fantasai: We'll just say Safari supports L5 of selectors, and L4
            doesn't accept combinators
  <tantek> agreed. reasonable restriction

  emilio: Did we decide on how the new error recovery behavior
  emilio: Did we decide about serialization of invalid selectors in
  TabAtkins: I didn't think we were doing anything in particular?
  ewilligers: I thought we'd just drop them.
  emilio: What if they're all invalid?
  ewilligers: You just get :is(). A little weird with
              :nth-child(even of), tho.
  ewilligers: What about parsing of weird stuff? Extra close brackets,
              what happens?
  TabAtkins: Syntax already handles brackets correctly. We just split
             the tokens on top-level commas, then interpret each chunk
             as a selector.

  fantasai: So back to the issue, :is() and :not() take a list of
  fantasai: Currently any invalid selector invalidates the entire
            selector list.
  fantasai: Because we now have these functional notations that
            creates some scoping, within :is() we can just ignore in
            the invalid selector, but still process the rest.
  fantasai: So we're gonna resolve that within :is(), we ignore
            invalid selectors.
  ewilligers: And :where(), :nth-child(), :has(), etc.
  fantasai: But not in :not() - the whole thing will invalidate if any
            are any invalid.
  gregwhitworth: I think it's weird to have :not() work different. I
                 get the percents making it hard tho.
  AmeliaBR: I do use :not() as an @supports for new selectors...
  AmeliaBR: e.g. :not(:valid) means you support :valid, and this
            selector selects things that are not valid
  TabAtkins: I was going over the boolean logic for :not()
             invalidating just parts too this morning, and was getting
             really confused...

  RESOLVED: Drop individual invalid selectors from selector lists in
            *all* selector functions that take such lists, *except*
            for :not().

Selectors for textish and buttonish elements
  github: https://github.com/w3c/csswg-drafts/issues/2296

  fantasai: Use-case seems quite reasonable
  fantasai: People wanna style things that look like buttons as a set
  fantasai: But that set isn't clear, and it's a long list that
            changes over time, maybe across OSes, etc.
  fantasai: So having a selector that classifies inputs as "buttonish"
            and "text inputish", so when you style buttonish you can
            style them all at once to look the same
  fantasai: That seems reasonable to want.
  <bkardell> aliases would help here, but also they wouldn't cover
             'new' things that get/got added
  TabAtkins: I've been in favor of this for a while.

  emilio: textarea counts as inputish?
  fantasai: Yes

  AmeliaBR: Complex things - where text and button are both *parts* of
  AmeliaBR: Pseudo-element to target pieces, maybe?
  AmeliaBR: And other issue is which groupings makes sense.
  AmeliaBR: I think there is consensus on textish and buttonish, and
            maybe popup-ish
  fantasai: I think for popups UAs typically categorize those one way
            or the other, depending on whether it's styled to look
            fundamentally like an input or like a button
  TabAtkins: What's popup?
  AmeliaBR: Like <input type=color>, raising a popup.
  fantasai: The UA has to categorize, but for those with some options,
            UA should classify according to how they in particular do
  fantasai: Compound things are complicated.
  TabAtkins: I think for things like file input, when it's a
             text+button combo, it just matches neither.

  hober: How does a custom element say it's buttonish or textish?
  TabAtkins: DOM is just now discussing API for custom elements to
             hook into forms, we should get into that convo.
  bkardell: Was fantasai suggesting an ARIA role=button is buttonish?
  fantasai: That's a possible way to handle the style mapping for
            custom things, yes.
  fantasai: Unsure if it's a good idea, but it's a source of input.
  AmeliaBR: I would say don't do that. If the purpose is to target
            elements with a certain set of default browser styles,
            then the aria-role doesn't apply.
  AmeliaBR: And it goes against the thing that ARIA is for custom
            widgets that don't fit into the browser default stylings.
  <astearns> +1 to role=button isn't buttonish for this discussion
  bkardell: Yeah, what's the intent is the question.
  fantasai: One of the big things is getting styling that author
            doesn't know, because it's from the UA. For custom
            elements the author should know.

  AmeliaBR: Another issue for this is verbosity, plus it's not forward
            compatible. If a new type gets added it could be
            buttonish, but it won't be in your selector today.
  fantasai: And platform conventions can vary.

  tantek: I realize there's a point you can argue either way, but I
          think this is styling according to the browser's default
          styling, not the semantics.
  tantek: I think the instances AmeliaBR and fantasai pointed out are
          key here.
  tantek: One input could be texty or buttony on different browsers,
          that's presentation, not semantic.
  astearns: Does that suggest the name should be :browser-button, etc?
  tantek: Not gonna bikeshed, just contributing to narrowing what
          we're solving

  bdc: I find the intent pretty obscure to be honest.
  bdc: The fact that we're avoiding a few selectors, or classes, isn't
       super compelling.
  bdc: Forcing browsers to make the decision on whether it's buttonish
       or textish is weird.
  [discussion on whether an input exists that could be ambiguous
      between the two categories]

  bkardell: I think if you look around 2008ish in the archives, you'll
            find discussion about this sort of thing.
  bkardell: I think maybe Selectors, when it was still in CSS main,
            included some of these things? A button pseudo?
  bkardell: jQuery definitely supported these things, I think because
            it was in the spec at the time.
  <AmeliaBR> jQuery `:button` selector: https://api.jquery.com/button-selector/
  bkardell: Every designer I know that tries to enforce this style
            runs into this problem.
  bkardell: We landed on the possibility of solving it with Tab's CSS
            Aliases thing.
  bkardell: Important to not create something that's bound too tightly
            to make tiny categories.
  hober: I presented a form-submission API a few years ago, and the
         current proposal looks a lot like it. From what I recall it's
         not tied to the element being a custom element.
  bkardell: Yeah, just think it's important to consider the use-cases
            as holistically as possible, to make sure it gives authors
            a good experience.

  astearns: So think I'm hearing *general* agreement on this, with
            some skepticism about whether it will end up being useful.
  AmeliaBR: I don't usually say this, but this might be worth throwing
            it to WICG.
  AmeliaBR: On that thread lots of people active in CSS communication/
            education, but not in standards. If we could convince Keith
            etc. to draft up some ideas, might be a useful way forward.
  <bkardell> that seems good
  TabAtkins: I support that.
  fantasai: I think on the CSS side it's just a few paragraphs. On the
            HTML side they'll have to define exactly how it applies.
  TabAtkins: And there will be a DOM side, to opt your elements into
  fantasai: If we don't have the extensibility, is it still worthwhile
            to have this in CSS? The CSS side is just like 15 minutes
            of work.
  astearns: We'd still need the HTML side, right?
  fantasai: That's more clarification, I'd think.

  RESOLVED: Open up a new WICG project for this selector and its

<label> elements
  github: https://github.com/w3c/csswg-drafts/issues/397

  AmeliaBR: I brought this up on WHATWG because the relevant text is
            in HTML, but they threw it back to CSS.
  AmeliaBR: Often you want to do some styling on the label or on
            gencon that depends on :required or :invalid or :focus on
            the label's associated input
  AmeliaBR: Right now the only way to do that is by modifying your DOM
            structure so the label is a following sibling of the input.
  AmeliaBR: Having to modify your DOM to do styling is iffy, there are
            some cases where this can't work.
  AmeliaBR: And it also means you can't use the implicit association
            of label with child inputs; you have to use IDs, which can
            cause problems in dynamic content.
  AmeliaBR: So the suggestion was that the <label> should reflect the
            form-related pseudos, and :focus/:hover, of the associated
            form element.
  AmeliaBR: Last time this was discussed there were some performance
            concerns, but labels already have a DOM association (you
            can chase a DOM property to see the associated input)
  AmeliaBR: As I recall there is something in the HTML spec about how
            focus or hover already propagates in a certain way...
  <xfq> WHATWG issue: https://github.com/whatwg/html/issues/1632
  <astearns> some concerns from bz:

  myles: People use labels and form controls everywhere already, is
         this gonna break anything?
  AmeliaBR: If you've got `label:invalid` that currently does nothing,
            then it could be an issue.
  AmeliaBR: Or perhaps some of the more common pseudos
  TabAtkins: I think :hover is the most likely to see some new stuff
  emilio: Eh, reasonable to see `form :invalid`, would trigger more.
  emilio: And the fact that labels can be anywhere in the DOM (current
          state propagation, like to fieldset, is just parent/
          ancestor-based), talks to BZ's concern about this being one
          more thing to slow things down.

  <AmeliaBR> `label:for(:required)`
  AmeliaBR: On the perf issue, it's worth remembering that labels and
            inputs already have DOM properties that link to each
            other. But they probably aren't used much, so they might
            be slow getters, I dunno.
  emilio: Also worth noting that CSS needs a 2-way link; label->input
          for the selector, but input->label for invalidation
  <AmeliaBR> Re DOM APIs, labels have a `control` property, while
             labelable elements have `labels` (node list)

  scribe: fantasai

  TabAtkins: In general I'd say resolve to reject at this point, since
             still implementer resistance on performance grounds.
             Which makes me sad because I've run into these exact
  <bkardell> can we note the "waves hands and invokes potential
             houdini solution" in the rejects notes?
  astearns: Not really a rejection, just no implementer interest yet
  TabAtkins: Yeah, not going in as expected feature of the spec atm
  AmeliaBR: If we do it in the way Tab proposes, to avoid any
            back-compat issues with :for() pseudo
  AmeliaBR: So there's a CSS issue and a WHATWG issue
  AmeliaBR: CSSWG says if we do this, this is how we do
  astearns: And try it out with Houdini
  TabAtkins: I still have to finish TypedOM, but custom selectors will
             probably be next
  hober: There's the AOM work to do association without IDREFs, using
         direct assignment. Should probably tie in with that
  <hober> https://github.com/WICG/aom/issues/2
  TabAtkins: I recently had discussions with people about solving
             problems, can we have a selector associated with a map
             that I have created
  TabAtkins: Seems like would solve a lot of problems
  TabAtkins: Should be part of houdini work

  RESOLVED: Push this out to Level 5

Unknown pseudo() arg
  github: https://github.com/w3c/csswg-drafts/issues/3603

  TabAtkins: We can either go with JS likes to signal errors for error
  TabAtkins: or DOM likes to return nulls
  TabAtkins: I believe we should return a null for this object.
  TabAtkins: fremy made a good use case for being able to easily test
             whether a pseudo is supported in an element
  TabAtkins: Throwing is more verbose in JS
  astearns: There's also question of does this element support this
  TabAtkins: https://github.com/w3c/csswg-drafts/issues/3603#issuecomment-463287002
  TabAtkins: I think this is fine.
  TabAtkins: Null will immediately throw an error if you try to access
             properties on it, so you'll get an error if you don't
             check anyway
  TabAtkins: Gives you same behavior in practice, but null gives you a
             more useful boolean result in practice
  * fantasai wonders what gCS(unknown-property) returns

  myles: ...
  TabAtkins: querySelector() throws and it's really annoying
  myles: Just pointing out the fact that it throws
  fantasai: If you and fremy agree, seems OK to me
  fantasai: We can also ask the TAG if they have an opinion on this
  astearns: Not sure it's that important
  <bkardell> +1
  fantasai: It's about consistency across the platform. TAG is good
            for that.

  RESOLVED: Return null provisionally and open a TAG review issue.

New generated content pseudo :between/:separator
  github: https://github.com/w3c/csswg-drafts/issues/2960

  fantasai: I don't wanna do another generated content pseudo.... :(
  TabAtkins: Gonna discuss the problem
  TabAtkins: People want to address generated content siblings of an
  TabAtkins: There's a few variants that people want, but usually you
             want to address siblings, and before/after children
  TabAtkins: Sometimes it's about wrappers
  TabAtkins: There appear to be several different possibilities to
             address this

  TabAtkins: First one, is a ::between pseudo
  TabAtkins: It's like ::before/::after in that it creates children of
             an element. They sit between the children rather than
  TabAtkins: Solves problem of ordered list with separators
  TabAtkins: ul::between { content: " | "; }
  TabAtkins: Right now have to be careful about not styling last
             element or first element or whatever.

  TabAtkins: Next one is ::contents, which is a wrapper element around
             all of the real children.
  TabAtkins: This has a number of use cases. People want extra
             wrappers and have asked for this before.
  TabAtkins: Have to do it by putting more elements in the DOM
  TabAtkins: Can be used like ::between in some cases, if you set the
             actual element to be 'display: contents'
  TabAtkins: and then style the ::contents instead of the element

  TabAtkins: Next one is ::parent/::wrapper, inverse of ::contents
  TabAtkins: Creates a pseudo outside the element. More complicated
             wrt inheritance, because it flows uprward from
             originating element

  TabAtkins: Last suggestion is ::outer-before/::outer-after. Creates
             siblings of originating element.
  TabAtkins: travels sideways

  TabAtkins: I think we should not have all of these. Maybe one of
             these. Maybe none of these
  TabAtkins: 'display: contents' makes some of these easier
  TabAtkins: Question is do we want to do any of these, and if so
             which one?

  fantasai: I really don't like the way ::contents requires hiding
            the element itself
  fantasai: This has bad cascade ergonomics
  fantasai: ::between seems simplest
  fantasai: solves some use cases very cleanly
  <fantasai> The ::contents solution affects how every part of your
             stylesheet interacts with this particular element. You
             want to solve this separator problem in this corner of
             your style sheet, but because you do it by hiding the
             actual element and moving all styles to the ::contents
             pseudo, every other part of your style sheet need to know
             that it has to style the ::contents pseudo of that element
             instead of the actual element.
  <fantasai> This is fragile cascading and bad ergonomics for the
  <tantek> Cascading is already too hard for authors, I tend to agree
           with fantasai that this would make the model worse (harder)
           for authors to predictably use / style etc.

  emilio: Can we agree that whatever we do, that doesn't affect
          inheritance of the children? If you do ::wraper { color:
          green; } doesn't affect children of the element
  emilio: Because ::first-line has that weird thing and I prefer not
          having it

  dydz: So the problem is that you had that horizontal list and you
        wanted separators, and you wanted vertical bar or character,
        and currently the person is saying there's no easy way to get
        at every other element, don't want to put a bar before the
        first one and not after last one
  fantasai: That's part of it, it's nicer that it's easier to express.
            But the main problem is existing ::before/::after is child
            of the item, but you want a sibling of the item.
  dydz: Why can't you use ::marker?
  TabAtkins: Markers are also children
  TabAtkins: They're inside the list item. If I put a border around
             it, it'll include the marker
  myles: So you want a sibling
  TabAtkins: Yeah, at least in the box tree

  jensimmons: To dydz's point, people who write CSS have a workaround
              for the specific case in the thread
  jensimmons: but when we talk about possibility of creating a new
              pseudo element
  jensimmons: My brain starts spinning about all the dissatisfactions
              we have about this
  jensimmons: Sometimes we wish we had much more than ::before/::after
  jensimmons: Sometimes we wish we had ones that were siblings
  jensimmons: If we go down this road, think about all the ways that
              we want to have pseudo-elements, that's great.
  jensimmons: But let's come up with something that's robust and
              elegant, and solves this use case without creating new
  jensimmons: The scope of this problem is too small. It's a hint to a
              bigger scope. Coming up with a quasi-hack that solves
              this one thing is not as robust or complex as what we
              really need
  futhark: What Jen is saying is, ::before and ::after can be same
           alias of ::between?
  fantasai: Child list of an element is ::before, first child,
            ::between, second child, ::between, third child, ::after
  <dbaron> We had something like this before, but I think concluded we
           wanted XBL (or its successor) instead.
  jensimmons: Wouldn't be between, would be something else. You could
              have as many as you want. Like 17 of them. could
              determine if children or siblings
  jensimmons: We have gaps in flexbox and grid, another way would be
              to style gaps or empty grid cells
  jensimmons: would allow authors to style those things without them
              being real

  <bkardell> would it make sense to try to tackle the definitions
             there in houdini?

  myles: General solution to boxes is really interesting. But we don't
         want to go so far and make a whole DOM in CSS.
  myles: A competing proposal that is more powerful and general would
         be interesting, would want to hear about it.
  jensimmons: Most common case for pseudos that are siblings is
              decorating empty grid cells without putting empty markup
              in the DOM
  TabAtkins: That one we definitely need to solve, I agree.
  TabAtkins: That one is easier because it doesn't require where to
             insert between elements, can be a pile of ::befores
  TabAtkins: I fear that a general solution would just re-implement
             the DOM, though.

  fremy: I was going to say, I feel like in what we provide in CSS, I
         would be very glad if we have ::between which is reasonable
         for most use cases
  fremy: If you want custom boxes, use Houdini
  fremy: If you need 17 boxes, you need specific stylings for each
  fremy: 17 random boxes is not useful
  fremy: Grid is a good example of where we can describe this, but in
         the general case I think it will get more and more obscure
  <dauwhe> https://www.w3.org/TR/2003/WD-css3-content-20030514/#inserting0
  fremy: But if we do decoratively in CSS, seems nice, ::between is
         very similar to what we already have and it solves a lot of
         cases that people have
  fremy: Having something simpler solution is better
  fremy: I think ::between is the best way to solve this case. If you
         need more complex, Selectors is maybe not the right solution.

  TabAtkins: We're talking about boxes, but it's about elements.
  TabAtkins: And custom layout is about fragments, not boxes.
  TabAtkins: Let's look more into stuff.
  TabAtkins: Jen brought up more possibilities, we should pay
             attention before tackling this.

  jensimmons: The need is to have a way to lightweight put styling on
              things, like dividers between things or bg colors on
              particular grid cells
  jensimmons: Want to do that in an elegant way, not limited to one or
  jensimmons: We've been using ::before/::after. We're reaching limit
              of those hacks.
  jensimmons: I don't want to solve one use case. I want to solve the
              systematic problem at the right level.
  jensimmons: I don't think it's just about lines between navigation
              elements, I think it's styling things on the page that
              don't exist in the content.
  <bkardell> wonder if we can be careful if/when we do that about
             whether generated text winds up exposed to the
             accessibility tree too

  dauwhe: I run into this all the time. We want multiple borders in my
          world. Just nest a bunch of divs.
  myles: Which is contrary to the philosophy of CSS.
  tantek: That feels a little different than what Jen was talking about
  tantek: Jen was talking about ways to style the negative spaces in
  fantasai: Wrt multiple borders, we should solve that by actually
            having multiple borders.
  astearns: Sounds like we're done for now, keep discussing later.

URL modifiers for image loading
  Scribe: TabAtkins
  github: https://github.com/w3c/csswg-drafts/issues/1603

  AmeliaBR: So there are several modifiers that exist in HTML image
  AmeliaBR: background-images don't need crossorigin info, so if it's
            the first thing it sees, browser fetches it without
  AmeliaBR: If you then use it for something else that *does* care
            about CORS, browser has to fetch a second time.
  AmeliaBR: Or it just gets reused and errors.
  AmeliaBR: Both are suboptimal.
  AmeliaBR: Can get around it today by adding a <link rel=preload>,
            but then need to alter markup to adjust CSS.
  AmeliaBR: So having a way to indicate in CSS that something should
            be requested with crossorigin permissions for later would
            be useful.

  tantek: I agree completely with the use case and with the more
          general use case, that everything you can tweak about image
          loading in HTML should be tweakable from CSS as well
  hober: I agree that CSS should match HTML here.
  hober: But both should be sitting on top of Fetch. Fetch should have
         some keywords, and we use those keywords
  AmeliaBR: Good point
  AmeliaBR: I think all of these should be addressed together with a
            common syntax.
  AmeliaBR: I don't know what's the nicest or more author-friendly
            syntax, but good to consider them all together, not
  AmeliaBR: Other ones open are #2994 on preloading something, #2095
            for async decoding, and #3659 for lazy loading
  AmeliaBR: Issues for async and lazyload is that browser defaults for
            CSS images are different from HTML content images.
  AmeliaBR: Maybe can't copy html, need to think about what makes
            sense for CSS specifically

  jensimmons: Yes, we need this. Proposal is to put the burden on
              authors to set this up correctly?
  jensimmons: Authors already have a hard time on CORS compat.
  jensimmons: Can we put the burden on the browser instead?
  TabAtkins: I suspect not. These are all behavior changes, so
             changing defaults could break changes.
  AmeliaBR: Also if browser has to consider all possible cases for how
            it'll request an image before it can send the request, it
            can get messy/slow, especially with dynamic loading
  astearns: Yeah, browser might not know that a *future* load will
            need CORS, so there's no way for it to tell without a hint.
  astearns: So on the align-with-fetch issue, does Fetch have keywords
            for all these topics we can follow?
  emilio: Firefox already does async decoding on all images.
  myles: Really? We did that but had to roll it out.
  emilio: We do it unless it's something our image library can tell is
  TabAtkins: Is there an attribute for async decoding on <img>? Not
             sure we should do anything img doesn't.
  AmeliaBR: Yeah, there's a `decoding="auto|sync|async"` attribute

  emilio: What's the story with unknown url modifiers? Would be sad if
          you have to rewrite the url several times for different
          combos of browser support.
  TabAtkins: Not defined right now. We should decide how we want to do
             error handling
  * emilio thinks lazyload should be split from the rest of the
           proposal, since that's fairly different
  myles: We solved this for src: with forgiving handling, split on
         top-level commas and ignore unknown stuff.
  astearns: Yeah, good to match.

  <AmeliaBR> URL modifiers https://drafts.csswg.org/CSS-values/#url-modifiers
  AmeliaBR: Reading the definition of url-modifier, it looks like they
            can't be used on unquoted urls or just-string urls. That
            means it needs to have a quoted string inside?
  TabAtkins: Yes.
  fremy: Edge currently ships with the quoted-url-as-function-token
  emilio: Also Firefox.
  astearns: So any objection to silently ignore unknown url-modifiers?

  RESOLVED: Unknown <url-modifier>s get silently ignored (rather than
            invalidating the function).

  AmeliaBR: So I think the rest of the issue is, align CSS's image
            loading support with HTML's support, via url modifiers.
  TabAtkins: Agreed.

Received on Tuesday, 26 March 2019 19:29:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2019 19:29:19 UTC