41–50 of 160 posts
Earlier quoted context omitted.
> But my biggest let-down with the element is that it's comnpletely unstyled And it can't be styled without JavaScript? That's how it works with . So utterly frustrating.
You can style it normally. They just don't like the default style.
Earlier quoted context omitted.
> comnpletely unstyled, this is what completely holds back most built-in browser components from widespread usage, i suspect the vendors implementing it just don't care at all because it's not their problem every company i've ever worked at had at least a somewhat consistently defined design language and it would look completely amateurish and out of place to use built in browser components in most places, regardless…
the most commonly used element that I use is the date picker. i hate using it, but i'm not loading some library or framework just for it either.
you might as well cut their public valuation in half at that point. it's just not worth it to use the completely neglected and anemic components that are part of the browser, they are a joke
I started using in 2019, even though Firefox and Safari wouldn't support it for another couple of years, but Google's own Polyfill (of which I am a very modest contributor) was top-notch quality and so I had no problems using it in production for my LoB SaaS day-job. But my biggest let-down with the element is that it's comnpletely unstyled, beyond a very basic (and very un-Chrome-like) thick black line pixel border…
> comnpletely unstyled, this is what completely holds back most built-in browser components from widespread usage, i suspect the vendors implementing it just don't care at all because it's not their problem every company i've ever worked at had at least a somewhat consistently defined design language and it would look completely amateurish and out of place to use built in browser components in most places, regardless…
Why is this on the front page? It is nothing special
Earlier quoted context omitted.
the most commonly used element that I use is the date picker. i hate using it, but i'm not loading some library or framework just for it either.
i don't know what context you're using it in, but imagine a company like airbnb or booking.com using the built in date picker on their front page you might as well cut their public valuation in half at that point. it's just not worth it to use the completely neglected and anemic components that are part of the browser, they are a joke
Earlier quoted context omitted.
> comnpletely unstyled, this is what completely holds back most built-in browser components from widespread usage, i suspect the vendors implementing it just don't care at all because it's not their problem every company i've ever worked at had at least a somewhat consistently defined design language and it would look completely amateurish and out of place to use built in browser components in most places, regardless…
I feel like every company's (different/contrasting) "design language" and their insistence on using it, ends up being yet another weird looking thing on my computer. I'd rather decide for myself the fonts, color scheme, look and feel, etc. for applications on my computer, and have applications be consistent and respect those preferences. Rather than have some artist I don't know 2,000 miles away from me simply decide…
Earlier quoted context omitted.
i don't know what context you're using it in, but imagine a company like airbnb or booking.com using the built in date picker on their front page you might as well cut their public valuation in half at that point. it's just not worth it to use the completely neglected and anemic components that are part of the browser, they are a joke
Weird. I think the built in date picker is actually pretty nice.
Earlier quoted context omitted.
Modals that blocks focus to an entire browser window aren't really a good idea (I'm of the opinion that they are almost always a shitty idea, but that's harder to argue). People have multiple tabs open, and what if another tab contains information that your user needs to complete your dialog. You also have to be incredibly careful about how much visual control you allow over an actual dialog - especially making it lo…
> Modals that blocks focus to an entire browser window aren't really a good idea (I'm of the opinion that they are almost always a shitty idea, but that's harder to argue). Good news then, because alert/prompt/confirm do not block the window in any modern browser! In Firefox it only blocks the viewport of the current tab, so it behaves exactly like a DIY modal. In Chromium browsers it does pop over part of the browse…
Correct: they don't block the browser's desktop UI thread - but they do block the web-page's thread - and for abvout the past decade we can't move alert/prompt/confirm prompts: Chrome forces them to appear at the very top, dead-centre, and you can't scroll the page while it's open.
I started using in 2019, even though Firefox and Safari wouldn't support it for another couple of years, but Google's own Polyfill (of which I am a very modest contributor) was top-notch quality and so I had no problems using it in production for my LoB SaaS day-job. But my biggest let-down with the element is that it's comnpletely unstyled, beyond a very basic (and very un-Chrome-like) thick black line pixel border…
> no-one wants an unmovable popup or modal-dialog that completely obscures the user's view of an underlying document Eh, I beg to differ. Lots of use cases for that kind of dialog, for saving, confirming changes, etc etc.
...how can I confirm a set of changes if the popup is blocking my view of said changes?
I started using in 2019, even though Firefox and Safari wouldn't support it for another couple of years, but Google's own Polyfill (of which I am a very modest contributor) was top-notch quality and so I had no problems using it in production for my LoB SaaS day-job. But my biggest let-down with the element is that it's comnpletely unstyled, beyond a very basic (and very un-Chrome-like) thick black line pixel border…
> comnpletely unstyled, this is what completely holds back most built-in browser components from widespread usage, i suspect the vendors implementing it just don't care at all because it's not their problem every company i've ever worked at had at least a somewhat consistently defined design language and it would look completely amateurish and out of place to use built in browser components in most places, regardless…
The dialog element behaves exactly how you'd want it to behave for a company with their own design language — you can style every part of it exactly how you need it (including the backdrop, the positioning and size of the dialog element itself, borders, colours, contents, etc). Depending on how you implement the design language, you can either apply those styles to the dialog element in general, or provide a custom component that wraps the dialog element and provides the styles you need.
What the previous poster was complaining about was the opposite situation: they aren't working with their own design language, and instead want to use native-looking HTML elements (the default inputs, selects, buttons, etc). However, the dialog element does not provide a native look-and-feel, and instead is very minimalistic, providing only the base that developers can add their own styles to.
That said, I think the browser implementors have made the correct choice here. The dialog element is not a native popup, and doesn't behave like a native popup at all, so it doesn't make sense to style it natively. In addition, the more styles they provide as part of the user-agent styling, the harder it is to reset those styles if you want to do something different. Apart from inputs, browsers fairly consistently stick with providing the minimum possible styling for an element to be usable, and this means that developers have the largest range of freedom to use those elements as they like.