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

[CSSWG] Minutes and Resolutions Paris F2F 2012-02-08 Wed AM I:

From: fantasai <fantasai.lists@inkedblade.net>
Date: Sun, 12 Feb 2012 02:17:16 +0100
Message-ID: <4F37131C.5010301@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
Dropping Prefixes
-----------------

   Discussion of whether to drop prefixes pre-CR for transforms, transitions,
   and/or animations.

CSS3 Images
-----------

   RESOLVED: WAIPF gets until 22nd of February to send LC comments, since
             they requested an extension.

CSS2.1 Errata
-------------

   - Proposed that root element does not establish a BFC, but participates
     in one stablished by the ICB; resolution pending review.
     https://www.w3.org/Bugs/Public/showbug.cgi?id=15702

   - Discussed interaction of scrollbars with box model and whether spec
     prose requires fixing.
     https://www.w3.org/Bugs/Public/showbug.cgi?id=15880

   - RESOLVED: For percent heights inside auto heights, change
       "The value computes to 'auto'"
     to
       "The value is treated as 'auto' for the purpose of calculating
        the used value"
     and fix the computed value line.
     https://www.w3.org/Bugs/Public/showbug.cgi?id=15392

Media Queries
-------------

   - RESOLVED: dpi/dpcm in 'resolution' media query uses CSS units.
   - RESOLVED: In section 4.11 ('resolution'), append after the first paragraph
               "For printers, this corresponds to the screening resolution (the
                resolution for printing dots of arbitrary color)."


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

Present:
      Rossen Atanassov (Microsoft)
      Tab Atkins (Google)
      David Baron (Mozilla)
      Bert Bos (W3C)
      John Daggett (Mozilla)
      Elika Etemad (Mozilla)
      Simon Fraser (Apple)
      Sylvain Galineau (Microsoft)
      Daniel Glazman (Disruptive Innovations)
      Vincent Hardy (Adobe)
      Koji Ishii (Invited Expert)
      Håkon Wium Lie (Opera)
      Chris Lilley (W3C)
      Peter Linss (Hewlett-Packard)
      Luke Macpherson (Google)
      Alex Mogilevsky (Microsoft)
      Anton Prowse (Invited Expert)
      Florian Rivoal (Opera)
      Alan Stearns (Adobe)
      Steve Zilles (Adobe)

Observers:
      Jet Villegas (Mozilla Corporation)
      Tavmjong Bah (Inkscape)

<RRSAgent> logging to http://www.w3.org/2012/02/08-css-irc
Agenda: http://wiki.csswg.org/planning/paris-2012

