[CSSWG] Minutes and Resolutions Telecon 2012-03-21

Note: The issue fragment URLs will hook up once I regenerate the HTML version of the DoC.


   - RESOLVED: New Working Draft for Transforms.

   - RESOLVED: Defer directional images (ltr/rtl annotations) to CSS4 Images
               to address design-level LC comments.

   - RESOLVED: Accept to drop content-box resizing behavior from object-fit;
               address use cases in CSS4 Images.

   - RESOLVED: Shift object-fit/image-fit back-compat aliasing to Print Profile

   - RESOLVED: Approved edits treating unsupported fragment syntaxes as invalid

   - RESOLVED: image-orientation inherits

   - RESOLVED: image() can accept element()

   - RESOLVED: Consecutive page areas are glued together by aligning their
               start edges when element calculating bounding boxes. (Resolution
               pending approval by Alex and Vincent.)

   - RESOLVED: element() deferred to L4 due to outstanding issues and need
               for further review cycles

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

   Glenn Adams
   Rossen Atanassov
   David Baron
   Bert Bos
   Tantek Çelik (via IRC)
   Arron Eicholz
   Elika Etemad
   Simon Fraser
   Sylvain Galineau
   Daniel Glazman
   Molly Holzschlag
   John Jansen
   Brad Kemper
   Håkon Wium Lie
   Chris Lilley
   Edward O'Connor
   Anton Prowse
   Florian Rivoal
   Dirk Schulze
   Alan Stearns
   David Storey
   Steve Zilles

<RRSAgent> logging to http://www.w3.org/2012/03/21-css-irc
Scribe: Molly


   <sylvaing> extra agenda item from overtime 2 weeks ago: whether to move gradients to css3-gradients
   Dirk: propose publishing new draft of css3-transforms
   Daniel: Asking for comments about proposal
   Simon: [says something about removing some issue comments]
   Daniel: Objections? Comments?
   smfr: remove green section
   RESOLVED: New Working Draft for Transforms

   * fantasai notes that Flexbox, Variables, and Grid Layout were supposed
     to be published already, but aren't
   * glazou will sort that out with Bert

CSS3 Images

   Daniel: Next up Sylvain and Gradients
   Sylvain: Open issues on features in the spec
   Sylvain: Only one implementation of other features, so maybe we want to
            take gradients into their own draft
   Sylvain: We should make a decision on this
   Florian: We want gradients to get to CR asap, but the CR process itself
            doesn't have to be rushed.
   Sylvain: I think that the feature has been around long enough, we're sitting
            on our hands waiting
   Florian: Getting to CR is urgent. Getting to PR isn't. So if things will hold
            up PR but not CR, it's not a concern.
   Sylvain: In violent agreement, but I want to get it to CR as soon as we can
   fantasai: Can we focus on resolving issues?
   Florian: Let's go through the issues, and if we don't can't resolve the issues
            at the end of this telecon
   <dbaron> um, that makes what order we discuss the issues in a pretty big factor
   Florian: I'm ok if it's a fixed number of more telecons, just not indefinite.
   Daniel: Moving to issues right now
   <ChrisL> link to issues list?
   http://wiki.csswg.org/spec/css3-images/lc-2012 (summary of issues for WG discussion)
   http://dev.w3.org/csswg/css3-images/issues-lc-2012 (full disposition of comments)

   fantasai: First issue is on directional images
   fantasai: Kenny raised some design issues we can't address correctly that
             quickly: 1. noting that ltr/rtl annotations should be per-image()
             rather than per-URL, and 2. suggesting that this feature integrate
             with image-orientation.
   fantasai: I suggest deferring until L4 so we can address these properly.
   Daniel: No Objections
   RESOLVED: defer directional images

