Eric Meyer: Hello, I am Eric Meyer. I'm a developer advocate here at Igalia.
Brian Kardell: And I'm Brian Kardell. I'm also a developer advocate here at Igalia.
Eric Meyer: If you've listened to past Igalia chats or if you know anything about me or Brian, you know that we like CSS. CSS is pretty cool, lets you do a lot of really nifty stuff with the web platform or sometimes not on what we think of as the web platform. CSS is in a lot of places you might not expect it, so we like to talk about CSS and so we have a guest today, Roma Komarov.
Roma Komarov: Yes. Hello. My name is Roma, by the day job, I'm a senior front-end engineer at Datadog working on a design system. However, I spent most of my free time playing with CSS, doing experiments and sometimes writing about them.
Eric Meyer: Yeah. On a really, really nicely designed blog and website in general.
Brian Kardell: And you also give talks, don't you?
Roma Komarov: I gave a few lighting talks. I think I usually gave larger talks back in Russia, but in English I think I gave only four Lightning talks, two at Fronteers Jam Sessions in 2012, 13 and then two at dotCSS. I don't remember. I think one was right before COVID and one I think maybe a year before.
Eric Meyer: How did you get started with coding in general? What was your journey to CSS, as it were?
Roma Komarov: I started with programming back in school. We had in sixth, seventh grade BASIC lessons. So we learned how to draw shapes there and that's basically it. I think I remember the teacher showing us how sprites are done in games. I think there was some suit where you could see them drawn and then stuff like that, but I think in the later grade, there was a summer school where I did participate in a project where we did burn CDs with photos from the same summer school and I basically worked on content management a bit, adding them and modifying HTML for the gallery. So that was like 2001 maybe. Right after that, maybe a few months later I created my first page for myself. From that it started.
Eric Meyer: Where was that page hosted? Do you remember?
Roma Komarov: I think some third level domain at some random free hosting changed it a few times I think.
Brian Kardell: So you said that you spend a lot of your free time experimenting with CSS. I saw your Fronteers talk from 2013 where you explained some of those and another one or two that you've done too. I thought it was really interesting because of not just the thing that you did, but also your explanation of what does it mean to do experiments, what is the point and what should you not do and everything. I just thought you explained that really well in each of them and I wanted to know if you could maybe explain what are your experiments that you do? Give me some idea about what that means. There's lots of experiments I suppose, and also still feel the same way that you felt in those about the purpose, why you would do them.
Roma Komarov: I think I still think a lot of things that I said then it was... If I remember correct, one of the ideas is that, okay, don't look into the source, this thing that we actually have and that is very useful, an ability to look into the source of our pages, like any examples and articles and dig deep into them. For me it was interesting to solve problems and just to see if I can do something without actually looking how it was done before. And it was to extremes where I could see a title of a post and not even open it and just imagine what could that post talk about and then just try to implement it. And at the same time, just if I had some idea, I usually write it down somewhere and maybe try to implement it later. So for me, experimenting is just solving problems and sometimes just playing with things like when you're reading some specs, looking at things that are written and imagining, okay, how would this actually work in practice? How would this interact with some other properties in CSS or with some layouts in HTML. And then you go and try it and see the result and sometimes you find interesting things that maybe you did not see before.
Eric Meyer: That interests me that you say some of the experiments come from looking at a title and saying, 'I'm not going to read it. I want to see if I can figure out for myself how you would do that.' Do you then go back to the article and see if you came up with the same solution?
Roma Komarov: Usually yes. It's interesting to see what the author did actually meant. And sometimes I find that I actually solved some different problem and maybe over complicated things or maybe found something new and in the end I could get two solutions because I get one question that the author did ask and then another that I imagined they did ask. And yeah, it can be useful to just see how things compare, what the approach was for the author and to see what I know and maybe dig deeper into some of the aspects that I did not know I had to dig.
Brian Kardell: One of the things that I really liked about the talk that I saw was you made I think a GoBoard, you made a whole Go Game that had no JavaScript, right?
Roma Komarov: Yeah.
Brian Kardell: And you said, 'Look, this has accessibility problems and it's overly complicated and you should not do this in production.' But also I learned a really lot by doing this and it's also really cool to learn those sorts of things, what is possible, and then later on you'll have a mass of knowledge. And when you have to do something in production, you can draw on that knowledge and deep understanding. I thought that was a really great way to frame it because I agree with you, it is super cool that you can do that. But I also agree that yeah, you probably shouldn't do exactly that and I think it's a great way to present it and also a very responsible way to do it.
Roma Komarov: Yeah, I would say that a lot of my experiments go usually in a ways that you don't want to use them in production, and that's one of the reasons why I often don't provide tutorials how to recreate this experiment. You might look into the source and see how I did it, but often I would just in my articles present some snippets of how things like particular interactions between properties work to just demonstrate some idea or some way to solve a problem or work around some problem. But often these are more of is it even possible in any way and not necessarily a good way. One of the things that we can think about, I cannot draw at all, but I really like sometimes look at things people do in a single Div. For example, whole last month we had a lot of examples for that. That's from Lynn who often does really great things and-
Eric Meyer: Lynn Fisher?
Roma Komarov: Yeah.
Eric Meyer: Yeah.
Roma Komarov: When you learn to do something like this, you have to learn the edges of what is possible and then you can apply it. But this thing itself, usually for a drawing, you would probably use SVG or just PNG or any of the new formats if you want to have an image. Usually SVG, if you want to control some aspects of it, like animate things or change colors based on something, but you would not use this one Div as something that you would use in production. However, sometimes if it's a very small thing, it might be very useful to just use CSS, like if you want to square or if you want a circle or if you want a tick box instead of SVG, you could use a much smaller subset of CSS and when doing more complicated things, much simpler things go much easier.
Eric Meyer: Yeah, I've used, I would say similar technique to the single Div type design for things like separators. One of my preferred tricks is that if I want a separator in a page, like in a blog post, I'll put in a horizontal rule, right? Because that's what you use for a separator, but I'll style the heck out of it by making it an M tall and then putting in a bunch of backgrounds. And if you know how to use gradients of various types, which is how most a single Div stuff is done, then you can make these sort of artistic separators that look much better than just a simple horizontal rule by layering up three or four linear and radial gradients that are constrained in some way and then maybe you decide to also bring in an SVG and you use those backgrounds to mask out parts of what you're doing. That's the thing I use in production, those kinds of techniques. Like you say, I'm not trying to recreate company logos using all these background gradients, even though you could most likely if you really worked at it. But in those cases you're probably better off bringing in an SVG, but then if you want to have a circle behind it, you just put in a radio in gradient in the background and you're done. So yeah, that sort of experimentation I also find really, really useful. And it's strange to me how uncommon it feels for people to do that, to just mess around with stuff and see how far can I push this? What can I do here that would work in an interesting way. CSSBattle for as much as some of the rules do not appeal to me, so I don't play CSSBattle, I think is interesting for that.
Brian Kardell: What is CSSBattle?
Eric Meyer: CSSBattle is a site where they will put up four images and the challenge is you need to recreate them using only CSS, and you have I think a Div, so it's basically a single Div except gamified. And your score is dependent on how compactly you can do that. So basically the fewer characters you have, the higher your score or the lower your score. I don't remember the scoring exactly, but-
Brian Kardell: Do you get to use a pre-processor?
Eric Meyer: You didn't when it started?
Brian Kardell: Okay.
Eric Meyer: I don't think so, but because it's number of characters like white space counts, which I object to a little bit, which is why I don't play because I'm interested in trying to do these things elegantly and cleverly. I'm not interested in trying to minify them for this particular purpose. I was just wondering, Roma if you have ever messed around with CSSBattle?
Roma Komarov: Yeah, I think a few years back, tried playing a bit. If I remember correctly, they provide PNGs and if I remember correctly, again, they are using a reference implementation in I think Chrome and then make basically a screenshot of it maybe automatically and then you have to recreate it. And this means that whatever you write the system behind it would make a screenshot again, I think in Chrome a specific version of it and that means that you can use whatever Chrome provides and only need to think about it.
Eric Meyer: Yes, thank you. That's part of the scoring I forgot about in addition to the how few characters can you do, there's also render the code you input to an image and then we'll do an image diff on our reference image. So I mean it's interesting and I had fun with it sort of privately, not as part of the competition. I wasn't trying to get on the leaderboards, I was just trying to think of what are ways I could do this that are compact and elegant.
Roma Komarov: I personally, I don't think I continued playing with it mostly because I don't really like to optimize things that far. And some of the techniques that people did come up to optimizing things are very chrome specific, very something that you for sure would not use in production in any way. However, there are sometimes very clever things you could learn from this very tight CSS where you can rely on the specifics of how CSS Parser does things because you can omit a lot of things. You can do a lot of crimes against any style guide of writing CSS and then get a good result on the end. But yeah, I usually like to implement a thing and then move away to the next one instead of spending a lot of time on just one small thing.
Brian Kardell: Could you explain what are some of your experiments? And also maybe a question that you can think about in relation to that is are there any common threads, common building blocks, really important conceptual things that you learn along the way that wind up in just an awfully lot of experiments somehow?
Roma Komarov: Yeah, I would say that the common thread that I try to do is find something that is not possible in CSS and then try to make it possible with any means. Sometimes it goes into quite weird territories and not often something that should be even ever used. For example, when playing with HTML limitations and nesting a link inside the link, you for sure don't want to do this, but sometimes practicality need to find a way to do this in bigger companies when you implement some very complex UIs and it's not always accessible and that's one of the issues. And the common thread is that it often goes into territory where it's not accessible, but it's something that is not possible to do in any other way. And I really like when it's something that was not possible before, but it's now possible due to some weird interactions of new immersion properties. When it's just declarative stuff, it's possible to just do it and maybe even use it in production with some graceful degradation. For example, there's scroll driven animations I think provide a lot of ways to just enhance experience and make things be okay in stable chrome and chromium based browsers, but fall back to some more simple things in other browsers.
Eric Meyer: Yeah, you've been doing a lot with scroll based animation recently. Can you talk about that a little bit? I mean that's a pretty new thing.
Roma Komarov: Yeah, interesting thing that initially when I saw the scroll-driven animation specs, I did not think that I would use them a lot and that I would find a lot of interesting things. Mostly because whenever they were presented they usually were shown as this way of implement some of the shiny promo page like animations when you scroll and things rotate, and appear, and disappear. However, when I started playing with them, the thing that I did realize is that the scroll animations basically provide us a lot of information about both where an element is positioned inside this container related to the scroll, some of the dimensions of an element related to the container. And what we get in the result is like resize observer and intersection observer just with CSS, knowing the dimensions of elements, knowing the positions of elements allow us to do a lot of interesting effects that previously were impossible without involving some JavaScript. Like all the sticky elements, things like when an element becomes smaller when scrolling, developers wanted to have a stuck pseudo-class for sticky elements for quite a long time and Chrome currently is experimenting with providing this as kind of state query. But what I'm thinking about scroll-driven animations actually is a much better fit for this because with just stuck pseudo-class, you have a binary state, the element is either stuck or not. With scroll-driven animations, we can adjust things more gradually based on the position, like how an element relates to an edge of viewport. So in my experiments, in my first article about scroll-driven animations, I did implement header which sticks to the top, but does this gradually resizing its content inside. And yeah, this allows us to achieve the same effect already in stable chrome and yeah, it's really nice.
Eric Meyer: Let me see if I understand this correctly. So instead of doing the thing where you have a sticky header or a fixed header, let's say at the top of the page and then as soon as it gets moved off the page, there's some JavaScript that looks to see are we at scroll position zero? And if we're not, then we're going to add a class to that fixed header and then its height will change. And then with CSS, you can use transitions to make that smoother. Instead, what you're doing is you are using scrolling to animations to basically do all of that. The CSS engine is doing the watching to see if there's been any scroll, and if there's been scroll, then depending on how far the scroll has gone, that header is actually resized. You're not using a transition, you're literally resizing it down as the scroll goes a little bit. So if you scroll just a little bit down, it gets a little bit smaller and then if you go further, it gets smaller and then at a certain point it stops. Did I get that right?
Roma Komarov: Yeah, yeah, correct.
Eric Meyer: Wow.
Roma Komarov: Yeah, with animation ranges, so for timeline ranges, we can control the span over the distance over which this animation happens. So we could have... It starts value, the end value in the key frames and then we can choose where this would happen. So in this example, I'm using a viewport or I think it's actually container height or block container unit to get the element outside of viewport. It's complicated to explain in words, but the timeline range by itself allows us to hook things when elements is scrolled into view it's like from the bottom of the screen or when it's exits the screen from the top. And in this case it's exiting but in reverse. When we show an element appears as if it was exiting, but it's actually appearing. It's a bit complicated to explain, but actually all the view timelines, ranges is really complicated for me to understand. I think Bramus has a good tool to visualize this, but even then, I think even with all my experiments, I still sometimes struggle to really work through what should I use and when should I use something. So I'm really hoping that one day we would have a proper support for scroll-driven animations in dev tools. Bramus also working on an extension for this, but I did test it and there are a lot of limitations to what an extension can do because not everything is provided for us. For example, when we have scroll-driven animation on pseudo-elements, we cannot really get the information about the pseudo-elements in JavaScript reliably. So yeah, there are a lot of cases where Bramus extension does not work, but it still helps a lot in various other cases.
Eric Meyer: Wow. I can imagine that you could do something similar with the page footer as you scroll down to the very bottom on pages that have footers, which should be all of them, but that's another discussion. It gets bigger or a focus mode where the elements that are closest to the center of the viewport have full opacity and the ones towards the edges fade down to say half opacity.
Roma Komarov: Yeah, that's very easy to do one of the probably main usages and it's just-
Eric Meyer: Wow.
Roma Komarov: Just a few lines and you get this.
Brian Kardell: So this obviously sounds like really good feedback into standards and I know that you do open issues and comment on issues in the CSS working group drafts. Another area that I think you're interested in is anchor positioning.
Roma Komarov: Yes, yes. I think maybe with anchor positioning, I returned to doing a lot of experiments. Before that I did not do a lot of them for a few years, but anchor positioning really provides a lot of interesting ways we could do things that we couldn't do ever before just because absolute positioning is something that before you position element, absolutely it does not know about anything around it. You only provide some coordinates to it and that's it. In anchor positioning, we get this ability to hook into the positions of other elements, including other absolutely positioned elements if we want to. And some of the things that are possible are really nice because we can, similar to scroll-driven animations, measure some of the things because we can take positions of different elements, use calculations, min/max and just have a sum or negation to compare values of different anchors and then do things correspondingly. There's so many things that I want to try doing with anchor positioning, but currently not stopped experimenting with it but delayed a bit because I'm waiting for the specification to not finalize but be more stable. Apple provided a lot of feedback and provided their own exploration of how they see anchor positioning and it's very different from what was implemented and specced currently in Chrome. However, I think I would like to see both of them. Apple for example, provides an ability to use grid-like syntax to say, 'This element should be positioned at the start end of this element.' And this can be very good way of defining things without actually getting into the nitty-gritty of inset block start and all of that and using anchor to get coordinates. But at the same time I would like to see both and have this ability to say inset block start anchor named anchor and then calculation and then something else. Because yeah, I would like to have an easy way to do easy things but then have a more complex way of doing more complex things.
Eric Meyer: I've looked through Apple's proposal and yeah, it does do a lot of very interesting things. The one thing that it apparently doesn't do that is a use case near and dear to my heart is you can't really position an anchored thing with relation to the previous anchored thing. When I looked at it, there was no way to say if I'm an image that's being anchored, positioned out into the right gutter, I need to be positioned below any previous image that has been positioned in the same way so that we don't overlap.
Roma Komarov: Yes, I think it has a few differences for this. I think in their original exploration they did mention that, okay, if we're mentioning different elements with the same name, we choose the first one and that was actually the way it was working in Chrome in the first implementation and spec they did, after which I wrote my article and gave some feedback and they did change it. So now the case that you also wrote an article about the side notes, it's possible just because of that. I think there were some other limitations like you cannot use multiple anchors. I think in their proposals they only did talk about when we have a single element, a single positioning context, and a single popover element. That's why I would want to have both proposals combined because in Apple there is also a good way to define tether pseudo-element, which could be often used as an arrow for Popover and which would be automatically positioned between the anchored element and the anchored target. There are a lot of things that can go wrong with it. I did play with what we have now in Chrome to emulate what would happen with the new proposal and it's really powerful. But yeah, I'm just waiting when it would all be finalized so I could play with it more.
Eric Meyer: One of the things that Brian and I were talking about is that in some of your old talks you talked about the subject selector and then there was no subject selector for a really long time and now suddenly we do.
Brian Kardell: Yeah, I noticed that in your Fronteers talk, I was surprised to see that you had something using the subject selector. So the subject selector first appeared in 1999 and a spec in CSS. The subject, the thing that you're writing a rule about is always the last thing. So if you have a complex or compound selector, it's always the thing most to the right. The next obvious question is, but how do you make it about the thing that's over further to the left? And you couldn't. And the answer to that was proposed to be colon subject. And then for a lot of years, very quickly we got to :has(), :has() pseudo-class basically, the thing that we have now, but it was very complex implementation wise and there were big worries about performance because especially at the time, even regular CSS, we had lots of worries about performance. For a little while I was really pushing a lot. In fact, the thing that got me named to the CSS working group in the first place on behalf of the jQuery Foundation was pushing on some of these things that jQuery had including :has(). Because I was pushing on it a lot. There was a renewed discussion and someone, I believe it was [inaudible 00:27:40] suggested that we switch back to the subject idea because it would be easier to implement and that we make it a bang, an exclamation point before the thing that you wanted to be the subject. Which always felt very, very unintuitive myself, but also I thought it was less powerful. But somehow in your demos you had the bang version and who implemented that? That's really surprising to me that there was a prototype I didn't even know about.
Roma Komarov: The key for this is that it looked like it worked. In reality I don't think anyone ever implemented it.
Brian Kardell: Okay.
Roma Komarov: It was one of the things that I like to do is like, okay, here are these things proposed. Here are these things that developers want to do. How could it look like if I would to implement it with what we have now? I think in this case what actually was happening that show two examples. One, in which there's a list of items and we hover over an item and we highlight the one that goes before it and one that goes after it. Highlighting the one that goes after it is possible with just regular CSS, but highlighting the one that goes before it, you might think that, yeah, we need a subject selector or :has(). What I did is cheat around it by placing two sets of elements. One is for interactions, one's for their visual representations. One goes after another and that means if we know the number of elements we could make a selector, like using the next sibling selector like plus, plus plus, plus plus and highlight the element that goes after it, after a while. So in this case, let's say we have five elements, we'll place five elements, then place five more elements and then get selectors like an element hover plus five. Any other elements in the next one that would be the element that shows next to what we want to show. This way we only use the next sibling selector and make it look like we actually have a different element. And this is possible because we know the count of elements and yeah, this is limitations and we also don't get all the positioning that we could do, but still we can fake it, can look at how it could look like. And I think I even did use something like that in production in a few places where you can separate the visual representation of some element from it and place it further into the tree and then just fake this by only using what we have now.
Brian Kardell: I was really fascinated because I don't even run into people who are generally familiar that there was a bang version proposed because it was very brief period of history, like months or maybe not even that, I don't know. But I'm curious now in retrospect because you knew that existed. Now that we have :has(), do you wish that had been the bang or are you happy with :has()?
Roma Komarov: I think I'm happy with :has() mostly because we can use multiples of them and it's becomes a bit more powerful. And just one symbol as a bang, I don't think it's as noticeable as a :has(). I imagine syntax highlighting could help with it, but it also would help with :has(), you could show it in slightly different way if you want. And yeah, I'm very happy that :has() is finally shipping. We got yesterday news that Firefox has an intent to ship it. It was also nice that Nicolas Chevobbe, I think the developer of Mozilla developer tools in Firefox, he said that they did implement a very nice feature where they show if a :has() selector is unbounded and unconstrained, which means that it might be bad for performance. Because yeah, one of the reasons we did not have :has() is because it could potentially lead to performance issues. And if you are placing it without any actual context, like you have space Combinator before :has() and do not add any class names or element names to what you are selecting with :has(), it would mean that it would try to select for every element on a page, go inside of it to the depths of every element inside and would try to find what you're looking for. So we actually had in production, some people started using :has() in some product and we have very big tables with thousands of rows. There could be multiple of tables like that. And at some point it became a bit slow and one of the reasons was because yeah, selectors can be slow and :has() selector produces a lot of overhead for this. So we did introduce a style in through our code base that prevents this unconstrained :has(), and I was very happy to see it yesterday that developer tools and browsers would actually prevent this as well. And I wish developer tools would provide a lot more feedback than they do now. And they're really happy that there are cases like this where we actually get more details about things in CSS. Just very nice.
Brian Kardell: Yeah, we've gotten a lot of really cool things in CSS in the past two years I think. What is something that you see coming up now? Is there something beyond? I guess while you said anchor positioning, is there anything else that you're anxiously waiting to land?
Roma Komarov: I really hope we would get an ability to divide and lose a unit or strip units from values. Basically, for example, when you have some length in CSS, like 100 pixels and then you have one EM, very often what you want to do is to divide 100 pixels by one EM and get a proportion of what is the proportion between these two values, the ratio. Now we can't. We cannot divide things like that in CSS. However, just recently Jane Ori did write an article about how we can do this with some trigonometric functions like tan, atan2 and then provide values and then basically calculate that because we can calculate a degree between two sides of a triangle and then get the ratio from this degree. And by this we can get our value. I think it almost works in most browsers. I don't remember what was the state the last time I saw it. I think it required a lot of things around it because there were bugs in how this attempt to function was implemented, but it also is not applicable everywhere. And I remember playing with it and I crashed Chrome stable, so we had to report about it. So I would really like to see this as a feature because it would open so many things. And yeah, there's so many things in CSS that I would like to see. Too many.
Brian Kardell: To your point about experimenting with things that CSS can't do or that you think it can't do, and also to this point you're saying now where it is possible probably, but it's a lot of complex math functions or something. It would be nice if there was a easier way to do that. I wonder again, one of the reasons that I got into CSS is I would like to also make CSS extensible so that we can do things like that. So there's a proposal for custom functions and it would allow somebody who had those extreme skills to just provide a function that other people could use maybe for two or three people to provide some variance and then for us to see which ones people use and understand. And then it seems like it would be pretty easy to standardize version of that. Do you think that that would be helpful or is that in your opinion, a good idea or a bad idea?
Roma Komarov: Yeah, I think you're talking about some of the Houdini API stuff. I remember seeing some of the experiments when it was implemented in, I think in Chrome. I think it was from Vincent De Oliveira, yes, Vincent De Oliveira. He did a lot of experiments with CSS Houdini and Paint API and doing very wild things. For me-
Brian Kardell: No.
Roma Komarov: Yes.
Brian Kardell: I was just going to clarify. So yes, it is potentially related spiritually to Houdini. I mean it should technically be a part of Houdini except that Houdini is really just a task force that's supposed to be focused on a specific thing. And also a lot of those things are things that the CSS working group also is just focused on. There's a lot of overlap between those two. So the CSS custom functions, there are a few different proposals for that actively, and they're not under a Houdini umbrella, but they're just part of the CSS working group. Although I agree technically you would call that Houdini. The reason I'm not is because most of the work on Houdini has been focused on things that I think are low value targets, like Paint. A lot of that you can do Paint, don't get me wrong. I just don't think it's the thing that anybody really cared about or had a lot of uses for practically. Whereas I think the ability to make custom selectors, custom functions, things like that would open whole new doors, the properties and values API even.
Roma Komarov: Yeah, I think I now understand what you're talking about. We had recently proposal like exploration from Miriam Suzanne about mixins and custom functions. Yes, I would really happy to see anything of that regard. In CSS we have a lot of need to do some more complicated things and mixins and things like that would be really nice to have because it's not even the case of doing what preprocessors do, which provides some ways to abstract something into reusable code. But with CSS, especially with custom properties, there are a lot of things you would want to do dynamically, not as just substitution. The last thing that I was looking at, I think Lea Verou recently did an experiment and showed a CodePen where we could actually now use color-mix to achieve the relative color syntax by define only some of the components of colors. However, the syntax for this is a bit like verbose. You have to write a lot of boilerplate each time you want to modify a color. And a custom mixin or a function in CSS that would output that would be so very useful. I think we could work around this with... The current way to do mixins in success is when you have a star selector and assign some CSS variables there. So whenever you assign a variable, all of them are recalculated. Like every variable that is dependent on this other variable is recalculated on this element. And I think it was also Lea Verou who did write about it the first time I saw it, and this is a way we can do mixins now, but it's very cumbersome. You cannot do multiple calls on the same element for the same mixin as we can say it. We need to duplicate it and have different instances duplicating all the CSS variables which are involved in it. So yeah, having mixins as something native would be very, very, very nice. And I remember a few years ago I was feeling very depressed because we did not get any things in CSS happening. We did not have :has(), we did not have container queries and very often requests for features like that in CSS working group were met with, 'We probably could not do this because of cyclic dependencies.' But at some point it was really nice that we finally got out of that thing where we finally understood that, okay, we can provide some restrictions like with container queries or I think there was some restrictions initially with :has() and then actually get the thing maybe not working at a hundred percent of what we could imagine it could be doing, but still working and covering a lot of use cases. And with that, I really wish and want mixins to actually take some form and be available for us because yeah, it would allow us to write so many abstractions, so many things, much, much more compact way, much more powerful way, and share some of the CSS snippets techniques. Like setting up your CSS grids and whatever with templates and variables in a much more concise way where you could just import some of your mixins, throw down their call in your element and then get everything. And do it dynamically based on some state reusing CSS variables set on parents through inheritance. Yeah, there are so many things that could be possible with mixins.
Brian Kardell: I feel like that ability that you described to make things more compact is secondary to the second thing you described as being able to distribute and share that somehow. I think that would be really key to have a completely portable way to share some relatively complex function that would be out of the capabilities of someone like me, for example, to implement that. But for me to say, 'Yes, that is exactly what I want to do,' and 'Yes, I have that information, let me give it to you and then you can give me back the thing that I need.' I think that would be really awesome. And I think the closest thing that we have to that today is preprocessors that have some ability to have plugins and things.
Roma Komarov: Yes. And I think another thing I was experimenting with slightly and would continue experimenting is how we can use custom elements, web components with CSS this way. Maybe using them for polyfilling some of the techniques because we can have custom element which would come with some CSS, more complex CSS inside. Then we could, if something is not supported, provide an implementation in JavaScript for just that specific thing. And it would just work for browsers which supports something and would be using JavaScript for when it's not supported. It's like lightweight polyfills. The only thing that currently is not very convenient is that in custom elements we have Shadow DOM, we have Light DOM, we can provide built-in styles in Shadow DOM, but we cannot really ship Light DOM styles with a custom element as it is. And I find this limitation slightly frustrating because I very often want to have all the possibilities that custom element can have, but without actually using Shadow DOM. However, maybe some of the possibilities that Shadow DOM provides can be helpful because we can still provide styles with it. And the CSS variables the best thing that they pierce the Shadow DOM. If we have an element, we do something in Shadow DOM and put result as a CSS variable in it, then this variable is available for Element nested in it. And I think that there is a lot of things and possibilities in this area combining CSS variables, Shadow DOM, maybe Light DOM and Custom Elements and doing polyfills with JavaScript in them and mixins would help with it. But for now I really waiting for more Shadow DOM improvements. For example, declarative custom elements would be really nice because for now we still have to use JavaScript to register them. And it would be really nice if we could have some way to just provide, okay, this here is an element, here's some built-in styles. We want to use it without JavaScript. And yeah.
Brian Kardell: Boy, I have so many thoughts on the thing that you're just saying. I'm writing all of them down in a blog post that I've been trying to write for, I don't know, six months. So maybe I'll get around to getting that finished so that I can share them instead of taking a whole bunch of time here after we were already so far into this. But yeah, I agree with you that Shadow DOM is very almost. There's so many good qualities to it and also so many things that are just in the way and frustrating and it feels like we're missing a thing there. But I like your idea of using those today.
Roma Komarov: Yeah, we're waiting for this article. I would be happy to read it.
Eric Meyer: So we've talked a lot about the cool stuff in CSS and cool stuff that's coming. What's your favorite thing that CSS is just now or is just about to start getting?
Roma Komarov: So many things, it's hard to choose one. It's really hard to choose. And also, for example, I really like what we can do with scroll-driven animations, but at the same time I'm slightly anxious about it because okay, for now we have a lot of things with scroll-driven animations that work in Chrome. However, especially a lot of experiments that I do are relying on a lot of other aspects of CSS and the fact that they work in some tandem together, for example, how CSS variables work in animations at all. And we have a lot of browser bugs already filled, for example in Firefox where we cannot use scroll triggered animations using CSS variable because Firefox just does not work with CSS variables in animations the same way there are some other limitations. So even when Firefox would implement scroll-driven animations, it's not certain that all the techniques that I'm coming up with would work there. And one case which I'm really waiting for finally land would be @property. However, it's the same. There are a lot of things @property which allow us to do a lot of very nice effects like providing transitions in animations, providing fallbacks to initial values and a lot of nuances that could potentially be lost when at least initially when it would be implemented in Firefox. Hopefully it would just be a case of filing bugs and waiting for them to be fixed. And it's really nice that we already have a lot of benchmarks of what @property can do by... The already mentioned Jane Ori, Anna Tudor I think did a lot of experiments and really cool animations using a property and storing values length. So yeah, it would be really nice to have it. So many CSS stuff that they would want to see but the main issue is that when it would be interoperable and how could we combine them when all of that would land in browsers. But yeah, I think it's mostly a question of time and patience and filing bugs. And I just recently contributed my first test to platform testing.
Eric Meyer: Nice.
Roma Komarov: Would be happy to try and doing this more.
Eric Meyer: More tests is good. I was going to ask you, if you could wave your magic wand and add one thing to CSS, what would it be? I think the answer to that would be mix-ins based on what you were saying.
Roma Komarov: Yeah, mix-ins would be nice. However, because we already have this exploration from Miriam, it's more likely that we would get it because a lot of other explorations from Miriam ended up revolutionizing the way we write CSS. Yeah.
Eric Meyer: Yep.
Roma Komarov: So yeah, if I would think about something that we probably would not get, I really want to have a lot of things, but probably some magic stuff. I don't know, maybe some typography ability to just use a regular expression and select some text inside the paragraph and style it in some way. We probably would not really get it. I remember reading some issues related to this and there are some underlying issues which prevents us from doing this, like mostly performance and ability to very easily break a lot of things. We get some of it with CSS highlights, which are not really CSS because you have to write a lot of JavaScript for them, but still an ability to just select random, not random, but predefined spans, highlight things based on their content and not position in the line. The issue with that, why I don't think we would get this at least in this decade, I think maybe in the next we would do not get it either is because we already have first line, first letter and they are kind of bad. We have so many issues with the way they work. We have this initial letter property and it also is not completely interoperable. There are so many small issues with them. And yeah, I just don't see this implemented, especially given how hard it to work with texts like with Unicode, with combined letters like emoji or non-Latin stuff. So yeah, it's just something that probably we would never get, but as someone who really likes typography and stuff, yeah, this is something that if I would have a magic wand, give me an ability to do a lot of good typography.
Brian Kardell: It is really an interesting confluence of last questions and comments because I'm really pleased of all the things that we've gotten in CSS and I'm also really pleased that Igalia played a major role in getting almost all of them. And for me, when I came to Igalia, one of the things that I learned that is the thing you were saying about, well there's so many things, right? There's just so many things and you're asking me to pick one. But boy, it's hard because there's things in HML and there's things in CSS and there's some things that are about typography and there's other things that are about the way that you write things and there's other things that are about your capabilities of what you can do. But every browser has to prioritize resources independently for the most part across all of those things. And so getting to the intersection of where they're finally interoperably in all the browsers because everyone has finally prioritized them and shipped them is like, boy, some three-dimensional chess is really not easy. If you had to pick one thing, what thing would it be?
Roma Komarov: Yeah, there's one thing. If it's one thing that could be nice to have, I was playing a lot with multi-column stuff. And one thing that we don't have and we can't really work around well is when we have columns and want them to wrap in a block direction. So we can say, 'Okay, we want to have this multi-column layout, we want to have a certain height of a column.' But when it goes overflowing in inline direction instead of like it is now just going further, we want them to wrap into the block direction. And this prevents us from doing a lot of topography based layouts, which we could do otherwise. And there was an article by Rachel Andrew in 2019 I think, where she talked a lot about various things that we do not have yet in CSS and we still do not have them. This one, one of them. Some of the things that she talks about can be worked around maybe a bit, maybe I would write an article about it. But this one thing could improve a lot of things in how we do it. And multicol layout in itself I think very overlooked. And there are a lot of things that can be improved in it and for developers to use it.
Brian Kardell: So beyond all of the cool stuff we don't have, what do you see coming next for CSS and the use of CSS?
Roma Komarov: I think that with all the possibilities that we are getting with new foundational possibilities that we're getting like layers, container queries, nesting, a lot of other stuff, CSS would become at some point at least complete enough to compete with a lot of the JavaScript solutions that currently exists in a way that people start treating CSS with more respect. And trying to find a solution in CSS because it would be able to provide a lot of solutions in a very good ways with layers, with scopes. I hope we would get them a lot of other things. Creating components would be much, much easier. And especially if we would also work at the same time on improving things in HTML, for example, how Open UI does good great work, like having Popover API, a lot of other things. And I really like how they interact with CSS, with Popover API, having this extension of anchor positioning. I think that a lot of patterns that people usually go to grab a library from NPM and just use it would be just solvable with CSS. Maybe not in a few lines, but in a much more performant accessible solutions. And CSS would become this standard library of things that you're using to implement your websites, your applications, and not using outside JavaScript hacks.
Eric Meyer: Yeah, that would be very cool. Whereas the anchor positioning becomes more settled and maybe some of these other things we'll have to have you come back on and you and Brian can talk about Open UI work and CSS and how those two could work together and synergize as our friends in the corporate boardrooms would say. I mean this has been a great conversation. Really appreciate you coming on Roma. Where can people find you on the internets?
Roma Komarov: Yeah, my website kizu.dev and at my Mastodon, @kizu@front-end.social. The instance in Mastodon by Miriam Suzanne. And there are a lot of front-end developers there. So I would say yeah, go there and find people to follow outside of me as well.
Eric Meyer: Right. So that's K-I-Z-U.dev.
Roma Komarov: Yes.
Eric Meyer: And then @kizu@front-end.social, I think it is. I think if people search for Roma Komarov they should be able to find you-
Roma Komarov: Yep.
Eric Meyer: ... for your Mastodon. Awesome. All right, well thank you so much for joining us. This has been a fantastic conversation and look forward to more CSS experiments on your beautiful blog.
Eric Meyer
Brian Kardell
Roma Komarov