W3C home > Mailing lists > Public > www-style@w3.org > March 2011

[CSSWG] Minutes and Resolutions F2F Mountain View March 2011 Day 3: Fonts

From: fantasai <fantasai.lists@inkedblade.net>
Date: Sun, 13 Mar 2011 21:28:09 -0700
Message-ID: <4D7D9959.3070207@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
Summary:

   - RESOLVED: Publish updated WD of css3-fonts with issues noted during meeting
               marked as issues.
   - Discussed @font-feature-values syntax
   - Discussed font-feature-settings syntax
   - Discussed font matching algorithm and fallbacks
   - Discussed IVS (Unicode variation selectors) and font matching algorithm/fallback behavior
   - Discussed how to spec same-origin restrictions for font files

====== Full minutes below ======

<RRSAgent> logging to http://www.w3.org/2011/03/09-css-irc

ScribeNick: fantasai

CSS3 Fonts
----------

   <jdaggett> http://dev.w3.org/csswg/css3-fonts

   jdaggett: There are some recent edits that I wanted to go over, based on
             comments that were made at previous F2F and on www-style
   jdaggett: We'll go through those, then at the end there's some discussion
             that needs to happen wrt WOFF.
   jdaggett: Overview: css3-fonts expands font properties from CSS2.1 and
             adds definition for @font-face which allows fonts to be
             downloaded, and add supports for OpenType font features,
             which are exposed via font-variant

@font-feature-values
--------------------

   jdaggett: Font features are ways of selecting alternate glyphs or
             alternate ways of showing text using data that's contained
             in OT fonts.
   jdaggett: Covers superscripts subscripts, alternate glyphs, ligatures, etc.
   jdaggett: It let's you select which (of multiple variant glyphs for given
             set of codepoints) is chosen
   jdaggett shows stylistic()
   jdaggett: Because the argument to stylistic() is specific to the font,
             a lot of people in the group felt we needed a way to associate
             that value with the font that had that feature.
   <jdaggett> http://dev.w3.org/csswg/css3-fonts/#font-feature-values
   jdaggett: Because of that, we added the @font-feature-values rule
   jdaggett: For each of the font-specific alternate types, you define a set
             of name-value pairs for a given font
   jdaggett explains the rest of @font-feature-values
     Basically, you create an @-rule associated with a font name and then
     within that block you define name-value pairs. The same name can be
     used in multiple @-rules, associating different values with the same
     name depending on the font. Then in the declaration, stylistic()
     takes the name, and maps to the appropriate value depending on the
     font actually in use.
   howcome: Do we need the comma between the name-value pairs?
   fantasai: Technically, no.
   jdaggett: I think it makes it easier to read
   jdaggett: I had swash: delicate 1, flowing 2; but since the cascading
             behavior is very different from what you'd expect from that,
             WG wanted a different syntax.
   fantasai: The cascading behavior is as if "swash" was an element name,
             and the name-value pairs were property-value declarations.
   fantasai: There was another proposal that made this clearer
             (by adopting element { property: value; } syntax)
             at the expense of adding more braces
   * fantasai wonders where molly is
   jdaggett shows more examples from the spec that illustrate the cascading
     behavior, which collects all name-value mappings across style sheets
     (redeclaring same name overrides, just like property-value declarations)
   jdaggett shows some other func() font feature notations that use
     @font-feature-values rule
   More discussion of comma.
   howcome thinks it's unnecessary typing
   fantasai notes that counter properties don't use commas
   dbaron notes that he always gets that wrong even though he implemented it
   howcome: commas used to be used to denote alternates
   Tab: But that's not true anymore
   Tab: e.g. text-shadow, background
   Some discussion of syntax.
   howcome feels it's unclear that the name-value pairs are additive,
     suggests being more verbose and using separate @ rules for each pair
   jdaggett notes that this is possible if that's wanted
   Several feel that's excessive typing and don't want to require it.
   jdaggett shows the Greek coin example
   <bradk> http://www.tktype.com/chartwell.php
   jdaggett notes for the future that having selectors for picking out
     patterns to alter the font-features of would be nicer than having
     to use spans.
     But this example is rare enough that for now this doesn't seem to be
     a problem for us to solve.
   Some questions about how OT features work.

