Hacker News Reader

Comment by wildrhythms | Hacker News Reader

I work in UX, I am constantly being given designs that don't work well with native/semantic elements- a great example is tables. As soon as the table needs some kind of animation, drag-drop behavior, anything like that, I can't use a <table> anymore; or it becomes some frankenstein kafkaesque amalgamation that is impossible to maintain. Does the table really need an animation? (probably not) drag and drop? (probably not) But management and the people in charge of OK'ing these designs have a 'make-it-happen' attitude and nobody really cares about semantic, native feel when they've invested so much into a "design system" that is largely antithetical to that.

Select elements are the bane of my existence. Impossible to style. I am constantly re-implementing a <select> because it has to look a certain way. Just terrible.

View on HN

What you need is Open UI. The browser vendors are working on it.

https://open-ui.org/

> The purpose of Open UI to the web platform is to allow web developers to style and extend built-in web UI controls, such as <select> dropdowns, checkboxes, radio buttons, and date/color pickers.

> To do that, we'll need to fully specify the component parts, states, and behaviors of the built-in controls, as well as necessary accessibility requirements, and provide test suites to ensure compatibility. We'll also implement polyfills for our extensible web UI controls.

Mandatory standards xkcd

For todays lucky 10,000 https://xkcd.com/927/

For todays lucky 10,000 concerning the lucky 10,000 https://xkcd.com/1053/

HTML and CSS is one standard, two if you squint. The problem is a hundred nonstandard ways to do it, and this is going to be the first standardization of this for the web. I don't think that comic is relevant.

Oh wow. Thanks for pointing this out. I had no idea this was happening. I've wanted it for forever, but I thought browser vendors had always shut down talk with "just don't style native controls" dogma. Good to see it changing to reflect the reality that everyone does it anyway.

For what it’s worth, I’ve had pretty good luck styling checkboxes and radio buttons (e.g. with appearance: none), however I’ve had pretty though luck styling selects. My best shots at custom selects have involved multiple backgrounds, css masks with linear gradients, etc. As for the options list, I’ve never even tried.

In an fortunate twist for the unfortunate circumstances, the fact that there's fewer browser rendering engines today means that it's easier to get "all" browsers at the table and agree with a singular direction for things like these: there's simply fewer of them.

> The browser vendors are working on it.

How's progress?

https://open-ui.org/charter

> Most recent revision: April 1, 2020

That doesn't inspire confidence...

Well, it only took 25 years to get some real control over vertical alignment via grid, maybe selects will not be horrible by… 2029? I live in hope.

It’s definitely active, just today I was listening to Dave Rupert talking about a versatile element for tabs widgets (and other things) that’s really making good progress.

Isn't that just the charter which lists their goals? Should their organizational goals change massively in a single year? The charter of most NGOs basically stays static for their entire lifetime.

I think they're referring to the date, April 1 is "April Fool's Day" in many countries. Some companies put out joke press releases on April 1 that are not intended to be taken seriously.

https://github.com/openui/open-ui last commit 10 hours ago

Confusing naming as there already exists https://openui5.org Open-source sibling of SAPUI5

And when you reimplement <select>, it won’t feel native because different platforms have different conventions (e.g. placement of dropdown, click-and-drag behaviour, whether focus is selection, keyboard shortcuts like Tab), and very few implementations try even half-baked user-agent sniffing to try to emulate the platform. And that’s just thinking about desktop platforms; on mobile platforms, the native dropdown behaviour is simply unimplementable.

I would say: if it’s just about the style of the <select>, stubbornly refuse to reimplement it, just do what you can on it with CSS and try no further. If you’re needing different functional behaviour (e.g. adding right-aligned text on each option, or making it intelligently filterable by typing—e.g. an airport picker making “CHC” match “Christchurch”), then yeah, you’ve got to reimplement <select> even though it’ll necessarily be a smidgeon worse in some ways.

<select> makes a very bad primitive.

