[CSSWG] Minutes Telecon 2021-09-15 [css-fonts-4] [css-nesting] [css-multicol-1] [css-backgrounds] [css-values-3]

  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.

CSS Nesting & Fonts

  - RESOLVED: Adopt if/else as next level of css-conditional (Issue
              #6520: Nesting @supports inside @font-face / font tech
  - RESOLVED: Accept the PR
              (Issue #6520)
  - There are still some open questions and concerns that were
      discussed on the call, but they will be raised as separate issues.

CSS Multicol

  - RESOLVED: Transition css-multicol-1 back to CR (Issue #6612:
              New CR?)

CSS Backgrounds 3

  - RESOLVED: Add a note [this falls out from the computed value
              definition] (Issue #6586: What is the serialization
              "background-position: top right 10px"?)

CSS Values 3

  - RESOLVED: Serialize as url("") (Issue #6447: Serialization of empty
              url() undefined)


Agenda: https://lists.w3.org/Archives/Public/www-style/2021Sep/0005.html

  Rachel Andrew
  Tab Atkins-Bittner
  Christian Biesinger
  Oriol Brufau
  Dan Clark
  Emilio Cobos Álvarez
  Elika Etemad
  Simon Fraser
  Megan Gardner
  Chris Harrelson
  Daniel Holbert
  Brian Kardell
  Brad Kemper
  Jonathan Kew
  Daniel Libby
  Chris Lilley
  Ting-Yu Lin
  Alison Maher
  Morgan Reschenberg
  Dominik Röttsches
  Jen Simmons
  Miriam Suzanne
  Lea Verou

  Rossen Atanassov

Scribe: fantasai
Scribe's Scribe: drott

CSS Nesting & Fonts

Nesting @supports inside @font-face / font tech queries
  github: https://github.com/w3c/csswg-drafts/issues/6520

  chris: Basic problem is that we need a way to ensure that only one of
         the possible options works
  chris: If you have unicode-range and a character outside that range,
         all the others will be loaded to see if it has that char
  chris: so this has been paired with another issue
  chris: It seems we need to discuss together
  lea: Looks like primary problem with using @supports is that pattern
  lea: of older code being unwrapped, but wrapping new code in @supports
  lea: but that doesn't work well with @font-face
  lea: because the second rule doesn't override the first rule
  lea: they combine to form a single family
  lea: although normally only second font is used
  lea: If browser encounters character not in the second, it will
       download the first to check if it is there
  lea: so for this we would need an else condition
  lea: so that we never have both @font-face rules in effect at the
       same time
  lea: There's a proposal from Tab to combine feature queries and media
       queries, and has else
  lea: Tab suspects it's easy to implement
  lea: I this can be implemented together with font-technology(), that
       would be nice
  lea: Concern that if implement without it, we'll have this
       problematic pattern

  chris: Overloading the format string does have this benefit of
         combining the conditionals properly
  chris: If we don't rapidly converge, we'll be stuck with that
  astearns: So you're concerned to get if/else quickly so that practice
            doesn't ossify into bad syntax
  chris: People will just ship what's in the spec now
  myles: I thought we would remove the complicated resource grammar

  drott: I spoke to implementers, to Anders and Rune who are familiar
         with our CSS code
  drott: They have no immediate concerns with the when/else proposal
  drott: Which brings my question of timing
  <chris> \0/ to no concerns!
  drott: I'm also supportive of removing the syntax in the spec now
  drott: but eager to have something to enable font tech feature
         testing atm
  drott: We're supportive of the when/else proposal, but it would be
         better to have font tech queries soon and maybe when/else as
         an upgrade path
  astearns: Is it possible to have a font-tech syntax in the @font-face
            that would not handle the conditional with fallback?
  drott: Current feature in spec is encapsulated in src descriptor
  drott: in the format() function
  drott: Authors can order it by most advanced tech, and then the UA
         will pick the one that it supports
  drott: In current proposal, without @else we have an accumulation of
         fonts into the family
  <lea> astearns: https://drafts.csswg.org/css-fonts-4/#font-face-src-parsing
  <lea> ^ that is the current syntax
  astearns: Would it be possible to have a limited state for this font
            technology where you could put it into your @font-face and
            have a font face exist if the font technology was
            supported, but have it not exist if it wasn't
  astearns: No fallback, just make this font face if the tech is
  drott: You could use different families
  lea: If you don't want fallback, that's fine. You just make an
  astearns: So wanted to remove things from spec, remove the current
  astearns: in favor of clearer if/else
  astearns: but people still want conditional on font
  astearns: and it would be nice to have that font tech
  chris: We need to do both
  chris: for a solution

  fantasai: I think we had previous notes on this, can't find it
  fantasai: It was basically: we should have both, the font-technology
            function in @supports, and the ability to query the tech in
            the format function, and they should share the syntax. And
            the syntax should be simpler.
  fantasai: for @supports, you might want to query not only if it's
            color, but you might want to query for format
  fantasai: I would simplify the syntax of the font-technology function.
  fantasai: In a way to remove the sub functions, and just have a list
            of keywords, for example font-format-...
  drott: I think you did post it somewhere, I had updated my pull
         request to flatten it...
  lea: I think that was my proposal to flatten from color() to color-

  chris: The format shouldn't be the orphan that gets left behind that
         you have to do in src, it should be same conditional thing
         that we do in font-technology
  chris: so if woff5 comes along, we can also put that in this new
         shiny syntax
  fantasai: it should be the same function, for format and font
  <chris> I don't really like calling it font-format
  lea: If I understand correctly, a format should also have been a
       condition in @supports
  <chris> yes exactly lea
  lea: if designing today that's how we would do that
  lea: only reason we have format function is that it's legacy
  <chris> we can't get *rid* of the format legacy though, so it has to
          remain in the spec
  lea: So I think what Chris is saying is that we also need to be
       adding a font-format() function into @supports so that authors
       can combine @font-technology queries
  lea: Whereas what fantasai is saying is to have only format()
       function, and have it allowed both in src and @supports

  astearns: So we're looking for a way to express simpler supports
            queries in @font-face rules
  astearns: and remove fallback ability
  fantasai: I think we're not aiming to remove fallback
  chris: The things that drott proposed, it would be helpful to allow
         that as a direct query in @supports conditions
  myles: I think adding that should be blocked on having some way of
         solving the problem that jfkthame described

  lea: No way to do else, so authors will need to negate their queries
  lea: and it would get very verbose and complicated
  myles: Not even sure if it's possible
  myles: because there's a third value here, not just supported or not
         supported, but also case of "browser doesn't know what you're
         talking about"

  chris: So need a resolution on proposal, but also how do we move
         forward on Tab's draft
  chris: Can we adopt it as an ED?
  myles: We should split this font-specific issue
  myles: One piece blocked on else rule and one that isn't
  myles: and discuss else rule in its own CSSWG issue
  <chris> this is its issue: https://github.com/w3c/csswg-drafts/issues/112

  drott: I discussed this issue with jfkthame offline. I think he's
  drott: In our question, jfkthame expressed some flexibility regarding
  drott: I'd like to emphasize what chris was saying earlier, if we
         move the supports syntax from CSS as it is now, then we don't
         have anything to do feature testing
  drott: I consider @supports an upgrade path
  myles: I've heard some people say they want to remove unimplemented
         flexibility in the spec now, and others don't want to remove
         it but to reformulate to make it simpler
  myles: Either one is reasonable to me
  lea: Which part is blocked on what?
  myles: If we want to keep the unimplemented features of the format()
         in src, we wouldn't need to be blocked on else
  lea: the problem with that is that we don't want microsyntaxes
  <TabAtkins> It is true that `@supports unknown-font-thing() {...}
              @support not (unknown-font-thing()) {...}` will fail to
              match both of them (the first is unknown, treated as
              false; the second is negated unknown, which is still
              unknown and thus treated as false)
  <TabAtkins> whereas `@support unknown-font-thing() {...} @else {...}`
              would match one or the other, guaranteed.
  <TabAtkins> Oh wait, sorry, I was wrong - @supports doesn't use the
              unknown value.
  <TabAtkins> We resolved on that a bit ago.
  <TabAtkins> Unknown things are just false in @supports.

  lea: Important point from the issue drott raised hasn't be raised yet
  lea: else is syntactic sugar for negation
  lea: but another way to work around is to use unicode-range
  lea: drott mentioned that most font-face rules are generated, and
       have unicode-range already
  lea: which means this isn't a problem
  myles: unicode-range is an orthogonal feature
  myles: If author is trying to use fancy syntax that is / isn't
  myles: both @font-face rule and fallback will have the same
  myles: so the problem still applies
  lea: Problem is if the character is not included in the range
  myles: Problem that I'm concerned about is that character is inside
         the unicode-range block, but not supported by the font's CMAP
  myles: In that case the browser will download both fonts serially
  drott: Should have unicode-range identical to CMAP
  <TabAtkins> So my statement above was wrong - both are equivalent,
              and you'll definitely select one or the other. (We use
              unknown for @media, where the browser very well *might*
              match an unknown query once it starts supporting it; a
              browser that doesn't understand a feature, by definition,
              doesn't support it, so that's a safe `false`.)

  fantasai: Lea was concerned about multiple different microsyntaxes.
            My proposal doesn't do that. Format function, should have
            identical syntax, whether it's in src: or in @supports.
  fantasai: If that's the case, we can ship src: first - ship @supports
            version later.
  lea: There's another unexplored option
  lea: What if we had an inline conditional function that does supports
  lea: A supports() or supports-if() function to put inside any value
  astearns: I think it would be a good idea to write down what you're
            suggesting, Lea
  astearns: but getting a proliferation of options, unsure we can get
            to resolution on anything specific today

  astearns: I think we can resolve at least that we would like to work
            on the if/else syntax
  TabAtkins: Adopt as an ED in the WG? Currently draft in my personal
  <lea> +1 to working on @else proposal
  <jfkthame> +1
  astearns: Resolution would be to adopt, yes
  fantasai: So that would be css-conditional-3?
  TabAtkins: Sure

  drott: Potentially add any resolution, then idea would be to have a
         font-tech function to combine with that?
  <TabAtkins> I also was under the impression that Conditional started
              with 1.
  dbaron: I think conditional-3 is already advanced
  fantasai: oh, I meant whatever's next
  <drott> +1 to that.

  RESOLVED: Adopt if/else as next level of css-conditional

  astearns: So question of current font-technology draft and reworking
            them with existence of if/else in mind
  astearns: so take back to issue to determine what changes, if any,
            need to be made
  chris: I don't see a dependency there
  chris: I think we can adopt PR as-is
  <drott> +1 as well
  lea: +1
  lea: this is something useful immediately
  <TabAtkins> +1
  astearns: Adopting PR will resolve the issue?
  <drott> yes
  lea: the bulk of it
  astearns: And we can open new more tightly constrained issues
  astearns: So proposed resolution?
  drott: Adds font-technology() function to @supports, which has a flat
         list of font technologies and options, which can be used
         inside an @supports rule
  <drott> https://github.com/drott/csswg-drafts/commit/62cfd95a5f52604c952e4aa37be6e4d6386f88f5

  myles: The @else rule should make it clear that it works with this
         new query inside @supports
  myles: Either explicitly or implicitly
  myles: And I'd ask implementers not to implement font-technology()
         without @else
  myles: because if you only give ability to do it wrong, people will
         do it wrong
  <dbaron> That request to implementers should be  in the
           spec .
  lea: They can still do it right, it's just tedious
  myles: Because @else is the solution to this problem, so one depends
         on the other
  <jensimmons> +1 to myles
  fantasai: I am not sure I agree with this particular PR.
  fantasai: I think the function should have identical syntax to what
            we should have in src:.
  fantasai: One question I have: font-technology - would this be
            allowed to be queried in src:?
  astearns: I think we should merge it in and take separate issues
  chris: I edit both specs anyway
  myles: But if we're making src less flexible than it is to day (in
         the spec)
  <drott> +1 to that, if we can have the font-technology PR
  fantasai: Happy to do so, as long as we can work on it and not just
            ship what's in the PR
  <chris> @drott I see the PR on your fork repo but not the one on the
          csswg repo

  myles: I think it's OK to resolve this, I think fantasai's idea about
         making them match makes sense to me
  myles: I think making them match gives drott a path to implementing
         that doesn't rely on us standardizing a big new feature
  myles: so I think that's the best path forward
  astearns: We've not got to solve everything today
  astearns: So let's merge the PR and file more issues
  <drott> +1
  <lea> +1
  <chris> +1
  astearns: Any objections?

  RESOLVED: Accept the PR

  <chris> :)
  myles: Can we add a note to the PR to say "don't implement this yet,
         implement this other thing first"
  astearns: Open an issue


