Chrome Ships With This TERRIBLE Code (it took me so long to debug...)

The default user styles are full of questionable choices. This might be the most questionable though, especially when you consider how nye IMPOSSIBLE it was to debug.
SOURCES
/ 1774347141449994736
source.chromiu...
developer.mozi...
wiki.csswg.org...
/ 1774356986110390309
Check out my Twitch, Twitter, Discord more at t3.gg
S/O Ph4se0n3 for the awesome edit 🙏

[@PraiseYeezus]

Webdev is awesome since it makes you work with the two craziest, zany, unpredictable pieces of technology...Javascript and CSS. It's like trying to run a law firm with The Mask and Bugs Bunny

[@everyhandletaken]

😂

[@deadchannel8431]

browsers bro

[@marc-andreservant201]

Yeah, and with some social engineering you can make only :visited pseudo-classes opaque and ask the user to "Click on all the letters Q in the image" to prove they're human. After this first pass, you falsely say they got the Captcha wrong and use the coordinates from the previous round to refine your search if you find anything spicy. By the 2nd "Captcha" you know your user's geolocation and adult video preferences, even through a VPN. The "JS ignores styles applied by certain pseudo-classes" rule only stops Javascript from leaking your history. It can't prevent social engineering that causes the user to leak their history manually.

[@xdarrenx]

It's worse, it's The Mask and Bugs Bunny, that are disguised as Spiderman and Biden, but nothing changes (all the frameworks that pretend to improve things, but just shift shit around half of the time like fashion trends that return after x amount of years have passed)

[@balala7567]

Then web browser development means you work to maintain the thousands of pages of weird, unpredictable, somewhat stupid specifications for these two, while struggling to prevent it from using absurd amounts of resources, and failing.

[@MajorBreakfast]

11:10 "The only thing that's 'cascading' in CSS is the tech debt" 🤣

[@Gamesaucer]

Great line, but unfortunately not true. CSS would be easier if it were. For all the things that cascade, nothing _good_ actually does.

[@modernkennnern]

custom properties cascade - which is incredibly good

[@Gamesaucer]

@@modernkennnern It's only good because it would be inconsistent if it didn't. Any time anything cascades you have to deal with things like specificity, `!important`, layers, user agent stylesheets, and more. Things would be so much easier if nothing cascaded and styles just applied from top to bottom or vice versa. It's not a _great_ solution but at least it doesn't actively make your styles difficult to maintain or impossible to reason about.

[@modernkennnern]

@@Gamesaucer I'd love a world where the only thing that cascades were custom properties

[@Gamesaucer]

@@modernkennnern How exactly are you going to be able to do anything with that? All author styles are in the same cascade layer unless you use `!important` or `@layer`, so making custom properties cascade would have literally no effect if you don't use them. Not to mention, if nothing cascades, `@layer` and `!important` would be completely redundant, so you'd be reintroducing them _just_ for custom properties as the _only_ thing in the language they work on? Are you sure you're not confusing "cascade" for "inheritance" or something? Because those two concepts are completely unrelated.

[@namstel9225]

I've learned to embrace the Computed tab, even just for stuff I made. It gives me a clearer overview of what selectors are targeting a specific property.

[@JorisGriffioen]

Definitely, whenever I don't immediately understand the output, that's the place to look for what is *actually* applied.

[@Atmos41]

Ranting about CSS being hard to debug without using the computed tab is a bit like complaining about how hard an exam is without studying.

[@TurtleKwitty]

@@Atmos41 About how hard an open book exam is without looking at your textbook yup

[@tastingburgers]

@@Atmos41 And what makes it worse is the thing he's complaining is in the Styles tab too. In his own video.

[@EwanHowell]

at 1:47 if you carefully look through the individual frames, you can clearly see the styles you are saying "are not there". it is listed under `dialog:-internal-dialog-in-top-layer`

[@tastingburgers]

Maybe if he didn't have so much --tw- crap there he'd be able see it...

[@edjemonkeys4896]

Wow good spot lol. Hope that chrome dev didn't spend too long trying to replicate this 😬

[@edjemonkeys4896]

@@tastingburgers I love tailwind but yeah it can make reading through the styles a pain. That is why the filter input is there though, surprised he either didn't use that or it didn't find it...

[@JeSuisUnKikoolol]

