6 ms·

Progress is very gradual in this space, but browser vendors are working on a lot of this stuff in the Open UI W3C community group. https://open-ui.org/ https://

Progress is very gradual in this space, but browser vendors are working on a lot of this stuff in the Open UI W3C community group. https://open-ui.org/ https://open-ui.org/ https://open-ui.org/components/combobox.explainer/ https://open-ui.org/components/combobox.explainer/ https://open-ui.org/components/switch.explainer/ https://open-ui.org/components/switch.explainer/ > Where are the native HTML Tabs control? You implement tabs today (aka accordions) with `<details name="tab">`. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/details#name https://developer.mozilla.org/en-US/docs/Web/HTML/Element/de... "This attribute enables multiple `<details>` elements to be connected, with only one open at a time. This allows developers to easily create UI features such as accordions without scripting." You do have to write some CSS to align tabs horizontally, but it's fine. > Image selector? Use `<input type="file" id="avatar" name="avatar" accept="image/png, image/jpeg" />`. Opens the OS photo picker on mobile. You can style it however you like. > We can't even get text input to respect autocomplete directives properly. "Properly" seems to be doing a lot of work there. "autocomplete" works fine, but it's annoying to get it right, and this kinda can't be fixed, because HTML is under a lot of backwards-compatibility constraints. If you have autocomplete bugs to file, file them, and maybe convince the Interop group to focus on this issue. Their priorities for 2025 were just announced, but there's always next year. https://web.dev/blog/interop-2025 https://web.dev/blog/interop-2025

crabmusket 2y ago
> it's annoying to get it right, and this kinda can't be fixed, because HTML is under a lot of backwards-compatibility constraints Sorry, but this seems like a wild mischaracterisation, at least in regards to the problems I've had with users on Chrome. In our experience, Chrome aggressively shows an autofill prompt on almost every input it can. It also ignores the specced autocomplete=off attribute. We have observed Chrome showing a password prompt on an <input type=number> which is just bonkers. It is not hard NOT to do this. The Chrome team thinks whatever heuristic they're using is better than allowing developers, or even end users, to control filling behaviour. https://issues.chromium.org/issues/41163264 https://issues.chromium.org/issues/41163264 https://issues.chromium.org/issues/41239842 https://issues.chromium.org/issues/41239842 (By "autofill" I don't necessarily mean the input is automatically filled without user interaction, but sometimes a promotions shown with e.g. account login details or an address.) The argument has been that developers are naughty and turn off autocomplete inappropriately, which worsenes accessibility. But I've never seen e.g. a tooltip option in a browser to let me, the user, fill in details when I know they're appropriate? I am merely at the whim of the Chrome algorithm.
- dfabulich 2y ago
  Yes, disabling autocomplete can be annoying, but it is possible. Usually it amounts to being more descriptive in the value of the `autocomplete` attribute, rather than simply applying `autocomplete=off`. > We have observed Chrome showing a password prompt on an <input type=number> which is just bonkers. "We have observed" it, but not filed a bug? Neither of the bugs you linked to exhibit that bug.
  - crabmusket 2y ago
    > Usually it amounts to being more descriptive in the value of the `autocomplete` attribute No, there are many inputs where there is no sensible autocomplete value. For example, "create a new CRM customer record". This is a new customer who I have not seen before. By definition it is impossible to autocomplete. In the past, the Chrome team advised to "make up an autocomplete value and we won't do anything with it". This advice is a) dumb and b) no longer works anyway. > but not filed a bug? It's clear the Chrome team has no interest in fixing this behaviour so I'm not going to waste my time. Yes, that's bad of me, but I have bills to pay.
    - dfabulich 2y ago
      [flagged]
      - deleted 2y ago
        [deleted]
      - crabmusket 2y ago
        If you're a Chromium contributor or otherwise involved, I'd be happy to chat further about this and work up a submission to demonstrate the issue with a minimal repro. But if not, I don't think they need you to stick up for them. It's clear from the threads I did post that lots of devs are frustrated with Chrome's behaviour and the team's lack of attention to not just fixing bad behaviour, but complying with the HTML spec. Without even focusing on the type=number problem, I have spent enough time fighting other behaviour which is only an issue in Chrome. > you only vaguely remember a bug Thanks to that ad-hom I am now irritated, and I went back to our internal Slack to find the screenshot of the type=number bug. Sharing a screenshot here would have no real value to this discussion, but it's real.
prmph 2y ago
> Use `<input type="file" id="avatar" name="avatar" accept="image/png, image/jpeg" />`. Opens the OS photo picker on mobile. You can style it however you like. This just selects the image. 99 times out 100, you want to do the same things with the image data: adjust it in some way, and save it to object storage or something. The file input is too primitive for this. And this is the theme all over, HTML control remain too primitive to do any real world rih UI with, which leads to the proliferation of JS UI libraries. > If you have autocomplete bugs to file, file them, and maybe convince the Interop group to focus on this issue. Their priorities for 2025 were just announced, but there's always next year. https://web.dev/blog/interop-2025 https://web.dev/blog/interop-2025 Autocomplete "bugs" abound aplenty, some of which will make your jaw drop. I've been testing with Chrome and Firefox. The length to which browsers will go in a misguided attempt to be clever with auto-complete is frankly absurd. So I'm not sure they are "bugs" so much as they are a wilful refusal by browser vendors to follow the spec.
- rafram 2y ago
  > This just selects the image. 99 times out 100, you want to do the same things with the image data: adjust it in some way, and save it to object storage or something. The file input is too primitive for this. That's not true at all. Obviously there's no `adjustinsomeway` or `savetoobjectstorage` attribute on the <input> element, but you can trivially grab the selected files, read them, and act on them with JavaScript: https://developer.mozilla.org/en-US/docs/Web/API/File_API/Using_files_from_web_applications https://developer.mozilla.org/en-US/docs/Web/API/File_API/Us...
  - prmph 2y ago
    > and act on them with JavaScript I thought the whole point was to avoid JavaScript, by having rich UI components built right into the browser
    - rafram 2y ago
      Sure, but what kind of image manipulation do you think would actually belong in the HTML spec? That just seems way out of scope to me.

