W3C home > Mailing lists > Public > www-style@w3.org > July 2014

[CSSWG] Minutes Telecon 2014-07-16

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 16 Jul 2014 17:47:09 -0400
Message-ID: <CADhPm3vXNPXkYAVuc5rxLca80CRAmL5mepL7gAG7MzzOC1G5Ww@mail.gmail.com>
To: www-style@w3.org
Errata for Canvas Background
----------------------------

  - Bert brought the proposed errata text he wrote to the group.
  - He was given two edits to make in order to make the errata more
       accurately reflect the group's thinking.
  - fantasai will update the test suite to reflect the change.

Error handling rules in grid layout
-----------------------------------

  - RESOLVED: Accept proposal (available here:
       http://lists.w3.org/Archives/Public/www-style/2014Jul/0074.html)

Transforms Shorthand
--------------------

  - TabAtkins updated the group on where his thinking has evolved to
       after discussions on the very active thread.
  - TabAtkins will re-write a new proposal and send it to the list
       for further review.

CSS Color Classes
-----------------

  - TabAtkins addressed the changes he's made since he presented his
       ideas from the wiki last week.
  - Leaverou had some concerns about his attempt to address the
       various types of color syntax and will write up her concerns
       and post them on the mailing list.
  - The plan to remove the RGBcolor name from DOM Level 2 ran into
       some objections and will be addressed in the thread.

Animations Issues
-----------------

  - RESOLVED: Defer new timing keywords for bounce animations to
       level 2
  - RESOLVED: Defer a new steps() timing function to level 2
  - RESOLVED: Begin work on Level 2 of Animations
  - RESOLVED: Accept the edit proposed in this e-mail:
       http://lists.w3.org/Archives/Public/www-style/2013Jan/0054.html
  - RESOLVED: Inserting an @keyframe rule if it wasn't there starts
       an animation.

===== FULL MINUTES BELOW ======

Present:
  Glenn Adams
  Rossen Atanassov
  Tab Atkins
  David Baron
  Bert Bos
  Adenilson Cavalcanti
  Dave Cramer
  Alex Critchfield
  Bruno de Oliveira Abinader
  Elika Etemad
  Sylvain Galineau
  Brad Kemper
  Dael Jackson
  Peter Linss
  Liam Quin
  Matt Rakow
  Florian Rivoal
  Simon Sapin
  Dirk Schulz
  Lea Verou
  Greg Whitworth
  Steve Zilles

Regrets:
  Chris Lilley
  Mike Miller
  Anton Prowse

  Scribe: dael

Errata for Canvas Background
----------------------------

  <Bert> http://lists.w3.org/Archives/Public/www-style/2014Jul/0289.html
  plinss: Let's get started.
  plinss: Anything to add to the agenda?
  Bert: Maybe check the text of the errata that we created last
        week? If we can't agree in two minutes we can postpone to
        another time.
  Bert: That's (link above) my response to SimonSapin's message.
  Bert: So shall I explain now?

  Bert: We decided that the background of the canvas would not be
        taken from the root or body if they have display: none. If
        they have visibility: hidden everything is normal
  Bert: SimonSapin was writing the text originally, but here's the
        text I came up with. I proposed to add two sentences [reads
        proposal]

  SimonSapin: When you said undefined, does it mean the spec
              doesn't define or it's not in the background?
  Bert: I don't think we defined...

  Bert: SimonSapin question was what does "background undefined"
        mean?
  Bert: I didn't find any rule in the spec that says what the
        canvas background is other than taking it from the root
        element.
  fantasai: I think we say it's transparent and that means it's
            whatever it'll be if everything is transparent. It's
            treated as background transparent.

  dbaron: Wasn't the point of the agreement last call that when
          it's display: none normal rules apply?
  fantasai: What?
  dbaron: I thought this errata is backwards.
  fantasai: I think if there is not a root element box, then
            background position is undefined, so we made a root
            element that's display: none propagates transparent up.
  dbaron: Didn't we say all browsers show background in that case?
  fantasai: I thought they said it doesn't.
  MaRakow: It's split. In IE if body is none we paint.
  fantasai: You paint with visibility: hidden.
  MaRakow: That could be right.

  fantasai: There's 2 options. You propagate transparent up because
            the box isn't there, or we use the initial containing
            block. Most implementations use the first option. This
            is a really weird case.
  dbaron: Okay.

  Bert: So I should make a next version of the text that says
        canvas background is transparent rather than undefined?
  fantasai: Yes.
  fantasai: With display: none on the body, when we propagate do we
            use the body's dimensions to set the positioning? I
            don't think so.
  Bert: It says it's positioned as per the root element. It's
        strange, but you don't use the body, use the root.
  fantasai: In that case, it's defined to say you propagated up
            even if it's display: none. I don't know what
            implementations do.
  Bert: I don't think the proposal is if there's display: none.
  fantasai: I would word it as :if no box is generated in the
            render tree such as in the case of display: none" since
            there may be other ways to make something not create a
            box.
  Bert: I can see your point.
  dbaron: I think if it's not propagated from a root element that's
          display: none, it should also not be for a body that's
          display: none
  fantasai: That's fine.

  Rossen: If you work to remove body in HTML, what would you
          propose for that? Would that me the same?
  SimonSapin: I think the same.
  Rossen: That's more the case that's likely to happen.
  fantasai: If you remove an element from the render tree, it
            renders like it was never there.
  Rossen: So you should display the same way.
  fantasai: So if you render with no elements, okay.
  Rossen: I could have a div.
  fantasai: We don't special case HTML. We special case the root,
            and we special case a <body> child of the root.
  Rossen: So. If I remove body in HTML and inject a span with a
          pink background that's supposed to propagate up, I don't
          think that works right now.
  dbaron: I would think that works.
  Rossen: I was playing with something like that and thought there
          was interop, but I might be wrong.

  plinss: So do we have concrete text?
  Bert: I should re-write after what I've heard.

  fantasai: Rossen, that has to work because you can't otherwise
            have a canvas background on arbitrary documents.
  Rossen: I tried it with that special case with the inline element
          and the root.

  SimonSapin: I think Bert's proposal is fine with "undefined"
             replaced by transparent.
  fantasai: I also want to make the change about not having the box.
  Bert: Let me try it again with those changes.
  Rossen: But not having a box doesn't mean you can't get
          propagation. Why would it be the same as no element?
  fantasai: We need a box to position the images inside.
  plinss: Okay?
  Rossen: Umm...okay.
  plinss: So Bert will come back with new text next week.

  dbaron: Is someone willing to take an action to fix the test in
          the test suite?
  <dbaron> http://test.csswg.org/suites/css2.1/20101027/html4/root-box-003.htm
  dbaron: Maybe we dropped it, I have a link [above] but it may be
          broken.

  * trackbot is creating a new ACTION.
  <trackbot> Created ACTION-634 - Address the text suite [on Elika
          Etemad - due 2014-07-23].

Error handling rules in grid layout
-----------------------------------

  Rossen: We're fine with fantasai and TabAtkins' proposal.
  plinss: Okay.
  plinss: Other opinions? Objections?

  RESOLVED: Accept proposal (available here:
         http://lists.w3.org/Archives/Public/www-style/2014Jul/0074.html)

Transforms Shorthand
--------------------

  TabAtkins: The proposal has evolved from the e-mail. It's more
            similar to what Shane proposed with shmanslation,
            shmale, and smotation. These behave how you would
            expect in real life.
  TabAtkins: If you have a translate involved it's applied after
            the fact. If we name it appropriately to look like
            translate, it behaves in a way that behaves according
            to the author's mental models.
  TabAtkins: It also lets us independently animate translate and
             rotate and the like.
  TabAtkins: We can also maybe later get additive to work, but for
             now this proposal gets transforms it to work in the
             intuitive way.
  TabAtkins: Final proposed grammar isn't written exactly, but I
             accepted krit's proposal to build in origin directly
             to match SVG. So, add the 3 proposal.
  <dbaron> It would be nice to see the proposal that's on the table
           and be able to discuss on the list.
  <astearns> +1 dbaron - I'd like a new thread with the full
            proposal detailed.
  <fantasai> +1 to dbaron from me, too
  <sgalineau> +1 astearns, dbaron.

  smfr: Is this proposal to make the properties independent instead
        of multiplying?
  TabAtkins: Those are the same.
  smfr: There's magic from krit that confused me.
  TabAtkins: I think anyone that is familiar with this is getting
             lost because these are treated independent and
             separate. You can implement them by turning them into
             separate things.
  smfr: So you can't do a rotate then translate and a translate
        then rotate and get the same thing.
  <astearns> they are independent *only if* you specify that
             schmscale operates in the rotated coordinate result of
             the schmrotate.
  TabAtkins: Ignore your previous knowledge. Scaling from an origin
             gets the same thing.
  smfr: You have a translate and a rotate?
  smfr: The implicit ordering?
  TabAtkins: That ordering makes them look not connected.
  smfr: Span needs to say they're in an order. In implementation
        terms they're not independent. Users expect independent.
  TabAtkins: It's not just for simplicity. If users use one thing
             they want it to work. If they're trying to use more
             then one, they function separately. This will be you
             translate an element, you rotate an element, you scale
             and element and these are separate.

  <leaverou> Like I said on the list, strong +1 to Tab’s proposal
  <dbaron> leaverou, which of tab's proposals?
  <sgalineau> There is more than one proposal variant so not sure
              what Lea says +1 to :)

  fantasai: I think this property needs to be written fully and the
            shorthand property in it's entirety should be there so
            we can compare.
  <sgalineau> fantasai +1
  <MaRakow> +1 to writing it up, I'm confused.
  TabAtkins: Their feedback isn't relevant anymore because it's in
             the current proposal. The shorthanding proposal doesn't
             work that well.
  <astearns> I vote to kill the shorthand proposal preemptively
  TabAtkins: I've disavowed the original.
  fantasai: Write it up and start a new thread. The thread is in
            lots of sub threads.
  TabAtkins: It's all getting people to understand it's not
             transforms.
  fantasai: So get a new clean proposal.
  TabAtkins: That's fine with me.
  fantasai: Okay. And then we can discuss next week.
  <SimonSapin> thanks fantasai :)

  plinss: dbaron you were trying to make a point?
  dbaron: I was trying to say it's no where ready to discuss. This
          is a massive thread with lots of proposals and we need to
          know what we're talking about.
  <leaverou> dbaron: Mainly, I just think the problem needs to be
             addressed. I haven't made up an opinion on the
             specifics to be honest.
  TabAtkins: Yes. I can pull mine into a separate thread.
  fantasai: After you draw up your proposal, address the other
            options and explain why they're not being considered
            anymore.
  TabAtkins: I think that could be confusing because it will draw in
             concepts that don't need to be considered. I'll draw
             something up, we don't need more call time.

