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

[CSSWG] Minutes Telecon 2014-03-26

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 26 Mar 2014 20:47:29 -0400
Message-ID: <CADhPm3sws5Bp=GhA8EqfFQLOY-oW4JemyDiO-oGW=vVMNbyppQ@mail.gmail.com>
To: www-style@w3.org
Seoul F2F

  - Glazou asked that those that volunteered to speak at the event
         with the Korean government message him with proposed topics.

Rename extent/measure to block-size/inline-size

  - RESOLVED: Rename to block-size and inline-size

CSS Scoping

  - TabAtkins and fantasai discussed the proposed agreement that
         they came to for combinators and pseudo-elements in Shadow
  - They also brought to the group their proposal for CSS Scoping
         which includes their above solution, some styling text from
         Regions, and new proposed syntax of @scope.
  - RESOLVED: ED for CSS Scoping
  - Granting a FPWD for CSS Scoping will be considered at next
         week's telecon after the potential issues are integrated
         into the document.

Asynchronous Decision Making

  - Specific details on how the group will handle asynchronous
      decision making was decided:
     - All requests will go through the co-chairs.
     - Co-chairs will post the request for decision on both the www-
         style list and the internal working group list as well as
         the twitter account.
     - Most decisions will be given at least a week for comments
         with urgent and administrative decisions potentially
         being given shorter periods.

Ruby Anonymous

  - The group agreed in principle with twk's proposal for CSS Ruby
         being in line with HTML5's treatment.
  - fantasai will look specifically at fixing the spec.


  - dbaron's question about handling how style changes interrupt an
         already-running transition and put it on a different path
         was discussed with Google's implementor being willing to
         help him come up with a solution.
  - RESOLVED: Move to matrix for the serialization of the computed
         value for Transitions.


  Glenn Adams
  Rossen Atanassov
  Tab Atkins
  David Baron
  Tantek Çelik
  Elika Etemad
  Sylvain Galineau
  Daniel Glazman
  Rebecca Hauck
  Koji Ishii
  Dael Jackson
  Taichi Kawabata
  Brad Kemper
  Philippe Le Hégaret
  Peter Linss
  Edward O'Connor
  Simon Pieters
  Anton Prowse
  Matt Rakow
  Dirk Schulze
  Alan Stearns
  Lea Verou
  Greg Whitworth
  Steve Zilles

  Bert Bos
  Bruno de Oliveira Abinader
  Simon Fraser
  Chris Lilley
  Florian Rivoal
  Simon Sapin

ScribeNick: dael

Seoul F2F

  glazou: Let's get started
  glazou: I have an extra item about Seoul,
  glazou: The meeting with Korean government.
  glazou: They asked us if we can do three talks about the CSS WG
          and the future of CSS tech.
  glazou: I'm willing to do the first about how we work.
  glazou: I noticed astearns and Dave Kramer said they'd talk if
  glazou: Are they still willing?
  astearns: I am.
  glazou: Can you message me about what you'd like to talk about?
  astearns: Yes.
  glazou: That goes for Dave, who isn't here.
  glazou: That's all from me. Any other extras?

