- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 16 Jun 2009 23:43:46 -0700
- To: www-style@w3.org
Present:
David Baron
Bert Bos
John Daggettt
Arron Eicholz
Elika Etemad
Sylvain Galineau
Daniel Glazman
Molly Holzschlag
Håkon Wium Lie
Chris Lilley
Alex Mogilevsky
Anne van Kesteren
Steve Zilles
<RRSAgent> logging to http://www.w3.org/2009/06/05-CSS-irc
SVG Attributes as CSS Properties
--------------------------------
Scribe: Bert
Chris: Some are attribs in SVG 1, not properties. Width/height attribs,
but also width/height properties.
Chris: This is ongoing work to harmonize in SVG2
Chris: SVG2 intent is to say that that the property width is the *CSS*
property width.
Chris: SVG also wants to know what happens with calc().
http://lists.w3.org/Archives/Public/www-style/2009Jun/0057.html
Fantasai: Antennahouse has implemented calc().
Fantasai: Editor is Håkon.
Håkon: Values and Units module.
Håkon: I didn't know about the implementation. Browsers don't do it currently.
Chris: Calc very much wanted.
Håkon: Also interested in other stuff, like cycle()?
Chris: Don't know...
dbaron: Use case for cycle() is list style, cycling through a set of values,
then start over when you run out: symbols for bullets, italic/normal
for font-style., etc.
Chris: As I'm co-editor, I can probably just go ahead. But what parts are
others interested in?
dbaron: Mozilla might get to it soon.
Fantasai: To Web authors this is as imprortant as backgrounds.
Håkon: Authors can just add another element and get the effects.
[Discussion about how realistic that is. Many designers or db-driven sites
can't add elements.]
Alex: MS is looking at the features. No commitments. Seems possible to add it.
Chris: We don't know what Apple plans.
Chris: Module also seems to have to wait for other modules, because we might
still need another unit or something like that.
Daniel: So answer to SVG about calc() is: yes
dbaron: Val & Units still needs impl. feedback, so expect some changes still.
David: I think we'll find that we broke something somewhere in this module.
AnntennaHouse didn't sent many comments, but I'm skeptical that it
is really ready.
Daniel: Is SVG asking for 'x' and 'y' properties?
Chris: Or use 'top' and 'left'? But what is the interaction?
Chris: What feedback can I take to the SVG WG?
Anne: Can you do 'svg-x'?
dbaron: Using 'top' seems OK, as long as you don't abs. pos. SVG elements.
Fantasai: What are those properties in the e-mail for, exactly?
[Chris explains x, y, width, cx, rx.... for center radius, etc.]
Fantasai: Can maybe put some of them together in a shorthand. Use more
descriptive name, write out the name.
Fantasai: Naming scheme not very like-CSS.
Anne: prefixing with svg- may be enough.
fantasai doesn't think prefixing with svg- makes sense, we don't prefix with
css-
Daniel: Discuss at TPAC?
Chris: SVG will not meet there, but some people can be there.
Daniel: Good, bcause SVG apparently already thought more about this.
Steve: How about the writing-direction independent versions?
Chris: The geometry is not dependent on writing direction.
Chris: Relative directions are useful for text.
SVG comments on Transitions
---------------------------
Chris: Some mistakes in module, e.g., some properties are not interpolatable.
Chris: Dean hasn't responded to the comments so far.
http://lists.w3.org/Archives/Public/www-style/2009Feb/0681.html
Chris: Not clear why things are different from SMIL. Is that on purpose
or oversight?
Chris: Dean should explain that, if there are problems with SVG and SMIL
approach.
Daniel: Without maintainer of spec present we cannot go much further.
We need replies from him first.
Daniel: Since Feb [when e-mailwas sent] no replies at all?
[We find a reply Mar 4]
Chris: So seems SVG missed that reply then.
Chris: So we need to wait for the updated draft then.
Chris: Come back to it when we have that update.
Fonts
-----
<jdaggett> http://lists.w3.org/Archives/Public/www-style/2009Jun/0059.html
John: Wanted to talk about bolder/lighter.
John: I made a FF test build.
John: Problem with old definition is figuring out what weight is when
there are multiple steps since some ancestors.
Chris: Does new idea work when there are only two fonts and two weights
in the family?
John: My build is available for people to experiment with.
John: You can toggle between old and new behavior, via about:config
[John shows results with a rich font on screen]
John: Differences in weights between some steps is quite subtle. This
screen is from existing behavior. Very little difference in this
font between 800 and 900. 200 and 300 are the same in this font.
Chris: What was the mapping from original font to CSS weight values in
this case?
John: The spec is very specific, it is defined, especially in the new draft.
John: Searching for available font first goes in direction of keyword
(down for 'lighter') and when it doesn't find any it goes back up.
John: Important for a font with only one weight, e.g.,
John: 400 and 500 can both become the normal weight, depending on the font.
Some fonts have both, sone one or the other,
[Another screen, three weights in the font.]
[John shows example with actual text, side by side old and new]
John: The table in my e-mail is font-independent. E.g., if you inherit 600
and ask for bolder, you get 900 as computed value.
[Another example, with font that has 100, 200 and 400. so going 'bolder'
from 100 gets 200 in the old scheme, but 400 in the new.]
[Another screen, with nested elements]
[Screen shows that with a rich font, the old scheme shows almost no
difference when you do 'lighter'.]
John: This last example is not a very typical case. Can't imagine somebody
actually doing this. There are also only very few fonts like that.
John: Also not very interoperable. On Windows quite hard to get at those
weights.
Chris: So question of using the right APIs.
Chris: With @font-face, you can make a font that counts as weight '900'
even if the font file itself says '100'.
John: Yes, I have an example later on with that principle.
Steve: The model for @font-face is that it provides an index into a database
of fonts and you use the font that is finds for you.
John: New system for bolder/lighter doesn't have to know what the available
weights are.
John: Some comments from Adobe seemed to be from viewpoint of API and
asking 'bolder' relatibe to this font. But there is no "this font"
in new system.
Steve: Can calc() apply here?
Steve: Ask for "old font-weight + 100" e.g.
Steve: I'm trying to step through the font, looking for all available weights.
But that seems impossible in practice.
Steve: Would need a new type of query, to get the set of available weights.
Steve: I think John's new system works well for the naive user. I was
wondering if we lost something that was possible before.
[Discussion of how much and how bolder/lighter are used at the moment.]
John: We said at telcon before that the new mapping table was probably OK
but we needed more examples.
John: Bert, you had some issues before?
Bert: Don't remember exactly, but the system seems reasonable so far.
John: Current Fonts module mostly has implementations apart from some parts.
dbaron: How about wider/narrower?
John: Yes, I don't like that part in the spec. Don't see the use case.
John: Bolder/ligher makes sense, but why wider/narrower?
Chris: Probably thy just exist for symmetry with bolder/lighter?
John: Drop them then?
Chris: Leave, but mark them, so people can react.
Chris: What is status of font-variant?
John: I want to work on accessing OpenType features, in combination with
font-variant, but I don't have that yet.
[John shows stretching example]
John: Condensed faces are more common than expanded.
John: Also added exmaples for 'unicode-range'.
John: Google's Droid font is interesting, it has a couple of faces,
including symbols.
John: Various Unicode ranges in varipus faces, so you don't usually need
the big 4.5MB font.
John: Latin/Greek/Cyrilic is only 190K, e.g.
John: With @font-face and unicode-range you can declare the complete font
but not have to download it all.
Chris: So what are the cases where previous bolder/lighter gave different
results?
John: Some cases were undefined.
Chris: What happens with weights that aren't hundreds? E.g. 250?
John: Can we come back to that later in the discussion, I have some thoughts.
John: Existing wording already talked about font systems that don't use
the numbers, but only has names.
John: Weights in OpenType are in something called the OS/2 table, Apple uses
it sometimes but not always. And it changes between Apple releases...
<dbaron> (mapping from style names to weights)
Steve: Adobe has similar adjustments, because table not always reliable.
John: Also mapping from name in different languages to weights is difficult
(impossible?) to standardize.
Chris: We should keep patform-dependent aspects out of the spec.
Steve: That seems consistent with other heuristics we have, such as using
italic when oblique was requested.
<ChrisL> wel, out of the model. those details can ber in an implementation
appendix for example
John: Adobe has no fonts with weights lower than 250.
Steve: That is because of GDI...
<ChrisL> but the model should (re)group the logical components of a font
family together
John: The module gives description of this, informative.
Chris: That is fine. Explaining is good, but the model has to be clear.
Steve: Won't get interoperability, though.
Steve: Because the mapping when the numeric weights are missing or unreliable
will be different on different platforms, implementations, etc.
Steve: Testing difficult.
Chris: Nothing in the description is a testable statement.
John: We may want to make it normative that families can have more than
two weights.
<jdaggett> http://people.mozilla.org/~jdaggett/font-face/
John: E.g., Arial Narrow can still be used, but it should also be possible
to use Arial with property narrow.
John: Name given by @font-face overrides the name in the font file.
John: So I ask for 'font-family: headline' and the system happens to have
a "headline", but I still want the font that I called "Headline"
in my own @font-face.
[John shows example of that]
John: We will need to make test cases for this.
<ChrisL> I notice http://people.mozilla.org/~jdaggett/font-face/fontfacewithall.html
[John shows an example of overriding weights and styles with @font-face:
a table that shows same font for all weights and styles.]
Chris: Important for small-caps, too.
John: But 'font-variant' is not a descriptor, so that doesn't work.
John: But I'm working on OpenType features, bsides small-caps.
<ChrisL> i would support adding back font-variant as a descriptor, to
point to small-caps fonts
John: To enable OT features, we need to add more values to font-variant.
The traditional values remain, but as rendering, rather than
selection features.
John: [Talking about shaping in Arabic, shows example]
John: I added a hint: format("truetype-aat")
John: A platform that recognizes that can use the font with that format,
which contains advanced shaping.
Chris: Does OT allow both the tradional and the AAT tables in one file?
John: Syntactically yes, but some people say they will conflict.
John: In the list after 'src', UA downloads the first fornat it recognizes
(if any).
Steve: What are the format() keywords? Is there a registry? OT has
different variations.
<ed_work> it would be good if the format-table listed ".svgz" as a common
extension for svg fonts
<fantasai> why are they quoted? why not identifiers?
John: The list of keywords is not a requirement on UAs to know them all.
John: Vendors can add more.
John: I see the issue, but seems a separate issue, unrelated to the spec.
Chris: It is a non-exclusive registry, currently. The list in the spec is
defined, but other keywords are allowed.
Anne: Can suggest a vendor prefix?
Steve: But unlike prefixed proeprties, these names are meant to be shared.
Steve: Need a way to find the definition of a name.
Steve: Can you mark the issue in the draft? Ask for comments on need for
registry.
Chris: Erik just asked for .svgz to be mentioned.
Håkon: The "z" means it is same as SVG, but compressed?
Anne: Do we need the list of extensions to be there at all?
Chris: There are no MIME types for fonts.
John: Not as font/foo, no, but we can do MIME types.
Anne: we do not do extension sniffing, we do content body sniffing
Anne: therefore extensions are irrelevant and should not be listed
John: Listing the extensions is helpful for authors.
Steve: In appendix, looks like mapping is wrong way round, from features
to properties.
Steve: Change the heading?
Steve: Also in appendix, what about weights like 250?
John: I don't really know how to solve that. Needs more time, to long for
this draft.
Steve: I sent a proposal earlier.
John: OK, we should look at that (after today).
Steve: Looking for something that says that the model may have hundreds
as values, but...
Steve: Something that helps people to understand that info about a font
comes from several sources.
Steve: Not normative, but warning people.
Steve: A pointer to the appendix from the definition maybe enough.
Steve: Original spec implied that values like 250 could not be mapped
into CSS model.
John: It is a 9-point scale, forget about the actual values. Just need
to map the font onto nine points, whatever their names.
Steve: Overlap between font models make things difficult.
Daniel: Publish?
RESOLVED: publish WD
[BREAK]
<myakura> "Note: The following systems and UNICODE characters have not
been given keywords: The superscript and subscript digits
(starting at U+2070)" http://dev.w3.org/csswg/css3-lists/#non-repeating
<myakura> since we got "super-decimal" in <numeric>, this should be updated right?
<fantasai> myakura, good point. But I'm thinking to remove the non-repeating section entirely...
<fantasai> myakura, circled numbers could be defined as numeric imo
<fantasai> myakura, but I haven't thought about it much yet :)
ScribeNick: fantasai
jdaggett: Once the current draft is in WD, I will start adding proposals
for extensions to what we have now
jdaggett: Steve and I were discussing how to add support for specific
OpenType features
jdaggett: But I think it's better if I put those in a more concrete form
before we discuss
jdaggett: Also considering stroke and fill for fonts
jdaggett: Hyatt had some proposals for that
fantasai: Can we just use the SVG properties? Less properties to carry around
jdaggett seems unconvinced
ChrisL seems enthusiastic
<ChrisL> please use the svg properties which already do that, not a new
and conflicting thing
Received on Wednesday, 17 June 2009 07:48:24 UTC