W3C home > Mailing lists > Public > www-style@w3.org > June 2009

[CSSWG] Minutes F2F 2009-06-05 Part I: SVG Properties, Fonts

From: fantasai <fantasai.lists@inkedblade.net>
Date: Tue, 16 Jun 2009 23:43:46 -0700
Message-ID: <4A3890A2.3060301@inkedblade.net>
To: www-style@w3.org
   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().
   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

   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.
   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
   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.


   <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
   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
   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
   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

<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

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:27 UTC