[CSSWG] Minutes Telecon 2016-06-08 [css-grid] [css-transforms] [css-values] [mediaqueries] [css-conditional]

Previous Topic Next Topic
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

[CSSWG] Minutes Telecon 2016-06-08 [css-grid] [css-transforms] [css-values] [mediaqueries] [css-conditional]

Dael Jackson
  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.


  - The group is considering switching to the software and document
      license (available here:
      and any working group members representing a company were
      asked to review this change with the appropriate parties.
  - The new charter will still require deadlines so the group plans
      to put items that should be finished soon due in a year and
      other items due at the end of the charter.
      - Spec authors are asked to please give ChrisL any input on
          what specs they plan on working on at what time to help
          him determine dates.

Handling combined opacity & preserve-3d

  - RESOLVED: Any value of opacity less than one forces transform
              styles to be flat.

OK to have fragment-only URLs always refer to the host document?

  - There were strong objections to this approach so TabAtkins will
      re-write with a different approach.

@else rule

  - glazou had strong concerns that this rule would be very hard for
      editors to implement, but TabAtkins felt that the benefit to
      authors was greater than the trouble caused to editors.
  - There were concerns that having all @else rues ignored after one
      is found as true isn't consistent with other media queries,
      however it is consistent with most programming languages so it
      was felt it wouldn't give authors too much of a problem.
  - RESOLVED: Add @else to the next level of conditionals pending
              review by dbaron.


Agenda: https://lists.w3.org/Archives/Public/www-style/2016Jun/0022.html

  Rossen Atanassov
  Tab Atkins
  Dave Cramer
  Alex Critchfield
  Elika Etemad
  Simon Fraser
  Daniel Glazman
  Tony Graham
  Dael Jackson
  Brian Kardell
  Ian Kilpatrick
  Chris Lilley
  Peter Linss
  Edward O'Connor
  Simon Pieters
  Florian Rivoal
  Alan Stearns
  Greg Whitworth
  Steve Zilles

  Tantek Çelik
  Brad Kemper
  Anton Prowse
  Jen Simmons
  Lea Verou

Scribe: dael


  Rossen: Hello everyone. Let's get started.
  Rossen: As usual, I'm asking for extra agenda items. I have one I
          want to start with, but any extra items?
  ChrisL: Is charter on?
  Rossen: That's the one I was going to give.

  <Rossen> http://www.w3.org/Style/2014/css-charter
  Rossen: One thing brought to our attention is that our current
          charter as in ^ link expires in 7 days.
  <ChrisL> http://w3c.github.io/charter-drafts/css-2016.html
  Rossen: So we have a week to renew our charter. ChrisL started a
          new draft at this link ^ (from ChrisL)
  Rossen: We need to act on this rather rapidly. I'd like to let
          ChrisL talk to us about it and come up with some actions
          so we can close before it expires.

  ChrisL: There's a new template that has to be used which has some
          new language. I've kept that. The template is on github
          and I've put this on github. Because it's for discussion
          I've kept a lot of noisy highlighting. There is some buff
          background issues from the charter template itself. On the
          greenish I have issues I've raised.
  ChrisL: First, when referencing a spec you have to have normative
          issues, link, description, state of the draft, and
          expected completion. When we rechartered last time we
          resolved to get rid of these dates. We presented a charter
          with no dates and were told to put them back. So we're
          required to have a timeline with all the dates.
  ChrisL: If you look in the old charter there's a list of
  <astearns> do dates have to be as specific as Q1, etc.? Could we
             just have years? 2017-ish?
  Florian: Can you roll a die and do random dates? When it's done no
           one will look.
  glazou: Not quire true. ACs could look and see there's no progress.
  Rossen: I agree with glazou. Before we do dates lets have ChrisL

  ChrisL: Main thing I need is peoples thoughts on the old
          deliverables. We had high priority list. Selectors was a
          really bad one, TR is 3 years old. Basically a bit of help
          would be useful because if people think should be bumped
          down or active things that should go up.
  <fantasai> and Overflow
  <fantasai> and Tables is now active :) but that's recent
  ChrisL: Once I have a bit more information...I'm going to copy
          them to the charter and add descriptions. But if people
          chime in on when they'll work on specs it will help me add

  ChrisL: Horizontal review is no longer required, that's different.
          The template requires you to say your WG home page has all
          deliverables, issues, actions, meetings, and I don't think
          that's reasonable. I think most groups have that on
          different pages.
  ChrisL: There's something about the group conducting work on
          public ML and I've been talking with plh about adding
          github since we're there. I expect that to self-resolve.
  ChrisL: We need to do licensing. It says the group will use one of
          the options [reads options]. I suggest we pick software
          and document license but I'd like opinions.

  glazou: There's one thing, what is the expected end date of the
  ChrisL: Typically we ask for 2, I'm going to try for 3. It's
          reasonable and worst is we get 2.
  glazou: Then I suggest that for estimated dates the ones we want
          published ASAP give them one year. For the other...
  <glazou> for the others, duration of the charter
  Rossen: I'm sure once we get into dates it'll take a bit. I want
          to close on a few other things first and I'll get back to
          you on this.

  Rossen: First was the license thing. We'll have to take this back
          to lawyers and I'm assuming others will too.
  ChrisL: So there are two and they're linked. One is document
          license which is what we're using. The software and
          document is newer. It means examples and the like are
          covered by the software license and allows people to copy
          them and that's okay.
  Florian: IT sounds like if and example is three lines it's fair use.
  ChrisL: It does. But people worry about this. It removes the
          source of worry.
  <ChrisL> https://www.w3.org/Consortium/Legal/2015/copyright-software-and-document
  Rossen: So yes. I'll have to follow up on our side. I'd urge
          everyone representing a company to take that action and
          make sure you're comfortable with the licensing section of
          the charter.

  Rossen: Another great point glazou brought up offline is the
          addendum of the WG may add additional work in the future.
          I think that's important for us to keep.
  ChrisL: I put it in this one after glazou made that comment.

  Rossen: With that we can have a looser wording around dates and
          timelines. I think now is a good time to resume the
          timeline discussion. But let's cap it at 15 minutes. From
          memory that topic can take a long time.
  Rossen: So glazou I cut you off. Can your resume?
  glazou: I thought since giving estimates for specs is highly on
          the guess side, I think giving one year to the specs we
          want to publish ASAP and giving the duration of the
          charter to others is good to do. We've experienced this in
          the past and it's too hard to say.
  <fantasai> +1 to glazou's plan
  <ChrisL> No-one will complain if we get stuff done early
  Rossen: Yes, we've proven time and time again our estimations have
          had problems. Sometimes we can surprise people. But I'm
          with you on this one.
  Rossen: Can we keep it loose in terms of timeline? Can we keep it
          before the end of the charter and after expiration of this
  ChrisL: I think that's good.
  Florian: By complete we mean?
  Rossen: Whatever we put for the timelines is what we'll hold
          ourselves to. If we say REC by the end then that's it. If
          it's CR than that.
  Rossen: We should look for ways to not get bogged down to exact
  Rossen: To use looser language and speak in terms of charter
          expiration to guide us.
  ChrisL: I'm happy to do that.
  Rossen: I wanted to hear from more people in the WG. Any input
          into this? Anyone care?

  <ChrisL> is the "current work" page still the best one to link to?
  ChrisL: I have one other question. Currently the charter links to
          the current work page. Is that still the best? Is it
  fantasai: Yes.
  fantasai: I'm due for double checking it, but it is being
            maintained. Bert and I update.

  fantasai: As for the dates I'm happy to give you estimates like
            "we might get this to CR, this likely not" but nothing
            is getting to REC until we have testers that are as
            active as the editors.
  fantasai: Except maybe Writing Modes, and that's largely because
            Japan is driving progress on that.
  Florian: Hasn't that changed because gsnedders is doing stuff?
  fantasai: He's going to make it easier to collect tests, but
            evaluating it isn't on his list and it's not fair to ask
            him to do that on all specs.
  Rossen: Even if we want to communicate CR expectations that would
          be somewhat conformant?
  ChrisL: Sounds right.
  Rossen: Great. So let's not get too detail-ly.
  ChrisL: Thanks.
  Rossen: We'll work with ChrisL and organize all the current work
          in terms of expected dates and then circle back with the
          WG before we go back to plh. If you have concerns about
          licensing and/or dates please look at this charter
          template and comment.

  <fantasai> The stuff in Stable should be possible to get to REC,
             but requires someone to own that process. Until then, I
             expect no REC within the next 3 years.
  <fantasai> The stuff in Stable I expect to stay there.
  <fantasai> The stuff in Refining should get to CR before the end
             of the 3-year period, excepting CSS2.2
  <fantasai> Wrt Revising, I expect Grid to reach CR in about a
             month. Box Alignment, Selectors 4, and Display 3 are
             likely to reach CR by the end of 3 years.
  <fantasai> Sizing and Overflow 3 were recently trimmed down,
             should also reach CR soon.
  <fantasai> Media Queries 4 is in the process of being trimmed,
             also likely to reach CR
  <fantasai> I'm optimistic about Scroll Snap, Pseudo-elements, and
             Inline Layout also reaching CR.
  <fantasai> I expect nothing else to reach CR.
  <fantasai> ChrisL, that's my best guestimate :) Feel free to copy
             it over into the charter.

  <gsnedders> Florian, fantasai: reviewing tests is on my to-do
              list, albeit a touch distance, but I don't have the
              competency to review tests for all modules

