W3C home > Mailing lists > Public > www-style@w3.org > September 2015

[CSSWG] Minutes Paris F2F 2015-08-25 Part IV: Snapshot 2015 and Prefix Policy, @apply rule [css-2015]

From: Dael Jackson <daelcss@gmail.com>
Date: Fri, 4 Sep 2015 17:28:54 -0400
Message-ID: <CADhPm3sjvZfzFNpGG2n2YNcLg9mO2C00HPwfrCH0+g1qRXrhMg@mail.gmail.com>
To: www-style@w3.org
Snapshot 2015 and Prefix Policy
-------------------------------

  - fantasai explained the approach to the snapshot as containing
      specs that are in CR and have well-tested implementations as
      a way to distinguish further the status of the various specs.
  - There was general agreement that the previous resolution for
      which specs should be in the snapshot was correct and that
      transitions, animations and flexbox should be in as
      implemented, but not yet stable.
  - There was no agreement to adopt the prefixing policy section,
      but as people seemed to generally agree on what it needs
      to say, interested members will work on wording and return
      with an updated proposal.

@apply rule
-----------

  - TabAtkins brought his proposal for an @apply rule to the group,
      available here: http://tabatkins.github.io/specs/css-apply-rule/
  - The overall reception was positive, but there were concerns
      about the feasibility of certain behaviors due to how style
      resolution works.
      TabAtkins will work on solving those problems before he brings
      the proposal back to the group.

===== FULL MINUTES BELOW ======

  scribe: dael

Snapshot 2015 and Prefix Policy
===============================