font-feature-settings property
------------------------------

   <jdaggett> http://dev.w3.org/csswg/css3-fonts/#font-feature-settings-prop
   jdaggett explains
   jdaggett reviews some updates to the font-feature-settings syntax
   jdaggett: There's a set of registered OpenType features.
   jdaggett: All of them will be CSS identifiers.
   jdaggett: It's technically possible to define an OpenType feature that,
             e.g. starts with a 3.
   jdaggett: For those cases that we want to escape, you can add the optional
             ot- prefix
   jdaggett: For these tags I haven't put in any syntax definitions
   jdaggett explains the escaping mechanism e.g. 3cap feature would have to
            be written as ot-3cap
   jdaggett: For boolean features, just placing the feature name will set it
             to 1 (on).
   jdaggett: Also the author can be explicit with functional notation, which
             allows integers, but can also use "on" and "off" keywords.
   dbaron: You don't need the ot- prefix for escaping, since you can just
           escape the number
   Tab: Why aren't we just using quoted strings?
   <Bert>/<dbaron> ot-3cap and \33 cap are the same
   * glazou wonders where is Molly...
   jdaggett: There was also the question of e.g. attr() function, which
             could conflict with an OT feature
   jdaggett: You're not just giving the feature name, you have to give a
             value, too.
   <Arron> "3pix" 1
   fantasai asks what would happen if a font format defined features that
            took string values
   plinss: use a comma to separate mapping pairs
   <dbaron> e.g., font-feature-settings: "smcp", "swsh" 2
   jdaggett: for this, I think commas don't make sense
   <bradk> "c2sc" 1, "3piX" 1
   Steve: It would be nice if the pairing notation was the same in both places
   jdaggett: For the name value pairs we are always defining a name and a value
   jdaggett: For this in most cases you just want the tag name
   jdaggett: So you wwant "smcp", "swsh" 2
   plinss: The comma separates features settings, so that you can distinguish
           between a feature name and a value
   Steve says something, several people disagree
   <dbaron> Steves asks whether given @swash flowing 1;, you could do
            font-feature-settings: swsh(flowing) or
           font-feature-settings: "swsh" flowing
   jdaggett: So what if I say "ital" for which we have no feature settings
   dbaron: That seems like extra code to support the non-recommended way of
           doing something
   jdaggett: That means the author has to know which CSS property maps to
             which opentype feature name.
   Steve: I just want to make sure we make a conscious decision.
   jdaggett: I just want to make sure everyone wants to have a non-functional
             notation, which is different from above
   Several: Yes. Those are CSS-defined. This is an open-ended set of potentially
            non-identifiers.
   Luke: It's not clear that this is impossible to parse, it's just that you
         are introducing a whole bunch of these ..
   Luke: We can't have a nice enum of whatever this type is
   Luke: Instead of a simple arbitrary string, you have this extra syntax thing
   fantasai: You have to parse arbitrary idents for counters anyway
   Simon: I think you should figure out a way of not using ot-, or use it all
          the time. Having it be optional is weird
   <jdaggett> alt 1: font-feature-settings: smcp, swsh 2;
   <jdaggett> alt 2: font-feature-settings: "smcp", "swsh" 2;
   <jdaggett> alt 3: font-feature-settings: smcp swsh(2);
   <jdaggett> alt 4: font-feature-settings: ot-smcp, ot-swsh(2)
   <smfr> alt 1 and alt 3 may require ot- prefixes
   jdaggett: This sets smcp to 1 and swsh 2
   Steve: I don't understand why each of the pieces are being proposed
   * fantasai notes that font family names are not required to be quoted,
              even though they could be anything
   howcome: If it's just a low-level feature as an escape hatch in the baseline,
            why is the syntax that important?
   glazou: It's about finding the most elegant syntax that avoids problems
           for the future.
   fantasai: Font families are either idents or quoted strings
   fantasai: Why not do that here, where both 1 and 2 are possible?
   Arron: I like that
   plinss is concerned about this
   dbaron: We have the future-proofing problem for counters and several other
           things already
   <Bert> +1 to fantasai (let author use quotes or not, as fits best)
   <fantasai> alt 5: either 1 or 2 is valid
   plinss: With strings you avoid potential conflicts with expansions in
           either CSS or the fonts
   plinss: Also this avoids authors being confused about whether they need
           to quote something or not
   plinss: It's safer to always require it to be quoted.
   plinss: This is an obscure rarely-used feature. It's simpler and easier
           to maintain if you always have to quote it
   plinss: This avoids any potential problems ever.
   jdaggett: I define on and off to be 1 and zero
   plinss: That's fine.
   jdaggett: And you're ok with assumption of 1 as default value
   plinss: Yes, no problem. Those are all very clean CSS ways of doing things.
   plinss: Our default design should be to avoid any possible conflicts with
           future CSS keywords
   plinss: For something obscure like this, we really have no good reason to
           go against that.
   <Bert> (The "ot-" prefix should probably be on the property name, not on
         the values...)
   plinss: The ot- prefix is very complex because you parse an ident then
           have to reparse to break it down, I don't want to introduce that,
           especially not for something obscure like this.
   Bert: The quotes are redundant. They're parseable without.
   Bert: And if you put this in an attribute, e.g. in HTML you have to
         double-quote.
   Bert: That's why we didn't put quotes in font-family
   Tab: The issue here is that once you go beyond idents, you have to start
       escaping, and that's very confusing for authors.
   Tab: Very few people understand escaping rules
   Bert argues for arbitrary unquoted strings
   vehement disagreement
   jdaggett: I will write up the proposal and post to the mailing list
   fantasai: I would like to do something that gets a WD published.
   <jdaggett> http://dev.w3.org/csswg/css3-fonts/#vertical-position-prop
   RESOLVED: jdaggett will write up alt 2 into the spec, mark as open issue
             whether quotes are required