New CR?
  github: https://github.com/w3c/csswg-drafts/issues/6612

  rachelandrew: We've been doing a bunch of work from css-multicol-1,
                took it from CR to WD to work on it
  rachelandrew: That's my notes on preparing to take back to CR
  rachelandrew: I've had horizontal review from everyone except
                security, who hasn't responded since 12 May
  rachelandrew: but don't expect any issues
  rachelandrew: Obviously we have wide implementation of this spec
  rachelandrew: after CR need to sort out test suite
  rachelandrew: There's a column which details the larger changes that
                I don't think have tests yet, but need to check since
                browser vendors have been doing work
  rachelandrew: so would like to get approval to move to CR
  <fantasai> +1
  <florian> +
  astearns: Any objections?

  RESOLVED: Transition css-multicol-1 back to CR

  <fantasai> \^_^/
  <jensimmons> yay!! I know it's been a ton of work...

Backgrounds 3

What is the serialization "background-position: top right 10px"?
  github: https://github.com/w3c/csswg-drafts/issues/6586

  smfr: Spec allows specifying a corner and an offset from that corner
  smfr: spec doesn't specify
  smfr: WebKit serializes as inputted
  smfr: Gecko serializes calc()
  fantasai: We already did discuss this - that's the way the computed
            value is the way it is.
  fantasai: You could possibly map the values of varying percentages to
  fantasai: It's said that it's a length/percentage value per axis.
            There's no way to distinguish if somebody specified calc()
            of a value
  fantasai: We had discussed this before: main concern would be: in the
            future we would have logical keywords
  fantasai: With that, the computed value for background-position would
            become more complicated
  fantasai: I don't have a strong opinion on it because of what we plan
            for in the future.
  fantasai: Spec is clear, in the "computed value" line
  <emilio> I agree this falls from the "Computed Value" definition

  TabAtkins: Since it confused some people, maybe a note to highlight
             that this information is lost would be helpful
  smfr: I just wanted to follow link to where it's clear...
  TabAtkins: As a combination of lengths and percentages, you'd have to
             use calc()
  dbaron: Other principle is use most backwards-compatible syntax, and
          at least in Gecko calc() predated the background-position
          extended syntax
  astearns: Suggest closing issue by adding a note to css-backgrounds-3
            and maybe also values and units
  smfr: Works for me

  RESOLVED: Add a note

  astearns: no normative change, but we will explain why

