5 ms·

Styling an HTML dialog modal to take the full height of the viewport

75 points by maxloh 2y ago

MortyWaves 2y ago
At this point I’m no longer shocked by shoddy poor defaults for elements or “user agent style” as they like to call it.
- deleted 2y ago
  [deleted]
- deleted 2y ago
  [deleted]
VladVladikoff 2y ago
Seems like a good example of depending on LLMs too much. After the first bad output the next step should have been to open inspector, not to try three more LLMs.
- tonyedgecombe 2y ago
  If your only tool is a hammer then everything looks like a nail.
  - rf15 2y ago
    You are the nail in this metaphor, asking for different hammers to hit you.
- dawnerd 2y ago
  Seriously. This would have been trivial with a few second look in inspector.
- kevmo314 2y ago
  At that point in the article, I thought Natalie was some new LLM I hadn't heard about.
- simonw 2y ago
  I'd looked in the inspector after the first time I saw the gap (just added a note about that to the document) - my problem was that I didn't realize Firefox doesn't show you the default user agent styles, while Chrome does.
  - memhole 2y ago
    So things can be styled based on the user agent? Besides the obvious difference between mobile and desktop.
    - simonw 2y ago
      Yeah, that's why I thought this was worth writing up as a TIL.
      - memhole 2y ago
        Thanks! I had no idea. I have an issue with a large gap on mobile I should dig into. Maybe this will help me figure out how to fix it. Also just a neat fact to know regardless
    - mubou 2y ago
      That's how <b> tags are made bold etc. There's a css file that's basically loaded before everything else to apply those default styles. Here's WebKit/Safari's for example: https://github.com/WebKit/WebKit/blob/main/Source/WebCore/css/html.css https://github.com/WebKit/WebKit/blob/main/Source/WebCore/cs... Try turning on user agent styles & user agent shadow dom in your dev tools settings.
  - smitelli 2y ago
    In FF DevTools, open settings, under "Inspector" check the box for "Show Browser Styles." It clutters the window up some, but I've gotten used to it.
- perardi 2y ago
  No, this is one of those bizarre “wait, really, they put that in the default stylesheet” problems. There is a lot of weirdness lurking in the default user agent stylesheet…especially in Safari: https://blog.jim-nielsen.com/2021/things-i-learned-reading-webkits-ua-stylesheet/ https://blog.jim-nielsen.com/2021/things-i-learned-reading-w... Browser vendors put a lot of surprising, and very poorly documented, defaults into user agent stylesheets, and they can trip you up at the most basic level, and the styling is poorly exposed in most web inspector tooling. I ran into a nasty one with Safari’s date picker—had to go down a lot of rabbit holes to figure out I needed to finesse the `::-webkit-date-and-time-value` CSS to get an input field styled correctly.
  - dartos 2y ago
    I don’t think those 2 problems are mutually exclusive.
  - knallfrosch 2y ago
    I've found that the "Computed Styles" section catches most weirdness quite easily. Remove your own styles, view Computed and you'll see "User agent style sheet" as the source.
    - MrJohz 2y ago
      Even if you don't look at the computed styles, the user agent styles are shown in the default element style view, at least in Firefox. There, you can see all of the applied styles as a stack, so you can see which styles have been applied first, which ones have been overridden, etc. This is a good place to look if you're trying to figure out why an element is behaving weirdly, because it shows all the styles and exactly how they override each other, as well as the source of each style.
  - paczki 2y ago
    Something I discovered while changing the thumb track of a range slider just the other day, is if you add padding-top to the thumb, it will also add padding to the bottom. Even better, you have to set its appearance to none for chromium before you're able to style it in any capacity, which probably makes sense to somebody but not to me.
