- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 11 Apr 2012 13:12:04 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- RESOLVED: Accept Anton's edit merging the sentences in comment 2 and 3 in
CSS2.1 bug 16049 about margin-collapsing.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16049
- RESOLVED: Accept Anton's edit about margin-collapsing of a min-height
parent and last-child for CSS2.1 bug 16037.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16037
- Closed ISSUE-229 about justification and pre-wrap; text-align already
defines this.
- RESOLVED: Change the animation model to snapshot much less properties.
Details of exactly what snapshotting is left TBD.
- RESOLVED: Treat both mismatched string lengths and non-rectangular regions
as illegal syntax in Grid/Template.
- Discussed -webkit-mask and reflections; and relation to SVG properties and
element(). Edward O'Connor to write up what WebKit implements for masking,
FXTF to help harmonize with SVG
http://robert.ocallahan.org/2008/06/applying-svg-effects-to-html-content_04.html
http://people.mozilla.com/~roc/SVG-CSS-Effects-Draft.html
====== Full minutes below ======
Present:
Glenn Adams
Tab Atkins
David Baron
Bert Bos
Tantek Çelik (via IRC)
Arron Eicholz
Elika Etemad
Simon Fraser
Sylvain Galineau
Daniel Glazman
Vincent Hardy
Molly Holzschlag
Koji Ishii
John Jansen
Brad Kemper
Chris Lilley
Peter Linss
Edward O'Connor
Anton Prowse
Alan Stearns
David Storey
Steve Zilles
<RRSAgent> logging to http://www.w3.org/2012/04/11-css-irc
<glazou> FWIW, we have the transition conf call for both Backgrounds and
Images later today
ScribeNick: TabAtkins
Administrative
--------------
plinss: Last minute items?
glazou: Maybe the email about webkit-mask and reflections.
glazou: I just read that Ted will submit a proposal to the WG.
glazou: But maybe we need to discuss what to do about that.
fantasai: I think we did discuss that at some point.
vhardy: I'd like this to be in the FXTF charter, as this is related to
SVG as well.
<fantasai> IIRC, we concluded that reflections should be done with
filters or some other generic mechanism
plinss: Where will it live and how much priority?
glazou: we don't need to discuss it right now.
plinss: Start with margin-collapsing, then.
Margin Collapsing
-----------------
plinss: Any remaining issues?
antonp: One and a half, yes.
antonp: The one we got halfway through last week...
antonp: Is the bug I'm about to paste.
<antonp> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16049
antonp: This concerned a note in chapter 10 about min-height and max-height.
antonp: It was a confusing note; arron and I came up with a simpler note.
antonp: We just removed most of the note completely.
antonp: But fantasai wanted to keep some mention of margin-collapsing in
that note.
antonp: So she proposed some wording.
<fantasai> http://lists.w3.org/Archives/Public/www-style/2012Apr/0101.html
antonp: Rather than take her exact wording, I thought we could resolve to
something similar.
<antonp> last week fantasai proposed: "for example, margin collapsing is not
affected because it's based on computed values and not used values"
antonp: The proposal can be found in that bug report.
antonp: Scroll down to the very end of the comments to see the proposal from
last week.
antonp: I'm fine with adding an extra line along the lines of what fantasai
proposed, but I'm not entirely happy about her exact wording.
antonp: I agree that a note about margin-collapsing here could be useful
antonp: But if it's needed, it's because the calculation for min/max height
need a temporary value of what the computed height is.
antonp: And the idea of the note is that you're *not* supposed to re-think
about margin-collapsing when doing the real height.
<fantasai> suggest s/affected/recalculated/ in the note
antonp: So I'd prefer what I said in note 3.
antonp: So the full proposal is to take the sentence in comment 2 and the
sentence in comment 3 and put them together.
antonp: last week we agreed on the comment 2 sentence, but there was some
confusion about the comment 3 sentence.
* fantasai defers to dbaron :)
<dbaron> fine with me
plinss: I hear no objections.
RESOLVED: Accept Anton's edit merging the sentences in comment 2 and 3 in
the bug report about margin-collapsing.
<antonp> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16037
antonp: In this case, we've got an auto-height parent with a large
min-height.
antonp: And it contains a last-child.
antonp: Should there be collapsing between the margin of the last-child
and the margin of the parent?
antonp: We discussed this in Paris and drew some diagrams.
antonp: And we more-or-less agreed that we should do collapsing, even
though it seems a bit strange in this case.
antonp: It turns out this bug has a relationship to bug 16036 which we
discussed last week.
antonp: In the comments there's some mention of this, and how it influences
the wording we need to use to fix 16037.
antonp: The proposal is in comment 5 of the bug report.
antonp: This makes things a bit clearer.
antonp: It splits the conditions into a list, rather than a long complicated
sentence.
antonp: In the previous spec it was a complex sentence, but the addition
we're making renders it much harder to read.
antonp: So hopefully we're achieve the desired effect, which is to say
that margin-collapsing does occur between the last child and the
bottom margin of the parent in this case.
antonp: This is currently part of a giant note.
antonp: It was previous normative, but it was recently changed to a note
so it could be changed to more readable and comprehensive normative
text later.
dbaron: So the change is that you're removing the mention of min-height
at the beginning of the sentence, and adding a mention of it in
the third bullet?
antonp: Yes.
antonp: I don't think the current spec is quite wrong, I think it's just
overly specific.
antonp: And because of that, it gives you the impression that you wouldn't
collapse in another condition.
antonp: And we're saying there can be collapsing in another condition as
well.
antonp: Giving very specific conditions can be misleading if there's a
more general rule in actuality.
dbaron: Sounds okay to me, though I haven't worked through it in full detail.
plinss: Can this change behavior in some cases? Do we have testcases?
antonp: I'm not aware of any specific testcases for this.
<Katie> [Microsoft.aa] has Katie
antonp: There are testcases around this, but as soon as you get into complex
sets of conditions for margin-collapsing, there usually aren't
testcases.
antonp: I'm all in favor of adding testcases.
plinss: I'd like to see testcases for this.
antonp: Does that mean you'd like to see a testcase before resolving?
plinss: I think so, unless someone really wants to resolve now?
mollydotcom: I think that personally if the language is clear, it's fine.
mollydotcom: It seems that in what Anton described, that's the behavior
that people expect.
TabAtkins: I disagree - margin-collapsing is ridiculously complicated,
so we need testcases anyway.
<smfr> TabAtkins++
mollydotcom: I just mean that if the language is clear, it's not required
that a testcase appears before we accept the note.
RESOLVED: Accept Anton's edit about margin-collapsing of a min-height
parent and last-child.
antonp: The other issue in the agenda doesn't seem to have priority.
I can postpone.
plinss: Sounds good.
Justification and White Space
-----------------------------
Scribe: dbaron
plinss: Next topic - combining justification and white-space: pre.
fantasai: I think this is already resolved because of a decision we
made about 2.1 -- should already be in the spec.
TabAtkins: Was it put in the spec more than a month ago?
fantasai: Says in the section on 'text-align': ... reads from spec...
fantasai: Well, there's obviously a missing "not" in the sentence,
but otherwise it's there.
TabAtkins: This does work once that is changed from collapsible to
non-collapsible, which means this is fine.
http://www.w3.org/TR/css3-text/#text-align
"If an element's white space ... must ensure that tab stops continue to
line up as required by the white space processing rules."
breaking replaced elements
--------------------------
ScribeNick: TabAtkins
fantasai: I haven't triaged any css3-break issues yet, and rossen's
not on the call, so we should defer this issue until the
two of us have had a chance to look at it.
plinss: Vincent, are you okay with deferring?
vhardy_: Yep.
animation-fill-mode
-------------------
<plinss> http://lists.w3.org/Archives/Public/www-style/2012Mar/0445.html
plinss: Next, interaction of animation-fill-mode with running/completed
animations.
sylvaing: What happens if the animation-fill-mode is updated after an
animation is started or after it's completed?
sylvaing: There's some language about snapshotting the values when an
animation starts.
dbaron: I don't like the whole wording about capturing values.
sylvaing: So what do we do then?
dbaron: I think this should have an effect either way.
dbaron: You have an animation, it starts at some time, and you can
compute ...
dbaron: The things that have an effect at the time the animation starts
are duration, delay, and name.
sylvaing: So those you'd treat as if they're snapshotted.
sylvaing: So if you have a 2s delay, and after 1.5s you update it to a
3s delay, what do you do?
dbaron: I think I wrote something about this a year ago, trying to remember.
sylvaing: The snapshotting is simpler from implementation.
sylvaing: But if we don't do it, we still need something clear and predictable.
dbaron: My memory of what webkit does is that they snapshot some things,
but not as much as the spec says.
dbaron: My general issue is that anytime you snapshot, you're exposing more
details about when changes occur.
dbaron: So if you set an animation and then change a property about
animations, whether it affects the animation or not depends on how
you batch style changes.
sylvaing: So what do we do instead?
dbaron: I think what I proposed was that you compute a start time for the
animation based on when animation-name changes.
dbaron: If someone sets play-state to 'paused', while it's paused it moves
that time forward.
dbaron: But otherwise the only thing you snapshot is that start time.
smfr: So you're suggesting that authors can change iteration-count or
direction while it's running?
dbaron: Yes.
smfr: If you're halfway through a reverse iteration and you suddenly
change animation-direction, it'll jump.
sylvaing: So how does this stop detecting style batching? You're still
in control of when you apply animation-name.
smfr: Were you suggesting that duration is snapshotted as well?
dbaron: I don't think so.
TabAtkins: I think the implication there is that if you're 2s into an
animation, and you change duration to 1s, it would automatically
end and fire an animationend event.
dbaron: Maybe something like that.
sylvaing: I think the snapshotting has its downsides, but it's simple and
predictable.
dbaron: That's not what webkit did - it didn't match the snapshotting.
sylvaing: Sure, but we could consider that to be a bug.
sylvaing: Is this better for authors?
smfr: We've had feedback that people want to change animation-duration
after the animation has started.
vhardy: I also think it's better to have a live model than a snapshot -
this is the SMIL model too.
[discussion about needing testcases]
TabAtkins: Testing seems to be a red herring - we'll need it anyway.
We need to decide between snapshot everything, snapshot some,
or snapshot minimum.
sylvaing: Current impls don't quite snapshot everything.
smfr: Delay is interesting if you push it forward past the current time.
dbaron: I think Gecko snapshots delay.
dbaron: We compute a start time, and that involves delay.
plinss: To me, it makes sense to let delay change if the animation hasn't
started yet, and disallow it if it hasn't.
dbaron: And if you set the delay back before the current amount of time
delayed, start then or start as if it was delayed there the
entire time?
TabAtkins: I think the latter.
plinss: So question is snapshot some, or snapshot minimum?
sylvaing: Seems that snapshotting less seems reasonable.
vhardy_: SMIL's lack of snapshotting is convenient and solves some problems.
plinss: Seems reasonable.
sylvaing: I think we're agreed not to keep the snapshotting. Maybe some
more discussion about precise details.
RESOLVED: Change the animation model to snapshot much less properties.
Details of exactly what snapshotting is left TBD.
mismatched grid-template strings
--------------------------------
<plinss> http://lists.w3.org/Archives/Public/www-style/2012Mar/0418.html
PhilCupp: I can speak to this.
PhilCupp: What happens when strings are shorter than other?
PhilCupp: We could consider extending the last character until they're
equal length.
PhilCupp: But that can create non-rectangular grid cells.
PhilCupp: So I suggest we just pad it with empty cells.
PhilCupp: I think Bert just responded with the same suggestion.
PhilCupp: The second discussion was about non-rectangular regions.
PhilCupp: I think there was agreement that it would be useful, but we
don't want to add it to the current level of the spec.
TabAtkins: I agree with both of these.
antonp: For shorter strings, I'd prefer them to be invalid.
PhilCupp: We could do that too.
antonp: I think it's good to encourage typing out the periods when you
want empty cells, to make it more readable.
vhardy: agree with antonp
plinss: Then we could in the future decide to make mismatched string lengths
pad out the last cell, even if it's a non-rectangular region.
PhilCupp: I'm okay with that.
RESOLVED: Treat both mismatched string lengths and non-rectangular regions
as illegal syntax in Grid.
-webkit-mask
------------
glazou: The WG needs to discuss this because of the f2f discussions in paris.
glazou: I spent roughly 20 minutes today looking for sites using this in
production. It's spreading fast.
<fantasai> http://robert.ocallahan.org/2008/06/applying-svg-effects-to-html-content_04.html
glazou: I'd like to avoid the clash we had in Paris for other properties.
glazou: I heard the message from one browser vendor that the chairs didn't
jump on the properties implemented by one browser and spreading,
so let's do this.
fantasai: We had a discussion about these properties before, and our
conclusion was not to have new properties for masking and reflection,
but rather to use the existing SVG properties for this.
ChrisL: Agreed. Looking at this blog post, it seems Maciej didn't like or
understand them.
ChrisL: And we can extend this in the future.
ChrisL: Such as using one color channel in an image, or something like that.
ChrisL: So using SVG's seems to be a more workable approach and has a longer
implementation history.
glazou: There's a trend about webkit-mask today.
ChrisL: But if we do this now, SVG will have to support both of them now.
ChrisL: We've had this confusion before, and we'd like to avoid it if possible.
plinss: We do need to address this problem, but not necessarily by importing
the Webkit properites per se.
<fantasai> plinss++
vhardy: Some of the uses I saw was people using masks to fill text with a
gradient. Is that what you saw?
glazou: Most of what I saw was masks on images.
mollydotcom: Once again we see a webkit property proliferating, so I agree
with Daniel that we need to address it. Just saying "here's SVG"
won't win the day.
mollydotcom: We should sync with SVG, but the demand is already here and needs
syntax that people understand (CSS, not SVG).
<glazou> +1
<glazou> unfortunately
fantasai: The proposal isn't "Use SVG". The proposal is to take a property that
SVG already has and say "you can use it on HTML too", instead of
inventing a new property that does almost exactly the same thing.
<vhardy> fantasai++
<smfr> applying a mask should not require typing angle brackets
mollydotcom: Once the precedent is widely created, how do we turn back?
<smfr> what is the proposal?
<fantasai> http://people.mozilla.com/~roc/SVG-CSS-Effects-Draft.html
ChrisL: You don't need to point to SVG. The property lets you point to
an image.
<JohnJansen> I think this boils down to something being implemented in
webkit, but no one brings that to the WG to get it
standardized. It would be good to have a process other than
"I've heard of this new thing in webkit..." Who owns bringing
something to the WG?
<mollydotcom> thanks john for saying what I couldn't articulate
<fantasai> JohnJansen: it was brought to the WG. And the WG decided to go
with roc's approach.
<fantasai> JohnJansen: but nothing happened, so now people are panicking
<sylvaing> JohnJansen: yes, this is not a new random thing.
<JohnJansen> fantasai, sylvaing: I realize that... where is the proposal, though?
<sylvaing> John: see links posted above
<dbaron> and then there's also
http://www.w3.org/TR/2012/WD-css3-images-20120112/#element-reference
<dbaron> which we just decided to remove
<smfr> dbaron: that's certainly relevant for reflections
<dbaron> smfr, yes
<fantasai> dbaron: we didn't decide to remove it, we decided to defer it
krit: 'mask' actually needs to point to a <mask> element.
TabAtkins: And that's not cool. :/
ChrisL: We could use the same simplifying technique we used with 'filter'
to make it CSS-friendly.
plinss: In general that's okay.
plinss: So could someone propose a clean CSS syntax for this?
hober: I can write up what webkit currently does, but I'm not sure I'm the
best person to harmonize with SVG.
TabAtkins and vhardy: We can help.
glazou: And reflections?
dbaron: We had something - the element() value - that would have allowed
reflections, but we decided to defer it a few weeks ago.
Meeting closed.
Received on Wednesday, 11 April 2012 20:12:37 UTC