Scribe: Molly + fantasai
   fantasai: Object-fit / Changing size of content box
   Florian: We have two concerns about the effect. First, the use case that's
            described for it seems useful, but I'm not convinced that's always
            the behavior you want. Might want to turn it on or off.
   Florian: Second case is if you have max-width to 100px and width is less
            that, it will enlarge the image up to 100px
   Florian: Among the ppl who understand this text, am I wrong to think the
            text says that?
   dbaron: It does say that you enlarge images in a bunch of cases, but I
           think... you're talking about wanting a constraint that shrinks/
           enlarges only if necessary?
   Florian: Problem is max-width + object-fit: contain causes your image to
   Florian: It might be useful, but certainly counter-intuitive
   Florian: So my conclusion based on that, I think we should split that
            behavior out of object-fit so that you have that behavior but
            it's not confused with object-fit contain and cover
   Molly: Sounds like a language problem
   Florian: So my conclusion based on that, I think we should split that
            behavior out of object-fit so that you have that behavior but
            it's not confused with object-fit contain and cover
   fantasai: Maybe we can add a 'resize' keyword that determines the behavior
   fantasai: to allow resizing the box (in level four)
   Florian:  So the proposal is to drop the paragraph, add a keyword in level 4
   dbaron: I think it's good to drop this to L4
   dbaron: I have comments on the feature for L4, not spend time on that right now.
   <Rossen> +1 for moving it to level 4
   sfmr: We have a scale-down keyword...
   <sylvaing> not clear on what the resolution is....
   fantasai: Do we have a resolution on dropping the text?
   Florian: The first paragraph of contain and cover is dropped, use cases
            it solves moved to L4
   Daniel: No objection?
   RESOLVED: Accept proposed changes for LC issue 24

   fantasai summarizes issue about image-fit/image-position aliases of
            object-fit/object-position, which were allowed for printers
   Florian: I think it's useful to specify such things so that new UAs
            can be backwards-compatible
   Florian: But also at the F2F we discussed what an alias means, and we
            don't have a definition.
   Florian: If we allow an alias, we should define it, and discussing
            that might take awhile.
   Florian: This is not the spec to spend this time.
   fantasai: How about we shift this to the print profile
   fantasai: It's printer specific -- not a backwards-compat issue on the Web
   dbaron: I'd also prefer not having aliases here.
   dbaron: I would prefer C to B, but I don't think we need to make that
           decision right now.
   Florian: We can drop it from Print Profile later if it's problematic
   glazou: Can you live with B?
   dbaron: I suppose so.
   RESOLVED: Shift to Print Profile

   fantasai summarizes issue 14:
     Kenny suggested treating media fragments as invalid images rather than
     requiring support in image(). We rejected this because the one major
     purpose of image() in this level is creating safe fallback behavior for
     authors using Media Fragments for spriting. However, for future media
     fragment extensions, we added a clause stating an unsupported fragment
     syntax for a given image type makes the image invalid (triggering
     fallback to the next image in the image() list).
   Florian: Don't know enough about the topic. Sounds reasonable to me.
   dbaron: Sounds reasonable to me, should probably run it by the Media
           Fragments group
   ChrisL: We could; should I take an action to do that?
   Florian: Is there another solution?
   dbaron: Has anyone read the media fragments enough to understand? Does
           their error handling conflict with this?
   <fantasai> http://www.w3.org/TR/media-frags/#error-uri
   dbaron: If there isn't any behavior there I don't see any need to run it
           by the group
   RESOLVED: Edits approved for issue 14
   <dbaron> "If a URL uses a fragment identifier syntax that the implementation
     does not understand, or which the implementation does not consider valid
     for that type of image, the URL must be treated as representing an invalid
     image. This error-handling is limited to image(), and not in the definition
     of URL, for legacy compat reasons."
   <florianr> http://wiki.csswg.org/spec/css3-images/lc-2012#image-and-invalid-fragments

   fantasai: image-orientation overview
   fantasai summarizes issue 42
     Kenny suggested to make image-orientation inheritable. The old spec
     listed its inheritance as N/A so this won't even contradict that.
   glazou: Yes, I think this would be more useful for authors.
   RESOLVED: image-orientation is inheritable

   fantasai: element(), lot of issues here - 2 options: Resolve all issues;
             or move to Level 4
   fantasai: Tab removed out-of-document element references, which clears out
             some of the trickier ones - if anyone has any objection to that,
             please speak up
   Hakon: It seems that this other issue with the elements - I would agree
          this doesn't sound highly intuitive