Not only that, but reimplementations tend to have bugs. I cannot remember a single time I used YouTube's comment text field without some bug in the last 5 years. It always breaks in some way, usually when line breaks get involved. Right now when I press Return twice the cursor will only move down one line. It's been like that for at least 6 months. Now and then they replace the bug with a different one, but it never really works correctly.

>and very few implementations try even half-baked user-agent sniffing to try to emulate the platform

well, to be fair every tutorial on JS for the last 16+ years or so has said avoid user-agent sniffing but only detect capabilities, not to mention freezing of user agent string will make this point moot. Problem of course being that you cannot detect how the specific browser makes a select work with capability detection.

Freezing the user-agent string won’t prevent sniffing, it’ll just possibly make sniffing of precise version numbers a bit more difficult (… because you’ll be abusing feature detection to achieve it); but for this sort of thing you’re mostly just caring about the platform at a coarse level, and maybe the browser (though I think Edge lost its distinctive <select> style and behaviour in the Chromium migration, so that now all browsers on Windows work roughly the same). So UA freezing won’t cause any trouble at all for this sort of thing.

For various sorts of keyboard shortcuts, this style of platform detection has long been essential, so that you can use altKey/⌘ on Apple platforms and ctrlKey/Ctrl everywhere else. Ain’t never been no feature detection candidate for that.

> But management and the people in charge of OK'ing these designs have a 'make-it-happen' attitude and nobody really cares about semantic, native feel when they've invested so much into a "design system" that is largely antithetical to that.

It feels like at some point you'll just have to start telling them that their ideas will result in technically bad solutions and be ready to look for a new job.

Clearly that's not a good idea for everyone, but if unions could form and fight back against unfair treatment of workers, why don't developers have similar organizations to fight against privacy breaches, unethical development or business practices, or even just unreasonable design demands that are not standards compliant or accessible?

To expand upon that: if doctors refuse to harm people, why do developers harm websites and other pieces of software so readily just because they're told to?

The weird thing is that some things are hilariously complicated in web, but simple in native, and vice versa.

What you described is very easy in eg Qt. You have a bunch of classes representing the table and the contained data, a rendering class etc. that you can extend and override methods easily. Relatively easy, maximum control.

OTOH some years ago (still Qt4 times iirc) I was supposed to add a messaging function to an app that should look like mobile messaging, with those speech bubbles. It was a freaking nightmare to get this past a proof of concept that wouldn't have weird glitches and performance issues if you tried to break it. After two weeks of iterations we just embedded a QWebView and got it working better than ever before within two days, although we felt pretty stupid and defeated for basically pulling in a browser just for that.

Every time I’m given a table mockup, it’s flexible column widths with a sticky header. It’s damn near impossible even with JavaScript.

100% agree. Also consider that tables, uniquely, size to their content. So a cell's width is actually the width of the widest cell in its column; the cell height is the height of the tallest cell in its row. It's a problem with so much hidden complexity, and people who come up with these beautiful table designs genuinely do not understand the hidden challenges of implementing it.

Exactly, non-fixed row heights / column widths are a performance nightmare. I have managed to create a super fast Javascript Data Grid. There are many performance tricks, but the first thing I decided was to give each column a fixed with and each row a fixed height. Here's a One Million Cells demo that shows its performance: https://www.datagridxl.com/demos/one-million-cells.

You can do this all in CSS, if you’re willing to restyle all the table elements to use grid. I demoed this at my last job, and it worked pretty well. (This has its own trade offs)

We used to use tables to style things that should be grids, now we use grids to style what should be tables. Back to square one :)

Just be careful of the accessibility doing this. You need to apply the correct role attributes at every level so it is understood by assistive technology to be a table.

Screen readers give special treatment to tables to help users understand what is being presented. They also offer special commands to help navigating in a row or columnar fashion.

You lose this all of this if you use non semantic elements. I believe semantics can even be lost if you change the css display property of an actual <table> element. Make sure to test whatever you do!

