- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 14 Jan 2010 01:16:01 -0800
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- Reviewed status of CSS2.1 test suite and next steps
- RESOLVED: Tab's response to PF on css3-background
http://lists.w3.org/Archives/Public/www-style/2010Jan/0112.html
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 ======
Present:
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
--------------------------------------
http://lists.w3.org/Archives/Public/www-style/2010Jan/0109.html
<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
representation
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
interoperability.
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
significant
Chris: Accepting scientific notation would allow better HTML-SVG-CSS
integration
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
-----------------------
http://lists.w3.org/Archives/Public/www-style/2010Jan/0152.html
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