It actually is in the styles tab too, you just missed it. If you advance frame by frame at around 3:40 you can see it, it's under "dialog:-internal-dialog-in-top-layer". The code you consider "TERRIBLE" is actually the recommended default behavior for browsers (as the url on line 1445 at 5:11 would hint) and isn't even Chrome specific. If you take a second to think about what a modal is, it would make a lot of sense that it doesn't cover the entire screen by default... This video is one giant skill issue

[@tomasvn09]

Probably if it wasn't cluttered with tw variables, he could have seen it

[@infrofl6557]

Most of his videos are originated from skill issues. No reason not to enjoy them though

[@Yxcell]

@@tomasvn09 If he had just used the Filter tool in the Styles tab to search for "max-width" he could have easily seen it.

[@joshix833]

Has he addressed yet that he spread lies about chrome?

[@trildar]

"it would make a lot of sense that it doesn't cover the entire screen by default..." Except that's not the reason for this default. It's addressed at 9:04. It's just to accommodate the default padding and border because content-box box-sizing is a pain. So not really any fault of Chrome but still dumb.

[@Kane0123]

Cascading tech debt… a story of frontend development. RIP to an evening lost of dumb problems.

[@spicybaguette7706]

Definitely make a video about the CSS mistakes! Some of the entries are hilarious

[@Imperial_Squid]

Similarly, a video on The YAML Document from Hell would be great

[@Atmos41]

If you are using the dialog element, you should use it with showModal(). Then you don't need to mess with styling or portals. If you don't want to use showModal(), don't use the dialog element. It is not designed to be used as a div. The problem here is your code, not the dialog element :D

[@Atmos41]

Adding onto the issue: if the dialog is supposed to be shown (and you refuse to use showModal() for good or bad reasons) then it should have the "open" attribute. Otherwise the accessibility will be bad and the behavior will be inconsistent, because closed modals are not supposed to be displayed to the user. Edit: it is worth mentioning that this is not ideal. You should use showModal() with dialogs, otherwise it will open as a non-modal: no focus trapping, no top-layer, no keyboard navigation, etc.

[@EwanMarshall]

Even if you use showModal(), if you want to full screen it, your need to override this default. It will also mess with any other custom sizing. It should at the very least show this exists in the dev tools on chrome.

[@Atmos41]

@@EwanMarshall what you are saying is not true, and it is easy to disprove. I cannot post Codepen links here so you will have to look for it: username atmos4, pen WNWzgyZ. If you wish to try it by yourself: create a dialog, a button to open it with showModal(), then assign 100vh and 100vw to the dialog with pink background color.

[@Atmos41]

@@EwanMarshall KZbin wont let me post Codepen links here, but what you are saying is easy to disprove: all it takes is a dialog element with a button that opens it with showModal, then 100 vw/vh on the dialog and some pink background.

[@Atmos41]

Ignoring browser standards then complaining about them is a bit like using square-shaped wheels on a bike and complaining it doesn't roll.

[@msclrhd]

The WHATWG HTML spec defines the dialog:modal styles, including max-width and max-height with those values, in section 15.3.3 (Rendering > Flow content). The :modal pseudo class is in the CSS selectors 4 editor draft (section 12.2).

[@blessedpigeon6304]

my exact thoughts. now the only mysteries left: 1. why didn't it show in the devtools 2. why this max-width max-height in the spec in the first place... upd: finished the video. second mystery also solved

[@joshix833]

The first mystery is solves at 1:47.

[@invincibearofficial]

So basically, another day in the life of a front-end programmer.....

[@Burnsie]

The new generation of the framework oriented programmer. 🤷

[@helleye311]

I mean, as crazy and annoying as this is (and it should definitely display in the element styles), I don't think modals are supposed to cover the entire screen, so it's a reasonable default for non-framework folks. Still annoying to find.

[@EvanEdwards]

I agree. :modal is right there in the w3c docs, and from there the user-agent css makes sense for the defined intent of the element. A dialog is not just a cute different name for a div. This is a frustration rant... but it does what makes sense.

[@zekiz774]

​@@EvanEdwardsit doesn't show up in the styles tab. That's what's so frustrating

[@EdwinMartin]

@@zekiz774but that’s a Chrome issue and not a CSS issue

[@zekiz774]

@@EdwinMartin Nobody said it's a CSS issue. It's even in the title of the Video

[@tastingburgers]

@@zekiz774 Except it does show up. It's even right there in the video. 1:47 as mentioned by @EwanHowell above.

[@wlockuz4467]

