Styling an HTML dialog modal to take the full height of the viewport
til.simonwillison.net
til.simonwillison.net
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_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/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!
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?
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-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.
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.
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.
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.
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.
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
GitHub's new, React-based code viewer aggressively virtualizes the rendered text. Only the lines visible in the viewport, together with 10-20 lines around the viewport, will be rendered. This is why search is broken when using the native browser search (not all text is rendered).
As another comment pointed out, VS Code is capable of opening such large files with syntax highlighting, minimap, etc. VS Code is also employing some form of virtualization. It's unclear why GitHub's file viewer refuses to show files larger than a megabyte or so.
Then why is it so fucking slow all of the time?
Although off-topic for this thread, one minor annoyance is how the "improved" Issues interface no longer displays pagination controls until several megabytes of JavaScript finish loading. Meanwhile the Pull Request page, one of the oldest parts of the GitHub interface, is capable of displaying pagination controls before JavaScript loads, and it's interactive (i.e. clicking on pagination buttons will work as expected, even without JavaScript).
Want to note that web-based UI doesn't have to be this way. In the case of rendering text with syntax highlighting, VS Code shows that it can be done in a performant manner. As for functionality without JavaScript, embracing standard web APIs, etc., that is exactly what frameworks like React Router (formerly Remix) are designed for.
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/acoecgia...
Tachi Code for Firefox: https://addons.mozilla.org/en-US/firefox/addon/tachi-code/
GitHub is not VS Code. GitHub is a Ruby on Rails website with some React sprinkled on. You can't expect the same performance optimization from a website that a whole IDE has.
While surely the text fits, it’s all the stuff around it like rendering and layout that take the memory.
So does Firefox. Enable "Show Browser Styles" in the developer tools settings.
... 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/re...
Here's a GitHub mirror with a commit log view showing changes over time: https://github.com/mozilla/gecko-dev/commits/master/layout/s...
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
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.
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/A...
[1]: https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...
[2]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/di...
Code is here: https://github.com/simonw/tools/blob/main/side-panel-dialog....
Key code is that when you click an item it effectively does this:
sidePanel.innerHTML = '...';
sidePanel.showModal();
You should try using this with a screen reader if you’re able, that’ll let you know where you may need further improvement.
Right now the behavior on the page is that of a dialog and you’re using the (correct if you want a modal) modal API, that will cause issues for users
You should also use the autofocus attribute if you want the modal to focus on something other than the close icon in the corner upon opening
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.
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.
- 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
Example output based on Linux kernel @ "Cregit-Linux: how code gets into the kernel": https://cregit.linuxsources.org/
I learned of Cregit recently--just submitted it to HN after seeing multiple recent HN comments (yours being one I've had open in a tab for a week to remind me! :) ) discussing issues related to line-based "blame" annotation granularity:
"Cregit-Linux: how code gets into the kernel": https://news.ycombinator.com/item?id=43451654
git log -L 120,150:filename.txt
git log -S <the-string>
git log --grep <the-word-or-phrase>
git blame —- $(git grep -P -l 'the.*regex') | grep -P 'the.*regex'
———
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>
Link (not much info there): https://www.jetbrains.com/help/idea/investigate-changes.html...
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.