CSS Values 3

Serialization of empty url() undefined
  github: https://github.com/w3c/csswg-drafts/issues/6447

  smfr: CSS Values talks about empty URLs and how we avoid normal
        behavior of resolving against stylesheet URL
  smfr: empty treated as involved
  smfr: and we introduced "about:invalid" as a URL
  smfr: which is what Gecko serializes
  smfr: ??? serializes the resolved URL which is wrong
  smfr: but I think empty URLs serialize as such
  TabAtkins: That was my intention, and I'm happy to adjust spec to
             make it clearer
  smfr: Also do we serialize as url() or url("")
  TabAtkins: I think completely empty URL, is that even valid?
  fantasai: It is valid, just tested
  TabAtkins: That would be a serialization nobody uses
  TabAtkins: so I lean toward url("") because at least one browser is
             doing that currently
  emilio: Who?
  TabAtkins: Whoever is passing that test
  emilio: smfr updated the test to use empty string
  emilio: but Firefox serializes as about:invalid and I don't know what
          WebKit and Blink do
  <smfr> https://wpt.fyi/results/css/css-values/urls/empty.html?label=experimental&label=master&aligned
  TabAtkins: nevermind, nobody passes that
  smfr: Test expect everything becomes quoted

  TabAtkins: Let me see if CSSOM specifies anything
  TabAtkins: Yes, CSSOM expects all URL functions to contain a string
  <emilio> https://drafts.csswg.org/cssom/#serialize-a-url
  TabAtkins: regardless of whether inputted with or without quotes
  TabAtkins: So for consistency, empty url() should also serialize with

  astearns: So proposed resolution is to make this test valid, using
            quoted empty string?
  emilio: Before we resolve, I wanted to make an argument for url()
  emilio: if you consider invalid URL not a URL
  emilio: but I'm fine
  astearns: If you're fine with the explicitly quoted empty string, I
            think it makes much more sense, it's consistent
  astearns: Any objections?

  RESOLVED: Serialize as url("")

Received on Wednesday, 15 September 2021 23:08:16 UTC