W3C home > Mailing lists > Public > www-style@w3.org > December 2013

[CSSWG] Minutes Telecon 2013-12-11

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 11 Dec 2013 21:45:50 -0500
Message-ID: <CADhPm3tNYbvHwPY-a=cr9am-Ru-C67uVRojYAdmgMEU6Kr1JCA@mail.gmail.com>
To: www-style@w3.org
September F2F

  - The September F2F will be 8-10 September unless there are objections
         raised soon.

Compositing and Blending

  - Cabanier will make edits regarding functionality for the group to
         review before next week's call.

CSS Masking to CR

  - Krit requested more time to go over edits he recently received.

WebVTT Review

  - ChrisL had some comments and suggestions that he will send to the
         VTT group.
  - Other members of the WG will continue to review and send comments
         later if they have them.
  - Everyone appreciated being brought into the process early on.

Will-Animate Proposal

  - Several different concerns about the proposal were raised, including
         giving too much access and how exactly it works with stacking
         and animations.
  - A summary of the current status of the proposal will be posted to
         the mailing list in order to further conversation.

Interpolate() Proposal

  - Discussion was deferred.

:Sorted Pseudoclass

 - RESOLVED: Add :sorted pseudoclass to selectors 4


  Glenn Adams
  Rossen Atanassov
  David Baron
  Bert Bos
  Rik Cabanier
  Tantek Çelik
  Dave Cramer
  Elika Etemad
  Simon Fraser
  Sylvain Galineau
  Daniel Glazman
  Dael Jackson
  Philippe Le Hégaret
  Chris Lilley
  Peter Linss
  Anton Prowse
  Florian Rivoal
  Simon Sapin
  Dirk Schultz
  Alan Stearns
  Steve Zilles

  Tab Atkins
  Mihain Balan
  Brad Kemper
  Kang-Hao (Kenny) Lu
  Simon Pieters
  Leif Arne Storset
  Lea Verou

scribenick: dael

  plinss Let's get started
  plinss: Any additional items?
  sylvaing: Please put your name for registration for the January F2F.
  sylvaing: It's especially important because we need to issue badges so
            you can get in.
  sylvaing: The earlier a complete count is available the better.
  * plh plans to come
  * ChrisL will be there and has planes booked
  plinss: This is a good time to make travel arrangements.

September F2F

  SteveZ: I believe the AB meeting is the 16-17th Sept
  SteveZ: I think Bert was offering to host.
  SteveZ: Optimally if it was near those dates I would only need one
          trip to Europe.

  krit: I would prefer after.
  glazou: Me too.

  plinss: Any other preferences?
  sylvaing: With TPAC afterwards, it was inconvenient that summer,
            autumn, and winter meetings were close together.
  <Bert> (TPAC is Oct 27-31)
  plinss: That is true.
  plinss: The week of the 22nd would be 4 weeks before
  krit: If we did the week before that would be okay.
  SteveZ: That's fine with me.

  plinss: Bert, are any these dates a problem?
  Krit: TPAC is on Halloween so it must be in October.

  plinss: So do the week of 8-10 September?
  plinss: That work for everyone?

  ChrisL: That's fine for me.
  florian: If we move further from TPAC it's better.

  plinss: Okay, unless we hear other complaints soon, let's call it
          September 8-10.

