[CSSWG] Minutes Paris F2F 2013-09-12 Thurs I: Font Load Events, TPAC & F2F Schedule

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