Whenever I run into obsecure issues like this, my first go to is to reproduce in a different browser. You'd be surprised how greatly this narrows down the issue. In this case it may not have helped immediately but if by some chance you inspected Firefox's dev tools, you would've noticed the styles. I know it doesn't have to be this way, but its something that has helped me in past with navigating this stupid mess we call web.

[@tastingburgers]

Except the styles are right there in Chrome too. Just Theo moving too fast to see what he needed to see.

[@KaKi87]

@@tastingburgers Indeed, I was just going to say the same as @wlockuz4467, without double-checking Theo's assertion, but once checking frame-by-frame, turns out you are indeed true. I think he missed it rather than concealing it though.

[@lakhan4164]

1. Never used a modal that occupies the entire screen (seems counter intuitive) 2. From an accessibility/usability perspective if a modal uses the full screen user can get confused hence the style was applied

[@mikopiko]

Nr 2 makes sense

[@k-yo]

I don't think he wanted a Fullscreen modal, but a Fullscreen backdrop.

[@sharkinahat]

Any sufficiently advanced CSS is indistinguishable from magic. -Arthur C. Clarke (probably)

[@jouebien]

the saddest part about border-box is that early versions of ie used to default to border-box. Well I guess ie got one thing right.

[@almcchesney]

Lol how do you not go immediately to the computed tab and see the stylesheet declaration that says user agent.

[@mikopiko]

It's Theo, are you surprised?

[@tastingburgers]

No need to go to Computed. It's in Style. One would see it if one wasn't in a rush to make a rant video crapping on others' work.

[@tastingburgers]

Theo, you need to grow up. A lot of kids watch you and look up to you. Making tantrum videos, for *actual non-issues* (see 1:47 in your own video right here - the thing is right there in the inspector Styles tab) teaches young devs to speak before they think. Or worse, judging by the "yeah same lol" "me too haha" comments - not think at all. With 265K subscribers you need to be better than this. And no, I'm not basing this comment on this one slip-up here. Your attitude generally is "I know better than everyone and I'll be arrogant about it" (when so often you don't know better) is just not a great example to follow. You can do good and teach young devs to think critically. Or you can be just the next youtuber that's here just for the clicks, views and subscriptions.

[@tastingburgers]

​@@liquidsnake6879 Standards exist for a reason - so that things work consistently (for everyone and for a long time). Get rid of standards, and you'll be back to IE days where every browser did whatever it wanted. The point of my post is that people like Theo, with a large number of subscribers need to be more responsible. Instead of acting like a child, and reacting impulsively, he should step back, be a little bit more humble, entertain the idea that the problem might be him missing the thing he is looking for and spend the 15 seconds needed to carefully review the Styles tab before throwing his hands up in the air and shitting on the Chrome team. It'll be better for him in the long run. With each crap take like this, more and more people will realise that he's just full of it.

[@tastingburgers]

​@@liquidsnake6879 What exactly are you arguing for? You and Theo are not arguing against a specific 30 year old piece of the CSS spec. Specifically he's crying about an imagined bug and a specific decision that was made for how dialogs (a brand new element and spec) should look. Because he thinks he knows better. And seems you do too?

[@tastingburgers]

@@liquidsnake6879 The one reset almost everyone does is box sizing (and there are exceptions for sure). It's one line and trivial to. With "nobody actually uses", you are generalising - it's just not the case. There are tons of sites that rely on various defaults and that don't load a reset or don't load the same reset you are loading. Addressing that would not be a light task and the only benefit would be that devs wouldn't need a 5-10 line reset - that's all you will get from this, nothing more - no new features, no new control, no new possibilities. None of this warrants rethinking or redoing the standard or coming up with strict or whatever other modes. There's much more useful things that browsers should focus their efforts on (and they thankfully do, instead of listening to misguided voices like Theo). Regarding the margins on the dialog - why wouldn't they be there? The dialog needs a default appearance. You, like Theo, may not like this particular default appearance, but it's not a subjective matter - it's not up to you, Theo or me for that matter. But for the sake of discussion, let's say the margins shouldn't be there. What other part of the default appearance do you think should be removed? Where do you put the line? Do you get rid of user agent styles altogether?

[@LowPolyPixel]

This is the kind of thing I don't miss in front end dev. I remember years ago doing work with indexed db when safari 8 was a relevant browser. Its implementation was broken where the same keys in different collections overrode each other and we had to fix it with a polyfill.

