[CSSWG] Minutes Telecon 2014-08-06

New CR Process

  - Everyone was tasked with reading the new process for CR
       documents in order for the group to be able to discuss how to
       handle current CR documents in light of the new process.


  - RESOLVED: John Daggett is reinstated as Font spec editor

Animation Issues

  - Defer to next week

CSS Color Classes

  - Many members of the group expressed a desire to have a more
       unified color class instead of the separation in TabAtkins'
       proposal; something closer to what leaverou is trying to
  - There was also concern expressed for how the proposal handled
       CYMK colors.
  - Tabatkins requested that people type up their proposes and/or
       thoughts in e-mails so that he can respond in long form with
       his reasoning for separation.

Brand Color

  - gregwhitworth will post examples to the mailing list in order to
       further conversation.

Transform as a shorthand

  - There was some of skepticism about the value of the proposal,
       but most people wanted more time to consider it.
  - Some others expressed a desire to focus attention on review of
       transforms level 1 before considering this proposal.
  - TabAtkins will create a document that looks more like a spec
       proposal in order to aid conversation which will likely
       continue at the F2F in September.


  - After a bit of clarification, these items were deferred to the
       mailing list.

September F2F

  - Everyone was reminded to register because if they don't, they
       won't have network access.


  Glenn Adams
  Tab Atkins
  David Baron
  Bert Bos
  Adenilson Cavalcanti
  Alex Critchfield
  Dave Cramer
  Bruno de Oliveira Abinader
  Elika Etemad
  Simon Fraser
  Daniel Glazman
  Dael Jackson
  Peter Linss
  Edward O'Connor
  Matt Rakow
  Florian Rivoal
  Lea Verou
  Simon Sapin
  Dirk Schulze
  Alan Stearns
  Greg Whitworth
  Steve Zilles

  Rossen Atanassov
  Chris Lilley
  Michael Miller
  Simon Pieters
  Anton Prowse

  ScribeNick: dael

New CR Process

  glazou: Let's start, guys.
  glazou: As usual, extra items on the agenda? I have two to add.

  florian: I have a brief comment. Just wanted to comment about the
           upcoming F2F wiki. There isn't much about agenda or
           participation details.
  glazou: We should start putting items there, agreed.

  glazou: My two things: first is the new process. It's live and we
          have to decide the new CR exit criteria. What do we do
          with existing specs in CR? Do we republish under the new
  <glazou> https://www.w3.org/wiki/ProcessTransition2014
  glazou: The document is the above URL. That's the transition
          document. It has a section about the main changes. I
          suggest everyone reads.
  glazou: Have people had a chance to read this?
  fantasai: I have. I read it a while ago.
  glazou: Others?
  <adenilson> nope.
  <TabAtkins> read it
  Several: nope.
  glazou: Let's put an action on everyone to read for next week.

  Action everyone read the new process doc.
  * trackbot is creating a new ACTION.
  <trackbot> Error finding 'everyone'. You can review and register
           nicknames at <http://www.w3.org/Style/CSS/Tracker/users>.

  <krit> topic for F2F?
  glazou: This is possibly for the F2F, but with the action for
          reading it now there's no excuse not to have it read by

  fantasai: I think we should transition to the new process as we
            publish specs. If we republish a CR we should do it into
            the new process.
  <krit> agree with fantasai
  <TabAtkins> I agree with fantasai too.
  glazou: I'd like everyone to read the new process.


  glazou: Second item is about jdaggett. He's rejoining as you saw,
          but won't be at the F2F. He'd like to become editor of
          Fonts again and requested agreement from the group. I
          don't think it's a problem.
  <Bert> +1
  <krit> +1 for John
  <fantasai> yay!
  <SimonSapin> +1
  <SteveZ> +1 for John being editor
  TabAtkins: I say yes because otherwise I'd have to take over.
  glazou: Any objections?
  <florian> +1
  <adenilson> +1.
  <leaverou> +1

  RESOLVED: John Daggett is reinstated as Font spec editor

Animation Issues

  dbaron: I think we can save that for next week.
  dbaron: sylvain was going to start a thread, and said he would do
          so tomorrow.
  glazou: No problem.

