CSS Proposals and Debates | Igalia - Open Source Consultancy and Development

Igalia's Brian Kardell and Eric Meyer discuss what's caught their eye in CSS of late...

May 28, 2025

0:00

Mentioned Links

Transcription

Brian Kardell: Okay. Hi, I am Brian Kardell. I am a Developer advocate at Igalia.
Eric Meyer: I'm Eric Meyer, also a Developer advocate at Igalia. This week we're going to be talking about just stuff that's caught our attention recently. For me, that'll be mostly CSS. I think Brian has more of a mix of things that have interested him. But yeah, things that the working group has been discussing or has been deciding recently. One of my favorites that's been a topic of discussion over a few working group meetings is, 'What is a hairline?' So the idea is that-
Brian Kardell: And how many angels could dance on it?
Eric Meyer: How many hairlines can we get on ahead of a
tag? Anyway, you have border widths of thin, medium, thick or whatever. And so there's this idea of being able to have a hairline border. And there was some discussion about maybe we should have a hairline unit. So you could have something be two hairlines thick or three hairlines thick. But that really led to the question of, 'Okay, but how thick is a hairline?' And one of the proposals was, 'Well, it should be one hairline thickness should be one device pixel.' Not a CSS reference pixel, but a literal actual display device pixel. Which these days can be incredibly thin. And so there was some concern about, 'Well, maybe that's too thin.' And then, 'Okay well, if we're not going to just go with device pixels,' which could lead to very different results across different devices. If you have a low pixel embedded device then maybe a hairline on that looks much thicker than it does on an iPhone or whatever.
Brian Kardell: I guess there's also a question of whether that's a bug or a feature of that approach.
Eric Meyer: Sure, absolutely. That's part of the discussion. But to me it's sort of captured. One of those interesting things about being involved in CSS discussions. Sometimes you have these discussions that are surprisingly difficult to come to a resolution on. And I use resolution here intentionally, because you could define a hairline very simply to be a device... like a hairline width line is just a row of one row of device pixels. Which could be in some cases a device so high resolution that you can barely see it no matter how high the contrast is. And in other devices, it's very obvious. That's sort of the simplest approach to take if you're not going to do that. If you're going to say, 'Well, we want hairlines to be sort of consistently visible.' Then you're back to how big is a reference pixel, except now it's a smaller reference pixel. And that discussion is still ongoing. If people are interested in joining in with their thoughts on how a hairline should behave across devices and across display surfaces and what you think of as hairline how you might use it, we'll have a link in the show notes to that issue about hairline. And yeah, contribute to that discussion. Because it's not settled. It's still being looted. About for that matter, would you find real usefulness in being able to say, 'I want this thing to be two hairlines thick, but I want this other thing to be five hairlines thick.' Because my recollection is that in the discussion nobody could really come up with a good use case for that.
Brian Kardell: I would like to say at the beginning of this episode that I have been semi-checked out of CSS working group for the last month or so. And so I'm catching up here just like you.
Eric Meyer: Yeah. Well, and I'll be catching up on some of the things that I think you want to talk about.
Brian Kardell: I'd love to have people also just write in and tell us, do you want that?
Eric Meyer: Yeah. I mean there's that as well. There's certainly the position to be made of, 'We shouldn't be wasting our time on this.' As an industry or for that matter as a working group.
Brian Kardell: Very difficult because frequently it involves similar people. I mean, certainly the whole working group has to spend time listening, even if it's to mostly go, 'Sure, I guess we trust the editor,' or, 'We trust the three or four people who are going to talk about this.' But very often the primary inputs are the same three, four, or five people. And if they're doing that, then they're not maybe doing something else.
Eric Meyer: Yeah, they're not doing something else. Yeah. It would be interesting to hear from people to see do you even care? Does this really strike you as angels on the head of a pin kind of discussion? Or as soon as you heard hairline width lines, you were like, 'Yes, that is absolutely a thing that I would love to use.' Let's know. Anyway. Another thing that caught my eye recently--although it's not as recent a topic--was item flow. So listeners probably are familiar with the discussions around Grid and Flexbox. And then there's been masonry layout. We had Rachel Andrew on a few episodes ago to talk about the two sort of viewpoints at that time, which was there was a viewpoint that masonry should be part of Grid layout, sort of like a special kind of Grid layout. And then there was a view that it should be a special kind of Flexbox layout. Or that maybe it should be its own thing. And now there's been a proposal--I read about it in the WebKit blog--basically saying, 'Well, what if we didn't make it really part of either, but we specified item flow?' So we have flex items and Grid items, but we could talk about item flow. And by having certain properties and value combinations we could get masonry style behavior actually kind of out of either Flex or Grid, depending on exactly what kind of masonry behavior you want. And I just thought it was really interesting. I actually wrote a blog post.
Brian Kardell: Yeah, I was just going to say you wrote a really nice blog post on this actually. I will link to that as well.
Eric Meyer: My first blog post in a while. But yeah, we can throw that in the show notes. And the link to the original WebKit blog post, which goes into more detail than mine did. But yeah, it's really interesting how that discussion of, 'Well, do we do it this way or do we do it that way?' Might... And let's be clear, might yield this new way of doing things that actually sort of harmonizes or it brings together Flex and Grid. So instead of being very separate things, they actually start to become different expressions of this item flow idea. So yeah, if you have any interest in masonry layout, which has been a wish list item for a lot of designers for years. And there have been polyfills and JavaScript libraries and such to make it possible with a minimum of scripting. Look into it more and see what you think. I feel like--and I said this in my blog post--that their item flow might actually make multi-col sort of subsume multi-column layout. I think you can just do multi-column layout and different kinds of multi-column layout and more powerful multi-column layout using item flow and not actually having to use the columns property anymore. I'm not a hundred percent sure about that, but I'm like 90% sure that that should work. So yeah, it's an interesting possibility. There's some tantalizing ideas there.
Brian Kardell: This thing that you're saying, we had a perfectly good proposal from masonry back in 2019 or something like that. And a few people were like, 'Eh, but it maybe it's more like this.' And that spent some time developing. And then after some time it was like, 'Eh, but maybe it's more like this.' I do think that each time it gets better, but I also do accept and recognize that sometimes it can be circular. And there's this tension with when do you just ship it? When do you go, 'We will probably have ways to tweak this.' But at some point we need to ship the thing. So yeah, this is an interesting to me example, because I agree with you that what we're talking about here looks actually way more interesting. It's this way to unify the things. Which is a common thing that happens when we sit on something long enough is a bunch of people start to notice, 'Well oh, this and this and this and this. They're all very similar. Maybe we can unify them.' So yeah, I agree. Your last one there is really interesting, the item flow. But I don't know what you think about that comment about how long do we sit on it? I bet if we sit on it for another two or three years debating or fighting about it we'll come up with something that we'll be like, 'Oh yeah, that's even better. Variables is like this in a way. It went through many, many, many versions until finally Tab Atkins came up with this, 'What if they're really basically just custom properties?' And then that was like, 'Yeah, that's the one thing that nobody else can do.' Only custom properties could do that. So yeah, we like that. And I think it's been great. It's been really great.
Eric Meyer: Yeah. I mean yes, if you let something marinate for long enough the flavor profile will change many times. And yeah, I mean given enough time you can eventually get to a much better solution. But yeah, there is always that question of, 'Okay, but how long is too long? When do we actually ship?' And who knows? Right now item flow looks like it's good enough that it could ship to me. But it also hasn't really been subjected to a huge amount of scrutiny, I feel like. I'm always looking for the community to come in and say, 'Okay, well how would I do X with this system?' Or, 'This is how I think I would do this with this system.' Because sometimes that leads to, 'Oh no. Actually we can't do that and that's a problem.' Or, 'That's not how you would do it, but you would do it this other way. But it's interesting that you thought it was this way.' Those sorts of things. So much like with the hairline, if people are interested in that idea or hate that idea we'd really like to see them contribute to that discussion. A good enough proposal hopefully will stand up to scrutiny. And a not good enough proposal will yield to that scrutiny and become a better proposal. That's of course the ideal, whether that always happens is another question. But that's what we're always aiming for.
Brian Kardell: I would say the observation that you made about sometimes somebody brings along a use case and they're like, 'Oh no, you can't do that.' I would say you're underselling that because in my experience it's not sometimes. It's pretty much all the time. The more people you have going, 'Okay, I would like to use this.' And quickly realizing that they can't for the thing that they thought they could and they get feedback back into the system sooner rather than later. That's always a good thing. Because you can prevent design mistakes. You can short-circuit bad problems and things like that. So yeah. Anyway, we can link to those two things. What else you got on your list?
Eric Meyer: I think we're actually going to link to a lot of things. But you just mentioned custom properties, Tab Adkins sort of have that solution for doing variables and CSS. What are the things that got published recently? First public working draft of custom functions, which-
Brian Kardell: I'm excited about that.
Eric Meyer: Okay, tell me why.
Brian Kardell: It's actually how I got into the CSS working group in the first place is because I was frustrated by the fact that there were things that I wanted in CSS, but you couldn't polyfill. I was frustrated by the sort of black boxedness of CSS, whereas in the DOM or in JavaScript, they're kind of soft and malleable. And I could build something that was almost as good as a real thing with a polyfill. And with CSS, I just absolutely could not do that. And just very much leaning into the comment that I just made before we came to this topic, I wanted people to be able to give us some feedback. And so I reached out through a mailing list and I ended up talking to Tab Adkins and Boris Zabarsky from Mozilla, probably hundreds of emails back and forth. And we had sketched out a few custom things like custom pseudo classes, custom aliases for pseudos. And I was really excited custom functions got added to the list in Toronto in 2018 or 2019. And then they just kind of disappeared. I didn't hear anything else about them. So yeah, I'm excited that we're getting somewhere with that.
Eric Meyer: So what's the use case for a custom function?
Brian Kardell: Polyfilling other functions, or in my mind also speculatively polyfilling. I really am still a big believer that at some point if we're to succeed we need to be able to make proposals and then give them to people and let them break it and tell us why it doesn't work and show us the better. Until finally we lay down a cow path and then we can make it native. I really still think that that's a really positive path forward if we can get there. But I think that this version of custom functions is very specifically limited to something that can do math.
Eric Meyer: It seems that way from reading the specification. It seems like that's what all of the examples are showing. And just so we're clear, this should really say custom function values I think for maximum clarity. So a function value is something like the repeat value in Grid where you say, 'Repeat, open parenthesis, three, comma 1fr, closed parenthesis.' And that sets up three Grid tracks that each has a width of 1fr. Or calc is a functional value. And this would allow you to make custom functional value. So you could have a value sort of taking from the specification. You could have a custom functional value called add. So it would be dash, dash, add. And then in parentheses you gave it two numbers. And then the result would be the addition of those two numbers. But it doesn't necessarily have to be numbers. So you can say, 'This function should return a length, this function should return a color.' I mean yeah, I imagine that there could be very, very interesting uses for this. It's just hard to tell how many of them would be possible with this particular specification, this particular version of it. It seems like it's mostly numeric based. And how many times do I want to do math with CSS that I can't do in calc?
Brian Kardell: I mean, I do think that that's part of the idea though, is that in any other programming language we would build an abstraction around some math, right? And so what are the common abstractions? I don't think that there's probably much of anything that you couldn't technically do with all the math functions that we have created. I think you could do most of them with calc anyway.
Eric Meyer: A lot of them.
Brian Kardell: But giving them names and a kind of simple signature allows people to just put a label on it and recall it and say, 'Oh, yeah, that thing. And I don't need to know the math involved.' Which means we can distribute a style sheet that you can import, or maybe it can be a mix in your SAS or whatever.
Eric Meyer: Yeah, I can see where being able to build your own color functions could be interesting. Trying to do calc based color. It's always a challenge really of deciding, 'How much of this do I need to split up? Do I need to have a separate calc for the hue and the this and the that and the other thing.' And this would sort of let you just say, 'I'm going to throw some numbers at this function and then I'm going to get back a color.' And however that color was made, it's going to be a full sRGB or HSL or P3 or whatever color it is that it's being returned. So that could be interesting. And then beyond custom functions, one of the things I noticed in looking over what's being discussed these days is most things are in app blocks, so at function, blah, blah, blah, blah, blah. And at sheet, at layer for specificity layers, obviously AdMedia has been around for a while. We have ad supports. And then one of the things that's being discussed is scroll based queries. They're sort of like media or container queries except they're for scrolling. Which is interesting, being able to do things based on the scroll state. Which you'd use JavaScript for now, but this would be another app block. And then there was a decision to allow container queries to use the sibling counting functions. So you could basically have a container query that says, 'At container blah, blah, blah at container, if there are more than five descendant elements apply these styles.' Which okay, interesting.
Brian Kardell: What's really interesting to me is that, so Alice Boxall who works here now at Igalia, she and I worked on Focus Visible is what it's called now. But before it was even an official Google thing or whatever we thought about and wrote a speculative polyfill, wrote a blog post about it and everything, modality or something like that. And the idea was, 'How are you currently interacting? Are you using the keyboard? Are you using...' But it wasn't even as specific as that. It was just sort of like, 'Are you using sequential focus or are you using non-sequential focus?' So we wrote, I thought a really nice article for O'Reilly and people were kind of excited about it. And then we were called up to have a meeting with some people at Google. And they said, 'But maybe it shouldn't be a at-rule.' Because the thing is when you have an at-rule, if you think about all that has to do, it has to read what are the rules, what are the total set of rules? And then not just what are the total set of rules, but now sort them in terms of origin and specificity. And then once you have all that then only can you determine what is relevant to your tree. And you have to do that kind of node by node. So they were like, 'Yeah, it would be kind of a lot if that's happening maybe multiple times as you're interacting with the screen.' And I totally get that. And I think that the solution we came up with is fine. But now I think you can just about do the same thing with the custom properties and the style queries. And absolutely people will. And also like you say, everything is at-rules now. We have so many at-rules. And it's just interesting to me that it's like, 'Let's not do at-rule because we don't want whole sheets coming in and out of relevance.' There's all kinds of things that media queries are doing now. Like you said, scroll state. A scroll state is going to enable or disable a whole style sheet potentially, right?
Eric Meyer: Potentially. Yeah, and having all these app blocks is... I mean, there's more to talk about. What's interesting to me with this one--the counting functions in container queries--is that it actually grew out of an issue that was opened with a CSS working group that actually asked to disallow the tree counting functions in some contexts. And it was actually disallow mix functions, random functions and tree counting functions in certain contexts. And at this point in the discussion, the tree counting are actually being allowed in container queries. So that like I say, you can say, 'I want to apply if this container has this, some number of children.' But yeah, there's more a app blocks coming seems like all the time. One of the things that you mentioned was... When we were getting ready for the show, one of the things you mentioned was that there's now an explainer for anchored container queries.
Brian Kardell: Yeah, yesterday. Literally yesterday. Was-
Eric Meyer: Right. And anchored anchor positioning has some app blocks in it for fallbacks and tries. Anyway, now we've got apparently anchors and container queries. So have you read the explainer? I haven't had a chance to read it yet.
Brian Kardell: I haven't, but I have a link to it on my screen. I just found it now an hour before the show when we were talking about like, 'Oh, what are we going to talk about?' I did a quick, 'Oh, what's this? This just happened yesterday. I didn't even see it.' So it has to do with the position trie stuff.
Eric Meyer: Yeah. But yeah, so querying containers that are anchored.
Brian Kardell: Yeah, I mean, I guess. It says... Let's see. 'There have been multiple requests to support styling of anchored elements based on the chosen position. So if you are matched at this position at the top, then we need to style tether-like arrows to match the direction of the anchored elements position relative to its anchor.' There's a number of GitHub issues linked. So yeah, it's a way that you would say, 'If you're anchored like this, or if you're matching the fallback,' basically which one are you matching?
Eric Meyer: Yeah. Has the little pop-up showed up above the anchor or below the anchor? To one side or the other? Is it in a corner? Sure. I mean, that makes sense that you would want to be able to style conditional on where the pop-up or where the thing that's being positioned this positioned with respect to its anchor. We're going to have at-rule collapse, basically there's going to be-
Brian Kardell: Well listen to this, 'Chrome Canary 138.0.7194.0 and later has an experimental implementation of this behind a flag.' So we literally just got the explainer added yesterday. And there already is an experimental implementation behind a flag. So at least it's behind a flag. And that's good. That means we can go and not just use our imaginations. We can go and play with it and make sure that we understand. So good.
Eric Meyer: And another chance for people to bring their use case to it. Try it out. See if they can figure out how to make their use case work. And if they can't then come to the discussion and say, 'Here's what I was trying to do. Here's how I tried to do it. It didn't work. Did I do it wrong? Or is it just not possible?' Which is... Yeah, like we said, it's a valuable part of this whole process. I don't want to spend the entire show on app blocks. There are so many now.
Brian Kardell: It's a good segue to one of mine was the at sheet, because I just wanted to say that the folks at Microsoft are working on a number of things. And one of those is at sheet.
Eric Meyer: Which is what?
Brian Kardell: Which is just a way to put it at-rule you say, 'At sheet.' And you can give it a name and then that block, it doesn't apply anywhere by default. So this was first discussed in I think 2023. There's a proposal, it's issue 11509 on CSS working group. It's been open since the beginning of this year anyway. And the idea is this plays very closely with the proposals we were talking about. Earlier in the year we had Mia on. Maybe it was not this year probably. We had Mia on, I think that was a good episode. And we talked about styling in the shadow DOM. And how that gets really tricky. And also how do we make it declarative and make it so that you can sort of import things and say, 'Hey, these things, I'm pulling them from the outer page,' or, 'I have one set of styles that I'm shipping with the outer page for whatever reason. And I want my components to be able to import them.' So you can do a lot of this today, but you have to do it imperatively. You have to polyfill something. You have to sort of make it up. We did it with some sort of hacking. But this is an interesting thing. And there's a kind of related thing in HTML that they're also pushing, which is to be able to use anchor links on link style sheet, like link rel style sheet. Href equals hash-something. And it would refer to the name of a style sheet in the page.
Eric Meyer: So that's sort of what at sheet helps make possible, although there might be other ways to do it.
Brian Kardell: It's one of the things that it would-
Eric Meyer: Right, so you could say at sheet shadow styles. And then have a block of styles. And then in your shadow DOM thingamajig template, whatever. If they're calling them, you can say link rel equals style sheet, href equals octothor shadow styles. And so it kind of reaches up into the parent document and gets that identified at sheet and applies it in its little shadow context, but that you would be-
Brian Kardell: Well, that's tricky because-
Eric Meyer: That's what this proposal talks about doing. And also the thing you were talking about where you could say, 'Link rel equals style sheet, href equals octothor sheet seven,' or whatever. And then somewhere you have sort of an SVG where you have a bunch of definitions of things that you've ID'd then you can refer to them from other places in the SVG. It's sort of like that.
Brian Kardell: It's a bit of an uncanny valley though, because like you say, href and it's not really most other hrefs like we don't have a way to do that kind of thing exactly. And anchors... Sorry, not anchors but the IDs. They don't cross shadow boundaries. For example, if you say, 'Document get element by id.' It will only be in that level of the shadow DOM. It won't go down into or anything. And so it's an example of one of those things that we said earlier where if you hold off, if you wait longer maybe you can make improvements. But then also there's this tension with just shipping the thing. I feel like shadow DOM is one of the things that I wish we would've spent a little bit longer on very early on in retrospect. At the time I was like, 'Please, can we just ship it?' But I feel like we've created a number of problems there. And now we get into all these things that are esoteric and seem a little bit circular. So we have had... In fact, I made one of them a proposal for a more global global. Which is just like, 'No, I really do mean I want to be able to refer to this anywhere at any level of the shadow DOM.' Because globals don't by default to do that today. But we could define a new thing. I mean, we just kind of go in some circles on a few of these things. So it'll be really interesting to see how this plays out. And there's all these gotchas in there that the longer we take on it that things change. So one of the things was very early on people were like, 'Oh, well see every single shadow DOM...' Let's say you have a custom button and I have 47 custom buttons on the page. Every single one of those is importing style sheet. They all have their own copy of the style sheet. And so then they link and then they have to reparse the style sheet. And they have to... They're using all the memory and blah, blah, blah. So we need a solution to that. But well then a few years later, somebody points out, 'Well, that's not really much of a problem anymore because we knew that that was a problem and we just fixed it.' Browsers are really good at identifying that that happens. And they're not using multiple copies of the memory. They do it really fast actually. And then I'll wait a little while longer and somebody says, 'Yeah, but if I mutate one of those, does it mutate all of them? And then if yes, is that a bug or a feature?' So I don't know, it's fun to watch these things play out. It's also a little bit dizzying. And I think it's one of those things that could use more input.
Eric Meyer: Yeah. And I mean, more eyes on any problem is a good thing. And also someone who's listening to this episode might have listened to the last few minutes saying, 'Yeah, I don't care about Shadow DOM.' And that's fine.
Brian Kardell: Yeah, you don't have to.
Eric Meyer: We're going to move off of that in a minute. But the people who do care about shadow DOM should absolutely be sort of pushing on this. I think the point I'm trying to get at is you don't have to be in all of these discussions. It's like find the discussion that really appeals to you or find the discussion about the thing that you really, really want or that you really, really think would be the worst thing ever. And get involved in that discussion. Let other people get involved in the other discussions. So yeah, it would be nice to have more input, more use cases more have-you-thought-abouts on, for example, at sheet and the fragment references of link tags, that sort of thing. There was another one you were talking about. Something about pseudo elements?
Brian Kardell: Yeah, if you don't like shadow DOM, maybe like pseudo elements. Actually shadow DOM can make new pseudo elements so you can both of them. So first, I don't remember why. I was trying to look and see today just before the show if I could find where it came from. But CSS pseudo elements level four newly defines IDL, which if you don't know what IDL is it's like the way that you give a JavaScript DOM shape to something. So what properties does it have? What methods does it have? What do they do? And it's interface definition language. So it's these things that if you scroll through a spec you'll see something that says like, 'Oh, this is on the document or this is on an element. And then here are the properties, here are the methods.' And yeah, there's a whole explainer. It's a big thing trying to figure out. And it's linked to lots of other CSS issues that are trying to figure out all of the twists and the turns and gotchas of, 'Okay, so what if we give you a way to access pseudo elements from JavaScript?' There are a lot of gotchas in there, right? There are a lot of gotchas. And a lot of questions that I would imagine you wouldn't think of anyway if you didn't write browsers for a living. And maybe even if you do.
Eric Meyer: I was literally just going to say, because that happens sometimes in these discussions. Is someone comes in from completely outside the realm of making browsers and says, 'So can I do this?' And everyone says, 'No, but you probably should. And we didn't think of that. That never occurred to us.' So having direct JavaScript access to before and after and first letter and first line and custom pseudo elements, if those ever become a thing. That, yeah, I can only imagine what the... Actually, I can't even imagine what the constraints and parameters of that would be and the, 'If we allow this, what is that going to break?'
Brian Kardell: Yeah, so the basic proposed idea is that you'll just say element, big E elements, like the element object dot pseudo. And then you pass it like a type before or after whatever. And there's just simple things, like what is that? Is it live? Can you change it? If you request it two times in a row and then you say, 'Is A equal to B?' Is it true or not? And to me, I wouldn't actually even have thought of that even though I am an engineer. I would've been like, 'Why would somebody do that? Why does it matter?' I would assume it doesn't matter, but there's a lot of conversation about if it should or not. Yeah so anyway, we'll link the explainer and the explainer links to a dozen different issues that are like, 'Oh, well, what about keyboard handling? Can you have an ad event listener on it? What happens if you change this?'
Eric Meyer: A lot of questions there. I did want to wrap it up with a couple of closely related CSS things. One is a proposal to be able to derive generic shapes from images. So people who've used shape outside might know that you can already sort of do this. With the shape outside for floats, you can point at an image--it could be a PNG, could be an SVG, could be a CSS gradient--then say, 'At a given opacity threshold, that's where I want the edges of this shape to be gotten from.' So you can have a big circle, like a simple SVG circle, but then you can say, 'The shape outside should be taken from basically the 50% opacity threshold of this circle.' And that way you don't have to actually figure out how to type in the circle definition in your CSS. It's taken from the image. You can also do that with a PNG, or I guess with a GIF. But only shape outside can do that at this point. And the idea is, 'Well, how about if we had clip paths or mask paths?' Now that we have a more generic shape, functional value, can we point at an image and say, 'Get your clip path from that, or get your shape path from that.' Whether it's a clip path or a mask path, which I think is kind of interesting. The capability is there shape outside already does it. So there's a path. It's been implemented. Browsers have done it. So this seems like a relatively easy sort of step forward and an easy win to just be able to say, 'That thing that we do for shape outside. We're also going to do it for clip paths and masking paths.' There would be some differences, because those properties do different things. But I find that really interesting.
Brian Kardell: I do find that very interesting.
Eric Meyer: But then that brought up the related question of, 'Okay, so if I have an element that I say I want to mask and I'm going to point at an image at this thing to create the mask. And so I'm going to cut out parts of it, what do we do about hit-testing?' The parts of the rectangular element box that have now been masked away. Not clipped, but masked. Can you still click on them if it's a link or if it has some sort of event handler? Or can you not? Same thing with clip paths. You could maybe make an argument that, 'Well, if I've clipped off the corner with this image shape that I've derived from an image or whatever.' That I shouldn't be able to click there. I clipped it. Or I shouldn't be able to handle events in that area. But what about masks? Masks are not necessarily clips. And for that matter, shapes. Shape outside kind of shapes. Should you be able to click on the thing? Should you bubble an event? And that's still being discussed. It's not clear, because that then leads into questions like, 'Okay, so at what value of the opacity property does a thing suddenly not hit test anymore?' Is it only zero? If I have opacity 0.00000001, will that handle events? And if so, can I then clickjack a site by injecting a thing that just draws a big hyperlink that fills the entire viewport and has an opacity of 0.000001. So no human can perceive it, but when you try to click on something on the page, then it gets intercepted. So should there be some sort of perceivable threshold? And those are questions that have been largely deferred until now when it comes to things like opacity, but they're being re-brought up because if you're deriving a mask from an image, that image might not be simply opaque or transparent. You could be getting it from a gradient image. And so it blends from opacity zero to opacity one. And so at what point does clicking not work anymore? And those are open questions right now, but it's an interesting conjunction of, 'Okay, let's grab things from images.' And an image can be, like I said it can be a linear gradient. And if I have my linear gradient go from transparent black to fully opaque black and then I use that as the masking path or the masking thing for this other element, what effect does that have on hit-testing? And there are a lot of opinions.
Brian Kardell: I don't want to hijack this, but-
Eric Meyer: Well, you can clickjack it's fine.
Brian Kardell: It made me think is the problem that... I should know the answer to this, but I don't. But the problem that you describe, what happens today if I just say, 'Okay, give me a new top Z index. And it's just transparent, but put a click handler.' On it and anything that you click, I'm just going to take it.
Eric Meyer: Yeah. The last time I checked--and it's been a while--I think it was anything above opacity zero could register events. But like I said, that may have changed.
Brian Kardell: This is already a problem then.
Eric Meyer: Sure. It's already a problem. It was sort of the... I mean, it's the mathematically easiest thing to do, right? If it's zero, then nothing. And if it's anything other than zero, then yes. That actually brings up an interesting question. If you're going to restrict the hit-testing based on the mask or the clip, what are the accessibility implications on things like formals, or whatever?
Brian Kardell: That's interesting too.
Eric Meyer: So yeah, anyway. But yeah, there's a lot of questions there. So again, if you're interested in this or any of these other conversations, dive down one of the rabbit holes we'll have in the show links. And participate in the conversation please.
Brian Kardell: Yeah. And all of these were, I know at the beginning of the show you said yours are going to be all CSS and mine will be wider. The only one of mine that's wider is the one in HTML that is about a style sheet link. So it's really still about CSS, but we could maybe think about doing a future show that is wider because there are lots of other things that are developing that are also pretty interesting to watch. And they also could use more participation. So maybe look for that in a future show.
Eric Meyer: Yep. All right. Cool beans. Good talking to you, Brian.
Brian Kardell: Thanks, Eric.