Superscripts/Subscripts
-----------------------

   jdaggett moves on to vertical-position
   jdaggett explains how superscripts and subscripts are currently
            implemented: the vertical alignment is adjusted, and the font
            size shrunk down
   jdaggett: This has some problems. The typographic color is affected,
             since a typographic superscript or subscript is not used
   jdaggett: And because of the vertical alignment, the line height is affected
   jdaggett: So we have this feature
   jdaggett: This property behaves as a shorthand, resetting font-size and
             vertical-align (to inherit and initial)
   jdaggett: You effectively null out those property definitions
   jdaggett: For older clients that don't support this feature, they will
             still use the default adjustement to font size
   jdaggett: shows example
   dbaron: There's also the second fallback case, of where the font doesn't
           support it
   jdaggett: For that we put in synthesizing rules
   Alex: Doesn't this still use smaller size
   jdaggett: Yes. If those glyphs are missing, you don't get them. But you
             at least get a superscript. And you don't affect the line height.
   dbaron: This seems to be the first time we have a shorthand that sets both
           inherited and non-inherited properties together. I'm a little
           concerned about that.
   dbaron: Also, I'd like something that works for the default UA style sheet
   <stearns> if only the old styling is used (vertical-align: sub) does a
             new implementation use the new synthesizing rules that do not
             affect line height?
   Steve briefly explains his proposal

   dbaron: Third proposal --
   dbaron: Make vertical-position a non-inherited non-shorthand property
   dbaron: Then say that any text inside an element with vertical-position set
   dbaron: you ignore the vertical-align value on the element that had
           vertical-position set
   dbaron: And you recompute the font size based on the ratio of the font-size
           of the element with vertical-position set to its parent
   dbaron: if you have nested vertical-position, you ignore it on the nested one
   dbaron: Then you can use it in a UA style sheet, and if the author nests
           superscripts you no-op it
   fantasai, Steve: But the point was to have nested subscripts to work
   <dbaron> It still doesn't really work with nested subscripts. :/

   jdaggett: In your (Steve)'s proposal, the line height is affected
   Steve: My thinking is that I have a subscript, and if my font has subscript
          characters, I want to use them
   Steve: If it doesn't have a character in the font, then I'd like reasonable
          fallback
   Steve: So my goal is to think about what would the fallback require, and
          then say how I can then go back and enable the font feature to be used
   Steve: and in fact mixed with fallback
   Steve: Say my subscript is 1a, and the font only has 1 as a subscript
   jdaggett: My concern is that you're still affecting the line height
   Steve: How do I make sure there's enough room for the subscript if we don't
          adjust the line-height?
   jdaggett: The whole point of the font's glyphs is that they're designed to
             fit in with the rest of the text so you don't need to change the
             line height
   <Bert> (Something like: 'vertical-position: superscript', IF the font has
           superscript glyphs AND the the elt has 'vertical-align: super',
           sets a hypothetical inherited 'font-size-multiply' property to
           (parent-size/own-size) and ignores 'vertical-align')
   Simon: Do fonts have glyphs for all their characters as superscripts?
   jdaggett: No. Usually only a small subset. If the glyph is missing, the UA
             synthesizes whatever is missing
   some confused discussion
   howcome: Why couldn't we key off 'vertical-align' and just have a setting
            that says "be smart"
   <Bert> ('vertical-position: smart' means, if 'vertical-align' and 'font-size'
           are set in certain ways and the font has the necessary glyphs, then
           ignore the properties and use those glyphs.)
   Fantasai: keep the computed values, but change the used values.