Snapshot Contents
-----------------

  <fantasai> https://drafts.csswg.org/css-2015/#css
  TabAtkins: There's a question of what criteria do we use to
             include in the snapshot. Things in CR, things widely
             implemented? I think the latter is more useful to
             authors.
  fantasai: The original purpose of the snapshot is we had a bunch
            of specs in CR and a bunch that were but kinda weren't,
            but the W3C statuses didn't mean a lot. We're a lot
            better at not having things in CR that shouldn't be. But
            we also have some things in WD that are a bit behind.

  fantasai: The previous snapshot was things in CR and had been in
            CR long enough that we were sure things weren't going to
            change much.
  fantasai: So we had implementation experience throughout all the
            tests. We could see all of it being implemented and most
            issues being shaken out. We knew all the parts had been
            tested and implemented to some extent. But there were
            still bugs that blocked moving to PR.
  fantasai: So we agreed those spec weren't wrong and would remain
            pretty stable, and therefore put them in the Snapshot
            to represent that stability.
 fantasai:  E.g. when Flexbox hit CR, it wouldn't have been in the
            snapshot because we didn't have experience with it yet.
            At this point, flexbox is really stabilizing and in the
            next 6 months we would be able to say its pretty stable
            and won't have many changes.
  fantasai: I think that's a useful delimiter. To get into PR and
            REC you have to have two passes of everything and a lot
            of the time we're waiting on bug fixes. A spec can be
            almost as stable as REC, but just not quite there. The
            snapshot is to break the CR into two different pieces.
  fantasai: It's kind of like when we have WD where it's exploratory
            and things lock down toward the end and that's not
            reflected in W3C process. I think that's a useful
            distinction in the snapshot and we should maintain that.
            We could alternatively include more and have all the
            specs in CR and the stuff that's stable.
  TabAtkins: Sure. Okay. Seems reasonable.

  Florian: We've also suggested that the intro of what CSS is would
           fit in the snapshot well.
  fantasai: I think that's a great idea and we shouldn't work on it
            right now.
  Florian: And CSS 2.1 hasn't been completely replaced.

  fantasai: We've incorporated all the property indexes. We split
            down the list and put a short description of what are
            all these specs.
  TabAtkins: If you were to look chapter 4 is an index of all the
             terms we've included.
  fantasai: And it maps all the things in 2.1 that have been
            replaced. That's what's in the snapshot right now.

  fantasai: So questions for the group:
  fantasai: One is transitions and animations. How far are the edits
            behind the resolutions?
  dbaron: Animations is a bit behind. Transitions I don't think
          there's resolutions, it's just going through e-mail
          backlog.
  fantasai: Should we publish an update to transitions?
  dbaron: We have a resolution to publish a CR, but I have to do a
          DoC first.
  dbaron: I don't know that that much has been updated from the last
          draft.
  fantasai: What about transforms?
  dbaron: There were a bunch of preserve-3d changes that need to be
          edited in. They're still scary in terms of web compat. I
          think there's some other issues with the spec not
          explaining it well.

  fantasai: So what I think would be a good idea, we did resolve on
            a list of things to add to the snapshot, but I would rec
            that we put transitions, animations and flexbox into the
            snapshot as things that are impl widely, but not quite
            stable yet.
  TabAtkins: Can we just base it on the work status of the spec?
             That would auto-update the snapshot. We'd have to make
             sure work statuses are used correctly.
  fantasai: I think we could, but the text we're using and the order
            is significant, so we couldn't auto-generate right now.
            Maybe for next year?
  TabAtkins: We could do it now.
  fantasai: I don't want to deal with all this text that needs to
            stay in. I'd like transitions, animations, transforms,
            and flexbox into a section of snapshot that's marked as
            not stable.
  dbaron: I'm not convinced it needs to be stable.
  TabAtkins: The web is depending on it.
  fantasai: But the spec isn't synced to the web yet.

  hober: Should the specs be in, yes. How you organize it I don't
         think we need to talk about.
  dbaron: If you create more categories, there's more categories for
          us to argue about what goes into them so we're better off
          not creating more.
  fantasai: I just feel that if we put them in as-is, it's just
            here's bunch of stuff that you can use as is. The job of
            this thing is to tell you what's stable.
  hober: I hear you saying we organize this in a way to make it
         useful. Sure.
  dbaron: At the level the snapshot audience is going to look at it,
          it's fine.
  fantasai: There's a variety of audiences. There's Japanese market
            and digipub market and they're going to look at it
            differently than a Web author would.
  fantasai: The snapshot is for us to communicate with other people
            in the industry.

  skk: Is the writing-mode in this document?
  fantasai: Not yet. Hopefully writing-mode and flexbox will be
            stable by the end of the year.
  Florian: So writing-mode is not yet, but soon.
  skk: OKay. That one is important for me.

  fantasai: That's most of the issues other than prefixing.
  Florian: While we're talking about stability, different
           communities care about different levels. Japan's industry
           and publishing want things that have a big stamp that
           says it's ready.
  fantasai: I think the snapshot level is what they want to be
            looking at. I think for them the distinction we had
            in the 2007 and 2010 snapshots is a useful one.

