W3C home > Mailing lists > Public > public-houdini@w3.org > October 2015

Minutes Paris F2F 2015-08-25 Part III: Properties and Values, Generalized Cascading Sheets

From: Dael Jackson <daelcss@gmail.com>
Date: Fri, 16 Oct 2015 19:38:43 -0400
Message-ID: <CADhPm3v7We+xpaS3sRBoWcGYM=MTeQVhDXuEjfkk1m2RW48baQ@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Friday, 16 October 2015 23:39:43 UTC