[@MrSpartanOP]

It seems like it is in the html standard, as linked on the chromium page.

[@1Lll_llllllLLLLllllll_llL1]

lux?

[@yuvalne]

standartisation organisations: define standards browser designers: nice suggestion but I'm gonna politely ignore it.

[@HemstitchedIrony]

This has to be one of the most infuriating types of issues to find in webdev, just something that someone at some point added because they were in a silly goofy mood and makes styling not behave in a predictable way at all. I'd love to see a video on the css design mistakes list.

[@sarahwbs]

The styling is fine, it's the not showing up in dev tools that's the problem.

[@SimonBuchanNz]

​@@sarahwbsas others have pointed out, it totally does show up in there. Just buried by the --tw custom properties.

[@tastingburgers]

If only people applied some thought and checked for themselves before repeating a lie. What a wonderful world it would be. : )

[@mehfooz-ur-rehman]

It's truly remarkable how open web browsers are, providing developers with accessible tools from the get-go. The evolution of technology owes much to the countless developers who, over decades, have tirelessly strived to make even the quirkiest cases function within browser standards. This mindset stems from the belief that every screen is not unique, requiring CSS or JavaScript should adapt seamlessly. However, when we look beyond the web, the story changes. Android's tablet mode and iOS's uniform frontend code across devices remain elusive dreams. While discarding these ideals might seem straightforward, in practice, it's not so simple. Each developer thinks they've found the best approach, yet often fails to grasp why their predecessors made certain choices I love theo's videos but replacing the whole web standard as it stands is not the solution.

[@m4rt_]

maybe css should have a version thing you add to the top of the stylesheet, like you have with file formats, etc. so you do @version 1; or something, and if you don't set it it defaults to the old way, so you can set it to a higher version and have more sensible defaults and not have to worry about affecting old stuff.

[@ralphstube]

Could it be a namespace in html? Potentially browser versions could be added to give Devs the opportunity to remove backward compatibility.

[@nikensss]

The “::backdrop” detail cracked me up. And the “cascading tech debt” was the cherry on top haha very interesting video and very funny at the end

[@verdaderoken]

In 0:41, i believe you could also use `size-screen` to take care of both width and height at the same time

[@shapelessed]

A web developer's life is constant torture. But it has its upsides. You can watch your colleagues suffer as well!

[@bj0rnen]

Technically, :modal is a pseudo-class, not a pseudo-element, as it describes a state of the dialog element rather than a sub-element within it that isn’t part of the DOM. That said, the user agent CSS should still appear in the inspector when said :modal state is active, so it does sound like a Chrome bug.

[@saikouhuebr]

Sometimes I think is better break all the internet if this is the price for better standards... Because... WTF!

[@anthonypace5354]

I learned to use *{margin:0px;padding:0px;border:none;width:100%;height:100%;} then go custom on EVERYTHING else. My css decreased in size because I didn't have to do any weird workarounds, and pixel accuracy went to 100%. Also if you want default behavior, you can do so per element or class/id and it's children can inherit. Try doing 3D in css while relying on the defaults and you will pull out your hair.

[@nilaallj]

I agree with the take that `box-sizing: border-box` should not be added in the UA stylesheet for EVERY new element, because that would make things inconsistent. However some elements, such as buttons and inputs, DO have it in the UA stylesheet, all according to spec. I might be wrong about this, but I think that is because those elements had the border-box behaviour even before the box-sizing property existed. My conclusion is that since there already are inconsistencies, it should be OK to add `box-sizing: border-box` to a new element when the alternative is a bunch of weird spacing hacks from the UA, as if that would make things less confusing?

[@charliecarrot]

I would definitely watch a video going over the css mistakes list. Sounds super fun

[@user-nj1qc7uc9c]

0:50 - 1:23 as someone who isnt a web developer and has little CSS experience, this is how i feel whenever i do anything in CSS

[@abhayvashokan5580]

Devin: Checks Stackoverflow Theo: Gets the answer from Twitter Devin: 😲

[@MachineYearning]

My mans had so much tailwind clutter in his styles that he couldn't find a style that's actually there. This is why you should go through a minimal reproduction before you report an issue, much less make a KZbin video about it.

[@ThatRobHuman]

I'm right there with you on web needing a hard reset. If you end up championing it, promise me one thing: you'll make make sense....

[@CBusschaert]

I'd watch the CSS working group mistake list video 👀

[@Cool_Goose]

