- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 04 Feb 2010 15:54:37 -0800
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- CSS2.1 Test Suite Alpha 1 being published today
http://www.w3.org/Style/CSS/Test/CSS2.1/20100127/
- RESOLVED: move forward with joint css/svg TF: arrange joint afternoon
meeting at next F2F if possible, set up telecons, work on
charter, etc.
- RESOLVED: Move August F2F to 23-25
- Discussed pts vs pixels thread:
http://lists.w3.org/Archives/Public/www-style/2010Jan/0058.html
Proposal is to fix 96px per inch. Whether inches fixed to reality
or pixels fixed to screen res / viewing distance may vary (print
would match real inches, screens align with viewing distance +
screen res).
====== Full minutes below ======
Present:
César Acebal
Tab Atkins
David Baron
Bert Bos
Arron Eicholz
Elika Etemad
Daniel Glazman
Brad Kemper
Håkon Wium Lie
Peter Linss
Steve Zilles
<RRSAgent> logging to http://www.w3.org/2010/01/27-CSS-irc
Administrative
--------------
plinss: additional agenda items?
plinss: David, you had an action item last week.
dbaron: Didn't get to it.
plinss: ETA?
dbaron: Hopefully next 2 weeks, but I'm pretty busy.
plinss: We'll return to that when we can.
CSS2.1 Test Suite
-----------------
plinss: First real topic. Css2.1 test suite. Where are we on that?
fantasai: Checking in Alpha 1 right now.
fantasai: Haven't been able to add in Hixie's tests, because they don't have
metadata.
fantasai: Can't index them without the metadata.
fantasai: Also haven't yet added all the ref tests, because I haven't
figured out how to present them.
<Zakim> +Bert
fantasai: Other than those, pretty much everyting is built and should be
checked in by the end of the call.
arronei: I know for Hixie's tests I was planning to add the metadata, so
you should be able to index them by early next week.
arronei: Also my feedback for all the reviews, I'll start sending out today.
arronei: If anyone's got tests submitted, take a look at issues on the tests.
plinss: Sounds like good progress there.
plinss: Anything else you guys need?
fantasai: Arron, you want comments on reftest format, or talk about it later?
arronei: Later. Need to do some research first, I"ll send out an email.
CSS/SVG task force, cross-group ftf meeting
-------------------------------------------
plinss: Perhaps coincident with our ftf meeting?
glazou: Long chat with Scheppers, both agreed that the best way to harmonize
css and svg, maybe webapps, is to dedicate one day (or half-day)
of our upcoming ftf to joint meeting with svg.
glazou: We both think it's better than a localized bay area meeting, because
some people would be out of the loop.
glazou: We discussed that svg relies heavily on CSS, but not enough
integration.
glazou: Both are major technologies, now is the time to start discussing
better interaction between the two groups.
glazou: Idea is to actively discuss what's going on in both svg and css so
other groups know.
glazou: Start with ftf with one joint day, and see if we can do better in
the future and come back to "mini-TPAC idea" with svg/css/html/
webapps all together.
glazou: And of course the effect tf is probably the best place to start with.
glazou: We could schedule an extra conf call for those interested in it.
plinss: confereence call was suggested for thursdays?
glazou: That's the first date doug proposed, but it's not firm. open to
discussion.
plinss: Opinions?
TabAtkins: in favor
plinss: Anyone else?
glazou: I think it's good. Frex, pointer-events property came from SVG,
and now Moz and Apple implemented it for html. But it was never
standardized in CSS, so harmonization is needed here.
plinss: Anyone willing to participate?
glazou, TabAtkins: yes
plinss: Thursday good for you guys?
glazou, TabAtkins: Sure.
brad: Might be able to come on Thursday sometimes.
plinss: Kick off now, soon, wait for ftf?
glazou: Let's discuss with Doug. We need to confirm the date/time/length.
glazou: And other things to do.
szilles: We need to have a clear charter of what it's trying to accomplish.
glazou: Absolutely. That's first item in Doug's email.
plinss: Hearing support, no objections?
RESOLVED: Move forward with joint css/svg work
glazou: I'll notify Doug.
<shepazu> [I suggests starting the telcons before the f2f]
<glazou> shepazu, 1h30 may be too much for 8pm UTC for me
<shepazu> glazou, we would just hold a 30 minute meeting to start, use
the rest just for SVG
Shifting August F2F dates
-------------------------
plinss: szilles, you want to shift dates?
szilles: Yes, a week later. dsinger also wanted to move them.
howcome: Yeah, moving it is fine with me. dsinger preferred early,
szilles preferred late part.
glazou: The end of that week will be extremely busy wrt air travel.
End of summer break for schools in europe.
glazou: If we go to end of week, I recommend you book flight asap.
szilles: That's fine, do it at the beginning of the week.
howcome: I think school in norway has already started by then?
plinss: 23rd to 25th is what I'm hearing?
RESOLVED: Move august ftf to 23-25
pts vs pixels
-------------
plinss: Seems like the thread's died down.
plinss: Only issue is Brad's zoom issue.
bradk: Seems like the zooming would help if the ratio is wrong for a
particular screen.
plinss: Question is if we're solving zoom in the right place, and
metaquestion - can we table that discussion and resolve zoom
in a later part?
bradk: I think we should suggest that there's some way for the user
to change the ratio if the browser doesn't get it right.
bradk: I'm willing to forgo author control.
plinss: Some OSes have it, but browsers dont' respect it, and browsers
have their own zooming controls
plinss: I think it's okay to recommend browsers giving users this
control, but it's not something we can mandate.
bradk: My iphone already has that control.
plinss: iphone zooming is just part of the normal way of dealing with
zooming in and out.
bradk: I'm not sure if the way the current zooming is ipmlemented,
if it's exactly the same as just setting how big a CSS px is,
or is there more to it than that?
bradk: But that's an impl detail, we can just recommend that there's
a way out of it.
plinss: So back to pts vs px. Not hearing any objections against
sticking px to 96/inch
plinss: And media determines what unit to use as base.
szilles: That seems to be a complete reversal of subtended angle.
plinss: That still comes into play when you're mapping css px to
device pixels based on device.
plinss: Some devices you'll know the relation between device pixels and
real-world units, and want to align those. Screen, not so much.
szilles: It seems to be a major reversal, and an inconsistency with SVG.
TabAtkins: I think we're just speccing what browsers are doing now.
Bert: I thought that the spec already said that?
Bert: Basic computer screen, with sufficient dpi, has 96px to the inch.
szilles: I thought the subtended angle was supposed to do that.
bradk: But there's really no way to, precisely, figure out the angle.
szilles: Makes sense.
szilles: What I think we're trying to solve is that px dimensions stay
commensurate with absolute units.
Bert: On a device, but we can't define that across devices.
plinss: But we can define the ratio. We nail 96 px to 1 css inch.
Bert: But CSS pixels should be tied to device pixels.
[rehashing of mailing list discussion about physical units and pixels]
Bert: There's no error in the spec. We can't change the spec because
people implement it wrong.
plinss: We do that all the time to match reality.
TabAtkins: IE and Safari both use the set ratio. Gecko doesn't (it
conforms to the spec?), and it makes pages wonky sometimes.
howcome: So, change proposal is making px just a ratio of a physical
unit, like cm and in have.
plinss: Yeah.
howcome: I see the benefit of interop, but you lose expressibility.
howcome: You can't use px when you need px, and absolute when you
need absolute.
howcome: But right now, you can't rely on physical lengths.
plinss: Right now, the css pixel has no guaranteed relationship to any
other unit in CSS.
howcome: That's not a problem.
plinss: We're getting complaints from impls about the two being
disconnected.
howcome: I'd like to see a test case for this.
plinss: dbaron, you guys seeing any bug reports?
dbaron: Not specifically, but in general browsing, I'm seeing problems,
esp. in china. But I haven't been following individual bugs.
Bert: Most common unit ever is "em" and "px", except font size which is
specified in pt for some reason.
Bert: We need a blog post or something to say "No, you don't have to use
points, you can use other units."
?: You have a strong belief in education, and I'm with you here. We're
losing something here.
<dbaron> http://www.bjbus.com/ (Beijing bus site) used to break at DPI
larger than 96dpi, but it seems better now
TabAtkins: Is that loss *important*?
howcome: People will take things to print, etc, and screw things up there.
plinss: No change will be made to print media. In print media, a px is
almost exactly 1/96 inch.
szilles: I think we're getting confused by the media issue. Perhaps the
issue of scaling/zooming, like Brad is talking about, is more
important.
szilles: I can see adding a property that defines mapping of px to physical
units, or somehow talks about being a zoomable surface.
szilles: I'm being vague, but I somehow think that fixing px to particular
number just is the wrong thing to do. It's not capturing what
people are desiring. So I'm agreeing with Håkon and Bert.
TabAtkins: MS fixed the ratio several versions ago, and people were fine
with it then.
szilles: But the world was 96dpi then.
plinss: Yes, and now that it's changing, we need to make sure that things
stay the same.
szilles: It seems like there's a better way of solving this.
plinss: Got a solution?
szilles: Wish I did. It seems that the screen is a window to the canvas,
and the canvas may have relevant units, but you may not see all
of the canvas.
szilles: So measuring things on the screen isn't what you want to do.
szilles: But that doesn't happen in print because the document itself is
the window - there is no zooming.
szilles: That's what I think Brad was trying to get at, building the zoom
factor in, as that influences the result too.
bradk: I think that when you're dealing with print, the unit is the unit.
If you're designing something 30ft high, you should be able to say
you want letters x in high.
bradk: But on screen/projection, you'll never know what the physical size
is. You only know what the device driver says, you don't know how
far away people are standing from it.
bradk: So then you don't have in as a reliable measurement, but you do
have device pixels as a reliable measuremenet. And maybe something
that says you'll be better off with 2 device pixels to the CSS px.
but you don't know that is accurate.
szilles: So what I was leaning toward is saying something like that, but
it's the wrong thing. It's not the author that wants to say it,
it's the usage context that wants to.
bradk: Zoom was a property in IE, and apparently has some use. That's why
I suggested that it also be an author-based thing. But that's not
exactly essential to this issue.
szilles: I guess where i come out is that I'd like at least a week to
think more about this. I find it very scare to change the
definition of what pt and in mean.
plinss: We're not changing the deifnition. A pt is 72 to the inch, and
in print media where you know the dimensions, an inch is an inch.
We're talking about fixing the ratio of px to inch, so it's not
a unit that floats indeterminately based on the device.
plinss: What we're trying to stop is the situation where people use px
for everything but pt for text, and the page looks great in IE
and Safari, but okay-to-bad in Gecko based on the device dpi.
Bert: But not everybody believes that ratio.
plinss: But it is the common case, and the current behavior of IE and
Webkit to have a fixed ratio between px and in.
TabAtkins: All this matters only to screens with varying dpis.
Bert: The most dangerous device is a screen with 140 dpi.
TabAtkins: Yeah, that's the big transition point.
howcome: So UAs will have to ask the device driver for the dpi?
plinss: Yes, and that's what they have to do today.
howcome: And why will they trust that? What does the new superunit get
tied to?
TabAtkins: Whatever the browser thinks is appropriate.
howcome: And how does it know what's appropriate?
TabAtkins: Based on whatever information is available and a best guess.
The guess might be bad, but at least it'll be consistent.
plinss: Right now you have a unit that changes according to device pixels,
which isn't useful as we go into the future.
Bert: But then you'll have fuzzy lines?
TabAtkins: Only if the browser maps CSS px to a non-integer number of
device pixels, but they won't do that.
plinss: Except maybe in a zoom mode.
Bert: That's fine, it's a user issue.
Bert: I'm hearing different things between what Tab and Steve are saying.
Steve is talking about ratio with device pixels?
plinss: I'm talking about just defining the ratio between CSS px and the
inch. And the device pixel to CSS px ratio is up to the browser
and user.
Bert: That's what the spec says.
plinss: The spec does not give us a reliable ratio between the px and
a reliable unit.
Bert: Yes.
plinss: That's the one place we want to change.
Bert: And I don't want to change it.
howcome: I still want to see a test page first.
Received on Thursday, 4 February 2010 23:55:16 UTC