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

[CSSWG] Minutes Fukuoka F2F 2019-09-17 Part VI: Writing Modes L3, CSS Fonts [css-writing-modes] [css-fonts]

From: Dael Jackson <daelcss@gmail.com>
Date: Tue, 3 Dec 2019 18:16:07 -0500
Message-ID: <CADhPm3vOO2vF7y6j6bC7r+cdT7b+YFnNR1U+472o974j8sfUAQ@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.
=========================================


Writing Modes L3
----------------

  - RESOLVED: Move CSS Writing Modes L3 to PR.
  - Issues #4026, #3095 and #2890 will be retagged to be addressed in
      L4 and this will be noted in the DoC

CSS Fonts
---------

  - RESOLVED: Remove font-variant @font-face descriptor from Fonts 3
              (Issue #2531: Remove font-variant @font-face descriptor
              from Fonts 3)
  - RESOLVED: There should be a way to use true user-preferred font
              sizes. (Issue #3708: Dynamic text size)
      - The method of achieving true font sizes was not agreed upon,
          just the intention to do it. There was a proposal for yet
          another mode switch, but also a desire not to keep adding
          permanently-used mode switches to the Web platform.
  - RESOLVED: Adopt the proposal (
https://github.com/w3c/csswg-drafts/issues/4044#issuecomment-532052266
)
              for font-stretch (Issue #4044: Vertical text doesn't
              play nicely with font-style and font-stretch)
  - There are concerns about removing access to local system fonts
      as proposed in issue #4055 (Mitigations for font based
      fingerprinting. Concerns include performance, breaking content
      for minority language users, and requiring more data download
      which is bad especially for users that have limited or metered
      bandwidth.

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

Agenda: https://wiki.csswg.org/planning/tpac-2019#agenda

Scribe: mstange

CSS Writing Modes
=================

Implementation Report and Open Issues
-------------------------------------
  <florian> https://drafts.csswg.org/css-writing-modes-3/implementation-report-2019-08
  <xfq> Current open issues (for L3):
        https://github.com/w3c/csswg-drafts/issues?q=is%3Aopen+is%3Aissue+label%3Acss-writing-modes-3

  florian: We've been working on the writing mode spec for some time.
           I've updated it since I've showed it last month.
  florian: Out of about 1000 tests, about 14 failed and 24 others
           failed. (?)
  florian: There will always be some tests that fail. We'll be fixing
           things forever.
  florian: Have we done enough fixing already to move on?

  florian: There is a number of issues that are marked in yellow,
           which are a not insignificant part of the remaining tests.
  florian: They have some patches which are about to land in Gecko so
           that they will pass.
  florian: Some tests could be split up into two tests, both of which
           will each pass in different browsers.
  florian: There are a couple legitimate failures as well.
  iank: Please don't remove tests that test intersections of features.
        Those tests are useful.
  florian: In this particular test, the two features are independent.
           The intersection is not tested.
  florian: The test results are from current Chrome Canary.
  florian: We have not done enough work on writing modes to never
           think about it again.
  florian: But I don't think any problems are in areas we believe to
           be wrong in the spec.
  florian: It's my opinion that we can move on despite those failures.

  fantasai: There are some issues about things where the spec is
            unclear, and we should just do those clarifications.
  florian: All issues are about things that ought to be better
           defined. But we need help.
  fantasai: I think it would be better to address these issues before
            saying that writing mode L3 is done.
  dbaron: I've been uncomfortable with some of the things about
          intrinsic sizing.
  dbaron: I think the third issue is more on the material and sizing
          than on the material and writing modes.
  dbaron: In response to being asked to implement something in
          Firefox, I ran into a list of conditions that was unclear.
  florian: Was this not partly answered by text that was restored?
  dbaron: I think this was after it was being restored.
  florian: fantasai discovered that some section had been lost and it
           was recovered in late August.
  dbaron: This is a specification pattern that is difficult for
          authors. Rather than saying "You want to compute X", it says
          "You calculate in the following terms".
  dbaron: It is very hard to know what some of the terms mean in a
          specific context.
  florian: I agree that this specific text should be tweaked. But the
           level of writing in L3 is higher than in L2. Raising the
           bar of writing is good, but gating specs on that bar might
           not be necessary.
  florian: Can we address this in L4?
  dbaron: I guess. L2.2 probably did not have backward references to
          things that were poorly defined to the degree that L3 does.

  Rossen: How do we move writing modes forward?
  Rossen: Do we actually want to hold off and resolve on these issues
          with additional spec works and re-enter PR at a later time?
  fantasai: With the exception of some tweaks, Gecko seems to have
            implemented this just fine.
  fantasai: We are basically rewriting all of CSS 2, but we need to do
            it in pieces. The current writing is not ideal, but it is
            the best I could do without rewriting CSS2 chapters 8/9/10.
  AmeliaBR: Given that fantasai has said that Gecko is right, could
            dbaron suggest new text that describes that & addresses
            his issues (in time for publication)
  dbaron: The hard part is the edge cases. The question is not, "Do we
          follow this list of things in simple case X which is being
          tested", it's "what is the exact list of cases where we need
          to do this list of things"
  Rossen: We almost went into Rec two or three years ago. I think the
          level of the spec is fairly high at this point.
  dbaron: I'm ok moving forward if you want, but there are cases that
          are not defined enough to be implementable in an
          interoperable way.
  fantasai: This spec was written assuming grid and flexbox do not
            exist. We can't make this gate on defining exactly how
            things work in grid and flexbox.
  dbaron: It would be nice to give an example where this list doesn't
          apply.
  fantasai: I don't know of one.
  dbaron: That's why I suggested stating in the spec that it always
          applies.
  fantasai: Ah, the case was about computing max-content inline-size
            vs auto block box inline size: in latter case, it's not
            well-defined what max-content computation is in CSS2, so
            could be conceptually that available size is infinite, and
            it's OK. But auto width computation needs definite length
            to subtract margin/padding/border from and result in
            non-infinite content-box width, so can't use infinity, so
            have to use fallback size

  Rossen: The proposal was not to resolve the issues, it was to move
          them and retag them for L4.
  Rossen: Any objects to retagging the three issues to level 4? Those
          are 4026 3095 and 2890.
  <astearns> and they will need to be added/updated in the DOC
  Rossen: No objections. We will move these issues to be tracked
          under L4.
  Rossen: Are there any objections to move CSS writing mode Level 3 to
          PR?
  Rossen: No objections, resolved.
  <xfq> \o/

  RESOLVED: Move CSS Writing Modes L3 to PR.

CSS Fonts
=========

Remove font-variant @font-face descriptor from Fonts 3
------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/2531

  myles: We have two text paths. In WebKit. The distinction which path
         to go to has to happen before font fallback.
  myles: Sometimes we detect something too late and can't go back and
         re-do everything, so we just do our best.
  myles: If this is not necessary for the web platform, let's remove
         it.
  fantasai: It does look like there is an implementation (faceless2
            says it in the issue)
  fantasai: If the feature doesn't have a problem, we should leave it.
            We do not need implementations to move this spec at the
            moment.
  myles: When is the deadline? It's been years.

  Rossen: This is a non-verifiable implementation. How do we evaluate
          it?
  drott: We would support removing it because the semantics are
         unclear in some cases.
  heycam: We would also be fine with removing it. We haven't heard
          much demand from authors.
  heycam: In principle it seems like a useful thing, but we would be
          fine with removing it.
  Rossen: Any objections to removing it?
  Rossen: No objections.

  RESOLVED: Remove font-variant @font-face descriptor from Fonts 3

Mitigations for font based fingerprinting
-----------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/4055

  chris: The issue is that you can pretty much identify individuals
         based on the set of installed fonts.
  chris: For example, I have all CSS test fonts installed and some
         fonts for languages I don't speak, and that identifies me
         uniquely.
  chris: One proposal was to only report fonts that are the standard
         fonts for that platform.
  chris: But this would cause you to re-download fonts you already
         have.
  chris: This consumes unnecessary bandwidth.
  florian: On some OSes, even the set of default fonts can almost
           uniquely identify you.
  myles: It is impossible for the spec to describe the set of default
         fonts.
  myles: The proposal is to say in the spec that browsers must have
         some affordances to protect user privacy by having some sort
         of (?)
  florian: On the performance vs privacy question, I lean towards
           privacy. On performance vs internationalization, it's less
           clear: If you don't have the font for a particular language
           and can't read the text, that's bad.
  chris: There is a strong web compat problem here. Things that used
         to work should not break.
  florian: When working means look pretty, there's a trade-off. When
           it means you cannot read it, it's different.

  <fantasai> It was also pointed out that downloading fonts can cost
             money in some areas, and this is more likely to be the
             case in areas which are more likely to use minority
             languages and which have less money to spend

  myles: WebKit has been doing this for over a year. We discard
         user-installed fonts from lookup in CSS
  florian: Mongolian without fonts is unreadable.
  florian: When it is readable, removing the fonts breaks it.
  myles: It's a trade-off.
  thomas: How did you choose that list of fonts?
  myles: I commented on the issue.
  thomas: Rather than a bespoke list, could we come up with a list
          that can be updated periodically? Some list that covers
          languages for i18n use cases, as well as some fonts that are
          installed on machines.

  ?: Why do we have an API to return list of fonts?
  iank: The information about fonts is queryable by measuring the
        bounds of boxes, without getting the list of fonts from an API.
  Rossen: We will pause the discussion of this issue and unpause it
          after the break.

Dynamic text size
-----------------
  github: https://github.com/w3c/csswg-drafts/issues/3708

  jcraig: For a long time we've had scalable fonts that are based on
          the Desktop Web.
  jcraig: It took us a while to make it work on all extreme cases.
  jcraig: We would like to support low vision users who have extremely
          large text sizes.
  jcraig: But forcing such giant font sizes on web pages would make
          most web pages unreadable.
  jcraig: We would like to have a way to opt in to larger font sizes
  jcraig: as an author.
  jcraig: We would also like to propose a feature that allows web
          pages to detect large font sizes and adjust the sizes of
          other elements.
  jcraig: We have some aspects of this that are available today: You
          could detect based on min-width in ems, but that does not
          work consistently.
  jcraig: Right now there is no standard way to opt in to this that
          works across all browsers.
  jcraig: Most browsers on mobile systems don't want to break their
          users' layout.
  jcraig: We have examples where it would be very difficult or even
          impossible to achieve the intended layouts today.
  jcraig: [demo]
  jcraig: I have applied iOS settings that render text extremely large
          and bold.
  jcraig: I can show how different apps deal with this setting.
  jcraig: Calendar switches to 3 or 2 column layouts.
  jcraig: The Books app switches from a 2 column layout to a single
          column layout.
  jcraig: In Mail, with larger font sizes, the title gets clipped but
          the email's time is preserved.

  <fantasai> These are all very easy to do if you have flexbox/grid
             and correctly implement media queries in em units
  <fantasai> or ch units
  fantasai: Is the problem that we can't actually implement media
            queries with accurate em and ch units because the web
            would break, but you want to have media queries with
            em and ch units?
  fantasai: Everything you've demonstrated here is totally possible
            with em and ch units in media queries.
  fantasai: On mobile you're not returning the correct values because
            that would break. So what you're saying is you want real
            units?
  jcraig: What we want is an ability for an author to say "I can
          handle any font size you throw at me."

  florian: How possible is that this signal becomes worthless over
           time as it gets copied around, and we need to add still
           another signal?
  chris: People are rapidly going to find out that just copying this
         around will break them.
  jcraig: The reason we don't turn this on by default is that web
          developers *don't* find out that it breaks them.
  jcraig: They haven't turned on these large fonts on their system.
  <chris> fair point, retracted

  jcraig: The first part of what we need is the opt in to the higher
          font sizes. The second part is the media query part.
  fantasai: In order to do the kind of layout transformations you
            want, you also have to know how many letters fit on the
            screen. You'd use the min-width query with ch.
  jcraig: That would get us some of the way.
  fantasai: Having just a media query for the font size itself is not
            enough if you can't relate it to the size of the viewport.
  florian: You can't compare the font size and the viewport because
           the lengths have different units.
  florian: The thing you call an opt-in would also opt in the media
           queries to behave properly.
  florian: Whichever opt-in we have needs to opt in both to behave how
           things were originally intended.
  <AmeliaBR> `@media (min-height: 10em)` only works if the window root
             em size is accurate. So if we don't reveal the accurate
             preferred em value except in an environment value, you'd
             need to use `@media (min-height: calc(10*env(
             user-font-size)) )`

  fremy: If you have a user font size variable, you can use calc to
         obtain the right answer.
  fantasai: As an environment variable, it would work out.
  fantasai: But Firefox uses different font-sizes for different
            languages, so it would be multiple variables, not one
            variable.
  fantasai: The size of ch is dependent on the initial font, not on
            the font that is used.
  florian: There is a number of ways you can use environment variables
           to do what you want, but if the opt-in mechanism opted in
           everything, it would also work.
  florian: Is there reason to exclude media queries from the opt in?
  jcraig: It should not be excluded.
  fremy: You want to be able to opt in only parts of a web site.
  fremy: If the developer in the iframe did the work to deal with
         large fonts, if it is embedded in another website that does
         not handle them, all the work is for nothing.
  jcraig: The reverse is also true.
  fantasai: If the widget is inheriting the font from the parent
            document, then it's going to have problems if the parent
            document picks a larger font, regardless.

  fremy: You cannot say media queries behave differently for different
         parts of the same document.
  florian: Yes, if you put a responsive widget into a non-responsive
           website, then yes, your responsiveness is wasted.

  jcraig: It sounds like we're agreeing that it would be useful to
          have an opt-in for websites to express that they can handle
          large font sizes.
  florian: And we do not agree on the media query part - depending on
           how we do the opt-in switch, that switch may also opt in
           media queries automatically.
  florian: If we can't make the existing media queries work, we maybe
           need to add more media queries.
  jcraig: That sounds reasonable. Once we have an opt-in we can
          experiment and see in what cases it's not good enough.

  AmeliaBR: Having it in CSS would be better than having it in markup
            because you can put it into one shared stylesheet.
  AmeliaBR: In order to get useful media queries, the opt in has to be
            outside of a property.
  AmeliaBR: If somebody has explicitly set this opt in value, then the
            existing font-size keywords that were supposed to be
            relative to the user-chosen default font size can actually
            do that.
  AmeliaBR: Otherwise, the default size will be the legacy 16px.
  jcraig: I think that sounds ok. But a new media query would be
          clearer in terms of what we want to communicate to authors.
  jcraig: Without that, the complexity of doing layouts based on width
          and layouts based on font-size is going to result in lots of
          media query blocks. (?)

  Rossen: We need to work towards a resolution.

  plinss: I'm concerned about adding yet another mode switch. Mode
          switches are bad. Can we do the right thing without a switch?
  fantasai: I hate meta tags because you can't put them in a
            stylesheet and link them from everywhere.
  fantasai: However, it seems to make the most sense to add this as a
            meta tag because it affects media queries and the initial
            containing block size.
  fantasai: And once the mode has been switched, font sizes and
            everything else can start working the way initially
            intended.
  fantasai: These things all belong together so we should just tack on
            to the meta viewport tag.

  Rossen: I do not hear agreement on exact technicalities.
  Rossen: Let's have a resolution on having a way to opt in, even if
          we don't have the exact way of doing it.
  Rossen: Objections on opting in to true user font sizes?

  jcraig: We (Apple) tried to do this without a mode switch, by
          default, and all 200 000 apps broke.
  jcraig: Even with an opt-in switch, it took years for all first
          party apps to support this mode.

  plinss: ...
  fantasai: I don't like mode switches either, but the alternative is
            to add an entire duplicate set of font-relative length
            units. A mode switch is a lot simpler.
  AmeliaBR: I came in with the same concerns as plinss, but one thing
            I did bring up was that, at the user agent level, there
            should be reflection of the fact that there are two
            classes of users.
  AmeliaBR: Some users want fonts that don't want broken web pages,
            and some users want readable fonts even if pages are
            broken.
  AmeliaBR: It seems that most users will accept smaller fonts if it
            means that pages are not broken.
  plinss: I have no concerns with a user switch. I have concerns with
          adding a switch to the web platform.
  plinss: If we have to commit this in again of adding another mode
          switch, let's add it in a way that it can fade away in the
          future, and not such that content will break if authors
          don't anticipate the switch.
  plinss: There is real costs to adding mode switches.
  myles: The resolution seems to be about intention, not
         implementation. Let's try to agree on that.
  Rossen: Objections to having the option to have true font sizes?

  RESOLVED: There should be a way to have true user-preferred font
            sizes.

  <break>

Vertical text doesn't play nicely with font-style and font-stretch
------------------------------------------------------------------
  Scribe: emilio
  github: https://github.com/w3c/csswg-drafts/issues/4044

  nmccully: CJK text differs from latin because of the multiple
            orientations
  nmccully: because of that multiple features related to the line
            width become quite complex
  nmccully: [explains example in the issue]
  nmccully: depending on the glyph orientation glyphs get stretched in
            different directions
  nmccully: As a user is backwards, as an implementor you need to poke
            at the internal characters
  nmccully: while the feature is about stretching the whole line

  myles: This was discussed in OpenType and there was some discussion
  myles: The font can't know how to do it right and there's an
         opentype feature that only gets applied to upright characters
  myles: but it's pretty hard to set up
  myles: So opentype would introduce a new axis
  myles: have both vertical and horizontal width
  myles: and the application would set the relevant vertical /
         horizontal axis depending on whether the glyph is upright or
         not
  myles: No resolutions anywhere yet but need to move it together
  myles: So we need font-face descriptor to say that it supports
         stretching in the vertical axis or not
  myles: So plan is to extend font-stretch to specify using a
         `vertical` direction that it's stretched in the vertical axis
  myles: The font-stretch property wouldn't change syntax, but it'd
         change behavior
  myles: rotating the font in the appropriate direction
  myles: which means that writing-mode and text-combine and such would
         also be inputs to the font selection algorithm
  myles: because if it's vertical it'd need to download the font that
         can expand in the vertical axes

  myles: Thoughts?
  fantasai: sgtm
  leaverou: Would the property change?
  myles: The property has no grammar change but has behavior change
  nmccully: You may need it for TCY
  myles: The system I'm describing would either select an horizontal
         or vertical font, but it's important that fonts can support
         both so you don't require different files for fonts that
         support both japanese and latin scripts
  myles: Everything I've said also applies to font-style (for the
         italic angle)

  koji: What's the syntax proposal?
  myles: [explains proposal in the issue:
          https://github.com/w3c/csswg-drafts/issues/4044#issuecomment-532052266
]
  myles: The OpenType piece is that we need to standardize a new axis
         for vertical width and for non-vertical font you also need a
         vertical width
  nmccully: Adobe has formed an opinion already and has a prototype
  koji: Should it be physical or logical?
  fantasai: For font needs to be physical
  fantasai: When you're typesetting vertical text you mix both upright
            and rotated characters, so stretch axis from the glyph's
            perspective depends on the uprightness
  fantasai: Upright chars get "longer" in the vertical axes, sideways
            keeps the same height but stretches horizontally
  fantasai: so for the font descriptor it needs to be physical and the
            property is logical and only applies in the inline
            direction
  koji: So you're saying physical to line orientation not to glyph
        orientation
  fantasai: font-stretch is line-relative and the font-stretch
            capability in the font file is physical relative to the
            glyph orientation
  myles: [explains that in a different way]
  koji: agree

  heycam: I think proposal makes sense, I'd like to understand how
          authors can achieve this without this feature and how
          difficult that is compared to the font
  nmccully: The browser would have to know how each browser treats the
            font (regarding upright-ness)
  nmccully: Then go browser by browser and change fonts per rune
  heycam: So part of the issue is that browsers disagree on that,
          right? (fantasai mentioned punctuation before)
  fantasai: Yeah, even by that is a per-codepoint thing
  fantasai: The initial values of text-orientation is mixed by
            default, the author would have to do the automated
            determination of rotated vs. not for the particular font
  fantasai: Way too much work to request on an author, requires lots
            of inline markup around punctuation also
  nmccully: It's mixing two things, whether something is sideways is
            not the author decision
  nmcully: it's automated based in unicode-range
  heycam: Oh I assumed that authors would have expectations and
          browsers would be consistent
  fantasai: I think this is the right design, I think it works great
            for font-stretch
  fantasai: for oblique and such it may not

  myles: There's another piece. Today if you say font-style: italic on
         vertical text you'll get weird stuff
  myles: this proposal will fix that
  fantasai: Don't we have a resolution on that?
  florian: I think hiroshi wanted to reopen that
  florian: but didn't because nobody seemed to run into a spec
  Rossen: Would this change this resolution?
  florian: Only if we apply it to font-style

  fantasai: I think we may have a font-stretch-vertical descriptor
            rather than stashing it on font-stretch
  fantasai: but that's more bikeshedding and I generally agree with
            the proposal
  Rossen: Objections to adopt this?

  RESOLVED: Adopt the proposal for font-stretch

