W3C home > Mailing lists > Public > www-style@w3.org > February 2020

[CSSWG] Minutes A Coruña F2F 2020-01-24 Part I: CSS Fonts, CSS Text, CSS Text Decor, CSS Ruby [css-fonts] [css-text] [css-text-decor] [css-ruby]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 19 Feb 2020 19:51:13 -0500
Message-ID: <CADhPm3swSrfCEGUsFiOwZAOBPxEOz6tA44qMvnC02YbC6fkqHQ@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.
=========================================


CSS Fonts
---------

  - The group is very interested in addressing the privacy/
      fingerprinting concern raised in issue #4497 (Limit local fonts
      to those selected by users in browser settings (or other browser
      chrome)), however agreed it will need to be a SHOULD
      requirements since CSS-PDF renderers have a valid use case to
      not conform to this requirement, and because it will take time
      and experience to work out the requirements more exactly.
  - An additional complication will be a need to define what the
      system OS fonts are; each OS has this data available in a
      different way.
  - ChrisL volunteered to work with pes in drafting up initial
      proposed text to add to the Fonts spec. The group will review
      this text on the next call after the F2F.

CSS Text
--------

  - RESOLVED: Disallow before hyphen in normal and strict. Allow break
              between ID and hyphen in loose. This means Kanji+Hyphen
              breaks; and Alphabetic+Hyphen doesn't break, unless
              word-break:break-all makes Alphabetic behave like ID.
              (Issue #4419: Line breaking for ambiguous characters;
              e.g., U+2010, U+2013)

CSS Text Decor
--------------

  - RESOLVED: Fully specify an algorithm that specifies ink skipping
              that references other specifications that isn't
              codepoint-by-codepoint (Issue #4276: Clarifying
              skip-ink:auto behavior in relation to CJK text)
      - jfkthame will write up the spec text for group review.

