W3C home > Mailing lists > Public > public-webfonts-wg@w3.org > June 2011

Minutes, 22 June 2011 WebFonts WG call

From: Chris Lilley <chris@w3.org>
Date: Wed, 22 Jun 2011 23:10:55 +0200
Message-ID: <1866276283.20110622231055@w3.org>
To: public-webfonts-wg@w3.org
Hello,

Minutes of today's call at
 http://www.w3.org/2011/06/22-webfonts-minutes.html

and below as text for tracker.

                 WebFonts Working Group Teleconference

22 Jun 2011

   [2]Agenda

      [2] http://lists.w3.org/Archives/Public/public-webfonts-wg/2011Jun/0086.html

   See also: [3]IRC log

      [3] http://www.w3.org/2011/06/22-webfonts-irc

Attendees

   Present
          +1.781.970.aaaa, +1.417.671.aabb, +44.845.397.aacc, ChrisL,
          +1.408.536.aadd, jfkthame, jdaggett, Vlad, Glenn

   Regrets
          Tal

   Chair
          Vlad

   Scribe
          ChrisL

Contents

     * [4]Topics
         1. [5]Formal objection from Samsung
     * [6]Summary of Action Items
     _________________________________________________________

   <trackbot> Date: 22 June 2011

   <scribe> scribe: ChrisL

   <erik> can't call in, sorry