uallo 2y ago
> I was using Firefox. Natalie pointed out that Chrome DevTools display default browser styles for elements [...] So does Firefox. Enable "Show Browser Styles" in the developer tools settings.
- simonw 2y ago
  Thanks, that's useful - I added that to the document: https://til.simonwillison.net/css/dialog-full-height#user-content-update-firefox-can-show-browser-styles https://til.simonwillison.net/css/dialog-full-height#user-co... ... which also lead me to the html.css stylesheet in the Firefox source code, a really useful reference: https://searchfox.org/mozilla-central/source/layout/style/res/html.css https://searchfox.org/mozilla-central/source/layout/style/re... Here's a GitHub mirror with a commit log view showing changes over time: https://github.com/mozilla/gecko-dev/commits/master/layout/style/res/html.css https://github.com/mozilla/gecko-dev/commits/master/layout/s...
  - uallo 2y ago
    - WHATWG https://html.spec.whatwg.org/multipage/rendering.html#rendering https://html.spec.whatwg.org/multipage/rendering.html#render... - Firefox https://hg.mozilla.org/mozilla-central/file/tip/layout/style/res/html.css https://hg.mozilla.org/mozilla-central/file/tip/layout/style... - Chromium https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/html/resources/html.css https://source.chromium.org/chromium/chromium/src/+/main:thi... - Webkit https://github.com/WebKit/WebKit/blob/main/Source/WebCore/css/html.css https://github.com/WebKit/WebKit/blob/main/Source/WebCore/cs...
zx8080 2y ago
> The spec lives in GitHub in a 7MB source file which is too large to view through the GitHub web interface It's a bit offtopic, but think about it: cannot view the doc despite its size is only 7Mb ~ about 0.04 percent of a typical computer's memory (16Gb). We can open and view PDFs much bigger and search there without an issue in browser. We can view movies worth half of the memory. But it's surprisingly not possible to view a 7Mb text file in the professional tool for working with textual source code called github. Shame. And sad.
- ehutch79 2y ago
  7mb is a LOT of text. More than most epic fantasy novels. While surely the text fits, it’s all the stuff around it like rendering and layout that take the memory.
- sureIy 2y ago
  The file is 142k lines line that GitHub would have to turn into HTML and the browser would have to render immediately. The browser is perfectly able to render the raw file (you can try it yourself) but everything that goes with it would be asking a bit much, particularly because the intent of the author was to blame the file, therefore adding yet more information/elements to the page. While browsers nor GitHub are beacons of performance, I don’t think it's fair in this case. PDFs can be rendered page by page and each page is self-contained. Same with videos, where you read the index and jump to the key frame you're onto, reading data in a highly optimized and parallelized way (often down to the chip). With HTML you must render every letter that comes before line 100000 before rendering line 100000
  - kevmo314 2y ago
    You might be surprised to learn that VS Code renders its viewport with HTML and it has no issues displaying this file.
    - quintu5 2y ago
      Indeed. This is also one of the use-cases I built the Tachi Code browser extension for. It injects a monaco-based editor into the current page when it detects you're viewing a raw file (i.e., the page's rendered body contains nothing other than a <pre> tag). Tachi Code for Chrome: https://chromewebstore.google.com/detail/tachi-code/acoecgiamdjjkhmdodcfdfanfnagamjf https://chromewebstore.google.com/detail/tachi-code/acoecgia... Tachi Code for Firefox: https://addons.mozilla.org/en-US/firefox/addon/tachi-code/ https://addons.mozilla.org/en-US/firefox/addon/tachi-code/
sophiebits 2y ago
For what it’s worth, the “normal” value of max-height is none, not inherit or 100vh.
- simonw 2y ago
  Thanks, I applied that fix (to the document and the example code).
xg15 2y ago
> I also found out today that the HTML Living Standard is very much a living standard - the whatwg/html repo has had 12,318 commits, the most recent of which was less than 24 hours ago. I understand their mission of capturing the messy real-world usages of web technologies and distilling them into a standard, paving the cowpaths etc etc. But I don't see how anything can be called a standard that updates daily.
- ceejayoz 2y ago
  Look at the actual commit. https://github.com/whatwg/html/commit/85effead0a5df3742ebe29387a9c140e0ff108d1 https://github.com/whatwg/html/commit/85effead0a5df3742ebe29... A document of this size will have typos, require clarification, get reorganized. It didn’t fundamentally change here.
- Devasta 2y ago
  In the year 2525, if man is still alive, he may find he has a web page from an unknown time period. To read it, all he'll need to do is reimplement all standards for the previous 500 years. Version numbers wouldn't make this easier at all, somehow.
  - xg15 2y ago
    It will still be served on IPv4 tho.
    - Devasta 2y ago
      And after all their efforts to get the unknown markup into an document form, they'll convert it's contents into the dominant information format of the 26th century: PDF.
