[CSSWG] Minutes and Resolutions 2010-04-21


   - Shinyu Murakami added as co-editor of css3-text and css3-text-layout

   - RESOLVED: Provisionally accepted bz+fantasai's table anonymous box
               proposal for CSS2.1 Issue 109:

   - Reviewed CSS3 Fonts issues in Bert's email:

     a) 'font-stretch' was originally excluded from 'font' shorthand
        because 'font' shorthand was very fragile and editors were
        concerned about adding anything to it. jdaggett to look into
        whether it's still a problem, and see if it can be added.

     b) Agreed to remove note about font format name registry.

     c) Wrt syntax of local() being underdefined, seem to have agreement
        on copying quoting conventions of font-family property.

     e) Wrt font-matching algorithm and synthetic bolding, it seems the
        spec may need some clarification since there is no disagreement
        in desired behavior, only in reading of the spec text.

     g) font-kerning to have three values:
          * 'auto', the default, which means the UA may turn it on or
            off depending on perf or other concerns. Recommended to be
            always on.
          * 'normal', meaning always-on (OpenType's default)
          * 'none', meaning always-off

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

   Tab Atkins
   David Baron
   Bert Bos
   John Daggett
   Beth Dakin
   Elika Etemad
   Simon Fraser
   Sylvain Galineau
   Brad Kemper
   Shinyu Murakami (via IRC)
   Chris Lilley
   Peter Linss
   David Singer
   Steve Zilles

<RRSAgent> logging to http://www.w3.org/2010/04/21-CSS-irc
Scribe: fantasai


   Peter: Any other agenda topics?
   fantasai: Murakami-san would like to become co-editor of css3-text
             and css3-text-layout
   No objections
   <murakami> Thanks

   Topic: Test Suite Status
   fantasai has not worked on the test suite since the F2F (was studying
   for the FE exam last Saturday instead), so nothing to report

Table Anonymous Boxes

   Tab: AFAICT, it looks great
   <plinss> http://lists.w3.org/Archives/Public/www-style/2010Mar/0551.html
   dbaron: Was Boris happy with it?
   fantasai: yes
   fantasai: There's a related issue of handling abspos elements
   fantasai: Boris's original proposal had abspos elements leave behind
             a "placeholder", which would then affect the anonymous
             table box generation
   fantasai: From an implementator's perspective, I can see why. In Gecko
             each out-of-flow has a placeholder left behind so that we
             can calculate its static position
   fantasai: But from an authoring perspective, it doesn't make any sense
             for the abspos to leave anything behind
   fantasai: The out-of-flow should just disappear from its original
   Tab agrees that it should not affect layout where it used to be (but
       is no longer)
   <oyvind> does it break compat?
            is shown here...
   fantasai: it's easy to say that the abspos elements don't affect box
             generation in their former location, but it's harder to
             stay then what the static position is
   ACTION: Tab write a proposal

   Bert: There were some changes to the behavior in Boris's proposal,
         are those still there?
   Bert is concerned about changes to the spec
   Tab asserts that the spec had a lot of errors, and this cleanup is
       the right direction to go in
   <TabAtkins> <style>div { display: table; }
               span.tc { display: table-cell; }</style>
                 <span class=tc>foo</span>
                 <span class=tc>baz</span>
   Tab: Given this testcase, you see one row in Firefox and Chrome,
        not one table with three rows
   <sylvaing> same results in IE8 and Opera 10.51
   fantasai: bz did a lot of testing of all the major browsers when
             he was writing this
   fantasai: and tried to write something that was as compatible as
             possible with all of them
   Tab: Looks like current 2.1 also specifies a single row
   <TabAtkins> To be specific, I misread the proposed algorithm.
               It does indeed mandate the behavior that we see in
               browsers for that testcase.
   Peter: Any other issues? Everyone's ok with the proposal?
   Bert: yes, I can't read it in such a short time
   Bert: I'll complain later if I see problems with it
   RESOLVED: Provisionally accept bz+fantasai's table anonymous
             box proposal for CSS2.1

CSS3 Fonts Issues

   <jdaggett> http://lists.w3.org/Archives/Public/www-style/2010Mar/0553.html
   jdaggett: Bert posted a list of comments on the css3-fonts spec
   jdaggett: There are both editorial and substantial comments.
   <jdaggett> http://lists.w3.org/Archives/Public/www-style/2010Apr/0069.html
   jdaggett: I fixed most of the editorial comments
   jdaggett: Here are my responses

   jdaggett: The first issue is about font-stretch not being included
             in the font shorthand
   jdaggett: My reason to skip it out was that 'font' already has a ton
             of stuff in it
   ChrisL: When we were working on that we concluded that 'font'
           shorthand was too fragile to alter
   ChrisL: So we concluded to only include settings from 2.1 in the shorthand
   ChrisL: If that's not a problem anymore, then, there's no reason not
           to include it
   jdaggett: I'm on the fence because I don't see font-stretch being used much
   jdaggett: I'll experiment and see if including it into the shorthand works

   jdaggett: Comment B), there was a note because Steve was concerned
             about conflicts. We were talking about whether to have a
   Steve: Offhand I guess I agree with Bert's observation. At the time,
          we had much more volatility going on.
   Steve: If we can update the document to handle it...
   <ChrisL> agree the volatility is manageable
   Steve: Bert's comment is fine, I can live with that

   jdaggett: Comment c) is about the syntax of local()
   jdaggett: Bert is asking whether we should put in wording about the
             syntax if it's not quoted
   jdaggett: I think that sounds good, but I'm concerned about our
             current discussions about unquoted font names
   jdaggett: Some of the proposals don't correlate with an
             easy-to-understand rule
   jdaggett: And I'm waiting to see what happens there
   ChrisL: We should have the same set of restrictions on both font-face
           and font-familky
   jdaggett: I agree with that, but also because of font shorthand,
             there are some restrictions that you need to have in
             font-family that you don't need in font-face
   jdaggett: I think it's really confusing for people
   jdaggett: e.g. a font name that starts with a number causes all kinds
             of problems
   jdaggett: Bert, did you have anything?
   Bert: Trying to find where <font-face-name> is defined
   <ChrisL> I sent in some responses to Bert's comments (before seeing
            John's ones) -
   jdaggett points to the definition
   Bert: My issue is what does "optionally" mean? When do you need
         quotes? When do you not need quotes? When are they optional?
   jdaggett: It's always optional
   fantasai: It can't always be optional. If the font name includes
             brackets or backslashes, you have to quote it.
   fantasai: The best thing to do would be to point to the font-family
             definition. It might be slightly more restrictive than
             necessary here, but I think that's less of a problem than
             having an inconsistency there. You can recommend to quote
             anything with numbers or symbols.
   <szilles> +1 for what fantasai said
   <dsinger> I would recommend always quoting font names.  I would expect
             to have to, in fact.  They are not part of the CSS language
             (keywords in their own right) but values supplied into it.

   jd talks about the font-matching algorithm
   jdaggett: The point here is to do font-matching without downloading
             the font insofar as possible
   jdaggett: because we dont' want to download the font if we don't need it
   Bert: The problem I have is with specifying sythetic bolding / italics
   jdaggett: If someone wants to never have synthetic bolding, they can
             point the bold versions at the same font
   Bert: Hm, I thought the text said something else
   Bert: I thought it meant that, if the descriptor said the font is bold,
         and the font is normal, the UA would have to synthesize the bold
   Bert: I don't object to what you explained

   jdaggett: g) is on whether font-kerning is needed as a property or not
   jdaggett: It's right now specified as on by default
   jdaggett: Authors have the ability to disable it
   jdaggett: It's there for situations where authors don't want kerning.
             These are uncommon, but I think it's important to allow
             authors to turn it off.
   Bert: I think there are so few cases where you'd want to turn it off
   jdaggett: in some cases you might not have the right kerning data
   Steve: What happens with kerning on monospace fonts?
   jdaggett: It usually doesn't have any kerning data
   Steve: I'm trying to think of a case where I'd want to turn off kerning
   jdaggett: For complex script support, there might be cases where you
             need to override that.
   jdaggett: I think I need to come up with specific examples
   fantasai suggests marking it at-risk

   Steve: I hope that everyone agrees kerning should be on by default.
   jdaggett: One of the objections to turning kerning on by default is
             that people compain about performance implications
   jdaggett: This way those people can turn it off.
   jdaggett: I will add a note saying that there's some question of
             whether this feature is needed.
   dbaron: It seems like the perf concerns are less about authors who
           particularly want perf than about things like perf benchmarks
           and stuff
   dbaron: It's going to be somebody testing perf characteristics, not
           an author tweaking a page to make it faster.
   dbaron: If it's measurable in that context, I'm not sure that it is,
           I don't think having a property for turning it off is really
           addressing the perf concern
   jdaggett: Kerning usually requires going through a slower-path API
             for font rendering that allows for more effects
   jdaggett: you have to go through that API for most of the new
             features here anyway
   Simon: In terms of WebKit, we know that kerning has a serious impact
          on pageload perf
   Simon: I'm not sure what the impact of these complex text features
          will be
   Simon: If the expectation is that browsers will suddenly start doing
          all this complex text layout, I don't really see a path to
          getting there
   jdaggett: You have to render a huge amount of text to get a pref lag
   jdaggett: Firefox has had kerning on by default for 2 years now
   dbaron: I thought that was only for large font sizes
   jdaggett: On Windows.
   jdaggett: You can do the measurements, and you can get numbers that
             it's faster to turn it off
   jdaggett: But when you look at documents and what it takes to lay
             them out
   jdaggett: the effect of kerning is a very small part of that
   Sylvain: MS did some testing awhile back, and with kerning on the
            text part of layout was almost twice as slow.
   Sylvain: We haven't done that testing recently, and not sure what
            the effect on total page layout is
   <ChrisL> sounds like we could do with some recent benchmark numbers
            on current platforms
   jdaggett: The APIs were optimized for complex scripts, not for
             additional font features on simple scripts
   ChrisL: We need to get up-to-date measurements
   ChrisL: If we're going to have this discussion, we need to have
           measurements from current builds using current APIs
   fantasai suggests having a default 'auto' value that lets UAs pick
            a compromise between perf and prettiness
   fantasai: If an author wants it on, they can pick the always-on option
   dsinger, Bert: it makes sense to have the browsers compete on perf
                  vs prettiness
   Steve: We should recommend that kerning be on by default
   Steve: That's the default in OpenType
   <ChrisL> sounds like a three way auto | on | off where auto mean
            "should be on"
   <fantasai> "but could be off if the UA decides the perf isn't worth
               it in some cases"
   Sylvain discusses sub-pixel positioning and that turning kerning
           off can be helpful for debugging sites
   Sylvain: and on certain sites, where the author isn't expecting it,
            can alter the layout in ways the author does not want
   jdaggett: So what I'm taking from this is that kerning is a property
             with three values: 'auto', which means UA decides, but
             recommended to be on, 'normal', which means on, and 'none'
             which means off


   dbaron: I sent some comments on the CSSOM issue over email.
   Tab too

Meeting closed

Received on Thursday, 22 April 2010 20:33:24 UTC