[CSSWG] Minutes and Resolutions San Diego F2F Tue 2012-08-14 PM II: CSS Variables

CSS Variables aka Cascading Variables
-------------------------------------

   - RESOLVED: Syntax of variables settled on var-foo and var(foo)
   - ACTION: TabAtkins, fantasai, and glazou to write blog post explaining
             why not using $
   - RESOLVED: Include fallback in Level 1
   - RESOLVED: Defer parent-var to Level 2
   - RESOLVED: Accept Variables L2 with parent-var() as work item
   - RESOLVED: Publish WD of CSS Variables providing sentence jdaggett objects
               to is removed.

   Tab Atkins: http://www.xanthir.com/blog/b4KT0
   Daniel Glazman: 
http://www.glazman.org/weblog/dotclear/index.php?post/2012/08/17/CSS-Variables%2C-why-we-drop-the-%24foo-notation

====== Full minutes below ======

Discussion of what to discuss
Tab: I can do variables in half hour!
Tab spends half an hour erasing the board.
(j/k)

CSS Variables
-------------
Scribe: fantasai

   jdaggett: We would like to not ship this prefixed.
   Tab: Neither do we
   jdaggett: So we should keep this to the absolute minimal spec, because
             whatever's there, we won't have a chance to fix anything
   Tab: Question is what features to preserve in the draft and how to call them
   Tab: Right now variables are created with a property
   Tab: Few different ways to handle this
   Tab: Right now they're declared as property declarations.
   Tab: property name options
     var-foo
     $foo
     my-foo
     user-foo
   Tab: 3 ways to use a variable
     prop: $foo
     prop: var(foo [, fallback])
   Tab: use var function with optional fallback
   Tab: Option to do something when var isn't defined or is invalid,
        very useful functionality
   Tab: other function is parent-var()
   Tab: which does the same thing, but checks the variable value on your
        parent
   Tab: Less than 1 week ago would suggest moving to $foo
   Tab: Now I don't, because I think there's some interesting solutions
   Tab: partially due to dbaron's selector idea and some conversations
        with fantasai
   Tab: So think we should not go with $foo syntax
   Tab: I want to do something like SASS's extend, or what dbaron proposed,
        which needs a very compact thing
   Tab: This why I don't want to use that syntax right now
   Tab: I want to leave us with these two functions var() and parent-var(),
        as written
   Tab: and keep what's there for var declarations
   Tab: maybe one of the other options suggestion

   Florian: I'm happy with this proposal
   * fantasai too
   jdaggett: When you're using the variable, what's the syntax
   Florian: That was the way initially proposed to the group
   Rossen: it's good
   fantasai: I think it's good that the basic use is consistent with the
             more complex uses
   jdaggett: I don't like the syntax, but $foo keeps the stylesheet a lot
             more tight
   Molly: People are already familiar with $foo
   jdaggett: It also causes confusion because it's a shell variable
   jdaggett: But having compact notation is important
   Tab: I think that's a decent argument against it
   Tab: Because in preprocessors, it behaves very differently
   Tab: In SASS etc. they are pretty much macros
   Tab: They're global variables, can do replacement anywhere for anything
   Tab: I think we want something similar to what SASS etc. do, but this
        isn't that
   Florian: Our variables are different, so we shouldn't match their syntax
   Tantek: Heard request from jdaggett for fully-written-out examples
   Tab: in the spec

   glazou: Last time we mentioned $foo, someone mentioned ppl behind the
           processors were willing to change their own $foo if we were
           ready to accept it for CSS
   Tab: That's still the case
   glazou: So why don't we use $foo
   Tab: First of all, they can't match us entirely.
   Tab: They can only do so in restricted cases, would be very confusing
   Tab: You can't do it without severe hacking
   Florian: They can change their syntax to match or not match ours.
            They can't change their behavior to match ours.
   fantasai: Because we use the cascade and inheritance, and they do
             simple string substitution
   plinss: That only saves us collision with SASS. Doesn't save us the
           confusion in minds of authors.
   Florian: None of the existing languages that use $foo for denote variables
            [behave this way]
   glazou: We still need a way to express parent-var, and with $ you can't
   Tab: I want to reserve our use of $ for something similar
   Tab: Where you can do variables for Selectors, and there a very short
       glyph-based thing like $foo is necessary, whereas less necessary
       in CSS value

   Florian: I think we're going to take some flames for it, but we should
            go this way
   Tantek: I'm going to go with your recommendation, and publish with that,
           and if it really is that objectionable to the authoring community
           we will hear about it very loudly from them.
   Tantek: I'd rather have that debate there than here.
   Tantek: Let's go with your judgement, and if authoring community has
           unified force against that, they we can reconsider.
   szilles: Besides, you can always use SASS to replace the $foos.

   fantasai: I agree with Molly that we need a very clear blog post
             explaining why we are deciding this way
   * fantasai volunteers to help write that
   jdaggett: I think it is important to talk about the inheritance model
   jdaggett: It needs to be in the forefront that this is not a macro
             replacement mechanism.
   Tab: Cool

   Tab: In the FPWD, all we had was var-foo and var(foo)
   Tab: We couldn't specify fallback, and didn't have parent-var()
   Tab: Are these acceptable in Level 1
   Tab: They could be deferred, but are sufficiently simple and useful
        that could be part of Level 1
   jdaggett: I really think for this level, since we aren't going to be
             behind a prefix for X months, we should keep this to a minimum.
   jdaggett: In particular I don't like parent-var(), because it feels
             like an experiment
   jdaggett: The things it's useful for, might be better ways to do it.
   jdaggett: I think there's going to be little pockets of places where
             it will be difficult to get interop
   jdaggett: I'm not saying I oppose the feature, but for Level 1, get
             the simplest functionality out there
   Tab: I'm ok with deferring parent-var(), but really want to keep fallback
   glazou: How about add a note explaining parent-var(), as "in the future
           we may consider this"
   dbaron: So, I sortof have mixed feelings about dropping parent-var
   dbaron: on onehand, I'm not crazy about the name parent-var()
   dbaron: On the other hand, it seems trivial to implement once you have
           all the rest
   dbaron: Although maybe I'm missing something
   glazou: I think you're right it is very simple
   glazou: I think web authors using variables will need more, parent-var()
           is only the first step
   Tab: On one hand I have several use cases really awesome for parent-var
        in the spec
   jdaggett: There may be many examples, but maybe that's not the right set
   jdaggett: If we stake a claim on parent-var, everything else has to fit in
   glazou: If it's simple to implement, can do Level 2 in a snap
   Tab: ... grab property value from the parent and use the value in your stuff
   dbaron: that's a can of worms
   Tantek: I hear what you're saying, John, but rather than entertain that
           as a hypothetical possibility, invert that into a challenge
   Tantek: Provide the use cases for other possibilities
   Tantek: I think we should include it based on commentary that has been made
   jdaggett: Keep in mind this is not prefixed
   tantek: 2nd, we have a notion of variables in one place, which is the
           font-size
   tantek: You can refer to font-size of yourself or parent in a few places
   tantek: Nobody's come and said "I want font size of grandparent"
   dbaron: we have rem now
   Tantek: but probably safe to go with just parent-var
   Florian: I say we go with L1 without parent
   Florian: Then make a L2 quickly that just has parent
   Florian: have the discussion about parent-var there
   tantek: ...
   jdaggett: This is going to spread like wildfire once it's implemented
   Tab: I'm fine with this. Fine with doing small drafts that advance quickly.
   glazou: Tantek, I would agree with you if it was going to take awhile,
           but this is small and fast
   RESOLVED: Syntax of variables settled on var-foo and var(foo)
   ACTION: TabAtkins, fantasai, and glazou to write blog post explaining
           why not using $
   RESOLVED: Include fallback in Level 1
   RESOLVED: Defer parent-var to Level 2
   RESOLVED: Accept Variables L2 with parent-var() as work item
   fantasai: I don't think we should go to LC yet; want to get a few weeks
             of feedback in response to this WD.
   jdaggett: Also, I want that sentence changed. He knows which sentence.
   RESOLVED: Publish WD of CSS Variables providing sentence jdaggett objects
             to is removed.

   plinss: Who is building a test suite for Variables?
   jdaggett: dbaron has already started
   Tab: I'm going to expand that more, because I need to write test suites
        for 3 different specs I'm in charge of

Day 2 closed.

Received on Wednesday, 29 August 2012 23:44:50 UTC