- From: Dael Jackson <daelcss@gmail.com>
- Date: Mon, 30 Sep 2013 19:14:08 -0400
- To: www-style@w3.org
- Message-ID: <CADhPm3s9EvDCLucMZg4=t-W2aKM0nRCTen--AC-gvCjz+GGFyA@mail.gmail.com>
Font Load Events
------------------------
- Discussed possible new spec for font load events, including
improvements on the explanatory text and security concerns about
match() function.
- FontFace interface issues were also discussed. TabAtkins requested
that others review the spec to allow for implementation to occur.
TPAC and F2F Scheduling
----------------------------------
- Still looking for a space for a Sunday meeting at Shenzhen in
November.
- Tentative resolution for Jan 27-31, joint meeting with SVG, in
Seattle, hosted by Adobe.
- Investigating Asian locations for week of May 12-16.
- Sophia some time in September.
======FULL MINUTES BELOW==========
Present:
Glenn Adams (Cox)
Rossen Atanassov (Microsoft)
Tab Atkins (Google)
Mihai Balan (Adobe)
David Baron (Mozilla)
Bert Bos (W3C)
Tantek Çelik (Mozilla)
John Daggett (Mozilla, via phone+IRC)
fantasai (Mozilla)
Sylvain Galineau (Adobe)
Daniel Glazman (Disruptive Innovations)
Israel Hilerio (Microsoft)
Koji Ishii (Rakuten)
Kawabata (NTT)
Ian Kirkpatrick (Google)
Håkon Lie (Opera)
Peter Linss (HP)
Ted O'Connor (Apple)
Simon Pieters (Opera)
Simon Sapin (Mozilla)
Dirk Schultze (Adobe)
Alan Stearns (Adobe)
Shane Stevens (Google)
Leif Arne Storset (Opera)
Lea Verou (Invited Expert)
Jet Villegas (Mozilla)
Yamamoto (NTT)
Steve Zilles (Adobe)
[agenda/schedule wrangling]
http://wiki.csswg.org/planning/paris-2013#agenda
Font Load Events
-----------------------
Scribe: Fantasai
<glazou> jdaggett, reviewed it, I have no real comment, no I don't
find it strange.
<jdaggett> hmm.
<jdaggett> document.fonts.clear() isn't a tad odd?
<glazou> the name yes, the feature, no.
<jdaggett> um.
<jdaggett> so you have n @font-face rules and you call that.
<glazou> jdaggett, and it clears the fonts loaded in the layout
engine, yes.
<glazou> despite of rules.
<glazou> super useful.
TabAtkins: Quick intro on new spec for font load events.
TabAtkins: John just sent a bunch of really nice comments on improving
spec prose, but nothing major iirc.
jdaggett: Last part of mail suggests fundamental change.
TabAtkins: Iteration order?
jdaggett: Yeah, and just how add and delete should throw for
CSS-connected font base objects.
TabAtkins: Ok, think that's reasonable to discuss after intro.
TabAtkins: Recall original proposal John made at last F2F, FontLoad
interface, 5 interfaces related to all fonts, 3 for
individual fonts.
TabAtkins: Based on consensus, redesigned around Future.
TabAtkins: Roughly based on my blog post, but made some changes based
on thinking of how to make this work in Workers.
TabAtkins: Have no story of how to ship a font face over to Workers.
TabAtkins: So, start with FontFaceSet.
TabAtkins: Closest analogue to John's proposal.
TabAtkins: It's a set class, which while not defined in WebIDL quite
yet, but similar to Map class that is defined there.
TabAtkins: Acts like a JS set, containing a bunch of Font faces.
TabAtkins: Methods and events:
TabAtkins: To address original issues, still retained 3 of the events:
loading, loadingdone, and loadingerror.
TabAtkins: These fire with regards to every single font load,
TabAtkins: onload fires as soon as doc starts loading fonts, loading
done when it's done, simultaneous with loadingerror if
there was a failure.
TabAtkins: Past events, there are promise-based functions.
TabAtkins: load() function, give it font value and optional some text
you want to render with it.
TabAtkins: check() just checks, not asynchronous.
TabAtkins: ready() fulfills once all fonts are loaded.
TabAtkins: This was previously described in my blog post and F2F
discussion.
TabAtkins: I also added a match() function as well, which exposes CSS
font matching algorithm.
TabAtkins: It returns list of what fonts would be used for some text.
jdaggett: The match() method won't work.
jdaggett: You can have platform fonts in there, so unless you create
font entries for platform fonts, won't work.
jdaggett: Honestly, don't think you really want to expose nitty gritty
of font matching, unless you have a good reason.
glazou: Isn't it security/privacy hole?
<ChrisL> exposing platform fonts is a privacy/profiling issue perhaps
glazou: Web page could discover which fonts you have installed on the
system.
fantasai: You could figure that out by just ask for local before
webfonts, then see which fonts got loaded.
dbaron: I don't think we can solve the fingerprinting issue without
having browsers ship with a set of fonts and then allowing
only those and downloadable fonts, and not arbitrary local
fonts.
jdaggett: When you have explicit name of a platform font in the match
list. I assume your method doesn't pull in fallback fonts.
TabAtkins: Why don't I want to expose fallback fonts?
jdaggett: Would be really system specific.
fantasai: Are you talking about system fallback font, or falling back
down the list?
jdaggett: System fallback font.
jdaggett: That method really needs to have some justification.
jdaggett: Use case is just, here's a string that I want to render,
just want to make sure that all fonts needed are loaded.
TabAtkins: I went through the spec trying to figure out what
primitives are needed.
TabAtkins: This method was really useful for describing other
algorithms,
TabAtkins: Although we could make it just a spec-internal method.
<Bert> I think we should be able to restrict local() to browser and
user style sheets.
jdaggett: Anyway, I think we can move on. Just want to note that I
think it's a bad idea.
TabAtkins: Ok, if it winds up being a bad idea, I'll just shift the
algorithm to being spec-internal.
TabAtkins: Anyway, that's the entire FontFaceSet interface, what we
discussed at F2F.
TabAtkins: Past this is what I had to invent to make it work well with
workers.
TabAtkins: One is the FontFace interface-
TabAtkins: It is a rough analogue of CSS font-face rule
TabAtkins: But doesn't have any connections to document / style sheet
TabAtkins: So safe to ship to a worker.
TabAtkins: load() and ready() methods
TabAtkins: Also has a match() function, which returns boolean.
Jdaggett explained why he doesn't think it'll work, so
we might drop that.
TabAtkins: FontFace can be generated from @font-face rules, or can be
constructed via JS.
TabAtkins: And that's the entire spec.
TabAtkins: Only place I haven't written out yet is the interaction
between CSS and these interfaces.
TabAtkins: As I said, each @font-face rule should automatically
generate a FontFace object, separate from CSSOM object, and
insert into document.fonts.
TabAtkins: This is connected up with font-face rule, so that CSSOM and
FontFace object reflect each other.
TabAtkins: Adding or removing @font-face rules will automatically
add/remove FontFace rules.
TabAtkins: Intention is that font matching algorithm will iterate over
FontFaceSet, not just @font-face rules and local fonts.
TabAtkins: jdaggett has a whole bunch of comments, which I'll need to
address.
jdaggett: The main concern I have about what you specc'ed out already
is that while adding a new font-face rule automatically
populates into FontFaceSet, if you remove it from that,
@font-face is not updated reflect that.
jdaggett: So posted restrictions on how that should work.
TabAtkins: While I did say that FontFace and font-face rules are
connected, there's no connection between them and the style
sheets.
TabAtkins: So an @font-face rule could still be present in CSSOM after
FontFace is removed from FontFaceSet.
glazou: Comments on iterating over FontFaceSet.
glazou: Seem a little inconsistent.
glazou: clear() seems like "unloadAll()", while size() is more like ?
jdaggett: That's the pattern in JS.
TabAtkins: clear() doesn't unload, just removes everything from
the set.
TabAtkins: The fonts are still there, if you pulled them out of the
set and have reference to those FontFaces.
jdaggett: It's inconsistent from existing DOM APIs.
TabAtkins: delete() is fine?
jdaggett: But it is consistent with other JS APIs.
jdaggett: So for Workers case, this might be more appropriate.
* fantasai thinks clear() is clear enough
SteveZ: So clear() removes items from the set, but doesn't delete
them.
glazou: You may want to add a note clarifying this.
TabAtkins: I think it might be confusing because JS sets are new.
jdaggett: Could define collection object that matched [?]
TabAtkins: No, people hate collections. With reason. Bad idea.
TabAtkins: Do you have suggestions for better integration between
FontFaceSet and CSS @font-face rules?
TabAtkins: CSS font-face rules still generate FontFace objects, but
can't be removed from FontFaceSet.
jdaggett: In other words, if CSSOM is created, would have to remove it
from OM
jdaggett: Trying to remove it from FontFaceSet would throw an
exception.
TabAtkins: Seems reasonable to me
TabAtkins: As long as FontFace object is in FontFaceSet, would be
connected to style sheet.
jdaggett: Tab, are you thinking this going to be transferrable?
TabAtkins: Whichever one doesn't neuter, just copies over.
jdaggett: Seems like this should be cloned.
TabAtkins: So, you agree, after you transfer it is like normal
FontFace and can be added to Workers set like normal?
jdaggett: Sure.
TabAtkins: I'm ok with this, simplifies some things.
jdaggett: Yeah, because the way you were trying to manage collection
seemed really weird.
TabAtkins: OK
TabAtkins: Any other changes besides clarifications?
jdaggett: Haven't looked carefully at other parts of spec.
jdaggett: e.g. haven't looked at Promises part .
TabAtkins: Promises prose is up-to-date with latest spec.
jdaggett: Not so worried about that.
TabAtkins: Any other comments?
krit: I want Futures instead.
ChrisL: In the Future.
TabAtkins: Promises spec is in GitHub at the moment, expecting it to
move over to WHATWG at some point.
jdaggett: Also I think we need heycam to add set class to WebIDL
TabAtkins: Agreed
TabAtkins: Review by others would be great, because we are chomping at
bit to implement this.
israelh: Do you have Events model here to be replaced by Promises
model, or co-exist?
TabAtkins: Will co-exist. Events and Promises do different things.
TabAtkins: A lot of things are better off as Promises, but things that
fire multiple times are better done as Events.
israelh: ... Do you get Promise and Event simultaneously?
TabAtkins: Yes.
TabAtkins: One is right before other, but adjacent steps in algorithm.
israelh: Will there be a suggestion of which to listen for?
TabAtkins: I expect individuals to use different things.
TabAtkins: If you want to do something after fonts load, Promise is
better,
TabAtkins: But if you want to have e.g. an indicator of whether fonts
are loaded or not, Event is better.
Everyone is cool with this.
TPAC and F2F Scheduling
-----------------------------------
plinss: Sent email about space for Sunday meeting, but no response
back.
SteveZ: There is I believe an event put together by the sponsors that
day.
jdaggett: Anyone have an office in Shenzhen?
plinss: Doesn't seem like anyone can offer space at the moment
<dbaron> I think our closest office to Shenzhen with a conference room
big enough for the CSS WG is... Paris! :-)
<glazou> dbaron, I can live with that :-)
plinss: If you find out about space, let us know.
<jdaggett> google hong kong?
<jdaggett> ...peter is mumbling...
plinss: We have a request from SVGWG for joint meeting on Tuesday
TabAtkins: Alternately, b/c our schedule is usually packed, could
overlap with them on Thursday.
fantasai: We could do half and half.
dbaron: Note that AC meeting is Tues afternoon / Thurs morning
plinss: Any fxtf people not going to be around on Thursday?
Silence
plinss: Next topic would be F2F meetings for next year
<jdaggett> http://wiki.csswg.org/planning
<jdaggett> I put strawman proposals in there
sylvaing: We can host in Seattle
plinss: Were thinking East Coast in Feb. Works for folks?
<jdaggett> Didn't someone offer NYC?
<jdaggett> The buildings are heated...
<glazou> jdaggett, justin erenkranz did
*fantasai can't hear
* ChrisL we can't hear much either
*jdaggett What's peter talking about...? Feb. meeting?
* ChrisL yes, in NY
<dbaron> jdaggett, Who were you thinking of as host for Taiwan?
<jdaggett> dbaron: Mozilla Taiwan.
<dbaron> jdaggett, I don't remember a room big enough.
[unminuted discussion]
Narrowing to 1st week of Feb.
Asking what preferences on days
Proposal: Feb. 4-6
<jdaggett> Well, we can propose it, then investigate the possibility.
<jdaggett> Anytime in Feb is good for me.
<glazou> Proposal is 4-6 Feb 2014.
<jdaggett> Yes.
<jdaggett> NYC is fine.
plinss: NYC or West coast?
<jdaggett> Snow is pretty.
<jdaggett> And we can have a css hockey game.
<dbaron> jdaggett, the what?
<jdaggett> w3c office at MIT.
<jdaggett> Interesting interaction with tech folks at MIT?
koji: that week conflicts with UTC
<dbaron> koji: UTC is Feb 3-7
Proposal: 10-12 Feb
Proposal: Jan 28-30
<jdaggett> What's the proposed location? Seattle?
<fantasai> NYC
<dbaron> http://www.unicode.org/timesens/calendar.html
<jdaggett> good
<dbaron> (and http://www.unicode.org/L2/meetings/utc-meetings.html )
krit: Seattle could do joint with SVG
krit: CSS/SVG split the week, fxtf on wed
krit: in Seattle
Tentative resolution: Jan 27-31, joint meeting with SVG, in Seattle,
hosted by Adobe
Discussing locations for May
Thinking Asia in May, Sophia in Sept
fantasai: Maybe we can meet in Korea for May, and trap some Korean
typesetters for interrogation.
dbaron: May is always a crunch of conflicts.
glazou: I have to check with respect to hosting in Korea.
<jdaggett> First week of may is holidays in japan
glazou: Not sure Samsung can offer the facilities we need; access to
conference rooms / open internet. Security there is super
strong.
<jdaggett> dbaron: Ok, gotta run
<jdaggett> dbaron: back after 2:30 your time
<Bert> Cannes Film Festival, if you think of coming to the French
Riviera, is 14-25 May 2014
<Bert> WWW2014 in Seoul is April 7-14
plinss: Mark out May 12-16, several folks to investigate locations in
Asia
plinss: Sophia in September, pick dates later?
OK
<break duration=15m>
Received on Monday, 30 September 2013 23:14:36 UTC