Btw, the box-sizing was less of an issue with the borders (yes transparent border) but it was annoying with the padding, since with 100px + padding 20px -> width 140px , this is the one thing IE did right from the start ;) since technically border-box is IE's way.

[@AloisMahdal]

I'm pretty "new" (re-learning after some tinkering ~15 years ago) to CSS so take this with a grain of salt. Seeing Theo, such a frontend demi-god in my eyes be surprised by this... tells me that the CSS learning curve is not just *steep* but steep, then vertical and then steep in the other direction.

[@zig5712]

As a 5 months beginner in the world of web dev, i'm glad to have already gone through this. I'm not too bothered by it since it "just" one more css reset parameter to add. The easy solution as far as i'm concerned would be to have an option to disable the user agent entirely.

[@hvsniddin]

I've just faced this issue TODAY. How i solved it is i looked at the styles of the dialog element and saw that it has the default style of max-width and max-height set to something like calc(100vw - 4rem - 2px). So I've set them to unset in my stylesheet and it's fixed.

[@justjoshingaround]

Quick tip, if you select the "top-layer" chip in the DOM inspector, I was able to find that class being applied.

[@ShadowDrakken]

The "we don't want to break old websites" line is getting seriously stale. Evolve or die. We need to fix these problems because they're just going to continue to pile up until the whole thing collapses and becomes unmaintainable.

[@tastingburgers]

The way CSS maintains backwards compatibility, and the fix for old rules that no longer make sense (like the default box model) is unmatched. You load a 5-10 line reset CSS and you're good to go.

[@ShadowDrakken]

@@tastingburgers great argument for bringing things up to standard. If everyone is already running the resets, they should be standard.

[@tastingburgers]

@@ShadowDrakken Then you break old sites. Just so that you don't add 5-10 lines to your (likely) 1000+ line CSS file.

[@ShadowDrakken]

@@tastingburgers good, break old sites. Move forward, fix the problems instead of piling them up. Stop using bandaids to fix deep rooted problems. If a site is that old and poorly maintained, it deserves to be broken.

[@tastingburgers]

@@ShadowDrakken Careful what you wish for. In 10 years someone like you will advocate that the sites you created and maintain get broken, just so they save themselves 5 lines of code ; ) Straight-forward change-and-break aside, the idea for a "strict" or whatever way of switching behavior can work, but still, you'll be adding that, instead of the 5-10 lines. So you're not really saving a lot of time and effort. I'd much rather browser companies speed up the adoption of great new features, rather than waste time on replacing a 5-10 line reset CSS with a new mode and all the complexities that will come with it.

[@tiruialon]

Hey Theo, I know you probably won't read this but here is a tip. You can enable showing the hidden pseudo elements in the settings of the dev tools. It'll show all shadow roots, and their contained (pseudo-)elements , and make them available for easy inspection. It helps me occasionally. It's interesting how elements like input are actually built.

[@prozacgod]

I think sometimes when people post oddball replies it's because they had half the conversation in their head, and then posted some conclusion the "two of you discussed" as if you supposedly understood the context. In their mind they are dropping pearls of wisdom. I only ... suggest this... because of "reasons" "a friend of mine used to do this...."

[@_Yolandi]

On 3:40 if you go frame by frame ("." key) you can clearly see the max-width/max-height informations in the style tab, you just missed it because of the massive Tailwind Preflight definitions. Not sure about this video, why Chrome gets bashed.

[@Catif8]

I understand the bug about the user agent stylesheet didn't appear. But tbh, the logic about the max-width and max-height is understandable. A dialog is a modal, and why did you want a modal take all your screen ? That sound like a bad idea

[@WooShell]

Knowing Google, they won't fix it in Chrome, they'll force it through into the next HTML/CSS standards revision.

[@fldgr]

I feel like 99% of my problems in UI comes from built-in defaults in browsers.. But the fact that it's not even in the style tab is horrifying.

[@Z4KIUS]

on one hand limiting the size of modal to not allow it to be a complete overlay makes sense on the other put it in docs and the inspectable DOM tree! also, chrome being broken should be a common knowledge already, both from the user and from the dev perspective edit: oh, so that is the default on the saner engine too and it shows it too, cool, means you hurt yourself by developing in the inferior browser, oh well...

[@murtadha96]

Don’t even know what you’re trying to say here…

[@Z4KIUS]

