- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 22 Oct 2014 22:58:38 -0400
- To: www-style@w3.org
Animations Issues
-----------------
- RESOLVED: Animation properties don't apply inside keyframe rules
except animation timing function (where we have explainer
text already)
- RESOLVED: Keywords are invalid @keyframes names and will throw
when set through the OM
- RESOLVED: findRule/deleteRule return/delete the last rule with
the specified key.
- sylvaing requested input/assistance in turning the resolution
from Sophia regarding how the animating values are computed
when they depend on the value of another property into actual
prose in the spec.
Text
----
- There was disagreement between the authors about the purpose and
effectiveness of an author poll to try and determine
sentiments from Korean speakers about the spacing solution
developed at the Sophia F2F.
- In the end, there was wide support for contacting companies to
see what issues they have encountered and an e-mail will be
written to poll individuals in an attempt to get more
responses. If there is no significant response or no valuable
data, the group will defer to their Sophia decision.
- Once this issue and a few others are resolved, Text will be
ready for a LC publication, so people were asked to submit
any issues they may have soon so they can be addressed.
TPAC
----
- If they haven't already, TPAC participants were asked to add
their information to the CSS wiki
- Another call was also put out for additional topics for
discussion to be added to the wiki.
- Flexbox's LC period will end just before TPAC, so everyone was
urged to review it, especially for compat feedback on the
flex-basis: auto/main-size issue.
===== FULL MINUTES BELOW ======
Present:
Rossen Atanassov
Tab Atkins
David Baron
Bert Bos
Adenilson Cavalcanti
Alex Critchfield
Arron Eicholz
Elika Etemad
Simon Fraser
Sylvain Galineau
Daniel Glazman
Koji Ishii
Dael Jackson
Dean Jackson
Brad Kemper
Peter Linss
Mike Miller
Edward O'Connor
Anton Prowse
Steve Zilles
Regrets:
Dave Cramer
Bruno de Oliveira Abinader
Florian Rivoal
Simon Sapin
Dirk Schultz
Mike Sherov
Alan Stearns
Lea Verou
Scribe: dael
glazou: Let's start. We have a few regrets.
glazou: Are there extra items?
<dbaron> my SIP client isn't working right now, so unable to join
<glazou> dbaron, ACK
Animations Issues
-----------------
sylvaing: I want to make sure we have the right people on the call
for this.
sylvaing: During Sophia we agreed to let animation properties
effect running animations so if your animation is
running and you change the timing or what not it has an
immediate effect.
sylvaing: Outstanding issue is what happens when you update an
animation in a @keyframe.
sylvaing: TabAtkins was of the opinion it ignored them and that's
fine with me. You end up in a tricky area. I can't find
any real minutes or e-mail thread suggesting consensus.
sylvaing: If people don't object I'll document it, but I want to
double check.
glazou: Opinions?
sylvaing: So inside an @keyframe the only animation property that
has an effect is timing. The others are ignored.
TabAtkins: And it doesn't do what it normally does inside, it's
just between keyframes.
smfr: So this is about properties that effect animations, not
changing the keyframes.
sylvaing: So the question is can a keyframe rule change a running
animation property.
sylvaing: So we covered what it means to change when an animation
running, the only leftover part is when you have a
@keyframe rule.
smfr: Sounds fine.
glazou: Seems resolvable.
RESOLVED: Animation properties don't apply inside keyframe rules
except animation timing function (where we have
explainer text already)
sylvaing: Next issue
<sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25344
sylvaing: This bug above
sylvaing: It's likely a non-issue. When you have a keyframes
objects for an @rule, today you can set the name of the
keyframe rule to 'none'.
sylvaing: That's not a good keyword. The question was should we
throw, I think yes.
sylvaing: This isn't controversial, I think. Unless someone thinks
of an exception.
smfr: Is 'none' the only special value?
sylvaing: For the name of a keyframes rule?
smfr: I can imagine 'infinite' or 'inherit' names which would be a
bad time.
sylvaing: So the usual global keywords would throw.
sylvaing: Fair point.
dino: Haven't we in the past required keyframes to be quoted?
smfr: The original spec had, but we removed that.
sylvaing: So you can say if you want to use 'inherit' you can
quote it, but if you don't quote it, what happens? You
can't set to that.
smfr: So is it valid when you're passing the first time?
glazou: What about counter names?
TabAtkins: Explicitly disallowed.
glazou: So I say we do that.
TabAtkins: You get that for free if you reference custom-idents.
sylvaing: Okay. That works.
<smfr> http://dev.w3.org/csswg/css-values/#custom-idents
plinss: Does custom-ident spec reference the OM?
TabAtkins: Not so much, but if you check the grammar for the
animation name you get there.
sylvaing: I'll clarify in the prose for the spec. So if I do
@keyframe and "none" does that work?
TabAtkins: No, it doesn't match the keyframes grammar.
sylvaing: You're right.
sylvaing: So.... when I set it in the OM, the named property to
'none', it still throws.
TabAtkins: Yeah.
TabAtkins: Anything that prevents re-serializing it.
RESOLVED: Keywords are invalid @keyframes names and will throw
when set through the OM
sylvaing: Next one.
<sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25034
sylvaing: This came from an e-mail from glazou.
sylvaing: It was deleteRule/findRule. What happens when multiple
rules contain the same key?
sylvaing: The API today assumes that there is one. In practice
browsers apply the rule to the last one.
glazou: The problem is different between deleteRule and findRule.
We may have to change find but can fix delete.
* smfr wonders why we’re specifying any css om stuff
sylvaing: From my testing they find and delete the last one.
glazou: I'm not sure if this is what the user would expect.
sylvaing: It made sense before. You would find or delete the last
one. Now that there's cascading across rules it may not
find or delete everything.
sylvaing: A find rule may give an incomplete description or you
may think you deleted everything and it won't.
sylvaing: So today it's find and delete the last one.
glazou: In answer to smfr's question in IRC: CSS WG got the OM
from DOM long ago. We were long ago going to add the OM
pieces.
sylvaing: And this is the OM in Animations spec.
smfr: I guess I understand. I thought we had a longer term goal to
rewrite the OM, will it still work after we re-write?
sylvaing: I agree we may want to clean it up in the future. I
suggest for level 1 we should agree on what to have
interop on.
sylvaing: I think the behavior is reasonable for find.
smfr: It seems to be current functions are insufficient.
TabAtkins: They are, but that was in the original spec and
implementation.
smfr: So we're not going to change, just define.
sylvaing: And it used to be reasonable, it's just more awkward now
that we cascade across rules. It's not ideal, but we
should describe what browsers do.
sylvaing: So saying delete/find rule apply to the last of that
rule?
smfr: So how does that work?
sylvaing: So right now it is a separate issue. In browsers today
you see the first one and the second instance is thought
of as a separate item.
TabAtkins: Original spec OM was a hot mess, basically.
sylvaing: It was over-simplistic.
<dino> more detail: "50%" is different from "50%, 60%" and might
even be different from "50%,60%" (no space)
smfr: Can we add a note to the spec that describes this issue?
sylvaing: I can do that.
smfr: I think it should be for authors so they know we understand
there's this issue.
glazou: I think smfr's request is important to add a note. An
editor will rely on findRule, so please do the note.
TabAtkins: The occasional thing where we say it's not great
behavior but it's legacy.
<dbaron> I don't understand what " RESOLVED: keywords are invalid
@keyframes names and will throw when set through the OM"
means
<dino> dbaron, I think the resolution was that setting keyframes
rule name to "inherit" via the OM will do nothing other
than throw an exception
sylvaing: Let me resolve this and then I'll answer dbaron's IRC
question.
RESOLVED: findRule/deleteRule return/delete the last rule with the
specified key.
sylvaing: So dbaron: what this means is that if you retrieve the
keyframes rule for the OM and set its name property to a
keyword like 'none', they think it's a name like any
other. And this means it should fail.
dbaron: And does parsing fail?
sylvaing: Yes. It's a custom-ident based fail.
sylvaing: that's all I had for today.
sylvaing: We'll have more for the F2F and then we'll be pretty
much done. The one that's left and I would love input is
the one from Sophia which had tests everyone ran.
sylvaing: That one is tricky. Any input is welcome.
dbaron: I'm not sure which one you mean...
sylvaing: The one you sent all the alternatives on multiple
animations running concurrently. You had the list A-G
and alpha and beta. We resolved to G Beta, but what that
means in spec prose is trickier.
sylvaing: That's it for today.
Text
----
koji: Yeah. fantasai?
glazou: Just one thing before we start this, I'd like to leave the
last 10 minutes for TPAC conversation.
koji: So fantasai and I discussed this and we disagree so we need
the WG opinions
<koji> https://wiki.csswg.org/spec/text-justify-auto#future-possibilities
koji: Looking at the table from the last F2F (above).
koji: We have the options listed there. fantasai's point is that C
option is really bad. She finds it unacceptable and should
be avoided at any cost.
koji: I don't think it's that bad. I'd rather less docs and
authors being affected.
fantasai: The issue is koji wanted clarification on what data
we're going to collect and how that impacts our decision.
fantasai: I thought we wanted to look for what can/can't people
live with.
fantasai: I understood that the Japanese don't want large spaces
because it make it ugly. For Korean we're not sure about
if it's okay to treat Han and Hangul differently. Does
that make odd spacing?
fantasai: Let me paste...
fantasai: There was a place for code snippets and I can't remember
where.
<smfr> pastebin?
fantasai: Here we are.
<fantasai> http://pastebin.mozilla.org/6853299
fantasai: The question we need to ask is does creating spaces
between Han and not Hangul create weird parsing of
Korean or does it look awkward,
fantasai: In the way having large spaces in Japanese would look
awkward.
fantasai: That's my understanding of the key question
koji: I understand that. I think asking if it's acceptable or ugly
to end users will fail. "How bad" is hard to figure out by
interviewing users.
koji: What we're asking is to help us...how do we determine this
as a WG?
koji: One idea that came from our discussion was would be to ask
companies how badly their product does for justification
behavior, but other ideas would be appreciated.
hober: I can say that the current webkit behavior is what we've
been asked to have and we don't have any bugs from Korean
users.
koji: Okay. Great.
hober: It's worth noting that the web corpus for Korean isn't
similar to historical documents. If the default is good for
modern and there's a way to tag historical, that's the best
we can do.
koji: I understand. A behavior that I'm worrying about isn't
webkit. fantasai?
fantasai: I'd like to hear from actual Korean people. Cases where
this will be noticed isn't really common. You need
narrow lines or a large word that wraps. That's going to
be more common on mobile, but isn't common in general.
fantasai: It's important to understand is it as bad if you put
random justification somewhere in the middle of a word.
Is it going to effect where spaces are interpreted and
where word boundaries are, that's more important than if
a justification space is slightly bigger than ideal.
koji: This issue itself isn't about backwards-compat only. We're
asking authors to explain what to do. If we're not breaking
many documents, is that something we would choose?
fantasai: You're like, well, we're only going to break some
documents in Korean which is less important than making
more documents in Japanese look right. I think we should
get a minimum of 'this isn't broken'. You're saying
let's break one thing to make other things look better,
I'm saying break nothing even if it makes everything
look worse overall.
fantasai: We're supposed to get information.
koji: Why have there been no webkit complaints if this is that
bad?
fantasai: Maybe they didn't notice.
koji: But if they didn't notice it's not a big problem, is it?
fantasai: If I put spaces in the middle of an English word so it
looks badly kerned, most users won't notice, but it's
still very wrong.
fantasai: If you come up with a case where that space gets larger,
it becomes a problem for readability.
fantasai: What do you want to know from the WG? I think we need to
know from Korean people if this is an okay place to put
spaces or is this as bad as putting a space between a
suffix and the rest of a word in English.
glazou: I still have a lot of good contacts in Korea. If you want
to send me an email I can forward so they can hopefully
answer.
fantasai: Okay.
koji: What I'm saying is that if we ask users about how bad this
is, is it unacceptable or just ugly, that's not the right
way to investigate.
koji: Only could say ugly or unacceptable to the same thing, it's
just dependent how they think it is.
glazou: I don't really understand, koji. Pinging the users about
impact is always good.
hober: When we discussed this in Sophia we ended up in a
reasonable place without the feedback. I don't think
anything has changed, we want that feedback.
glazou: So what are the next steps?
fantasai: I have an e-mail I just need to tweek before I send it
to you to be forwarded.
glazou: I'm not sure I'll get an answer, but I can forward.
fantasai: I don't know what koji wants, I think he wants to not
ask the uses because he doesn't think they will give
good feedback.
koji: If the question is yes or no or compared to something it's
okay. If it's is this ugly or unacceptable I think it's
inaccurate.
fantasai: That's why I phrased with comparisons to English and
Japanese.
koji: I got different feelings from that. The difference is subtle.
koji: Am I wrong? Regarding investigating?
<fantasai> 1. Don't ask anyone from Korea to help
<fantasai> 2. Come up with a question and do our best to get the
information
fantasai: I think the action options are (above)
fantasai: You're saying do 1 because the best isn't good enough to
be worthwhile.
<sylvaing> Not sure why #1 is not an option
<sylvaing> or rather why it is an option
koji: Ask Korean natives?
fantasai: We need to ask someone who isn't Japanese. We have a
bias because there's lots of opinions from Japanese
speakers, but no Korean. I don't care who we ask, but if
you're arguing we don't talk to anybody it doesn't make
sense.
koji: We had started asking companies.
glazou: I'm not sure this is going anywhere. fantasai, you send me
an e-mail and we'll give them a week to answer. If we get
a useful answer, fine. If not we do otherwise.
glazou: Anything else on this issue or in Text?
koji: We've been discussing this for a long time. After this and a
few others are resolved, we want to take text to CR, so if
there are other concerns please state them.
fantasai: We have to go through LC again, but there should be no
changes beyond that.
glazou: Okay. Thank you.
TPAC
----
glazou: I don't know if you have seen the request from Janina for
a joint meeting Friday morning. That's outside our two
days, so anyone willing to attend, please do so.
glazou: We have a bunch of observer requests. It seems our agenda
will be packed with joint meetings, but we don't have a
lot of official items.
glazou: It looks like most of us will arrive Sunday evening. So
let's have plans together by Sunday evening. Any questions
about TPAC?
fantasai: Flexbox LC ends at the end of this week, so if you have
feedback please try and put it together. If you need
more time, please let us know.
fantasai: We were looking in particular for compat feedback on
the flex-basis: auto/main-size issue.
rossen: Which module?
fantasai: Flexbox. So get your feedback together.
glazou: Anything else?
SteveZ: Any idea of what topics will go on what days? I have a
Tuesday problems so I'd like anything layout to go on
Monday.
glazou: Given the number of TPAC constraints, I'd appreciate if
they can go on the wiki. I'm asking everyone to put their
name on the participants list on the wiki. Right now
there's only 6 or 8 people. That will help us monitor who
is here when.
glazou: Anything else?
glazou: OK. I guess this is all today. Safe flight to anyone
flying and I'll see you there!
Received on Thursday, 23 October 2014 02:59:05 UTC