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

[CSSWG] Minutes Lyon F2F 2018-10-23 Part I: Spacial Navigation, CSS Fonts, Overscroll Behavior [spacial-navigation] [css-fonts]

From: Dael Jackson <daelcss@gmail.com>
Date: Sun, 2 Dec 2018 06:23:51 -0500
Message-ID: <CADhPm3vgw_ugu1GkdjvNjZKVuLJp=XVw6J1QwLwLBHNy6ZWGLw@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.
=========================================


Spacial Navigation
------------------

  - RESOLVED: Adopt spatial-navigation as CSSWG ED

CSS Fonts
---------

  - RESOLVED: local() matches against both full font name and
              postscript name (Issue #3177)
  - RESOLVED: Investigate whether it's practical to implement
              multi-locale name matching across all platforms
              (Issue #3177)

Overscroll Behavior
-------------------

  - Issue 2473 needs to be resolved before bringing this spec to FPWD.
  - astearns will ensure the IP is covered and encourage Facebook to
    join the CSSWG for that purpose before the next telecon in hopes
    of being able to call for FPWD then.

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

Agenda: https://wiki.csswg.org/planning/tpac-2018#schedule

Present:
  Rachel Andrew, Invited Expert
  Rossen Atanassov, Microsoft
  Tab Atkins, Google
  L. David Baron, Mozilla
  Tantek Çelik, Mozilla
  Emil A Eklund, Google
  Elika Etemad, Invited Expert
  Javier Fernandez, Igalia
  Simon Fraser, Apple
  Daniel Glazman, Privowny
  Jihye Hong, LGE
  Koji Ishii, Google
  Brian Kardell, JS Foundation
  Ian Kilpatrick, Google
  Vladimir Levantovsky, Monotype
  Vladimir Levn, Google
  Rune Lillesveen Google
  Myles C. Maxfield, Apple
  Cameron McCormack, Mozilla
  Manuel Rego, Igalia
  François REMY, Microsoft
  Melanie Richards, Microsoft
  Florian Rivoal, Invited Expert
  Dominik Röttsches, Google
  Hiroshi Sakakibara, Beyond Perspective Solutions
  Dirk Schulze, Adobe
  Jen Simmons, Mozilla
  Markus Stange, Mozilla
  Surma, Google
  Alan Stearns, Adobe
  Philip Walton, Google
  Greg Whitworth, Microsoft
  Eric Willigers, Google

Scribe: fantasai


Spatial Navigation
==================

<florian> https://wicg.github.io/spatial-navigation/

  florian: We initiated this spec in this working group. The
           suggestion back then was that this was a CSS topic, but not
           only a CSS topic, so we should try a more broad venue so
           went to WICG
  florian: We've had a fair amount of feedback, but none of the people
           came from the WICG. Being in WICG didn't do anything useful
           for us.
  florian: So in practice, didn't really help much
  florian: But we've had different levels of review and different
           levels of enthusiasm

  florian: Wrt impl, we're talking to Google and Vivaldi
  florian: Google is positive, Vivaldi is quite excited about it
  florian: Not quite ready for FPWD
  florian: On the other hand, there is interest in the topic, and we
           want to keep moving on it
  florian: And we think it'd be more comfortable to keep working in
           this WG rather than WICG
  florian: There are many specs this needs to integrate with on the
           layout side and also things like overscroll-behavior
  florian: Overall, this is not a CSS-only topic, but it is fairly
           integrated with CSS concerns
  florian: So our request is to move back the ED to the CSSWG, with
           intent of doing the FPWD
  florian: in the future

  astearns: Comments or opinions?
  krit: You are asking for an ED in W3C space?
  florian: Yes, we have a draft in WICG, not sure what that's called,
           but would like to move that draft into this WG as an ED
  astearns: Opinions from other browser vendors about suitability of
            the work?
  <silence>
  astearns: Given that we have some interest, and you have relatively
            good reviews...
  TabAtkins: We're fine with this being in the CSSWG

  astearns: Proposal is to adopt this as an ED for the CSSWG
  astearns: Any objections?
  <tantek> +1

  RESOLVED: Adopt spatial-navigation as CSSWG ED

  florian: Other than that don't really have any specific issues to
           discuss today.
  florian: If anyone wants to talk about this at TPAC, let's do
           breakout sessions

  astearns: Any WICG issues open on the spec?
  florian: A bunch, everyone welcome to look
  florian: Also in addition to spec we have a polyfill, which we're
           trying to keep in sync
  florian: Vivaldi has integrated the polyfll, if anyone wants to play
           with it I can provide a build

  astearns: Part of the work of migrating to the WG would be moving
            all the comments
  florian: I will move all the issues, but will not move the polyfill
  florian: WG doesn't really keep polyfill code in this repo
  iank_: Why not?
  florian: We could, but CSSWG is not scoped to maintain software.
           Also, if we move polyfill into w3c space we need to put it
           under a w3c license, currently it's MIT
  florian: Having it in its own github repo makes it easier to
           integrate into npm or whatever
  iank_: That sounds fine
  iank_: Just as long as the explainer is also kept
  florian: We'll keep the explainer
  astearns: What do we do for houdini code? Aren't there polyfills?
  iank_: They're built by third parties
  iank_: There is example code in the repo, though
  astearns: Example code for spatial navigation makes sense to keep
            if any

  jihye: I hope that our spec can be worked on in CSSWG
  jihye: so I'm happy with this
  jihye: I think there will be some concerns that this spec is not all
         about CSS, so would like to hear if anyone has such an opinion
  florian: Another significant aspect is integrated with focus
  florian: so there is some integration on the HTML side as well
  florian: But we won't stop listening to others of course
  florian: Need to work with HTML, a11y, etc.
  astearns: Might be worth sending out a notification prompting
            feedback / involvement from others

  florian: I think that's it for this topic?

Fonts
=====

src: local() font name matching
-------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3177

  drott: I raised this issue
  drott: It's about the local() value of font-face
  drott: Used for uniquely identifying font on the local system
  drott: Identifies one font
  drott: Current description that it can only match the ??? name and
         the ??? name
  drott: First want to expand it to Arial Bold Condensed
  drott: We want the authors to have more success in actually matching
         the font
  drott: Currently spec asks authors to add both names to the src
         descriptor
  drott: So current proposal is to match both, help authors have more
         success in matching the font

  drott: Second part of the proposal is about which locale/language to
         match against
  drott: Currently the spec says only match the US-en version first
  drott: If this one cannot be found, then try to match the first one
         encoded in the font
  drott: I find this aspect of the font rather arbitrary, and don't
         think we should be doing this
  drott: I'm not so worried about conflicts here
  drott: If any questions, be happy to answer those

  heycam: Do we have any requirements on matching non-local font names?
  drott: If you don't use the local() value, you do family style
         matching
  heycam: But in terms of what the family name is matched against?
  drott: Family name matches against the family name
  drott: Fonts have three name entries
  drott: There's family name
  drott: and then full font name
  drott: and postscript name
  drott: In regular font-family matching, you match that against the
         family part
  heycam: Is it true that some implementations match the postscript
          name for font-family?
  drott: I believe so
  drott: But the matching is not so sharp for family
  drott: You leave it to the matching algorithm to find the closest
         font to what you specified
  drott: But for local() you have to match exactly, that's the intent

  myles: I think both of these are good for the web platform, I just
         don't know how to actually implement them.
  myles: If someone knows how, that'd be great, happy to do it.
  drott: Maybe don't specify as a MUST
  drott: But I think we should remove the current specification that
         says english first, otherwise physically-first entry in the
         name table which seems pretty random
  drott: I think Firefox implements this on all platforms
  drott: Windows has DirectWrite API
  drott: Fixing in Chromium, I also did this on Linux and Android so
         far
  drott: Maybe not with CoreText, but I think we can find a language
         that would allow implementations to do this
  astearns: Is your suggestion to keep English first, but allow other
            matching, or drop any mention of English?
  drott: I would prefer to match any

  astearns: Do you have any particular spec language or just looking
            for agreement to go in this direction?
  drott: Don't have spec language ready, but agreement to go in that
         direction would be OK
  astearns: So proposed resolution is to loosen font name matching
            requirements and allow more matching than is currently
            allowed
  drott: Specifically to match both font names, and secondly to match
         against all languages

  dbaron: Allow or require?
  astearns: For the first part, full name and postscript name, would
            that be allowed or required?
  drott: Required
  drott: But for second part, locale-matching, would allow. not sure
         there's consensus to require
  dbaron: My concern is that we'll end up in situations where impls do
          different things
  dbaron: I'm more comfortable going with a requirement either way
          than to do MAY
  dbaron: What we'll end up with there is someone having a web-compat
          problem and have to go fix it
  dbaron: If that impl can't implement it, then we have a bigger
          problem
  myles: Agreed
  myles: Part of this issue for me is relying on API that isn't clear
         what it's doing
  drott: I see your point
  drott: I would prefer a requirement as well
  drott: Would be hopeful we can spec that
  drott: Otherwise just widening allowances makes sense to me
  dbaron: Maybe give Myles a chance to see what CoreText can do?
  dbaron: We should care what platform APIs offer when we spec these
          things
  myles: Is CoreText the only API that's concerning here?
  drott: I looked at FontConfig and DirectWrite and on Android looked
         at APIs
  drott: On FontConfig and DirectWrite it's no problem
  <dbaron> I don't know... jfkthame would probably be the person to
           ask for Mozilla expertise
  drott: On Android I implemented an indexing method, so possible but
         might require own indexing
  myles: I would like to not parse font files myself

  astearns: So I guess the proposed resolution is to find better/more
            ways to match fonts
  astearns: and try to make requirements a MUST
  astearns: but we don't have spec language for this
  fantasai: I agree with dbaron we need to see if myles can implement
            it
  drott: Can we split the resolution? Can we match full name +
         postscript name
  myles: it's OK

  astearns: So proposed to match on full font name and postscript name
            (MUST)
  astearns: Any objections?

  RESOLVED: local() matches against both full font name and postscript
            name

  RESOLVED: Investigate whether it's practical to implement
            multi-locale name matching

  astearns: Might also want to ask the i18nwg if they have any input
            on this

  fantasai: To what extent are there fonts that have one localization
            plus English, and someone else has a different
            localization plus English?
  fantasai: Let's say you have a font that's released in Japan and
            France, and the French version has English and French
            names, not Japanese names
  fantasai: and the Japanese version has Japanese name and English
            name, but not a French name
  fantasai: I suspect the restriction was there to handle situations
            like this
  fantasai: if you force the author to use the English name it could
            work in more place, if such situations are common
  myles: I've never heard of a font author doing that. usually they
          just make a font in a particular set of languages
  fantasai: Just wanted to check if this has historically happened in
            the past

Overscroll Behavior
===================

  majidvp: I'd like to move overscroll behavior to FPWD
  majidvp: Spec was in WICG
  majidvp: We moved it to CSSWG a couple months ago
  majidvp: Last we spoke resolution was to move to CSSWG and get an
           editor
  majidvp: I agreed to become backup editor
  majidvp: I am happy to be the editor
  majidvp: It's a small specification, right now there's maybe two
           issues filed against it which should be small changes
  majidvp: Next step is FPWD

  fantasai: If previous editor doesn't want to join CSSWG, what
            happens to IP?
  TabAtkins: I thought this was written by a googler?
  majidvp: He's from Facebook
  astearns: He's from Facebook, and Facebook is a member of W3C but
            not member of CSSWG
  astearns: But I understand that commitments made by developing in
            WICG are sufficient
  majidvp: I think that's correct. I think he just didn't want to
           commit the time necessary to be the editor
  dbaron: Was it published as a CG report by the WICG?
  majidvp: I do not believe so
  dbaron: It's possible that makes a difference here
  dbaron: I think when reports are published companies can choose to
          make patent commitments on those reports
  TabAtkins: I think WICG has something more extensive than standard
             CG, but not sure of details
  florian: What I remember is that when you submit to a CG you commit
           your own IP, and when you publish a report then other
           members can commit what they didn't contribute themselves
  TabAtkins: FPWD triggers patent exclusion for this WG
  TabAtkins: If benoit already contributed his IP as part of WICG,
             that covers us from Facebook's angle, right?
  TabAtkins: Publishing here would trigger patent exclusion for CSSWG
             members

  fantasai: So Facebook is not a member of the CSSWG, but the concern
            for them is not that they don't want to commit IP but that
            the editor doesn't want to spend time on it?
  astearns: I've been asking to benoit and their AC rep, as far as I
            understand their only concern is time
  astearns: I could maybe ask AC rep to join WG just from a patent
            commitment
  fantasai: I think that would be a good idea
  florian: They already committed what they contributed
  fantasai: Yeah, but if we end up with IP that they didn't directly
            contribute but own anyway, it helps us here.
  florian: Yeah, can't hurt and might be good

  fantasai: Wanted to ask if there was any issue wrt API design wrt
            writing-modes or fragmentation
  majidvp: We just have an issue on adding logical longhands, issue
           2473
  <majidvp> https://github.com/w3c/csswg-drafts/issues/2473
  fantasai: I would suggest let's fix that first before we publish
  <smfr> +1
  astearns: FPWD?
  <franremy> +1
  <dbaron> +1
  astearns: Let's have that issue addressed, and I'll see what I can
            find out about IP commitments today
  <majidvp> +1
  astearns: And maybe we can resolve on FPWD at the next telecon
Received on Sunday, 2 December 2018 11:24:57 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 2 December 2018 11:24:58 UTC