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

[CSSWG] Minutes Telecon 2019-12-18 [css-ui-4] [css-fonts] [css-lists]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 18 Dec 2019 20:01:08 -0500
Message-ID: <CADhPm3vni=VbBSdrhpKEfMfNDJzsBM3PoyVL3TUbA+5696h_5w@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.
=========================================


Summer 2020 Meeting
-------------------

  - Dates will be finalized on the private list.

CSS UI L4
---------

  - RESOLVED: Publish a new WD of CSS UI L4

CSS Fonts
---------

  - The group discussed limiting the exposed fonts in order to limit
      fingerprinting vectors (Issue #4497: Limit local fonts to those
      selected by users in browser settings (or other browser chrome))
      and was interested in creating possible spec text.
      - Even though there are plenty of other vectors to fingerprint
          users, a majority of the group felt that it was worth the
          effort to chip away at the problem.
      - There were different options as to what fonts to use; an
          intersection of OS fonts, a union of them, or somewhere in
          the middle where we accept that you'll still be able to know
          basic information like OS from the font list.
      - Though the spec shouldn't list exact fonts, there was a desire
          to have an accompanying note-like document that does say
          fonts which are known to conform to the spec text.
      - In the current GitHub there is a proposed way to still allow
          users to install and allow a font and that use case is
          important to support as this is a common need for users that
          consume content in a minority language.
      - Though there's a desire to ensure this text strongly protects
          users of browsers it may still need to be a SHOULD level
          requirement as there are other use cases where
          fingerprinting isn't a concern such as PDF renderers

