- 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