- 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