CSS Color Classes
-----------------

  TabAtkins: So last week we accepted color classes. I wrote the
             proposal up and wanted to get review. The proposal
             evolved a bit from the wiki. leaverou pointed out that
             people might want to manipulate in the color space.
             Such as they might want to tweek the hue a bit and with
             my previous version that was hard. I separated it into
             different color classes, one for each syntax.
  TabAtkins: They interop well and I've gone to some effort to make
             sure it's easy to extend for authors.
  TabAtkins: If they want a new color class it's pretty easy to do
             and there's guidance in the spec for how to do that.
  TabAtkins: So I wanted review.

  <leaverou> Where is the updated proposal? I can only see the
             original one in http://wiki.csswg.org/ideas/color-object
  * plinss leaverou: http://dev.w3.org/csswg/css-color/#apis
  * leaverou thanks plinss!

  TabAtkins: Final bit is naming. Names are all short and easy to
             work with.
  TabAtkins: Hopefully they're fine, but may clash with author names.
             I think that's fine. I think if they clash they'll over-
             write. It'll be hard to mix old and new text, but
             legacy sites will be fine.
  TabAtkins: RGBcolors clashes with a DOM Level 2 Style Class. That
             clashes with us and webkit. I've been advocating for us
             to drop it if possible. I explained the difficulties in
             the e-mail.
  TabAtkins: I don't think the name will be a problem. I think if
             you didn't implement DOM Level 2, that's fine. If you
             did you can change instance of RGBcolor that to
             something dumb and phase it out.
  TabAtkins: I think we need a resolution for that.
  <dbaron> I think we already agreed to deprecate (or worse) those
           interfaces
  <leaverou> I still don't understand why we need separate classes
             for color models that are just a transformation of RGB.

  krit: RGBcolor is DOM 2, but it's CSS2 primitive. Does Firefox and
        Blink expose?
  TabAtkins: I think we do. It's easy to obtain an RGB color value
             object assuming it's and RGB or Hex color
  TabAtkins: You can do an RGBcolor in Blink. However, usage is
             minuscule.
  <dbaron> Firefox does have the RGBColor interface -- it's only
           exposed for computed style, though

  leaverou: I don't understand why we need separate classes for
            color models. Why can't we modify the hue?
  TabAtkins: RGB colors don't have hues.
  TabAtkins: If you try and expose the union of all possible
             properties, you have clashes. Hex and % don't work
             together. HSL and RGB have no conflicts, but if we do
             something like HWB, the B conflicts. B is Black and B
             is Blue. We can expand into the word, but that's less
             good.
  leaverou: So for example if you have RGB and you parse another
            color in and want to modify the hue with HSL, do you
            have to keep converting between the two...
  TabAtkins: Why would you convert just for the purpose of hue?
  leaverou: You might have RGB and want to change hue, but want to
            remain in RGB. It's the same color space, but a
            different way to refer.
  TabAtkins: You have to adjust anyway. The conversion incurs a bit
             more cost, but it's not huge.
  TabAtkins: Once you're adjusting hue, you just want to use HSL
  leaverou: Wouldn't it be more convenient if you can adjust hue in
            same color class without conversion?
  <MaRakow> +1 to leaverou
  TabAtkins: I'm not sure it's worth union-ing. We end up with
             namespace issues.
  TabAtkins: It makes what you're doing less clear.

  fantasai: I think you just call it red, green, and blue
  TabAtkins: But people are used to RGB. I think JS exposes them as
             RGB.
  MaRakow: Maybe just white and black?
  TabAtkins: But then you have H, White, and Black
  leaverou: HWB is just whiteness and blackness.
  TabAtkins: B clashes with Blue.
  TabAtkins: I don't want to use full name, because saturation and
             lightness aren't short. They're not easy to type.
  TabAtkins: If we're abbreviating one, we should abbreviating all
             since they're well established.
  <bradk> I wouldn't mind using .blue and .black instead of .b
  <bradk> .brightness is probably more clear than hsb.b anyway.
  <fantasai> bradk, agreed...

  leaverou: But if you're typing the whole word, isn't it easier.
  TabAtkins: It is easy to use.
  leaverou: But you seem to think if you want to modify saturation
            or hue, you don't want to do it in RGB. You seem to
            think you should convert.
  TabAtkins: So you think people would want to first adjust the
             color and then the saturation?
  TabAtkins: You wouldn't want just an RGB?
  leaverou: I'm saying they're all a the way of presenting the same
            data so I don't know why we're not making them the same
            model.
  TabAtkins: I understand and agree, but I object due to practical
             considerations.
  fantasai: I think leaverou should write up an alternate proposal
            and submit it as a reply to your proposal. I think
            leaverou has a bunch of valid concerns and we're not
            getting anywhere.

  TabAtkins: So we still need to address the RGBcolor naming issue.
  fantasai: We can do a different name. Let's poll at another point.
  TabAtkins: I'm saying are we okay changing a deprecated
             interface's name.
  plinss: Other opinions?
  * fantasai defers to dbaron.
  TabAtkins: Any objection to changing the DOM level 2 name?
  <dbaron> I think the objections would come from web content that
           breaks rather than from people who don't like it.
  <glenn> yes, i object to changing name of RGBColor interface
  <fantasai> dbaron, I kindof see you as a representative of
             sensibleness wrt breaking web content :)

  smfr: This seems like a slippery slope to exposing more in JS. Is
        that something we want to do? I know color is special, but
        is this worth it for just colors?
  <leaverou> I think ultimately exposing all CSS values to JS would
             be valuable, but there is a more pressing need for some
             (e.g. colors) than others.
  TabAtkins: I'm not sure. We could expose a bit more, but we don't
             want to go too far. All this could be exposed by a
             better OM that I proposed in January. All this is
             backfill and we'll expose everything in several years.
             We can avoid most of the pressure, but colors are
             really common.
  TabAtkins: Lots of people write color classes and it's common
             enough that it's worth exposing. There may be some
             others like maybe parsing links. Maybe gradient, that's
             an edge case. I think we can maintain a high bar of
             what to expose so we don't write alternate OM for all
             of CSS that we replace in a few years.
  TabAtkins: Right now color is all I'm interested in.

  fantasai: I think we can write pieces we're interested in now and
            integrate them in 6 months.
  fantasai: That's in a timescale that we can adjust the bits we're
            designing now to fit in better with other things.
  TabAtkins: Ultimately what we do will be incompatible with the
             entire OM property. It can look similar, but not be the
             same.

  plinss: So going back to the class name, so at some point we need
          to embrace JS modules. So, if we have a naming conflict,
          this might be the time.
  TabAtkins: We haven't implemented this just yet.
  plinss: No one has implemented this yet either. It's a dependency
          issue.
  TabAtkins: I don't know how soon we'll want to do modules. We will
             eventually need to to go into the web IDL.
  glenn: I do object to changing the name of RGBcolor.
  TabAtkins: Why?
  glenn: It's implemented and deployed.
  TabAtkins: And on it's way out.
  glenn: When it's gone we can revisit, but until then I object.
  TabAtkins: Okay. We can address in the thread.
  TabAtkins: We can move on.