CSS Lists
---------

  - RESOLVED: Reverse previous blockification requirement and require
              generating a block container (Issue #4448: How should
              spaces be treated in markers?)
  - RESOLVED: Use white-space:pre as the value in UA stylesheet with
              text about possibly processing new lines (Issue #4448)

===== FULL MINUTES BELOW =======

Agenda: https://lists.w3.org/Archives/Public/www-style/2019Dec/0014.html

Present:
  Rachel Andrew
  Rossen Atanassov
  David Baron
  Amelia Bellamy-Royds
  Christian Biesinger
  Oriol Brufau
  Dave Cramer
  Elika Eteman
  Simon Fraser
  Dael Jackson
  Brian Kardell
  Chris Lilley
  Peter Linss
  Stanton Marcum
  Myles Maxfield
  Devin Rousso
  Christopher Schmitt
  Pete Snyder
  Jen Simmons
  Alan Stearns
  Lea Verou
  Sean Voisen

Regrets:
  François Remy

Scribe: dael

Year in Review
==============

  astearns: I think we have enough to start
  astearns: Any changes to the agenda?
  Rossen: I wanted to add an item.
  Rossen: I wanted to give a summary of the year we had.
  Rossen: Here's some numbers
  Rossen: We could resolve 176 items not counting the ones we
          discussed without resolution
  Rossen: Published 18 WDs, 9 CRs, 2 RECs. This is really amazing. I'm
          inspired by everything we've done
  <florian> yeah us !
  Rossen: I get praise for the way the WG works and it's amazing.
          We've done 10 REC this decade and 2 were this year. Inspired
          by this year and looking forward to 2020
  smfr: Do you have a decade summary?
  Rossen: I couldn't get the decade for the WD and CR. /tr didn't go
          back far enough
  Rossen: It would be fun to do as a summary of the decade; especially
          for those of you that have been here for the entire declare

2020 Summer Meeting
===================

  astearns: Can we lock down dates
  astearns: Two dates provided. One in July which was better for
            spacing, June which was better for Mozilla
  astearns: Does anyone from Google know if both dates are available?
  astearns: Lacking that, are there Mozilla people that very much
            prefer June dates?
  <dbaron> btw, did Alan's view of the thread include the October
           messages:
https://www.w3.org/mid/c8aababf-85c6-6406-8a32-e5c2a1e77784@inkedblade.net
           and https://www.w3.org/mid/4e5672f3-475e-42ce-93ed-be4dff028160@www.fastmail.com
?
  jensimmons: Can you mention the dates again?
  astearns: I believe June 22-25 or...not sure July dates
  plinss: I have week of 20-24 July
  plinss: And the following week of August
  dbaron: Thread was 22-24 June or 20-22 July
  astearns: Right. And dbaron you thought June was easier for Mozilla
            folks?
  dbaron: Yes but heycam was okay either way and has longest trip.
  astearns: Lacking strong opinions on the call let's go to the list.

CSS UI L4 WD
============

  florian: Been under low pace maintenance, but we're 2 years from
           last WD. One section with significant changes is on
           appearance property. Thanks to zcorpan it's more fleshed
           out and feels like could be impl
  florian: Noticed how out of date it is I thought we should publish
  astearns: Objections to new WD of CSSUI L4?

  RESOLVED: Publish a new WD of CSSUI L4

  astearns: Since this is a regular WD and I assume all changes came
            from resolutions I think you could have published without
            resolution
  florian: I think some changes didn't have a formal resolution
  fantasai: You can publish with editorial
  astearns: I have not checked the draft but an up to date changes
            section would be useful
  florian: I'll look

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

  pes: Right now font fingerprinting by most measurements is highest
       entropy. Would like to address and solve
  pes: Needs standards level because will require some degree of PR or
       author notification or browser changes so everyone moves in
       tandem.
  pes: Couple proposals but in general need to limit types of fonts
       websites can tickle are those that are useful for users
  pes: Most recent proposal is let's figure out default fonts for OSs,
       union those, websites can access those. If users want to opt in
       other fonts you should be able to do those with a prompt from
       the browser

  astearns: One things about privacy discussions and opting in to
            exposing information is the concern about messaging to the
            user what they are doing. Is there possible a way to opt
            in to that giving a good story to the user what they're
            doing?
  pes: Two thoughts; if users are doing this they already know
       somewhat what they want. Conveying some of the functionality
       without the meaning is easy. If there's the desire to convey
       why I think that's easy to describe. I could put up text.
       People usually follow defaults. From examples in GitHub is
       moderately expert users and that's something two steps out of
       the mean
  pes: I think it falls nicely where browsers are doing things users
       don't expect and taking it from default path is a win and
       allowing users intentionally installing fonts is doable

  myles: A couple points. 1) Fingerprinting based on set of available
         fonts is real bad and we philosophically should try to solve.
  myles: 2) There's a problem here issue is trying to address which
         isn't stated yet. Safari already disallows user installed
         fonts so we're similar to proposal but don't ask users to
         allow. There's a problem with that where for some lesser used
         scripts there may be no system font that can support so can
         have unreadable pages
  myles: This proposal has affordances to solve that where for those
         scripts users can opt in. That's good. But there's a cost
         which is throwing additional prompts to user they may not
         understand and adding friction at OS install time is
         something the entire company tries to minimize
  myles: Realistically us adding a screen at OS install time is
         difficult to do and generally not something we're comfortable
         with
  astearns: Clarification on scripts not supported- is Safari not
            rendering some web pages it might otherwise be able to
            with the script?
  myles: Yes. Logic is it's a better situation for them to have to use
         web fonts because it's better to require that then for every
         user to install a font with a name because less websites then
         web users
  jensimmons: I was never aware Safari doesn't allow user installed
              fonts. And I've never heard a web designer talk about
              that. I agree it's complicated for users to understand a
              browser setting. That's the kind of thing a webdev can't
              count on. It may be something to think about but doesn't
              seem core to solving

  jensimmons: Looking at last part of GH issues I see intersection of
              fonts vs union of fonts. Union is when you have all the
              fonts on both even if they're only on some OS. Some
              people are saying to do intersection where Arial is on
              so it's allowed but Avenir is only on Mac so not
              allowed. Intersection would be a massive problem. I
              don't think it's a problem to limit to what's shipped
              in OSs
  jensimmons: If we try to limit to intersection it will break
              millions of websites. I don't think people are counting
              on some people might have fancypants font. But they are
              counting on some people have Avenir but others Roboto
  pes: Clarifying the proposal: Union of all fonts shipped by default
       by all OSs that an be reasonably compiled. And the ones fed to
       the website are intersection of installed and system fonts.
       That is one option on Android, another on OSX, etc.

  pes: Proposal isn't to say at install time let these fonts be
       accessed. Proposal is for small set of users who expect these
       fonts to be available because region of website allow user to
       go into advanced and have a drop down of additional fonts.
       Expectation is relatively few people do this, but communities
       that needs this already install extra font so this additional
       step isn't infeasible

  chris: I wanted to say contrary to jensimmons not seeing it [user
         installed fonts for uncommon languages] done, I have seen
         this on some sites, particularly when Indian was worse. South
         Indian it's common to install locally used fonts. It could be
         there's a pack that installs a bunch of fonts. I don't want
         to break web experience for those that have been using it
         successfully
  astearns: Is there a way to survey scripts and say these aren't by
            default but everybody in that region installs these fonts
  <jensimmons> +1
  chris: It would be a valuable addition

  myles: One other small things. Mechanically ability to discern
         between fonts is not a public API on OS. I would love to hear
         if any browser programmers wanted this exposed; I'd love to
         know that
  <Rossen> I'm not convinced that waiting for exposing such API on the
           OS platform is worth it

  <pes> https://github.com/Valve/fingerprintjs2/blob/master/fingerprint2.js#L557
