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