6 ms·

So after decades of developer pain, all we're getting is a better select? Where is the native HTML datagrid (that supports sorting, filtering, paging, download

by prmph 2y ago

So after decades of developer pain, all we're getting is a better select? Where is the native HTML datagrid (that supports sorting, filtering, paging, downloading, row/column freezing, column resizing and re-ordering)? Where are the native HTML Tabs control? Image selector, resizer/cropper, and uploader? Toggle button? etc. We can't even get text input to respect autocomplete directives properly. On the major browsers, giving your user id and password inputs nonsensical names seems to be required, along with numerous other hacks, to ensure that when a user is registering, the form is not auto-completed with saved passwords. HTML is really holding us back right now.

sa46 2y ago
> Where is the native HTML datagrid Which parts of a datagrid should a browser provide? I'm familiar with AG Grid [1] and the API surface is enormous. Aligning browsers on a feature set would be challenging. Maybe there's a core set of functionality, like Flutter's GridView or QML https://doc.qt.io/qt-6/qml-qtquick-gridview.html https://doc.qt.io/qt-6/qml-qtquick-gridview.html. [1]: https://www.ag-grid.com/ https://www.ag-grid.com/
- crab_galaxy 2y ago
  The simplest would be to follow the aria role=“grid” spec, ideally with sortable columns. IMO it doesn’t need the kitchen sink AG Grid approach just a sane way to semantically build a data grid with proper accessibility. https://www.w3.org/WAI/ARIA/apg/patterns/grid/examples/data-grids/ https://www.w3.org/WAI/ARIA/apg/patterns/grid/examples/data-...
  - dimal 2y ago
    It has to handle every possible use case for a grid. You’re thinking of your use case. The spec needs to handle everything else. I don’t see how that’s manageable.
    - sensanaty 2y ago
      At minimum filtering and sorting should be handled by the browser, including async for both of those. Pagination could be argued as well, but at least that's simple-ish to implement (but still, it's such a common UI pattern that it ought to be handled in a unified way by browsers IMO)
      - dimal 2y ago
        Look at how much effort has gone into just getting a stylable select box. Look at tooltips. A data grid is several orders of magnitude higher in complexity than both of these. You are severely underestimating the complexity of your ask. HTML/JS/CSS is not supposed to solve all your UX problems. It’s a toolkit for building UIs, not a framework.
        prmph 2y ago
        Is it not the design by committee approach that slows down the design consensus on things like these? Just complex is it to design a spec for a stylable select box that is reasonable for most use cases? If it has to take decades to agree on a design for a stylable select box, then there is something fundamentally broken with the approach.
        dimal 2y ago
        For an open standard, how do you design it without agreement among a committee? Just let Google go rogue and define it? And have you ever worked in a large company? Have you seen how difficult it is to get any large group of people to agree on ANYTHING? These specs depend on the agreement of multiple large companies coming together. Each one of those companies is made up of many subcommittees who have to come into agreement with each other. While maybe you could imagine a straightforward technical implementation (and I think you’re overlooking the complexity of getting the API right while making it extensible), the social engineering involved to make this happen would be Herculean. And it would be for an element that’s on less than 1% of web pages. If you really want a data grid, I’d suggest learning how to code one. It’s a fun challenge, and implementing basic features like sorting and filtering isn’t difficult using a modern framework. If it is difficult for you, then I’d suggest that it would be a GREAT experience to try. Then imagine how you’d make it extensible for unknown use cases. The main reason it took decades for a stylable select box is because for two decades, we were just told “Don’t style select boxes. It’s bad for usability,” which was a mistake. We’ve only started to overcome that mindset in the past few years. The work on stylable select boxes only started in the past few years.
tisc 2y ago
Imo it’s not html, it’s browser vendors. There’s a decent specification for the `autocomplete` attribute: https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/autocomplete https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes...
- kevincox 2y ago
  It is actually a reaction to websites doing stupid things to try and prevent password auto-fill. The sites are fighting against security in a misguided attempt to improve security, so the browser vendors added a bunch of heuristics to try and correct these situations and you end up with the mess we have.
  - petepete 2y ago
    Equally having to jump through extra hoops to prevent autocomplete where you don't want it is frustrating, like in admin interfaces where you might be updating someone else's name. It's an arms race of stupidity.