Rename extent/measure to block-size/inline-size

  <glazou> http://lists.w3.org/Archives/Public/www-style/2014Feb/0822.html
  TabAtkins: Just a continuation of the previous discussion?
  TabAtkins: Not much came from thread, but we can go with a straw
             poll. I'm fine with any of the options.
  fantasai: What are the options?
  TabAtkins: I think it was length.
  <fantasai> block/inline-size, block/inline-extent, block/inline-
  fantasai: Does anyone want another option? So there's size,
            extent, or length (above).
  fantasai: I think the concerns about size were mostly being
            perceived as 3D.
  fantasai: With <length> and "length" it was just we use it
            everywhere for all kinds of things
  TabAtkins: Yes. We do use size for 1D in several specs. At least I
  TabAtkins: That's all I have to say. I'm happy to poll.

  fantasai: That's a summary of people's thoughts. Did I miss
  glazou: We can do a straw poll with these three.
  <sylvaing_> what's the question?
  <fantasai> Straw poll: inline/block- [size|extent|length|abstain]
  glazou: Let's do that. Microsoft?
  glazou: MaRakow and gregwhitworth?

  glazou: Question is block/inline size, length, or extent.
  MaRakow: I'm not sure. I want to discuss with rossen.
  MaRakow: I'd have to abstain until I hear from rossen
  gregwhitworth: I don't have enough info to quantify. I think we're
                 in Tab's bucket.
  <astearns> size > extent > length for me
  <fantasai> extent > size > length for me
  glazou: Krit?
  <krit> Abstain
  sylvaing_ : Abstain
  <leaverou> Abstain, as I just joined the call
  astearns: I like size
  zcorpan: Abstain
  <SteveZ> extent > size > length for me
  glenn: Extent
  <BradK> I was in the elevator just now. I prefer length
  fantasai: Extent
  plinss: Abstain
  <plh> Abstain
  <rhauck> Abstain
  <antonp> *not* length
  hober: Slightly prefer extent, but rather abstain.
  antonp: Not length
  dbaron: Probably size, though not strongly.
  TabAtkins: Size
  SteveZ: Extent
 * sylvaing_ from the depths of Tab's pockets, Microsoft says...
  bradk: Length or size
  koji: Size
  tantek: Abstain
  glazou: Myself, size
  krit: Abstain

  glazou: Did I miss anyone?
  glazou: That's tough.
  fantasai: It occurs to me that we might at some point have
            properties with these names so we should go with easiest
            for authors.
  fantasai: I prefer extent for vocabulary within specs, easier to
            keep things straight, but for property names size is
            easier for authors to relate to.
  TabAtkins: That makes sense to me
  <antonp> +1 to what fantasai said
  * dbaron was assuming that it would eventually be exposed to

  glazou: So a lot of people are saying extent. Any objections
          against extent?
  TabAtkins: fantasai switched to size.
  glazou: Sorry, size. Any objections against size?
  * BradK likes that size is only 4 letters

  RESOLVED: Rename to block-size and inline-size