Virtualized scrolling for performance reasons also adds another layer of complexity regarding accessibility. Since not all rows of the table/DataGrid are available in DOM

I'm sure grid was faster than table, However, for real performance benefits, forget about <table> and forget about grid: you need absolutely positioned DOM nodes, and CSS transform/translate for animations. You'll end up with a Data Grid that renders faster than Google Sheets: https://www.datagridxl.com/demos/one-million-cells. (Dislaimer: I am the maker)

You might need table-layout:fixed and could also help to set a column width using colgroup col elements. I think that's what I'm doing on my little table component in this page:https://i5ik.github.io/_____/7guis/

That's why I included "flexible column widths" since it's definitely doable if you use a fixed layout table.

I know it's not great for performance, but to get a sticky header and flexible column widths you can render two tables and contain one of them to show only the header which you can then wrap into a <div>, position absolutely to cover the top of the table and give position: sticky.

For sticky headers you can literally just put `position: sticky` on the thead now!

https://codepen.io/chriscoyier/pen/WNpJewq

That is my exact same experience. In good tookits you have good native components, good Dropdown, GridView,DataView even AdvancedDataView , I could put in a native tookit 1 million items in such a widget and have no more performance hit then 20 items where with web the best practice is to implement pagination.

Imagine a CSV editor implemented in web with the "native" components, you will have to paginate the CSV file after each 20 rows.

In good toolkits you just drop the native widget and customize it, and if some idiot will say that native is not customizable then let me tell you that you have no idea what you are talking about, you could customize as much as you want, even paint the pixels one by one if needed and still get performance when you have a table with 1 million of customized widgets.

You can have a super fast CSV editor online, in fact I made one: https://www.editcsvonline.com/. It's based on my product DataGridXL, which, I believe, is the fastest Data Grid out there.

Editing cell values with EditCSVOnline is faster than it is in Google Sheets :-)

I did not say it is impossible, but it is not a simpel thing like on a toolkit where you would

1 add a DataGrid widget

2 connect a data provider

3 setup special rendering functions for some columns (only if needed)

4 define sorting functions if needed

And that is all, you get performance, sorting, column resizing, re-ordering for free, you can focus on the business logic and not on creating a DataGrid widget from scratch and fixing bugs for years until you get to 20% of the performance and features of similar desktop native one.

TLDR , web needs widgets like desktop toolkits for people that want to focus on bussiness logic, for the rest they can use more simple things they create themselves or npm install or buy some more cool widgets.

With current web tech we spend to much time on re-creating functionality(not styling), have often you see borken menus or dropdowns on websites? Wouldn't a native dropdown that could be styles or a native menu widget that could be styles would make things much better ?

Yeah, I've been in the same situation. I do think drag&drop has a place in tables, but definitely not like some (including our) designers want it to work. Luckily my boss was at least somewhat understanding and (after some convincing) let me implement drag&drop using an "insert line" (idk what to call it) instead of moving the element around for real.

- drag start: opacity: .5 the dragged row - drag move: if hovering over a row, apply border-bottom or border-top depending on which half the cursor is closer to - drag end: move the row to the hovered row, opacity: 1

EDIT: or maybe it was outline instead of border, or even a hard inset box-shadow... Whichever one of those ended up wasting the least time re-calculating layout in testing

> But management and the people in charge of OK'ing these designs have a 'make-it-happen' attitude and nobody really cares about semantic, native feel

I think this is generally a symptom of current leadership practices, where the people making decisions about technical direction are not people who understand how their product functions. This generally isn't top leadership, but the upper and mid level management, who feel they need to "make their mark" on the product to get promoted.

This might be a dumb question but, isn't this something that could be implimented using CSS grid? Not being able to use semantic elements does suck though

Why is drag and drop an unreasonable expectation to have for a table where that makes sense?

Reply on news.ycombinator.com