bryanrasmussen 2y ago
The fullscreen api allows you to make any element fullscreen. https://blog.logrocket.com/experimenting-with-fullscreen-api/ https://blog.logrocket.com/experimenting-with-fullscreen-api... the article notes some accessibility issues, those have been resolved. on edit: misread title as take full size of the viewport, and not full height. So not necessarily applicable but keep it up as I think it is sort of an interesting Modal strategy.
tomhallett 2y ago
Is there a git gui/extension/etc which makes exploring the git blame similar to what the author did easier? Here is what I find myself doing often: - blame on file - scroll to line 123, click on commit to see the change - ok, that commit wasn’t the “meaningful change” I’m looking for - click on parent commit - browse files (for that sha) - go to file - click blame - scroll to line 123 (or similar) - repeat
- pests 2y ago
  Perhaps not exactly but you can run: git log -L 120,150:filename.txt To see all commits that have touched lines 120-150 in filename.txt, and see those lines. Gives a view into a subset of lines but won't help if the code in question moved out of the line range.
- uhoh-itsmaciek 2y ago
  Not sure about a GUI way of doing this, but in the CLI, I use `git log --patch [path]` all the time. It will show you the history of diffs for that one file.
- belden 2y ago
  If I’m looking for code changes: git log -S <the-string> If it’s commit messages I’m interested in: git log --grep <the-word-or-phrase> Sometimes I want to know “all the commits that introduced a pattern”: git blame —- $(git grep -P -l 'the.*regex') | grep -P 'the.*regex' This last one I use frequently enough that I wrote a little shell script for it, called "git-blep" (for "blame-grep") ——— If there’s a function name that you’re logging, then you might get mileage from git log -L :<the-function-name>:<the-file-name> Though that probably would not have worked in the original author’s case.
- solardev 2y ago
  In Jetbrains you select a line of code and say "show history for selection" and it parses all that for you and just gives you a history of commits affecting that specific line. It's got a built in commit browser and visual diff tool. Link (not much info there): https://www.jetbrains.com/help/idea/investigate-changes.html#view_selection_history https://www.jetbrains.com/help/idea/investigate-changes.html...