Formal objection from Samsung

   [7]http://lists.w3.org/Archives/Public/www-font/2011AprJun/0069.html

      [7] http://lists.w3.org/Archives/Public/www-font/2011AprJun/0069.html

   Vlad: Glenn has joined the call.Please give the background for your
   objection. There has been much mailing list discussion

   glenn: represent Samsung.Padt member of CSS WG.
   ... in section 1 intro it has three requirements on user agents
   ... unusual to have normative requirements in introduction
   ... the note seems to contain a normative must, unusual in a note
   ... these should not be in an introduction
   ... core issue is that these three paragraphs and note make
   reference to css3 rules and ua behaviour,this constrains
   implementations of woff
   ... other implementations might use other ferencencing mechanisms or
   other access policy
   ... majorr objection is use of referencing mechanisms and ua
   resource fetching in this file format specification rather than some
   other document
   ... if these are all removed and subtiture text offered this would
   solve the objection

   jdaggett: which version are you looking at

   <Vlad> [8]http://dev.w3.org/webfonts/WOFF/spec/

      [8] http://dev.w3.org/webfonts/WOFF/spec/

   <cslye> [9]http://dev.w3.org/webfonts/WOFF/spec/

      [9] http://dev.w3.org/webfonts/WOFF/spec/

   ChrisL: the /TR version. Glenn, the editors draft has moved this
   normative text from the introduction

   jdaggett: which version of the css3 fonts spec did you look at?

   glenn: just the woff part
   ... ok so my first issue is solved
   ... in the editors draft
   ... want to see the general requirements removed
   ... a separate document defining this would be okay
   ... access control policy that applies to a ua or other agent that
   uses this file format

   jdaggett: on the list you seem to want the css3 font spec to change
   also? or only the woff spec

   glenn: same comments on css3 font spec it should not define the
   fetching process
   ... the way to refer to a font. not a fetching mechanism. nothing
   says about the transport protocol used to fetch this
   ... this wg does not develop css3 fonts

   Vlad: yes but they are markjed as features at risk because we
   believe they should be removed from the format spec and placed in
   css3 fonts instead

   glenn: understand but dont't agree
   ... right nw we have looping references
   ... want a tree graph not a circular graph

   ChrisL: your mail says that moving all this to html5 how would that
   solve your problem?

   glenn: no preference

   ChrisL: html5 spec and css3 spec both define auto fetching linked
   resources, how do they differ

   glenn: html5 defines the fetching mechanism in detail
   ... css3 fonts does not define that mechanism not should it

   jdaggett: so you are sayingit cant define requirements around that
   fetching?

   jfkthame: throughout the woff document there are ua requirements

   glenn: png or mpeg or jpeg dont define ua requirements in the file
   format. format should be independent. conformance on processing is
   reasonable, like encoding or decoding
   ... conformance levels related to presentation.
   ... those are reasonable
   ... requirements on access mechanisms and transport protocols are
   not appropriate

   jfkthame: we agree the file format is not the place to define it.
   that was accepted and agreed but it is not as yet defined anywhere
   else
   ... much harder to understand your objection to defining that in
   css3 fonts. its defining the @font-face rule and entirely
   appropriate to define how a ua behaves when processing that rule

   glenn: other referencing specs at w3c like xlink or xml stylesheet
   spec or css 2.1 which refer to other resources dont define fetching
   or access semantics
   ... so that precedent should apply here

   jdaggett: seems to be a thoretical distinction. why the requirement
   to follow those boundaries

   glenn: group can do as they wish, define different levels. specs are
   mixing layers here, transport and formats

   jdaggett: do you feel the same way about the loading mechanism of
   images in the canvas api, like the tainting rules - do you object
   there? this is very similar

   glenn: canvas started in html5
   ... its linked to html5 in a way that css3 fonts is not. it doid not
   start out by having acccess mechanisms in it

   Vlad: historically css started as part of the html activity then
   migrated

   jdaggett: canvas has a similar definition about origin, if the
   canvas references images from a particukar origin it has impact on
   ua behavioour. its part of the html5 spec right now at w3c.
   ... the reason its erelevant to this discussionis an example is it
   defines ua behaviour

   glenn: html5 is a definition of UA behaviour. css 2 does not define
   origin requirements

   jdaggett: are you saying no definition of access can be in css
   specs?

   glenn: html5 defines a user agent. css3 should be referenceable by
   other specs that use other acess control or transport mechanisms

   jdaggett: cant see how a spec that defines fetching resources is not
   a user agent specification

   glenn: css can and has been employed in other contexts. idea of
   modularisation is to make specs independent. fetchingsemantics in
   css3 is going backwards. unnecessary dependencies that are not
   rwquired in woff or css3

   Vlad: are you saying that if we had this text in a separate spec is
   okay

   glenn: yes

   jdaggett: pushing everything out to another spec makes no sense its
   findamental to the @font-face rule

   cslye: it was decided after long discussion that it was relevant

   glenn: html 5 has a section that goes into great detail on resource
   fetching. that is a good place to define this also
   ... or in a separate spec
   ... work with authors and content providers (scribe missed some)
   guidance to authors and we are folliwing up on this. if these
   requirements remain then our specs will override this and make them
   optional in our specs
   ... if this is in a separate spec we might reference that in some
   profiles

   cslye: so this seems to undermine the point that defining this is
   generally inappropriate

   glenn: after looking at the email again we dont object to same
   origin per se or to SOR vs From-origin. want the option for another
   group that i am working with to have the option to refer to woff and
   to css3 font face and have the option to include sor or not

   jdaggett: a group that is not epub?

   Vlad: epub does not have confidentially restrictions

   glenn: its a group for consumer electronics and the fcc has adopted
   its specs for tvs and handhed devices
   ... due to confidentiallity i can't say more

   jdaggett: so this impacts creating a profile?

   gl: yes, it means we have to overide it instead of the flexibility
   of making it optional

   jfkthame; consensus of the group was that this should not be
   optional

   cslye: yes that was what made the font vendors comfortable with it.
   adobe would see no value in this spec without sor

   glenn: want this to be optional. we can overide it if you publish
   like this but we think its architecturally unsound. understand that
   the group has asked font vendors.
   ... neither truetype or opentype or pdf define this

   cslye: woff is not a font format its a delivery container

   glenn: yes

   jdaggett: having specs refer to other optional specs mean aiuthors
   cant rely on the feature. so it makes things not work

   glenn: might allow the user to disable user agent restrictions,that
   is another option

   jd; we are primarily interested in specs defined by w3c. if other
   people want to profile this in other ways ...

   glenn: dont see this is only for use for w3c defined user agents

   Vlad: actually the group charter says that
   ... first statement, mission is for interiperable download of fonts
   on the web

   glenn: ah okay

   Vlad: you said that part of the group has a strong interest ...
   actually that is a resolution of the whole wg. and normative
   behavious gives interop, this is also a group consensus
   ... agree that the format spec is not iseal, best place is in css3
   fonts which is where this referencing mechanism is defined

   glenn; we will object if its in either of woff or css3 specs

   Vlad: so primar y requirement is to be able to profile it out?

   glenn: no the primary objection is the mixing of layers

   cslye: do others support you on that?

   glenn: yes i have had some supporting email. have not looked at
   other participants in this other consumer electronics forum but some
   of them are w3c members so i will ask what their position is
   ... if samsung is a lone dissenter we might drop the objection later
   ... will look at how this is resolved

   jdaggett; as editor of css3 fonts spec, i dont see a way of changing
   the spec to what you are asking for, so that the same origin
   mechanism goes into a third spec. it merely pushes the specs around
   rather than adressing the actual issue of what the origin mechanism
   should be

   glenn: understand your position
   ... see that html5 defines same origin and something related to
   fonts
   ... this is where it should be defined

   Vlad: thanks glenn for joining us so we can better undertand each
   other's positions. this has beena positive discussion and i think we
   all understand the issues now
   ... can see that other organisations develop subset specs, this has
   happened before. that is fine but for w3c we want somthing that is
   coherent, tstraightforward as possible

   glenn: on a final not, we are not trying to make a change
   thatprecludes content authors restricting access to content. no
   objecting to that. dont want to stop content authors or font
   foundries protecting their content or intellectiual property
   ... there are mechanisms for controlling access
   ... autgors can express constraints on access and uas can accept
   those contraints. no problem with that
   ... happy to attend a future call, thanks for the discussions

   agdourned

Summary of Action Items

   [End of minutes]
     _________________

-- 
 Chris Lilley   Technical Director, Interaction Domain                 
 W3C Graphics Activity Lead, Fonts Activity Lead
 Co-Chair, W3C Hypertext CG
 Member, CSS, WebFonts, SVG Working Groups
Received on Wednesday, 22 June 2011 21:10:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:34:15 UTC