- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 21 Mar 2012 17:14:11 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Note: The issue fragment URLs will hook up once I regenerate the HTML version of the DoC.
Summary:
- RESOLVED: New Working Draft for Transforms.
- RESOLVED: Defer directional images (ltr/rtl annotations) to CSS4 Images
to address design-level LC comments.
http://dev.w3.org/csswg/css3-images/issues-lc-2012#issue-37
http://dev.w3.org/csswg/css3-images/issues-lc-2012#issue-41
- RESOLVED: Accept to drop content-box resizing behavior from object-fit;
address use cases in CSS4 Images.
http://dev.w3.org/csswg/css3-images/issues-lc-2012#issue-24
- RESOLVED: Shift object-fit/image-fit back-compat aliasing to Print Profile
http://dev.w3.org/csswg/css3-images/issues-lc-2012#issue-33
- RESOLVED: Approved edits treating unsupported fragment syntaxes as invalid
images.
http://dev.w3.org/csswg/css3-images/issues-lc-2012#issue-14
- RESOLVED: image-orientation inherits
http://dev.w3.org/csswg/css3-images/issues-lc-2012#issue-42
- RESOLVED: image() can accept element()
http://dev.w3.org/csswg/css3-images/issues-lc-2012#issue-27
- RESOLVED: Consecutive page areas are glued together by aligning their
start edges when element calculating bounding boxes. (Resolution
pending approval by Alex and Vincent.)
http://dev.w3.org/csswg/css3-images/issues-lc-2012#issue-26
- RESOLVED: element() deferred to L4 due to outstanding issues and need
for further review cycles
====== Full minutes below ======
Present:
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
Publishing
----------
<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
http://wiki.csswg.org/spec/css3-images/lc-2012#directional-images
http://dev.w3.org/csswg/css3-images/issues-lc-2012#issue-37
http://dev.w3.org/csswg/css3-images/issues-lc-2012#issue-41
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
http://wiki.csswg.org/spec/css3-images/lc-2012#object-fit
http://dev.w3.org/csswg/css3-images/issues-lc-2012#issue-24
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
grow.
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
http://dev.w3.org/csswg/css3-images/issues-lc-2012#issue-33
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:
http://dev.w3.org/csswg/css3-images/issues-lc-2012#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
http://dev.w3.org/csswg/css3-images/issues-lc-2012#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
http://wiki.csswg.org/spec/css3-images/lc-2012#element
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
http://dev.w3.org/csswg/css3-images/issues-lc-2012#issue-35
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.
<silence>
Florian: should we move to other issues?
http://dev.w3.org/csswg/css3-images/issues-lc-2012#issue-3
<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
http://dev.w3.org/csswg/css3-images/issues-lc-2012#issue-27
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
http://dev.w3.org/csswg/css3-images/issues-lc-2012#issue-26
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
it.
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
task
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
element.
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