bfgeek 2y ago
Yeah - this was arguably mostly my fault (sorry!). There's quite a bit of history here, but the abbreviated version is that the dialog element was originally added as a replacement for window.alert(), and there were a libraries polyfilling dialog and being surprisingly widely used. The mechanism which dialog was originally positioned was relatively complex, and slightly hacky (magic values for the insets). Changing the behaviour basically meant that we had to add "overflow:auto", and some form of "max-height"/"max-width" to ensure that the content within the dialog was actually reachable. The better solution to this was to add "max-height:stretch", "max-width:stretch". You can see the discussion for this here: https://github.com/whatwg/html/pull/5936#discussion_r513642207 https://github.com/whatwg/html/pull/5936#discussion_r5136422... The problem is that no browser had (and still has) shipped the "stretch" keyword. (Blink likely will "soon" - https://groups.google.com/a/chromium.org/g/blink-dev/c/SiZ2nDt3B9E/m/kP_rKOaDAgAJ https://groups.google.com/a/chromium.org/g/blink-dev/c/SiZ2n... ) However this was pushed back against as this had to go in a specification - and nobody implemented it ("-webit-fill-available" would have been an acceptable substitute in Blink but other browsers didn't have this working the same yet). Hence the calc() variant. (Primarily because of "box-sizing:content-box" being the default, and pre-existing border/padding styles on dialog that we didn't want to touch). One thing to keep in mind is that any changes that changes web behaviour is under some time pressure. If you leave something too long, sites will start relying on the previous behaviour - so it would have been arguably worse not to have done anything. It may still be possible to change to the stretch variant, however likely some sites are relying on the extra "space" around dialogs now, and would be mad if we changed it again. This might still be a net-positive however given how much this confuses web-developers (future looking cost), vs. the pain (cost) of breaking existing sites. Sorry!
- simonw 2y ago
  Whoa, thanks for the detailed backstory!
- solardev 2y ago
  Thanks for the details! I wonder, do you think "hidden" behaviors like this discourage lazier devs from using HTML standards and just use divs for everything and reimplement default functionality with 3rd party UI libs?
no_wizard 2y ago
What you built is a dialog, not a modal. The fundamental difference is a dialog isn’t forced to be addressed by the user at any time, and lacks the alert dialog[0] role, at least I don’t see any of this in the example code. I know this seems like pedantic criticism however my hope is to spread some information about the (very real) differences between a dialog and a modal, even though the dialog API doesn’t do a good enough job distinguishing this [0]: The alertdialog role is to be used on modal alert dialogs that interrupt a user's workflow to communicate an important message and require a response
- simonw 2y ago
  Please tell me more! My goal here is absolutely to use the dialog element as a modal - I thought that was what it was for, and that using it in this way has significant accessibility benefits.
  - no_wizard 2y ago
    It is what the element is for. It can be used for both a dialog or modal UI widget. And it can significantly streamline accessibility. MDN has a good overview of the aria attributes associated with modal[0][1] and some more explainer on the dialog API[2] The long and short of it though is modal dialog is generally expected to halt user progression until dealt, where as a non modal dialog does not halt user progression and can be safely ignored from a user perspective. The differences are definitely subtle. It’s also why the dialog element has .show and .showModal as an API, they aren’t synonymous, they actually set different contexts implicitly for accessibility reasons. This is in part some of the criticism that people have of the dialog element, FWIW. There was a debate prior to its introduction to break these two UI patterns into separate elements, one being <dialog> and the other being <modal> so their semantics could be obvious and more easily preserved. I believe the additional complexity wasn’t worth the cost but it does leave this confusing situation about modal vs dialog around. To the create of the committee though it does go a long way in addressing both concerns, even at the cost of “obviousness” [0]: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Attributes/aria-modal https://developer.mozilla.org/en-US/docs/Web/Accessibility/A... [1]: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Roles/dialog_role https://developer.mozilla.org/en-US/docs/Web/Accessibility/A... [2]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog https://developer.mozilla.org/en-US/docs/Web/HTML/Element/di...
bob1029 2y ago
The 8px of body margin is one default style that always catches me off guard. Every time I build a layout I stub my toe on "why do I have overflow?".
fitsumbelay 2y ago
The firefox/browser styles tip is greatly appreciated

75 points by maxloh 2y ago

MortyWaves 2y ago

At this point I’m no longer shocked by shoddy poor defaults for elements or “user agent style” as they like to call it.

deleted 2y ago
[deleted]
deleted 2y ago
[deleted]

VladVladikoff 2y ago

Seems like a good example of depending on LLMs too much. After the first bad output the next step should have been to open inspector, not to try three more LLMs.

tonyedgecombe 2y ago
If your only tool is a hammer then everything looks like a nail.
- rf15 2y ago
  You are the nail in this metaphor, asking for different hammers to hit you.
dawnerd 2y ago
Seriously. This would have been trivial with a few second look in inspector.
kevmo314 2y ago
At that point in the article, I thought Natalie was some new LLM I hadn't heard about.
simonw 2y ago
I'd looked in the inspector after the first time I saw the gap (just added a note about that to the document) - my problem was that I didn't realize Firefox doesn't show you the default user agent styles, while Chrome does.
- memhole 2y ago
  So things can be styled based on the user agent? Besides the obvious difference between mobile and desktop.
  - simonw 2y ago
    Yeah, that's why I thought this was worth writing up as a TIL.
    - memhole 2y ago
      Thanks! I had no idea. I have an issue with a large gap on mobile I should dig into. Maybe this will help me figure out how to fix it. Also just a neat fact to know regardless
  - mubou 2y ago
    That's how <b> tags are made bold etc. There's a css file that's basically loaded before everything else to apply those default styles. Here's WebKit/Safari's for example: https://github.com/WebKit/WebKit/blob/main/Source/WebCore/css/html.css https://github.com/WebKit/WebKit/blob/main/Source/WebCore/cs... Try turning on user agent styles & user agent shadow dom in your dev tools settings.
- smitelli 2y ago
  In FF DevTools, open settings, under "Inspector" check the box for "Show Browser Styles." It clutters the window up some, but I've gotten used to it.
perardi 2y ago
No, this is one of those bizarre “wait, really, they put that in the default stylesheet” problems. There is a lot of weirdness lurking in the default user agent stylesheet…especially in Safari: https://blog.jim-nielsen.com/2021/things-i-learned-reading-webkits-ua-stylesheet/ https://blog.jim-nielsen.com/2021/things-i-learned-reading-w... Browser vendors put a lot of surprising, and very poorly documented, defaults into user agent stylesheets, and they can trip you up at the most basic level, and the styling is poorly exposed in most web inspector tooling. I ran into a nasty one with Safari’s date picker—had to go down a lot of rabbit holes to figure out I needed to finesse the `::-webkit-date-and-time-value` CSS to get an input field styled correctly.
- dartos 2y ago
  I don’t think those 2 problems are mutually exclusive.
- knallfrosch 2y ago
  I've found that the "Computed Styles" section catches most weirdness quite easily. Remove your own styles, view Computed and you'll see "User agent style sheet" as the source.
  - MrJohz 2y ago
    Even if you don't look at the computed styles, the user agent styles are shown in the default element style view, at least in Firefox. There, you can see all of the applied styles as a stack, so you can see which styles have been applied first, which ones have been overridden, etc. This is a good place to look if you're trying to figure out why an element is behaving weirdly, because it shows all the styles and exactly how they override each other, as well as the source of each style.
- paczki 2y ago
  Something I discovered while changing the thumb track of a range slider just the other day, is if you add padding-top to the thumb, it will also add padding to the bottom. Even better, you have to set its appearance to none for chromium before you're able to style it in any capacity, which probably makes sense to somebody but not to me.

uallo 2y ago

> I was using Firefox. Natalie pointed out that Chrome DevTools display default browser styles for elements [...] So does Firefox. Enable "Show Browser Styles" in the developer tools settings.

simonw 2y ago
Thanks, that's useful - I added that to the document: https://til.simonwillison.net/css/dialog-full-height#user-content-update-firefox-can-show-browser-styles https://til.simonwillison.net/css/dialog-full-height#user-co... ... which also lead me to the html.css stylesheet in the Firefox source code, a really useful reference: https://searchfox.org/mozilla-central/source/layout/style/res/html.css https://searchfox.org/mozilla-central/source/layout/style/re... Here's a GitHub mirror with a commit log view showing changes over time: https://github.com/mozilla/gecko-dev/commits/master/layout/style/res/html.css https://github.com/mozilla/gecko-dev/commits/master/layout/s...
- uallo 2y ago
  - WHATWG https://html.spec.whatwg.org/multipage/rendering.html#rendering https://html.spec.whatwg.org/multipage/rendering.html#render... - Firefox https://hg.mozilla.org/mozilla-central/file/tip/layout/style/res/html.css https://hg.mozilla.org/mozilla-central/file/tip/layout/style... - Chromium https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/html/resources/html.css https://source.chromium.org/chromium/chromium/src/+/main:thi... - Webkit https://github.com/WebKit/WebKit/blob/main/Source/WebCore/css/html.css https://github.com/WebKit/WebKit/blob/main/Source/WebCore/cs...

zx8080 2y ago

> The spec lives in GitHub in a 7MB source file which is too large to view through the GitHub web interface It's a bit offtopic, but think about it: cannot view the doc despite its size is only 7Mb ~ about 0.04 percent of a typical computer's memory (16Gb). We can open and view PDFs much bigger and search there without an issue in browser. We can view movies worth half of the memory. But it's surprisingly not possible to view a 7Mb text file in the professional tool for working with textual source code called github. Shame. And sad.

ehutch79 2y ago
7mb is a LOT of text. More than most epic fantasy novels. While surely the text fits, it’s all the stuff around it like rendering and layout that take the memory.
sureIy 2y ago
The file is 142k lines line that GitHub would have to turn into HTML and the browser would have to render immediately. The browser is perfectly able to render the raw file (you can try it yourself) but everything that goes with it would be asking a bit much, particularly because the intent of the author was to blame the file, therefore adding yet more information/elements to the page. While browsers nor GitHub are beacons of performance, I don’t think it's fair in this case. PDFs can be rendered page by page and each page is self-contained. Same with videos, where you read the index and jump to the key frame you're onto, reading data in a highly optimized and parallelized way (often down to the chip). With HTML you must render every letter that comes before line 100000 before rendering line 100000
- kevmo314 2y ago
  You might be surprised to learn that VS Code renders its viewport with HTML and it has no issues displaying this file.
  - quintu5 2y ago
    Indeed. This is also one of the use-cases I built the Tachi Code browser extension for. It injects a monaco-based editor into the current page when it detects you're viewing a raw file (i.e., the page's rendered body contains nothing other than a <pre> tag). Tachi Code for Chrome: https://chromewebstore.google.com/detail/tachi-code/acoecgiamdjjkhmdodcfdfanfnagamjf https://chromewebstore.google.com/detail/tachi-code/acoecgia... Tachi Code for Firefox: https://addons.mozilla.org/en-US/firefox/addon/tachi-code/ https://addons.mozilla.org/en-US/firefox/addon/tachi-code/