Prefixing Policy
----------------

  <fantasai> https://drafts.csswg.org/css-2015/#experimental
  fantasai: So, implementation of unstable and priority features.
  TabAtkins: Prefixing policy.

  TabAtkins: I believe gregwhitworth had some objections to the text
             in the prefixing policy.
  gregwhitworth: Objection is a strong word, but yes I sent some.
  <Florian> https://lists.w3.org/Archives/Public/www-style/2015Jul/0447.html
  gregwhitworth: I believe someone, I think hober or SimonSapin,
                 shared the concerns that CSS shouldn't get into how
                 or where people ship things. I think we should
                 leave it out and that we just ultimately don't want
                 prefixes. I think the TAG needs to be a part of
                 this. I think it should be up to the UA on how they
                 handle shipping things. If it's reg keys or no
                 matter the mechanism.

  Florian: I think you are correct that the issue isn't CSS
           specific, but I think the solution might be language
           specific. To the extent that the previous policy is being
           replaced, giving it the same title makes sense.
  gregwhitworth: And that's what I said. I do understand that. Just
                 try and make it as broad as possible.

  Florian: I don't think anyone here has the delusion that the W3C
           can boss around browsers. It is useful to document what,
           as of today, the WG and browser community feels is the
           best policy to release things. There will be exceptions,
           there will have to be, but it's important to say.
  Florian: Getting this wrong, as we've done it in the past,
           significantly hampers our ability to do things in the
           future. The best way to release a work in progress is
           worthwhile to document. If you do it the way we describe
           but sometimes for business reasons you can't, that is
           life.
  hober: I think I agree/disagree with both of you.
  hober: I basically agree with Florian's intent. We shouldn't
         characterize contingent facts of one browser's
         implementation policy as the best practice. I preferred
         gregwhitworth's wording. It allows heterogeneous release.
  hober: In the current snaposhot, 3.3.1 [reads the draft]
  hober: This assumes there's such a thing as a non-release build.
  Florian: The wording might not be great, but if unfinished
           products are exposed finding a term to cover that, sure.
           The wording in gregwhitworth's mail is too vague, saying
           that authors should only be allowed to experiment with
           those. What does that mean? Is that what we've been doing
           and users are a part of the experiment?

  <Ms2ger> As long as we make it clear that shipping prefixed
           properties is bad
  <dbaron> I think there's an important piece missing in
           gregwhitworth's email.Things that are shipped should also
           come along with the ability for others to implement them,
           which includes specifications that are good enough for
           other implementors for implement from.

  gregwhitworth: So let's say we have a feature that we think is
                 great. We do a prefix, it's behind the flag, but we
                 give you a key and it lets us turn it on for 10% of
                 your users. That gives us live data and it doesn't
                 handcuff us for years.
  gregwhitworth: I don't think you should constrict it. I only
                 stress this because we're trying to do responsible
                 work. I don't think anyone disagrees with the goal,
                 but we carry the burden of you're not using the
                 spec. If I want to opt-in to a solution that should
                 be possible.
  TabAtkins: If you have a good reason not to follow spec, you can.

  fantasai: We have two problems with prefixing. One is if you don't
            support that prefixed property and the author assumes
            everybody is webkit, the site breaks. Second is that we
            lock people in because it's on production websites that
            aren't updating.
  gregwhitworth: The example I gave is contract based...it's
                 something we spit-balled in TPAC. We won't have a
                 one size fits all solution. Instead of constraining
                 it, we should be more open. Have a note saying
                 please don't prefix.
  ojan: What you're both saying is shipping vendor prefixes ends up
        shipping a feature. If the CSS spec should be weighing in on
        that is a separate question.

  Florian: People started shipping prefixes because we said that,
           but the previous suggestion was bad.
  gregwhitworth: So remove the prefix suggestion.

  dbaron: I wrote this in IRC a few minutes ago, but I think it's
          important that if you do ship something you provide what's
          necessary to let others ship that too. In some cases
          that's a spec that you bring to the WG to say here's the
          thing we shipped.
  gregwhitworth: I'm not seeing how my statement disagrees.
  dbaron: It doesn't, it's just something that should also be said.
  gregwhitworth: Okay, I agree.
  Florian: And if you ship something with your name on it, we all
           feel bad when we have to implement properties that have
           the word webkit in it.
  gregwhitworth: I think we agree, I'm just saying don't constrain
                 as much as this. You say release vehicle and I
                 can't guarantee that there will be.
  fantasai: We don't want to release things that are unstable and
            non-standard for production use and we don't want to
            release it in a general way until it's stable.
  fantasai: So maybe the wording change is "should not be released
            for production use"
  gregwhitworth: current-color is an example of where we'd violate
                 the spec but it worked in our case.

  fantasai: This is for use on the web, that's the key here.
  Florian: That's a distinction we're trying to do. Yes, CSS is also
           used on not-web and it's also in that case useful to have
           some guidelines indicating the best way to do this. If
           you're going to do something not exposed to the web and
           you release something, you might be dumb. Prefixes are
           great in a non-web space.
  Florian: Things not built for web content would be things that are
           good not to be able to be used on the web. Maybe later
           you want that on purpose.
  Florian: Trying to phrase around web and non-web is difficult.
  SteveZ: I don't understand the web distinction. If I'm writing
          tutorials I can put anything on the web.
  fantasai: What we mean is for use in an environment where you'll
            be interoperating with other CSS implementations.
  TabAtkins: We mean in a browser.
  fantasai: Not just that.
  Florian: So if you add a CSS property for specifically Firefox's
           UI, it's not from a HTTP server.
  SteveZ: So when MS Word started putting out its stuff, it added a
          property for use in Word, but they could be in the web.
  TabAtkins: But that's when you choose HTML.
  Florian: That's exposing to the web.

  SteveZ: You're dealing with an impossible situation. It takes
          years to standardize.
  TabAtkins: If it's not standardized you can't use it.
  SteveZ: I don't see the distinction. I want to put everything I'm
          doing on the web. I agree about not polluting the
          namespace, but you're a level beyond. I understand the
          webkit prefix policies. I also support that you ought to
          come in with a spec if you think you could standardize.
          It's unrealistic for a vendor to wait to have something
          standardized.
  TabAtkins: Then you're not publishing to the web.
  gregwhitworth: It sounds like you want 3 things. If you want to
                 publish something proprietary, bring it to us, if
                 the group says that's stupid and we have business
                 reasons to, we tried.
  Florian: The wording doesn't constrain you from that.
  hober: So he's saying he'll ship things anyway. If he does do it
         unprefixed.
  Florian: If you can't standardize, don't prefix.
  gregwhitworth: It sounds like being a good web citizen. So just
                 try and put it on standard track and go from there.

  fantasai: I changed to to recommend for best practices.
  <fantasai> gregwhitworth,
