[CSSWG] Minutes Telecon 2016-06-01 [css-animations] [css-scoping] [css-values]

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-01 [css-animations] [css-scoping] [css-values]

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.

Consider accepting string as animation name

  - RESOLVED: Accept strings as animation-names

Scoped attribute on style element removed from HTML

  - RESOLVED: Move fragment styling and @scope to a delta level 4 of
              scoping module.

Logical equivalents for vw/vh units

  - RESOLVED: Add vi and vb to values & units 4.

Naming logical values for the float and clear properties

  - Florian and TabAtkins were actioned with reviewing the naming
      proposals for discussion on next week's call.

Improving use of github issues

  - Issues won't be closed until a decision is reach or the working
      group resolves on them.
  - TabAtkins will add pre-pending the spec name as a part of the
      issues template.
  - TabAtkins will propose an etiquette of contributing guide to
      include in the issues template on the mailing list for approval.
  - RESOLVED: Add the labels listed here:


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

  Rachel Andrew
  Rossen Atanassov
  Tab Atkins
  David Baron
  Bert Bos
  Tantek Çelik
  Dave Cramer
  Elika Etemad
  Daniel Glazman
  Tony Graham
  Dael Jackson
  Ian Kilpatrick
  Edward O'Connor
  Anton Prowse
  François Remy
  Florian Rivoal
  Alan Stearns
  Ian Vollick
  Greg Whitworth

  Alex Critchfield
  Chris Lilley
  Myles Maxfield
  Jen Simmons
  Steve Zilles

Scribe: dael