auto-repeat inside grid-template shorthand

  Rossen: I think this was fantasai or TabAtkins
  TabAtkins: Didn't we talk about this last week?
  fantasai: Yeah, we did a tentative resolution pending a week. I
            don't think there's anything to discuss.
  astearns: This is probably my fault. I thought I had de-labeled
            all these.
  Rossen: Do we need a resolution or move on?

Handling combined opacity & preserve-3d

  <Rossen> https://lists.w3.org/Archives/Public/www-style/2016Jun/0013.html
  Rossen: Who wants this?
  smfr: I responded in the e-mail and I'm not sure we need to talk
        much. Implementations were not treating opacity as something
        that caused flattening.
  smfr: You need to flatten to do correct group opacity so I think
        it's correct that it should override.
  Rossen: So proposal is change that opacity forces flattening.
  smfr: The current ED of transforms says that I believe.
  <smfr> here's the text in the draft that describes this:
  <smfr> "opacity: any value less than 1."

  Rossen: I think on our side we'd be in favor.
  iank: I think there's an e-mail on blink dev saying we will, but
        I'm not sure.
  smfr: I think I talked to someone at SF F2F and we agreed.
  iank: Yeah. We've got intent to implement force flattening of
        elements with opacity < 1
  Rossen: So you're okay with this iank?
  iank: Yes I think so unless I'm misunderstanding.
  TabAtkins: I don't think you are. I think we support it.

  Rossen: So objections? smfr exact wording?
  smfr: Any value of opacity less than one forces transform styles
        to be flat.
  Rossen: Objections to that?

  RESOLVED: Any value of opacity less than one forces transform
            styles to be flat