sophiebits 2y ago

For what it’s worth, the “normal” value of max-height is none, not inherit or 100vh.

simonw 2y ago
Thanks, I applied that fix (to the document and the example code).

xg15 2y ago

> I also found out today that the HTML Living Standard is very much a living standard - the whatwg/html repo has had 12,318 commits, the most recent of which was less than 24 hours ago. I understand their mission of capturing the messy real-world usages of web technologies and distilling them into a standard, paving the cowpaths etc etc. But I don't see how anything can be called a standard that updates daily.

ceejayoz 2y ago
Look at the actual commit. https://github.com/whatwg/html/commit/85effead0a5df3742ebe29387a9c140e0ff108d1 https://github.com/whatwg/html/commit/85effead0a5df3742ebe29... A document of this size will have typos, require clarification, get reorganized. It didn’t fundamentally change here.
Devasta 2y ago
In the year 2525, if man is still alive, he may find he has a web page from an unknown time period. To read it, all he'll need to do is reimplement all standards for the previous 500 years. Version numbers wouldn't make this easier at all, somehow.
- xg15 2y ago
  It will still be served on IPv4 tho.
  - Devasta 2y ago
    And after all their efforts to get the unknown markup into an document form, they'll convert it's contents into the dominant information format of the 26th century: PDF.