Consider accepting string as animation name

  astearns: Do we have a TabAtkins or a fantasai?
  astearns: It is 5 after. Given that TabAtkins replied to the
            agenda as to why they were tagged with agenda+ in
            github, I'm assuming all these were bits TabAtkins wanted.

  <astearns> https://github.com/w3c/csswg-drafts/issues/118
  astearns: Is there anyone on the call with an opinion?
  ??: It's probably fine
  Florian: Why do we want it? I missed a bit of context.
  astearns: I'm reading from the issue. "I guess it's not a bad
            idea, we've seen it in the wild. It's supported for
            prefixed in blink but not unprefixed"
  Florian: In general we try and stick with identifiers as strings
           when they come from outside CSS. So in general we
           shouldn't have strings, but if there's backwards
  glazou: I agree with Florian. Here we're naming an object in CSS
          and we don't allow strings there.

  TabAtkins: I'm here and can give reasoning. The big nice thing
             about doing strings here is the animation shorthand was
             defined badly and animation names are ambiguous with
             other keywords. When we add a new keyword existing
             working animations may fail to parse correctly. Strings
             make that unambiguous. It goes against our general
             principles, but custom-ident lives in an in-between
  TabAtkins: String, while slightly weird, does give authors a more
             stable interface.
  astearns: The problem of introducing keywords that break existing
            sites is only accommodated if existing sites are using
  TabAtkins: The hope is we can evangelize using strings and it
             would reduce the sites we could break. It's thresholds,
             not 0 vs not-0.
  Florian: It's a bit ugly, but there's a reason. Okay, maybe.
  TabAtkins: I wouldn't do this for any future custom idents. We can
             do it correctly in the future.

  glazou: As an editor it's weird in 2 ways. It's inconsistent with
          other idents. I'm also scared by having leading or
          trailing spaces. That will catch up editors, especially
          with a complex UI.
  TabAtkins: You have have leading spaces in custom idents.
  glazou: I'm not saying it's a problem to have it, it's a problem
          to work with them. When you see a whitespace and want to
          copy you may make a mistake.
  TabAtkins: That's true of all..
  <fantasai> Do we really expect this to be a problem? It's not
             perfect, and maybe we could've done something
             differently in the past, but is it worth changing the
             syntax here?
  glazou: [missed some due to bad connection] Strings are so much
          more than idents it's opening Pandora's box.
  TabAtkins: But we have several strings and that's never been
             brought up as a reason to avoid strings.
  Florian: I can see the UI challenge.

  * fantasai wonders what dbaron thinks
  <dbaron> I'm in favor of allowing strings here.

  <glazou> am I correct we have that proposal because a version of
           chrome introduced strings there ?
  <TabAtkins> no. this is a "feature" of the original webkit
              implementation (pre-fork, so Chrome inherited it as
  <glazou> ok thanks
  <glazou> TabAtkins do you have stats about usage of strings as
           animation name?
  <TabAtkins> no stats, no

  Florian: I'm somewhere halfway between TabAtkins and glazou. I see
           the UI challenge, but as TabAtkins is saying, what's new.
           We have strings as identifier when it comes from
           somewhere else.
  Florian: Yes, this is annoying, but we have this problem.
  TabAtkins: We have an ident string ambiguity in font family names.
             You can have either one there and whatever you present
             in the editor you can have.
  Florian: For glazou's other question about Chrome doing something
           silly, that's part of the reason. The bigger part is we
           designed the grammar poorly and strings makes it

  <Bert> q+ to ask if @keyframe foo === @keyframe "foo"
  <TabAtkins> Bert: Yes.

  astearns: It sounds like 3 engines are in favor of allowing
            strings. Opinions from Edge?
  <glazou> I don't like it but no objection
  fremy: It's a good chance I'm in favor.
  astearns: I think that's a fair consensus to do it. Does anyone
            actually object to allowing strings?
  Rossen: I was talking on mute.
  Rossen: I have to re-evaluate before we have a final answer, but I
          don't see a reason to block. I don't have as strong as an
          opinion as glazou. I'm not sure if he's there.
  astearns: He's been typing in IRC because sound problems.

  astearns: Bert is the IRC answer sufficient?
  Bert: I think it's correctly answered and that's the answer I
        hoped for.

  astearns: Objections to making this change?
  fantasai: If we were starting from scratch I'd be against this
            change, but since we have implementations I don't mind.
  TabAtkins: Starting from scratch we would have required animation
             name to come first in the animation shorthand, avoiding
             the problem.

  RESOLVED: Accept strings as animation-names

Scoped attribute on style element removed from HTML

  <astearns> https://github.com/w3c/csswg-drafts/issues/137
  TabAtkins: The scope attribute on the style element was removed
             from HTML because only one browser implemented and no
             one else had interest.
  TabAtkins: Parallel to that, fantasai and I wrote @scope rule.
             Since the feature is low value for HTML I propose we
             drop from scoping spec as well.
  tantek: I thought the problem was back compat.
  TabAtkins: I don't recall that, but I don't have a good memory of
             the past.
  <dbaron> I don't understand what the compat problem is.
  tantek: I have an e-mail from you saying that. I think that means
          that that's why it didn't take off in other browsers.
          @scope is brand new and doesn't have a compat problem so I
          would give @scope more of a chance.
  TabAtkins: Can you link me that?

  tantek: Is there a reason to drop @scope from scoping at this
  TabAtkins: It should be advancing soon because it has the current
             definition of shadowDOM. So I'll be pushing it soon.
             @scope was because HTML dropped it.

  fantasai: What tantek says is fair and @scope is easier to use and
            use frequently. So the usage pattern would be different.
            For now with no browser interest it's worth pushing to
            the next level. It may be worth revisiting in the
            future, either @scope or something to offer more control
            over the cascade.
  fantasai: Scoping to elements and using the nesting or doing
            scoping of the rule would be useful for authors. So
            these are my more general rules and these are my
            specific rules so it would cascade at the scope level.
            Those things I'd like to pursue, but the current level
            should just be the shadowDOM.
  fantasai: I wouldn't drop it completely, it's worth looking into.
  tantek: Would you be willing to mark it as at-risk so you could
          drop at CR with no problems?
  TabAtkins: It would be acceptable, but I'd rather punt to lvl 4.
  fantasai: tantek's point is reasonable.
  fantasai: I think it's fine either way.

  tantek: It's a syntax issue?
  fantasai: The part in the module is mostly syntax, yes. How scopes
            are calculated in the cascade is in cascading.
  tantek: I don't feel strongly. This is a gentle request to leave
          it in. I think it is useful and there are use cases. I can
          point to a few examples of bloggers doing it on their
          sites. I've seen it on custom post settings. So it's page
          level for the post perma-link, but shows up on their home
          page where they scope it to just that post.
  tantek: It's non-0, though maybe too small.
  TabAtkins: I agree. I made this from lack of impl interest on a
             parallel feature.
  tantek: I could file it on Mozilla to check interest.
  TabAtkins: So proposal: I punt fragment styling and @scope to a
             delta level 4 of scoping module.
  astearns: So it would indicate interest but not we're waiting on
            impl interest. And what's left has been impl and could
  TabAtkins: Yeah.
  astearns: Objections?
  <tantek> Thanks for consideration TabAtkins

  RESOLVED: Punt fragment styling and @scope to a delta level 4 of
            scoping module.

Logical equivalents for vw/vh units

  <astearns> https://github.com/w3c/csswg-drafts/issues/113
  TabAtkins: I think Xidorn brought up there are use cases for using
             viewport units in a logical axis way.
  TabAtkins: He proposed vi and vb for the units.
  TabAtkins: It sounds reasonable, but I leave it to the group.
  fantasai: I'm in favor.
  astearns: Anyone interested in implementing? Does Xidorn want to
            work on it?
  TabAtkins: I suppose?
  fantasai: This is V&U 4 which we haven't even finished drafting.
  Florian: If the use case sticks remains to be seen, but it makes
  astearns: Anyone opposed to adding this idea to a future draft?
  * fantasai hasn't forked V&U 4 yet, is waiting for the calc()
             serialization section to get properly reviewed before
             republishing and then forking

  RESOLVED: Add vi and vb to values & units 4

Naming logical Values for the float and clear properties

  dbaron: Speaking of logical keywords, it would be useful to get
          agreement on the keywords for float and clear. If it's
          inline-start and inline-end or...?
  Rossen: Our impl treats them as logical and the vertical. So
          orthogonal flows you don't have the problem of floats
  Florian: Tricky part was extension of page floats. We should
           resolve on this and there's a lot of context I need to
           load into my brain.
  Rossen: I think what you're saying is mostly to positioned items.
          It's mostly boundaries which is the page floats example.
  Rossen: If you have floats scoped to BFC you don't have a problem
          with float-left or -right being ambiguous across different
          writing modes.
  Florian: The problem is if float-start and -end should be renamed
           to inline-start and -end to remove ambiguity.
  dbaron: That's the issue.
  dbaron: That is noted as an issue in the spec. We'd like to ship
          and given there's an issue in the spec with the name
          there's a problem.
  <dbaron> the issue in the spec is at

  ACTION Florian look into naming of float-start and -end for next
  <trackbot> Created ACTION-777
  ACTION TabAtkins look into naming of float-start and -end for next
  <trackbot> Created ACTION-778

  TabAtkins: So revisit this next week for a definite answer.
  Florian: I think so.

  astearns: I didn't ask for additional items at beginning of the
            call. We have time if you have additional items

Improving use of github issues

  astearns: The items I put on the agenda this week were tagged as
            such on github. That was really helpful. It would be
            more helpful if you tag it and add the reason/what you
            want to talk about on the call. Any other suggestions on
            better use of github issues?
  TabAtkins: I'm going to look into some issue management so we can
             do some better organization. The issues list straight
             up looking at it isn't a ton better than the ML. It's
             not easy to get into. I'm going to see if I can get
             something together to let people focus on individual
             specs more easily.

  fantasai: There's was a discussion about closing issues and I feel
            strongly that we shouldn't close until the edits are done.
  Florian: Right. Or we resolve to close it. But if it's not resolve
           or not in the spec it shouldn't be closed.
  <tantek> +1 to keeping issues open until resolution done (edits
           done ok too)

  astearns: And fantasai you mentioned it's still useful to have the
            spec pre-pended to the issues. Since we have a giant
            repo it's useful to see the tag or have it in the name.
            So I do prefer that.
  fantasai: And I need tags to filter my e-mail.
  fantasai: That way people who file issues without permissions can
  <dbaron> Ideally we could auto-tag issues based on the spec URLs
           cited in the issue, and auto-complain in issues that
           don't have a URL pointing to the spec :-)
  TabAtkins: a) I did fix our spec snippit so it refers to github
             and instructs to have the spec shorthand. We can use an
             issue template in github so it will show with a header
             that has css-foo in it so people remember.
  astearns: Sounds good.
  Florian: It does
  <TabAtkins> issue templates:
  <TabAtkins> I'll add one to the repo today

  astearns: dbaron also mentioned auto-complaining about issues
            where a spec doesn't have issues pointing to it. I don't
            think many do. Is that a problem?
  astearns: It's easier if you link to the spec section, but often
            e-mails on the list don't have URLs.
  dbaron: I think it's more useful with a URL. If we had a bot to
          auto-add the tags it could do so on the URL.
  fantasai: Not all issues have a URL. Some are more general or have
            an un-addressed use case. There's a lot of issues where
            the URL would be the whole spec or more general.
  TabAtkins: We can have a bot where if there's a spec link, auto
             tag. If there's a tag and no spec you can auto add the
             spec. These are all possible and not hard. And fun for

  Florian: Can we have a short dos and don'ts for when people file
           issues? A memo up above an issues with instructions?
  TabAtkins: I'm writing an issue template. It's stuff that's
             pre-filled on title or content. We can add a
             contributing guide that has the etiquette. We should
             also have an official code of conduct if W3C has it. Or
             add it.
  Florian: I think W3C has one but it's mostly IP.
  <fantasai> Here's the one for www-style -
  TabAtkins: I'll come up with something on the ML
  dauwhe: Can this be on the main read me of the repo?
  TabAtkins: Sure.
  Florian: And it will be easier to moderate if we had a guide. Like
           where TabAtkins didn't like all the +1 and if we had a
           guide saying don't do that I think we could remove them.
  * fantasai thought Florian said that Tab just removed all the +1,
             and Florian would be more comfortable doing that if
             there was a rule that said don't do that.

  tantek: I think I agree with a lot of the comments. One thing I've
          observed watching this group is we've evolved the use of
          the email list in a way that's been more structured than
          other groups. It doesn't surprise me that the switch to
          github didn't add much on browsing, but that's because we
          were already good. It will hopefully be easier for new
  tantek: One thing is the social web WG has been using github from
          day 1 and we've been taking things from commentary to CR.
          We've had a minimal set of labels that I'll share.
  <tantek> https://github.com/sandhawke/spec-labels-min/labels?sort=name-asc
  tantek: This came from proposal, iteration, and in person
          discussion. It's been working for us, so I'm giving it as
          a starting point. Take it into consideration, if we need
          to modify that's fine, but this starting point is useful.
          Especially if we work towards a common set across WGs.
  Florian: Thanks.
  tantek: So we're actively using this to transition documents.
  fantasai: Labels look good. I think "needs group input" is our
  tantek: Yeah. I think we tried to word by state rather than the
          action in the semantics.
  Florian: I think "needs group input" is a bit different than
           agenda+. Agenda+ means lets talk this week.
  tantek: It's also used as a way for the editor to say I can't
          decide on this on my own.
  <tantek> https://www.w3.org/wiki/Issue_labels
  tantek: Additional background ^
  tantek: This came from a much larger list.
  astearns: I'd be up for adding these labels as-is and try them out.
  TabAtkins: Yep.
  astearns: Let's do it.

  RESOLVED: Add the labels listed here:

  Florian: Labels are flat. We can't separate those labels from spec
           labels, right?
  TabAtkins: We don't. All the spec labels start with css- but
             that's it.
  fantasai: Except MQ.
  fantasai: We may want a common prefix.
  astearns: <snark>label management</snark>
  tantek: We tried to put label management in the colors.
  Florian: It shows.

  astearns: Any other github issue ideas?
  astearns: Any other topics, or is this a short call?
  astearns: Thanks everybody.

  <tantek> more context around Social Web WG's use of Github Issues: