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

[CSSWG] Minutes and Resolutions Telecon 2012-04-11

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 11 Apr 2012 13:12:04 -0700
Message-ID: <4F85E594.6000207@inkedblade.net>
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 GMT

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