| 00:08 | <TabAtkins> | smaug____: http://dev.w3.org/csswg/css-forms/ Feel free to comment on www-style. ^_^ |
| 00:16 | <Domenic> | TabAtkins: jeeez, that + @extends make this quite a day for you. Although presumably the work of the last few weeks. |
| 00:17 | <Domenic> | "Any elements with class=my-button receive the same styling as actual button elements, as if they had a tagname of button in addition to their normal tagname." woah! |
| 00:17 | <TabAtkins> | Domenic: Things often clump in time. |
| 00:17 | <Domenic> | that clause is super useful for custom elements |
| 00:17 | <Domenic> | custom-button { @extends button; } |
| 00:18 | <TabAtkins> | Yup yup. |
| 00:28 | <smaug____> | TabAtkins: @fosdem. I'll try to look at that tomorrow |
| 00:28 | <smaug____> | hmm, "The source file for the page css-forms/Overview.html has recently been updated and automatic generation is pending." |
| 00:28 | <TabAtkins> | Give it a minute or two. |
| 00:30 | <smaug____> | background is btw interesting case, if it includes bg image |
| 00:31 | <smaug____> | IIRC gecko is the only one which support bg image for select popup |
| 00:31 | <smaug____> | and it had to limit how the popup is shown to prevent popup to cover the whole screen |
| 09:13 | <annevk> | TabAtkins: Domenic: pointer to @extends? |
| 09:24 | <annevk> | "I don't like your API. It creates too much objects. Let me wrap it in a polyfill." Yes, that will make things more efficient |
| 09:34 | <SimonSapin> | annevk: https://tabatkins.github.io/specs/css-extend-rule/ |
| 09:40 | <annevk> | SimonSapin: ta! |
| 09:41 | <annevk> | SimonSapin: do you know why the rationale in the introduction is not applicable to using .serious.error instead? |
| 09:47 | annevk | files https://github.com/tabatkins/specs/issues/38 |
| 09:57 | <SimonSapin> | I don't know |
| 10:36 | Ms2ger | wonders if the spec defines that the selected files are emptied when changing input@type |
| 12:16 | <annevk> | I don't really follow how @extend would influence querySelector() |
| 12:18 | <annevk> | Also, what's the object model story? |
| 14:32 | <Ms2ger> | In this talk: Acid tests |
| 14:36 | <Ms2ger> | Also, namespaces. Namespaces everywhere. |
| 14:37 | <Ms2ger> | And XPath |
| 14:40 | <jgraham> | Ms2ger: Are you sure you didn't slip into a nightmare? |
| 14:40 | <Ms2ger> | No |
| 14:41 | <Ms2ger> | Aren't you around here? |
| 14:43 | <jgraham> | No |
| 14:43 | <jgraham> | I sort of forgot about i |
| 14:43 | <jgraham> | t |
| 14:43 | <Ms2ger> | I see |
| 14:49 | <gsnedders> | Anyone got any idea why, given six web fonts with similar definitions, only two would load in IE8? |
| 14:49 | <Ms2ger> | "IE" |
| 14:49 | <gsnedders> | Like, just aren't loaded. At all. |
| 14:51 | <jgraham> | That's almost as obscure as my question, which is basically "why is Chrome not passing my wptrunner tests when it's basially using the same code as Gecko, which does pass" |
| 14:52 | <gsnedders> | Bah, you guys are smart! |
| 14:53 | <gsnedders> | And now I reload and they all load. |
| 14:53 | <gsnedders> | WHAT THE ACTUAL HELL. |
| 14:53 | gsnedders | flips IE |
| 14:53 | <gsnedders> | (I bet this is some CORE-44944-like bug) |
| 14:56 | <jgraham> | Oh joy. time.sleep(1) => tests pass |
| 14:57 | <gsnedders> | :) |
| 15:08 | <jgraham> | Hah |
| 15:08 | <jgraham> | It fails if the window doesn't have focus |
| 15:10 | <jgraham> | https://code.google.com/p/chromedriver/issues/detail?id=388 |
| 16:02 | <TabAtkins> | annevk: There's an issue in the spec about whether @extend should affect querySelector or not. I'm undecided so far. |
| 16:02 | <TabAtkins> | annevk: What's your concern about the object model? |
| 16:06 | <annevk> | TabAtkins: I don't see how it could affect querySelector() |
| 16:06 | <annevk> | TabAtkins: just wondering what it looks like |
| 16:06 | <annevk> | TabAtkins: if it flattens or something else |
| 16:06 | <annevk> | TabAtkins: (I saw the open issue, just didn't see how it would possibly have an impact) |
| 16:06 | <TabAtkins> | By... affecting what matches the selector? |
| 16:06 | <TabAtkins> | Such that a querySelector('.error') also returns .serious-error elements? |
| 16:07 | <TabAtkins> | For OM, the rules just gain a .cssRules attribute, which @extend goes into. |
| 16:08 | <annevk> | Why would .error match .serious-error if .serious-error copies styles from .error? |
| 16:09 | <annevk> | Seems weird |
| 16:13 | <TabAtkins> | annevk: Because you're reading the spec wrong, I guess? .serious-error elements gain the qualities necessary to match .error selectors, for the purpose of matching selectors. |
| 16:14 | <TabAtkins> | So when you write a selector like ".error { color: red; }", .serious-error elements are targeted as well. |
| 16:14 | <TabAtkins> | So it makes at least some sense that querySelector(".error") would return .serious-error as well. Dunno if it's good in practice. |
| 16:17 | <annevk> | The way that rule reads to me is like a mixin |
| 16:18 | <annevk> | Which sort of follows from it being part of the block rather than being part of the selector |
| 16:21 | <TabAtkins> | annevk: @extend is similar to @mixin, yes. But they're not the same. |
| 16:22 | <TabAtkins> | If you ignore some fiddly details, they're functionally the same, applied in an inverse manner. |
| 16:22 | <TabAtkins> | But those fiddly details are important. ^_^ |
| 16:22 | <TabAtkins> | And usability-wise they're very different once you get away from the trivial examples. |
| 16:23 | <TabAtkins> | For example, you can create a whole suite of rules for styling .error in various situations. With @extend, your .serious-error elements can opt into the entire thing with a single rule. With @mixin, not so much. |
| 16:23 | <TabAtkins> | (Technically possible to do so, by using nesting rules inside the @mixin block, but not a good practice or very common.) |
| 16:23 | <annevk> | Yeah I guess, and @extend is across all stylesheet boundaries (includes UA stylesheets) |
| 16:23 | <TabAtkins> | Yeah. |
| 16:24 | <annevk> | I don't think we would want layout to affect the results of querySelector() though |
| 16:25 | <TabAtkins> | There's no layout involved? |
| 16:25 | <TabAtkins> | Unless you're using "layout" in a very broad and incorrect way. |
| 16:25 | <TabAtkins> | @extend affects the cascade only. |
| 16:26 | <annevk> | I love using layout in an incorrect way |
| 16:27 | <TabAtkins> | ^_^ |
| 16:27 | <annevk> | But yeah, having querySelector() depend on stylesheets in general |
| 16:27 | <TabAtkins> | Yeah, I was unsure if that was a good idea. Or if it was a useful idea in general - I could see it being pretty confusing. |
| 16:27 | <TabAtkins> | Even if the technical details were fine. |
| 16:28 | <annevk> | I'm sure we could explain it, somehow (though would require synchronous cascade in some cases), but I'm not sure it'd be pretty |
| 16:28 | <annevk> | Though if we want to do style isolation a la shadow trees as style primitive, maybe we need it? |
| 16:29 | <TabAtkins> | Still unsure that makes sense as a style primitive, rather than as a DOM API. |
| 16:31 | <TabAtkins> | Basically I'm vaguely uncomfortable with any attempt to do isolation/encapsulation stuff with a big global API like style. I think we need something more direct and local. |
| 16:37 | <annevk> | TabAtkins: any documentation for -webkit-tap-highlight-color anywhere btw? |
| 16:37 | <TabAtkins> | Doubt it! |
| 16:37 | <TabAtkins> | Just things like http://css-infos.net/property/-webkit-tap-highlight-color |
| 16:47 | <annevk> | Google does not even return that for me |
| 16:57 | <TabAtkins> | I literally just googled for webkit-tap-highlight-color |
| 18:14 | <annevk> | Oh doh, the leading hyphen is a problem |
| 18:15 | <annevk> | You'd think Google knows about CSS properties :p |
| 18:16 | <caitp> | if they started adding heuristics to figure out if you meant "negate this word" or not, it would probably get even harder to use |
| 18:17 | <annevk> | All they need to do is recognize it as a word |
| 18:17 | <TabAtkins> | But -word already has a meaning - "exclude matches with word". |
| 18:17 | <caitp> | but sometimes it's a word and sometimes it's an operator |
| 18:18 | <caitp> | so you need inconsistent rules to figure out which is which |
| 18:18 | <annevk> | I meant that you'd use --webkit-tap-highlight-color to exclude it |
| 18:18 | <caitp> | if the word is quoted i think that should ideally work as expected |
| 18:18 | <TabAtkins> | how woudl it know that -webkit-tap-highlight-color didn't mean "exclude results with webkit-tap-highlight-color"? |
| 18:18 | <caitp> | (but it doesn't) |
| 18:19 | <annevk> | TabAtkins: because it knows the latter is not a word |
| 18:19 | <TabAtkins> | How does it know that? |
| 18:19 | <annevk> | TabAtkins: usage patterns, presumably |
| 18:22 | <TabAtkins> | And when *I* need to search for something and exclude "webkit-foo", how am I to know I need to double-negate it? |
| 18:23 | <caitp> | "-webkit-foo" << don't negate, -"-webkit-foo" << negate -webkit-foo |
| 18:23 | <caitp> | probably the most predictable way |
| 18:23 | <TabAtkins> | caitp: Yeah, that uses well-known and consistent grammar. |
| 18:47 | <annevk> | TabAtkins: if you want literals, use quotes |
| 18:47 | <TabAtkins> | I know that. |
| 18:48 | <TabAtkins> | You're the one saying otherwise. ^_^ |
| 18:48 | <annevk> | TabAtkins: no, I'm saying it should be better about words |
| 19:54 | <jgraham> | I thought that quotes on Google didn't actually work anymore |
| 19:55 | <jgraham> | Although I might be wrong. Doesn't seem impossible to have an algorithm where if -x results in nothing, you try the query again as if quoted |