Compositing and Blending

  cabanier: I got comments from James Robinson,
  cabanier: He's asking for something that doesn't require spec changes,
  cabanier: Should I wait another week to ask for CR?
  cabanier: Or does that not stop it?

  ChrisL: It's obviously a judgement call.
  ChrisL: If it's ongoing and going to produce significant changes you
          should wait,
  ChrisL: If not you can push it to later.

  cabanier: He's asking for clarification on something in the spec.
  ChrisL: It's just a clarification you're fine.
  cabanier: Should I put it in disposition of comments?
  ChrisL: Yes.

  ChrisL: Is there something we can look at?
  cabanier: Yes, I'll paste in IRC.
  <cabanier> doc: http://dev.w3.org/fxtf/compositing-1/issues-lc-2013.html

  ChrisL: One comment, introduce some classes there with colors,
  ChrisL: So someone can see green with agreement etc. That makes it
  ChrisL: You should distinguish between where everyone agreed and
          everyone talked about it and the person is happy even if they
          didn't get want they wanted.
  cabanier: Okay.

  <fantasai> http://dev.w3.org/csswg/css-flexbox/issues-cr-2012
  <fantasai> http://dev.w3.org/csswg/bin/issuegen.pl
  fantasai: First link above is an example of a color coded one.
  fantasai: And the 2nd is a template to generate from text.
  cabanier: That's handy.
  fantasai: If you do this it spits out instructions and it'll create
            the HTML.
  fantasai: There's others you can use, this is the one I wrote.
  cabanier: I was surprised when Cameron told me I had to register.
  cabanier: I'll update.

  <dbaron> I'm a little concerned about the number of parts of the spec
           marked non-normative.

  cabanier: Should I wait for CR is it it fine?
  plinss: As long as it's updated for the spec. call I think it's okay.
  cabanier: The comments from James will be in there.

  smfr: I find the spec confusing because it has a lot but doesn't
         provide new properties.
  smfr: For example it has a section on knockout groups, but it doesn't
        have examples.
  smfr: It's very confusing because it has a long section on theory and
        I don't know why it's relevant.
  cabanier: It has a lot of normative text.
  <dbaron> There are a bunch of references to a 'knockout' keyword
           that's no longer in the draft.

  smfr: I think technical information is fine, they just want to know if
        they can use it now, use it later, what's being developed.
  smfr: It's explaining what it's for.
  smfr: Does this need knockout groups?
  smfr: There isn't an SVG for this, right?
  cabanier: I don't think anyone implemented that.
  smfr: This looks theoretical.
  smfr: I think it should stay.

  dbaron: I don't think so. I think there's a bunch of references to
          something that as there before.

  smfr: Is that for level 2?
  smfr: Knockout we've tried for some time, but if it's to level 2
        that's okay.

  sgalineau: I think there's two options. 1: We remove knockout. 2: We
             make clear which isn't covered.
  cabanier: I think we can remove things not covered. I think it can be
            done in CR.
  cabanier: That second section is informative about how it could work.

  smfr: We're removing things not covered so it's confusing,
  smfr: And having a long normative section is dangerous.

  dbaron: I think it's not clear what's non-normative.
  dbaron: Does this section mean what is non normative. Like is 5
          non-normative, but 5.1 isn't?
  cabanier: I should be in the header.
  sgalineau: It should be an appendix.

  dbaron: To be clear sections 5, 6, 7, 8, 9, and 10 are marked as
  dbaron: Does that mean sections 5, 6, 7, 8, 9, 10 don't define
          anything but property syntax?
  cabanier: We discussed this and at the time only properties were
            supposed to be marked as non-normative.
  dbaron: Who told you that?
  cabanier: I don't remember. I can look.

  plinss: Unless there's a good reason, that's the sort of thing that
          should be normative.
  plinss: You shouldn't have someone implement a blend mode and get
          different results.

  smfr: It sounds like that should change in the spec. It's important.
  * sgalineau thinks the backgrounder should be an appendix.

  plinss: Are we in agreement those sections should be normative?
  ???: We should make it normative in a later version.
  plinss: I think we agreed earlier that items not referenced should
          move to the next level.
  plinss: We should shift text from not normative to normative before
  plinss: Do we want to see these changes and then revisit going to CR
          or resolve now and see it later
  smfr: I think it was clear, but some people found it confusing so
        should we wait to see if this makes it less confusing?
  ???: This is something we're going to remove is CR, so why not do it
  cabanier: We can do it next week.
  ???: Otherwise it looks like we're removing for no reason.
  cabanier: I wanted to be less confusing in LC. I think I'll make the
            changes and discuss next week.
  plinss: Agreed. The only problem is editing functionality.
  ???: We're not changing any behavior.
  plinss: So you have your orders for changes and we'll revisit next

CSS Masking to CR

  krit: I got comments a few hours ago.
  krit: I got fantasai's comments.
  krit: Her comments will delay CR, so I'd like to discuss on the
        mailing list,
  krit: Since her requests are changing behavior and names.
  plinss: So you want that before CR?
  krit: Yes.
  plinss: Let us know when you want to revisit.