nonchalantsui 2y ago
I'm not finding any of those proposals on the whatwg html repo, mind linking them?
- prmph 2y ago
  That's my point, they are not on the roadmap, although they absolutely should be, IMO. The W3C and WHATWG have their priorities mixed up.
robertoandred 2y ago
Safari already has toggle buttons and autocomplete directives.
dfabulich 2y ago
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.
crabmusket 2y ago
RE autocomplete in Chrome. The only thing we've found to work reliably is ensuring that all inputs are in form elements. Any inputs outside forms are going to have inappropriate autocomplete prompts. It's extremely annoying but at least this works for now. (I say "for now" because who knows when the Chrome team will change their heuristic?)
- joshuacc 2y ago
  Why wouldn’t you put your inputs in a form element?
  - crabmusket 2y ago
    I mainly work on a large complex SPA with UX that does not often look like a form, but does have lots of inputs. These days I'm much bigger on semantic HTML, to the small extent it matters in our case, but there is a large burden of pages which were just div soup and loose inputs.
  - lelanthran 2y ago
    > Why wouldn’t you put your inputs in a form element? Not all inputs are form-submission data. For example a datalist-backed input to scroll to a specific page/chapter/section/subsection in a long document. You might populate the datalist with hundreds of entries so you don't have a long list of links that the user will have to scroll through in the sidebar. You can perform the scroll on the change event of the input. That's a good UI for the user, instead of presenting a long list of links for the user to browse/search through, they simply have the input auto-suggest based on the populated datalist.
- prmph 2y ago
  Nah, this does not work reliably. The weirdness I've found regarding autocomplete will fill a book.
  - martijnarts 2y ago
    I'd love to read a "Falsehoods programmers believe about..." post about this!
inopinatus 2y ago
Apple’s webkit team killed customised built-in elements by refusing to implement them on ideological grounds, so you get a dripfeed of piecemeal solutions instead.
- greiskul 2y ago
  Apple is actively sabotaging the web for a number of years now. They don't want web apps to be able to compete with native iOS apps. And they prohibit different browsers from the app store, so users don't even have a choice.
- troupo 2y ago
  Those reasons are not ideological and there's a new proposal that doesn't have the downsides of the original spec and enables new use cases discovered since: https://github.com/WICG/webcomponents/issues/1029 https://github.com/WICG/webcomponents/issues/1029 Nothing with customizable built-ins would give you what the original commenter asked for
  - deleted 2y ago
    [deleted]
cosmic_cheese 2y ago
Datagrid is mysteriously missing on several newer desktop UI frameworks too, which effectively makes those frameworks ill-suited for a whole range of desktop applications. The only place reasonably batteries-included versions of those widgets can be found are in the old guard toolkits like AppKit, win32, MFC, Qt, GTK, etc.
thrance 2y ago
Right? There are already dozens of deprecated elements, just deprecate these too and give us new ones that actually do what they're supposed to do and don't require us to know the entire history of HTML just to do a dang <select> that isn't ugly.
user3939382 2y ago
Please forgive my tangential rant on the DOM. You have an input field where type=number and when you read it with .value() you get a string. Cmon man.
- MildlySerious 2y ago
  There is .valueAsNumber. input.value returns a string, regardless of the input type. Making the return type dynamic would be worse, imo.
cxr 2y ago
> Where is the native HTML datagrid (that supports sorting, filtering, paging, downloading, row/column freezing, column resizing and re-ordering)? That's called <table>. https://news.ycombinator.com/item?id=42163128 https://news.ycombinator.com/item?id=42163128 https://news.ycombinator.com/item?id=39489285 https://news.ycombinator.com/item?id=39489285
- prmph 2y ago
  I'm not sure how those comments address the need for a built-in table element with the said features. Can you explain, or link to demo that shows what you are trying to say?
  - cxr 2y ago
    https://www.mozilla.org/en-US/firefox/features/picture-in-picture/ https://www.mozilla.org/en-US/firefox/features/picture-in-pi... https://old.reddit.com/r/PleX/comments/mr1k8m/just_discovered_the_picture_in_picture_mode_in/ https://old.reddit.com/r/PleX/comments/mr1k8m/just_discovere... https://news.ycombinator.com/item?id=43121881 https://news.ycombinator.com/item?id=43121881
