- From: Dael Jackson <daelcss@gmail.com>
- Date: Fri, 4 Sep 2015 17:28:54 -0400
- 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