Mitigations for font based fingerprinting
-----------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/4055

  TabAtkins: [introduces the issue]
  TabAtkins: We expose a lot of PI data on the web
  TabAtkins: Even if you plug fonts we're probably not below the level
             where you cannot identify a single user
  TabAtkins: to do that you probably need to do software rendering on
             canvas for example
  TabAtkins: so unless somebody comes up with a list of stuff and data
  TabAtkins: I think we shouldn't do that
  TabAtkins: A bit annoying from a PR standpoint to argue why it
             doesn't really matter but...

  myles: Our goal is to remove all the sources of fingerprinting on
         the web
  myles: We should reduce as much as possible
  TabAtkins: You cannot remove all of them
  TabAtkins: no media queries, etc..
  TabAtkins: Unless you could reduce it to 20 bits or less, you haven't
             accomplished anything
  myles: Well you're closer to the goal
  [funny metaphors]
  TabAtkins: Going from "individually identify someone" to
             "individually identify someone" does nothing
  TabAtkins: there's a specific threshold we need to reach to do
             anything
  TabAtkins: and nobody can
  myles: We'll try

  dino: I really believe we should ask the question for each feature
        of what the cost is
  dino: I accept what TabAtkins says about the number of bits
  dino: but it's this group's duty to do the cost of the feature vs.
        the privacy impact
  florian: Cost is breaking the web for minority languages, benefit is
           not clear yet

  TabAtkins: W3C has the privacy interest group working on this, if
             their conclusion is that we can hit this range by doing
             this
  TabAtkins: then happy to
  plinss: Every time we add a bit we make it that much harder, if we
          throw our hands up in the air then sure, let's add
          identifiers
  thomas: There's also ways to alert the user it's being fingerprinted

  nmccully: I'm hearing mostly that it's not the right fix. We
            shouldn't make it worse but...
  myles: Our job is to design CSS APIs and we have to weigh pros and
         cons. We found that font-based fingerprinting is one of the
         most unique ways users are fingerprinted. We also found that
         it doesn't affect most users' experience
  myles: so pros and cons seem clear here
  emilio: I agree with myles

  leaverou: Lots of old sites rely on common fonts like Calibri or
            Cambria installed
  leaverou: also there's a perf impact of always downloading the font
            since sites tend to use `local()`

  Glenn: Are we getting ahead of the game between standards and impls
  myles: The spec can't do much here
  myles: We are a standardization group, we can't do more that saying
         in the spec that should have privacy considerations
  myles: but browsers like Safari can and have gone further

  florian: So you mentioned that you investigated the amount of sites
  florian: that broke or not
  florian: If you're removing language support minority users can't
           use the web
  florian: also bandwidth may be a concern
  florian: I don't care if sites are slightly slower for Californians

  myles: Having philosophical discussions is not particularly useful
  myles: we need a concrete proposal
  myles: and there's nothing to resolve on until there's one
  myles: The spec already says that a UA may or not scan all fonts in
         the system
Received on Tuesday, 3 December 2019 23:17:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:14 UTC