https://hg.csswg.org/drafts/diff/a8ffa9d7d989/css-2015/Overview.bs ?
  gregwhitworth: You changed the title?
  <fantasai> "To avoid clashes with future stable CSS features, the
             CSSWG recommends the following best practices for the
             implementation of unstable features and proprietary
             extensions to CSS. "
  fantasai: The first sentence. That's the only place "policy"
            appeared.
  fantasai: I only fixed the first paragraph.

  Florian: As for generally replacing the content for something more
           general it's okay, but I don't want to say be reasonable
           please.
  gregwhitworth: I want to have prefixes are bad.
  Florian: If you're writing UI specific thing that won't be sent to
           the web, do use prefixes. That's useful because they
           won't clash with anything and won't render on the web.
  gregwhitworth: It feels like we've talked about it, don't want
                 prefixes, so that's what this should say.
  gregwhitworth: Also, we want it but we can't hold anyone
                 accountable, so why write it?
  fantasai: We want to express a lot of things to people, like don't
            implement something in FPWD and never make any changes.
            We publish ideas because we want people to have better
            ideas and to help us improve before anything ships. It's
            a nightmare for authors to have all these different
            stages of non-interoperable implementation.

  Rossen: You're implying something target-able by content. If it's
          something like UA flags, all the behavior you just
          explained is implementable. I would argue early
          implementors are very useful to drive spec and clarify
          hurdles. What you're implying is that the holdback
          mechanism that was prefixes sucks. No one has argued that
          using prefixes as holdbacks sucks. Flags or experimental
          features are better and we're starting to use them.
  Rossen: Whether or not, gregwhitworth's 3rd point, during the
          early phases of development and playing with the feature
          we also want to collect user feedback. There are features
          that allow lighting up of those for random users. That's
          different and an experimental way of using holdback
          without exposing to everyone.
  TabAtkins: We agree, we should have something like that. But in
             the meantime we know prefixes are a terrible way of
             doing this.
  Florian: But we agree they're terrible, but the sentence we
           proposed you didn't like.

  fantasai: We all fundamentally agree on what we're trying to do.
  hober: People think gregwhitworth wording is underconstrained, the
         current is thought overconstrained. Let's go away and make
         edits and come back.
  Florian: Yes, but not having a wording means the current snapshot
           is 5 years old. Should we say the old policy is bad and
           please hold on a new one?
  fantasai: I think those of us interested should wordsmith this and
            come back to the group.

  Florian: The current wording was from this.
  fantasai: That was five years ago.
  Florian: So, let's do that.
  fantasai: We had flags in the five years ago.
  fantasai: We were intending for flags to be the way forward, but
            if we failed to word that in we failed.
  <fantasai> http://www.w3.org/blog/CSS/2012/08/30/resolutions-53/
  fantasai: We didn't fully resolve because we hadn't worked out
            wording yet. We're working on translation right now. I
            get the sense we agree what we're trying to do so we
            should wordsmith it and make sure we get what's in all
            our heads. If we find a real difference of opinion we
            should come back to the group.

  SteveZ: I think I now understand why I object to the use of the
          web. You're telling me it's okay to use prefixes for
          features used for implementations not intended to
          interoperate.
  Florian: I'm not sure. There has been an example of Apple adding
           something to iPhone and telling people to make websites
           with it, but then they say they don't intend it to be
           used elsewhere.
  Florian: I'm not trying to exclude these.
  SteveZ: The web is a mythical thing. I think the wording you have
          will be misinterpreted by everyone. It didn't suggest to
          me what we're trying to include.
  Florian: You can join the convoersation when we fix that.

  plinss: We should exclude content on public websites using
          prefixes.
  tantek: It should be HTTP
  plinss: But there's intranet.
  tantek: I'm saying that's the bar.
  gregwhitworth: I think we're trying to define the web.
  fantasai: I'd we're serving it over HTTP.
  plinss: If HP makes a propriety server for a client that can
          browser the web, but it can also suck down these HP
          things, who gives? It's walled off to yourself and not
          exposed.
  Florian: This is hard to wordsmith, but it's meant to be the web.
  plinss: If it's somewhere people can get to it shouldn't be using
          prefixed.
  SteveZ: I don't see why you can't have proprietary content.
  plinss: Then you have the iPhone web and the kindle web.

  <skk> CSS is only for online manner? How about for offline
        situation? (if it's not the point, sorry)
  * fantasai thinks skk has a good point, too, we need to make sure
             this policy translates to worlds like EPUB

  SteveZ: What's bothering me is this body because a gateway for
          what people can do and we don't move fast enough.
  Bert: This is for a small part of the web. Just CSS.
  <Ms2ger`> A pretty essential part
  Bert: You can make your own format, MyCustomizedCSS,
             and do whatever you want with that
  SteveZ: When we get to the Houdini meeting it gets worse, I don't
          know what you do.
  plinss: If you expect the property to work you ship the code along
          with the property and that can run one anyone's browser.
  SteveZ: There's still the standardization and namespace pollution
          issue.
  plinss: Houdini isn't the way to make a new property, it's a new
          custom property.
  SteveZ: How do I know?
  plinss: Prefix. That one prefix we've designated for that process.

  plinss: So you guys will wordsmith and come back?
  Florian: We'll try.
  <fantasai> Steve's phrase, something like "intended for an
             environment with multiple interoperable
             implementations", captures our target, I think.

  tantek: Should we document current objections?
  Florian: That's going to take too long. We'll do it over beer.

  esprehn: Can we talk about this in terms of population size
           instead of prefixing? If you ship it to enough people
           that other people have to implement it too.
  fantasai: If you're intending to send this page to an environment
            where there's multiple interop, you shouldn't prefix.
  dbaron: I don't think number of people isn't the criteria.
  gregwhitworth: I think he means impact.

  tantek: The current text talks about preventing accidental lock-in
  hober: I don't think it's the place of the WG to go too much into
         how you determine lock-in.
  tantek: I don't know how you improve the wording right now.
  fantasai: We just need to improve the first sentence.
  tantek: It doesn't sound like we're that far.

  plinss: Are we done on this?
  fantasai: For now. I think we should resolve by the end of the
            meeting.
  tantek: So you'll come back by the end of the meeting.
  fantasai: Yes.

@apply rule
===========

  <leaverou> For anyone who can't see the screen:
             http://tabatkins.github.io/specs/css-apply-rule/
  TabAtkins: So I just sent the thing and haven't e-mailed the WG,
             but it's a tiny spec.

  TabAtkins: Polymer and post-css have used variables in an
             interesting way to port chunks of style.
  * TabAtkins shows example with --tolbar-title-theme, which is set
              to one set of rules on :root, and differently on
              .warning
  TabAtkins: That is totally valid.
  TabAtkins: Polymer has things like the @apply rule that lets you
             refer to this and inlines them. This seems like a fine
             application and there's reasons to have reusable styles
             in a variable.
  TabAtkins: These seem like a nice easy application of custom
             properties. That shouldn't be too hard to work with.

  dbaron: It seems annoyingly cyclic.
  TabAtkins: No more so than var. There is an issue where if you
             define that property in there it would be cyclic.

  dbaron: I don't see how they do this with pre-processing.
  TabAtkins: It's not full fidelity. Maybe they pack it into JS.
  TabAtkins: This is the entire example.
  dbaron: It seems nice.
  TabAtkins: We do want to make sure we deal with setting variables
             in the theme used by @apply.

  SimonSapin: In variables in custom property you have a declaration
              that contains var. You don't pass it yet. It's only
              when you do all the variables that you pass it. You
              have integration of the property and that's why you
              need the cascade. For here, for @apply rule you don't
              know what property make sense. In different places in
              the tree it could have different rules.
  TabAtkins: You can't resolve until computed value time and you
             have multiple instances.

  dbaron: This would require us to do the work we decided to avoid
          doing in variables by taking the worse solution in
          cascading.
  TabAtkins: Where we did the default fallback rather than cascading
             fallback.
  TabAtkins: Yeah. We did decide that for the var function. That may
             have killed this.
  shane: Maybe there's a default fallback you can do that works.
  TabAtkins: Thank you for bringing that up. We'll see if there's
             anything we can do that's reasonable.

  shane: If we can make this work you said it looked interesting.
  dbaron: How important is it to use cascading variables rather than
          global variables?
  esprehn: Cascading variables seems counterintuitive.
  TabAtkins: We have it so you can override the them for some things.
  TabAtkins: Like that you can do with variables where you could say
             inside a toolbar it's red in error state and this
             packages it up nicely.
  shane: One of the uses that Polymer adopted, it's just like custom
         property you inherit down.
  TabAtkins: That's why it's important to use with cascade. It's
             using variables for theming and that's cumbersome with
             variables. This lets you package them up in a way that
             could obviate how you do something like shadow styling.

  esprehn: Can I use a var in @apply?
  TabAtkins: No. There's nothing naively preventing that. It has
             enough context, but it might invoke circularity. This
             is an early bound variable, it takes the value theme
             from the root element.
  esprehn: So you don't have to remix the variables.
  TabAtkins: It's just one big custom property.
  TabAtkins: Okay.
  Florian: Try and fix it, it looks useful.

  TabAtkins: Copying the defaulting of current variables might work.
             We need to have something where you need to maintain a
             shape for a style.
  Florian: Some kind of typing where each rule has the same set?
  TabAtkins: Yes.
  Florian: That seems strange and restraining.
  TabAtkins: It might be nonsense too.
  TabAtkins: Right now we can take the custom property, remove the
             opening and closing brackets, and span it out.

  * fantasai wonders when the CR of Variables is going to get
             published

  SimonSapin: If you [missed]
  TabAtkins: That might be. Maybe we can do that. It lets you do the
             theming. You're namespacing variables in a more compact
             way.
  TabAtkins: I know that will work, but let's see if we can make
             less space work.
  shane: If that will work can you specify all.
  TabAtkins: If your custom property isn't valid, you'd lose all of
             them. You'd get unset for everything.
  SimonSapin: So don't forget your specificity.
  shane: Wouldn't we be able to add another toolbar?
  TabAtkins: If your specificity is okay, yes.

  TabAtkins: Another issue, here in the CSSOM. Modifying CSS styles
             OM to allow @rules, we can't just do what I said
             because CSS grouping rule. Unless we decide that it
             doesn't matter and it's at the end, which I don't like.
             We need a different way of representing it.
  Florian: And the declaration is aligning?
  TabAtkins: Yes. We need a new way of defining. It's pretty
             trivial, but it's something we'd have to write.
  TabAtkins: It's new, it would be a CSS prop interface with a name
             and a property.
  SimonSapin: For the CSS style interface?
  TabAtkins: It doesn't expose anything for child rules so we can
             invent what we want. CSS style interface gives a bunch
             of camelface property.
  SimonSapin: Can you iterate?
  TabAtkins: I don't know...no. You shouldn't be able to because we
             don't define an iterator.
  SimonSapin: It's not a real iterator, but we should have an item.
              Will @apply rules show up there?
  TabAtkins: The ones it's applying to aren't obvious until you
             apply. The @apply rule...I would say no. There's no
             reason to expose them in that interface. You do it off
             of .cssrules or something similar names.
  SimonSapin: For get compute and all that, for the element side,
              don't you only get the declarations that are specified?
  TabAtkins: Okay. What as? I guess just property names. So there's
             DOM string there. We could maybe expose the @apply
             there.

  leaverou: If you use variables in these property sets are they
            resolved from the scope they're defined in or the scope
            they're used in?
  TabAtkins: They're just custom properties. We in the future want
             late binding vars.
  leaverou: It would be good if variables are resolved where they
            are used. @apply is already trying to give authors
            mixins, and this would even give them parameterized
            mixins.
  TabAtkins: I agree, I'm just going for the simplest form now.

  TabAtkins: Okay, sounds pretty good. We know some issues. Assuming
             we can resolve these issues are people interested?
  leaverou: Can this be nested?
  TabAtkins: Yeah.
  leaverou: I mean @apply rules inside the property set.
  TabAtkins: You can use the var itself.
  Florian: That will insert extra.
  TabAtkins: I haven't spec it, but that's the direction.

  Florian: If you have an @apply inside the custom property, it
           doesn't seem possible to make it work.
  dbaron: On the inner you'll get the value of the variable it's
          getting applied to.
  <dbaron> ... rather than the value where it was declared.
  shane: So maybe applying late would be better.
  Florian: You need to define it now to make it clear.
  TabAtkins: My current definition is bracket wrapped block of
             properties, which obviously isn't a real set.

  fantasai: When is variables getting published as CR?
  dbaron: I thought it was. Did we just resolve to publish and not
          do it?
  fantasai: Yeah.
  fantasai: Let's put this in a pipeline please.
  TabAtkins: I'll talk with Chris.
  dbaron: We shipped it on the basis of the resolution.
  fantasai: I think that's okay.
  TabAtkins: I'm not changing anything about variables.

  plinss: You can have multi @apply and they don't interact?
  TabAtkins: They cascade normally.
  TabAtkins: I should add an example of that.

  zcorpan: Can you use @apply in other @rules?
  TabAtkins: No.

  dbaron: I feel like you have previous property that did some of
          this?
  TabAtkins: A long time ago I had an @mixin that was someone
             similar, but a global rule.
  TabAtkins: You couldn't reset based on certain parts of your tree.
  shane: It's also...the same thing happened with global variables
         that people didn't like.
  dbaron: I think we have recognized that some of these things need
          to be global.
  TabAtkins: That's what custom MQ are, really. There's use cases
             for things like that.
  fantasai: You may also consider file-scope stuff. Like selector
            variables might be a good case for that. Like the chance
            of you using the same selector variable is different.

  TabAtkins: It's the same as style nesting.
  fantasai: No, there's cases like :matches(blah blah) and you want
            to use that as the child.
  TabAtkins: You can do that.
  fantasai: As a subject of the selector.
  TabAtkins: Yes. You use the placeholder symbol.
  fantasai: I think that requires you to have your styles organized
            in a particular configuration.
  fantasai: I might want to have all my sidebar rules together and
            all my article rules together and all my front page
            rules together and not organize it by what element I'm
            styling.
  TabAtkins: That's a good point.

  TabAtkins: Right now I'm doing global variables in a lot of
             context specific ways.
  TabAtkins: Okay, I'll bring this up to the WG again after fixing
             these issues.
  <leaverou> btw authors are pretty excited about the idea
             https://twitter.com/leaverou/status/636202346259836928
             (15 RTs and 9 faves in a just few minutes)

  plinss: Okay, we're adjourned for the day
Received on Friday, 4 September 2015 21:29:56 UTC

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