CSS Color Classes

  TabAtkins: I haven't read minutes from last week. Did we discuss
             last week?
  TabAtkins: So no. In that case, leaverou hasn't posted the counter
             proposal, so I say we keep the first section until
             later, I'll continue pinging her. I know she's busy.
  TabAtkins: We can doing the naming of RGB Color Class. As I said,
             the name RGBColor is taken by a DOM level 2 style
             interface, one of those terrible ones. I don't think it
             matters in the slightest.
  TabAtkins: I'd be surprised to find one in one million pages using
             this. I'd be surprised to find one. I think it's fine
             for us to steal the name as browsers never implemented
             it or in Blink's case halfway implemented.
  <dbaron> I've seen some pages using the class, but I don't
           remember seeing them use the name.
  TabAtkins: We can rename it to something else and have a note in
             the spec saying we're stealing this name.

  <krit> Is there a use counter in Blink for it?
  TabAtkins: There is no use counter in blink for it, but I am 100%
             confident in the results. If you think it's needed we
             can measure, but I think it'll be below the noise
  TabAtkins: I don't believe we report below one in a million.

  glazou: Do we really need RGB Color and HSL Color? Can we have
  leaverou: That was what the counter was going to be. The main
            problem is...It was going to be having RGB in the same
            color class instead of separate classes, but there's a
            name collision.
  leaverou: There is an issue that TabAtkins and I discussed on IRC
            after the last call. If we don’t have single letter
            properties, the collisions are much fewer. However,
            there is still one. If  we ever add HSV, there will be a
            collision on the saturation property, since HSV’s
            saturation is very different from HSL saturation.
  leaverou: That's one of the reasons I don't have a counter is
            because I don't have a solution.

  glazou: I'm trying to think as a web designer. A color is a color
          and you're expressing in different units. I don't see the
          point of separating.
  TabAtkins: So we need an extra type whose sole purpose is to
             differentiate between HSL and HSV?
  fantasai: I don't think a type is right, I think you need separate
            functions with separate names.
  fantasai: You may just have HSLSaturation/HSVSaturation.
  TabAtkins: That's worse. It's verbose and inconsistent. Nothing
             else will be tagged. I think it's redundant to have RGB
  <SimonSapin> color.rgb.r?
  <dbaron> SimonSapin: We could have color.rgb.r so there's an
           intermediate object

  * dbaron wonders if we're doing HSV, HWB, or both?
  <leaverou> dbaron: we currently have HWB in the ED, but it's
             possible HSV will be added in the future

  glazou: I suggested it for cleanness of proposal and because it
          solved naming issue with DOM.
  <Bert> (That was also my main question on reading the proposal:
         why 4 classes instead of just 1?)
  TabAtkins: I don't think the name is important. I have other
             reasons why I don't want to merge. I'd prefer to give
             them in an e-mail because they're long, but name
             collision is one reason I think it's the way to go, but
             there's at least two other important reasons.
  TabAtkins: I'd rather wait until there's a serious proposal.

  SimonSapin: I typed a proposal on IRC.
  <leaverou> SimonSapin: +1
  TabAtkins: Can someone raise this in the mailing ist so I can
             raise objections in long form text?
  <leaverou> agreed this will be better discussed in the ML
  <glazou> +1

  Florian : For everything that happens in RGB space, the CYMK part
            bothers me because for every other coordinate system
            it's the same, but it's not that with CYMK
  TabAtkins: I think you'd have to make it so that each class
             represents different syntax for each color space. CMYK
             and RGB.
  Florian: I'm not sure I'm comfortable with having a conversion
           between RGB and CYMK
  TabAtkins: We have that problem with device-CMYK. Right now if the
             browser has knowledge of conversion it uses that, else
             wise it uses naive.
  <leaverou> fwiw, I think the current spec treats CMYK/printing as
             a second class citizen, and SimonSapin’s concerns are
             very valid
  Florian: Yes, but that is using things beyond the syntax level.
           This is just introduced for syntax reasons. Now we're
           going beyond syntax and using color spaces. You don't
           allow it to do the smart thing.

  glazou: Let's take this back to the ML and move on with the agenda.
  Florian: So put this on the list?
  TabAtkins: Yes please.

