W3C home > Mailing lists > Public > www-style@w3.org > February 2014

[CSSWG] Minutes Seattle F2F 2014-01-29 PM III: Media Query Macros, CSSOM Values API

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 19 Feb 2014 16:20:24 -0800
Message-ID: <53054A48.6090209@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
Media Query Macros

   Tab introduced a proposal for aliasing media queries and selectors
   for easier reuse.

   RESOLVED: MQ part of TabAtkins's proposal to be added to MQ4, new ED
             for Custom Selectors granted


   Tab presented a proposal for a new CSSOM API that avoids the need
   for parsing CSS values in JS. Currently taking initial feedback.

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

Media Query Macros

   <dbaron> http://tabatkins.github.io/specs/css-aliases/
   TabAtkins: CSS variables work really well for a lot of use cases but
              for some CSS preprocessors are still better
   TabAtkins: for example, if you have an extended media queries, you are
              out of luck
   TabAtkins: this is a proposal to define aliases
   TabAtkins: it includes a declarative form that is equivalent to what
              preprocessors can do today plus a script-based form that
              extends it further
   TabAtkins: this is my current proposal for declaring a custom media query

   TabAtkins: there is a restriction that the custom name must contain an
   TabAtkins: there is a similar restriction in HTML where you want to
              define custom elements without clashing
   TabAtkins: in that case they got around this by using dashes
   TabAtkins: you have to include a dash in a custom element name
   TabAtkins: in the same way, this requires underscores
   TabAtkins: <idents> can use underscores but we've never used them
   heycam: will you remove underscores from <ident>
   TabAtkins: no, <ident> still includes them but we the language never
              use it

   glazou: it seems like you're defining a media type
   <dbaron> (glazou doesn't like the parentheses)
   TabAtkins: it's actually defining a media feature
   TabAtkins: you need to use parentheses in @media since it's not a media
   TabAtkins: but authors will soon stumble across that and work it out

   TabAtkins: it should also be possible to set up a media feature via
   TabAtkins: you should then also be able to test for that feature using
              CSS markup including :  and <
   TabAtkins: the javascript can define a boolean, number or string
   TabAtkins: this allows the style to react to something in its environment
              that can be controlled from script
   TabAtkins: so modernizr could use this rather than defining styles on
              the body

   dbaron: is there a use case for being able to set lengths
   TabAtkins: probably but I'd like to defer that until I talk about OM
   TabAtkins: I think it depends on what we decide on OM
   TabAtkins: so I'd like to add that later

   smfr: can you unset values?
   TabAtkins: this is just a map so you can just unset as usual
   SimonSapin: would the map already include the ones defined in markup
   TabAtkins: yes, and I'd have to define the order
   TabAtkins: I haven't specified it here, but for example, if defined
              twice the last one wins, javascript wins over markup etc.
   TabAtkins: standard precedence stuff

   dbaron: Can you put @custom-media inside other conditional rules
           (esp. @supports)?
   TabAtkins: I assume no, the definitions are probably global but I can
              change this depending on what is reasonable for implementation
   dbaron: I'm fine with no.
   TabAtkins: Also, no need for custom @supports stuff because you can use
              CSS.customMedia.set() with results of supports queries

   heycam: I don't think we should have MapClass anymore
   heycam: no-one much likes it
   TabAtkins: I want real maps but I don't care how to markup it up in WebIDL
   heycam: I think we can come up with something else and then I'll let
           you know

   TabAtkins: the selectors rule works the same way for custom selectors
   TabAtkins: this is always going to be a pseudo-class
   TabAtkins: (presents an example of a heading pseudo-class from the draft)
   smfr: why is it :_heading?
   TabAtkins: the _ is from the restriction I mentioned before, : is because
              otherwise it would be an element name
   krit: that's not in the production
   TabAtkins: yes, that should be there

   ?: Why have the : in the @custom-selector, rule?
   TabAtkins: Clearer that way.
   heycam: what if you put an <ident> directly before the custom selector?
   heycam: e.g. p:_heading
   <projector> p:_foo === p:matches(...)
   TabAtkins: it just works because it expands to :matches

   glazou: there are restrictions to what are allowed in a :matches()
   glazou: you should duplicate that explicitly here so it's a syntax error
           where the @ rule is defined
   TabAtkins: sounds reasonable
   glazou: @custom-selector should be a syntactically-invalid @-rule if it
           doesn't meet the syntax requirements for what goes inside :matches()
   TabAtkins: I should special-case top-level :not() so that it expands
              into :not() instead of :matches() in that case.
   glazou: I recommend we expand the :_heading example to include an
           expansion without the custom selector so that people don't
           think it's not just a macro
   <projector> No using custom pseudo-classes to define other custom
               pseudo-classes, because it hits the "no :matches() inside
               :matches()" rule.
   TabAtkins: ... not sure what I think of that

   SimonSapin: why do we have that restriction: no :matches inside :matches
   SimonSapin: this feature would be a lot more interesting without this limitation
   SimonSapin: what is the scope of this rule?
   TabAtkins: document scope
   florian: you need to define that if a selector is not matched it is not
            invalid but simply not matched because it may be defined later
   SimonSapin: does it update dynamically?
   TabAtkins: yes
   TabAtkins: that means you can actually define fallback
   <florian> you need to define that if a selector is not defined yet it
             is not invalid but simply not matched because it may be
             defined later

   smfr: I think this needs more syntactical sugar so it's easy to remember
   smfr: they look like C preprocessor defines but they don't behave like that
   smfr: it would be easy to forget the colon when you use it
   smfr: in @custom-selector :_foo the : looks a it like a property declaration
   smfr: so the space could end  up on the wrong side
   smfr: I like the feature but not the syntax
   TabAtkins: happy to change the syntax
   florian: this syntax proposed for media queries is fine, I think, but
            I can see the concern for selectors
   smfr: Also concerned about the extra parentheses in media queries
   dbaron: agree with florian... though I wouldn't mind seeing () rules change

   glazou: how does this relate to CSS hierarchies?
   TabAtkins: it doesn't
   glazou: does it impact it? is having both too much?

Scribe: glazou
   Tab: nesting is very close if not identical to what we get from preprocessing
   Tab: I also have a proposal for script-based custom selectors
   Tab: you define a name
   Tab: a function and when it's evaluated
   Tab: and a base selector that has to be fulfilled first
   Tab: (tab reads spec)
   Tab: based on mutation observers
   Tab: whenever a mutation comes in we try to reevaluate the function

   heycam: are you afraid of style flashes because of events order and stuff?
   Tab: no
   Tab: was waiting for an infinite loop question
   florian: might be brilliant but :-)
   TabAtkins: very close to an existing lib by bkardell
   smfr: don't think WebKit will ever want to run JS in the middle here
   heycam: if you want to implement it yourself, you can set a classname
           from a mutation observer
   smfr: I don't like it either
   florian: a way to retrigger evaluation of this?
   TabAtkins: there is something in the issue

   TabAtkins explains extra bits of the proposal
   SimonSapin: worth separating the API into two
   SimonSapin: first part substitutions
   SimonSapin: that part is less controversial
   TabAtkins: the script api of custom MQ is super powerful
   TabAtkins: I really want the MQ part
   TabAtkins: having to repeat MQ everywhere in your page is terrible
   TabAtkins: another option for script based selectors is assign a name
              and list of elements
   heycam: this is a simpler model
   Tab: being able to fill in a map walking over the document doesn't have
        much advantage over walking over the document setting a class

