[HN Gopher] The <Dialog> Element
___________________________________________________________________
The <Dialog> Element
Author : cardamomo
Score : 297 points
Date : 2023-02-12 03:51 UTC (19 hours ago)
(HTM) web link (developer.mozilla.org)
(TXT) w3m dump (developer.mozilla.org)
| transfire wrote:
| Masters of convolution.
|
| > the returnValue property gets set to the value of the button
| that was used to save the form's state.
|
| So a more complex form will have to shove all its data into a
| single attribute for retrieval? Notice the example provide
| returns the favorite animal as "cancel" if you hit cancel.
| projektfu wrote:
| You should be able to access the form elements directly after
| the dialog is closed. The returnValue tells you which button
| was pressed.
| squeaky-clean wrote:
| The example is a bit weird though. Rather than accessing the
| form elements to get the data, it pushes it into the "value"
| property of the confirm button.
|
| So if you select an animal, returnValue is that animal, but
| if you click cancel, returnValur is "cancel". Which feels
| very clunky if you were to scale this behavior to any kind of
| complex form. I suppose the intention here was to show that
| it can be a dynamic value. // "Favorite
| animal" input sets the value of the submit button
| selectEl.addEventListener('change', (e) => {
| confirmBtn.value = selectEl.value; });
| runarberg wrote:
| I agree. I've been using the <dialog> element at work for a
| few years now (with the polyfill). At first I experimented
| with using the returnValue, but as time went on I
| completely abandoned it in favor of just saving the form
| values in memory on confirm, and working with that.
|
| Basically I listen to the submit event of my <form
| method="dialog"> which I preventDefault, then I close the
| dialog with a value of "confirmed" and fire a custom
| "confirm" event with the form values as detail. As for
| dismissing the form (e.g. the top x-mark or a cancel
| button), I have a non-submit button which resets the form,
| closes the dialog with a value of the empty string. I also
| listen to the cancel event on the dialog (e.g. user presses
| the escape key) and run the same dismiss method.
|
| I guess my returnValue is therefor the empty string on
| cancel and a static "confirmed" on confirm, but honestly
| I've never actually used it outside of my initial
| experimentation when I felt like I should.
| projektfu wrote:
| Yeah, I agree. Looking at GitHub it's not very popular and
| hasn't developed an idiomatic style of use. Most of the
| uses I saw were homework assignments.
| wizofaus wrote:
| Anyone seeing that the topic tag for comments on this thread is
| truncated after the "The", presumably something to do with the <
| character?
| Mindless2112 wrote:
| on: <a href="item?id=34759527">The <Dialog> Element</a>
|
| Looks like the title is not properly escaped.
| taspeotis wrote:
| XSS here we come...
| sotrue5 wrote:
| https://news.ycombinator.com/item?id=34760481 doesn't work
| :(
| dang wrote:
| Whoops. Should be fixed now. Thanks!
|
| (This is related to a change I made a month or two ago.)
| rado wrote:
| Tried to make it useful here: https://radogado.github.io/n-modal/
| vxNsr wrote:
| > _It is important to provide a mechanism to close a dialog
| within the dialog element. For instance, the Esc key does not
| close non-modal dialogs by default, nor can one assume that a
| user will even have access to a physical keyboard (e.g., someone
| using a touch screen device without access to a keyboard)._
|
| Well this is annoying as a user. Not being able to click away or
| use escape to close it feels like built in pop up that can't be
| ignored.
| tgv wrote:
| Well, you'll just have to add event handlers. And some styling.
| Just like before. I don't think this element is so great. It's
| an easy one if you've got a simple HTML document and you need
| to throw in a rarely used dialog, sure, but once you want to
| build a page with more interaction, you're going to end up with
| Vue, React, etc., for which better dialog components exist.
| pickpuck wrote:
| > For instance, the Esc key does not close non-modal dialogs by
| default
|
| Modal dialogs are the ones that pop up on the screen and take
| over the main experience. Those come with escape key. I think
| you have to program the click-away with JavaScript however.
|
| Non-modal dialogs are uncommon, but basically they are more
| like menu pop-ups that can be ignored when open, so no need for
| escape key.
| runarberg wrote:
| I was recently refactoring the dialogs at work where I
| inherited a codebase with a few different custom
| implementations of equally many dialogs. Some of those had
| the click outside handler closing the dialog, others didn't.
| So I went outside to the world wide web to see how other apps
| do this to pick one consistent experience.
|
| What I saw is there is no consensus on whether clicking
| outside should close a modal dialog or not. A menu dialog,
| sure, but a modal dialog was all over the place.
|
| I went with not closing on outside press. My reasoning is
| that perhaps the user had filled up some form or done some
| other stateful interaction with the dialog's content, and
| then clicked outside on accident (perhaps missed the submit
| button because their mouse was jerked around, or they are on
| a very small touch-screen) that would be annoying to have to
| reopen the dialog and re-enter those values.
| userbinator wrote:
| At least this should theoretically make it easier to block those
| horrible popup modals, if they're all grouped under one element:
| dialog {display:none}
| coldpie wrote:
| In the meantime, NoScript[1] frequently avoids popups entirely
| by just showing the page contents with no JS at all, and Kill
| Sticky[2] cleans up the pages that require JS to show you the
| content you actually want. As a bonus, it also nukes those
| stupid sticky headers!
|
| [1] NoScript for Firefox (incl. mobile) & Chrome-based desktop
| browsers: https://noscript.net/getit/
|
| [2] Kill Sticky bookmarklet for all browsers including mobile:
| https://github.com/t-mart/kill-sticky
|
| Or, a Firefox extension that adds a toolbar button:
| https://addons.mozilla.org/en-US/firefox/addon/kill-sticky/
| crazygringo wrote:
| +1 for Kill Sticky. I map a hotkey to it and I can't imagine
| using the web without it anymore.
|
| It kills every annoying modal and gives 100% of window height
| to content instead of annoying headers and footers.
|
| Between Kill Sticky and an ad blocker, it basically feels
| like using the web as it was originally intended. For
| content.
|
| (Also an extension to stop videos from auto playing, ever
| since that scourge started a few years ago.)
| zagrebian wrote:
| Not a chance. The websites with the worst popups probably
| couldn't care less about something like <dialog>. It's all
| <div> and JavaScript for them.
| zrobotics wrote:
| Plus, the worst offenders have a vested interest in making
| those hard to block. For example, my 2 common offenders are
| Twitter and reddit displaying modals on mobile prompting for
| app download. Both companies have no interest in making these
| easy to block.
| djbeadle wrote:
| Supported on all major browsers and 93% of total users according
| to caniuse.com
|
| https://caniuse.com/?search=dialog
| Raed667 wrote:
| now go convince a product-manager that it is fine that 7% of
| the users can't see the login dialog.
| spiffytech wrote:
| I've noticed that adoption frequently slows to a crawl at
| around 95% or so.
|
| E.g., the JS `await` keyword, which started rolling out in
| 2016, is at 95%. CSS Variables haven't reached 97%.
|
| Past some point, you'll be waiting indefinitely for
| incremental adoption, and that point comes at a lower
| percentage than I'm happy with.
| tomxor wrote:
| It's because of safari. Same problem used to be with IE
| where computers/OS were stuck with a specific version. Now
| the world has moved onto evergreen browsers which are no
| pinned to OS versions (except for Apple).
| philistine wrote:
| Apple upgrades the desktop version of Safari for two
| versions behind the current OS. It's iOS that's tied to
| the browser.
| alerighi wrote:
| Safari is the new IE. From one point of view it's good
| that Apple still develops his browser and didn't choose
| to use Chromium like all the others (except Firefox), but
| from another to this day keeping up with all new web
| features and standard is not a simple thing. Safari
| usually is the last to implement modern web features.
| marcosdumay wrote:
| Seems to be Opera Mini at 1.1%, and IE adding up to around
| 0.6%, so no feature ever gets more than 98%. Also, the
| browsers that never support anything seem to be mostly
| desktop ones.
| stocknoob wrote:
| 93% of users; what % of revenue?
| Raed667 wrote:
| I have yet to work at a company that provides a dashboard
| that shows revenue by browser features
| baq wrote:
| Don't forget to set up the cost next to revenue if you go
| this way, and let your security team know
| 1123581321 wrote:
| We had this set up in 2014. Unfortunately, it was used to
| justify supporting ie8 as long as possible.
| LAC-Tech wrote:
| Sounds like a case of "be careful what you wish for, it
| might just come true!"
| drbacon wrote:
| 100% if used for login. /s
| acdha wrote:
| This is a valid concern but it comes with the caveat that you
| have to measure actual user-base. For example, in this case
| that's the stragglers using IE11 years after it being out of
| support. That might not be something you care about at all if
| you don't support that for other reasons such as security,
| and if there's a functional polyfill you might use that so
| the cost is shifted to the people who don't upgrade.
|
| Above all, I'd check your own site data: Can I Use has to use
| public, global data for obvious reasons but you can see
| fairly different numbers based on what type of site you're
| running.
| philistine wrote:
| Perhaps it's time to approach the problem differently.
| Here's what I propose:
|
| If a new HTML element is not supported in browsers with
| broad usage *but* those browsers are deemed insecure and no
| longer supported, go ahead.
| ketzu wrote:
| Although a bit off topic, I think it is really interesting to
| see that a lot of firefox users are on an old version. Firefox
| supporting <dialog> has around 2.4% users, while firefox not
| supporting <dialog> because it is old, has around 0.7%
| rockwotj wrote:
| Wish I could use this, but Safari only started supporting this as
| of 15.4, which was released less than a year ago. I'll likely
| have to wait another 2-3 years until our site stops seeing these
| older Safari browsers.
|
| EDIT: looks like Firefox released support around the same time,
| but my company's Firefox users seem to be all be ok more recent
| versions.
| jeroenhd wrote:
| Luckily I've never had to bother with supporting Safari, but
| isn't one of the only good things about dealing with it that
| customers generally update Safari relatively quickly?
|
| I don't really understand the Safari release schedule myself
| (browser updates only seem to come with combined operating
| system updates?) so I don't know what's keeping users from
| updating their browsers. Are these Apple users all running
| vulnerable browsers for some reason?
|
| I find it nice that Safari <15.4 is still considered a valid
| target for your company, given that its market share is about
| that of Firefox (https://caniuse.com/usage-table). Must be hell
| to develop for, though.
|
| Perhaps the upcoming inclusion of non-Safari browsers on iOS
| will help users stuck on old versions of the OS use a normal
| browser so these problems can go away. Chrome and Edge manage
| to release monthly updates that almost everyone installs so
| hopefully that option comes available to iOS users as well.
| pier25 wrote:
| > _but isn 't one of the only good things about dealing with
| it that customers generally update Safari relatively
| quickly?_
|
| Most users, not all. Either because they don't want to
| upgrade the OS or they can't.
|
| I worked in the education industry for some years and a big
| issue were kids using old iPads.
| AceJohnny2 wrote:
| 1. How do you get away with not supporting the second-most
| popular browser? [1]
|
| 2.
|
| > _help users stuck on old versions of the OS use a normal
| browser_
|
| Funny, iOS tends to be upgraded further back (ie support
| older devices), and faster [2], than (say) Android [3],
| because Apple is aggressive about updating users.
|
| [1] https://gs.statcounter.com/browser-market-share
|
| [2] https://gs.statcounter.com/ios-version-market-share
|
| [3] https://gs.statcounter.com/android-version-market-share
| jeroenhd wrote:
| > 1. How do you get away with not supporting the second-
| most popular browser?
|
| Quite easily: desktop SaaS web application; no Macs in the
| office and no interest in buying them specifically for iOS;
| no customers using Macs. Also, Safari works Well Enough
| (TM) for people not to complain about the minor CSS offsets
| and if they do they can always install Firefox. I don't
| work there anymore, but I doubt any customer will even try
| to switch to Macs in the next five years.
|
| For my personal use cases: if my site doesn't work on
| Safari, I can't legally test it on any of my devices so I
| don't bother. Even _Microsoft_ published a cross-platform
| browser, I 'll care about Safari the moment I can apt-
| install safari-dev/winget install safari.
|
| > Funny, iOS tends to be upgraded further back (ie support
| older devices), and faster [2], than (say) Android [3],
| because Apple is aggressive about updating users.
|
| Yes, iOS updates devices faster. However, Chrome isn't tied
| to the OS.
|
| I've said it before and I'll say it again: my perfectly
| good iPad 2 is useless despite its quite competent CPU
| purely because there are no browsers for it. Had it run
| Android, I could just install Chrome and use it for slower
| but quite usable browsing; with the Safari lockdown the
| device became useless.
|
| You can't install an up-to-date version of Safari onto iOS
| 15 because of Apple's architecture decisions, despite iOS
| 15 still receiving plenty of other updates, which means
| you're restricted in features if you can't install the
| latest major upgrade.
|
| Google decoupled WebKit from the system image years ago and
| has always allowed alternative browser engines like
| Firefox, which means you can install the latest version of
| Firefox on Android 5.0 (November 2014) or Chrome on Android
| 7.0 (March 2016), but not Safari 16 on iOS 8 (September
| 2014) or iOS 10 (September 2016). My Oneplus One (April
| 2014) still browses the web fine, and it's a mere budget
| device compared to something like an iPhone!
| tpush wrote:
| If you're developing a desktop browser app for a non-
| English speaking market, you can ignore Safari oftentimes.
|
| E.g. in Germany desktop Firefox has roughly double the
| market share of Safari.
| djxfade wrote:
| But supporting mobile Safari usually gives you desktop
| Safari support for "free". Not many first world markets
| you can ignore Safari mobile in.
| Kwpolska wrote:
| If you cater to the Windows-heavy corporate market, and if
| your software is meant to be used at a desk, the market
| share of Safari goes down to 0%.
| a3w wrote:
| This. Why is there not a billion devices using QQBrowser
| or something other obscure at place two? Mobile IMHO is
| different - not every website will work.
|
| Which really sucks on iPads, because not real free
| adblockers, faulty SVG rending in safari for a project I
| ran two years ago, and less support for browser features
| (PWA features mostly, so classical web often kinda works)
| makes browsing the web with touch often easy, yet very
| hard, when something is broken or nagging.
| carlosjobim wrote:
| Don't these corporate people all have iPhones and want to
| quickly take care of something while on the run?
| jeroenhd wrote:
| Luckily, the corporate people usually only need to view
| the marketing site on their phones!
| Kwpolska wrote:
| Depends on the industry and use-case. Some line-of-
| business apps might be designed without caring about any
| mobile/responsive usage. Others might be meant to be used
| at a specific workstation that has a computer as part of
| it (for example, the app might be controlling some
| equipment), or in some other environment in which mobile
| usage makes no sense.
| trollied wrote:
| > 1. How do you get away with not supporting the second-
| most popular browser? [1]
|
| Not speaking for the OP, but the internal tools I work on
| only supprt Chrome - you can only login to these systems
| using Single Sign On, which is only possible to login via
| Chrome (Google SSO). Makes devving loads easier!
| Synaesthesia wrote:
| Yeah but 15.4 is supported on versions going back to Catalina.
| ec109685 wrote:
| Surely there is a polyfill you can use?
|
| https://github.com/GoogleChrome/dialog-polyfill
| colordrops wrote:
| What sort of company do you work at where you can't prod your
| users to upgrade their browsers? Surely this is a security
| risk. I'm at a company of 100k employees and our small team has
| no problem telling users they need to upgrade.
| eyelidlessness wrote:
| > 100k employees and our small team
|
| I'm almost afraid to ask, but what do you think is a _large_
| team?
| zrobotics wrote:
| My guess is they are a small internal team and their users
| are company employees. Otherwise, I can't imagine another
| scenario where that statement makes sense.
| CSSer wrote:
| It's a bit odd though, because I've heard plenty of
| stories with those conditions where that's still not
| true. One example is bank software that must run on IE11
| because IT refuses to upgrade the equipment and security
| isn't a priority because it's airgapped or something
| silly like that.
| KyeRussell wrote:
| I'm just going assume that they don't have much variety
| of experience under their belt.
| motoxpro wrote:
| If people can use the entire web in their eyes without having
| to update their browser (which they can because they haven't
| had to update yet) EXCEPT for my site, why am I so specially
| that they need to update specifically for me?
|
| Bad UX. Or maybe you're in an industry where it is your job
| to secure users computers.
| colordrops wrote:
| Your last sentence isn't some side note. It's critical. Any
| browser over a year old is going to be riddled with
| security issues.
| realusername wrote:
| On a normal system you can update the browser but on iOS you
| are stuck with the one coming with the OS version you have,
| you can't really tell them to update their browser because
| that's not feasible (and yes it's a security risk but there's
| nothing you can do about it).
| [deleted]
| scarface74 wrote:
| Apple recently released "security updates" for the iPhone
| 5s - released in 2013.
| thayne wrote:
| In the case of safari, upgrades are tied to OS updates, so
| upgrading may require updating the entire OS, and in the
| worst case might require the user to buy a new phone.
| withinboredom wrote:
| I have a newish MBP from 2018. It's still fast as hell and
| reliable. I can't upgrade the OS because it is not supported.
| I don't use Safari, but I'm sure there are people out there
| using a perfectly fine computer that Apple has dropped
| support for.
| JimDabell wrote:
| Ventura supports all MacBook Pros from 2017 onwards:
|
| https://support.apple.com/en-sg/HT213264
|
| As far as I can see, the only possibility for buying a new
| MacBook Pro in 2018 that can't run Ventura is if you bought
| the MacBook Pro Retina (Mid 2015) model, which wasn't
| discontinued until mid-2018. All the older MacBook Pros
| that can't run Ventura were discontinued in 2017 or
| earlier:
|
| https://en.wikipedia.org/wiki/List_of_Mac_models#2015
|
| I think Ventura not supporting a model released more than
| seven years beforehand is a reasonable cut-off point. But
| if there are people who want to use an older model with a
| newer browser, they can use Firefox or Chrome.
| tomasf wrote:
| Hmm. Which MBP is that? As far as I can tell, even the
| oldest and slowest MBP from 2018 can run Ventura.
| withinboredom wrote:
| Nope. Says it's not supported when I try to install it.
| It doesn't give a reason though. It's a maxed out Intel
| unit from 2018, it's not listed as a supported model for
| Ventura. When I get home I can get the model number.
| worksonmine wrote:
| Is there a valid reason for this? Like their code not
| running on the hardware anymore or is it just for profit?
| Do you at least get security updates?
|
| Some kid somewhere digs up a rock under gunpoint and we're
| expected to throw it out as soon as something shinier comes
| along, disgusting. It's because of companies acting like
| this we need regulations on support and right to repair.
| stereocodes wrote:
| What are talking about? Most companies don't do this. Talk
| about a bubble.
| CSSer wrote:
| Maybe it's sarcasm? On the other hand, the new school does
| have it pretty good these days with the evergreen browsers,
| so it could be genuine lack of perspective. Webkit is
| stubborn and slow moving, but nothing like what we endured
| with IE, especially since polyfills were not a ubiquitous
| concept and checking for feature support at runtime was a
| kind of dark art. I shudder just thinking about user agent
| strings again. If anything, my daily dose of strange BS
| these days comes from imposed third-party SaaS vendors
| rather than browser interop even when accounting for older
| versions of Safari.
| acdha wrote:
| Most organizations with any sort of audit, insurance, or
| regulatory requirements do. Updating software is one of the
| most basic things covered by any security benchmark.
| zelphirkalt wrote:
| Maybe internally. If done externally, extorting your
| users to update their stuff, then it is clearly
| overstepping the boundaries. Creating awareness is good
| and necessary, but insisting on another entity, be it a
| user or another company doing something, because it is in
| your company's security benchmark, is inappropriate.
| Quickly silly things, that have no security benefit at
| all make it into that benchmark and are tried to be
| forced upon other entities. Suddenly a company will be
| interested in how you internally handle your SSH keys. Do
| you make new ones every 3 months? No sorry, every 4
| months is too long for our security benchmark.
| acdha wrote:
| The possibility of something being done poorly doesn't
| mean that it can't be done more thoughtfully. For
| example, most banks will refuse to let you do online
| banking using IE6 or SSLv3 and pretty much everyone is
| okay with that because the risks are obvious.
|
| That's always the tradeoff you have to make since you're
| balancing the benefits to the user and cost of
| development - customers do benefit if you can ship better
| things faster because you're not held back by
| discontinued browsers. <dialog> might not be there quite
| yet but it's close and if you already don't support IE11
| there's an obvious appeal.
| zelphirkalt wrote:
| I think you've got a good point there. It would be good
| to come together at a table and discuss such things on an
| eye to eye level, between entities. Obviously not always
| possible for natural persons to all come together.
| Announcing things well ahead of time can go a long way,
| rather than suddenly dropping support from one day to the
| next.
|
| What I would proprose then is, that companies should
| state their minimum security requirements to work with
| any other entity somewhere publicly available, so that it
| will not be something ad-hoc invented for some entity.
|
| I have seen companies trying to treat smaller ones like
| some kind of supplicant entity, that one can push around
| and ask about interna, that could easily lead to the
| bigger company building a copy of the smaller company in
| a few months, since they got much more workforce to put
| to it, if they really wanted. Asking for things like
| "architecture diagrams". I am quite sure, that big
| companies will laugh you out of the room, if you asked
| them to provide same for their architecture.
| ihateolives wrote:
| We force updates when users have not updated their browser
| by deadline. Security updates are not optional here.
| squeaky-clean wrote:
| Most shopping websites or social media come to mind. I use to
| work in airline web contracting and when doing work for
| certain countries' national airline booking systems we had to
| support ie6 until 2019 (gmail had dropped support in 2010 and
| Microsoft officially EOL'd it in 2016)
| colordrops wrote:
| The user I was responding to indicated it was internal
| users though, not a public website.
| ihateolives wrote:
| > certain countries' national airline booking systems
|
| Korea?
| dmitriid wrote:
| There are also government sites which really need to
| support all browsers since time immemorial because many
| people will access them from old and outdated devices.
| justinph wrote:
| Ran into this on nytimes.com. Ended up using the polyfill. The
| benefits of dialog are just too great to not use it. So much
| easier than using other modal libraries or rolling your own.
| davchana wrote:
| I came across this element few weeks ago.
|
| Before this,I used to use a div with stuff, and javascript to
| show hide that div when required. E.g. Spanner icon in this page,
| lower left corner: https://spa.bydav.in/tsDMV/tsVerif.html
|
| Now, recently I used this dialog element with javascript &
| buttons to show hide div. E.g like Settings button at
| https://spa.bydav.in/weather/
|
| I like that it comes on top, stays in center, no checkbook & css
| stuff.
| modeless wrote:
| The interesting thing about <dialog> is that it uses the "top
| layer" which always appears above everything else on the page
| regardless of z-index. So you can delete hacks like
| z-index:2147483647.
| rockwotj wrote:
| How do people normally manage z-indexes? I've found it's
| usually a mess of a people hard coding a bunch of values all
| over the place.
|
| Using CSS-in-JS we at least make constants so we can do stuff
| like: `const STICKY_HEADER_Z = TOOLTIP_Z + 1`.
| runarberg wrote:
| Normally I just set z-index to 1. z-index is only relative to
| the parent so you can still have a z-index of 1 overflowing
| another z-index of 9000 because the parent of the latter has
| a lower z-index then its sibling:
| https://jsfiddle.net/ec5qp7n3/
|
| Usually if I find that if I need to control more then one
| layer of stacking, I'm doing something that is unnecessarily
| complex, and the right solution is to go back and find a
| better design.
| jeroenhd wrote:
| SASS/SCSS helps. CSS variables would work too, but they're a
| but unwieldy and using tons of calc() isn't great for
| performance.
| louhike wrote:
| You still have the issue of the z-index being relative to its
| parent, and not absolute. So depending on which element it is
| set, its effect would not be the same. It's still a good
| practice to use constants, but I still often had difficulties
| to place elements relative to each others on the z-index.
| eurasiantiger wrote:
| Just use position: relative to start a new stacking context
| as appropriate.
| louhike wrote:
| I know, but it's still hard to use on a big website where
| you have to manage a lot of stacking contexts.
| JimDabell wrote:
| You can use isolation: isolate to explicitly create a new
| stacking context now. It makes the code a bit clearer
| because position: relative is used for lots of different
| things.
| devmunchies wrote:
| I usually make modal position:fixed and use JavaScript to
| position them in the center or wherever. Same for drop-down
| menu's when you click a button.
| rockwotj wrote:
| How does position:fixed help with the z-index?
|
| Also doesn't this mean you have to listen for scroll events
| this way and update the XY coordinates for things like
| dropdowns?
| Izkata wrote:
| "position: fixed" removes the element from the layout and
| positions it relative to the window. You can scroll the
| page any which way and the element will stay where it is
| on the screen, making it a good choice to handle X/Y
| positioning of the modal.
| rockwotj wrote:
| I asked how it helps with z-indexes not XY?
|
| Also drop downs are "attached" to some element in the UI,
| and you probably want those menus to scroll with the page
| Izkata wrote:
| The person you were responding to said they use
| "position: fixed" so they don't have to worry about
| z-indexes, and I was explaining why that works. See
| sibling reply for the more technical explanation.
| kijin wrote:
| "position: fixed" puts an element in a new stacking
| context, freeing it from the z-index of its parents.
| 2T1Qka0rEiPr wrote:
| In a previous life as a front-end developer using Sass, I had
| a single z-indexes module in which they would all be defined.
| chrismorgan wrote:
| Clarification: _modal_ dialogs do this. Non-modal ones don't.
| streptomycin wrote:
| So no dialogs inside other dialogs?
| Matheus28 wrote:
| > Warning: The tabindex attribute must not be used on the
| <dialog> element.
|
| This really needs an explanation
| Someone1234 wrote:
| "Why this is on MDN?" It is taken from the spec[0]:
|
| > The tabindex attribute must not be specified on dialog
| elements.
|
| Why is the spec like that? Uhh, I cannot find a source or
| explanation. If I had to GUESS, it is because it uses autofocus
| instead of tabindex to establish focus to the dialog when it is
| shown.
|
| [0]https://html.spec.whatwg.org/multipage/interactive-
| elements....
| Izkata wrote:
| Here's a long conversation on it from 2016:
| https://github.com/whatwg/html/issues/1929
|
| It does seem to have something to do with interfering with
| automatic focus on the dialog when it pops up as a modal.
| dmitriid wrote:
| The only reason dialog suddenly shipped is because browsers
| want to remove alert/popup/confirm.
|
| Until last year the spec for dialog was in such a state that
| Chrome (the only ones implementing it) argued that it should
| be removed.
|
| IIRC literally none of the issues were fixed but suddenly it
| got shipped in all browsers.
| werdnapk wrote:
| I replaced all uses of 3rd party dialogs with this native version
| in all my client projects (who's browsers support this feature)
| last year. Works well and that extra code is now gone.
|
| More advanced <select> elements are what I'd like to see support
| for next.
| runarberg wrote:
| Related: <selectmenu>
|
| https://open-ui.org/prototypes/selectmenu
| zelphirkalt wrote:
| > The native HTML <dialog> element should be used in creating
| modal dialogs as it provides usability and accessibility features
| that must be replicated if using other elements for a similar
| purpose. Use the appropriate .showModal() or .show() method to
| render dialogs. If creating a custom dialog implementation,
| ensure all expected default behaviors are supported and proper
| labeling recommendations are followed.
|
| Any bets how long it will take JS frameworks to catch up to
| default behavior?
|
| Many websites still do not manage to properly make the back and
| forward button work, even after years.
|
| I am glad, that more semantic elements made it into HTML,
| reducing the amount of stuff needed to make simple things. I only
| wish, that we used the standard more.
| pier25 wrote:
| > _Many websites still do not manage to properly make the back
| and forward button work, even after years._
|
| Yeah. Many (most?) JS client-side routers don't allow you to
| change the URL without reloading the current route, reset
| scroll, etc.
|
| I started working on a toy router for Svelte precisely to fix
| this behavior.
|
| https://github.com/PierBover/roots-svelte-router
|
| The project is abandoned though. I lost interest in client-side
| routing and focused on fullstack (SSR + hydration).
| cush wrote:
| Like most things in the js ecosystem, it likely never will.
| It'll be a best effort, chasing the standard with usability and
| accessibility gaps littering even the best libraries. But hey,
| there's rounded corners that glow, so totally worth it.
| interstice wrote:
| Those libraries often cover edge cases the spec doesn't. For
| example with this what if for some reason I need the top
| level to share a some permamently available UI element?
| ddulaney wrote:
| Just use iframes!
|
| But more seriously, you do this in multi-page apps by just
| having that UI element in every page. Just about any
| (server-side) templating system lets you do that easily.
| interstice wrote:
| Sure, but is <dialog> going to work seamlessly with that
| if it isn't aware of positioning outside of the top
| layer?
|
| It could be that it is, but this is just an example of
| the kind of relatively common case that these maligned
| libraries cover that the spec often doesn't acknowledge.
| mg wrote:
| It doesn't seem to prevent scrolling?
|
| https://jsfiddle.net/46nha7v3/
|
| I enjoy native elements when they are there. You can do really
| nice interactive trees with the <details> element for example:
|
| https://twitter.com/marekgibney/status/1593950777739218947
|
| But I am not sure if it is a good idea to bake more and more of
| them into the browsers. Couldn't well made JavaScript modules
| provide the same functionality without making browsers more and
| more complex?
| asddubs wrote:
| native browser features are usually more accessible, and can
| adapt to the platform they're on better
| AprilArcus wrote:
| Try this: body:has(dialog[open]) {
| overflow: hidden }
| body:has(dialog[open])::before { content: "";
| position: fixed; top: 0; left: 0;
| width: 100%; height: 100%; backdrop-filter:
| blur(4px); background-color: rgb(0, 0, 0, 0.5); }
| mg wrote:
| Have you tried it?
|
| Here in Firefox, it does not work.
|
| https://jsfiddle.net/t34wz6kx/
|
| Also, using "position: fixed" will fail when the dialog is
| longer than the screen. Then the user cannot read it all, and
| if the close button is at the bottom, they cannot close it.
| karlshea wrote:
| Firefox also doesn't support :has.
|
| There's some more information on MDN [0] about how to make
| a modal dialog, you can open one in JavaScript using
| showModal() which has a backdrop, is actually modal, etc.
|
| [0]: https://developer.mozilla.org/en-
| US/docs/Web/HTML/Element/di...
| mg wrote:
| Nice!
|
| https://jsfiddle.net/5gevzft8/1/
|
| Looks like you cannot use a button in the dialog then
| though. As it somehow makes the dialog scroll to the
| bottom.
| MrJohz wrote:
| This is the spec behaviour - the browser focus should
| immediately jump to the first focusable item in the page
| for accessibility reasons. (As I understand it, this is
| the norm for dialogs outside the browser.)
|
| My understanding is that you should be doing two things
| here: firstly, dialogs shouldn't generally be scrollable
| by themselves (or if they are, the interaction buttons
| should be sticky so that they're always visible).
| Instead, if you've got long text (say T&Cs) that should
| be in a scrollable box of its own. This allows the user
| to see the whole dialog (interactions and all) at once.
| Secondly, if there is something that should take focus
| before the buttons do, then you should set autofocus on
| that element explicitly. So in this case, you'd wrap the
| long text in a scrollable div, and add an "autofocus"
| attribute to that div to ensure that keyboard based users
| will immediately jump to it and be able to scroll it with
| their keyboard.
| derefr wrote:
| Your "cannot use" is my "element has proper accessibility
| consideration for people who are viewing the dialog
| inside a webview that disables scrolling." With the
| buttons always starting in scrolled-into-view and in
| focus, those people can at least dismiss the modal!
| irrational wrote:
| I'm the opposite. I don't want to have to use any third party
| code, libraries, frameworks, etc. I want it all in the standard
| library.
| sgt wrote:
| That's not the reality of modern web development in the last
| 10+ years though.
| wildrhythms wrote:
| Yes, and that has led to how many thousands of hours of
| developer time wasted building these things custom for
| their app (or trying to find some minimally invasive
| library to do it). Bring on the dialog element. Maybe we
| can get the ability to custom style select inputs next.
| irrational wrote:
| Which is why development has sucked so much in the last 10+
| years, in my experience.
| simultsop wrote:
| same here, it also bugs me when a language needs a framework
| then it needs a transpiler than an ide extension than a
| course to learn well how to align all ecosystem properly
| since standard not enough to give credit/satisfaction to all
| involved in dev :(
| zdragnar wrote:
| This is how we end up with insufferable things like type
| "number" inputs and alert and most of the other baked in
| things.
|
| They're halfway to what you want but can't go further
| because everyone has slightly different needs and browsers
| are already complex enough without baking in prebuilt
| components for everything from data tables to carousels to
| modals to drop-down menus.
|
| Also, the list of things that bug you that a language needs
| describes pretty much every programming language in
| existence.
| badsectoracula wrote:
| > Also, the list of things that bug you that a language
| needs describes pretty much every programming language in
| existence.
|
| The bit about ecosystem and the context on JavaScript
| makes me certain he meant _external_ needs - in other
| words he 'd like "batteries to be included". There are
| several languages that come with a lot of stuff out of
| the box.
| dgb23 wrote:
| I agree. The primitives should be general and extensible via
| JS/WASM and presentation should be customizable. Browsers can't
| cover every specific use case.
|
| Prebuilt, specific components should focus on providing utility
| for documents and forms.
|
| The "details" tag is a good example. It has interactive
| utility, clear semantics, but is easily extensible and you can
| fully style it.
|
| The text input tag, not so much. It's for example difficult to
| extend into a typeahead/combobox with sensible UX and
| presentation without writing a whole buch of JS. And the story
| around accessibility isn't clear either.
| Jaxan wrote:
| Maybe it's good not to prevent scrolling. I have had many
| situations where there was a non-scrollable modal dialogue and
| the buttons were off-screen (my phone has a small screen). So
| the website became completely unusable.
| derefr wrote:
| It shouldn't necessarily prevent scrolling; but I'd expect
| scrolling the page behind the modal to keep the modal where
| it is in the viewport. That is, after all, how native modal
| dialog windows work.
| samsin wrote:
| That still wouldn't solve the situation GP described where
| the <dialog> element has a height greater than 100vh.
| varrock wrote:
| It also doesn't trap focus within the dialog.
| philistine wrote:
| Listen I'm just one dude with a very shaky understanding of
| programming. I still want my website to be good, so all those
| functionalities are a great thing.
| cm2187 wrote:
| How do you deal with a large modal on a small screen then?
| wg0 wrote:
| It seems like the <font> tag all over to me. No?
| pickpuck wrote:
| Interesting! I'd say:
|
| <font> provides no structural or accessibility information. It
| was only there for styling purposes.
|
| <dialog> provides structural and accessibility information plus
| interactivity that previously required JavaScript. It comes
| with default styles but that's not the primary reason to use
| it.
| justsomeuser wrote:
| My notes on this:
|
| - <dialog>.showModal() is an indirect API to `top-layer`.
|
| - `top-layer` is kind of like a sibling to the root <html>,
| elements can be placed into the top-layer _from any position in
| the existing DOM_ (it is like they have two positions). This
| allows co-locating your <dialog> next to the relevant elements
| in the tree.
|
| - There is only one `top-layer` but it can have many children.
| Last opened === current element on top.
|
| - Z-index has no effect in the top-layer. No need to compete for
| a higher z-index.
|
| - ::backdrop is a pseudo element that you can style behind the
| <dialog>. It is always below the last <dialog> opened.
|
| - Not supported in Safari <= 15.3
| danShumway wrote:
| > - Z-index has no effect in the top-layer. No need to compete
| for a higher z-index.
|
| This is the kind of boring feature that can end up saving huge
| amounts of developer time. Z-indexing in CSS is kind of
| annoying and I've seen projects just detach dialogs from their
| normal position in the DOM entirely to get around stacking
| errors before. That obviously comes with its own set of
| problems...
|
| There are scenarios where you're still going to have to build
| custom controls, but a lot of my experience making dialogs has
| been frustration over these kinds of boring features -- "how do
| I get this to display on top and lock the page without writing
| a bunch of extra code and worrying about of edge cases?"
|
| ----
|
| Minor question:
|
| > - There is only one `top-layer` but it can have many
| children. Last opened === current element on top.
|
| Is this true? The spec says:
|
| > The top layer is an ordered set of elements, rendered in the
| order they appear in the set. The last element in the set is
| rendered last, and thus appears on top.
|
| I'm still playing around with `dialog` elements, so you may
| well be right, I'm just having trouble finding the actual spec
| rules about what happens when there are multiple dialogs and
| they're being simultaneously manipulated.
|
| ----
|
| > - Not supported in Safari <= 15.3
|
| Worth noting that there is a polyfill
| (https://github.com/GoogleChrome/dialog-polyfill), but that the
| polyfill comes with some fairly large limitations, specifically
| that they don't advise dialogs be used as children of elements
| with their own stacking context.
|
| This is reasonable, but also... my first thought when I
| originally ran into `dialog` was "finally I can stop worrying
| about which of my elements create new stacking contexts!" -- so
| it does decrease the usefulness quite a bit.
| sam_goody wrote:
| How long has this been available (in Chrome/FF on desktop)?
| ofirg wrote:
| Maybe someone can explain the reason why the imperative and the
| declarative way of controlling the open state works differently.
|
| I run into the modal/no modal thing just a day ago.
___________________________________________________________________
(page generated 2023-02-12 23:01 UTC)