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

[CSSWG] Minutes Telecon 2014-10-22

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 22 Oct 2014 22:58:38 -0400
Message-ID: <CADhPm3uMGLxdFKLFW_iHDN59ANZuznxoNKPV-nWxAbDqxGvmLA@mail.gmail.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:47 UTC