dansalvato 2y ago
I think some of this stuff isn't the responsibility of HTML. If HTML already has a full autocomplete spec, isn't it the fault of browsers/extensions/OS if the implementation is broken? Or are you saying the spec is too ambiguous? A lot of stuff becomes redundant under the framing that HTML is designed to provide semantics, not a user interface. How is a toggle button different from a checkbox? How are tabs different from <details>, where you can give multiple <details> tags the same name to ensure only one can be expanded at a time? Image manipulation is totally out of scope for HTML. <input type="file"> has an attribute to limit the available choices by MIME type. Should there be special attributes for the "image" MIME type to enforce a specific resolution/aspect ratio? Can we expect every user agent to help you resize/crop to the restrictions? Surely, some of them will simply forbid the user from selecting the file. So of course, devs would favor the better user experience of accepting any image, and then providing a crop tool after the fact. Data grid does seem like a weak spot for HTML, because there are no attributes to tell the user agent if a <table> should be possible to sort, filter, paginate, etc. It's definitely feasible for a user agent to support those operations without having to modify the DOM. (And yes, I think those attributes are the job of HTML, because not every table makes sense to sort/filter, such as tables where the context of the data is dependent on it being displayed in order.) Generalized rant below: Yes, there are pain points based on the user interfaces people want to build. But if we remember that a) HTML is a semantic language, not a UI language; and b) not every user agent is a visual Web browser with point-and-click controls, then the solution to some of these headaches becomes a lot less obvious. HTML is not built for the common denominator of UI; it's built to make the Web possible to navigate with nothing but a screen reader, a next/previous button, and a select/confirm button. If the baseline spec for the Web deviates from that goal, then we no longer have a Web that's as free and open as we like to think it is. That may be incredibly obvious to the many Web devs (who are much more qualified than me) reading this, but it's not something any end user understands, unless they're forced to understand it through their use of assistive technology. But how about aspiring Web devs? Do they learn these important principles when looking up React tutorials to build some application? Probably not—they're going to hate "dealing with" HTML because it's not streamlined for their specific purpose. I'm not saying the commenter I'm replying to is part of that group (again, they're probably way more experienced than me), but it reminded me that I want to make these points to those who aren't educated on the subject matter.
troupo 2y ago
> Where is the native HTML 14 years have been wasted on making web components happen, and they still offer... nothing really, and people already advise to skip large portions of their specs (Shadow DOM) even if you adopt them. Imagine if the literally millions of dollars spent of them were spent on something like https://open-ui.org/ https://open-ui.org/ (started by Microsoft of all companies and now also completely overrun by Googlers)
- JodieBenitez 2y ago
  I find web components very useful. Yes, I avoid shadow DOM as it only makes things more complicated for me, but having bits of functionality grouped in a new tag is great.
  - troupo 2y ago
    Yeah, the "HTML Web Components" can be useful: https://adactio.com/journal/20618 https://adactio.com/journal/20618 and https://blog.jim-nielsen.com/2023/html-web-components/ https://blog.jim-nielsen.com/2023/html-web-components/
    - JodieBenitez 2y ago
      > You just take some normal HTML markup, wrap it with a custom element, and then write some JS to add capabilities which you can then style with regular CSS! Everything’s of the Light Side of the Web. No need to pierce the Vale of Shadows or whatever. Ah ! Yes, that's basically me.
adam12 2y ago
I'm just glad I don't have to support IE6 anymore.
nikeee 2y ago
Internet Explorer had a native Data Grid with two-way data binding and much more. https://schepp.dev/posts/today-the-trident-era-ends/#data-grids https://schepp.dev/posts/today-the-trident-era-ends/#data-gr...
- xnx 2y ago
  That's a great article about advancements in IE that still haven't all been matched.
vivzkestrel 2y ago
you forgot the most important one, where s the browser native virtual list, grid and table?
arkh 2y ago
> Where is the native HTML datagrid Imagine a world where instead of letting IE die, microsoft decided to add a <XLS> tag in the early 2000. The most used nocode database in the world directly in the browser. In 2000.
- numtel 2y ago
  You do realize that that was the big problem with IE security in those days: ActiveX. You literally could embed an Excel file in your HTML page. You could embed any native code and it would just be a small yes/no dialog to download and run it.
