W3C home > Mailing lists > Public > www-style@w3.org > January 2010

[CSSWG] Minutes and Resolutions 2010-01-13

From: fantasai <fantasai.lists@inkedblade.net>
Date: Thu, 14 Jan 2010 01:16:01 -0800
Message-ID: <4B4EE0D1.2090209@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>

   - Reviewed status of CSS2.1 test suite and next steps
   - RESOLVED: Tab's response to PF on css3-background
               is the WG's official response.
   - Discussed px vs. pt thread; Tab to write a summary
   - RESOLVED: The UA may transform numeric values on input (e.g.
               limiting their precision or clamping them to a range),
               but anything the UA produces as output it must also
               accept as input.
   - Simon to write up a proposal for putting the above rule in the spec.
   - RESOLVED: Publish css-style-attr LCWD with 3 week LC period.

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


   CÚsar Acebal
   Tab Atkins
   David Baron
   Bert Bos
   Beth Dakin
   Arron Eicholz
   Elika Etemad
   Simon Fraser
   Sylvain Galineau
   Daniel Glazman
   Brad Kemper
   Chris Lilley
   Peter Linss

<RRSAgent> logging to http://www.w3.org/2010/01/13-CSS-irc
ScribeNick: fantasai
Happy New Year Everyone

CSS2.1 Test Suite

   Peter: Calling it done in a few days, see where we are
   fantasai: Not all tests are indexable yet -- e.g. hixie's tests don't
             have metadata
   fantasai: Microsoft's tests are now all indexable
   fantasai: Plan is to publish a snapshot soon so we have a good sense
             of where we are
   dbaron: So I'm expecting to post a refresh of Mozilla's submissions
           soon, sometime this week
   <dbaron> aware of issues in http://lists.w3.org/Archives/Public/public-css-testsuite/2009Sep/0012.html
   dbaron: Boris has some run-in tests that he plans to write and submit
   <fantasai> html2xhtml script - http://test.csswg.org/source/tools/
   glazou: What's ETA for another snapshot?
   fantasai: I think we'll aim to get that done by the end of next week,
             but we'll see what issues we run into
   fantasai: I'll be working with Arron all of next week on the test suite.
   peterl: Do you need help with anything?
   fantasai: If we just get the filenames to not conflict, we can use the
             existing build scripts to throw something up on w3.org
   fantasai: Not ideal, because we can't make .e.g a zipped copy for use
             on windows (which can't handle that many files in one directory)
   fantasai: Hopefully we get the build scripts fixed up for the beta next month
   fantasai: Probably some help in reviewing the test suite for missing
             tests once the index is up..
   <ChrisL> q+ to wonder if adding the xhtml mime type would be easy on csswg.org
   <fantasai> Just change 'svn' to 'source' in the url
   Peter: Since this is our top priority, we'll be checking on this every week

PF Feedback on Backgrounds and Borders

   <dbaron> http://lists.w3.org/Archives/Public/www-style/2010Jan/0112.html
   fantasai: I suggest adopting Tab's response as official
   Brad: does that include the part about media queries?
   fantasai: Yes. We agreed to do that when dsinger brought it up at the F2F
   Everyone agrees with Tab's response
   RESOLVED: Tab's response is official
   ACTION Daniel Respond that Tab's response is the official WG position

Absolute Length Units (pt vs. px)

   dbaron: Do we have good data on what existing browsers are doing?
   Tab: At least for pt, yes.
   fantasai: Can we get a writeup on the thread? All proposals, with pros
             and cons, summary of what seems to be the general consensus,
             who's dissenting and why, what raw data we have, etc.
   ACTION Tab: write up pt px thread
   Peter: Print drivers can scale and zoom as well. You don't want to
          redefine units there
   Peter: That scaling happens way after layout is done.
   Peter: I'm objecting to redefining pt so that it is no longer 1/72 of an inch
   Tab: In one of the browsers it's scaled to 4/3px rather than 1/72 in
   Peter: I don't care what defines what in what order, as long as the
          relationships stay the same
   Peter: We can change the relationship of px to physical units, but not
          physical units to each other
   Peter: that's just insanity
   Peter: We're talking about the px unit, not a device pixel
   <glazou> +1
   Peter: Allowing the px unit to float and scale and size in relation to
          the device pixel is what's leading to breakage
   Peter: because device resolutions are dramatically different these days
   Peter: and will continue to change
   <ChrisL> I think the confusion started when Macs often had 72 pixels
            per inch so 1px was 1 point. Sometimes people still assert
            that points and pixels are joined at the hip like that
   Peter: Allowing the px unit to change to try to match a device pixel
          is what's causing problems
   Bert is really confused now
   Tab: Are we saying that CSS px should not be tied to the device pixel
        in any way?
   Peter: It makes sense in many cases for the UA to round the ratio
   Chris describes the jump from 1px = 1 device pixel to 1px = 2 device pixel
   <ChrisL> they are often rounded to 1:1. Problem is we are approaching
            the time where the dpi is twice 96
   Chris and how it creates a disconcerting discontinuity
   dbaron: On mobile devices, the dpi might be twice 96dpi, but people
           hold them closer so the viewing angle becomes important
   Peter: I think this idea of true inches etc. is also crazy
   Bert: px unit is most useful. It is the only one that is guaranteed
         to be visible everywhere and sharp
   Peter doesn't like px.
   Peter: Then you have problems with bitmap images
   fantasai: One image pixel is 1px. So it will scale with px
   Tab: And because px rounds to device pixels, it's still sharp
   Peter talks about nextstep
   <sylvaing> ..and text is also going sub-pixel...
   Bert: At least on a mac, most browsers display pt too small.
   <ChrisL> sylvaing - yes, subpixel positioning is really helping
   Peter: So Tab will post a writeup to www-style. Anyone else have anything?

Numeric Precision in CSS Numbers

   Simon: It's not specified how numbers get formatted if there are lots
          of decimal places
   Simon: Some browsers report that in scientific notation, which doesn't
          parse back
   <ChrisL> answer is to allow scientific notation
   Simon: I'm looking for how large numbers and numbers with lots of
          decimal points should be round-tripped.
   <dbaron> I consider the scientific notation seralization that we do
            to be a bug; I fixed part of it at one point (I forget
            whether it was the computed style part or the
            CSSStyleDeclaration part)
   Simon: We don't want to go through text for all our apis
   Tab: Opera doing 2 decimals and WebKit doing 6 is weird
   Simon: Opera seems to be using 16 bits to store the number
   <dbaron> X11 is still limited to 16-bit numbers in many cases
   <dbaron> but that tends not to be a real problem
   Tab doesn't understand why it's not 32bits

   Peter: So did we want to allow scientific notation?
   Chris: SVGWG allows scientific notation; we asked for it from CSS
          awhile ago, but the answer was no
   Simon: It's important for transforms, you get numbers very close
          to zero but not quite
   Bert: The precision is another question -- it's about internal

   Peter: Several questions
   Peter: Should we define a minimum precision?
   Peter: Should we allow scientific notation?

   Bert: Precision is defined in bits, not in decimals
   fantasai: I don't think there should be a limit on what we allow,
             but having a minimum makes sense
   Peter: require the browser to be able to round-trip
   <arronei> I really like haveing a minimum definition so I can test
   dbaron: I think anything you can produce as output you should accept as input
   dbaron: Things you take as input, you sometimes transform the first
           time you output them
   dbaron: But anything you produce as output, you should accept as
           input that generates the same output
   <dbaron> (the second one is saying that parse+serialize is idempotent)
   RESOLVED: Accept dbaron's rules.

   Bert: If you're adding up numbers, sometimes the order you add them
         in will affect things
   glazou: Since the browsers sometimes output scientific notation,
           does that mean we accept scientific notation?
   dbaron: That's a bug
   Chris: Bert, would there be a problem adding scientific notation to CSS?
   Bert: The core grammar would have to change. We try not to change that,
         because it's a part of the spec we say we will not change
   <dbaron> you can serialize as 0.00000000275465
   Bert: Why do we need them now?
   Simon: transitions and transforms
   dbaron: Anything that you can serialize in scientific notation you
           can serialize in scientific notation
   dbaron: You just wind up with a lot of zeros that are not necessarily
   Chris: Accepting scientific notation would allow better HTML-SVG-CSS
   glazou: We could investigate how to follow dbaron's rules
   glazou: And investigate what it would take to accept scientific notation
   <bradk> http://en.wikipedia.org/wiki/Scientific_notation#Normalized_notation
   ?: It was rejected before
   <bradk> http://en.wikipedia.org/wiki/Scientific_notation#Normalized_notation
   Chris: Maybe because there wasn't a good argument for it
   glazou: It was rejected before for lack of use case iirc
   <bradk> http://en.wikipedia.org/wiki/Scientific_notation#E_notation
   Simon: Let's say you apply a transform for rotating 89deg
   Simon: You get a matrix back that has some very small numbers
   Simon: Say you want to print that out as a string
   Sylvain: You want to take that matrix and write it somewhere else
   Bert: Why don't you just write out all the zeroes?
   Simon: You'd get a long string of zeroes
   glazou: Scientific notation wouldn't help in cases where you have
           e.g. 1.0000something
   ACTION Simon: Write up a proposal for handling dbaron's rules
   <ChrisL> e.g. 2.007e6

Style Attribute Grammar

   glazou: It doesn't change anything
   dbaron: Yes, but grammar patterns tend to be more reusable if they follow
           the same whitespace patterns
   dbaron: I think ours tend to put whitespace at the end only
   <dbaron> but probably doesn't matter since it's not a complicated production
   ACTION Bert: Review this issue
   glazou: Whatever the result, I think we should publish asap
   fantasai: I'm ok with whatever Bert decides on the grammar, and to just
             decide to publish whatever he decides
   fantasai: The next step is LCWD
   RESOLVED: Publish css-style-attr as LCWD, with whatever Bert decides on
             the grammar issue. 3 weeks LC period

Meeting closed.
Received on Thursday, 14 January 2010 09:16:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:42 UTC