- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 19 Feb 2014 16:20:24 -0800
- 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
CSSOM Values API
----------------
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
underscore
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
feature
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
javascript
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
anymore.
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
later.
astearns: Go with map idea and let Tab name everything. :-)
<astearns> resolve to accept Tab's names for everything before he even
starts
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