Dropping Prefixes
-----------------

   ScribeNick: fantasai
   plinss: How long do you want?
   fantasai: 15 min
   Tab: Proposal is transforms, animations, transitions syntax is fully stable.
   Tab: So although the spec has some issues for CR, we propose to drop prefixes
   smfr: 2D or 3D transforms?
   Tab: Don't know
   glazou: What makes you think they're stable?
   Tab: Syntax hasn't changed in years
   ?: but you just proposed changing functional notation
   glazou: What about commas in functions?
   Tab: We'd have to preserve back-compat anyway
   Steve: Let's discuss on mailing list

   glazou: I think I agree with you in general
   glazou: I want to make sure we don't have clockwise/counter-clockwise
           disagreement in the implementations
   dbaron: That's a 3D issues, and we changed the spec to match implementations
   glazou: I want to make sure we don't get exactly opposite results in
           2 different browsers
   Vincent: Shulz has raised parsing issues wrt transforms, we need to
            discuss to finalize that
   <smfr> http://www.w3.org/Graphics/fx/wiki/MergedTransforms#DifferencesbetweenSVGTransformsandCSSTransforms
   dbaron: I think it's 3 years too late for that

   fantasai: The proposal is to list these under the legacy clause of
             the 2012 snapshot.
   fantasai: These are the top things on the pressure-to-implement-
             -webkit-prefixes list
   smfr: Listing these three as exceptions seems wrong; the right thing
         seems to be accelerate the spec to CR.
   smfr: Does dropping the prefixes let us fix the spec problems?
   Tab: We want to make sure this happens before IE10 releases
   sylvaing: It's possible, but I can't commit to it.
   glazou: Should we make a difference here between transforms and animations
           on one hand and transitions on the other?
   smfr: 2D Transforms and Transitions more stable, Animations next,
         3D Transforms last
   dbaron: I think 2D Transforms, then Transitions, then 3D Transforms,
           then Animations
   dbaron: The Animations spec is such an incomprehensible mess.
   sylvaing: Difference between early webkit on one hand and opera/ff
             on another for Transitions

   jdaggett: Object model for animations is not implemented the same way
   Tab: Just talking about the properties, not OM stuff
   jdaggett: So you're saying that all can change, even in an unprefixed state?
   Tab: We don't worry too much about OM for animations too much, people
        don't use it much.
   dbaron: Are you talking about the constant thing?
   jdaggett: It's small, but key.
   smfr: I think we can fix that.
   jdaggett: You're saying there will be changes that affect implementations,
             but the syntax won't change.
   Tab: Right.
   Tab: If people think we have problems that will be fixed by grammar
        change, speak up.

   sylvaing: 2D Transforms most ready. For IE10, could *maybe* drop prefixes.
             But if we change functional notation, will be hard.
   Tab: We agreed that even if we drop commas, we'd still accept with all commas
   sylvaing: I can see making an exception, but spec goes out as-is.
   jdaggett: I'm arguing for pushing to CR more quickly
   sylvaing: It would be more likely to drop prefixes if we don't change
             the functional notation
   Tab: What about transitions or animations?
   glazou: It's not only the syntax, Tab.
   glazou: If we discover an inconsistency to fix, we might have to change
           behavior to avoid breaking websites.
   <dbaron> For the record, I agree with Tab's proposal for at least 2-D
            transforms and transitions, and animations.
   glazou gives example of video editors, which we don't consider
   glazou: Changes can happen
   Tab: We are far too stable to change them.
   Tab: roc asked to drop prefixes 3 months ago, we havn't moved forward.
   ...
   Bert: Let's make an LC then
   Tab: Are they ready for LC? There are still things that need to be
        cleaned up in the specs. They still have issues
   Vincent: The merge effort has been raising parsing issues.
   dbaron: I don't think we should wait for the merge effort.
   Vincent: I don't argue with that, but I think we should at least look
            at what the issues are. On the syntax side, see if there's
            anything pinning us into a bad corner in the future.
   Vincent: If we make a decision to move the spec forward, and that
            prevents the merge from happening, that's a problem.
   Vincent: As long as we don't paint ourselves into a corner, we can make
            tweaks later.
   smfr: I think most changes are relaxing the parsing rules.
   Vincent: May not be that bad. All I'm asking that we have the discussion
            of what the issues are.
   dbaron: Then I think we need to have that discussion today.
   Vincent: Dirk has posted issues and analysis, see smfr's link
   <smfr> http://www.w3.org/Graphics/fx/wiki/MergedTransforms#DifferencesbetweenSVGTransformsandCSSTransforms
   Florian: If you find something that might be worth changing behavior for,
            we can do it, just can't do consideration for what might break.
   Florian: If it's nice to change, but not necessary, at this point might
            already be too late.

   sylvaing: There are still difference between ways implementations treat
             stacking context, etc.
   sylvaing: We also have a policy if you drop prefixes, you have to submit
             an implementation report. I don't want to make an excetion to that.
   sylvaing: We need to drive interoperability. If some small subset of
             shiny demos work, that's not enough.

   glazou: Let's go to CR asap
   Florian: We could drop prefixes before CR. We just have to look through
            all the issues and make sure that the issues that remain to be
            solved can safely be solved after dropping prefixes
   Steve: Send to the list that want to go to CR ASAP, and ask for people
          to submit their issues ASAP.
   dbaron: We've submitted a bunch of tests for 2D and 3D transforms, and
           Aryeh's been adding to them practically daily.
   smfr: Unfortunately tests rely on undefined behavior.
   * fantasai finds it odd that people want to implement webkit prefixed
              properties, but the same people don't want to drop prefixes