@@murtadha96 the default makes sense, chrome being broken isn't surprising and using inferior tools will always make your life harder

[@minnced]

@@Z4KIUS this is the recommended standard for all browsers and it is documented and it does show in the styles tab, theo just didn't see it.

[@dersuchmann]

Wasn't aware of the "official" list of CSS mistakes until now. Would love to see you go through it.

[@deatho0ne587]

CSS issues and you can not find it in Styles go to Computed. Heck sometimes now I just start with Computed. Not a huge fan of reseting all behavior in CSS, since some of it is decent just things like this can be a major annoyance. I also agree with Kevin on newer elements should just not have the same settings that old ones did.

[@padiengel]

Would love the video on the CSS-bloopers xD

[@RandomGeometryDashStuff]

why you mad at chrome specifically? max-width: calc(100% - 2em - 6px) is also in firefox and epiphany edit: devtools

[@Novacification]

Theo! You should definitely do a video on the list of CSS inconsistencies but since you mentioned the table layout, could you please make a video about tables in general? I feel like I'm losing my mind. This isn't discussed anywhere that I can find. The HTML table element/styling is so bad that at this point people just use DIVs to make tables with complex interactions. It performs terribly but it's somehow easier than dealing with native tables. I was so annoyed by how bad native tables are, that I spent most of my day today trying to figure out how the world of W3C worked on a design and development level but it was super obscure to get into. That's something else I would love to see a video on, since you seem to communicate with a lot of industry people and might have some knowledge on the subject. To me the table element is in dire need of some love but I couldn't find any serious discussions on it anywhere.

[@patricknolen916]

Would definitely watch a video on the design mistakes of CSS. I mean, I watch most of your videos anyway. Yeah, we should haven't to do resets to get back to ground zero just to work on our projects. What about the CSS working group creating a CSS reset? It would reset all browsers to sane standards and be maintained by that group. That might be similar to the strict mode you mentioned.

[@philheathslegalteam]

FYI any styles applied to dialog itself will cascade to :modal pseudo. So you dont need to target it, but it’s still ridiculous.

[@xorlop]

I agree with the spec that there should be min-width for inputs, and this is also not exposed. However, you are correct, there should probably not be a max-width. That does not make a lot of sense. You bring an excellent point that these hidden defaults should be exposed to developers.

[@pokefreak2112]

New HTML5 elements are genuinely some of the most poorly designed stuff ever, would've loved using them but the sane thing to do is to just use divs with aria

[@tastingburgers]

Ah. If only people knew what they're talking about before posting on the Internet.

[@pokefreak2112]

@@tastingburgers Try making an animated accordion using details/summary Or try making a circular indicator Or try styling the builtin html input validation Or try styling number inputs Or try making a [range] slider with a start and end knob instead of just a value knob I guarantee you these elements won't make you life much easier than doing everything from scratch!

[@tastingburgers]

@@pokefreak2112 OK, agreed. Sorry, carried away in the discussion of "this doesn't work as expected" and "it's not there and it should be" and thinking specifically of the supposedly illustrated issue. There's more to be done and have available in terms of control, but that's no reason to make up shit like Theo here.

[@pokefreak2112]

@@tastingburgers Theo's takes are always a mixed bag because he's (self-admittedly) not that good of a programmer That doesn't mean his frustration isn't valid here though. It is trivial to style a div or a paragraph, and really there is no reason that styling a more complex element should be that much harder. You can say it's a skill issue but imo it's a failure on the spec designers part to consider their audience and how they might use these browser features.

[@tastingburgers]

@@pokefreak2112 Here I disagree. Nothing in this particular instance is hard to style. The entire video boils down to him not being able to see where some definitions come from and getting confused and ultimately frustrated about it. But it's right there in front of him exactly where he says it isn't. If he wasn't in a rush to make a rant video (and maybe if he didn't have a ton of meaningless no-value --tw definitions) he would definitely find it. And I find it a bit disrespectful for him to blame others for his own lack of attention/skill/whatever.

[@cem_kaya]

you should see the accessibility bugs in chrome for some reason h4 elements do not work with windows magnifiers screen reader ! where h1 h2 h3 work for some reason ?

[@vitalysuper3193]

You didn’t have to work with REAL chrome bugs, source maps hell, memory leaks, debugger freezes, dev tools crushes, some styles are not showed. AND JS CONSOLE IS ANNOYING! It’s just a disaster to have such bad devtools front end in 2024!!

[@froxx93]