CSS Scoping

  TabAtkins: From the naming conversation. Last week fantasai worked
             with me and Demetri.
  TabAtkins: We came up with names we're all happy with, right
  fantasai: I think they're better. They're a good starting point.
            I'm not 100% sold.
  fantasai: I think it's better than what was before.
  TabAtkins: I didn't want to start and have you hate them.

  TabAtkins: In general, we ended up agreeing the pseudo-elements
             make sense.
  TabAtkins: So shadow combinator is now a pseudo element. Just like
             ::attr, it doesn't add boxes, just structure.
  TabAtkins: So children of shadow-root and treated and children of
             the DOM
  TabAtkins: The content combinator is now a pseudo element as well.
             Same treatment for children.
  TabAtkins: We're leaving shadow-deep as is. We don't like it as a
             pseudo element and it's just a powerful descendant
             combinator. However, now there isn't shadow, we're just
             calling it deep.
  TabAtkins: We don't love the name.
  * krit TabAtkins: How much time do we have to decide about the
         name before it is shipping?

  fantasai: This combinator that they envision isn't just through
            shadow-tree, it's also a regular descendant combinator
            which will grab actual and shadow descendants.
  fantasai: So it makes sense it shouldn't be pseudo element in this
  fantasai: So removing shadow from the name made it clear it worked
            for regular tree children.

  fantasai: TabAtkins suggested that if we do ASCII we use triple
  <fantasai> a >>> b
  TabAtkins: The idea is we could do an alias for descendant so you
             could do a double >> and for deep it would be a >>>.
  TabAtkins: It's an issue in the draft, but otherwise we're okay
             with what we have.
  <gregwhitworth> I like combinators.

  TabAtkins: :ancestor() pseudo, which was identical to host, we
             changed to host-context. This makes it tighter and more
             clear about the variation.
  TabAtkins: Expresses relationship in a more general fashion since
             this is for theming purposes.
  TabAtkins: So we now have 2 pseudo elements, one combinator, and 2
  TabAtkins: Hopefully this is more harmonious with the WG's
             desires, so we're hoping for approval.

  * dbaron wonders if this proposal is written down somewhere
  <fantasai> http://dev.w3.org/csswg/css-scoping/#selectors
  * astearns dbaron: if you were asking about >> and >>> it's issue
             2 in http://dev.w3.org/csswg/css-scoping/
  * dbaron was asking about the whole thing
  * astearns dbaron the whole thing should be in
  * dbaron yep
  * tantek appreciates the progress on this subject

  fantasai: I think it's a good starting point and I'd like to talk
            about the draft overall and what concerns people have.
  fantasai: Pull those concerns into the draft and get consensus to
            work and give us something to work off of.
  TabAtkins: Um hum.
  glazou: Ok.

  fantasai: If no one has comments, I'd like to go over what we did
            to draft.
  fantasai: We took the shadow-style mod that TabAtkins drafted and
            expanded the scope.
  fantasai: We pulled in regions draft that astearns had removed and
            added scope styles that didn't have a defined place.
  fantasai: We put it all in the same draft and names it CSS Scoping
            (working title)

  <fantasai> http://dev.w3.org/csswg/css-scoping/
  fantasai: You can scroll to the table of contents to see what's
  fantasai: Only thing that's new is we define scoping and added
            @scope and we mostly have an issue on @global vs other
            ways to handle use-cases.
  fantasai: It links to appropriate areas of specs. We'll have to
            add font-face as an issue. There's shadow-styling, and
            than there's regions pseudo.
  fantasai: We want to expand to regions columns, fragments, and
            hope that'll be defined in the same sections.
  fantasai: So what does the working group think: Are there issues
            we should call out in the draft, can we publish
            officially in the WG?

  astearns: I think it's great you added regions, but in Seattle we
            said we'd do page-styling as the first fragment. So I'm
            assuming that this section gets worked into page-styling?
  fantasai: Yes, we didn't touch the technical text, we did an
            introduction. The idea is define page-styling primarily
            and we'll get the rest almost for free.
  fantasai: For right now, it's just a copy-paste of your stuff.
  astearns: Right, okay.

  fantasai: Anyone else have anything they want to say?
  fantasai: Okay. So I propose we add an issue for handling global
            rules like font-face to scoping.
  fantasai: I would like to get an opinion from the WG if you like
            @scope and if we can add it officially.

  TabAtkins: All @scope does is take the mechanism from style-scope
             and lets you paint it into a style sheet.
  fantasai: I figured it would be good to have syntax so you don't
            have to scatter style throughout your document.
  <fantasai> @scope #selector { <stylesheet> }
  fantasai: It looks like the above.

  dbaron: I'm worried this might change the performance tradeoffs we
          make when implementing scoped styles because it would
          encourage authors to use them at a finer level.
  TabAtkins: That is true. The use-case for scoping in style sheet
             can be solved largely with nesting. The big difference
             is it changed how the cascade works.
  TabAtkins: It is useful, but you don't want to apply it all the
             time. We can say not in CSS and just focus on the
  fantasai: I think we can add an issue explaining that this makes
            it easier, so would impact optimization..
  fantasai: That may or may not be good, but it is something to
            think about.

  <tantek> Interesting, it looks like scoped styles can potentially
           solve some of the SASS / LESS use-cases
  <tantek> Can you nest @scope ?
  <fantasai> Currently, yes.
  <tantek> Whoa cool.
  <tantek> @scope .container { @scope .subcomponent { img {
           height:1em; } } }

  TabAtkins: Does anyone in the WG object to this becoming an ED?
  TabAtkins: And/or FPWD?
  TabAtkins: Unless fantasai thinks there's something to do.
  fantasai: We need to add issues where there's concerns, but I'm
            happy to do FPWD.

  glazou: TabAtkins you asked two questions, ED or FPWD.
  TabAtkins: They're separate.

  glazou: FPWD is more formal than ED.
  glazou: Any objections to ED?

  RESOLVED: ED for CSS Scoping

  <tantek> I am for FPWD
  krit: Is there a way to add the issues and hold before FPWD?
  fantasai: Yes.
  krit: I think we can wait a week and it's okay.
  glazou: So you want a week to review? Is that okay?
  fantasai: Yes.
  <tantek> does that mean absent objections, FPWD in one week?
  glazou: So let's review in a week.

  fantasai: I'm going to add performance and global rules issues.
            Are there others that people want called out?
  fantasai: Anything we want people to know we're not sure about XYZ?
  glazou: Apparently not.

  <BradK> Will nesting be in the same draft?
  <fantasai> no
  <tantek> I think if there is anything else people want called out,
           they have a week to email the list about it and get it
           noted in the draft.
  <tantek> Sound reasonable?

  fantasai: Okay. We'll aim to publish next Thursday and put the
            issues in the draft. That gives a week.
  TabAtkins: Given that we have a call the day before, I'm okay
             waiting for the resolution next week
  tantek: I think it's good to have a resolution now because people
          on the list get a chance to know the ball is rolling.
  glazou: I can be 5 min at the next telecon.
  glazou: Everyone has an action to review and we decide.