Devasta 2y ago
HTML can never be meaningfully improved, that fact is at the heart of the current attitudes by the browsers. We are 20 years into the takeover from the W3C and still can't even do a PUT request without JS, nevermind anything approaching even one tenth of the capability of XForms. The best we'll get is little improvements like this which everyone will ignore because ChatGPT will recommend some react component instead.

by prmph 2y ago

sa46 2y ago

> Where is the native HTML datagrid Which parts of a datagrid should a browser provide? I'm familiar with AG Grid [1] and the API surface is enormous. Aligning browsers on a feature set would be challenging. Maybe there's a core set of functionality, like Flutter's GridView or QML https://doc.qt.io/qt-6/qml-qtquick-gridview.html https://doc.qt.io/qt-6/qml-qtquick-gridview.html. [1]: https://www.ag-grid.com/ https://www.ag-grid.com/

crab_galaxy 2y ago
The simplest would be to follow the aria role=“grid” spec, ideally with sortable columns. IMO it doesn’t need the kitchen sink AG Grid approach just a sane way to semantically build a data grid with proper accessibility. https://www.w3.org/WAI/ARIA/apg/patterns/grid/examples/data-grids/ https://www.w3.org/WAI/ARIA/apg/patterns/grid/examples/data-...
- dimal 2y ago
  It has to handle every possible use case for a grid. You’re thinking of your use case. The spec needs to handle everything else. I don’t see how that’s manageable.
  - sensanaty 2y ago
    At minimum filtering and sorting should be handled by the browser, including async for both of those. Pagination could be argued as well, but at least that's simple-ish to implement (but still, it's such a common UI pattern that it ought to be handled in a unified way by browsers IMO)
    - dimal 2y ago
      Look at how much effort has gone into just getting a stylable select box. Look at tooltips. A data grid is several orders of magnitude higher in complexity than both of these. You are severely underestimating the complexity of your ask. HTML/JS/CSS is not supposed to solve all your UX problems. It’s a toolkit for building UIs, not a framework.
      - prmph 2y ago
        Is it not the design by committee approach that slows down the design consensus on things like these? Just complex is it to design a spec for a stylable select box that is reasonable for most use cases? If it has to take decades to agree on a design for a stylable select box, then there is something fundamentally broken with the approach.
        dimal 2y ago
        For an open standard, how do you design it without agreement among a committee? Just let Google go rogue and define it? And have you ever worked in a large company? Have you seen how difficult it is to get any large group of people to agree on ANYTHING? These specs depend on the agreement of multiple large companies coming together. Each one of those companies is made up of many subcommittees who have to come into agreement with each other. While maybe you could imagine a straightforward technical implementation (and I think you’re overlooking the complexity of getting the API right while making it extensible), the social engineering involved to make this happen would be Herculean. And it would be for an element that’s on less than 1% of web pages. If you really want a data grid, I’d suggest learning how to code one. It’s a fun challenge, and implementing basic features like sorting and filtering isn’t difficult using a modern framework. If it is difficult for you, then I’d suggest that it would be a GREAT experience to try. Then imagine how you’d make it extensible for unknown use cases. The main reason it took decades for a stylable select box is because for two decades, we were just told “Don’t style select boxes. It’s bad for usability,” which was a mistake. We’ve only started to overcome that mindset in the past few years. The work on stylable select boxes only started in the past few years.

tisc 2y ago

Imo it’s not html, it’s browser vendors. There’s a decent specification for the `autocomplete` attribute: https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/autocomplete https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes...

kevincox 2y ago
It is actually a reaction to websites doing stupid things to try and prevent password auto-fill. The sites are fighting against security in a misguided attempt to improve security, so the browser vendors added a bunch of heuristics to try and correct these situations and you end up with the mess we have.
- petepete 2y ago
  Equally having to jump through extra hoops to prevent autocomplete where you don't want it is frustrating, like in admin interfaces where you might be updating someone else's name. It's an arms race of stupidity.

nonchalantsui 2y ago

I'm not finding any of those proposals on the whatwg html repo, mind linking them?

prmph 2y ago
That's my point, they are not on the roadmap, although they absolutely should be, IMO. The W3C and WHATWG have their priorities mixed up.

robertoandred 2y ago