WebVTT Review

  plinss: Everyone should have reviewed for feedback.
  Bert: I promised to review
  ChrisL: I have some comments, Bert can go first.

  plinss: I heard one person ask for time and one person had feedback.
  ChrisL: I had a little.
  ChrisL: WebVTT specifies certain properties must be set to particular
  ChrisL: And lists the properties that must apply (the others must be
  ChrisL: Is it correct that there is no DOM interface to get at the
          styling information, so the only way to see what properties
          are applied is if
  ChrisL: They have a particular visual effect?

  plinss: Do you have a suggestion for a better way to phrase that?
  ChrisL: I think I'm looking for a change in words.
  ChrisL: Saying you can't do these things is odd.
  ChrisL: It's better to say should not instead of must not.
  ChrisL: If you say must not you have to test and there's no way to do

  plinss: Okay, any other feedback?
  plinss: I hear folks need more time to review.
  israelh: I could do with more time for reading it.

  ChrisL: I have a follow-up.
  ChrisL: If we want tests for this, currently we can do SVG and HTML
          tests, can we integrate WebVTT?
  plinss: I don't understand how it would be significantly different.
  ChrisL: I was asking you.
  plinss: I think it's fine
  <ChrisL> ok cool

  israelh: Would you be able to share the location again in IRC?
  <ChrisL> https://dvcs.w3.org/hg/text-tracks/raw-file/default/webvtt/Overview.html

  glenn: Just as a note, VTT is a community group and hasn't entered
         into W3C rec track.
  glenn: It also doesn't have a status which is required before rec
  glenn: Current plan to to take it through the timed text WG.
  glenn: I wanted to mention that comments might be a bit premature.
  ChrisL: I understood, but I think it's good they asked for feedback
  ChrisL: I think they should be commended for asking early.
  plinss: Agreed.

  plinss: I'm not hearing anything else, but that concerns me.
  plinss: Do people need more time or are they okay?
  SteveZ: I think where they are would allow us to add more comments as
          we find them.
  plinss: I just want to make sure it happens.

  plinss: Only question is, all we have is Chris's comments. Do you want
          to send that yourself?
  ChrisL: Yes. I think it would be good to have something from the
          chairs saying there we discussed and there may be more
          comments later. Tell them they're good for asking.
  plinss: Yes.

Will-Animate Proposal

  plinss: Anyone want to speak about it?

  smfr: I can summarize.
  smfr: As far as I can understand, it will allow authors to say later
        they'll change something with an animation.
  smfr: This is a trigger to allow the user agent to prepare for an
        animation to start.
  smfr: The engine may create something ahead to allow it to work more
  smfr: This is exposing implementation detail and may change in future
        to make this unnecessary or confusing.
  smfr: I'm not a big fan and I think this could be mis-used to force UI
        to allocate too much memory.

  dbaron: There were some design details to avoid exposing too much
  dbaron: That said, one of the problems is there are a bunch of
          properties where everything by default causes stacking.
  dbaron: There's a desire for will-animate to cause that even without a
          new value.

  SimonSapin: I want to clarify that this proposal works with stacking
  smfr: Right, and authors can create stacking now.
  smfr: I don't see the need for will-animate to do that.
  smfr: Is the desire so that later on you create less work for the UI
        to do?
  dbaron: Yes.
  SimonSapin: This proposal creates stacking contexts, so it's not just
              about performance but also affects behavior.

  smfr: In webkit creating a stacking context isn't a lot of work.
  dbaron: The work is around creating layerizing. When it's not stacking
          it has to layerize differently.
  smfr: I think that's different between UIs.
  dbaron: I don't think it is. I think it has to do things in a way that
          makes it inherently more expensive.

  plinss: I also have a lot of concerns for similar reasons.
  plinss: It's the wrong place for optimization.
  plinss: What concerns me is adding the stacking. It may be useful
          because you don't want layering to change with animation, but
          I'm not seeing that happening.

  dbaron: I think it's worth talking about why we want this.
  dbaron: There are cases an author knows they want to animate,
  dbaron: For example touch interface.
  dbaron: When the user touches they know it'll move,
  dbaron: It's important that the response is instant.
  dbaron: When we're talking about trying to do touch UI on mobile
  dbaron: The cost of painting into a layer when it wasn't before is
  dbaron: And the cost of optimistically using lots of layers is
  dbaron: This is a hint.
  dbaron: Other then the change in stacking, it doesn't have normative
  dbaron: We haven't been able to get UI with touch to be responsive
          without this.
  dbaron: We need some way to address it and this is the least-bad so

  plinss: My concern is that this is changing behavior, even though you
          say it's a hint.
  dbaron: That's the problem we wanted a hint and this is what we had to
  dbaron: Authors are doing worse things right now.
  dbaron: They set translate in advance.
  dbaron: I think having something more explicite is better then
          widespread use of hints.
  dbaron: Such as things are faster in webkit if you stick translate Z,
  dbaron: That's the world we're in.

  florian: Should we create something meant to be a hint, or should we
           create a property that's also useful?
  ChrisL: That seems better to me.
  dbaron: That does create a hint, but it creates separate ways for
          spec. properties

  plinss: I do agree that is the desire is to create stacking context a
          property is better.
  dbaron: The desire isn't to create stacking context, the desire is
          animate to preferences better.

  smfr: I'm agreeing with dbaron.
  smfr: I also think that just creating stacking isn't enough for us to
        effectively run an animation without a hiccup.
  dbaron: It's not enough, but it's a good side effect.
  smfr: I think that's fine.

  plinss: Does it always create stacking, or only with some properties?
  dbaron: I don't know.
  plinss: I'd like to see stacking be a modification of another property
          and see if it needs to be explicit.
  plinss: I'd like to get rid of the hacks.

  dbaron: I think requirements; it's two properties making people set
          two properties.
  Rossen: On the other hand, with everything that's stacking today you'd
          be giving the illusion that you'll be able to put everything
          in context with a separate property.

  Florian: So everything that creates a stacking context with auto means
           that auto just is computed as force.
  Florian: You could do that without an opportunity for turning it off.

  Rossen: Like Simon pointed out, we're trying to find something
          animatable in it's proper context.
  Rossen: I particularly favor a separate property instead of stacking.

  plinss: My other question is, isn't there some way to look ahead
          through existing style and guess.
  plinss: If the issue is we're looking for something in Javascript it's
          an API not a property.

  Rossen: The animation is run through CSS not API.
  Florian: That's odd. If it's in CSS we should figure it out.
  Florian: If it's because there's Javascript in the middle we should
           address that.
  smfr: If you're using CSS we should fix it.

  dbaron: The other problem is that if authors want to rely on this they
          want to know heuristics.
  dbaron: I think it's good to give authors reliability in what
          performance they can expect,
  dbaron: And not say it's undefined.
  florian: It still feels like this is close to a property,
  florian: That says do what I say, but faster.
  * sgalineau agrees that if the impact of this property is unclear or
              varies across browsers its usefulness is questionable.
  smfr: It's saying prepare yourself for a future CSS property change.

  Rossen_: Does anyone know if web animations spec is trying to address
  smfr: I don't think so.

  smfr: I'm happy for this to continue, if someone on mailing list
        summarizes current proposal state.

  plinss: Can someone write up summary?
  plinss: And post it to the mailing list?
  dbaron: I can poke someone and see if they can.
  plinss: Then discussion will continue on the mailing list.

interpolate() proposal

  plinss: Leaverou had a proposal.
  <glazou> She is not here.
  plinss: None of the parties are here. Should we defer?

:Sorted Pseudoclass

  plinss: This was from Tab and I think we can discuss here.
  plinss: The proposal is to add a psudeoclass adding HTML sorting
  plinss: Anyone have thoughts?

  <tantek> would this also apply to <ol reversed> ?

  glazou: I made a comment on mailing list because I think the current
          proposal is not enough.
  glazou: It doesn't deal with columns that you don't sort,
  glazou: If you have a list of items with an index and you want that
          index to remain ordered, it won't deal with that.
  glazou: I think it's a good start to match HTML5 and we need to extend
          to be complete.
  glazou: It's something web authors are doing more and more. We need a
          way to present to the viewer.
  <sgalineau> Doesn't understand; if you leave your table as-is then it
              can't be re-sorted, right?

  plinss: My question is that we need to extend sorting model of HTML,
          not CSS.
  plinss: Are you saying CSS should override the display of the table?
  glazou: The columns sorted with select a column if it's sorted in
          another place.
  glazou: We can't select if it's not sorted.
  plinss: Wouldn't that be column-not sorted?
  <tantek> :sorted does not alter the sorting of the table/column/list
  <plinss> :not(:sorted)
  glazou: That's not possible.
  glazou: It's a bit verbose.
  plinss: The proposal was just about if it's sorted or not.

  glazou: I had another comment about the argument that is for
          determining only in index.
  glazou: We may want a way to extend to range.
  glazou: If you sort on multiple columns you may want to sort all
          without selecting the individual.

  glazou: Other then that I think we should continue. It's needed work.

  plinss: Any objections to adding this to selectors 4?

  bert: You would want to know if the table is sorted.
  bert: You can do that with subject selector, but may be easier to have
        pseudo on the whole table.

  tantek: The only comment is I had was should that apply to ordered
          lists too, other then normally ordered?
  plinss: That's an interesting point. I don't see why not.

  RESOLVED: Add :sorted to selectors 4

  Action: glazou add :sorted to selectors 4
  * trackbot is creating a new ACTION.
  * RRSAgent records action 4
  <trackbot> Created ACTION-602 - Add :sorted to selectors 4 [on Daniel
             Glazman - due 2013-12-18].

[End of Meeting]
Received on Thursday, 12 December 2013 02:46:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:37 UTC