Asynchronous Decision Making

  <glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2014JanMar/0260.html

  glazou: This is about using e-mails for establishing consensus.
  glazou: Everyone agrees about it I think. Is plh on the call?
  glazou: My question is should we, is it better to have it in the
          charter? The decision policy of current charter says
          nothing about this and other groups using async have
          something in their charter.
  glazou: It doesn't stop us, it's just cleaner.

  glazou: Other than that, I agree that if you want e-mail based
          decision, plinss or I will send it. It's better done by co-
  <tantek> +1
  glazou: plinss, what do you think?
  plinss: I agree.

  glazou: There's only one thing to remind people, we don't live in
          same time zone and have different schedules. One day isn't
          enough; we need to leave a reasonable time,
  glazou: So we can figure out general opinion of those reading.
  TabAtkins: I think plinss had done 2 days. I think that 48 hours
             is fine.
  glazou: If it's for something settled, agreed generally with
          people in the mailing list, 2 days is okay.
  tantek: I'm going to suggest a week because a lot of us travel to
          meetings and sometimes 48 isn't enough.
  tantek: If it's urgent 48 is okay, but else wise a week.
  <astearns> +1 to week default, but can be decreased to a minimum
             of 48 hours
  * sylvaing_ agrees it's hard to think of a decision that required
              less than a week
  * zcorpan would prefer a week also
  fantasai: I agree. There's times I won't check e-mail for a few
            days. For simple administrative decisions 48 is okay to
            prove consensus since we don't expect objections.
  fantasai: If it's technical a week is good
  <tantek> thank you glazou
  * plh notes that webapps has or thinking to have 10 days

  glazou: It's okay. It'll be a week by default. plinss or I could
          use the twitter account to make people aware.
  fantasai: I think you can CC the internal ML list too.
  glazou: As tantek said, we travel a lot and twitter is easy on a
          mobile device when e-mail is hard.
  fantasai: I think you should still CC in internal list.

  * TabAtkins sylvain, we've had things where we didn't get to the
              "publish as ??" agenda item in the call, and did a
              quick 2-day CfC on the list for it.
  * sylvaing_ Tab, we're talking about a default. as fantasai said,
              admin things can use a shorter deadline.

  glazou: So everyone agrees more calls for consensus on the mailing
          list, sent by the chairs, default it one week.
  krit: If you use twitter, you should also announce to both lists.
  glazou: Absolutely.
  <tantek> Agreed, CfC should be on www-style
  krit: Okay

  glazou: SimonSapin does this address all your concerns/questions?
  glazou: I'm not sure he's here.

