| 01:23 | <JonathanNeal> | TabAtkins: is there a post somewhere with your latest theory on CSS nesting? |
| 01:24 | <JonathanNeal> | Most sources point to http://tabatkins.github.io/specs/css-nesting/ and I wasn’t sure if that was tracking with your latest idea. |
| 01:36 | <TabAtkins> | It's not, no. I haven't updated the spec yet. |
| 01:37 | <JonathanNeal> | TabAtkins: ah, very good to know. Is your current thinking to use @ rules? |
| 01:37 | <TabAtkins> | Kinda. |
| 01:39 | <TabAtkins> | It's to allow naked embedding of style rules inside of other styles if the selector starts with &. Otherwise, you can use the @nest <sel> {...} rule. |
| 01:40 | <JonathanNeal> | Where `&:hover` would be right, but `body &` would be wrong? |
| 01:40 | <TabAtkins> | Most nested selectors start with &, so that'd give you the no-overhead nesting of Sass most of the time. |
| 01:40 | <TabAtkins> | Yeah. |
| 01:40 | <JonathanNeal> | Were other hypothetically-valid characters considered besides ampersand? |
| 01:41 | <TabAtkins> | Multiple languages converged on &, so it's not even a question, really. |
| 01:42 | <JonathanNeal> | Okay. Developer brains, or at least mine, love to stick to something consistent. If @nest <sel> {} became a thing, I could quickly imagine best practices recommending @nest &:hover over &:hover. |
| 01:43 | <JonathanNeal> | Maybe that’s not useful to even say, but I’m musing on it. I definitely like the selector being alongside the at rule more than nested within it. |
| 01:44 | <JonathanNeal> | Would it be valid to use @nest in a way that could be done without it? |
| 01:45 | <TabAtkins> | Yeah, you can do whatever you want inside of @nest. The selector has to contain an &, that's all. It can be at the front if you want. |
| 01:46 | <JonathanNeal> | e.g. .foo { @nest &.bar {} @nest &.qux {} } |
| 01:46 | <TabAtkins> | Yeah. |
| 01:46 | <JonathanNeal> | Ah, so it has to contain an &, that was going to be my next question |
| 01:46 | <JonathanNeal> | I was going to see if .foo { @nest { color: red; } } was the same as .foo { color: red } |
| 01:46 | <TabAtkins> | Yeah, if we allow omitting that's just implying an "& " at the beginning, and I don't want to encourage that accidentally. |
| 01:46 | <TabAtkins> | There's no selector at all there! |
| 01:46 | <TabAtkins> | Gotta have *something*. |
| 01:47 | <TabAtkins> | But .foo { @nest & { color:red; } } is indeed the same as .foo { color: red; } |
| 01:47 | <JonathanNeal> | And .foo { @nest .bar {} } is also invalid because it must contain the &? |
| 01:48 | <TabAtkins> | Yeah. |
| 01:48 | <TabAtkins> | Encouraging descendant selectors by default isn't a friendly behavior, so I'd make you write it out on purpose. |
| 01:48 | <JonathanNeal> | Why do you prefer that over the implied & ? |
| 01:48 | <TabAtkins> | Gotta do @nest & .bar {...} if you want that. |
| 01:49 | <JonathanNeal> | Or, to what you just said, why do you think descendant selectors is an unfriendly default? |
| 01:51 | <JonathanNeal> | And multiple selectors will work like Sass as well? .a, .b { @nest &.c, .d & {} } === .a.c, .d .a, .b.c, .d .b {} |
| 01:52 | <TabAtkins> | Because descendant selector is slow, and defaulting people into that (so it takes *more* characters to do the faster &>.bar thing) is bad. |
| 01:52 | <TabAtkins> | Yeah (re multiple selectors) |
| 01:53 | <TabAtkins> | Semantics are that you can replace the & with a :matches() containing the outer selector. |
| 01:53 | <JonathanNeal> | Excellent. Thanks for sharing your brain on that. I think @nest <sel> is pretty readable to those of us who deal with change badly. :D |
| 01:54 | <JonathanNeal> | Ah, you are referring to .a, .b === :matches(.a, .b)? |
| 01:55 | <JonathanNeal> | :matches and @custom-selector are definitely my favorite experimental goodies. |
| 01:56 | <JonathanNeal> | With things like (40em < width <= 60em) being a close second. |
| 01:56 | <TabAtkins> | Yeah. |
| 01:56 | <JonathanNeal> | The doubledash gets a bit tiresome, but only on vars. If anyone is like me, you are going to catch yourself making this typo: --var(thing) WHOOPS |
| 01:57 | <JonathanNeal> | :--heading {}, no problem. @media (--mobile), no problem. |
| 01:58 | <JonathanNeal> | --var, every day |
| 01:59 | <TabAtkins> | Interesting. |
| 02:00 | <JonathanNeal> | I hope so, I didn’t want to waste your brain space with that, but I thought it was interesting too. |
| 02:00 | <TabAtkins> | I'm p sure I'll have a use-case for --foo keywords naked in properties in the future, which is why I didn't want to use them for variables. |
| 02:01 | <JonathanNeal> | Will keywords be like variables without inline fallbacks? |
| 02:01 | <JonathanNeal> | *custom keywords |
| 02:03 | <JonathanNeal> | @custom-media --mobile (width < 30em); @custom-selector: :--heading h1, h2, h3, h4, h5, h6; @custom-keyword: --blue #b3d4fc; |
| 02:04 | <JonathanNeal> | That could be a beautiful thing, if that’s what you are referring to. |
| 02:05 | <TabAtkins> | Dunno! |
| 02:05 | <JonathanNeal> | Haha. Tell me more about the future now! |
| 02:05 | <JonathanNeal> | Well, I really appreciate you sharing your thoughts on this. |
| 02:06 | <TabAtkins> | np |
| 02:08 | <JonathanNeal> | Is there anything like Sass mixin currently proposed? |
| 02:09 | <TabAtkins> | For simple mixins, I just proposed http://tabatkins.github.io/specs/css-apply-rule and the WG accepted it. |
| 02:09 | <TabAtkins> | (Per the minutes, it was a provisional acceptance pending me resolving some circularity issues, but I resolved those issues in off-record conversation.) |
| 02:15 | <TabAtkins> | JonathanNeal: Oooooh, and you just gave me a good idea. |
| 02:16 | <TabAtkins> | So, vars are generally the "theming" solution for custom elements. You declare a few variables that your component uses, and people can set those to style them. This avoids the need to have shadow-piercing selectors in CSS. |
| 02:17 | <TabAtkins> | But sometimes you want to offer the ability to *fully* style a particular element within the shadow. That's not practical to do with vars, as you'd need 400+ vars, one per property. That's crazy. |
| 02:17 | <TabAtkins> | So CSS mixins (the @apply rule) were a solution here - you could just pass in the styles you want as a mixin-var instead. |
| 02:17 | <TabAtkins> | But that doesn't let you respond to different *states* of the element, like if you want to apply :hover styles and the like. |
| 02:18 | <TabAtkins> | The component author could predefine a few mixin-vars for this purpose, but it requires them to think of all the combinations of pseudo-classes you might want ahead of time. |
| 02:19 | <TabAtkins> | We can fix this by mixing together mixins and nesting! You can do ".component { --theme: { color: blue; @nest &:hover { color: red; } }; }" and it'd work! |
| 02:19 | <TabAtkins> | Yay, I'm happy I found a solution there. |
| 02:38 | <JonathanNeal> | I’m absorbing what is happening there. |
| 02:39 | <JonathanNeal> | Oh, you’re using custom propert sets and @nest like Sass |
| 02:41 | <TabAtkins> | Similar to Sass mixins with nested rules, yes. Just defined on the tree, like CSS vars are, rather than global like Sass. |
| 02:42 | <JonathanNeal> | I think I need to write my own rosette stone for @mixin to @apply to better fathom it. |
| 02:42 | <JonathanNeal> | *rosetta |
| 02:42 | <TabAtkins> | It's the same as the conversion from Sass vars to CSS vars. |
| 02:43 | <JonathanNeal> | I’m not sure how you pass in variables during an apply |
| 02:43 | <TabAtkins> | You don't (yet). |
| 02:43 | <TabAtkins> | I got plans for that in the future, but it's not in the v1 proposal. |
| 02:44 | <TabAtkins> | *Simple* mixins is the word of the day here. |
| 02:44 | <JonathanNeal> | Oh, I thought that’s the primary use case for mixins in Sass versus extend. |
| 02:45 | <TabAtkins> | It is! Without arguments, mixins is equivalent to placeholder extends in power. But we have neither in CSS so far. ^_^ |
| 02:45 | <JonathanNeal> | @mixin icon $type { background-image: url($type); } .thing { @include icon hamburger.svg; } |
| 02:45 | <TabAtkins> | (Equivalent in power, but the usage scenarios are slightly different, as they do the extension from different sides.) |
| 02:51 | <JonathanNeal> | Is --type passed in this scenario? https://gist.github.com/jonathantneal/f0cf9b1901ef32c6595d |
| 02:56 | <JonathanNeal> | I added some questions inside that gist next to the @apply usages. |
| 02:56 | <JonathanNeal> | Mostly, I’m trying to see how variable scope works. |
| 02:58 | <TabAtkins> | No. --icon is just a custom property that happens to have a specially-formatted value. var() functions in a custom property are processed at the time the custom property is applied to an element. |
| 03:01 | <TabAtkins> | Later, there will be a way to define a var() that isn't substituted normally, just by @apply passing in some values. |
| 03:02 | <JonathanNeal> | For now, the first menu would get background-image: none because it got it from :root, the second menu would get background-image: url(hamburger.svg); because that was the matching var at the time it was applied, and the third menu is non-sense css? |
| 03:03 | <TabAtkins> | What menus? There's only one. |
| 03:03 | <TabAtkins> | OH, you added to the gist, let me check |
| 03:03 | <JonathanNeal> | You’re right. I just updated it to call them menu-1, menu-2, menu-3 to clear up the confusion. |
| 03:04 | <TabAtkins> | 1 and 2 are both none; again, --icon is just a custom property with normal custom property semantics. When you set --icon on the root element, it substitutes any var() functions based on the other custom properties set on the root. |
| 03:04 | <TabAtkins> | And yeah, 3 is just invalid. |
| 03:05 | <JonathanNeal> | Well, apply seems like a nicer version of @extend so far. |
| 03:05 | <TabAtkins> | The two do similar but different things, just like extend and mixin in Sass. |
| 03:06 | <JonathanNeal> | It it accepted vars somehow, it would be like a super breed of extend and mixin |
| 03:06 | <TabAtkins> | It's nothing like extend. ^_^ |
| 03:06 | <JonathanNeal> | You’re right again. I meant placeholder extend. |
| 03:06 | <JonathanNeal> | Is that right? |
| 03:07 | <TabAtkins> | Only insofar as simple mixins and placeholder extends are similar in functionality. They're not similar in semantics. |
| 03:08 | <TabAtkins> | (mixins requires the "target" element to opt into the styling. extend puts the "targetting" responsibility on person writing the extend.) |
| 03:12 | <JonathanNeal> | Would variables be passed in like the .menu-3 example in v2? |
| 03:14 | <TabAtkins> | You'd need a different var() syntax in the custom property set, to indicate that it's a "late-bound var", but yeah, something like that. |
| 03:14 | <TabAtkins> | I have an example that I accidentally left in the spec with var(--theme-color late). |
| 03:14 | <TabAtkins> | Probably woudl use parens, not curlies. |
| 03:14 | <JonathanNeal> | Ha, I failed to notice that there wasn’t a comma. |
| 03:15 | <JonathanNeal> | I thought late was a css color I didn’t know about. |
| 03:16 | <TabAtkins> | I probably wanna make that more obvious, yeah. |
| 03:16 | <TabAtkins> | Maybe put it first |
| 03:16 | <TabAtkins> | var(late --theme-color) or something |
| 03:16 | <TabAtkins> | That probably works better with var(parent --foo) too. |
| 03:17 | <JonathanNeal> | parent being superior to late? |
| 03:17 | <JonathanNeal> | e.g. border: 1px solid var(parent --theme-color, none); |
| 04:05 | <TabAtkins> | JonathanNeal: Not superior. It just takes the variable value from the parent instead. Mainly useful for defining variables recursively, like --indent: calc(var(parent --indent) + 20px); |
| 06:53 | <annevk> | MikeSmith: thank you for working on https://github.com/whatwg/html-build/pull/28 |
| 06:53 | <annevk> | MikeSmith: working on the big patch that is Fetch that will be a huge help |
| 06:54 | <annevk> | MikeSmith: finding typos is rather hard atm |
| 06:54 | <MikeSmith> | yeah |
| 06:54 | <MikeSmith> | I will try to land that later today |
| 06:55 | <MikeSmith> | I need to refine it so it works teh same both for local wattsi and remote wattsi |
| 08:04 | <annevk> | Man, Fetch integration is so much work |
| 08:04 | <annevk> | Not even close |
| 08:04 | <annevk> | I wonder how this is ever going to be reviewed... |
| 08:26 | <nox> | annevk: If I notice some tree building rules where tokens should be reprocessed in state A, |
| 08:27 | <nox> | and state A states that the same tokens should be reprocessed in state B, |
| 08:27 | <nox> | should that be patched to remove the superfluous indirection? |
| 08:30 | <annevk> | nox: maybe, if someone is willing to do the work and find a suitable reviewer (not sure if there's anyone besides hsivonen who could do that) |
| 08:30 | <annevk> | nox: I guess Hixie could review too, if he's willing |
| 08:30 | <nox> | I see. |
| 08:31 | <nox> | Mmh in fact it was the opposite. |
| 08:31 | <annevk> | nox: there's a lot to do, so refactoring is not really at the top of my list, although I guess you could say Fetch is refactoring... |
| 08:32 | <nox> | "in template" insertion mode says to reprocess "in head" for "base", "basefont", "bgsound", "link", "meta", "noframes", "script", "style", "template", "title", |
| 08:32 | <nox> | and to reprocess "in body" for any other start tag, |
| 08:32 | <nox> | and "in body" insertion mode says to reprocess "in head" too for the same start tags as in "in template". |
| 08:40 | <annevk> | Yeah, I think that's basically "in body" calling "in head"(token) |
| 08:40 | <annevk> | When I implemented that it wasn't very clear to me either though |
| 08:47 | <nox> | annevk: Yes yes, the clause is just repeated, it's a minor detail. |
| 08:47 | <nox> | annevk: I wonder if patches that "parameterises" the states would be acceptable. |
| 08:47 | <nox> | annevk: For example, I'm pretty sure that the original insertion mode is only related to the "in text" insertion mode. |
| 08:50 | <annevk> | nox: dunno, would have to see it |
| 09:58 | <MikeSmith> | so if a Safari user doesn't have their "Block pop-up windows" user preference set to off (the shipping default is off), Web pages that use document.open to create new windows just silently fail to that, and the only error that's logged to the console is "TypeError: undefined is not an object (evaluating 'foo.document')" |
| 10:01 | <MikeSmith> | that seems very unhelpful to developers who want to legitimate let users opt-in to some UX/UI that uses multiple windows, and are trying to troubleshoot problems reported by users; e.g., "ur page it doesn't work at all for my safari. nothing isn't show up" |
| 10:02 | <MikeSmith> | no "popup was blocked" indicator shows up in this case in the browser chrome |
| 10:05 | <MikeSmith> | actually I guess it's window.open |
| 10:35 | <hallvors> | gsnedders: When you mention it, I think I looked briefly at those tests at some point and was wondering about the same thing. I suppose there was a plan to add some JS scaffolding and the work was never finished, or just not committed to SVN? |
| 10:37 | <hallvors> | MikeSmith: in some (all?) browsers, document.open() will actually invoke window.open() if there is a string argument. Compat pressure because of content confusing window.open() and document.open(). You're not alone ;) |
| 11:49 | <MikeSmith> | hallvors: ah yeah I vaguely recall this now |
| 12:40 | <annevk> | hallvors: it must have been user agents that made the first error there, otherwise content couldn't confuse them |
| 12:44 | <hallvors> | annevk: ok, probably some browser vendor developer thinking "what if somebody got confused by the two open() methods.." although the odds that people sometimes ship untested JS into production is rather high |
| 15:15 | <jgraham> | mkwst: So I'm somewhat reluctant to add gzipping by default because it's an extra layer of complexity that doesn't correspond to the things that are being tested. But I agree we should have some way to enable it for specific files |
| 19:19 | <gsnedders> | hallvors: no idea. I never looked at them till recently. They were converted to reftests at some point, at least. |
| 21:23 | <hallvors> | jgraham mkwst: +1 for *not* gzipping by default. In the XHR test suite we have a file dedicated to returning gzipped content - https://github.com/w3c/web-platform-tests/blob/e5e8fb9ebc4d5b2220abff5679fa0781c01f2c05/XMLHttpRequest/resources/gzip.py |
| 21:23 | <hallvors> | I suppose it's trivial to enhance it to accept a ?file argument or something like that |
| 22:20 | <gsnedders> | is anyone using test infra such that gzip will effect loading time? |