Scribe: fantasai
   Florian: I think I actually prefer proposal B, which is to defer element()
            to CSS4. I am not convinced we can go through all that in a short
            amount of time.
   Florian: Before we get into all issues, I think we might consider moving
            to Level 4 - I am not convinced we have enough time
   Florian: Wrt short, I mean a number of telecons we can agree to right now
   glazou: Still discussing the intimacy(?) of this feature; probably means
           it's not stable enough in everyone's mind.
   Florian: We're discussing whether we need to discuss what you (howcome) said
   dbaron: I think a bunch of these issues aren't all that hard.
   dbaron: we've put them to the end of the list
   Florian: If we can handle by end of next telecon or 3, fine. But not
            unbounded number of telecons.
   glazou: let's not spend time on meta-discussion

   Issue: GCPM element() and Images element() conflict
   dbaron: So I don't think the GCPM and Images conflict. One defines...
           well, ok, yeah.
   dbaron: nevermind
   dbaron: I think the element() name makes more sense in almost all the
           contexts its used. The one exception is 'content', which takes
           images and a bunch of other things.
   dbaron: Could say that element() only works inside image() for 'content',
           but everywhere else ok on it's own.
   fantasai: that seems weird
   <stearns> the number of reviews being solicited suggests to me that more
             issues will crop up, which pushes me towards deferral
   fantasai: So.. options include defining away the conflict in 'content'
             somehow, dbaron's proposal, renaming one or the other, or
             maybe merging the element() functionality into image() somehow.
   Florian: should we move to other issues?

   <glazou> http://dev.w3.org/csswg/css3-images/#decorated-bounding-box
   fantasai: Issue was bounding box is undefined. So we added a definition,
             and used the border image area as the basis of that definition
   fantasai: So the question is, does the WG approve of this.
   fantasai: we chose the border image area rather than the border box so
             that border images wouldn't get clipped if they were outset
   Florian: Sounds ok to me, but far from sure I have my head around all
            the implications.
   dbaron: I want to run this by roc
   dbaron: possible that it should be a little more related to 'overflow'
   fantasai: This parallels the SVG concept of "decorated bounding box",
             which includes not just the geometry of the of the svg element,
             but also the half of the stroke that sits outside it.
   bradk: Should this include outline?
   bradk: Wouldn't want outline to clip
   <ChrisL> outline takes no space (or at least does not cause reflow)
   fantasai: That would make the behavior undefined, since outline position
             is not defined.
   Rossen: outline doesn't include scrolling extents, so why include it here
   smfr: Then you get into issues of should it include box-shadow, filter
         effects that cause spilling, etc.
   Rossen: Seems odd to me to take into account outines for bounding boxes
   dbaron: What is this used for?
   fantasai: calculating the size of the image and its clipping bounds
   Brad: I don't see how 'outline' is different from 'border-image'
   Florian: I'm sure I don't want outlines in there
   <glenn> pixels from rasterizing glyphs also (may and often do) fall outside
           their bounding box; would another term be needed for this?
   dbaron: What does Gecko do?
   * fantasai doesn't know
   fantasai: But it's also a question of what's the right behavior here. In
             most cases border image area matches border area. Question is
             what's best to do in cases where they mismatch
   No conclusion here, moving on.
   <bradk> re: "In most cases border image area matches border area."
           Without border-image, wouldn't the image be clipped to the
           curves when there is border-radius? Would the corner behavior
           depend on if there was a non-initial value of border-image?
   <fantasai> bradk, bounding box is always rectangular
   <bradk> OK. Actually, if border box is used, it would still be rectangular,
           but with transparent areas outside the borde-radius corners. So,
           never mind.

Scribe: dbaron
   fantasai: next issue is issue 27, Allow image() to accept element() so
             that authors can specify fallbacks
   dbaron: sounds good to me
   Florian: sounds ok
   RESOLVED: accept changes for issue 27

   fantasai: Next issue is issue 26, specifying handling of varying-size pages
   fantasai: propose align page content boxes by their start content edges
             before taking the bounding box.
   dbaron: sounds reasonable to me
   fantasai: Other possible options are center-alignment, or end-alignment
             or left-alignment, or right-alignment
   Glenn: so the border on a page is more like outline than border in the
          normal CSS box model?
   fantasai: It's like border, but it's not part of the document formatting.
   fantasai: it's more like decorating the window or chrome of the browser;
             doesn't play with document at all. Document is rendered inside
   RESOLVED: accept text for issue 26 pending alexmog and vincents' approval

   Florian: I don't think we can solve all these issues. I'm fine if we can
            solve all the issue by next telecon. but not if it's an unbounded
   dbaron: I suppose so
   <dbaron> I'd sort of like to hear Tab's opinion
   <oyvind> I find it a bit hard to believe that these are the only issues...
   sylvain: +1 to Florian
   <mollydotcom> "editor doesn't mean decider" - Glazou
   * mollydotcom likes that quote
   * sylvaing editing: with great responsibility comes no power
   <glenn> editor's propose, we members dispose
   fantasai: My position is, I'm uncomfortable taking substantially rewritten
             or new sections of a spec between LC and CR.
   dbaron: element() is NOT the only section of this spec that's been
           substantially rewritten since last call
   discussion of whether to push element() to L4
   - how much time is necessary to resolve issues and get necessary reviews
   - how unstable is the feature, how many more issues might show up
   - etc.
   glazou: gradients is urgent. element() is not.
   (argument between glazou and molly)
   glazou: Given remaining issues and discussion today, I support deferring
   Florian: how do we resolve on this?
   <mollydotcom> I support deferring element.
   * Bert wondering if a generic way to duplicate elements wouldn't make both
          versions of element() redundant. Something like: body {grid: "a . b"}
          div.dup {flow: a, b} /* flow into both a and b */
   Straw poll
   <stearns> +1 to defer
   Poll: defer or work on element()
   sylvaing: defer
   <glenn> defer
   glazou: defer
   Florian: defer
   Molly: defer
   glenn: defer
   arronei: defer
   dbaron: work on it, but ok with deferring
   alan: defer
   smfr: defer
   dstorey: defer
   bradk: defer
   fantasai: I think I would prefer to defer
   anton: defer
   Rossen: defer
   hober: defer
   Bert: defer
   <stearns> that's the most consistent straw-poll I've seen from this group yet
   RESOLVED: element() deferred to L4

   <sylvaing> so moving to CR?
   dbaron: Substantial sections have been rewritten in last week.5, and
           should have time to review those before CR
   <fantasai> +1
   glazou: So let's make decision to move to CR at beginning of next concall
   Florian: Is that long enough for you, dbaron?
   dbaron: I'll see.
   fantasai: Let's go for 1 week and see where we get to.

Meeting closed.

Received on Thursday, 22 March 2012 00:14:41 UTC