bryanrasmussen 2y ago

The fullscreen api allows you to make any element fullscreen. https://blog.logrocket.com/experimenting-with-fullscreen-api/ https://blog.logrocket.com/experimenting-with-fullscreen-api... the article notes some accessibility issues, those have been resolved. on edit: misread title as take full size of the viewport, and not full height. So not necessarily applicable but keep it up as I think it is sort of an interesting Modal strategy.

tomhallett 2y ago

Is there a git gui/extension/etc which makes exploring the git blame similar to what the author did easier? Here is what I find myself doing often: - blame on file - scroll to line 123, click on commit to see the change - ok, that commit wasn’t the “meaningful change” I’m looking for - click on parent commit - browse files (for that sha) - go to file - click blame - scroll to line 123 (or similar) - repeat

pests 2y ago
Perhaps not exactly but you can run: git log -L 120,150:filename.txt To see all commits that have touched lines 120-150 in filename.txt, and see those lines. Gives a view into a subset of lines but won't help if the code in question moved out of the line range.
uhoh-itsmaciek 2y ago
Not sure about a GUI way of doing this, but in the CLI, I use `git log --patch [path]` all the time. It will show you the history of diffs for that one file.
belden 2y ago
If I’m looking for code changes: git log -S <the-string> If it’s commit messages I’m interested in: git log --grep <the-word-or-phrase> Sometimes I want to know “all the commits that introduced a pattern”: git blame —- $(git grep -P -l 'the.*regex') | grep -P 'the.*regex' This last one I use frequently enough that I wrote a little shell script for it, called "git-blep" (for "blame-grep") ——— If there’s a function name that you’re logging, then you might get mileage from git log -L :<the-function-name>:<the-file-name> Though that probably would not have worked in the original author’s case.
solardev 2y ago
In Jetbrains you select a line of code and say "show history for selection" and it parses all that for you and just gives you a history of commits affecting that specific line. It's got a built in commit browser and visual diff tool. Link (not much info there): https://www.jetbrains.com/help/idea/investigate-changes.html#view_selection_history https://www.jetbrains.com/help/idea/investigate-changes.html...