Scribe: SimonSapin
   glazou: Earlier we said we want to deprecate media types in favor of
           media features
   glazou: that implies that web authors are gonna write @media (screen)
           instead of @media screen
   TabAtkins: If authors want to do that they can, still better than media types
   glazou: it’s another argument against the () around custom media, or
           for allowing the current media types in ()
   TabAtkins: disagree, media types a bad in general. Carry more that you want
   TabAtkins: if you want to disable animations, you should target 'updates',
              not 'print'
   glazou: we will have to have a section mapping media types to lists of
           media features
   florian: I think that’s a bad idea, they will just copy-paste that list
   florian: It’d be better if they’d queried for just one feature
   glazou: will follow up on email

Scribe: glazou
   TabAtkins: requesting a new ED
   florian: find another name please
   ChrisL: antialiasing ?
   glazou: any objection ?
   TabAtkins: preferred is to put the MQ part in MQ 4, ...
   SimonSapin: er we wanted Selectors to independent from CSS
   SimonSapin: what about selectors API ?
   TabAtkins: yes!
   TabAtkins: MQ in MQ4 and Sel in Selectors ?
   dbaron: API part not ready yet
   <dbaron> (script selectors)
   dbaron: but happy to see it go in drafts
   TabAtkins: right

   glazou: I don't want to see an at-rule inside the Selectors spec
   TabAtkins: then Custom Selectors spec
   glazou: fine by me
   SimonSapin trolls Tab on spec dependencies
   SimonSapin: Aren't MQ also independent of CSS?
   RESOLVED: MQ part of TabAtkins's proposal to be added to MQ4, new ED
             for Custom Selectors granted

   <sgalineau> First Speculative Working Draft sounds like it should be
               a thing
   <Rossen> First Speculative Dream Draft will be even better

<br type=coffee>