The CSS mistake video would be a fun one

[@mistersimeeec]

The CSS mistakes list is really good, but some of the points on there are not at all clear on first glance / without domain knowledge. So would be a very welcome video.

[@santhosh3374]

I don't know why you didn't check max height and max width for the dialog as your first debug step. In one of my recent projects, I just had to add max-width: none and max-height: none to the dialog element and everything worked.

[@anon_y_mousse]

When you say chrome, do you mean the browser Chrome or the user interface decorations which the browser was named for? In either case, does this affect Firefox as well? Is this part of the standard for CSS or is it specific to the Chromium and/or Chrome source code? Regardless of whether you answer and/or how you answer, I'll keep saying that HTML/CSS/JS need to be wiped clean and a new standard needs to be devised for the internet.

[@spiderico00]

I wish this video existed a year ago when I found the same issue. I figured out the solution but had no idea that was the problem, good to know.

[@tastingburgers]

You may feel better knowing that this wasn't the problem. Not then, not now.

[@spiderico00]

@@tastingburgers I stumbled across the solution by trial and error but had no idea why it worked, I'll never feel better about CSS, lol

[@HHJoshHH]

Make the CSS video! I would watch it. We really don't need any more CSS tutorials on how to set styles for h1. lol. But the intricacies of CSS and Semantic HTML are fun to discuss. imho

[@SXZ-dev]

To answer the "why" it's because the HTML spec defines that itself. But yes, Chrome should expose it as a user agent default

[@tastingburgers]

It does expose it.

[@SXZ-dev]

@@tastingburgers He just showed it doesn't, unless you go to the computed section, which is never the case for the other such examples of similar rules

[@tastingburgers]

@@SXZ-dev 1:47

[@VeniMitev]

I just had this happen at work like 2 hours ago 😂 I was loosing my sh!t for a good hour and I just gave up. Thanks for spying on me and releasing the video just at the right time

[@rickdg]

Kevin be like “ah yes, good ol’ max-width on dialog:modal, amirite?” 😅

[@jfieqj]

What's stopping the CSS Working Group from adding a property like "css-version" that you can add to any element to set the behavior of it and children to a newer or older set of behaviors? Then new pages just add * { css-version: latest; } or whatever to their CSS, and now all elements default to border-box and merges word-wrap into white-space and all the other changes they want to do. I'm sure there's roadblocks with that idea, but it seems like they should at least pursue it at this point.

[@tastingburgers]

Cause it's a non-issue if one knows what they're doing. It would be a waste of time that would be much better used in rolling out new features. Which is exactly what the CSS working groups and browser companies / teams are doing.

[@omega_no_commentary]

What is that browser and how do you have it configured that way? I mean the left vertical bar, and that full screen view n all

[@TeleviseGuy]

Arc Browser, available on Mac, and has a beta waitlist for Windows

[@michaelpumo83]

The problem is that browsers apply their own arbitrary “design” to elements that they could just leave as-is. Why does it even have to have a border? No border, no need for calc on max-width etc. But in any case, everyone should be using Normalize CSS as baseline.

[@stefan1397]

You need to check display shadow dom in chrome. This is the typical: Not a bug but a feature... You can set it up in the chrome dev tools then it displays it in the default style tab

[@Jessyco]

What if we had something like a comment that would enable clean slate rules and enable "proper" things. turning on this flag would come with acknowledgement that it COULD/WILL change things in the future as we discover and define what things should have been. While we're at it, why not have a similar flag for normalizing css so we can get ride of the "reset.css" concept. :)

[@kaas99]

Omg finally somebody is talking about this, this always annoyed me. I wasn't sure how to overwrite this

[@josephconnolly8493]

I would 100% watch that video. Debugging CSS never feels like a good return on investment. There isn't some new cool feature you can point to - just - this box does what you would expect it to do now.

[@tastingburgers]

If one knows how CSS works, debugging it is great. Key word "if". E.g. I too would be frustrated debugging my car, but I don't know cars that well to do that myself so yeah...

[@josephconnolly8493]

@@tastingburgers @Theo - Apparently you just have a skill issue with wasting 45 min on this

[@tastingburgers]

@@josephconnolly8493 Apparently? Obviously.

[@CielMC]

Please I would love a video on all CSS mistakes

[@Gamesaucer]