Ruby Anonymous

  <glazou> http://lists.w3.org/Archives/Public/www-style/2014Mar/0392.html
  glazou: Can you summarize?
  tkw: Summarize my proposal?
  tkw: The email I sent you, I'd like to change the section of CSS
       Ruby 2.2 to be similar to HTML 5.
  tkw: As you know the HTML5 is only for Ruby and frames. CSS Ruby
      isn't an interpretation of HTML Ruby so creating an anonymous
      box is HTML but not CSS
  tkw: So HTML and CSS should be consistent, but it's not. It'd like
       to propose changing to CSS Ruby work with HTML5.

  fantasai: I looked at your message and agree with goals. I haven't
            looked at exact steps, but I agree we should fix is.
  tkw: This is technical, but in HTML5 Ruby base text should be
       interpreted as Ruby, but anonymous box in CSS Ruby does not.
  [tkw was accidentally disconnected from the call]

  fantasai: We're just missing text to deal with anonymous content
            which is an oversight on my part.
  * dbaron thinks this needs some time for not-in-teleconference
           review of the proposal
  glazou: I agree with dbaron we need offline review. We put this on
          agenda so everyone was aware.

  fantasai: I think this is an action on me.
  glazou: fantasai can you summarize?
  fantasai: We agree this should be fixed, there's an oversight in
            the spec. I think I need an action to fix this.
  tkw: I think so. I want to help fix it with fantasai.
  fantasai: I'll look at your text and check it's correct.
  fantasai: I'll pull it.
  tkw: Thank you.
  glazou: Thank you.

  action fantasai look at the proposal for CSS Ruby
  * trackbot is creating a new ACTION.
  <trackbot> Created ACTION-622 - Look at the proposal for css ruby [
             on Elika Etemad - due 2014-04-02].


  <glazou> http://lists.w3.org/Archives/Public/www-style/2014Mar/0530.html

  glazou: First issue was from dbaron.
  dbaron: A few months ago we agreed on this new model that we
          thought would work to explain how transitions start.
  dbaron: I know some people from Google implemented it in chrome
          and found it seems to work.
  dbaron: That said there's an open issue that I don't know how to
          explain and I'd like some feedback on how to.

  TabAtkins: I talked with Shane yesterday, ultimately we think
             we're pessimistic about being about to implement
             transitions and animations as a hack over cascade.
  TabAtkins: We're not sure what it should look like, but we don't
             think pure cascade would work.
  TabAtkins: We'd need something like "and than do magic."
  TabAtkins: Shane is willing to figure out what needs to be done,
             not what we're currently doing. There will be edge
             cases better addressed by animations anyway.
  TabAtkins: Shane would like to help figure out transitions and
             animations and how they interact. We don't think it'll
             be a normal cascade,
  TabAtkins: But we'll help.
  <fantasai> Can we get an example of what doesn't work without

  dbaron: I don't think this is related to cascades.
  TabAtkins: Because you're trying to figure out how to trigger, it
             still requires running cascade twice or doing
             dependability tracking, but that might be a related
             issues, not this one.
  dbaron: It would have been nice to have that sooner.
  TabAtkins: I know. Sorry. Shane did want to help write and figure
             out what needs to be done, so I'll get him in contact
             with you so we can figure out what is reasonable.
  dbaron: Okay.
  glazou: Anything else on this subject?
  dbaron: Nope.

  <glazou> http://lists.w3.org/Archives/Public/www-style/2013Dec/0317.html
  glazou: Next issue was from krit

  * glazou very hard to hear krit...
  * glazou thinks krit is too far away from microphone
  krit: From mailing list was a reservation about the transform. So
        the computed style..
  TabAtkins: He's proposing we define the serialization to always
             use matrix() or matrix3d()
  dbaron: We can't do that for spec.
  TabAtkins: Computed only.
  dbaron: Or the resolved value.
  dbaron: That the resolved is matrix() or matrix3d()?
  TabAtkins: Right now there's no difference between computed and
  TabAtkin: Do you think it's valuable to say it's the used value?
  krit: Will there be a difference in the future?
  dbaron: I think it's computed vs. resolved.
  TabAtkins: Resolved is either computed or used depending on
  dbaron: Ah. We may want to add better APIs in the future and not
          want this to apply.
  TabAtkins: Wouldn't with just serialization. Then it wouldn't
             necessarily apply.
  dbaron: Yes, but even including serialization.

  krit: That's what I started on the mailing list. There's
        implementations that depend on the matrix already.
  TabAtkins: Given that everyone serializes the same way, we should
             spec it and work around it later if needed.
  glazou: I think it would ease the pain in the case of matrix based
          computed value is we, officially as a WG we...we have an
          algorithm, but no code.
  glazou: If we do this it'll help web dev relying on matrix.
  <leaverou> This (matrix decomposition) could be a part of the new
             CSSOM somehow as well.

  krit: Two different issues. First, there's multiple algorithms.
        The one in the spec has requirement to change.
  krit: Even if we have one for CSS, there's still different use
        cases for decomposing.
  krit: API isn't great, but exposing the matrix into JS is better
        which we could do in the future
  glazou: Only 6 components?
  krit: 6 or 16.
  glazou: It doesn't seem like enough. I understand the multiple
          decompositions, but it's giving them one algorithm.
  glazou: Matrix will be complex.
  TabAtkins: There will be a default in DOMmatrix. It's not defined.
  krit: I'm not sure if we should. Decomposing algorithm isn't ideal.
        There are different proposals that are new, but if we have
        API like DOMmatrix, you can create JS library to do it for
  glazou: Okay, that solves my issues.

  glazou: Do we need a resolution?
  krit: Yes. On serialization.
  glazou: Any objections? dbaron?
  dbaron: So serialization of the computed value is where the
          mechanism that achieves that result changes to matrix?
  dbaron: I'm okay, but we may need to change it in the future.

  glazou: Other comments?
  glazou: Objections?

  RESOLVED: Move to matrix for the serialization of the computed
            value for Transitions

  glazou: It's the top of the hour, the remaining items will move to
          next call.
  glazou: Thanks and talk to you next week.
Received on Thursday, 27 March 2014 00:47:59 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:20 UTC