Safari already has toggle buttons and autocomplete directives.

dfabulich 2y ago

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.

crabmusket 2y ago

RE autocomplete in Chrome. The only thing we've found to work reliably is ensuring that all inputs are in form elements. Any inputs outside forms are going to have inappropriate autocomplete prompts. It's extremely annoying but at least this works for now. (I say "for now" because who knows when the Chrome team will change their heuristic?)

joshuacc 2y ago
Why wouldn’t you put your inputs in a form element?
- crabmusket 2y ago
  I mainly work on a large complex SPA with UX that does not often look like a form, but does have lots of inputs. These days I'm much bigger on semantic HTML, to the small extent it matters in our case, but there is a large burden of pages which were just div soup and loose inputs.
- lelanthran 2y ago
  > Why wouldn’t you put your inputs in a form element? Not all inputs are form-submission data. For example a datalist-backed input to scroll to a specific page/chapter/section/subsection in a long document. You might populate the datalist with hundreds of entries so you don't have a long list of links that the user will have to scroll through in the sidebar. You can perform the scroll on the change event of the input. That's a good UI for the user, instead of presenting a long list of links for the user to browse/search through, they simply have the input auto-suggest based on the populated datalist.
prmph 2y ago
Nah, this does not work reliably. The weirdness I've found regarding autocomplete will fill a book.
- martijnarts 2y ago
  I'd love to read a "Falsehoods programmers believe about..." post about this!

inopinatus 2y ago

Apple’s webkit team killed customised built-in elements by refusing to implement them on ideological grounds, so you get a dripfeed of piecemeal solutions instead.

greiskul 2y ago
Apple is actively sabotaging the web for a number of years now. They don't want web apps to be able to compete with native iOS apps. And they prohibit different browsers from the app store, so users don't even have a choice.
troupo 2y ago
Those reasons are not ideological and there's a new proposal that doesn't have the downsides of the original spec and enables new use cases discovered since: https://github.com/WICG/webcomponents/issues/1029 https://github.com/WICG/webcomponents/issues/1029 Nothing with customizable built-ins would give you what the original commenter asked for
- deleted 2y ago
  [deleted]

cosmic_cheese 2y ago

Datagrid is mysteriously missing on several newer desktop UI frameworks too, which effectively makes those frameworks ill-suited for a whole range of desktop applications. The only place reasonably batteries-included versions of those widgets can be found are in the old guard toolkits like AppKit, win32, MFC, Qt, GTK, etc.

thrance 2y ago

Right? There are already dozens of deprecated elements, just deprecate these too and give us new ones that actually do what they're supposed to do and don't require us to know the entire history of HTML just to do a dang <select> that isn't ugly.

user3939382 2y ago

Please forgive my tangential rant on the DOM. You have an input field where type=number and when you read it with .value() you get a string. Cmon man.

MildlySerious 2y ago
There is .valueAsNumber. input.value returns a string, regardless of the input type. Making the return type dynamic would be worse, imo.

cxr 2y ago

> Where is the native HTML datagrid (that supports sorting, filtering, paging, downloading, row/column freezing, column resizing and re-ordering)? That's called <table>. https://news.ycombinator.com/item?id=42163128 https://news.ycombinator.com/item?id=42163128 https://news.ycombinator.com/item?id=39489285 https://news.ycombinator.com/item?id=39489285

prmph 2y ago
I'm not sure how those comments address the need for a built-in table element with the said features. Can you explain, or link to demo that shows what you are trying to say?
- cxr 2y ago
  https://www.mozilla.org/en-US/firefox/features/picture-in-picture/ https://www.mozilla.org/en-US/firefox/features/picture-in-pi... https://old.reddit.com/r/PleX/comments/mr1k8m/just_discovered_the_picture_in_picture_mode_in/ https://old.reddit.com/r/PleX/comments/mr1k8m/just_discovere... https://news.ycombinator.com/item?id=43121881 https://news.ycombinator.com/item?id=43121881

dansalvato 2y ago

