- From: Dael Jackson <daelcss@gmail.com>
- Date: Fri, 16 Oct 2015 19:38:43 -0400
- To: public-houdini@w3.org
Properties and Values
---------------------
- The section regarding apply hooks in the Properties and Values
API spec were discussed.
- One of the problems encountered is how to address a situation
where multiple apply hooks are trying to change the same
output property.
- It was felt that limiting each property to only one apply
hook was too restricting.
- This would be run after transitions.
- It was agreed that the spec could use more examples in a few
places.
- There were significant concerns that this spec doesn't provide
enough use to authors, however many people argued that this
does provide a lot of power when combined with other tools and
is a necessary underlying step for other Houdini pieces.
- It was agreed to mark the apply hook as at-risk until the issues
can be worked through.
Generalized Cascading Sheets
----------------------------
- leaverou brought her proposal to create a generalized language
framework so more people can make languages based on the CSS
syntax.
- The group discussed what should be exposed in this generalized
language.
- The group had already agreed to expose the parser, so that
shouldn't be a problem, but the cascade seemed too
different between browsers to expose.
- Branding of how the parser is exposed would be key to making
this work. It shouldn't be the CSS parser, but instead a
parser of CSS-like things.
- The name needs to be changed since the cascade isn't part of
it.
===== FULL MINUTES BELOW ======
scribe: dael
Properties and Values
---------------------
<gregwhitworth> https://drafts.css-houdini.org/css-properties-values-api/
shane: I added this.
shane: We have an ED which is on the web. There has been some
discussion, I was wondering if we were thinking of FPWD on
this or if we need more thinking.
Rossen: Yeah.
shane: The main point is to start to explain parts of style
computation. When we put this together what we wanted to do
is come up with the minimum things we could expose to add
power. First is giving custom properties a type which let
them participate in animation. The second is if we provided
a post layout hook we could let them influence the native
properties so they can effect the changes to the visual
display
Florian: The apply hook is very useful, but to do the kind of
computed value adjustments that native properties do...it
seems to me that there may be an abuse of it since
computed time isn't when you effect layout. In some cases
you can do it, but the primary goal of this hook should
do computed value and computed time, not layout
shane: It could be a compute hook which is a single property or an
apply hook. We have examples at the style level where
properties effect other properties. This shouldn't be for
layout.
Florian: Having a computed value that works on a single property
isn't as interesting. This is important for being for
computed value time.
Florian: The single hook isn't powerful enough. We need to be able
to have a hook that works cross property, that is
important. But it shouldn't be for layout. Just because I
can influence the width of the computed value doesn't
mean it should effect layout.
shane: That's the general idea. There's lots of specifics. One
important point is these apply hooks would apply in these
described contexts, rather then the main thread. You want
the respond to relevant changes, not run at every re-layout.
You have to be specific what the hook is sensitive to.
shane: We had some ideas about how to deal with multi apply hooks
wanting to change the same output property. In CSS if you
have multiple properties that do apply to the layout, we
can reason which comes first, etc. We don't have that
ability when we open this to third party authors. The
initial design was only one apply hook could write to each
property, but that's too restricted.
shane: The advantage is you know straight away two hooks could
conflict and you can warn the author. Instead we need to do
it at the time they do conflict. But the very common case
of wanting two properties that effect the same element in
different places can work.
Florian: There's the same problem of having one hook effect a
property and another use it as a input.
shane: For this version we'd want to prevent chains. We could add
that as an advanced feature later if there's need.
Florian: I think we make sure we don't design them so we can't
chain later.
shane: We're left with pretty basic behavior, you register with a
name and a syntax string. It's just what we see in specs
right now.
heycam: You might want to use the style since the rest of the CSS
values syntax uses style.
shane: Yep.
shane: You do that, you specify if it inherits. You specify the
initial value. You get syntax error if the initial value
doesn't match the syntax or if you don't match the custom
property name production. That's registration of custom
properties. There's an unregistered.
shane: You need to specify your apply hook which is when your
custom property is set or changed on an element. It's
registered in the context, not on the main thread.
TabAtkins: The definition of changed is the same as transitions.
shane: Inputs are all computed values and would use that syntax,
as are the outputs.
shane: In terms of ordering this happens after transitions. I sent
an e-mail to the list about why.
TabAtkins: In particular, if you're using the syntax variant, not
*, but the transitionable ones, then with their syntax
information we can write transitions on custom
properties and then you want to be able to react to the
changes on the custom properties.
shane: The analysis I sent to the list is reasonably detailed.
Unless we think of other cases we need to support, this is
pretty conclusive.
TabAtkins: There are reasons to run before transitions, but
they're less useful. We might want to consider in the
future.
shane: A simple side point is you can use this to opt in or out of
inheritance and you can use this for type information so
this can be useful for properties.
heycam: I was worried a common thing with transforms, running your
apply hook every frame will force it to the main thread.
gregwhitworth: That's one of the elephants.
astearns: In the example the input property uses * notation to
grab a bunch of properties. Is it worth adding that the
input properties are *?
shane: I don't think so. This was us being lazy on the example.
TabAtkins: We have use cases for arbitrary properties with custom
names, but that's not a version 1 feature.
shane: We think this is tightly restricted. It opens new
capabilities.
ojan: This gets at what dino and smfr were getting at about what
can you do in your hook. If you look at the apply functions,
the only output is the field you put on the output style.
You can't get anything out of the worker beyond that so you
can't get something crazy out.
dino: Do I remember the previous version of the spec was a
sandwich between side by side elements?
shane: We removed that because we didn't think we could do it.
dino: Good, we didn't either.
ojan: The element passed to the apply isn't in the normal DOM
sense, it's in the style sense.
TabAtkins: It's a very restricted bag of information.
ojan: We're not adding output style to the main frame.
shane: It's an element proxy.
flackr: It doesn't include ancestors or children or a whole bunch
of things.
ojan: It only has input and output style.
shane: At some point we might add parent style.
dino: In the apply hook it says reading computed styles in element
property?
shane: That's correct. It happens after computation so it reads in
already computed values. If you have multiple apply hooks
they're running par. They don't chain. You do the
computation, you compute the apply hooks, if they don't
conflict you have a new set of values.
Florian: With that model to be able to do chaining you'd need a
different chain-able apply.
shane: I think it's important to opt-in to chain.
gregwhitworth: The author wants to chain though?
shane: The author has to be able to say it, yes.
gregwhitworth: We're hoping that 1% of authors apply this and you
give them these two libraries and apply hooks.
TabAtkins: It's like the JQuery and the $. We need to make it easy
for libraries to say never mind, here's the apply hook
I was going to use, go ahead and sequence it yourself.
Florian: This is the only concern I have on the spec.
shane: I think it's a great idea to get an example in there.
franremy: From all the specs this is the one I have the most
concerns about. The reason why is I don't see using this.
It doesn't solve any problem with a solution you can use.
You can't fix CSS Grid, I've yet to see an example
beside creating an animation.
shane: The two examples in the spec. [pulls up spec] This is a
full fidelity polyfill of translate.
shane: One example not in the spec, I want a property that lets me
lighten colors by 10%. You can do this as a property as you
wish.
shane: This spec is also an enabler of all the things we wish to
do in the future.
franremy: This doesn't go far enough in any direction to be useful.
We can't do this like short hand property.
TabAtkins: They're resolved at a much earlier stage. Handling
short hands will be in the future.
franremy: When I look at the spec every time I have a great use
case I'm told it's an extension to the spec. I'm worried
this will become the most complicated spec.
shane: There's two things missing. One will not end up the spec.
Short hands don't belong here, they should be specified.
The computed value hook should be here and isn't.
franremy: I'm afraid this is specific to one use case. You could
give me this in browsers and it doesn't solve any
problem I have.
TabAtkins: That's highly unlikely. You could polyfill most of the
property side of flexbox. That's what you need to
enable a lot of these things. We don't want you to be
forced to only get custom layout in JS. There are
limitations, but this is the most useful first place to
insert ourselves into.
shane: And it has a multiplicative effect when paired with others.
franremy: I see the point of combining with CSS painting. but if
you want to move further this isn't sufficient for
layout.
shane: You would use the layout spec.
TabAtkins: I would love an example of what this plus layout is
missing to re-implement flexbox.
franremy: You don't get shorthands and you don't get computation
rule and it's difficult for transition block.
TabAtkins: If you ignore shorthands, those are all nice single
value properties that fit into the model you have. You
should be able to transition a --flex-basis no problem
and have the layout hook take advantage of that.
TabAtkins: We can't solve everything at one.
franremy: I have the impression this spec is trying to say we
can't solve all the letters, so lets start with a, c,
and d.
shane: You can operate without shorthands, but you can't do
flexbox without this.
franremy: You say it's simple, I have a CSS polyfill for CSS grid.
We are talking about making things better so it's not
better than what exists that's not the point.
Florian: The CSS WG produces immediately useful things. This group
provides primitives.
Florian: When you don't have enough primitives, you need to have
enough to be able to combine them.
franremy: There are other ways to solve this problem that solve
other problems.
ojan: To answer smfr and dino about what do you do in an apply
hook, the equivalent code is the style adjuster in Blink.
There's code that takes the if your position: absolute makes
a block. If you add a new position-like property you want to
do that. You want to code yourself to that block if your
flexbox. It's not common for most libraries but you need it
for most use cases.
Rossen: It's needed when you're applying cascade.
johanneswilm: Can I use this if I need to invent a new property
and I have 10 stylesheets that override each other
and I want to know what this ends up at the end?
shane: There's no communication out.
johanneswilm: What say I invent something new and I have 10
stylesheets that override each other. If I apply 55
different values in different stylesheets, if I
don't want the JS to go through to figure out which
one wins, this should help me?
TabAtkins: Yes. All of that merging together happens earlier then
cascade. By the time we get to the apply hook it's done
and gone.
gregwhitworth: Can you add an issue to draw a diagram?
TabAtkins: Yeah.
dbaron: You couldn't implement a flexbox that doesn't take a
simple syntax.
TabAtkins: Yeah. Most properties are fine. If you ignore
shorthands, I think they all work.
TabAtkins: I think every non-shorthand is a single value.
ojan: It's just the flex shorthand.
dbaron: Still not being able to validate syntax that isn't those 6
things is limiting.
TabAtkins: We're limiting because their syntax is easy to create
invalid options. Our ability is to provide something
guaranteed unambiguous.
TabAtkins: In the future we might be able to provide a method to
figure out the ambiguity and we'll add that.
dbaron: You don't even allow validation of set keywords.
TabAtkins: We do. The second to last one is arbitrary items.
dbaron: What about 7 particular idents.
TabAtkins: That's what it's for. It's just like a CSS syntax
definition.
dbaron: It feels a little off to not allow code to validate.
TabAtkins: I suspect we want to do that at handle shorthand stage.
Right now the main purpose is to allow transitions to
work. Once we get shorthands we need less arbitrary
syntax.
shane: And I hope we can allow the syntax strings to take a
function.
Florian: To answer franremy's point, I think it's tempting to try
and make useful things, if we're not modeling along the
way browsers work we end up with a model that's not
exposing the internal model of the browser, but we won't
be able to expose that if we don't start there.
franremy: We cannot even provide more information that the API is
not of use. It doesn't make sense. We can provide it as
a spec, but it's not going to help most people. We can
ship something, but it's not useful.
TabAtkins: From what we can tell and the examples we've worked
through, the apply hook is rather useful for doing a
lot of things. Maybe not in an optimal way, but in a
useful way. If we're wrong and we can add more we'll
fill in the holes. That you think this level everything
is more or less useless, I think that's wrong.
franremy: I understand the point, I just don't think it's going to
add much.
dino: I agree. I think it's limited utility until we add other
specs.
TabAtkins: Oh yes. This is the maximum useful of the things and
provides a lot of power.
heycam: About the apply hook, the outputs are computed values and
ultimately you need to assign them to the output values,
what happens when you assign 12em.
shane: It would throw an error and we need to work through that.
TabAtkins: We have the information necessary to resolve.
esprehn: You're assigning more properties, we can resolve once.
TabAtkins: You take the single track at computed, you break off,
loop around, and put it back in. That's the mental
model.
heycam: If you effect, say, font-size, what happens to other
properties uninvolved in input and output?
TabAtkins: I think that's when we do the re-computation.
shane: We don't do that. It makes the font-size that was used to
determine it.
TabAtkins: By the time you hit the first computed they're pixels.
heycam: I think you have to store post- and pre-font-size.
esprehn: You have to do that already because the values that you
get...two apply hooks cannot communicate.
heycam: So you have to recompute any property with
font-size: relative if you effect the font-size.
esprehn: This seems like we should discuss further. It might be
beneficial to say you can't. We will let you resolve to a
pixel value and you do it yourself.
heycam: For the kids of properties we're already tweaking at apply
value, we want to be careful to describe what happens if
you effect one of those.
TabAtkins: We have two ideas. You think of all the fix up you do
as an apply hook that the browser sequences after
whatever the user applies. We may want it to run before
so you see the same world beforehand.
TabAtkins: The very least we need one.
dbaron: I don't think this works with our implementation. We hook
inter-property dependencies in a cached structure within
cached structures.
TabAtkins: So the canonization at computed stage happens easily
enough you have to expose those before the apply hook.
dbaron: For some.
TabAtkins: For use they can all be done later, but if we need a
list or spec that everything runs twice we can do that.
TabAtkins: If everything runs twice you're fine and it works for
us because we can do whenever. If I'm understanding
right.
dbaron: What about things like other lengths in em depending on
font size. So if you change the font size, is that saying
you'll go back and compute the lengths?
TabAtkins: That was heycam's second question and that we need to
go back and work it through. There's two options and we
can decide which one is better and performant.
ChrisL: Didn't we say this morning you don't only want things only
in pixels?
TabAtkins: This is later on. This is the middle of value
computation.
franremy: If we say you can only have pixel in the end you still
have an issue where you have custom property.
TabAtkins: Like var property? We have to work it out. It may be
the presence of var means we have to do our computation
first.
franremy: I believe the best stage is after specified value time.
TabAtkins: That doesn't let you do responded to transition.
franremy: That's not true. In a lot of cases you know which
transition will run and you can use a transition that's
already running.
Florian: This is a bit on a topic earlier: How slow can we allow
this to run if the apply hook is a DDoS that takes
forever. Can we have a provision to let the browser
fallback?
TabAtkins: If you have accidentally too slow code, maybe? We'd
have to decide what that means if you don't set any
value and it passes through unchanged. It's something
we should just pay attention to.
Florian: The problem of being too slow is common, but the solution
might be individual.
TabAtkins: I agree. There's a problem we should pay attention to
even if we just recommend UA mitigation
ojan: Two things. I view this spec similar to scripting. Its value
in itself is minimal but it's required for everything else
we're doing. It's not a spec we could integrate elsewhere,
though. Other point is I feel dbaron's point about executing
code to do validation got glossed over. I view what's in the
spec as the minimum we can ship that has most of the value.
Every script hook we add involves a lot of discussion so I
lean toward we can ship the first without script codes.
ojan: It's naturally easy to assume that you can pass one and I
think we'll add it, but I don't think the first version
needs it.
TabAtkins: We will need shorthands eventually and that ties well
into that stage.
dbaron: This weird flow here on the white board where you compute
twice, it doesn't feel like it's exposing browser
internals.
esprehn: Internal to a browser you can't...so border can't change
font-size. There's a constraint with how you repeat style.
TabAtkins: I don't know if we want to expose that. I don't want to
go through and map forever for the same reason we don't
let the var apply to normal properties, this would
require the same. I'd rather things become inconsistent
if you screw up.
heycam: I'd start to worry about the order you run things then. So
lets say you have some property not effected by apply
hooks. You've got one that effects em values and another
that will resolve.
esprehn: There's no chaining.
TabAtkins: The em have disappeared by the time you get to the
apply hook.
Florian: By the time we have chain-able we need to make sure we
can apply them. You can have a loop.
TabAtkins: Once you're chaining you're not writing into the same
data structure. Chaining would have input,
intermediate, output and each would see the
intermediate and write it. No apply hook can be writing
into the computation of a native property.
Florian: So if we wanted to expose exactly how it works it would
be exposing the engine and the code where authors tell
each other what to do. You're creating a two stage thing
that's not already there. You can't be a part of the
browser chain, you have to let that run and run your own.
TabAtkins: The alternative isn't doable.
heycam: I'm worried that introducing new native chains to CSS
would create breakages.
TabAtkins: Yeah.
TabAtkins: The browser can do arbitrary things, not because magic
powers, but because they have one apply hook.
<heycam> for example, extend an existing property with a new
length value that can be in em units
esprehn: So let's put apply hooks as at-risk. The property still
has a lot of useful pieces.
shane: If we can't get thought these issues we drop.
Rossen: Are you planning to add...I saw you're looking for FPWD.
Spec looks a little dry, quite empty. It's just ideas on
paper.
Rossen: Also I think there's need for better examples.
TabAtkins: Sure. And we need to comb through the minutes and add
the dozen or so issues.
shane: Perhaps the best thing to do is for us to do that over the
next week and send the result to the list.
TabAtkins: In the mean time, this as a ED of Houdini?
shane: It already is.
TabAtkins: Never mind.
Rossen: Is that it on this?
shane: Unless there's other questions
Generalized Cascading Sheets
----------------------------
<ChrisL> https://lists.w3.org/Archives/Public/public-houdini/2015Jul/0003.html
leaverou: In the past 15 years we've seen many languages come up
with similar syntax to CSS. Same grammar and cascading
and these can be unrelated to styling. I've included a
few examples in the e-mail.
leaverou: As you can see many are unrelated to CSS so my proposal
was to make something, this is a placeholder name,
something that lets us separate the style from the
cascading sheets and create a generalized language that
people can hook onto.
leaverou: A sort of generalized language framework so more people
can make languages based on the CSS syntax to make it
easier to show what classes and pseudos they accept. A
lot of this is being done in Houdini, but in the context
of extending CSS. It's also useful for these other
languages and right now they have to use a CSS parser
and that's not ideal.
leaverou: It would be easier for people to write tools and be
easier to define future languages, like CAS. We can also
have more interested parties working on this because
it's a language framework. Even the selectors language
would be accessible.
leaverou: I think that's the general idea, what do you guys think?
SimonSapin: To note selectors are in the CSS. Also CSS syntax spec
is fairly separate.
leaverou: This separation is happening, but it's centered around
CSS.
SimonSapin: Given that what else is needed?
leaverou: Something that defines what else is acceptable in the
language, like what @rules are acceptable. Right now
they can use a parser and it drops things that CSS
doesn't understand. They're not first class web
languages, they're leeching off the CSS.
ChrisL: We're trying to provide extensibility points and browsers
and I see this helping both. If you want to extend one
phase you should be able to do that. The thing about
discarding all the properties you know is a problem for
CSS where you don't want to discard properties you don't
understand. This is a small amount of effort to slightly
generalize the parsing API it would be useful for many
languages and reduces the pressure on this group to
standardize.
ChrisL: People come to the group and ask us to build things and
when we have this we can say no you can build them.
SimonSapin: I agree with everything you said. What steps can we
take in that direction?
<Bert> -> http://www.w3.org/Style/2014/css-charter Our charter has
since a long time presented syntax, cascading/inheritance
and rendering as three independent topics the WG can work
on.
leaverou: We should decide what the integration should be. Do
these cascade? Do they need to? How would we define the
syntax? The CSS values part of it, do we need that?
Selectors and syntax would be in GCS, but what else
would be, that's not clearly defined.
leaverou: We could discuss what the syntax would be. The way I
picture this is something with its own mime type so you
could have like text.gcs list JSONLD is LSON + LD
<ChrisL> text/sass+gcs
TabAtkins: The puzzle you have is several parts. Let's expose what
the browser does to turn characters into CSSOM. There's
parse as selectors and apply as cascade.
leaverou: Will the language have OM? We don't want them to mess
with the CSS OM. Do we give them an OM?
TabAtkins: Directly exposing the CSS parser so you don't have to
pull in a JS implementation of what the browser is
doing, probably that's reasonable. In our code if we
see something that's a selector we do some reordering
and pull something out to hand to JS. I'm not sure what
Firefox does. In so far as if you take text and you
parse it into CSS, what's the fidelity?
heycam: You lose things like universal selector.
esprehn: I think we can remove the parser manging.
leaverou: Perhaps separate languages could hook up separate code
even as a part of a GCS parser.
TabAtkins: The parser part seems reasonable. If you look at my
parse CSS I've added something about that.
leaverou: It's extensibility for authors and browsers. What if CAS
was implemented by browsers?
TabAtkins: The non generic of our CSS parser was a problem
recently when I thought we could implement CAS and now
we can't.
plinss: We agreed to expose the CSS parser.
esprehn: Exposing the parser is reasonable. The cascade isn't as
reasonable because it's not very generic.
gregwhitworth: I can see you're using the parser we expose through
the API and whatever your doc tree looks like and
you'd have your own implementation.
leaverou: If there's some way to get the specificity of a CSS
selector it would be easy to get it yourself.
TabAtkins: If we can say parse this as selector for me and
exposing the specificity directly is fine.
SimonSapin: With :matches they don't have specificity by
themselves.
leaverou: A part of this discussion is framing many things we're
doing differently for more interest. There's already
people writing their own language when they could be
using something like CSS. I've seen weird syntax that
would be better if they looked like CSS, but 'cause they
can't use generalized syntax it doesn't.
TabAtkins: Same experience here.
leaverou: And they don't look at CSS specs because they're not
doing style.
SimonSapin: Why can't they use a syntax like CSS?
Florian: They could if they fully understand it, but because they
don't they get close. If they could hook in they could.
leaverou: Imagine if Microsoft had something that's sort of like
SVG, but it's not quite the same as it. It's like trying
to describe a left by how it differs from the siblings.
<bkardell> Would it be fair to say what we are exposing is the GCS
parser and that CSS uses the GCS parser and as of today
has 0 deltas?
gregwhitworth: Let's say an author wanted to do theming based on
CSS, you're talking in a much more generic form. It
seems like you'd want the parser, not the whole
engine. I'm wondering the feasibility of this
outside embedding the entire engine.
leaverou: It's a good question as to if it's in scope for Houdini.
Most of our work is CSS API and this is a different
language. That's the first thing we should do, discuss
if this is in scope.
TabAtkins: Exposing the parser is in the charter. We need to write
it up, still.
TabAtkins: There's one part of what I've heard that we haven't
addressed and that is automatically getting a parser in
there to style type='CAS' and get CAS in there.
leaverou: Like browsers have an XML parser, I imaging it would be
similar.
Florian: Things early in the pipeline like the parser we will
expose. Things in the later stage when we're trying to
expose the primitives you're looking to expose the
general.
leaverou: Part is branding. People that aren't interested in CSS
won't care and they won't use it. This is not just a
technical thing, this is how branding works. If you
frame it as something people aren't interested in it
won't succeed.
dauwhe: I've been looking at Daniel Glazman's Simple Tree
Transform Sheets and it's very similar to something we use
to prepare comments. If someone gave me 1 million dollars
and I decided to implement that, does Houdini have what we
need? That's anther way to get to if this is a Houdini
level request.
leaverou: I've heard many CSS WG people say the future of
transformation is a CSS language. I think something like
this is around the corner.
Florian: I think there's multiple levels. Selectors aren't branded
CSS, syntax I think is. There's a difference of branding
specs and having generalized implementation of browsers.
TabAtkins: If we focus on parsing, let's do that. We have most of
the spec of that we need to just apply certain schema.
TabAtkins: Selectors are exposed in DOM.
leaverou: I imagine we'll come up with syntax of what's allowed.
Would it be possible to have parameters for cascading?
TabAtkins: Exposing the cascade would be something completely new.
The parser is exposing something we're doing. All of
our cascades are too tied into CSS specific application.
It's a matter of defining a new feature. Cascading is
easy enough and niche enough it won't pass the benefit
test.
dauwhe: I think I could do the STT thing with the existing cascade.
TabAtkins: If you're willing to use custom properties in CSS, sure.
bkardell: I don't know at this point how much I'll add...I agree
that the branding is important and maybe what we're
doing is saying that thing down there is more valuable
than just being a CSS parser given that it needs to
parse more than CSS. If we called it GCS parser and CSS
is in the family and the thing it gives you back is a
rougher thing than CSSOM is.
bkardell: As we describe these things our goal is to describe
thing in the appropriate layers. At different layers we
have extensibility points and the closer you get to
where CSS is at, at some point it's CSS.
TabAtkins: Yeah
Florian: Yeah.
<Florian> +1
bkardell: I don't know if it's helpful, but I like saying the
thing we're describing is not the CSS parser, its a
general parser of CSS-type things and trying to layer it
so it's possible to wedge most of those ideas in there
in ways that are flexible.
TabAtkins: I doubt it's useful to rename the CSS syntax spec, but
I agree conceptually. It can be framed like selectors
and MQ as language independent. We'll expose how to
parse with that.
TabAtkins: If there anything else we need to talk about?
franremy: The main thing is to have a few samples of what is GCS
and what is not. Examples of what it's a GCS-like so
people can test if their language is GCS compliant.
leaverou: We should also bikeshed the name.
Rossen: Is that it?
Rossen: We'll take a short break and then do the font stuff for
jdaggett.
<break=10-15min>
<Florian> GCS = Generalized Cascading Sheets, but we don't
actually include the cascade, so it's a bad name
<leaverou> Florian: Good point, Perhaps Generalized Declaration
Sheets? Generalized Property Sheets?
<leaverou> you could have a lang with just @rules and descriptors
<leaverou> so I'd rather if property was not in the name
<leaverou> declaration perhaps? [Generalized | eXtensible ]
Declaration Sheets?
Received on Friday, 16 October 2015 23:39:42 UTC