←back to thread

507 points tosh | 1 comments | | HN request time: 0s | source
Show context
ljoshua ◴[] No.43534919[source]
The challenge till this is widely supported (caniuse.com currently pegs it at 46% globally [1]) will be using this as a progressive enhancement that does not provide a worse or unusable experience for users with browsers not supporting it yet.

In other words, don’t include critical information or functionality in the new styling that isn’t available in the underlying plain select element! But such is always a good practice anyway.

Very nice to see this taking shape though! Should be a huge improvement over the div monster that custom select box replacements often are. :)

[1] https://caniuse.com/mdn-css_properties_appearance_base-selec...

replies(6): >>43535467 #>>43535494 #>>43535497 #>>43535566 #>>43538689 #>>43546962 #
ddoolin ◴[] No.43535566[source]
I agree that this is a huge improvement, but it's also over a decade late IMO. This should've been accomplished well before now, especially given that the issue has been there since the beginning.
replies(4): >>43535618 #>>43535690 #>>43542913 #>>43544593 #
pclmulqdq ◴[] No.43535618[source]
Because frontend is frontend, Javascript frameworks dominated the conversation even for silly things like basic web forms for the past 15 years. Basic HTML/CSS is now catching up to the fact that not everyone wants to run a Javascript monstrosity for custom styling on very basic tasks.
replies(3): >>43535666 #>>43535738 #>>43536859 #
no_wizard ◴[] No.43535738[source]
The prevalence of JS and JS backed components is due to the reluctance of browser vendors to introduce new HTML elements that everyone has been lobbying for in the same time period.

By and large browser vendors for the longest time, even today still in many respects, repeatedly ignore pleas for more elements that cover common use cases.

Even when they do arrive, they can be half baked - like dialog or details / summary - and that doesn’t help matters

replies(2): >>43539029 #>>43540502 #
lelanthran ◴[] No.43539029[source]
> Even when they do arrive, they can be half baked - like dialog or details / summary - and that doesn’t help matters

How are those half-baked? No smooth transition for details/summary, maybe?

Dialog seems to work well enough with little to no javascript required:

    <dialog>
        <h3>Warning:</h3>
        ...
        <button onclick='this.closest("dialog").close()'>Dismiss</button>
    </dialog>
My personal bugbear is the date/time input - FF doesn't even show a click element for time, you have to type in the time.
replies(2): >>43539745 #>>43540922 #
no_wizard ◴[] No.43539745{3}[source]
There's some quirks with the API around open vs openModal if you aren't aware of the accessibility implications you may not even realize this is the case.

Forms have some special quirks inside of a dialog.

The biggest thing though, is for the life of me I don't understand why you can't open and close a dialog without JavaScript. There's no way to do it.

replies(3): >>43539857 #>>43540966 #>>43541410 #
1. JimDabell ◴[] No.43540966{4}[source]
> The biggest thing though, is for the life of me I don't understand why you can't open and close a dialog without JavaScript. There's no way to do it.

You can use popovers like this without JavaScript:

    <button popovertarget="some-element" popovertargetaction="show">Open</button>
    
    <div id="some-element" popover="auto">
        <button popovertarget="some-element" popovertargetaction="hide">Close</button>
    </div>

You can mark a <dialog> element as open by default with the `open` attribute, and you can close it with a button using the `dialog` form method. No JavaScript required for that either.

I don’t think there’s any way at present to open a `<dialog>` element specifically without JavaScript, but command/commandfor handles this and was recently added to the HTML specification:

https://github.com/whatwg/html/pull/9841