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

[CSSWG] Minutes and Resolutions 2010-01-27

From: fantasai <fantasai.lists@inkedblade.net>
Date: Thu, 04 Feb 2010 15:54:37 -0800
Message-ID: <4B6B5E3D.1040705@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>

   - CSS2.1 Test Suite Alpha 1 being published today

   - 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:
     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 ======

   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


   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
   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
   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
   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
   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
   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

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