[CSSWG] Minutes and Resolutions 2010-03-17


   - New alpha of CSS2.1 test suite is out, using new rewrite of build system.

   - Discussion of jdaggett's new CSS3 Fonts draft. Reviewed some issues,
       * WG seems to agree with the level of granularity in the draft.
       * Some concern over applying font-specific settings to a fallback list.
         Extended discussion at:
       * Ongoing discussion about how to handle sub/superscript support in a
         failsafe way. See

   - Discussed Tab's proposal for gradient finite/infinite--ness and an
     'extend' value for 'background-repeat'. See email discussion at

   - Briefly discussed Sylvain's concerns about background-clip. Further
     discussion deferred to later.

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

   Tab Atkins
   David Baron
   Bert Bos
   John Daggett
   Elika Etemad
   Simon Fraser
   Sylvain Galineau
   Daniel Glazman
   Peter Linss
   Christopher cslye (Adobe)

<RRSAgent> logging to http://www.w3.org/2010/03/17-CSS-irc
Scribe: Sylvain

CSS2.1 test suite

   fantasai: new alpha build is out. please review tests, identify build system
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2010Mar/0152.html
   fantasai: if you review a test, please make sure to communicate it by adding
             yourself as a reviewer or mailing the list
   fantasai: we had a request to submit i18n WG testcases
   <fantasai> http://lists.w3.org/Archives/Public/public-css-testsuite/2010Feb/0015.html
   <fantasai> http://www.w3.org/International/tests/list-html-css

CSS3 Fonts

   jdaggett: I posted a draft update including opentype font feature support
             following the f2f discussion last year
   <jdaggett> http://www.microsoft.com/typography/otspec/featurelist.htm
   <jdaggett> http://dev.w3.org/csswg/css3-fonts/#font-variant-ligatures-prop
   jdaggett: There are lot of opentype features
   jdaggett: This proposal groups these features in compound properties;
             there is a granularity trade-off in that you pick a set of features
   <jdaggett> http://lists.w3.org/Archives/Public/www-style/2010Mar/0098.html
   jdaggett: Sergey Malkin preferred the features to be exposed as individual
   jdaggett: this would result in a lot of properties
   fantasai: I think you've done a good job grouping related properties
   fantasai: there is a lot of overhead in having a lot of properties, both for
             browsers and authors.
   fantasai: If needed, we can turn these into compound/shorthand properties
             in the future
   jdagett (answering Tab): for people who have Macs, this is easy to test
           using TextEdit. The font panel shows you available font features
   <jdaggett> http://lists.w3.org/Archives/Public/www-style/2010Feb/0244.html
   jdaggett: some font features are specific to a single font. this could
             have side-effects in a fallback situation
   jdaggett: this primarily affects those OT style settings that use a number
             (e.g. styleset() )
   jdaggett: the other properties do apply across fonts
   jdaggett: cslye: it's not just that some features apply only to one font,
             it's that styleset x in font B might look completely different
             and unrelated to styleset x in font A
   jdaggett: i think the spec could use more background on the rendering model.
   <dbaron> Where is the wording in the spec about the precedence?  (Or is
            it not there yet?)
   * sylvaing missed some of the discussion due to sound issues
   <jdaggett> dbaron: section 7
   <dbaron> jdaggett, section 7 doesn't seem clear whether the order it gives
            is highest-to-lowest or lowest-to-highest precedence
   fantasai: I think it's a good idea to have font-variant-alternates on the
             @font-face, to allow -font-specific variant selection
   fantasai: would we still have these numeric selections in the property?
   jdaggett: yes
   ?: the odds of falling back to a font with a competing equivalent styleset
      are lower. authors will go from most to least specific.
   fantasai: I'm concerned that authors will use the numeric selections on the
             property because it's easier
   fantasai: instead of tying it to the font in @font-face
   jdaggett: it's actually difficult to come up with a realistic scenario
             where this would work
   cslye: I understood stylesets to be a power user feature.
   fantasai: this doesn't prevent breakage, it only limits its frequency
   jdaggett: fallback will still happen
   fantasai: I am still concerned in applying this to all fonts
   plinss: I agree that this may not be a problem in the short term but it
           may be in the future. we should address these issues now

   <jdaggett> http://lists.w3.org/Archives/Public/www-style/2010Feb/0245.html
   jdaggett: one of the features that is not in the spec already relates to
             sub/superscript support
   jdaggett: OT can support a variant glyph suitable for sub/superscript
             resizing. it's also designed to look and feel like the rest
             of the text in that context
   jdaggett: it's analogous to real smallcaps vs. synthesized smallcaps
   <jdaggett> http://lists.w3.org/Archives/Public/www-style/2010Feb/0247.html
   <TabAtkins> character-transform: super|sub
   * bradk is unable to see much in TextEdit that shows additional OpenType
           font features. Found ligatures in Arial, but the checkbox doesn't
           have any effect of fi or ffi.
   jdaggett/fantasai/tab: we need to way to use this OT feature if the glyphs
            are available, but simulate it with vertical-align:super when not.
   <fantasai> that's what Tab's proposal is
   <fantasai> my comment was that the property Tab proposed should also reset
              vertical-align and font-size to their initial values at parsetime
   <fantasai> the same way a shorthand does

   jdaggett: also, it is hard for the spec to be format-agnostic i.e. not
             have a dependency on OT at this point
   dbaron: there is a difference between spec and the test suite. The spec
           may apply to multiple formats but the test suite does not need
           to cover them all.
   fantasai: for other formats, testcases can be submitted for conformance
             using that format by the vendor wanting to claim conformance
             using that format
   <fantasai> Can use examples to illustrate spec with OT-specific features
   <fantasai> For example, the specs don't require support for HTML or XML.
              You could use some other tree-based document format and style
              it with CSS
   <fantasai> But the test suite is written assuming support for XML or HTML
   <fantasai> And all our examples in the specs use XML or HTML

   jdaggett: I will do another edit in the next week