I think some of this stuff isn't the responsibility of HTML. If HTML already has a full autocomplete spec, isn't it the fault of browsers/extensions/OS if the implementation is broken? Or are you saying the spec is too ambiguous? A lot of stuff becomes redundant under the framing that HTML is designed to provide semantics, not a user interface. How is a toggle button different from a checkbox? How are tabs different from <details>, where you can give multiple <details> tags the same name to ensure only one can be expanded at a time? Image manipulation is totally out of scope for HTML. <input type="file"> has an attribute to limit the available choices by MIME type. Should there be special attributes for the "image" MIME type to enforce a specific resolution/aspect ratio? Can we expect every user agent to help you resize/crop to the restrictions? Surely, some of them will simply forbid the user from selecting the file. So of course, devs would favor the better user experience of accepting any image, and then providing a crop tool after the fact. Data grid does seem like a weak spot for HTML, because there are no attributes to tell the user agent if a <table> should be possible to sort, filter, paginate, etc. It's definitely feasible for a user agent to support those operations without having to modify the DOM. (And yes, I think those attributes are the job of HTML, because not every table makes sense to sort/filter, such as tables where the context of the data is dependent on it being displayed in order.) Generalized rant below: Yes, there are pain points based on the user interfaces people want to build. But if we remember that a) HTML is a semantic language, not a UI language; and b) not every user agent is a visual Web browser with point-and-click controls, then the solution to some of these headaches becomes a lot less obvious. HTML is not built for the common denominator of UI; it's built to make the Web possible to navigate with nothing but a screen reader, a next/previous button, and a select/confirm button. If the baseline spec for the Web deviates from that goal, then we no longer have a Web that's as free and open as we like to think it is. That may be incredibly obvious to the many Web devs (who are much more qualified than me) reading this, but it's not something any end user understands, unless they're forced to understand it through their use of assistive technology. But how about aspiring Web devs? Do they learn these important principles when looking up React tutorials to build some application? Probably not—they're going to hate "dealing with" HTML because it's not streamlined for their specific purpose. I'm not saying the commenter I'm replying to is part of that group (again, they're probably way more experienced than me), but it reminded me that I want to make these points to those who aren't educated on the subject matter.

troupo 2y ago

> Where is the native HTML 14 years have been wasted on making web components happen, and they still offer... nothing really, and people already advise to skip large portions of their specs (Shadow DOM) even if you adopt them. Imagine if the literally millions of dollars spent of them were spent on something like https://open-ui.org/ https://open-ui.org/ (started by Microsoft of all companies and now also completely overrun by Googlers)

JodieBenitez 2y ago
I find web components very useful. Yes, I avoid shadow DOM as it only makes things more complicated for me, but having bits of functionality grouped in a new tag is great.
- troupo 2y ago
  Yeah, the "HTML Web Components" can be useful: https://adactio.com/journal/20618 https://adactio.com/journal/20618 and https://blog.jim-nielsen.com/2023/html-web-components/ https://blog.jim-nielsen.com/2023/html-web-components/
  - JodieBenitez 2y ago
    > You just take some normal HTML markup, wrap it with a custom element, and then write some JS to add capabilities which you can then style with regular CSS! Everything’s of the Light Side of the Web. No need to pierce the Vale of Shadows or whatever. Ah ! Yes, that's basically me.

adam12 2y ago

I'm just glad I don't have to support IE6 anymore.

nikeee 2y ago

Internet Explorer had a native Data Grid with two-way data binding and much more. https://schepp.dev/posts/today-the-trident-era-ends/#data-grids https://schepp.dev/posts/today-the-trident-era-ends/#data-gr...

xnx 2y ago
That's a great article about advancements in IE that still haven't all been matched.

vivzkestrel 2y ago

you forgot the most important one, where s the browser native virtual list, grid and table?

arkh 2y ago

> Where is the native HTML datagrid Imagine a world where instead of letting IE die, microsoft decided to add a <XLS> tag in the early 2000. The most used nocode database in the world directly in the browser. In 2000.

numtel 2y ago
You do realize that that was the big problem with IE security in those days: ActiveX. You literally could embed an Excel file in your HTML page. You could embed any native code and it would just be a small yes/no dialog to download and run it.

Devasta 2y ago

HTML can never be meaningfully improved, that fact is at the heart of the current attitudes by the browsers. We are 20 years into the takeover from the W3C and still can't even do a PUT request without JS, nevermind anything approaching even one tenth of the capability of XForms. The best we'll get is little improvements like this which everyone will ignore because ChatGPT will recommend some react component instead.