- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Sun, 13 Mar 2011 21:28:09 -0700
- 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 UTC