Extent of Gradients in Backgrounds

   Tab: I had imagined gradients to be infinite but it's not how Mozilla
        implemented it
   dbaron: we changed it based on what we thought the spec said
   Tab: I would like to specify that the gradient be 'chopped' to the box
        and the extend keyword would make the gradient infinite
   fantasai: SVG could use 'extend' as well
   <fantasai> Right now content in SVG is clipped to the SVG viewport
   <fantasai> extend could mean don't clip
   <fantasai> So anything painted outside the viewport box would show up
   dbaron: I'd like to hear from Roc
   Tab: Anybody else implemented gradients?
   Simon: Webkit has the old syntax. I agree extend would be useful in
          many cases, and should be the default
   * sylvaing definitely leaves minutes to Elika. VoIP breaking down.
   * fantasai has lost track of the conversation tho!
   Brad says something about gradients being analogous to patterns
ScribeNick: TabAtkins
   bradk: I think that the infinite-version of gradients is more useful,
          and should be the default, and then have a keyword to change
          it to the finite version.
   TabAtkins: That's possible, but the SVG use-case for extend (popping
              it out of the viewbox) is still potentially useful.
              We can experiment with this.
   <dbaron> TabAtkins, Is there a www-style message summarizing the
            background-repeat: extend proposal?
   <dbaron> TabAtkins, I see only http://lists.w3.org/Archives/Member/w3c-css-wg/2010JanMar/0101.html
   <TabAtkins> dbaron: No, let me forward that mail to www-style.

background-clip and background shorthand

ScribeNick: fantasai
   Sylvain explains his concern about background-clip
   Sylvain: About how you can't specify origin and clip in the shorthand
   Sylvain: And there is no content-box value on background-clip
   Sylvain: I don't think we should exclude the people who want to set
            background-clip to the content box
   <fantasai> proposed syntax: Change <bg-origin> in shorthand to <bg-origin>{1,2}
   Bert: I don't think clipping to the content box is very useful, but I
         don't see it's harmful either
   Sylvain: I don't see why it wouldn't be useful to have separate backgrounds
            for the border, padding, and content areas
   Brad: I agree
   Tab: Would be more useful with multiple backgrounds
   Brad: I don't like the proposed background shorthand syntax
   fantasai: I'm strongly in favor of my proposal over Brad's
   fantasai: I really don't want to use a slash unless it's absolutely
             necessary, and it's not necessary here
   Daniel: From a parsing point of view the slash is very ugly
   some argument about syntax
   dbaron: I would note that the initial values of the two properties
           are different
   fantasai: yeah, we know that. Imo it's a bug in the spec that it's
             now too late to fix
   Further discussion deferred to later

Meeting closed.

Received on Friday, 19 March 2010 00:00:02 UTC