I'd go one step further than adding a CSS strict mode, and just throw CSS out entirely. And by that I don't mean throwing out the ability to style things the way we can style them with CSS, just throwing out CSS as a way to express that styling. It is fundamentally awful in nearly every way. It's like CSS was _intended_ to be painful to write and maintain. Like, just as an example, there's no way to sort out some specificity conflicts without risking breaking other styles unless you use `@layer` for _everything._ The problem goes like this: You have a rule A with a specificity that's _just_ below rule B. Now you want to write rule C, which is intended to be overridden by the styles in rule A where they both select the same element. _However,_ your selector is complex enough that its specificity is above that of rule B. Since you can't lower the specificity of C, you must raise the specificity of A for your styles to apply in the intended order. This causes another problem, though, namely that now you've inadvertently switched the order in which A and B apply, without touching B at all. Maybe you don't even know B exists at all, because you're working on a codebase that's not entirely your own, or it's just a lot or very old code. But all of a sudden, if A and B ever select the same element, the result is going to be broken styles. And there's no way to catch it until it happens, possibly months later at which point you wouldn't suspect A or B, you'd suspect whatever relevant thing you've most recently been working on, which in the best case scenario would be C. _Not only_ are these bugs hard to catch, it means that to guarantee that your change to A is safe, you must raise the specificity of _every single style rule in your codebase_ higher than A's original specificity (technically you don't have to do it for a rule that's 1-0-0 if A was something like 0-1-0, but ID selectors are bad anyway). The only way around this? Using `@layer` to make specificity non-existent and just have your rules apply from top to bottom.

[@natsuhiboshi7161]

Great video, interesting insight! Would love to see a video on the csswg list. I often get recommended your videos, but I find your thumbnails off putting, personally, which often leads to me not watching. I dislike their clickbaity reaction face nature. Keep it up, either way!

[@ichigo_nyanko]

1:47 dialog:-internal-dialog-in-top-layer

[@RandomGeometryDashStuff]

02:46 dialog:modal selects element that has tag name "dialog" and is modal, not pseudo element like ::before or ::after or ::backdrop

[@neeeeeck9005]

If only we could specify the version of spec we wanted to use explicitly. Either for HTML, JS or CSS.

[@dripcaraybbx]

For the longest time, I've had the hunch that Theo just doesn't understand CSS

[@exxon47_]

I don't know about chrome but Firefox has always required you to turn on a setting to see the default style on all elements

[@Assassin_Duck]

Could CSS4 be an excuse to do breaking changes fix those CSS mistakes? They could make it possible to target either CSS3 or CSS4 in your code and have the browser understand both, so they dont break any sites that dont want to rewrite to any new rules.

[@yuri0001]

"table layout should be sane" Yes, PLEASE

[@atljBoss]

I'd definitely watch a video full off CSS inconsistincies

[@thomassynths]

So it’s not a chrome bug. It’s a css skill issue.

[@jonniem]

why aren’t all css defaults set via css variables that can be exposed in tools and overridden ☹️ I know doesn’t solve this issue necessarily but it might at least make behavior more obvious

[@jamesauble8091]

Is anyone else noticing some weirdness with how the computed tab shows specificity of border widths? I've been running into this more and more often and need to research it.

[@tsukionyt]

this heavily feels like a bad faith, spur of the moment rant, theo. the code you are complaining is "missing" in the styles tab, is literally visible IN the styles tab at least twice. once at 1:47, and going forwards a few frames, and then again at 3:32 on the first or second frame. granted, some of it is hidden behind your webcam at the 3:32 mark, so i'm sure that probably has something to do with missing it

[@sleebu]

they did not commit a code. they commited a crime.

[@SpaceDoodle2008]

This is the prove we should use multiple browsers whenever those problems occur!

[@ChristopherCricketWallace]

But in the interview you have to crush Leet Code to prove your worth. hahahahah

[@henri470x]

i had this issue before, thankfully i have a habit to always check the computed tab first, intensely, when things got funky. I managed to fix it under an hour 😂

[@erzengaming]

There should be a new CSS 4 Version that should fix alot of these issues, it should also include a version: 4; tag at the top of the page to let browsers know they need to use css 4.

[@levyroth]

Using Chrome in 2024 seems to be the main problem here.

[@qm3ster]

What happens if you click on the little arrow at Computed?

[@HikaruAkitsuki]

Even though I'm not writing CSS at all, there is a ton of css that gonna help or ruin my project? Dang.

[@myronkipa2530]

I respect frontend devs more now that I see your struggle