W3C home > Mailing lists > Public > www-style@w3.org > November 2021

[CSSWG] Minutes Telecon 2021-11-17 [css-fonts] [css-cascade] [css-values] [css-position] [css-transforms] [css-backgrounds]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 17 Nov 2021 19:38:07 -0500
Message-ID: <CADhPm3tCnks73C9=35GQTKU0yJQgN7gyOcGaOaSGyGVoMHuLxg@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.

Meeting Scheduling

  - The meetings for next week and the last 2 weeks of December are
      cancelled due to holidays.
  - There is interest in doing an extended call on 8 December to make
      it through more of the agenda+ topics. A decision will be made on
      the mailing list.

CSS Fonts

  - In continuing to solve for issue #4497 (Limit local fonts to those
      selected by users in browser settings (or other browser chrome)),
      the group reviewed a proposed solution from Felipe
      ( https://github.com/w3c/csswg-drafts/issues/4497#issuecomment-763459971
      - The proposal doesn't specifically call out using a
          locally-installed font which does have use cases. This could
          also be a fingerprinting mechanism.
      - There is concern on using a permission prompt to inform the
          user since fingerprinting is complex to explain and there is
          already user fatigue around permission prompts.
  - RESOLVED: format() serializes with strings (Issue #6328: @font-face
              src: url() format() keywords vs. strings ambiguous in
  - RESOLVED: font/ MIME type registry manages valid values of format()
              (Issue #6328)

CSS Cascade

  - RESOLVED: Accept proposal [
              (Issue #6776: When an import rule fails to load or has an
              unsatisfied condition, does the layer still count?)
  - RESOLVED: Republish css-cascade-5

CSS Values

  - RESOLVED: Accept edits, expand to allow aliased functions (Issue
              #6193: define parse-time value aliasing)
  - RESOLVED: Add this to the Value Definition Grammar (Issue #5728:
              Clarify that function component values need to be
              followed by parentheses)

CSS Position

  - RESOLVED: Semi-replaced elements stretch in both directions in
              abspos (Issue #6789: Behaviour of semi-replaced elements)

Transforms & Backgrounds

  - The group was leaning toward resolving that background on root
      elements are not affected by transforms for issue #6683 (
      Transforms and backgrounds on root element). dbaron will look
      into the effects of filters on root element before the group
      resolves on it.


Agenda: https://lists.w3.org/Archives/Public/www-style/2021Nov/0009.html

  Rachel Andrew
  Adam Argyle
  David Baron
  Tantek Çelik
  Daniel Clark
  Emilio Cobos Álvarez
  Peter Constable
  Elika Etemad
  Simon Fraser
  Megan Gardner
  Daniel Holbert
  Richard Ishida
  Brad Kemper
  Jonathan Kew
  Daniel Libby
  Chris Lilley
  Ting-Yu Lin
  Peter Linss
  Morgan Reschenberg
  Jen Simmons
  Miriam Suzanne
  Lea Verou

  Tab Atkins-Bittner
  Chris Harrelson

Scribe: fantasai
Scribe's scribe: emilio

Meeting Scheduling

  astearns: Cancelled meeting next week and last 2 weeks of December
  astearns: due to holidays
  astearns: but we have a lot of Agenda+ items
  astearns: so maybe want to add extra meeting time
  astearns: Could add extra time in December, or in January
  astearns: Please let me know if any preferences on this
  astearns: or if there's a set of topics for a breakout session
  astearns: So far, topics seem mostly mixed, but open to suggestions
  fantasai: My suggestion would be to extend Dec 8th into a vF2F
  fantasai: Well after Thanksgiving and well before Christmas, and
            avoids topics dragging into January

CSS Fonts

Limit local fonts to those selected by users in browser settings (or
    other browser chrome)
  github: https://github.com/w3c/csswg-drafts/issues/4497

  astearns: Topic is about local fonts needed for i18n particularly
  [side discussion about positioning of Agenda Item 9]

  smfr: Myles isn't here, probably should be here also
  astearns: Other browsers than Safari probably need to sign on for
            whatever local font access we decide on here

  chris: It would be good to get some movement on this.
  chris: Felipe made a good suggestion, and thumbs up in thread
  [Felipe's suggestion at
  chris: Richard confirmed he liked the suggestion
  chris: Maybe we can resolve to accept the suggestion, and then work
         out the details in the spec
  chris: The general principle seems sound
  astearns: Summary is having some sort of permission interface, where
            if a web page tries to use a local font and browser notices
            local font is in system, UI would come up
  astearns: timed to make fingerprinting more difficult
  astearns: allows user to enable font access
  r12a: Then can have a checkbox for "don't ask me about this font

  jfkthame: Interested in Gecko
  jfkthame: Doing some foundational work towards potentially
            restricting font access
  jfkthame: One aspect not directly talked about, seems there are
            several senses in which a website could want to use a
            locally-installed font
  jfkthame: worth highlighting the distinction
  jfkthame: might be font name is given in font-family property
  jfkthame: so that specific font family is specifically requested, and
            page would like to use, and might or might not be allowed
  jfkthame: But what about font fallback? Character that is not in
            other fonts
  jfkthame: Would that trigger requests like this?
  jfkthame: Should there be a user request for fallback, when the
            character is not available in other fonts?
  jfkthame: I think the fingerprinting implications are different
  jfkthame: I think for fallback, I think it's particularly concerning
            for minority languages
  jfkthame: For such users, any font that supports the language would
            be helpful
  chris: For fallback case, script can know that fallback was used, but
         doesn't know which one
  chris: so imo shouldn't require a user permissions font
  jfkthame: Well, you are exposing the fact that the user has *a* font
            that supports these characters

  smfr: In general, we don't believe permission prompts are useful
        solution to this kind of problem
  smfr: One reason is user fatigue; users don't read the dialog, just
        want it out of the way
  smfr: Then it's really impossible to explain to users what
        fingerprinting means and implications
  smfr: ....
  smfr: Then users don't understand whether web page or browser is
        showing the dialog
  smfr: Long-term approach should be that system fonts have support for
        these minority languages
  smfr: so that we don't need to run into this problem in the first
  <tantek> +1 smfr, permission prompts are not a reasonable answer to
           this (users can't be expected to make informed consent)
  chris: The page gets laid out without the font, the dialog box pops
         up asking permission to allow this, so that next time come to
         that site (per origin) not bothered by it
  chris: so rapidly not going to run into this problem
  chris: A font on system that covers the charset vs specific font that
         gives the right design is different
  chris: ....

  r12a: There is somewhere a long post on one of these issues where I
        addressed the question of system fonts being able to display
        the text
  r12a: there are certain scripts and orthographies where not only does
        it not look good, but it actually causes problems in
        representing semantics
  r12a: Might end up with wrong kind of glyphs, doesn't look the way
        you expect as a user of type script
  r12a: Don't see any way to rely on system fonts here
  r12a: Also people like font designers have a problem, they can't
        check their fonts if they can't see them
  <chris> suspect r12a is referring to this:
  <chris> with Western Syriac example
  r12a: Noto fonts are not a panacea
  r12a: They are often in need of significant repair to do the job
  r12a: Sometimes missing for certain minority scripts
  r12a: Not coverage of characters, sometimes not the right glyph shapes
  r12a: A dialog box in front of the user is not great
  r12a: But it's better than not being able to get the font that you
  r12a: I couldn't think of any better solution to it
  r12a: It will probably help if we have the ability to say "don't
        remind me, about this particular font"
  r12a: I don't think there's a good solution here
  r12a: If you're creating web pages, you are checking your page using
  r12a: and in that situation, there's not going to be any phishing
  r12a: major pain in the butt if you can't spin up the page with the
        font you'd like to see
  r12a: So I'd like to argue that if you're working on localhost, then
        that should not prevent you from seeing fonts
  <chris> localhost is just one example of an origin

  astearns: My current take is that we're not ready to resolve on
  astearns: but encouraged by the fact that Gecko is interested in
            figuring out
  astearns: Sounds to me that there are some valid concerns about
            permission interfaces
  astearns: but also valid concerns about not doing anything and just
            relying on system fonts
  astearns: so I hope that people engage on the issue, because this is
            something that we need to solve
  astearns: Thanks, r12a, for joining us

CSS Cascade

When an import rule fails to load or has an unsatisfied condition,
    does the layer still count?
  github: https://github.com/w3c/csswg-drafts/issues/6776

  miriam: A few questions in here
  miriam: All related to establishing layers inside of an @import
  miriam: One question is what to do if the import fails
  miriam: Other question is what to do if the conditions of the import
          don't match
  miriam: Consensus in the thread was that we should conceptualize this
          to "layer is wrapped around contents of the import, even if
          empty due to failure, and condition is wrapped around the
          whole thing"
  miriam: We added language to spec to express it that way
  miriam: Layer is still added to layer order if import fails
  miriam: but not added if the conditions don't match
  miriam: That matches the behavior of if you had import inside of
          layer inside of condition
  miriam: Wanted to check with WG if this is acceptable
  jensimmons: Makes a lot of sense from authoring point of view
  <fantasai> +1 from me

  RESOLVED: Accept proposal

  miriam: This allows us to republish

  RESOLVED: Republish css-cascade-5

  <chris> miriam: is the changes section up to date?

CSS Values

define parse-time value aliasing
  github: https://github.com/w3c/csswg-drafts/issues/6193

  fantasai: Added value aliasing section to cascade-4/5
  emilio: Weird that it is scoped to keywords
  fantasai: We didn't see any examples of not keywords, but could
            certainly reword to be more general
  emilio: `-webkit-image-set()`-> `image-set()`
  emilio: Same with a bunch of gradient functions
  fantasai: So functions and keywords, anything else?
  <emilio> I don't _think_ so of the top of my head
  astearns: So proposed to take edits, with additional change to add
  fantasai: sgtm
  emilio: sgtm

  RESOLVED: Accept edits, expand to allow aliased functions

Clarify that function component values need to be followed by
  github: https://github.com/w3c/csswg-drafts/issues/5728

  fantasai: So tab added bikeshed functionality in which he can link to
            a function definition using `<ident()>`
  fantasai: but this is not actually valid according to our value
            definition grammar
  <fantasai> <'property-name'>
  <fantasai> <keyword>
  fantasai: That has quoted property references and terminal kws (^)
  fantasai: So should we add this to the value-definition grammar and
            update all specs to use this convention?
  fantasai: A subtle thing is that only terminals that represent a
            function will use this
  fantasai: Historically we haven't done this, e.g., `<url>`
  fantasai: so the question is do we want to extend our syntax in this
  chris: I would find this useful, have needed <foo> vs <foo()>
  astearns: So proposal is to add <name()> to our grammar for specs
  astearns: Will that require going back and fixing everything?
  fantasai: I think it would be useful to make things consistent
  fantasai: but I wouldn't do it for <url>
  astearns: If not required, it's better; would prefer not to mess with
            old things
  astearns: Any other opinions?

  RESOLVED: Add this to the Value Definition Grammar

CSS Position

Behaviour of semi-replaced elements
  github: https://github.com/w3c/csswg-drafts/issues/6789

  iank: After last week's meeting dholbert did an in-depth
        investigation, which was great to see
  iank: test page with a whole bunch of replaced elements, and looked
        at behavior
  iank: We both agreed that it's probably reasonable to stretch in both
        directions for all semi-replaced elements
  iank: There's no browser which does something consistently, so every
        browser would need to change
  iank: but this is a straightforward path forward
  dholbert: Every form control is stretched in at least one browser
  dholbert: but not every form control is shrunk in at least browser
  iank: e.g. we stretch in block direction but not inline
  iank: webkit and FF together have complete coverage of stretching in
        inline direction
  astearns: Change is to stretch in both directions in all browsers
  iank: Correct
  astearns: Any other opinions?
  fantasai: Tab and I are in favor of this

  RESOLVED: Semi-replaced elements stretch in both directions in abspos

  iank: We'll likely make this change in the next few months, and will
        report back if any web-compat concerns
  astearns: Thanks, dholbert, for your investigation

Transforms & Backgrounds

Transforms and backgrounds on root element
  github: https://github.com/w3c/csswg-drafts/issues/6683

  dbaron: Obscure passage in the spec, wrote a test for it, and ended
          up wondering if we really want spec to say this in the first
  dbaron: [quotes spec] [Fixed backgrounds on the root element are
          affected by any transform specified for that element. For all
          other elements that are effected by a transform (i.e. have a
          transform applied to them, or to any of their ancestor
          elements), a value of fixed for the background-attachment
          property is treated as if it had a value of scroll. The
          computed value of background-attachment is not affected.]
  dbaron: Basically, this is describing a special behavior for fixed
          backgrounds on root element, saying that transforms apply to
          that fixed background
  dbaron: Interesting because normal rules for background on root
          element say that backgrounds get propagated to canvas
  dbaron: and backgrounds on canvas, nothing says anywhere that they
          are affected by transforms
  dbaron: so if you read between lines in spec, I think what it says is
          that non-fixed background are not affected by transforms
  dbaron: could probably make other arguments, though
  dbaron: What I think the spec is saying is that fixed backgrounds are
          affected by transforms, and scrolled backgrounds are not
          affected by transforms
  dbaron: What my tests found, is that in chromium do the exact opposite
  dbaron: i.e. fixed background not affected, but scrolled backgrounds
  dbaron: In Gecko neither is affected by transform
  dbaron: and in WebKit both kinds are affected by transform
  dbaron: So 4 possible behaviors
  dbaron: and every browser fits into a different possible behavior
  <dholbert> as a see-also, we have
            filed on some WPT tests failing due to Gecko's behavior here
  dbaron: It's not clear to me we want what the spec says
  dbaron: I wanted to see if anyone has an opinion here

  smfr: Don't have a clear memory about why spec is the way it is,
        might have been ease of implementation
  smfr: We do special thinks for fixed backgrounds
  smfr: but I would expect that it would have been easiest to *not*
        apply transforms for fixed backgrounds
  smfr: so I'm pretty confused
  dholbert: [...]

  fantasai: So what do authors expect to happen here?
  dbaron: part of what I was wondering
  fantasai: so canvas is infinite...
  smfr: Think about rotate(45deg); does the background rotate?
  dbaron: Unsure anyone cares here, so maybe do the easy thing?
  dbaron: so not apply transform
  smfr: So if author wanted background to move around, they could put
        it on body and prevent propagation with different style on the
  smfr: and then transform the body
  dbaron: Might not cover the same area though
  smfr: What happens to gaps revealed by e.g. rotating 45deg?
  smfr: Are they filled, or ...?
  dbaron: WebKit has some bugs around that

  astearns: Anyone looked to see if any bugs filed against engines on
  smfr: Don't recall any for WebKit
  dbaron: I feel like this is a combination that nobody actually cares
  astearns: So suggestion of never honoring transform, is that ok smfr?
  smfr: My concern there is, naively, if root gets transformed, whether
        background is transformed with it depends on details of impl
  smfr: if we end up with behavior change, might force us to do
        additional work to handle
  smfr: I'm OK resolving background never gets transformed, and if
        hard, we can revisit
  astearns: So chrome would need to change also
  dbaron: Haven't looked into what's needed for that, but I'm OK
          looking into it

  astearns: Proposed that we change spec to say that background on root
            element are not affected by transforms
  dbaron: I think current spec is unclear about scrolled backgrounds
  dbaron: You have to infer based on propagation rules

  smfr: We've talked about effects of filters on root element in the
  smfr: Chris came up with a proposal for rendering model that allows
        filters to affect root background
  smfr: so maybe review that and see if any of it applies to transforms
  dbaron: Ok, so let's come back to this later
  astearns: So let's review filters and come back to this later

CSS Fonts Continued

@font-face src: url() format() keywords vs. strings ambiguous in spec
  github: https://github.com/w3c/csswg-drafts/issues/6328

  chris: Grammar here is complicated due to allowing strings and
  chris: but most compatible form is string
  chris: So we should support string and serialize as string
  astearns: Do we want to accept keywords as well?

  fantasai: Let's split into 2 questions, first is resolving on
            serializing as strings because they are the most
            backwards-compatible syntax
  astearns: does drott have any concerns?
  astearns: most backwards-compat usually winning argument

  RESOLVED: format() serializes with strings

  jfkthame: What are we intending to do with font-technology(), will
            that take keywords or strings, and will that be confusing?
  chris: That will take keywords as currently specced. Though that can
  chris: There's no back-compat concern with technology()
  astearns: Since we have back-compat issue with one, maybe all of them
            should serialize as strings
  jfkthame: I'm not sure what I favor
  jfkthame: I recognize the back-compat issue
  astearns: Let's take that as a separate issue
  astearns: and resolve to use strings for format() and then find out
            whether drott agrees, or whether we can do something more
            complicated, and if string serialization format sticks can
            decide on consistency for rest
  astearns: Any other concerns about serializing format() with strings?

  RESOLVED: format() serializes with strings

  chris: There weren't font MIME types at IANA, so we faked it by
         creating our own names
  chris: Now there is a fonts/ registry for MIME types
  chris: fantasai suggested that we just use that registry
  chris: but the RFC says that it is informative, and css-fonts-3 is
  chris: I think we'd like to change that so that they are normative,
         and we are informative, and they can handle registration of
         new formats so we don't have to
  astearns: So we would normatively refer to their spec?
  chris: And then errata the RFC so that it no longer says our spec is
  astearns: ...
  fantasai: Shouldn't have different keywords allowed between string or
            keyword in format()

  RESOLVED: font/ MIME type registry manages valid values of format()

  PeterConstable: What's involved in getting IETF updated?
  chris: I will contact the chair and ask if this is in scope of errata
         or not
  chris: Unsure if publish a new RFC or not
  chris: If errata, then errata submission form
  chris: If not then will need to spin up a very small wg to make the
  chris: but anyway I'll deal with it

  astearns: Last thing is whether we accept unquoted keywords
  chris: Does any implementation currently accept keywords for format()?
  jfkthame: IIRC webkit does, but haven't checked
  chris: And do we want to continue to allow that and allow other
         browsers to do so, or get them to fix that?
  astearns: out of time, so let's leave issue open on this question and
            ask for feedback
  <chris> fair enough

  astearns: Meet again in 2 weeks, please discuss whether to have a
            long meeting on Dec 8th to get through the agenda
Received on Thursday, 18 November 2021 00:38:51 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 18 November 2021 00:38:52 UTC