Question from WAIPF WG
----------------------

   Bert: They want 2 weeks more to review Images LC. Ask until Feb 22.
   fantasai: Can we ask them to send any identified issues as soon as
             they have them, so we can start addressing them, rather
             than waiting to collect them all and submit at the end?
   glazou: Probably don't have identified issues yet, just a time constraint.
   glazou: Any reason to answer no?
   glazou: Ok, resolved.
   RESOLVED: WAIPF gets until 22nd of February to send LC comments.

CSS2.1 Errata
-------------

   plinss: Would not want to spend all f2f time on 2.1 issues
   anton: Agree. Just these 6 issues would benefit from all implementers
          being present here
   plinss: If just need implementers, might make sense to do a small subset
           f2f with just those people
   plinss: Get all the proposals together, and then bring to WG for approval.
   Alan: could be a day or two before or after
   Anton: Requires implementers to have time to sit down and think about it.

   <antonp> https://www.w3.org/Bugs/Public/showbug.cgi?id=15702
   <dbaron> testcase: https://bug590491.bugzilla.mozilla.org/attachment.cgi?id=469029
   dbaron: Don't know if we checked what IE10 did
   ...
   dbaron: I'm not sure what happens if the root is floated. Might have
           ICB establish a BFC, too.
   anton: There does have to be an initial BFC.
   Anton: Question is does the root element also establish a BFC
   <dbaron> Based on that testcase, WebKit and Gecko consider the root to
            be a BFC and IE9 and Opera do not.
   <dbaron> sylvain, rossen: IE10 matches IE9
   fantasai: So what's the next step here?
   dbaron: I happen to think Gecko is wrong here.
   Anton: Do you think there ought to be an initial BFC?
   dbaron: Yes
   Rossen: That one I agree with.
   Anton: So the root element does not establish a BFC, but it participates
          in one stablished by the ICB
   sylvaing: I would like Arron to review this proposal.
   ACTION Florian: Check with Opera that this is okay
   <trackbot> Created ACTION-437
   ACTION Sylvain: Check with Arron that this is okay
   Florian: On this item, behavior hasn't changed.
   Rossen: So you're ok with the resolution?
   Florian: Sure

   <astearns> https://www.w3.org/Bugs/Public/showbug.cgi?id=15880
   Anton: Interaction of scrollbars with CSS box model is not well-defined.
   Anton: Interesting sentence in question is in 11.1.1
   Anton reads the bug report
   fantasai tries to explain what the spec says
   dbaron: We need testcases to determine what happens
   smfr: Also need to leave some things up to UA; in OS X the scrollbar
         just hovers over the content.
   dbaron: I think we need an action item for someone to write a bunch of
           testcases
   fantasai: I think the spec makes sense here when width is auto, but
             doesn't make sense when it's not auto.
   dbaron says something about shrinkwrap
   dbaron: I think the spec is internally consistent for [...] but
           doesn't match implementations
   fantasai: I'm unsure about shrinkwrap case, but I think the sentence
             in the bug report makes sense for auto width in non-shrinkwrap
             case.
   fantasai: I think the testcases you need are fixed width, auto width,
             shrinkwrap width
   dbaron: and height
   <dbaron> ACTION anton to create tests for https://www.w3.org/Bugs/Public/showbug.cgi?id=15880
   <trackbot> Created ACTION-438

   <astearns> https://www.w3.org/Bugs/Public/showbug.cgi?id=15392
   Anton reads from bug report
   fantasai: I don't think you can make the used value auto. You can treat
             a computed value of a percentage as auto in the calculations,
             but used value needs to be an absolute length
   fantasai: All you need to change is in that sentence where it says
             "The value computes to 'auto'" say "the value is treated as
             'auto' for the purpose of calculating the used value"
   <fantasai> (and fix the computed value line)
   dbaron: I think that's fine.
   RESOLVED: Proposal accepted

   <astearns> https://www.w3.org/Bugs/Public/showbug.cgi?id=15389
   Anton proposes leaving the problem of having an overly-broad undefined
         clause to be solved in CSS3
   dbaron: Bug says there are cases that should be undefined that aren't.
   [people generally agree that making more than necessary undefined is
    okay; issue of things that need to be undefined but aren't should be
    handled -- deferred to later]

