- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 16 Jul 2014 17:47:09 -0400
- 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