bfgeek 2y ago

Yeah - this was arguably mostly my fault (sorry!). There's quite a bit of history here, but the abbreviated version is that the dialog element was originally added as a replacement for window.alert(), and there were a libraries polyfilling dialog and being surprisingly widely used. The mechanism which dialog was originally positioned was relatively complex, and slightly hacky (magic values for the insets). Changing the behaviour basically meant that we had to add "overflow:auto", and some form of "max-height"/"max-width" to ensure that the content within the dialog was actually reachable. The better solution to this was to add "max-height:stretch", "max-width:stretch". You can see the discussion for this here: https://github.com/whatwg/html/pull/5936#discussion_r513642207 https://github.com/whatwg/html/pull/5936#discussion_r5136422... The problem is that no browser had (and still has) shipped the "stretch" keyword. (Blink likely will "soon" - https://groups.google.com/a/chromium.org/g/blink-dev/c/SiZ2nDt3B9E/m/kP_rKOaDAgAJ https://groups.google.com/a/chromium.org/g/blink-dev/c/SiZ2n... ) However this was pushed back against as this had to go in a specification - and nobody implemented it ("-webit-fill-available" would have been an acceptable substitute in Blink but other browsers didn't have this working the same yet). Hence the calc() variant. (Primarily because of "box-sizing:content-box" being the default, and pre-existing border/padding styles on dialog that we didn't want to touch). One thing to keep in mind is that any changes that changes web behaviour is under some time pressure. If you leave something too long, sites will start relying on the previous behaviour - so it would have been arguably worse not to have done anything. It may still be possible to change to the stretch variant, however likely some sites are relying on the extra "space" around dialogs now, and would be mad if we changed it again. This might still be a net-positive however given how much this confuses web-developers (future looking cost), vs. the pain (cost) of breaking existing sites. Sorry!

simonw 2y ago
Whoa, thanks for the detailed backstory!
solardev 2y ago
Thanks for the details! I wonder, do you think "hidden" behaviors like this discourage lazier devs from using HTML standards and just use divs for everything and reimplement default functionality with 3rd party UI libs?

no_wizard 2y ago

What you built is a dialog, not a modal. The fundamental difference is a dialog isn’t forced to be addressed by the user at any time, and lacks the alert dialog[0] role, at least I don’t see any of this in the example code. I know this seems like pedantic criticism however my hope is to spread some information about the (very real) differences between a dialog and a modal, even though the dialog API doesn’t do a good enough job distinguishing this [0]: The alertdialog role is to be used on modal alert dialogs that interrupt a user's workflow to communicate an important message and require a response

simonw 2y ago
Please tell me more! My goal here is absolutely to use the dialog element as a modal - I thought that was what it was for, and that using it in this way has significant accessibility benefits.
- no_wizard 2y ago
  It is what the element is for. It can be used for both a dialog or modal UI widget. And it can significantly streamline accessibility. MDN has a good overview of the aria attributes associated with modal[0][1] and some more explainer on the dialog API[2] The long and short of it though is modal dialog is generally expected to halt user progression until dealt, where as a non modal dialog does not halt user progression and can be safely ignored from a user perspective. The differences are definitely subtle. It’s also why the dialog element has .show and .showModal as an API, they aren’t synonymous, they actually set different contexts implicitly for accessibility reasons. This is in part some of the criticism that people have of the dialog element, FWIW. There was a debate prior to its introduction to break these two UI patterns into separate elements, one being <dialog> and the other being <modal> so their semantics could be obvious and more easily preserved. I believe the additional complexity wasn’t worth the cost but it does leave this confusing situation about modal vs dialog around. To the create of the committee though it does go a long way in addressing both concerns, even at the cost of “obviousness” [0]: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Attributes/aria-modal https://developer.mozilla.org/en-US/docs/Web/Accessibility/A... [1]: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Roles/dialog_role https://developer.mozilla.org/en-US/docs/Web/Accessibility/A... [2]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog https://developer.mozilla.org/en-US/docs/Web/HTML/Element/di...

bob1029 2y ago

The 8px of body margin is one default style that always catches me off guard. Every time I build a layout I stub my toe on "why do I have overflow?".

fitsumbelay 2y ago

The firefox/browser styles tip is greatly appreciated