CSS Ruby
--------

  - RESOLVED: ruby-overhang auto | none on ruby container (Issue
              #4492: Ruby overhang control)

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

Agenda: https://wiki.csswg.org/planning/galicia-2020

Present:
  Rachel Andrew, Fronteers
  Rossen Atanassov, Microsoft
  Tab Atkins, Google
  L. David Baron, Mozilla
  Amelia Bellamy-Royds, Invited Expert
  Christian Biesinger, Google
  Mike Bremford, BFO
  Oriol Brufau, Igalia
  Tantek Çelik, Mozilla
  Emilio Cobos, Mozilla
  Elika Etemad, Invited Expert
  Javier Fernandez, Igalia
  Koji Ishii, Google
  Brian Kardell, Igalia and OpenJSF
  Jonathan Kew, Mozilla
  Ian Kilpatrick, Google
  Chris Lilley, W3C
  Stanton Marcum, Amazon
  Myles Maxfield, apple
  Cameron McCormack, Mozilla
  Tess O'Connor, apple
  Manuel Rego, Igalia
  François REMY, Invited Expert
  Florian Rivoal, Invited Expert
  Hiroshi Sakakibara, BPS
  Jen Simmons, Mozilla
  Alan Stearns, Adobe
  Lea Verou, Invited Expert

Scribe: faceless

CSS Fonts
=========

Limiting local fonts
--------------------
  github: https://github.com/w3c/csswg-drafts/issues/4497

  pes: This is talking about font fingerprinting by identifying the
       computer based on which fonts are installed on the computer
  pes: One suggestion is to list a document which describes a list of
       specific fonts
  myles: I asked about what pete wanted to discuss that wasn't on a
         previous call
  <astearns> (from the last discussion: 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: One of the questions was to what extent this would be
          allowed vs recommended vs mandatory. I am comfortable with
          recommended not sure about mandatory partly because we don't
          know exactly what we're trying to do. open questions.
  dbaron: I think we should allow this
  myles: AT already does
  dbaron: [...] to recommend this, and work on adding detail to the
          recommendation. When we're comfortable with the level of
          detail there, we can mandate this, but there are lots of
          open questions
  dbaron: eg. effects on linguistic minorities, across OSes, etc.
  myles: If we don't make mandatory but do make recommended, would be
         good to hear from all present if we should change behavior
  pes: webkit is even safer than this, webkit won't load some fonts
       off disk
  dbaron: Maybe Jonathon can speak more authoritatively on this but we
          support a larger number of platforms and on some of those
          this might be more difficult to do on some platforms than
          others

  fantasai: I wanted to say there are classes of user agents where
            this makes no sense. eg css-pdf renderers, which need to
            access all fonts on the system
  chrisL: localhost could have access to all of them
  chrisL: css to pdf renderers have the ability to opt in to lists of
          fonts per site, which makes it more possible to opt out (as
          in opt out of fonts per domain)
  <chris> although I wasn't just speaking of css to pdf renderers

  myles: As an engineer I am always thinking about how we can test
         this, but if there's going to be no changes on the file
         system this will be untestable
  pes: Initial proposal was all this should be dealt with by the
       browser opting in
  pes: If the takeaway is that the idea is useful but nothing is
       required at this point, I don't think that's any change from
       the status quo
  fantasai: A SHOULD requirement is not a no-op
  fantasi: It recommends action and it may be appropriate in this case.
  myles: But if no-one acts on that recommendation what's the point of
         it?
  fantasai: User agents don't always act on hard recommendations
            either.
  <chris> 3. SHOULD This word, or the adjective "RECOMMENDED", mean
          that there may exist valid reasons in particular
          circumstances to ignore a particular item, but the full
          implications must be understood and carefully weighed before
          choosing a different course.
  <fantasai> https://tools.ietf.org/html/rfc2119
  fantasai: Should means if you have a good reason not to do it, you
            don't have to do it. But you need a good reason.

  <TabAtkins> If necessary I can state this at some point, but I
              believe Chrome's position is that we extremely want to
              stop fingerprinting as an identification vector, but I
              don't think that designing a solution in a committee
              with this skill set is appropriate. (There are groups in
              W3C (or elsewhere?) that are more appropriate and
              contain people with the right set of skills.)

  myles: To paraphrase fantasai: we can put a should and say all
         browsers should do this, or we can make a partition and say
         some browsers must, some must not.
  myles: Pete said first option was a thumbs down
  pes: If there's an option that is available to the user to access
       all local fonts, that's ok
  fantasai: I would imagine you would object to this being turned on
            by default. But css-pdf renderers would have to turn this
            on by default
  pes: Doesn't have to be that way. If you're saving documents off
       disk, for example, it could be off
  chrisL: Could you explain the harm of the status quo where someone
          on their own disk converts a file locally
  pes: That's not what I mean
  florian: So if we don't mean everyone has to do this, then lets not
           say everyone
  <fantasai> you MUST NOT use any fonts that are not either part of
             the OS-default set or downloaded by the page itself
  pes: It seems like this must not be a new idea - there are cases
       where apps using HTML renderers have one set of rules, browsers
       have others
  heycam: We do
  [but we don't like it]
  <heycam> different conformance classes for selectors (fast profile)
  florian: SHOULD means you have to do it unless there is a good
           reason, but good reasons do exist and if you have them you
           won't be non-conformant. You won't be arrested for not
           doing it under SHOULD, but neither would you be under MUST

  pes: Who's planning on doing what?
  pes: It's pretty important we get this sorted out so we can get the
       cross-browser expectations to users
  TabAtkins: Especially given recent information fingerprinting in
             side channels is a very tricky thing to do and we don't
             have the expertise in this committee so I'd object to
             putting a "must" on this as I don't think we have the
             ability to do it ourselves
  TabAtkins: While it's very important and needs doing, I don't want
             to put anything binding on this committee
  <astearns> and a 'should' allows all non-Chrome browsers to do the
             thing and eventually make it more likely for them to bend
  <tantek> note that "print formatters" are also "normal browsers" in
           Print Preview mode
  <florian> +1 to tantek
  florian: We could put a note on this clarifying the intent to
           explain why a should recommendation is there and who should
           follow it

  pes: Surely we do have the expertise
  TabAtkins: I'm talking specifically about the CSSWG - the goal of
             reducing fingerprinting is 100% our goal, but Chrome
             doesn't want to bind themselves to a MUST resolution
  pes: If you aren't the people to ask, who is?
  <tantek> we really need to capture as much as we can in the issue,
           and then reach out more broadly than the WG
  TabAtkins: We have engineers who are working on this and have the
             expertise on this, but none of this in this group have
             the expertise
  <tantek> sounds like this discussion is going in circles

  hober: You have co-chairs of ping and the privacy cg in this room,
         and Pete is not coming to us as an individual - this is a
         concern from a number of people in this area. As a member
         consortium it's the responsibility of this group that we have
         people who can speak on these issues. So it's disheartening
         to hear you don't want to consider this because we don't have
         the expertise. Part of our role is to make sure the right
         people are here.
  TabAtkins: Yes I understand but this is the only privacy issues on
             this point, it's not appropriate to invite the security
             team to be here
  TabAtkins: I'm not the right person, none of here are.
  <TabAtkins> I think the PING/etc are the right venues for this
              discussion, not the CSSWG.
  <hober> TabAtkins, PING came to us with this!
  <TabAtkins> This needs to be "privacy teams, with a font-related
              engineer on call", not "a bunch of layout/etc engineers,
              with a privacy engineer on call"
  <TabAtkins> hober, Sure, and I'm saying that looking to this group
              for binding resolutions on this topic isn't appropriate.
              We own a spec with a feature that will be impacted; that
              doesn't mean we should be designing the change, just
              ensuring that it's integrated and well-explained when
              it's finished.

  * tantek reviews https://drafts.csswg.org/css-fonts/#priv-sec
  <tantek> LOL: one-line S&P section in css-fonts 4: "The system-ui
           keyword exposes the operating system’s default system UI
           font to fingerprinting mechanisms."
  <myles> tantek, I don't think I wrote that
  <tantek> presumably we are talking about more than just system fonts

  rossen: [calls order]
  dbaron: Pete asked who are the right people. I think sort of a weird
          question, given the response we're trying for. I think we
          are the right people, but the misunderstanding that leads
          Pete to ask this question is that it's not a short process
  dbaron: We're trying to make a substantial change to the way this
          works on the web platform. It's a process that requires
          proposal, iteration, requirements
  dbaron: [is more emphatic]
  dbaron: We're trying to do this thing that requires iteration and
          refinement of a proposal, and what we're saying is "yes,
          we're accepting that this is the next stage of the process
          and it's worth pursuing"
  dbaron: but Pete is saying that's not the right thing - we need to
          have a solution now. But we haven't had the conversation
          that we need to have first. So we're basically saying yes to
          it, but we have to begin the process
  dbaron: I think that disconnect is why we're stuck
  pes: With respect this was filed in June. There has not been
       counter-proposal since then
  pes: This is the #1 privacy issues on the web
  rossen: We understand and we recognize the urgency but the reality
          is there is a backlog
  rossen: The fact it was filed a while back doesn't mean it's not
          important to us
  <TabAtkins> See, for example, how we were just spitballing about how
              to design a font list and how to segregate it. We don't
              have the expertise to do that; we can't get "close
              enough". It has to be done *right*, and we're not the
              group to do that.
  pes: I want to know what the next steps are. If there's a process,
       what is it, what is the timeline?
  rossen: One of the proposals is to resolve with accepting this as a
          SHOULD statement.
  astearns: The spec has this currently as a MAY?
  <chris> the current "MAY" has a lot less detail
  myles: Yes, what Pete is aiming for is different
  rossen: Can we take the resolution now that changing the current
          definition to a SHOULD and live with that?
  myles: Not unless someone can state what the SHOULD should say.
  <tantek> agreed I want to see the full statement here in the minutes
  florian: [agrees with myles]
  <tantek> +1 myles

  florian: You asked about next steps, the relevant user agents will
           attempt to do it once the SHOULD has been framed properly
  florian: After that, once the user-agents implement, we'll get
           feedback and see what to do then
  florian: Maybe we will find a line to draw to make a distinction,
           i.e. user agents loading from the file system. but we don't
           have that information now
  chrisL: Pete if you're happy to make a first draft of the SHOULD
          recommendation I'm very happy to work with you on this
  pes: Happy to, but is there a rough timeline, and also the current
       proposal points to a list maintained elsewhere. Is that the way
       we want to keep things?

  rossen: ok first issue. Do we want to stick with a list that is
          maintained elsewhere
  dbaron: A list of what?
  TabAtkins: local fonts that are allowed
  florian: The current spec is a list of things which are ok, - fonts
  florain: I think we should write the list down, put it wherever,
           once we have figured it out we can worry about where to put
           it later
  <heycam> +1 don't think where the list lives is the first thing to
           worry about here
  jkew: It's not clear whether this group maintaining a list is the
        right approach or whether we should look into platform APIs
        exist to determine which fonts are platform installed vs user
        installed.
  jkew: It seems like maintaining a list is a never-ending nightmare.
        Maybe OS vendors should maintain the list? I'm not sure it's
        realistic that we maintain it.
  florian: No macOS API will give you that list. We should start with
           a list and once we've written it, we can debate the proposal
  rossen: Let's try to find something actionable
  pes: I understand the reticence against a list and wanting something
       easier to maintain.
  dbaron: To respond to jkew and pes - list is maybe too specific a
          term. We should be describing what we want to do and on each
          platform there may be a different approach - an API, a list,
          it's the intent that matters.
  dbaron: The main thing is that we try this and see what works.
  <tantek> +1 dbaron
  dbaron: I don't think we know what the best thing to do is yet. We
          can't specify this with the right level of detail on each
          platform, we need to allow for feedback from each platform
          to find the best solution

  <pes> what is the road to get to the right answer then?
  <tantek> pes, where's the proposal? can you link it?
  <tantek> start with that
  <pes> this is not a new issue / problem. An outcome that is “vendors
        will look into it”, this is not progress
  <pes> [tantek : initial issue / concern
https://github.com/w3c/csswg-drafts/issues/4055,
        follow up proposal: https://github.com/w3c/csswg-drafts/issues/4497]
  <astearns> pes this not a new issue/problem, but it is a new
             solution. Looking into things is progress set against the
             status quo
  <tantek> pes, I think we're at the point where we need sample spec
           text proposed in the issue. Just reviewed the proposal bits
           and looks a bit scattered TBH
  <tantek> pes, I'm not disagreeing with the issue. I read through
           #4497 and the proposal there is more of an outline of
           desired outcome
  <pes> tantek: this might be closer to what you’re looking for
        https://github.com/w3c/csswg-drafts/issues/4497#issuecomment-565832611
  <tantek> pes, that's a very good summary start. Now, where in the
           spec would you put that, and can you reword it procedurally
           as a set of steps that browser should/must follow?
  <pes> tantek: on it :)
  <tantek> pes, related, you may be interested in contributing to
           https://github.com/w3c/csswg-drafts/issues/4697

  myles: First, responding to florian: feels florian was assuming that
         there was a single set of fonts common to everyone. We don't
         do that - we have different sets for different parts of the
         world.
  myles: So even just for us, we can't have a single list that is
         uniform.
  myles: so we certainly can't across all OSes
  florian: I was saying the current proposal specifies a single list,
           but that's probably not ideal. But that's our start point
           as it's in the spec.
  myles: There is no list for our platforms about what the currently
         available fonts are - we use an API.

  rossen: Next steps. Pete is going to take a stab at moving the
          current statement from a MAY to a more strict version of
          SHOULD
  rossen: and the technical recommendations of how to reference those
          fonts, dbaron said this well - referring to this as a list
          is not the full picture. But it is a start
  rossen: Once we have the actual proposal we can try to narrow down
          the technical solution
  rossen: Anything else?
  rossen: Pete, we're not trying to sandbag this - it's a normal
          process. We are interested in this and that might not be
          clear. Bear with us and once you have the actionable
          definition we'll go from there
  rossen: I suggest we end this and move on and will come back to it
          once Pete has acted? On the next call?
  pes: When is that?
  rossen: Probably two weeks
  rossen: Thanks for your engagement
  <dbaron> The calls are Wednesdays at 9am California time / noon
           Boston time / etc.

CSS Text Decor
==============

Clarifying skip-ink:auto behavior in relation to CJK text
---------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/4276

  jkew: The issue is about text-decoration-skip-ink, browser have
        chosen generally not to apply this to CJK text because in
        practice it clashes with most of the glyphs and looks terrible.
  jkew: What troubles me is that the webkit/chrome have chosen to skip
        this for a particular set of glyphs, but there's a disconnect
        as to which glyphs are skipped. In particular Blink has chosen
        to skip a number of punctuation characters
  jkew: I was hoping that the spec could pin this down to work on a
        sequence of script characters, so that punctuation surrounded
        by CJK is CJK.
  jkew: I'd like to settle on what we do in Firefox, which is better.
        At the moment the spec doesn't define it

  myles: Consistency is good but what the motivation? bug reports?
  jkew: I'm sure we did have reports
  myles: When you started implementing? Or was it issues around the
         specific characters?
  jkew: Initially we simply implemented and found the same issues in
        CJK as everyone else
  myles: In the absence of specific bug reports and users are not
         complaining, maybe we should leave it as it is?
  jensimmons: Can we perhaps specify it and see what comes from that?
  jensimmons: Is the desire of one browser to not put in the effort a
              reason to not spec interop. If interop on this is ideal,
              we can spec it and then each browser can make decisions
              about prioritization.
  koji: I'm generally with myles on this. We had reports that our
        slashes looked quite bad. When looking at gecko they don't
        look bad
  koji: So I believe we should add slashes to the list. So this is a
        heuristic. It's not testable. But I understand that if gecko
        gets reports that says the inconsistency is troubling then
        this is an issue

  florian: The spec is very vague, it says you can skip but not why.
           Even if we don't go all the way to defining a list, we may
           want to clarify the intent of this. That will not help with
           the immediate concern about interop, but it will help for
           anyone trying to understand or implement this
  myles: I can add some text about that
  dbaron: I think the situation today is if we don't define things,
          everyone will just copy what Chrome does. So if what Chrome
          does is right, let's put that in the spec as we're going to
          copy it anyway. If not, put in the spec what is right.
  myles: I'm not keen on that idea
  TabAtkins: If we do whatever Chrome does, it should be an choice
             made because Chrome is doing the right thing. I want
             something written down because it will be a compat issue
  myles: If no-one has bug reports, it's not a compat issue yet. Maybe
         we wait until the first report
  TabAtkins: We have enough issues to know that's not the best approach
  dbaron: We've found that compat constraints get stricter over time.
          The longer things are out on the web, they require interop
          and expect it to get better over time. So if we find things
          that aren't we should fix that early
  dbaron: With the lack of bug reports, we have a cultural bias -
          filing them requires that you speak English and this is not
          the sort of bug report that English speakers will file
  <tantek> ^^^ great FAQ answer for "Did you get a bug report?"
  myles: I'm not going to push back on this. I would prefer that the
         approach taken is that text describing this is a reference to
         another spec, not a list of characters.
  koji: I'm fine to have some text added that allows the UA to have
        some heuristics. Our bug report was opposite. We had strong
        opinions. People said "don't just disable skipping because
        slashes look bad"
  myles: How would you formulate that in a spec? a list that need to
         be skipped and the rest are undefined? something else?
  koji: Not strong on specifics, but if we got reports on a specific
        code point we could add that, but leave others undefined.

  rossen: Who's going to write this up?
  myles: I volunteer jkew
  rossen: Next action, jkew to modify the spec which - as myles
          suggests, references unicode - with a suggested approach
          that allows flexibility.

  ACTION: jkew add specifics into ink-skipping details TBD. And that
          it's done by reference.
  ACTION: jkew fully specify an algorithm that specifies ink skipping
          that references other specifications that isn't
          codepoint-by-codepoint

  RESOLVED: Fully specify an algorithm that specifies ink skipping
            that references other specifications that isn't
            codepoint-by-codepoint

  fantasai: Who's doing this?
  rossen: jkew

CSS Ruby
========

Ruby overhang control
---------------------
  github: https://github.com/w3c/csswg-drafts/issues/4492

  stantonm: I'll introduce this
  stantonm: Bit of background - in Japanese text, in normal text all
            the characters are solid text - there is no space between
            the characters. Ruby allows this to change - if the ruby
            is longer than the base text, it can push spaces between
            the text.
  stantonm: We've had feedback from authors that they don't always
            want to allow for this overhang. The overhang can cause
            confusion. We had feedback from JL task force and from
            younger users
  stantonm: Proposal is to add a new property to disallow overhang.
            Default we be auto which is the current behavior. New
            value would be none which would disallow overhang outside
            the containing box?

  myles: Question - which element do you apply this property to?
  stantonm: You could apply to document root but the one it would take
            effect on is the ruby tag
  myles: The proposal give the value a length?
  stantonm: The initial proposal was to be a bit more firm in the
            value of the value of overhang JLREQ and JIS recommend a
            value of 1, but none of the browsers actually do this
  stantonm: The suggestion of auto was to allow more flexibility
  myles: A length seems too fine grained. florian suggests auto vs
         none, I agree. Second best option maybe large/small. Third
         best is multiple of font-size. All better than a length
  stantonm: Auto and none fits the use cases we see from authors
  fantasai: Agreed with myles on auto vs none. Because the property
            is inherited, lengths would resolve against the root
            element's font-size which is less helpful
  florian: We may well have different approaches later, maybe clarify
           this or add more values later but for now, auto

  rossen: So we are comfortable with auto and not-auto? any
          objections? None? Resolved.

  RESOLVED: ruby-overhang auto | none on ruby container

CSS Text
========
  Scribe: emilio

Line breaking for ambiguous characters; e.g., U+2010, U+2013
------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/4419

  koji: The current CSS spec says that if the language is Japanese and
        line-break: normal there should be a break opportunity before
        U+2010 and U+2013
  koji: It can break strangely for English words within Japanese text
  koji: Gecko fixed it by not breaking if the previous character is a
        Latin character
  koji: but I want to fix this in the spec
  koji: and make sure all browsers agree.
  fantasai: We got together yesterday and concluded in all languages
            you want to disallow breaks before hyphens in normal
            breaking mode but japanese wants to allow it in loose mode
  <fantasai> https://github.com/w3c/csswg-drafts/issues/4419#issuecomment-577700150
  fantasai: so word-break: break-all would allow between the Latin
            letter and the hyphen
  fantasai: so that's the solution outlined in the last comment (above)
  myles: Are we going to contact ICU and CLDR?
  koji: If we agree I'll do
  florian: I support this
  Rossen: Objections?

  RESOLVED: Adopt the suggestion in
https://github.com/w3c/csswg-drafts/issues/4419#issuecomment-577700150
  RESOLVED: Disallow before hyphen in normal and strict. Allow break
            between ID and hyphen in loose. This means Kanji+Hyphen
            breaks; and Alphabetic+Hyphen doesn't break, unless
            word-break: break-all makes Alphabetic behave like ID.
Received on Thursday, 20 February 2020 00:52:00 UTC

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