[HN Gopher] Bringing Back Horizontal Rules in HTML Select Elements
___________________________________________________________________
Bringing Back Horizontal Rules in HTML Select Elements
Author : ingve
Score : 150 points
Date : 2024-01-26 06:48 UTC (1 days ago)
(HTM) web link (webkit.org)
(TXT) w3m dump (webkit.org)
| OJFord wrote:
| TFA mentions `optgroup` too, wouldn't it make more sense to use
| that and style it similarly? Especially if `hr`-in-`select` is
| only going to work in Safari anyway(?).
| chrisb wrote:
| The article isn't completely clear; but hr-in-select is
| standardized [0] - and it definitely works in the Firefox
| v122.0 I'm browsing with.
|
| [0] https://html.spec.whatwg.org/multipage/form-
| elements.html#th... (see the "Content model" line)
| OJFord wrote:
| Pfft I'm an idiot - I'm reading from (and tried it out with)
| Firefox too!
| genezeta wrote:
| It's been added in 122.0 [0], but it wasn't working
| previously.
|
| [0] https://www.mozilla.org/en-
| US/firefox/122.0/releasenotes/#no...
| lapcat wrote:
| Optgroup has a mandatory label attribute.
| vinnymac wrote:
| Not to mention the user experience for an optgroup on mobile is
| vastly superior as a sheet rather than a popover.
|
| https://developer.mozilla.org/en-US/docs/Web/HTML/Element/se...
|
| For those without iOS, see an example here:
| https://ibb.co/DkN16Gc
| Pesthuf wrote:
| <select multiple> on mobile devices is so good - why don't
| the finally improve the implementations on the desktop as
| well? The arcane 90s UI paradigm it currently uses everywhere
| just doesn't work.
|
| And please, just give us an attribute that adds a search
| bar... I don't want to use 30 KB of JavaScript just to have
| selects that feel like they're from this millennium,
| especially since those then don't work too well on mobile...
| extra88 wrote:
| That's a text input plus a datalist. Their browser
| implementations also have some issues but can do the job.
| moron4hire wrote:
| There's a whole other ball of problem wax with input plus
| datalist. The options don't appear again if one has been
| selected already; the user first has to clear the input
| and then the list appears. Also, the input can't be
| strictly limited to the options in the datalist; the user
| could type in whatever they want and it's still "valid"
| and fulfills any required attribute added to the tag.
| carlosjobim wrote:
| > And please, just give us an attribute that adds a search
| bar...
|
| That's the datalist html element.
| int_19h wrote:
| What is "arcane" about the desktop multiple selection
| paradigm? It has been the standard way to deal with
| selections in all desktop OSes for decades now.
| crazygringo wrote:
| Funny, it looks way better on mobile than it does on desktop
| [1].
|
| On desktop (Chrome on Mac) each optgroup label is just a
| disabled item, and then its options are indented menu items
| below it.
|
| It looks totally hacky -- the name of a group shouldn't seem
| like "disabled" option, nor are indentations in menu items an
| established convention.
|
| That sheet on iOS is perfectly intuitive, however.
|
| [1] Link to page section with demo:
| https://developer.mozilla.org/en-
| US/docs/Web/HTML/Element/se...
| int_19h wrote:
| Firefox renders group titles using bold italic font while
| indenting the items under it, so it looks like a header.
| shiomiru wrote:
| Agreed, this just looks like a non-accessible <optgroup>
| alternative and feels like a step backwards. I fear authors
| will now use hr instead of properly grouping their elements, to
| the detriment of screen reader users.
|
| Why not just make horizontal rules between optgroups the
| default?
| vinnymac wrote:
| > You could still see it by manipulating the DOM or using XML,
| but apart from a couple of experts nobody knew.
|
| Except for all the users who were frustrated by the change. Most
| users wouldn't even know who to report this to, even if they
| noticed it at all. They may chalk up the issue to the new
| computer or phone they purchased in the last two decades.
| lapcat wrote:
| For me the problem is that iOS already adds horizontal rules
| between all select options, so the new feature doesn't make any
| sense there, and I can't share code between Mac and iOS.
|
| I wonder if anyone on the WebKit team looked at the blog post
| example in Mobile Safari?
| eyelidlessness wrote:
| It doesn't render an extra separator on iOS, so you should be
| able to use the same markup.
| lapcat wrote:
| I think you're missing the point. The redundancy of the <hr>
| on iOS means that on iOS the <hr> doesn't serve its purpose
| of separating the options.
| eyelidlessness wrote:
| I was responding to your point that you can't share code
| between the platforms. It doesn't have the same
| presentation, but it's no _less usable_ with the <hr> than
| without.
| lapcat wrote:
| > it's no less usable with the <hr> than without.
|
| Sigh, you still don't seem to get it. The point of _code_
| is to provide _functionality_ to the user. If I want to
| visually separate the options, the <hr> on iOS does
| _not_ provide the functionality. Thus, I need to do
| something _else_ on iOS in order to visually separate the
| options, and thus I can 't share the <hr> code with other
| platforms.
|
| "no less usable" is a misleading way of phrasing the
| problem. The <hr> on iOS is not usable at all as a visual
| separator between options in a select element. It's
| pointless, with no use.
| eyelidlessness wrote:
| I'm responding from a perspective of over two decades of
| web development. It's a necessary reality of the web as a
| platform that different rendering environments have
| different capabilities, and this is a fairly typical case
| of/for graceful degradation.
| lapcat wrote:
| > I'm responding from a perspective of over two decades
| of web development
|
| How is that relevant to my point?
|
| > this is a fairly typical case of/for graceful
| degradation.
|
| I'm not interested in "degradation". I'm interested in my
| code actually working as intended and serving a useful
| purpose. It's great that the <hr> on iOS degrades
| gracefully, but that still doesn't help me even one tiny
| bit.
| torstenvl wrote:
| The use of serving <hr>-in-<select> to iOS is to avoid
| having to maintain two different code bases, which is an
| anticipated problem you _specifically_ complained about,
| saying "I can't share code between Mac and iOS."
|
| Choosing to serve different code to different browsers
| complicates development and maintenance, for almost no
| upside (minuscule bandwidth savings).
|
| Serving the same code, including serving <hr>-in-<select>
| to iOS, has the significant benefit of simplifying
| development and maintenance, has the benefit of
| automatically "upgrading" iOS users to your better
| experience once their browser supports it, and has no
| negative impact on usability (the iOS <select> looks and
| behaves identically with or without the <hr>).
|
| That is the point eyelidlessness is trying to make. There
| are two courses of action, one of which has a lot of
| downside and little upside, the other has a fair amount
| of upside _and no downside_. That 's what he meant when
| he pointed out that "it's no less usable with the <hr>
| than without."
| lapcat wrote:
| > Choosing to serve different code to different browsers
| complicates development and maintenance,
|
| I didn't say I was going to serve different code to
| different browsers. I said I would have to serve
| different code to different browsers _if_ I used <hr> in
| <select>. That's a hypothetical. The alternative is
| actually to use a totally different technique for
| separating options that works on both desktop and mobile.
|
| > for almost no upside (minuscule bandwidth savings).
|
| It's not about bandwith! It's 100% about the user
| interface. That's what neither you nor eyelidlessness
| seems to understand. The entire point of using <hr> in
| <select>, or some other technique for separating options,
| is for the user interface.
|
| > no negative impact on usability (the iOS <select> looks
| and behaves identically with or without the <hr>).
|
| What you describe _is_ a usability problem. That 's a
| bug, not a feature.
|
| It really boggles my mind that you can't understand the
| basic requirement: I want to separate the options on both
| Mac and iOS. Leaving the options unseparated on iOS is
| _not_ an acceptable alternative.
| TheCoreh wrote:
| iOS popup menus have actual separators, they are much
| thicker than those lines around each item. They just
| haven't shipped hr for select support in Safari for iOS yet
| (they will in 17.4, you can try it in the beta)
|
| For an example of how they look like in iOS 17.3 or
| earlier, long press the address bar/tab title in Safari
| vinnymac wrote:
| For those without an iOS device see this example:
| https://ibb.co/N7Mw4dW
| chrisoverzero wrote:
| Are you under the mistaken impression that this feature is
| _already implemented_ in mobile Safari on iOS 17.3? It isn't.
|
| On iOS 17.4, you'll be able to see that the divider is thicker
| and obvious. Long-press on the Safari address bar for an
| illustrative example. See the gap between "Voice Search" and
| "Move to Tab Group"?
| lapcat wrote:
| > Are you under the mistaken impression that this feature is
| already implemented in mobile Safari on iOS 17.3?
|
| The blog post didn't mention iOS at all. I'm glad to hear
| that the feature is coming in the future, though it's strange
| that the blog post didn't mention it, and also strange that
| they didn't implement it in 17.0 at the same time as desktop.
| alwillis wrote:
| > The blog post didn't mention iOS at all.
|
| Probably because iOS 17.4 is in beta and just got released
| a few days ago.
| lapcat wrote:
| The blog post was actually published on the same day and
| a little after the iOS 17.4 beta was released.
|
| This is a very odd coincidence, since the Mac change was
| released way back in September with version 17.0, which
| the blog post does mention.
| superhumanuser wrote:
| Doesn't work on Android. Every option has line below it.
| neogodless wrote:
| I'm on Android and see no lines at all.
|
| (Firefox)
| ahoka wrote:
| It does not work on iOS either :)
| squigglydonut wrote:
| Let's get chrome support
| grishka wrote:
| It does show the separators for me on Vivaldi (which is
| Chromium-based)
| throwaway290 wrote:
| It works in v120.
| kps wrote:
| 119 -- https://developer.chrome.com/blog/hr-in-select/ is
| linked from the OP article, but not prominently.
| squigglydonut wrote:
| Chrome android
| PaulDavisThe1st wrote:
| Another fabulous example of "since we're now aiming to implement
| 90% of new GUIs in the browser, let's take a couple of decades to
| slowly add each and every element of desktop native GUI toolkits
| from the 1990s".
|
| Sigh.
| lazypenguin wrote:
| Every time I read a recommendation for
| webview/tauri/electron/etc. I always ask myself "what about
| datagrids, docking tabs, context menus, etc.?"
| akira2501 wrote:
| GUI toolkits never had to be designed and implemented by
| committee, so they have the speed advantage.
|
| On the other hand we've got a "custom elements" implementation
| that's far more ergonomic and implemented across all platforms,
| some of them even let you play with the "internals" mechanisms,
| and all if it is better than I remember any GUI toolkit
| providing.
| uses wrote:
| i had no idea <select multiple> existed. it works great on my
| ipad and has great browser support.
|
| https://caniuse.com/mdn-html_elements_select_multiple
| ErneX wrote:
| Since 1995 (HTML 2.0)
|
| https://www.w3.org/MarkUp/html-spec/html-spec_8.html#SEC8.1....
| bdcravens wrote:
| It's always been there, but for traditional browsers, it was
| tedious: Ctrl/Cmd + click. Many non-power users found it tricky
| or didn't know about it, so we all more or less settled on
| checkboxes as a UX standard.
| alexfromapex wrote:
| Wish browsers would start shipping a sensible multi-select.
| There's one now but it's not user-friendly enough IMO.
| jareklupinski wrote:
| i built one a bit ago using an event (onselect or onchange?)
| handler on a regular dropdown that, when you click on an item,
| the handler removes that element from the dropdown options, and
| adds it to another ul/li list under the dropdown, with a little
| X to reverse the process
|
| select2 does something similar but yea it's weird this isn't a
| built-in
|
| maybe a dropdown with checklists?
| config_yml wrote:
| > maybe a dropdown with checklists?
|
| That's builtin with <select multiple> but it's only usable on
| mobile.
| c-smile wrote:
| I do not really understand what is the problem with flexible
| <select> implementation in browser.
|
| In my Sciter[1] the following are supported ( see screenshot [2]
| ): <select type="dropdown"> - select with popup
| <select type="list"> - select list <select type="tree">
| - hierarchical select (a.k.a. tree view)
|
| and all of them may have <select multiple> -
| multi-select, value = array[] <select
| multiple="checkmarks"> - multi-select, value = array[]
|
| select type="tree" may have also <select
| type="tree" treelines> - draw treelines
|
| <select> and <option>'s may have arbitrary markup inside
| (<hr>,<img>, whatever), even more any DOM element may have
| role="option" defined making it a selectable option :
| <li role="option">...</li> <option
| value="Sc"><code>Sc</code>Scandium</option>
|
| And as a bonus, by declaring different flows in CSS in list you
| may have: select { flow:horizontal; } //
| horizontal select select { flow:vertical-wrap; } //
| multicolumn select
|
| [1] https://sciter.com [2] https://sciter.com/wp-
| content/uploads/2024/01/select-variant...
| zerocrates wrote:
| At least some of this is hopefully on the horizon with the
| stylable select initiative (this was previously called
| "selectlist" but they seem to have pivoted to alter/enhance the
| select element instead):
|
| https://open-ui.org/components/selectlist/
| zerocrates wrote:
| What's the reasoning for allowing select to have hr children but
| not optgroup? It doesn't _seem_ like it would be any more
| problematic but I imagine I 'm missing some relevant issue.
___________________________________________________________________
(page generated 2024-01-27 23:00 UTC)