<— example of fingerprinting via fonts

  florian: I don't see TabAtkins on and I'd like to bring up a point
           from him. this seems less drastic then others discussed so
           down side not that bad. If we do the intersection of what's
           installed it has a fair bit of variability. Besides font
           fingerprint there are other means. The question to ask is
           does it actually help. If we don't reduce it enough then we
           haven't achieved anything even though we decreased it
  florian: Downside isn't that bad if we include the language specific
           common fonts, but there still is some cost. Are we paying
           it for something or do we not reduce your uniqueness enough
  <jensimmons> There are many other ways of fingerprinting, but many
               of us out here are knocking them out one by one. I
               believe we should also do our best to close such
               security flaws. (in response to florian's comment)
  plinss: Let's not let hte perfect be the enemy of the good. There's
          a lot of fingerprinting surface and we need to make small
          steps in every regard. We have to take small steps where we
          can and get a cumulative effect where we can
  <pes> +1000 for what is being said right now.
  <jensimmons> +1 from me as well
  florian: TabAtkins point is he doesn't think we can ever get there
  <astearns> yep, if it makes fingerprinting at all harder, it's
             progress
  plinss: If we never try we won't get there
  myles: I don't doubt we can get there so we have one vote on either
         side so worth discussing

  dbaron: Two comments. myles asked about the API on Mac. it's not
          something we planned to work on but if we do get to work on
          this it would be useful. Lack might cause us to have to do a
          work around. If it's exposed it would make this sort of
          thing more practical. But we don't have a concrete plan to
          use it
  dbaron: Other thing is that there's been a bunch of discussion about
          intersection and union of fonts across OSs. I'm not
          convinced we want either. There's an argument that we want
          to allow vary between OSs. There's a set of fingerprintable
          information we can hope to obscure but there's bits of
          entropy we can be okay giving up on and one of those is if a
          user is on windows or mac.
  dbaron: Either way of addressing it makes the solution worse.
          Intersection limits designers, Union is a bunch of
          fingerprinting exposed if users install fonts that are
          default on a different OS.
  <myles> dbaron++

  pes: Point about fingerprinting nihilism. Ping and those in privacy
       community are trying to address it in many ways. You chip away
       as you can. Nature of problem means different wins benefit
       different people are different times.
  <myles> pes++
  pes: Chipping off entropy bits is valuable. Different fingerprint
       endpoints yield differently as well. So adding noise is an
       option in some places, but fonts is not one of those places.
       Figuring out how to reduce problem to a subset seems valuable
       here. I think every time we take a slice of the problem we're
       benefiting some people. We're not throwing coins in a well
  <plinss> +1 to pes

  fantasai: Two points. 1) If we're going to do this we should
            document which fonts are allowed on which OSs so all
            browsers can align with interop. If we're going to do this
            we should start a registry of allowed fonts so authors and
            browser vendors can figure it out
  astearns: To that I think yes and no. There should be a rule for
            what's in and maintain it, but have the list generated
            from rules. If we do a union the set will only ever grow
  fantasai: Rule in fonts spec, document of fonts that conform to the
            rule. In an OS API is nice, but an author won't find it
            easily
  astearns: We aren't saying browsers restricted to this for all time,
            we're saying here's the set we're aware of and here's the
            rule to add a new font
  myles: There's a bunch of websites that list the fonts. Do we need
         to maintain if it's out there?
  AmeliaBR: Not in reliable up to date fashion
  myles: Will ours be?
  dbaron: Need something that reflects worldwide usage. Some of that
          will need to be us.
  fantasai: I don't want it in fonts spec. A note or a W3C registry
            that's easily maintained and doesn't need our intervention.
  fantasai: 2) I want to emphasize we need to address impact on
            minority language population and limiting to default fonts
            won't cut it. Need to not harm those communities. You
            can't use web fonts for things like this. Places with
            minority language are also where downloads are slower and
            more costly. need to make sure we address that head on
  <jensimmons> +1 to everything fantasai just said. It would be
               incredibly helpful to Authors to have such a list.

  astearns: Other points on this topic?
  pes: I'd like to know how Ping or I personally can be most useful to
       make sure a solution gets into the next part of the spec and
       get this solved
  astearns: I think being active on GH issues that are open and
            reviewing spec text is most helpful. Anyone else can chime
            in?
  <pes> i can promise to do that :)
  fantasai: Are we resolving to do this and if yes exactly what. If
            not, when do we follow up?
  <dbaron> I think we're a decent distance away from converging on a
           particular thing to add to the spec.
  astearns: I was thinking to draft a solution based on GH thread. I'm
            not hearing objections to trying to solve this. Coming up
            with something to put into Fonts spec to limit fonts
            available to web pages
  AmeliaBR: Have text saying browsers may limit what fonts are
            exposed. Is the agreement at this point to increase the
            normative standard of that or be more specific about which
            you might want to limit or be specific about which fonts
            are safe?
  AmeliaBR: Have it defined that if a font meets these criteria the
            browser should make it available and may block access to
            all others
  astearns: It would be yes on your first two. Increase to a must
            requirements and more concretely define the restriction.
            But we're not trying to come up with list of web safe
            fonts, we're defining what browser should make available
            in terms of locally installed fonts.
  astearns: Registry we have won't have all safe, but might be
            available
  AmeliaBR: Using safe from privacy PoV not author guarantee
  astearns: Yeah. Like dbaron said in IRC we don't have a thing for
            the spec yet. Just an intent to solve the problem

  <gsnedders> do some OSes still conditionally install fonts based on
              locale? what should the behaviour be then?

  myles: One point, I don't think can make a must because involves
         non-CSS pieces of browser.
  <fantasai> +1 to myles, this would have to be a SHOULD
  astearns: Must would be font matching algorithm. Not about browser
            that might make it less restrictive
  fantasai: Should still be a should. There's CSS UAs that don't want
            to limited in this way. Like a PDF renderer which is
            trying to print local documents. This will have to be a
            should.
  fantasai: Browsers will probably follow because it makes sense to
            them
  chris: Agree it should be a should for that reason. They might have
         to opt in but we shouldn't block it.
  * fantasai notes that Ahem probably needs to be on the list
  pes: In general a should doesn't mean too much when doing privacy
       review. We're looking to see if a browser properly implements
       will they be protected. Point taken where there are places
       where privacy doesn't apply and those should be carefully
       detailed out.
  pes: The case discussed where needs to be a way to opt in is handled
       in GH issue
  pes: I've not written specs but I know in many places functionality
       is described that hooks into browser chrome so might consider
       examples like that
  fantasai: I want to point out a couple things. One is we as a WG we
            don't know all UAs that exist or will exist and we
            shouldn't make a UA non-conformant just because satisfies
            a non-browser use case.
  fantasai: Technical definition of SHOULD is [reads]
  <fantasai> RFC2119: 3. SHOULD This word, or the adjective
             "RECOMMENDED", mean that there
  <fantasai> may exist valid reasons in particular circumstances to
             ignore a
  <fantasai> particular item, but the full implications must be
             understood and
  <fantasai> carefully weighed before choosing a different course.
  fantasai: I think that's appropriate in this case
  <chris> +1 to the RFC2119 definition

  astearns: I think we should go back to GH and hammer out exact
            proposal and level of requirements. I think there's quite
            a bit of work before there's something to put in spec, but
            we should get to that. Maybe checkpoint in a month
  <dbaron> "a month" is the face-to-face, btw
  <myles> good idea, dbaron
  AmeliaBR: Sample spec text drafts would be helpful so we can start
            comparing
  astearns: dbaron reminds me we have the F2F to hammer out the last
            details and get it into spec
  chris: Sounds good way forward.
  chris: pes you should keep watching issue and we update EDs daily so
         you can see evolution of text
  astearns: Anything else on this?
  astearns: Thanks everyone