OK to have fragment-only URLs always refer to the host document?

  <Rossen> https://github.com/w3c/csswg-drafts/issues/165
  TabAtkins: At the F2F after a long talk we did a special thing for
             fragment only URLs and I realized as I wrote it we
             could do better on a fragment only URL in an external
             stylesheet. Right now they're resolved relative to the
             stylesheet itself. CSS doesn't have fragment semantics,
  TabAtkins: It would be useful to be able to refer to local
             resources in the page and move the CSS to an external
             style sheet. I tentatively added that fragment only
             also refer to a local reference in the document.
  <fremy> @TabAtkins: lgtm
  fantasai: I strongly disagree. We talked in the past about adding
            a separate functional notation to let you reference URLs
            relative tot he document. I don't think the base url
            should change based on if it's a fragment.
  <plinss> +100
  glazou: I agree with fantasai
  TabAtkins: Okay. I'll try and do the local document URL when I try
             and write this
  Rossen: Okay, thank you TabAtkins

@else rule

  <Rossen> https://github.com/w3c/csswg-drafts/issues/112
  TabAtkins: This was also from the F2F. In a discussion about the
             unknown semantics it's frustrating to write a negated
             semantic of a MQ where we don't over-exclude but
             exclude enough.
  TabAtkins: dbaron mentioned doing @else and I wrote it up. We add
             an @else that has to follow a conditional rule. Only
             one @else can be true, whichever is true first wins. In
             order to handle additional queries I have a combined
             syntax that requires everything to be in a function,
             not alone.
  TabAtkins: Because you have the @else ability I added a
             generalized conditional rule to let you start the
             chain, @when.
  Florian: And @when isn't @if because @if was taken.
  TabAtkins: I'd rather not stomp on @if. And also @if can feed
             imperative but @when matches the imperative.
  TabAtkins: So how serious are people on this? We can put it into
             conditional rules.
  fantasai: Level 4.

  glazou: TabAtkins, I understand where this comes from and in
          theory I'm in favor. In practice dealing with MQ is
          already hell in my editor. My app was supposed to deal
          with arbitrary MQ and adding an @else inside MQ will
          complexify that. It will be easier for authors, but more
          complex for tools. I want you to understand it's already
          hell to manage MQ.
  TabAtkins: This is a separate rule following a MQ
  glazou: But it's negating the thing. You have to find the host and
          if it's an @else you have to climb up the tree and find
          the MQ and negate it yourself.
  TabAtkins: You look at the previous rule in the OM.
  glazou: It's already complicated and this is another level. If we
          deal a little with editors in this WG, I'm not sure this
          is worth the complexity.
  Florian: There's problems with writing not something. It's
           repeating yourself, very often people have complex MQ.
  glazou: We repeat ourselves all the time in CSS.
  <TabAtkins> (Check the example at the end of
              to see how complex doing three mutually-exclusive
              queries can be.)
  Florian: negating is not an edge case. Writing a complex MQ and
           negation is okay-ish, but maintining it is hell.
  <fantasai> florian++
  <zcorpan> @else can have a pointer to the object it's else-ing in
            the OM
  <astearns> +1 to @zcorpan's suggestion
  <TabAtkins> Yeah, that sounds good. I haven't specced the
              interface yet, but I'd be v happy to do that.
  <TabAtkins> (I really need to fix the bugs in the CSS highlighting

  [Missed question about doing an @elseif]
  TabAtkins: I thought it didn't make a lot of sense to introduce a
             elseif name for the intermediate rules.
  TabAtkins: I think it's simple to use @else for all the chaining.
  Rossen: And if you have an identical @else?
  TabAtkins: It evaluates in order and the first one to be true is
             normal and anything following is false.
  Rossen: It seems like a safe assertion for now, but it doesn't
          seem like it would stick. For the same reasons you gave
          for an @else they'll want this evaluated.
  Rossen: If you have an @else that's the same people will be
          surprised it doesn't evaluate.
  TabAtkins: Maybe, but if they do it once and see it's more like
             conditional chains in every other programming language.
  Rossen: I'm not disagreeing with that.
  <ChrisL> Yeah it is an easily transferrable knowledge. if then
  TabAtkins: You can just apply your programming 101 knowledge.
  plinss: If the following @else are evaluated independently it's
          just a @when and you should use @when. @else means
  plinss: I don't see why it would be evaluated.
  TabAtkins: I can see the possibility that someone who has never
             done programming would be confused for five minutes.
             Anyone that has done programming should get this
  plinss: Anyone that can parse English should get this.

  Rossen: I'm hearing one not strong pushback from glazou and a
          bunch of people feeling warm. Do we want more air time?
  TabAtkins: I'm happy to ask for it, but I'd like more feedback
             from dbaron since he's the editor of conditional rules.
  * fantasai would also like to hear from dbaron
  Rossen: Since he's not here for the next two weeks we can do a
          tentative resolution and let him respond.

  Florian: I'm in favor of this, but one thing worth noting I think
           this is a good idea but it's going to be a while before
           authors can use it because you have to wait until all
           browsers support it.
  Florian: So it's going to be a while.
  TabAtkins: It won't help until 5 years down the line when older
             browsers die out.

  Rossen: Anything else to add or move to resolution?
  TabAtkins: We can move.
  Rossen: Objections to add @else to conditionals pending review by
  TabAtkins: Next level of conditionals.

  RESOLVED: Add @else to the next level of conditionals pending
            review by dbaron.

  Rossen: We're at the end of our agenda. Unless anyone has
          something to bring to the table we can conclude.
  fantasai: If anyone plans to review Grid and hasn't, please do
            that. We're going to wrap up edits this week and ask for
            CR by end of the month.
  Rossen: Thanks fantasai.
  Rossen: Sounds like everyone gets 12 minutes and we'll chat next
  Rossen: Please look at charter licensing and dates.