Scribe: Tab Atkins
   dbaron: You need to worry both about children that are nested sub/supers,
           and children that aren't.

   fantasai: [draws some superscripted]
   fantasai: You have the baseline of the element
   fantasai: And pick one of the baselines in this box.  There's a different
             concept between what baseline you're aligning the text to, and
             what you expose as the text's "baseline" outside.
   fantasai: So text has an "alphabetic" and a "superscript" baseline.
   fantasai: When this feature is turned on, for the children, rather than
             aligning the children's alphabetic to the parent's alphabetic,
             align the children's alphabetic to the parent's superscript
             baseline.
   fantasai: And font-size is still inherited, so it'll shrink down as you
             drop, but the used value of font-size is based on the parent,
             so they'll be the right size when they're rendered.
   szilles: So what jdaggett is concerned about it, what is the line-height
            for the text?
   fantasai: The used value of the font-size is based on the parent.  It
             *looks* like you're shifting up, but you're really just using
             a different glyph.
   fantasai: It's only when you start nesting that you'll mess with the
             line-height.

   dbaron: I think there's a second related problem here.
   dbaron: It's that we're using "font-size:smaller", which isn't what we want.
   <stearns> If you don't have the OpenType glyphs, the synthesized version
             can run into line height problems as well
   <TabAtkins> stearns, no, the synthesized characters will have the correct
               line-height, too.
   dbaron: jdaggett says there's a metric that says not only where the
           superscript baseline is, but how large it is too.
   dbaron: if font-size had keywords for "superscript size", etc.
   Bert: MathML has a concept of a "script size".
   dbaron: If you combine the superscript baseline of a font with the
           superscript size, will you get something within the bounds of the
           font, so you don't bump the lineheight?
   jdaggett: It *should*, but not guaranteed.
   dbaron: We can ignore the problem of alternate glyphs for a moment, and
           just look at the sub/sup problem with synthesized/font-size stuff...
   dbaron: Then we'll solve the linebox problem, but not the weight problem.
   dbaron: And perhaps the alternate glyphs solution will fall out of what we
           come up with.
   dbaron: This depends on the superscript characters actually matching the
           reported superscript metrics, or else this all falls apart.

   szilles: There are two categories: 1) fonts that behave like David wants
            them to behave, and 2) fonts that don't.
   szilles: Which group should we design towards?  Either one may be broken
            in some case.
   cslye: I've looked at some Adobe fonts, and it looks like they're all
          "broken" - they use the same superscript baseline, which means
          they probably don't match the character size.
   szilles: I propose that we record an issue for this.
   jdaggett: My problem is that most of these proposals are fairly hairy.
   * TabAtkins declares minuting bankruptcy.
   szilles: [suggestion about making font-size and vertical-align compute
             to two values, one for normal text and one for sub/super text]
   jdaggett: I suggest I just put in a grave note about this being hairy,
             so we have some text about this in a WD.
   szilles: I recommend that the note point out that this is trying to
            solve the "line-heights get changed by sub/superscript" problem.
   szilles: Also that this being a shorthand "messes up" inheritance.