Media Queries
-------------

   Florian: When defining <resolution> in MQ, we didn't specify whether
            they are CSS in and cm, or whether they follow the usual
            definition
   <dbaron> http://dev.w3.org/csswg/css3-mediaqueries/#units
   dbaron: So the first sentence of section 6
   dbaron: "The units used in Media Queries are the same as in other parts
            of CSS. For example, 'px' represents CSS px, not device pixels."
   Florian: Definition of dpi doesn't say though
   Florian: Also other spec that redefines <resolution> makes it explicit
            that these are CSS inches etc.
   Florian: But this spec is not explicit.
   ...
   fantasai: dots are device pixels
   Question is what is the inch.
   dbaron: I think in our case it's a physical inch, not a CSS inch.
   sylvaing: Do you want number of device pixels per CSS inch or per physical
             inch?
   <dbaron> http://dev.w3.org/csswg/css3-images/#resolution-units
   * Bert thinks we can go ask what an inch is: We're in Paris, not far
     from http://en.wikipedia.org/wiki/InternationalBureauofWeightsandMeasures :-)
   Steve: I think dp physical inch makes most sense
   fantasai: Problem is that if you try to use resolution and width to
             calculate the dots across the width, you can't if the inches
             don't match up
   dbaron: What are people using resolution for?
   Florian: They aren't, they're using device-pixel-ratio
   smfr: Webkit doesn't support 'resolution'
   sylvaing: What do you do with that?
   smfr: You decide whether you load high-res implementations or not.
   dbaron: I would like to know what other implementations do, since this
           has been in CR a long time
   Florian: We did CSS inches for a long time, but recently started, on
            mobile-only, doing physical inches, but only on mobile.
   plinss: Being inconsistent makes no sense
   dbaron: Doing CSS sizes is much harder because you have to proxy all
           your device pixel ratio computations into resolution
   dbaron: I guess we just compute it entirely ...
   dbaron: But that would mean you can't get the physical size of the device.
   Florian: This doesn't give you physical size of a display
   dbaron: I wrote a script that did multi-step computation to find the
           physical size of a device
   Florian: [...]
   Steve, summarizing Florian: The CSS pixel is intended to encapsulate
     viewing distance and size together because that's what actually
     matters to the viewer.
   plinss: I think if we interpret inches differently in different places
           we're asking for trouble.
   ChrisL: Does that mean you can get the number of physical dots per CSS px.

   <dbaron> http://lists.w3.org/Archives/Public/www-style/2008Apr/thread.html#msg126
   <dbaron> oh, wait, that was about the dot part rather than the inch part
   dbaron: I don't see this thread having a clear conclusion
   Tab: Answer to original question of whether dots are CSS px or device px

   ChrisL: If so, what do you get from a printer?
   Tab: What's the problem here?
   Tab: Are printers lower-res than dots?
   ChrisL: The screen resolution is a lot smaller than the device resolution
   ChrisL: for a printer
   ChrisL: they combine ink colors to make a color
   ChrisL: So should we clarify printer situation?
   Tab: Yes, let's clarify that the device pixel in this case is the dot
        of arbitrary color.
   ChrisL: So the screening resolution
   Florian: The whole point of this is to supply high-res images
   ChrisL: but if they're choosing high-res vs low-res images, and they
           get back 200dpi from the printer as the screen res?
   ChrisL: The author who wants to figure out whether they have a high-res
           printer will expect 1200dpi
   Tab: Difference between high-res screen (~200dpi) and printer should
        be easy to distinguish
   ChrisL: A typical screening resolution is 175dpi
   fantasai: Question is, if the screening resolution is 200dpi and the
             other resolution is 1000dpi, do I send the printer a 200dpi
             image or a 1000dpi image?
   Koji: To answer fantasai's question, if it's a monochrome image you
         should use 1000dpi, and if it's color or grayscale you should
         send 200dpi
   fantasai: We can't make that distinction in Media Queries
   fantasai: To make that distinction you need both resolutions, and we're
             only providing one.
   ChrisL: The author can assume that 1000dpi gets you 200dpi screening
   fantasai: What if someone creates a device that has screening 600dpi
   Steve: Why not add a media query on screening?
   ChrisL: You need the physical dots per inch as well.
   Steve: No, instead of reporting actual results, ... it has to be reported
          with the same assumptions as the other resolutions.
   Steve: If you add a media query for screening, it's going to report
          information back. All I'm saying is that as long as the
          information is reported using the same assumptions as the other
          media query things, that will tell you whether the dpi is
          different from screening resolution and by how much.
   ChrisL: Given what you've just said, if I have high-res printer, what
           number do I send back?
   fantasai: Most people send images that are more than one color. So we
             should return the resolution that is applicable to that.
   fantasai: and add a media query that gives the other number, if needed
   ChrisL: Add "Therefore for printers this is the screening resolution."
   tab: Need explanation for non-printer-geeks
   fantasai: I like Tab's suggestion of "dot of arbitrary color".
   ChrisL: Should have both.

   sylvaing: Since when we zoom, we change the number of physical pixel
             to CSS px
   sylvaing: As soon as you zoom, you change whether the media query matches
   fantasai: you have the same problem with device-width, which is already
             known to be in CSS inches.
   fantasai: you need to exclude zoom from this.
   dbaron: I think FF has a bug with zooming
   dbaron: But I don't think what happens with zooming correlates with
           whether we're also including snapping to CSS px/in definition
   Florian: So based on that you're comfortable defining in terms of CSS px
   sylvaing: seems like it
   Rossen: Looking through the code it looks like we are doing CSS px/in
   plinss: Proposed to resolve as dpi/dpcm in CSS inches/cm
   dbaron: I'm not particularly happy with it, but okay.
   Florian: Unhappy that we're changing now, or unhappy about what we're
            changing to.
   dbaron: both
   Florian: We have to change too. Allowing use of 'resolution' in place
            of 'device-pixel-ratio' also makes more sense this way
   sylvaing: This is the author-facing behavior.
   sylvaing: it's got to be CSS px/in
   dbaron: Can I tentatively accept and double-check with roc?

   Bert: Question about what this means. It's confusing.
   Bert: So I'm looking at iphone display, sold as 326dpi
   Bert: What would be the CSS resolution in that case?
   Florian: It depends
   plinss: You're in the mobile pinch-zoom world,
   Florian: Fairly likely that resolution in dppx would be 2
   dbaron: It would be 192dpi
   sylvaing: When you do zoom in FF, what do you do?
   dbaron: I don't actually know
   sylvaing: talks about a testcase that changes bg color

   Florian: Is anyone aware of common use of 'resolution' in the wild
   dbaron: Probably not because webkit doesn't implement it
   <dbaron> For the record, roc is ok with the proposed change to the
            resolution media query.
   RESOLVED: dpi/dpcm in 'resolution' media query uses CSS units.

   plinss: To close loop on Chris's tangent on screening.
   fantasai: The proposal is to define resolution as screening resolution,
             and explain what that means.
   Section 4.11
   Append after the first paragraph in the 'resolution' section
   "For printers, this corresponds to the screening resolution (the
    resolution for printing dots of arbitrary color)."
   RESOLVED: Accept proposal for clarifying 'resolution' MQ for printers.
   ACTION Florian: File an issue on MQ4 about adding the other resolution
                   (for monochrome printing)
   <trackbot> Created ACTION-439
Received on Sunday, 12 February 2012 01:17:46 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:50 GMT