Brand Color

  glazou: TabAtkins you said something on the ML?
  <glazou> http://lists.w3.org/Archives/Public/www-style/2014Jul/0131.html
  TabAtkins: Someone said they can take this?
  gregwhitworth: I was going to speak to what it was. We've been
                 approached by windows phone to add an accent color
                 and we looked at other phones, such as iphone that
                 may have this. We think there should be a broad
                 consensus. It's not really a highlight, which was
                 deprecated. We were looking for what does the WG
                 feel the best place for this is. We'll need
  TabAtkins: I'm not 100% clear on use cases. Some examples of how
             this is used in an application, that would be cool. I
             don't get it right now.
  <dbaron> A generic accent color is a bit hard to use in
           combination with other colors since you don't know what
           other foregrounds/backgrounds will work with it.
  gregwhitworth: I can provide that. It's system color, but that's
                 deprecated. You're setting an accent, so you're
                 doing a theme on the desktop. Initially we were
                 going to say appearance, but that's deprecated too.
                 We're looking a place to stick a color.
  TabAtkins: This is why I need examples. I can imagine several
             different ways to do it, but it depends on what you're
             doing with it. Color might not be best because you
             might need light and dark.
  glazou: What you said sounds similar to CSS system colors we had
          in the past. We retired that because eventually there
          wasn't enough to do with that.
  TabAtkins: That's why I want to get past the abstract.
  gregwhitworth: I'll follow up on the thread with examples.

