Chrome Ships With This TERRIBLE Code (it took me so long to debug...)
Vložit
- čas přidán 7. 04. 2024
- 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.chromium.org/chromium/...
developer.mozilla.org/en-US/d...
wiki.csswg.org/ideas/mistakes
/ 1774356986110390309
Check out my Twitch, Twitter, Discord more at t3.gg
S/O Ph4se0n3 for the awesome edit 🙏 - Věda a technologie
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
😂
browsers bro
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.
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)
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.
11:10 "The only thing that's 'cascading' in CSS is the tech debt" 🤣
Great line, but unfortunately not true. CSS would be easier if it were. For all the things that cascade, nothing _good_ actually does.
custom properties cascade - which is incredibly good
@@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.
@@Gamesaucer I'd love a world where the only thing that cascades were custom properties
@@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.
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.
Definitely, whenever I don't immediately understand the output, that's the place to look for what is *actually* applied.
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.
@@Atmos41 About how hard an open book exam is without looking at your textbook yup
@@Atmos41 And what makes it worse is the thing he's complaining is in the Styles tab too. In his own video.
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`
Maybe if he didn't have so much --tw- crap there he'd be able see it...
Wow good spot lol. Hope that chrome dev didn't spend too long trying to replicate this 😬
@@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...
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
Probably if it wasn't cluttered with tw variables, he could have seen it
Most of his videos are originated from skill issues. No reason not to enjoy them though
@@tomasvn09 If he had just used the Filter tool in the Styles tab to search for "max-width" he could have easily seen it.
Has he addressed yet that he spread lies about chrome?
"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.
Cascading tech debt… a story of frontend development. RIP to an evening lost of dumb problems.
Definitely make a video about the CSS mistakes! Some of the entries are hilarious
Similarly, a video on The YAML Document from Hell would be great
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).
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
The first mystery is solves at 1:47.
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
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.
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.
@@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.
@@EwanMarshall CZcams 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.
Ignoring browser standards then complaining about them is a bit like using square-shaped wheels on a bike and complaining it doesn't roll.
So basically, another day in the life of a front-end programmer.....
The new generation of the framework oriented programmer. 🤷
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.
Except the styles are right there in Chrome too. Just Theo moving too fast to see what he needed to see.
@@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.
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.
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.
@@EvanEdwardsit doesn't show up in the styles tab. That's what's so frustrating
@@zekiz774but that’s a Chrome issue and not a CSS issue
@@EdwinMartin Nobody said it's a CSS issue. It's even in the title of the Video
@@zekiz774 Except it does show up. It's even right there in the video. 1:47 as mentioned by @EwanHowell above.
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.
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.
Lol how do you not go immediately to the computed tab and see the stylesheet declaration that says user agent.
It's Theo, are you surprised?
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.
Any sufficiently advanced CSS is indistinguishable from magic.
-Arthur C. Clarke (probably)
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
Nr 2 makes sense
I don't think he wanted a Fullscreen modal, but a Fullscreen backdrop.
It seems like it is in the html standard, as linked on the chromium page.
lux?
I would definitely watch a video going over the css mistakes list. Sounds super fun
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
Would love the video on the CSS-bloopers xD
Wasn't aware of the "official" list of CSS mistakes until now. Would love to see you go through it.
standartisation organisations: define standards
browser designers: nice suggestion but I'm gonna politely ignore it.
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.
Could it be a namespace in html? Potentially browser versions could be added to give Devs the opportunity to remove backward compatibility.
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.
The styling is fine, it's the not showing up in dev tools that's the problem.
@@sarahwbsas others have pointed out, it totally does show up in there. Just buried by the --tw custom properties.
If only people applied some thought and checked for themselves before repeating a lie. What a wonderful world it would be. : )
In 0:41, i believe you could also use `size-screen` to take care of both width and height at the same time
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.
Quick tip, if you select the "top-layer" chip in the DOM inspector, I was able to find that class being applied.
id love a video of that css mistakes list
A web developer's life is constant torture.
But it has its upsides.
You can watch your colleagues suffer as well!
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.
I'd watch the CSS working group mistake list video 👀
Please I would love a video on all CSS mistakes
Sometimes I think is better break all the internet if this is the price for better standards... Because... WTF!
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.
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.
The CSS mistake video would be a fun one
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.
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.
@@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.
@@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?
@@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?
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 CZcams video about it.
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.
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.
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?
Jesus Cristo, I ran into this already. I didn't know it was a Chrome messup
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
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
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.
Just yesterday, i was trying to (and failing) to style :cue pseudo-class on video captions, so i feel this.
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...."
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.
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
Arc Browser, available on Mac, and has a beta waitlist for Windows
"table layout should be sane"
Yes, PLEASE
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.
Omg finally somebody is talking about this, this always annoyed me. I wasn't sure how to overwrite this
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.
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
Web dev experience is you suffer with the tech you have to use and wish you can create a better tool. But in the end that tool also have to work with the other bad ones.
FYI any styles applied to dialog itself will cascade to :modal pseudo.
So you dont need to target it, but it’s still ridiculous.
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.
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....
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.
You may feel better knowing that this wasn't the problem. Not then, not now.
@@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
I'd definitely watch a video full off CSS inconsistincies
Kevin be like “ah yes, good ol’ max-width on dialog:modal, amirite?” 😅
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
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
Knowing Google, they won't fix it in Chrome, they'll force it through into the next HTML/CSS standards revision.
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
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.
No way I had this exact problem 2 days ago and I was testing between firefox and chrome back and forth, and I just gave up.
This is so terrible I didn't even consider that this is even possible lmao
Would it be easier to find this hidden styling with shadow DOM enabled for the elements tree?
This is the same experience when using a library that does too much internally. Fortunately this is fixable with css.
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.
But in the interview you have to crush Leet Code to prove your worth. hahahahah
Sounds more like a Tailwind bug, due to the missing reset.
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.
I would love the mistakes in CSS vid
That code was written on friday for sure.
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.
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.
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 ?
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!
For the longest time, I've had the hunch that Theo just doesn't understand CSS
This is the prove we should use multiple browsers whenever those problems occur!
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...
Don’t even know what you’re trying to say here…
@@murtadha96 the default makes sense, chrome being broken isn't surprising and using inferior tools will always make your life harder
@@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.
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 😂
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.
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.
Devin: Checks Stackoverflow
Theo: Gets the answer from Twitter
Devin: 😲
And…neither of them are likely to be correct, because complexity exists. Devin sucks, believe that.
aah the daily troubles of a frontend engineer
I think there is also no normal way to include a js selectbox or anything that would go outside of the bounds of dialog
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!!
I guess they were too busy turning Chrome into an ad-forcing machine.
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.
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.
@@tastingburgers great argument for bringing things up to standard. If everyone is already running the resets, they should be standard.
@@ShadowDrakken Then you break old sites. Just so that you don't add 5-10 lines to your (likely) 1000+ line CSS file.
@@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.
@@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.
I respect frontend devs more now that I see your struggle
Had this happen to me at work too, went through the same trouble before finding it
Why do you have a full size dialog though?
1:47 dialog:-internal-dialog-in-top-layer
Yes.... I ran into this problem last 2 weeks when I was working on a generic modal with the dialog element.. Very silly
I'm one minute in. Isn't it max height? Max width? What about doing negative margin or padding for chrome as a tempfix? Doesn't the dialog have some kind of a custom viewport? Why not try setting the dialog styling? Like padding 0 and margin 0 again?
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.
What’s the advantage of using dialog:modal vs just having your own div container that acts the same