Animations Issues
-----------------

  sylvaing: So there's a bunch of stuff. A few feature requests.

  <sgalineau> http://lists.w3.org/Archives/Public/www-style/2013Jun/0376.html
  sylvaing: Someone was asking about a new animation timing keyword
            for bouncing effects. I think for level 1 we should
            defer unless there's a strong opinion.
  <smfr> defer
  TabAtkins: On deferring it?
  sylvaing: Yes.
  TabAtkins: Yeah, I think that's fine.
  sylvaing: So any objections?

  RESOLVED: Defer new timing keywords for bounce animations to
            level 2

  <sgalineau> http://lists.w3.org/Archives/Public/www-style/2012Dec/0282.html
  sylvaing: Next issue is also a proposed feature that I think we
            should defer.
  sylvaing: This one is interesting because it's about timing. You
            can see in the example if you ask for a 3 step
            animation, the last step may not be visible because you
            go forward. They overshoot the animation.
  sylvaing: TabAtkins proposed some syntactic sugar. I agree with
            someone that said the name isn't clear. It does address
            the problem. There is definitely a problem, I'm not sure
            this is the solution. I think this is level 2
  <leaverou> +1 for step-mid, I’ve ran into this issue a few times
             as well. One of them was actually yesterday!
  TabAtkins: I'm fine with level 2. I'm assuming that'll happen at
             some point. A different possible name is segment
             function.

  krit: I think at the Paris F2F we resolved...at a key time this
        should already be...let me open an image.
  <krit> http://www.w3.org/TR/SVG/images/cumulative-transform-graph-1.png
  krit: Maybe this is something different. This image you can see
        each step sets a new frame. The next step is the new frame.
        In your example it seems the 6 second frame should appear.
  TabAtkins: If you're not doing a fill-forward and just taking an
             element that should go from 0 to 60 over 6 seconds and
             goes away, the current behavior makes it jump past 0 or
             makes it go away right at 60. So you'd have to
             overshoot to 80 to make the 60 appear. If you're doing
             fill-forward, you're fine.
  sylvaing: There are ways to do it, but the default doesn't get you
            what you want.
  TabAtkins: It's all achievable, but to do it it's slightly hacky.

  sylvaing: So any objection to moving this to level 2?
  sylvaing: Then maybe we can see if there's obj to starting level 2
  TabAtkins: I think we should start level 2. Usual practice is to
             have level 2 only as a diff spec that only maintains
             the changes.
  <dbaron> yeah, a diff spec for level 2 sounds fine

  plinss: So, backing up. Objections to deferring to Level 2?

  RESOLVED: Defer a new steps() timing function to level 2

  plinss: So any objections to starting level 2?
  sylvaing: I can start on it. Level 1 gets priority.
  fantasai: We can also do a wiki to collect things. Maybe start
            with a wiki and then once you have time to spec, do that.
  plinss: Is that a resource issue, or are you objecting?
  fantasai: I'm not objecting. I'm just offering a quick way to
            sketch.

  RESOLVED: Begin work on Level 2 of Animations

  <sgalineau> http://lists.w3.org/Archives/Public/www-style/2013Jan/0054.html
  sylvaing: This one is minor. It's a comment from dbaron about
            ambiguities when you repeat animations. I propose to
            just accept the edit. I think that's obvious, but want
            to make sure.
  sylvaing: So I'll let people read.
  plinss: Everyone fine with the edit?
  plinss: I'm assuming you're okay with it?
  sylvaing: I'm okay with it. In this case the 3 sec animation takes
            over.

  RESOLVED: Accept the edit proposed in this e-mail:
            http://lists.w3.org/Archives/Public/www-style/2013Jan/0054.html

  <sgalineau> http://lists.w3.org/Archives/Public/www-style/2013Oct/0248.html
  sylvaing: Next one is more interesting. It popped up a few times
            and Brian mentioned it recently. I started editing
            already. It has to do with a start time of an animation
            when you start an animation and there's no @keyframe yet.
            So do you start when you have the keyframe or a
            different time. I think it's when you have both the
            animation property and the keyframe.
  sylvaing: I think you start from the beginning when you have both.
  sylvaing: I think in some implementation if you insert the
            keyframe later it didn't start.
  sylvaing: So if you start animation with foo 0sec and have a
            keyframe at 10sec it starts.

  smfr: So does the snapshotting rule come into play and you have an
        animation with no keyframe?
  sylvaing: So you're asking if an animation has run and then you
            mess with keyframes do you start at the beginning?
  smfr: When you define as a set of keyframes, is it just the
        @keyframes block rule, or do they have to be valid keyframes
        within?
  sylvaing: I think to start you need animations and a matching
            @keyframe
  smfr: So empty @keyframe is okay?
  sylvaing: Yes. and if you start adding @keyframes later, it
            doesn't restart.
  smfr: Right, okay.

  <leaverou> Can’t hear what’s being said very well, but fwiw I
             think it’s much more author-friendly to play the
             animation when the @keyframes rule is inserted, instead
             of nothing happening. Whether it starts from the
             beginning or not, don’t think matters that much

  plinss: Is this at all in web animations spec?
  TabAtkins: I don't know.
  TabAtkins: I'm not sure what's in the web animations.
  dbaron: What's in an @keyframes rule is pretty CSS specific, so I
          suspect it's not.
  plinss: I haven't looked at the keyframes part of web animations.
          I'm just wondering if there's ways to affect through the
          API. I just want the specs to stay consistent.
  sylvaing: Web animations wanted the nothing happens if you insert
            @keyframes after. I'm not sure entirely, so I'll check
            with them.
  sylvaing: I had one more issue. Can we resolve that inserting
            @keyframe rule if it wasn't there starts an animation?
  plinss: So is there objections?
  RESOLVED: Inserting an @keyframe rule if it wasn't there starts an
            animation.

  <leaverou> besides the case where the @keyframes rule is inserted
             through JS on a webpage, it also applies to authoring
             environments like dabblet that update the page as the
             user types

  plinss: I'm assuming the remaining issue is more than 30sec?
  sylvaing: It'll take a few minutes. We can do that next time.
  plinss: That's it for this week then. I won't be here next week,
          but I think glazou will be back. Bye!
Received on Wednesday, 16 July 2014 21:47:37 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 16 July 2014 21:47:37 UTC