Transform as a shorthand

  TabAtkins: I posted a summary on the list about an hour ago.
  TabAtkins: It's adding three properties, transform, rotate, and
             scale. Syntax is similar to the functions and
             implemented in a similar way to transform-origin.
  TabAtkins: In particular they are pre-pended to the list in
             translate, rotate, scale order.
  TabAtkins: After the transform-origin business.
  * dbaron notes that "after" vs. "before" is ambiguous depending on
           whether you're using row vectors or column vectors...
  <SimonSapin> dbaron, my experience with implementing transforms is
               randomly swapping matrix multiplication order until
               it looks like other implementations

  TabAtkins: That's basically it.
  smfr: Does your proposal have the transform-origin business?
  TabAtkins: Yes. They're not required to be there, we can just say
             they use transform-origin, but I think it's nice to
             have them separable.
  fantasai: There will be lots of cases where you'll want to change
            the origin.
  TabAtkins: Yes, As I said these should be short hands of original
  TabAtkins: So translate would be X,Y and Z. So they're useful to
             cascade separately. If I'm doing several rotations
             around a non-default axis, that's useful.

  glazou: Other opinions?
  krit: I'm skeptical to be honest. Maybe we should that more time
        and talk at the F2F?
  TabAtkins: We've talked about this for 2 or 3 weeks, but the F2F
             is an okay delay.
  krit: I think two more weeks is okay.
  TabAtkins: I'm not saying it's unreasonable.
  * fantasai is happy to take this to F2F,would prefer people
             focused on krit's request for reviewing L1

  smfr: I think Apple's feeling is this is an unnecessary
        complication. We won't be too upset if it happens, but I
        object to splitting into separate properties. We've resisted
        that in other places. I don't protest the simplification,
        but I don't want to break them into more longhands.
  TabAtkins: Well, there was background-position that we resisted
             breaking, two browsers broke it into independent X and
             Y because authors wanted that. I don't see a difference
             between those.
  krit: I think that's a bad example because that was partly from
        implementation details.
  MaRakow: Split background properties have been pretty painful as
           it introduces a lot of complexity and a huge test matrix.
  * fantasai notes the main use case for splitting bgpos was image
             sorites, which is a hack
  <TabAtkins> The use-case was a hack, but the reasoning behind the
              use-case (wanting to position things according to a
              grid, where you want to write X+Y rules rather than
              X*Y rules).

  glazou: It appears this still needs more discussion. The scope of
          the proposal...everything. We need more to make a decision
          and there's an objection from Apple.
  glazou: fantasai, you say you want it as F2F item?
  fantasai: I think it's fine to bring this up at the F2F. I'd
            rather people focus on Krit's request to review level 1
            and that's the same people.
  <adenilson> +1
  glazou: Other opinions?
  glazou: Do people agree with fantasai?
  Krit: No objection to the priorities.
  glazou: Let's do as Krit wants and continue working on the other
          proposal. I don't feel this is entirely ready, even after
          the discussion.

  TabAtkins: I'm fine with review, but it's ready to be done.
  <dbaron> presumably the proposal is
           http://lists.w3.org/Archives/Public/www-style/2014Jul/0315.html ?
  glazou: We need more than an e-mail for the proposal.
  TabAtkins: What do you mean?
  glazou: A document or section? A changes section?
  TabAtkins: The entire proposal is pretty complete in the e-mail. I
             can write it in the visual style of a spec.

  smfr: Is this to go in transforms 1?
  TabAtkins: I won't do anything level-wise that means there will be
             objections to the spec because of level. It can go
             where ever as long as it get in somewhere.
  krit: Having a more spec looking document might help the review.
        With examples. It's maybe asking a lot, but just reading an
        e-mail can be hard.
  TabAtkins: I'll put something together.

  fantasai: I think this would be level 2. Maybe create a WD of
            level 2 for this? I don't want to put a time limit
            because the same people need to spend time reviewing
            level 1.
  TabAtkins: I don't think every object being done separate is
             useful, but I don't care what level it goes in.
  fantasai: If you want to draw up a document, get permission to put
            it on the dev pages.
  TabAtkins: It's on my github.

  glazou: So when it's published, will Google implement right away?
  TabAtkins: No
  glazou: I want to make sure this is on the normal rec track.
  TabAtkins: This is a personal proposal.
  glazou: Then I have no objection for it being in level 2.

  krit: Let's go on with an unofficial draft first.
  TabAtkins: Agreed.
  TabAtkins: Levels isn't relevant yet.
  glazou: Everyone agrees? No objections?

  fantasai: Unofficial draft, what will you call it?
  TabAtkins: I'll call it my proposal on my github.
  fantasai: I'd prefer it doesn't get put on github. We're writing
  TabAtkins: I'm doing e-mail attachments.
  glazou: We used to be able to store proposals on w3c. Bert and I
          sent proposals and I think TabAtkins should be able to.
  TabAtkins: We stopped when I got objections to putting proposals
             on that.
  glazou: Not on dev, it was on the WG page.
  TabAtkins: Oh. None of us have that permission
  fantasai: That is annoying. We should have a way to put everything
            on dev that's unofficial.
  glazou: Everyone fine with that?
  <gregwhitworth> I like GH myself, maybe a W3 GH repo?
  <gregwhitworth> Then it gets pulled in automatically?
  krit: No objection to dev or github.

  SimonSapin: On w3c.org, how do we do that? Through CVS?
  glazou: I suggest TabAtkins uses his github.


  <glazou> http://lists.w3.org/Archives/Public/www-style/2014Jul/0620.html
  glazou: We have two topics. First was by Boris about leading and
          trailing whitespace rules.
  fantasai: I think that will have to stay on the mailing list, I
            haven't gotten to it yet. Unless someone has interest on
            the call.
  dbaron: I think they're both better on the mailing list.

  SteveZ: I was confused from Boris' example why the base isn't just
          text and whitespace is disappearing.
  fantasai: There's special handling in Ruby to clear what you use
            of indentation. We have a bunch of rules to generate
            anonymous boxes and I need to sit down and find the
            right way.
  TabAtkins: Ruby bases and text are on different lines and there's
             rules about putting things for white space.
  fantasai: There's rules about anonymous box and white space
            discarding and I need to sit down and find a fix.
  fantasai: If you care about white space at a higher level, read
            the spec and send comments.
  SteveZ: I've tried, but get confused between elements and boxes.
  fantasai: They should all be boxes.
  SteveZ: White space is an element thing.
  fantasai: A content thing.
  SteveZ: But they're elements. They're nodes, but not boxes.
  fantasai: There's a bunch of examples in the spec.
  SteveZ: Trying to read it and the Ruby HTML spec doesn't work well
          together. I'll do it on the mailing list.
  glazou: So both items will go off the call. That's the last thing
          on the agenda. Bert F2F details?

September F2F

  Bert: Register. If you don't register, you don't get any network
  Bert: If you have questions or things for the wiki, let me know. I
        put the things I thought should be included, but let me know

  glazou: You've reserved a room? That's not mentioned on the wiki.
  Bert: I don't know the name of the room, but there is one reserved
        for us.
  glazou: Anything else?
  glazou: Okay. Then I think we have a short call.

  <gregwhitworth> How do you register, send an email is there a
                  magical button?
  <plinss> http://wiki.csswg.org/planning/sophia-2014
  glazou: gregwhitworth, to register you need to add your name to
          the wiki
  gregwhitworth: How to you do that?
  <fantasai> http://test.csswg.org/shepherd/
  plinss: Use w3c.org or shepherd credentials. It's a bit tricky,
          but we had a lot of spam.
  gregwhitworth: Thanks.
  <Bert> (If you can't use the wiki, send me e-mail, and I'll edit
         the page.)
  glazou: The main page of the wiki says how to register through
  glazou: Thank you for today and I'll see you next week.
  <adenilson> bye.

Received on Thursday, 7 August 2014 00:56:55 UTC