- 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