CSSOM Value-based API

   <smfr> TabAtkins shows http://www.xanthir.com/b4UD0
   TabAtkins: After long time thinking, I'm ready to propose one. Got
              approval from colleagues who would implement it.
   TabAtkins: We implemented DOM2 and are trying to remove it now.
   TabAtkins: Because it is terrible for many reasons.

   TabAtkins: Exposing specialized forms for a property is probably useful.
   TabAtkins: But it is not a direct translation of the property.
   TabAtkins: At base level I refuse that.
   TabAtkins: Might be future level.
   TabAtkins: DOM2 could not return value of a shorthand.
   TabAtkins: We should also make it look more like JS.
   TabAtkins: And efficient.

   TabAtkins: Looking at what we changed in properties over the years.
   TabAtkins: Simple properties can later become complex, from one value
              to a list of values.
   TabAtkins: Calling it "el.css" (rather than el.style), but it's just
              a name.
   TabAtkins: el.css.backgroundImage (CamelCase)
   TabAtkins: JS can now do things like .float, even if float is a keyword,
              because of the preceding "."
   TabAtkins: E.g., width will be an array of length|keyword
   TabAtkins: If you assign a single value, it'll be equiv to an array
              with one value.
   TabAtkins: The values are immutable values.
   TabAtkins: Every "10px" object is the same single object.
   TabAtkins: People pushing for 64-bit ints.
   TabAtkins: So next year we'll have fully immutable objects.

   TabAtkins: You could write ".width = 5px" which looks exactly like CSS.
   TabAtkins: The "5px" is an immutable object.
   TabAtkins: You can ask for the .px of 5px and get 5.
   TabAtkins: When you ask for getcomputedstyle, you'll get the em as well.
   glazou: Can you ask for something like ".%"? Syntax issue?
   TabAtkins: 5px is CSS.px(5)
   TabAtkins: Constructor.
   <glazou> you cannot write el.css.width = 10% because % is an operator
            you have to use CSS.percent(10)
   TabAtkins: After el.css.width = 5px you can get el.computedCSS.width.vw
              (and .em and .px and .percent) and it will be computed.
   TabAtkins: Other accessors as needed.

   krit: Is .css the element style
   astearns: This is inline style? Might want to call it InlineCSS.
   TabAtkins: Yes, this is inline style.

   SimonSapin: Percent is null?
   TabAtkins: Yes, .percent cannot be computed, needs layout.
   florian: Is there a typo in the example?
   TabAtkins: Yes, sorry. Needs [0]
   TabAtkins: List needs to have same value at given index all the time [?]
   TabAtkins: Precise data structure, order of values.

   glazou: If you query .width, I'd like to qurey what the unit was,
           i.e., get "px" back.
   TabAtkins: Not in proposal right now, but planning to.
   TabAtkins: If you pull a computed value, the unit may not be available
   TabAtkins: It'll say "px" in that case, arbitrarily.

   florian: So if a property accepts repeated foo and bar, an in next
            level it accepts repeated foo, bar and baz?
   TabAtkins: In a list, you get first value in a list. It is an array
              of arrays in reality.
   TabAtkins: After el.style.bgAttachment="scroll, fixed"
   TabAtkins: you get: el.css.bgAttachment => [CSSVal("scroll")]
   TabAtkins: and: el.css.bgAttachment.1 => [[CSSVal("scroll")],[CSSVal("fixed")]]

   heycam: Things that aren't lists, say a pair, how is that handled?
   TabAtkins: Say you have <length> <length> now and later we'll have
              <length> <ident> <length>
   TabAtkins: First you would get el.css.foo => [1px,20px]
   TabAtkins: Later you would get [1px,20px,...]
   plinss: maybe don't return arrays and only return maps
   szilles: You would have to cycle through array.

   TabAtkins: Not super happy about my arrays, we can decide for objects
   astearns: Go with map idea and let Tab name everything. :-)
   <astearns> resolve to accept Tab's names for everything before he even

   heycam: Shorthands also give an array back?
   heycam: Say font, which has a slash?
   TabAtkins: The slash is not returned, it is just part of the punctuation
              for ambiguous values.
   plinss: personal preference, I hate single-letter names
   TabAtkins: Named values must not collide with [?]

   florian: Custom properties?
   TabAtkins: Probably a list of tokens.
   florian: At rules?
   florian: selectors, etc.?
   TabAtkins: Haven't thought through those yet.
   TabAtkins: Properties most important for me.
   TabAtkins: Is first step.
   florian: At least think through it if it is compatible, without actually
            writing the spec.

   heycam: Can you define operator overloading between custom types and
           standard types?
   TabAtkins: Yes, you can.
   TabAtkins: Yes, overload can be parametrized by type.
   TabAtkins: So "5px + 10px" can be valid.
   florian: And "10px + 10%"?
   TabAtkins: Yes, that would return a calc() object.
   <heycam> |el.css.width + el.css.width| wouldn't work since they're both
            Array objects
   TabAtkins: You cannot overload plain objects.
   TabAtkins: Also have a proposal that I call CSS.convert()
   TabAtkins: Converts as much as possible.
   TabAtkins: var x = 32px;
   TabAtkins: Now x.em is null.
   TabAtkins: After el.css.fontSize = 16px, CSS.convert(x, el).em returns 2
   TabAtkins: This is current;y a big braindump.
   TabAtkins: Not asking for anything in particular right now.
   TabAtkins: If it is terrible, tell me.
Received on Thursday, 20 February 2014 00:20:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:51:17 UTC