Scribe: fantasai

Font Matching Algorithm
-----------------------

   jdaggett: Next topic is font matching algorithm
   jdaggett: This isn't totally completed
   jdaggett: There are things that still need to be investigated, will talk
             about that later
   jdaggett: This is the world we live in today. *shows lsides of four 'u's*
   jdaggett: You see normal, italic, obld, and bold italic
   jdaggett: The way we're going is this way *shows slide of lots of 'u's
             with multiple weights, some of which have italics, and some of
             which have narrow*
   jdaggett: This is the design of the Univers font
   jdaggett: If you go back and look at CSS2.1 algorithm, it says 'first match
             on this, then match on this'
   jdaggett: It's not fully describing the process that needs to happen
   jdaggett: For each of the axes within this family, you're narrowing until
             you have only one choice
   jdaggett: e.g. if you have font-stretch: normal, then you narrow to normal
             stretches
   jdaggett: Then if you say font-style: normal, you filter out the italic faces
   jdaggett: And if you say normal weight, then you select the normal weight
             within that
   jdaggett: if you select condensed italic bold, then you narrow like this
             *demonstrates by highlighting characters*
   jdaggett: Sometimes if the appropriate weight or italics is missing, the
             UA synthesizes them
   jdaggett: But in the font world you can have families like this *shows a
             slide of 'u's that fill in only random parts of the font
             weight/stretch/italic chart*
   jdaggett: I tried to make the rules as simple and straightforward as possible
   jdaggett: DirectWrite does some fancy grouping, where it takes fonts that
             have families that specify a style in the family name
   jdaggett: And it will remove the style names and create its own families
   jdaggett: Both IE9 and FF4 put in hacks to work around,
   jdaggett: if an author says I want "Gill Sans", which is typically available
             on OS X
   jdaggett: Via DirectWrite you would wind up wth a family that had only Gill
             Sans Ultra Bold
   jdaggett: Instead of saying very vague terms about you match this and then
             you match that...
   jdaggett: ...
   jdaggett projects the algo

   howcome: Are we going to have to change our implementations?
   jdaggett: Where there were ambiguities in the original spec, you may need
             to change your implementation. I think for the common cases it
             will not be necessary.
   jdaggett: For most families that exist on most platforms, it's a very
             simple choice. And those choices will not be affected.
   jdaggett: The choices that will be affected are when someone creates an
             incongruous family via @font-face
   jdaggett: Right now the choices in such cases that result in random choices
   howcome: It would be good if we could have test cases
   jdaggett: That's the intention. To put in rules here so that I can write
             tests and point to what they're testing.

   jdaggett: jkew pointed out the first line in rule 4
   jdaggett: Not all of the faces in a family will have the same character
   jdaggett: There's a question of, do you first say "what are all the faces
             that have a specific glyph" and then match after that
   jdaggett: UAs typically select a face and then find out whether the glyph
             is there or not.
   jdaggett: But you have problems, e.g. Arial has some faces (e.g. italic)
             that don't have all the characters in other faces
   <dbaron> so UAs typically select the face, and then if the glyph isn't
            present in that face, they fall back to the next *family*
   jdaggett: So you might select bold italic, and since the glyph isn't
             there, you fall back to a different font instead of falling
             back to another variant of Arial that has the glyph
   jdaggett: I put rules here that you select font-stretch similar to the
             way you'd select the weight
   Steve: So sort of the nearest reasonable value
   jdaggett: yes, but not precisely
   jdaggett: Here, for example, the normal face is the family to the left
   jdaggett: You can specify style values that are in between some of these
             families
   jdaggett: The rule I wrote up in the text is to always go away from 'normal'
   jdaggett: So it may not be the next closest nearest neighbor
   jdaggett: We might end up picking something further away
   Steve: that's true in weights as well
   Arron: You're trying to show visual change
   jdaggett: right

   jdaggett: I also put in rules that you don't synthesize
   jdaggett: That's marked as an issue
   jdaggett: I would prefer that we keep synthesis as effects, and not part
             of the selection process
   jdaggett: If you have a font style choice of italic and there's no italic,
             per CSS rules you technically should be falling back
   jdaggett: But in implementations today you don't do that, so these rules
             match reality
   jdaggett: We have 'normal' 'italic' and 'oblique'
   jdaggett: But typically, whether there is italic or oblique depends on
             the kind of font
   jdaggett: Current UAs don't distinguish italic and oblique
   jdaggett: So what I've written here is that UAs are allowed to do this,
             but for @font-face rules they must distinguish
   ...
   jdaggett: There was some confusion over this where some people were
             interpreting oblique as the synthesized face, but that's not
             the case.
   Bert: This is a change from CSS2.1
   jdaggett: It's a change from the wording of the CSS2.1 spec, but not
             from implementations
   jdaggett: In implementations, you couldn't specify italics and get normal.
   howcome: It would be good to get a list of changes.
   <dbaron> (relative to CSS 2.1)
   jdaggett points out sentence that uses actual value of font-size instead
            of computed, that it should be removed
   Bert thought it was removed already from 2.1, dbaron suggests maybe we
       forgot this occurrence
   <Bert> (15.7 "font-size" in CSS 2.1 says "On all other properties, 'em'
           and 'ex' length values refer to the computed font size of the
           current element. On the 'font-size' property, these length units
           refer to the computed font size of the parent element. On all
           other properties, 'em' and 'ex' length values refer to the
           computed font size of the current element. On the 'font-size'
           property, these length units refer to the computed font size of
           the parent element.")

   jdaggett: I also changed the behavior for small-caps, since this is no
             longer a separate font face with a different name, but part
             of the main font family, and UAs don't associate unrelated
             fonts via "small caps" in the name

   jdaggett notes that the system font fallback is very UA-defined, might
            involve multiple fonts, might depend on codepoint or encoding
            or language, so has clarified that
   jdaggett also added a last resort representation for missing glyphs
   jdaggett: This leads to character handling issues
   jdaggett: In Unicode you're not dealing with just a single character,
             but a cluster
   jdaggett: It could be something very simple like an a with an umlaut
   jdaggett: the exact way that we match this hasn't been defined, and
             we need to define this out more
   jdaggett: I haven't put this in here, but I think what we need to do
             is map the entire grapheme cluster together
   jdaggett: and if we don't have a font that matches all of those, then
             go back and do character-by-character
   jdaggett: The thing that's bad right now is that CSS2.1 requires that
             you use combining characters from the first font even though
             the base character is from a different font
   jdaggett: I added also that PUAs don't fall back to the system font fallback
   * fantasai thinks this is a good idea for generic fonts and system fallback --
              skip right to missing glyph
   jdaggett also added an escape clause for U+FFFD

   jdaggett: Another issue is how to deal with variation selectors
   jdaggett: The idea of a variation selector is that for a given Unicode
             code point, you want to be able to specify a particular
             representation for that character
   jdaggett: There are a lot of ambiguities here
   jdaggett: There are a lot of debates within people designing Unicode
             about whether these should be separate characters, or glyphs
             that are variations of a single character
   jdaggett: The variation selector was to indicate that if possible, you
             should display a particular character with a particular variation
   jdaggett: This comes up a lot in Chinese and Japanese where over time
             the glyph representation has changed
   jdaggett: In particular for people's names or place names, they're
             registered one way, an dyou want to be able to capture that.
   jdaggett: You want to specify with a Unicode codepoint what the ideal
             representation you're looking for is.
   jdaggett: So that I can show it on my screen with my fonts, and mail it
             to you and you can't see it because you don't have that font,
             but you send it to someone else and they can see it
   jdaggett: There's a question here of how you do fallback.
   jdaggett: If you say "I want to display in this font", and a character
             with a variation selector whose glyph doesn't exist in that
             font shows up, what do you do?
   jdaggett shows an example
   In this case there are several variants that are different, and several
     variants that are the same
   jdaggett: So do you want to fall back to a different font? Or show the
             default glyph? What if the default glyph is the same as the
             variant glyph?
   Steve: This would be a good topic for the workshop in June
   jdaggett: I think you would need to talk to people designing fonts.
   * fantasai thinks Unicode should have required variants that nobody can
              find a difference for to be unified
   jdaggett: If you go across fonts, you're not guaranteed to get something right
   jdaggett shows some more examples
   jdaggett: Here we're using a gothic font.
   jdaggett: The second line uses a variation selector, takes the glyph
             from another font
   (serif font)
   jdaggett: This one it's not subtle, the variation is a structural difference.
   jdaggett: But for an author to go from this, to this, it's a little incongruous
   jdaggett: My point is that nothing is cut and dry here.
   jdaggett: There are authors who would rather have the exact glyph
   jdaggett: And there are authors that would rather have the font match
   kojiishi: IVS is primarily for place name and people name
   kojiishi: Using the wrong variant is very impolite
   kojiishi: especially for peoples' names
   some argument between Koji and John about intended behavior of IVS
   jdaggett: If you fall back to a font that has slightly different style,
             then you may not be able to pick out stylistic differences,
             particularly if face is gothic face

   Steve: What I've heard you say so far is there are reasonable cases for
          saying that you want to preserve font integrity and perhaps do
          what we would do today
   Steve: Let's just deal with IVS
   Steve: There are two options.
          1. treat as request for specific thing, and fall back if not there.
          2. Use this thing if it's there, otherwise use the thing this is
             a variation of
   Steve: You've given good examples where one of those approaches is the one
         that's desired and others where the other approach is desired
   Steve: That suggests to me that have a property to control that would be
         a useful way for author to say which is more important.
   jdaggett: To define that fallback occurs to the system font, and have to
             analyze the cmap to find this, that UAs are required to find
             this font on the system, that's a lot of work
   jdaggett: There's how fallback works within fonts, and another of system
             font fallback
   jdaggett: We don't specify system font fallback
   jdaggett: Is that something that prevents UA from doing something intelligent?
             No. Just undefined.
   Steve: What occurs to me is that if I make the property have the default
          value of today's behavior
   jdaggett: The default behavior in FF4 is, if we have a font in the font
             list that supports the default character, then we will use the
             default character if the variation selector is not defined.
   jdaggett: This requires the author to specify a font that has the
             variation they want.
   jdaggett: Practically, they have to do this anyway because the system font
             is unlikely to have the variation they want

   Steve: My proposal is the property does today's behavior by default.
   jdaggett: There is no defined behavior today.
   Steve: This will not be the first time we define default by defining what is
   Steve: Could use property to trigger more refined behavior
   Steve: Could search for IVS, and if it's not there redo search for default
         glyph
   Steve: I don't think this is that complicated
   jdaggett: It is, doing this as system font fallback is complicated
   fantasai: So don't define it for system font
   jdaggett explains that this doesn't work
   Steve: You go looking through sequence of listed fonts, and if you find
          an IVS you use it.
   Steve: If you don't find it, you start over for the base character, and
          that one hits the system font fallback
   jdaggett: But koji says Unicode people want to get the IVS if it's there
             in the system font
   plinss: Time.

   jdaggett: There are a lot of issues here, and I don't think there's a
             simple answer here.
   jdaggett: There's a lot of complexity here and we can't decide one way
             or the other
   Steve: I would like for us to make IVS work, and avoid code points or
         other subterfuges that would have even worse side-effects.
   kojiishi: If you modify the spec to include normalized shapes for font
             fallback?
   kojiishi: What's the philosophy behind dealing with grapheme clusters?
   jdaggett: The behavior for grapheme clusters will be distinct from IVS
   jdaggett: Because of the internal structure of the way the selectors are
             defined, there has to be more with what goes on
   jdaggett: They should try to work similarly, but you have a whole bunch
             of variation selectors that point at the default.
   jdaggett: So the way this works is going to be slightly different.
   fantasai: Can we file a bug against Unicode?
   fantasai: Request that new variation selectors can only be registered
             if the registrant can explain how their glyph is different from
             all the other glyphs

Same-Origin Restrictions
------------------------

   jdaggett: If a UA is getting a font from the server, by default it will
             not take fonts that are on a different server.
   jdaggett: This prevents people from using a font from another site on
             their site
   jdaggett: Helps fulfil requirements on some font licenses
   jdaggett: There's a large issue if this should be by default requiring
             same-origin
   jdaggett: In <canvas> if you display an image from a different server,
             it taints the canvas and disables APIs that would read
             information from the canvas
   jdaggett: There are problems related to same-origins
   jdaggett: If it's loaded cross-domain, it will tain the canvas
   jdaggett: But it's really... there are some people that would suggest
             not allowing cross-domain use unless it's explicitly marked
             as cross-domain
   jdaggett: Most resources on the Web are not
   jdaggett: We can't go back and retroactively reset those
   jdaggett: because much of the Web has been built on that
   jdaggett: The spec as written includes this restriction
   jdaggett: So there's this kind of dependencies that are all jumbled up
   jdaggett: The CSS3 Fonts spec defines what a same-origin restriction is
   jdaggett: Since it needs to be defined with the loading mechanism, which
             is @font-face
   jdaggett: Apple and Opera have objected and want to have instead a
             different mechanism
   jdaggett: Where the mechanism is opt-in instead of opt-out
   jdaggett: Where the server would say that this resource is restricted
             to the same domain
   jdaggett: Then you could say the same thing for images, say that the
             images can't be used cross-origin
   jdaggett: This would allow server admins to not e.g. sniff referrer tags
   jdaggett: The WOFF team has decided that we're going to mark that aspect
             as at-risk, and there's a potential for dropping this restriction
             and this other mechanism can come in and replace it
   jdaggett: I don't know if that will work
   howcome: I think you've presented it in a fair manner.
   howcome: From Opera's perspective, our concern is the Web architecture
   howcome: We would like one mechanism that can be used for the whole Web,
            and not just specific to @font-face
   howcome: I don't have a strong opinion, but some others in Opera do
   howcome: Anne has written up a proposal for a From-Origin spec
   howcome: I don't think this should be in a font-specific spec, but in a
            generic spec that is not tilted towards a particular media type
   howcome: I also think the default value should be the same throughout the Web
   jdaggett: I don't think it's in-scope for this WG
   jdaggett: to tackle that question
   jdaggett: But we have to reference this issue somehow
   plinss: This is an important issue, being discussed at other leves,
           WebApps and TAG are looking at this
   jdaggett: How do I get my spec not stuck in limbo for 3 years?
   plinss: Mark the feature at-risk.
   <Bert> (I don't think we should say anything about specific mechanisms in
          CSS, even if we *do* have a good idea of what the mechanism might
         eventually be; just drop appendix A.)

Publishing
----------

   jdaggett: Would like to resolve publishing another WD
   RESOLVED: Publish updated WD, with changes marked above (adding issue notes),
             and list of font matching changes from 2.1
   <br type="lunch">

<Bert> (About sending to www-style, as Tab recommended: www-style was the
         busiest mailing list in W3C in 2010. Only public-html gets close...)
Received on Monday, 14 March 2011 04:29:13 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:38 GMT