crabmusket 2y ago

> it's annoying to get it right, and this kinda can't be fixed, because HTML is under a lot of backwards-compatibility constraints Sorry, but this seems like a wild mischaracterisation, at least in regards to the problems I've had with users on Chrome. In our experience, Chrome aggressively shows an autofill prompt on almost every input it can. It also ignores the specced autocomplete=off attribute. We have observed Chrome showing a password prompt on an <input type=number> which is just bonkers. It is not hard NOT to do this. The Chrome team thinks whatever heuristic they're using is better than allowing developers, or even end users, to control filling behaviour. https://issues.chromium.org/issues/41163264 https://issues.chromium.org/issues/41163264 https://issues.chromium.org/issues/41239842 https://issues.chromium.org/issues/41239842 (By "autofill" I don't necessarily mean the input is automatically filled without user interaction, but sometimes a promotions shown with e.g. account login details or an address.) The argument has been that developers are naughty and turn off autocomplete inappropriately, which worsenes accessibility. But I've never seen e.g. a tooltip option in a browser to let me, the user, fill in details when I know they're appropriate? I am merely at the whim of the Chrome algorithm.

dfabulich 2y ago
Yes, disabling autocomplete can be annoying, but it is possible. Usually it amounts to being more descriptive in the value of the `autocomplete` attribute, rather than simply applying `autocomplete=off`. > We have observed Chrome showing a password prompt on an <input type=number> which is just bonkers. "We have observed" it, but not filed a bug? Neither of the bugs you linked to exhibit that bug.
- crabmusket 2y ago
  > Usually it amounts to being more descriptive in the value of the `autocomplete` attribute No, there are many inputs where there is no sensible autocomplete value. For example, "create a new CRM customer record". This is a new customer who I have not seen before. By definition it is impossible to autocomplete. In the past, the Chrome team advised to "make up an autocomplete value and we won't do anything with it". This advice is a) dumb and b) no longer works anyway. > but not filed a bug? It's clear the Chrome team has no interest in fixing this behaviour so I'm not going to waste my time. Yes, that's bad of me, but I have bills to pay.
  - dfabulich 2y ago
    [flagged]
    - deleted 2y ago
      [deleted]
    - crabmusket 2y ago
      If you're a Chromium contributor or otherwise involved, I'd be happy to chat further about this and work up a submission to demonstrate the issue with a minimal repro. But if not, I don't think they need you to stick up for them. It's clear from the threads I did post that lots of devs are frustrated with Chrome's behaviour and the team's lack of attention to not just fixing bad behaviour, but complying with the HTML spec. Without even focusing on the type=number problem, I have spent enough time fighting other behaviour which is only an issue in Chrome. > you only vaguely remember a bug Thanks to that ad-hom I am now irritated, and I went back to our internal Slack to find the screenshot of the type=number bug. Sharing a screenshot here would have no real value to this discussion, but it's real.

prmph 2y ago

> Use `<input type="file" id="avatar" name="avatar" accept="image/png, image/jpeg" />`. Opens the OS photo picker on mobile. You can style it however you like. This just selects the image. 99 times out 100, you want to do the same things with the image data: adjust it in some way, and save it to object storage or something. The file input is too primitive for this. And this is the theme all over, HTML control remain too primitive to do any real world rih UI with, which leads to the proliferation of JS UI libraries. > If you have autocomplete bugs to file, file them, and maybe convince the Interop group to focus on this issue. Their priorities for 2025 were just announced, but there's always next year. https://web.dev/blog/interop-2025 https://web.dev/blog/interop-2025 Autocomplete "bugs" abound aplenty, some of which will make your jaw drop. I've been testing with Chrome and Firefox. The length to which browsers will go in a misguided attempt to be clever with auto-complete is frankly absurd. So I'm not sure they are "bugs" so much as they are a wilful refusal by browser vendors to follow the spec.

rafram 2y ago
> This just selects the image. 99 times out 100, you want to do the same things with the image data: adjust it in some way, and save it to object storage or something. The file input is too primitive for this. That's not true at all. Obviously there's no `adjustinsomeway` or `savetoobjectstorage` attribute on the <input> element, but you can trivially grab the selected files, read them, and act on them with JavaScript: https://developer.mozilla.org/en-US/docs/Web/API/File_API/Using_files_from_web_applications https://developer.mozilla.org/en-US/docs/Web/API/File_API/Us...
- prmph 2y ago
  > and act on them with JavaScript I thought the whole point was to avoid JavaScript, by having rich UI components built right into the browser
  - rafram 2y ago
    Sure, but what kind of image manipulation do you think would actually belong in the HTML spec? That just seems way out of scope to me.