- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 11 Dec 2013 21:45:50 -0500
- 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
=====FULL MINUTES BELOW======
Present:
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
Regrets:
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
easier.
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
normative.
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
CR.
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
now?
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
week.
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
values,
ChrisL: And lists the properties that must apply (the others must be
ignored).
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
that.
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
track.
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
earlier;
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
smoothly.
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
detail.
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
behavior.
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
hardware,
dbaron: The cost of painting into a layer when it wasn't before is
expensive,
dbaron: And the cost of optimistically using lots of layers is
expensive,
dbaron: This is a hint.
dbaron: Other then the change in stacking, it doesn't have normative
requirements.
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
far.
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
do.
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
this?
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
model.
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