CSS Lists
=========

How should spaces be treated in markers?
----------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/4448

  oriol: Revisiting a resolution we had. I said that browsers
         seemingly do when you have an outside marker that's
         blockified and we made it explicit in the resolution so that
         if they don't have whitespace then trailing spaces are
         reserved
  <Rossen> we do the same in IE and EdgeHtml
  oriol: I had been confused by internal terminology and in Chromium
         they are inline blocks. Outside markers generate a block
         container and that's what matters. If we want to reflect
         reality maybe should weaken resolution. Say they should
         generate block containers and then leave it to impl if it's
         block or inline level
  Rossen: This is same behavior we have in EdgeHTML so I support your
          proposal
  <fantasai> wfm
  astearns: Proposal is modify previous resolution? I see point 3 in
            previous resolution that outside marker box has display
            value blockified.
  oriol: It's generates block container not blockifies. It could be an
         inline block containers.

  fantasai: I think we might clarify outside display type is undefined?
  <fantasai> https://drafts.csswg.org/css-text-4/#white-space-trim
             might also be interesting
  Rossen: Could be inline. Did that when we impl outside markers the
          first time. In order to achieve good baseline alignment for
          list items that best way to model this was to wrap the list
          item markets in anon inline blocks with appropriate offset
          and deal with them.
  Rossen: Undefined or inline. Not sure if inline will make a
          difference
  fantasai: Markers have a particular interaction with positioning and
            line positioned to. When we decide they might have their
            own display:outside value. I'm happy to have it undefined.
  fantasai: Haven't figured out the model
  Rossen: I don't want display:undefined
  fantasai: We can call it inline-block for now so gCS returns
            consistently across UAs. Not sure if that matters
  oriol: Firefox does blockify into a block box so it seems behavior
         is different in impl
  dbaron: I don't think difference is a big deal for us but should ask
          Mats
  <fantasai> I think the two options we have going forward is either
             an outer display value of 'marker' or an outer display
             value of 'inline' and a 'position' value of 'marker' ...
             or something like that.

  Rossen: Going back to the proposed resolution I think the
          understanding is well defined
  astearns: Proposal: An outside marker box does not have its display
            value blockified, it generates a block container
  astearns: Correct?
  oriol: Should we cover what Firefox does?
  oriol: You said it's not blockified, but in FF it is. Maybe should
         say it may be blockified
  astearns: Yes, sorry. Previous was it has its display value
            blockified and we're not going to require that. Will
            require it generates a block container.
  <Rossen> sgtm
  astearns: Then can figure out outside container later
  astearns: Object to reverse previous blockification requirement and
            require generating a block container

  RESOLVED: Reverse previous blockification requirement and require
            generating a block container

  oriol: Whitespaces; want to preserve by default and resolved to do
         this to assign whitespace value in user agent origin. Then
         how to handle new lines. In SVG there way a value for this;
         should we add to CSS or use White-space:pre
  fantasai: We say the value is pre for now and UA may transform to
            spaces and we can try and figure out what to do in the
            future
  astearns: Reasonable
  <Rossen> wfm
  astearns: Concerns about UA stylesheet uses pre as the value and let
            browsers opt into processing new lines?
  florian: Compat with browsers inside case? Or outside only?
  oriol: Chromium outside markers get white-space:pre but inside
         inherits. In legacy spaces were preserved. In FF if the
         content property is normal then spaces are preserved like pre
         but if you spec something other than normal it uses
         whitespace inherited from list. It's probably compat because
         Firefox and legacy chromium preserve
  fantasai: We should reduce magic switching and make it a simple
            control
  florian: Would not necessarily be magic could have pseudo class, but
           not convinced we need to
  fantasai: No, let's keep it simple.
  fantasai: Just make it pre. How many people are doing a custom
            string? Almost nobody.
  astearns: florian do you object?
  florian: No, just wanted to get it out there
  astearns: Objections to use pre as the value in UA stylesheet with
            text about poss processing new lines?

  RESOLVED: Use pre as the value in UA stylesheet with text about
            possibly processing new lines

  astearns: That's it for the year and the decade. Talk to you all
            next year
  fantasai: Can we get some FPWD published next year?
  Rossen: We can and should
  astearns: We've got next decade for that
Received on Thursday, 19 December 2019 01:01:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:53:17 UTC