[danShumway]

Why don't we have completely separate styling systems for mobile devices, widescreen devices, vertical monitors, tablets, and billboard displays? Because that would be a bigger nightmare to deal with than CSS.

I like that when I visit a web page on my mobile phone, it loads regardless of whether or not the site owners hired someone to build a completely separate interface. And I like that when I design interfaces for phones and for large screens, I don't need to learn 2 languages to do it. And I like that when I stack two browser windows next to each other on a 1920x1080 monitor they resize and I can read both of them.

When people say that they don't want to worry about multiple screen sizes in their layout, they mean that they want an interface that works on one screen size and ignores everything else. And that would be a huge loss for accessibility and innovation if the web pushed developers in that direction. The reason it would be simpler for people to work with a more targeted language is because they wouldn't build the other interfaces at all. They'd learn one language, target one device that their most predominant customers used, and then we'd have a mobile Internet and a desktop Internet and they'd be separate things with no expectations that sites would work on both devices.

----

And I think this sort of gets to the complaints about complexity in general, because the complexity of this UI design is reflecting a reality that good interfaces are adaptable and people have multi-faceted needs from their software. Even on desktop, people use different screen resolutions, they scale fonts, they mess with layout. And there's this subtle idea behind complaints about complexity that when you dig into it is not actually "why do I have to target so many devices" but is really "why do people use so many devices? Why isn't the world more uniform, why on earth are people changing their screen resolutions, what's wrong with them? Why can't they just decide on a device and stick with it?"

But good UX design is about designing for the real world, not for a hypothetical standardized human, and in the same way that cars need adjustable seats and can't just say "well on average everyone is this height and width", good UX acknowledges and responds to the idea that software and content are delivered in multiple contexts.

Of course that's a balancing act, it does make interface design more complicated, and it's not something we can do perfectly. But it is a balancing act, it's not a problem we can solve by saying "heck it, everyone needs to stop buying HDPI laptops." I mean, we're not all Linux developers, we can't all just pretend that touchscreens don't exist ;)

The same exact complaints show up with the extensible web and with progressive fallbacks in general. It is real annoying to build software that degrades nicely depending on what hardware support someone has and what features they've turned on and off in their browser. But it's also a better way to build software that better reflects how software is used in the real world by real people.

[taeric]

A problem is that none of the arguments you are offering are bad, logically. It feels very appealing to think you can build a system that would solve "laying out text" for all time.

For me, what they lack is evidence that stands any stronger than video games. Specifically, I've played different games on various screen sizes and orientations that largely work as you would expect. They are not perfect, of course, but they work better than most web pages seem to. And they do that, largely, without the same reliance on something like CSS that web pages need.

More, it isn't like we weren't laying out billboard displays long before the web came to be. Nor is it realistic that billboards have at all the same concerns that a pocket sized phone will have. At large, you shouldn't even use the same fonts between those options. Heck, taken farther, a billboard can hold a slogan, that is about it.

This would be the same as if you tried to use HTML/CSS to make a poster for a movie. Which, sure, you can make a bit of an effort with it. I just don't see it being any better than letting a designer or probably an automated system layout several standard sizes with the standard type in the standard locations.

Pulling it in, I'll be delighted to get proven wrong and find that we have converged to a great abstraction for laying out content. I, of course, do not /know/ that it can't be done. I do pull my hair out at the amount of effort people will go to in order to have the system layout a set of divs, when most designs could probably have done a lot of that math up front and worked with far fewer nested elements than we seem to typically see.

[auggierose]

Good layout is simple. But can it be flexibly done without a good sense for abstraction and math? No. I mean, just look at the hot shit that is Tailwind, that's what people come up with while fighting abstraction.

CSS was a mess, but together with React is now the best language for building GUIs. You can build up any abstraction you want in React, even

    <FullScreen><Center>Hello World!</Center></FullScreen> 

In fact, that's what I did over the weekend for my Electron desktop application, writing my own little library of components, including tabs and treeviews, using only CSS and React and no third-party libraries apart from that.

You already have been proven wrong. You are just not ready to accept the proof.

[troupo]

> CSS was a mess, but together with React is now the best language for building GUIs.

People should stop saying this lie. To di so, they should try and look outside of the web for even a nanosecond.

Even Turbo Pascal from 1990s is a better language for describing UIs.

The "best language for building UIs" chokes on less than 1000 elements on a static page: https://pbs.twimg.com/media/GF__tHjXgAAZGUA?format=jpg&name=...

Compare that to an actual UI: https://cdm.link/app/uploads/2023/11/CleanShot-2023-11-15-at...

[danShumway]

So, a couple of issues:

A) Out of curiosity, is that "actual" UI screenreader accessible and does it work on mobile devices? Does it work with touchscreens? Can I scale the text? Maybe it does, I don't recognize the program off the top of my head. But I don't assume that by default.

And very often this is just the same argument over and over again. "Check out how cool the thing is that I can build when I assume that you'll be using a widescreen desktop monitor with a mouse and keyboard in the full screen." I mean, great, that's very cool, but I'm glad the the web doesn't allow you to make those assumptions. It's a better platform for forcing you to care about more stuff.

B) You can absolutely get more than 1000 elements on a static page, it's not that big a deal unless you're doing something weird. Of course, if you are putting 1000 elements on a page, you might take a step back and ask yourself why you're doing that because giant pages with thousands and thousands of nested elements are hell for screenreaders. You want to update a thousand pieces of the DOM at the same time. Well, OK, let's ask for a second whether that's actually good interface design. I would argue maybe it's not?

I make this point a lot on HN, but if you can't describe your interface using pure text, you don't have an accessible interface, period. And to rephrase point A, you're correct that if you don't worry about that, you can make very complicated interfaces that are extremely performant, and wow am I glad the web forces you to worry about that.

C) People have a fundamental misunderstanding of what the DOM is and how it should be used, in part influenced by treating the DOM as a markup tool rather than as a render target -- but suffice to say, there is nothing about the interface you're showing me that makes me think it's not doable on the web. Some of these visual components you might jump out and use canvas for -- that's not violating the spirit of the web, the DOM is your user interface, and a bunch of nested DOM elements that simulate a slider using div soup is not more accessible or semantic or maintainable than an actual native browser slider with accessible controls that you throw a canvas element in front of.

The thing that would be hard about building this interface on the web is I would have to care about what happens if the font size changes, and I would have to care about what happens if the user opens the app on a phone, and I would need to care about tab controls and turning this interface into an actual hierarchy, and I would have to think about touch screens, and I would need to have higher standards for my interface design than just "how many elements can I fit on a screen at the same time?".

And again, I am grateful every single day that the web forces designers to think about that stuff.

[troupo]

Your question stem from a few assumptions that you consider inviolable, so I'll go through them one by one

- that all software has to work on mobile

This is a fallacy. Not all software has to work on mobile. More over, mobile-first approach is exactly the wrong approach for a lot of software.

No, the software in question will not work mobile. Because it's a screenshot of Ableton Live, a professional DAW specifically made for desktop and for manipulation with mouse and keyboard.

It doesn't mean that the web is somehow superior here because "it can work on mobile, too". Not for complex UIs, for the exact same reason: screen sizes and interactions on mobile are completely different from desktop screen sizes and interactions. The simpler the UI and interaction, the better it works across desktop and mobile. See, e.g. the stripped-down versions shipped with SwiftUI/Catalyst.

- that complex dynamic UIs like the one in the screenshot can actually be done in DOM, no problem

No, they can't. And you immediately list several reasons: "because giant pages with thousands and thousands of nested elements are hell for screenreaders" and "You want to update a thousand pieces of the DOM at the same time. Well, OK, let's ask for a second whether that's actually good interface design. I would argue maybe it's not?" and "Some of these visual components you might jump out and use canvas for "

All this translates to: no, you can't make the same interface in DOM.

1. Complex dynamic interactive UIs are a hell for screenreaders regardless of technology. And there are no good solutions there.

2. Updating tens of thousands of elements is not an issue even for mobile. Games routinely update tens to hundreds of thousands of elements in a matter of milliseconds. If it's a problem for DOM, it's an indictment of DOM.

Updating even hundreds of elements is quite an ordeal for the browser. Professional software will easily update hundreds (or indeed thousands) of elements in its UI at any point without breaking a sweat. If that seems challenging to you, that's the problem of the technology you use and defend, not of the UI.

3. If you need to "jump out to canvas" to implement certain stuff, then you failed both your claim about screenreaders (canvas is 100% inaccessible) and your claim about "doable in DOM" (you wouldn't have to jump out to canvas).

Just like Figma you'd have to jump out for a lot of stuff and possibly "implement a browser inside a browser" (Figma's own words: https://www.figma.com/blog/building-a-professional-design-to...)

There's a gazillion reasons why recreating that UI in DOM is extremely difficult: browser will likely choke on that many elements, you have very little control over positioning and layout, any interactivity is likely to choke the browser due to multiple DOM updates and constant layout re-calculations etc. etc. etc.

> and I would need to have higher standards for my interface design than just "how many elements can I fit on a screen at the same time?".

No, no you wouldn't. If that was true in the general case, we would actually have actual correct beautiful performant useable useful UIs on the web. The matter of fact is that this is not the case, and web UIs are universally bad, underperforming, breaking all possible interaction modes etc.

And no. That Ableton Live UI isn't "cram as many controls as you can into UI".

> And again, I am grateful every single day that the web forces designers to think about that stuff.

This is such a bold lie.

[danShumway]

> This is a fallacy. Not all software has to work on mobile. More over, mobile-first approach is exactly the wrong approach for a lot of software.

Okay, sure, the web would be better if it wasn't cross platform. My bad, I didn't realize that it was actually a bad thing that I can check my bank account balance from Android Firefox. /s

Come on, seriously?

I don't know if it's actually worth going through this over and over again when you are literally just re-summing up my point. That all of this, "oh interface design would be so much better" talk very often boils down to:

"I shouldn't have to worry about real-world design constraints."

I am once again, so so happy that the web doesn't give you that option. Just wait until you find out that in most industries there are literal laws around considering stuff like accessibility. In most industries you don't get to act like people saying "should blind users be able to enjoy the thing" is some kind of moral slight against your artistic integrity.

But, to very quickly go over this:

----

> 1. Complex dynamic interactive UIs are a hell for screenreaders regardless of technology. And there are no good solutions there.

As it turns out, the answer is no, these professional awesome UIs that are so great don't worry about accessibility, I was correct: https://forum.ableton.com/viewtopic.php?t=230533

And once again, the critique becomes, "but accessibility is hard when I approach UIs this way, so I just shouldn't have to think about it."

And that's why we have HTML; because software UI developers don't think about a dang thing if they're not forced to. I cannot believe someone is going to try and argue that the web is worse because it works with screen readers and adblockers and extensions and all of the amazing stuff we can do because interfaces are at their core based on text and markup.

> 2. Updating tens of thousands of elements is not an issue even for mobile. Games routinely update tens to hundreds of thousands of elements in a matter of milliseconds. If it's a problem for DOM, it's an indictment of DOM.

Games are not a shining example of flexible UIs and they shouldn't be your target for most application UIs. The reason why updating tens of thousands of elements at the same time is problematic is because signaling those updates becomes a problem for users with low vision.

Nevertheless, the web has escape hatches for this in the form of Canvas/WebGL. Of course, it's harder to use them, because they shouldn't be the default thing you reach for.

> 3. If you need to "jump out to canvas" to implement certain stuff, then you failed both your claim about screenreaders (canvas is 100% inaccessible) and your claim about "doable in DOM" (you wouldn't have to jump out to canvas).

No, if you put a canvas in front of a native slider, that is 100% accessible, there is zero issue there. People don't understand how the DOM works. You can have canvas elements in your design. The only thing that actually gets in the way of accessibility is not having the slider. But there's not a requirement that your slider be made of 40 div elements, you can use the built-in browser primitives. The screenshot you provided of Ableton doesn't have 10 thousand actual logical elements in it to update.

It's got like a couple of dozen separate controls here, maybe if you want to be real generous a couple hundred: but they're just designed using some kind of skewmorphic crud that makes them seem more complicated than they actually are. But it's literally just not a problem for a couple of grid elements in there to be canvases, I'm not saying that you have to use divs for every single element in this UI.

Of course it also wouldn't be a problem for the design of some of these controls to be simpler and more visually consistent and to use common UI paradigms instead of mimicking guitar dials, but whatever, music production is obsessed with simulating physical dials in software for whatever reason. This is why I have to run a compatibility suite to get midi plugins working between Linux and Windows, because every plugin has to be quirky and ship with an entire graphics library.

Heaven forbid that we use buttons, that would get in the way of my moral duty to make my interface look like a piano. /s

One of the reasons why working with text during interface design makes you a better designer over time is because you start to group controls more and you start to think more about controls like they're logical units rather than just as collections of pixels on the screen.

> No, no you wouldn't. If that was true in the general case, we would actually have actual correct beautiful performant useable useful UIs on the web.

People need to heck off with this. We do have good UIs on the web. Better UIs than on native in multiple cases. Your standard for what is a good UI dismisses everything that is good about web UIs, but if you actually want to talk about responsive design that works in the real world and not just for a hypothetical happy-path mouse-controlled desktop, then the web often produces better UI results than native platforms.

And the web produces this result that literally no other platform can claim even though it is far more developer-accessible than most of these other platforms that people champion. I'm so tired of pretending that because somebody laid out a UI in Photoshop and they couldn't get pixel-perfect results on the web that somehow the web has failed. It hasn't. The web gets non-programmers to produce better, more accessible UIs than these professionals on the desktop that can't be asked to give a single heck about anyone who's not a prototypical customer using a standardized setup.

> This is such a bold lie.

You're right, I'm lying I'm not actually grateful for the web, you saw through my deception! /s What are you talking about?

[taeric]

Where was I proven wrong? Does that example compile down to something that isn't several dozen nested divs using react?

As stated in my post, happy to be proven wrong if that is the case. I am fairly far removed from a lot of this nowadays, and it would not be the first time that the world moved on without my noticing rapidly. (My favorite example of this is just how good battery technology has gotten. A decade ago, a battery powered lawn mower was a laughable idea. )

[danShumway]

Does it matter if it does compile down to that?

A lot of abstractions are complicated under the hood -- the high-level graphics formats that are used in engines are under the hood doing a ton of complicated tradeoffs and tricks to try and get the same sprites to render on Metal, Vulkan, OpenGL, and DirectX.

I tend to avoid over-abstraction when I can, but I still have to ask -- it a problem that those abstractions are complicated under the hood if they work for the developers that use them? Pipewire is pretty complicated under the hood to maintain compatibility with multiple setups; does that mean we can't have a universal audio interface for Linux and every device should be programming separately for ALSA and PulseAudio?

[taeric]

Fair that I don't think "what it compiles to" should be near as important as I was holding it.

CSS, though, did have a goal at the start to be a lot more approachable than what we have, though. User stylesheets were a huge selling point in early pitches that I recall. That is flat not possible with how we have things nowadays.

And I also think it would be fair to lay a lot of the blame on just how many divs so many designs explode things into.

[danShumway]

I mean... I do agree with this:

> And I also think it would be fair to lay a lot of the blame on just how many divs so many designs explode things into.

That could be a longer conversation but what I try to get across to designers is that the DOM is your interface, the DOM is not the tool you use to build your interface, the DOM should be a user-facing representation of application state, and incidentally you can also represent that visually.

So agreed, I hate it when I open dev tools and I just some completely incomprehensible mountain of divs.

That being said:

> That is flat not possible with how we have things nowadays.

I do this. I maintain custom stylesheets for websites I visit, it's very possible. It's one of the things I love about the web, I love that I can have website-specific stylesheets in Firefox without even installing an addon. I've set up hacks when I was trying to use the browser less to do grayscale effects across websites I didn't want to visit. It was a tiny amount of code and it mostly just worked, and I really couldn't do something equivalent with other platforms.

And OK, sure, maybe that's just me and it's unfair for me to say it's easy. I work with CSS a lot, I am generally proficient at it. So that's maybe a bad standard for me to have -- what about the people who don't want to work with CSS a ton until they understand it?

Well... do they use uBlock Origin? There are a host of browser extensions that modify stylesheets on the fly to do complicated things that help make the web better. uBlock Origin would be a lot worse without CSS. And there's an on-ramp for that kind of thing too, HN has honestly a pretty bad user-interface as far as the DOM is concerned. But I have a number of one-line filters in uBlock that are basically just CSS rules that help make the website better.

It's not perfect and it should be better, but I'm left looking at the alternatives again -- no other platform gives me as much control over 3rd-party user interfaces as the web. And for the most part it just works, websites like Facebook are the exception and very often, particularly for indie websites, I can open up the DOM and mess with things and fix problems.

It's a problem that it's not more accessible and I am not shaming anyone who struggles with it, but I don't think it's impossible. It's a normal thing for me to do. Maybe I'm biased on that, but I think it's very feasible for especially programmers to learn to override 3rd-party interfaces on the web.

My main critique of the web is that there should be more abstractions for non-programmers and UI designers to work with that doesn't require them to drop into a programming language when overriding things. Reader Mode for Firefox is a step in the right direction, although it could be a lot better. The browser controls for font sizes are good. There's a lot further that browsers could go to improve that situation.

[auggierose]

> Where was I proven wrong? Does that example compile down to something that isn't several dozen nested divs using react?

Why do you care about what it compiles down to? What does that have to do with anything?

As I said, your proof is here, it's just that you refuse to accept it.

[taeric]

As I said in the other response, I think it is fair to say I shouldn't care about what it compiles down to. That complaint is largely in pursuit of user stylesheets, where you basically do have to know the structure of the things in order to be able to adjust stuff.

I'm still skeptical, but largely on the difficulties I see frontend teams having. And despite the other poster saying they have great success with pages working on all of their devices, I daily have pages that don't. And I don't exactly visit a ton of pages. With some of these from large companies like Amazon and Google, I find it hard to believe that this is truly a solved problem. (Visiting smaller shop websites is basically guaranteed to not work on both my phone and on my monitor. Such that I don't think it is just a "big company" problem.)

[auggierose]

Basically, at least everybody using Tailwind is doing it wrong, because they are throwing out their biggest weapon: abstraction. So that could account for the failure in the real world you see. I think there are many users of Tailwind out there.

I am also not a big fan of many of the React libraries I am seeing out there. In case of my desktop app, I am more comfortable rolling everything on my own on top of browser APIs + React.

[danShumway]

> For me, what they lack is evidence that stands any stronger than video games. Specifically, I've played different games on various screen sizes and orientations that largely work as you would expect. They are not perfect, of course, but they work better than most web pages seem to. And they do that, largely, without the same reliance on something like CSS that web pages need.

Video game interfaces are a ton of work, and porting between different control schemes and devices is a ton of work and that's why a lot of games don't do it. Look at the work required to handle devices like the Steam deck and the amount of work Valve has put into trying to make mouse-controlled games usable on the device. It's not easy, it's significantly more work than building for the web.

Of course it's helped by the fact that Valve does have general abstracted concepts of input that games can hook into that are shared between different controllers. Modern games don't do input per-controller, they use abstraction libraries like SDL that are designed to allow them handle a lot of different input schemes with a single codebase. And even that is a crapshoot, if you're playing indie titles on a PC you are going to be rolling the dice on whether Xbox controllers and Dualshock controllers are supported or whether only one of them works. I like that when I use the web, even weird keyboards still type into webpages. We still don't have a standardized way to do controller rebindings in games -- Valve's Steam Input works by emulating a second controller for games that aren't using Valve input APIs and pretending to press the buttons the game expects to see.

So even with all of the advantages of cross-platform frameworks, the games industry still doesn't have a great track record for building games across devices. You're pointing out that there exist games that do build separate interfaces for different devices. Sure. And agreed, when devs put in the extra work, you can have great results that are far better than the average website.

The difference is that basically every website works on my phone. Games aren't even close to that level of compatibility and most teams don't have the resources or time to put in the work to support every device and control scheme. The world of games is exactly what we don't want on the web, because if having a website interface for mobile and for desktop means that everyone needs to design and program two separate interfaces using two separate languages, we will have about the same number of websites on both mobile and desktop as we have games on both mobile and desktop -- ie, very, very few of them.

It's a blessing for compatibility that engines like Unity and Godot allow targeting multiple platforms and form-factors with a single codebase. I wish I had to work less to get that same level of abstraction in my video game interfaces.

And all of this is before we even get into all of the other problems of game interfaces -- the all-too-common lack of ability to do anything with text sizes, the lack of accessibility controls, the inability to resize windows in or out of games. My goodness do I not want my web pages to act like video games, that would be a miserable experience. It's not uncommon for me to see video games that literally won't allow changing resolutions without restarting the game. Imagine if your browser forced you to close and re-open the webpage in order to resize your window.

----

> It feels very appealing to think you can build a system that would solve "laying out text" for all time.

We have not built a system that can solve laying out text for all time. That system doesn't exist and can't be built, it is impossible. That's exactly what we're saying: we are trying to build a system that does the best possible job of universally solving that problem, but it's incredibly difficult and necessarily results in complexity and tradeoffs.

But the only belief more naive than thinking we can have one universal layout system for everything is the belief that we don't need a universal layout system and that it's possible to reduce user needs into a finite list of use-cases that can be individually supported. That reduction isn't possible, the use-cases for end users are arbitrarily large and constantly growing and it is not possible for anyone to sit down and build a single list of formats that need to be supported on the web. That's just fantasy, people are too diverse.

I use both a 1920x1080 monitor and a 3840x2160 touchscreen monitor hooked up to the same computer. Every single website I visit handles both, fluidly, when switching windows between them. A lot of games have no idea what to do and a nontrivial number of native apps struggle with it as well. But the web works, and then people show up like, "well, I shouldn't need support that." Well, I'm glad you're forced to use CSS then because I know what the web would look like if you weren't forced to.

[taeric]

Yes, getting an interface to work is a ton of work. If you felt that I was claiming there are easier ways that are not a lot of work, my apologies. I did not intend it that way.

My point would be more that the work Valve has put into the Deck has enabled far more than the work the standards committees have done with CSS. You can correctly argue these are solving different problems. But my assertion is that I have seen more impressive content layout and interactions from the Steam Deck than I have really with the web. I'm curious what you'd offer as the reasoning there?

You seem to be taking it that the games industry isn't very cross device focused. But, that is missing that current gen games are usually at the absolute bleeding edge of what the absolute best devices are even capable of. It is not at all surprising that those do not work cross device that well.

You are, of course, correct that there are some generic engines that allow better cross device development now than have existed in the past. Do any of them use something like CSS for laying out a menu screen? If not, why not? How about the inventory or character creation screens of games? Would you think those should be designed in the same way that something like a character builder webpage would use?

I also have large monitors, and it is ridiculously amusing how many websites do not work well when I have my windows tiling. My favorite is just two windows side by side on the main monitor, but parts of the menu of many sites will not load due to confusion over what my window width should be. To my absolute annoyance, I have found this will often not be consistent between browsers.

Now, is it fair that "bugs mean the entire thing is nonsense?" No. And I do apologize that I can see how my post read that way. Realistically, the amount of manpower that has gone into CSS has landed on something that is quite capable. But we gave up on "user stylesheets" ages ago. And the cascading nature of how things interact is almost certainly not well understood by a large portion of the practitioners. My annoyance is far less on what is capable with CSS nowadays, and much more annoyed at the rube goldberg machine that is how the vast majority of websites are layed out.

[danShumway]

> My point would be more that the work Valve has put into the Deck has enabled far more than the work the standards committees have done with CSS.

Citation very, very much needed. Valve's work on Steam Input absolutely pales in comparison to the web. The number of supported games is minuscule. If the Steam Deck is our standard for cross-compatibility on the web, that's just really low standards. That's not the world I want to live in, CSS is better.

> But, that is missing that current gen games are usually at the absolute bleeding edge of what the absolute best devices are even capable of. It is not at all surprising that those do not work cross device that well.

No, the opposite. I'm talking about indie titles and AA titles and the average games put out by normal studios. Ironically, the giant AAA studios often have much better accessibility controls and cross-platform support. If you buy a AAA game, you're much more likely to have access to something like text scaling or dyslexic-friendly fonts or multiple input schemes, because those studios have the resources to care more about diverse use-cases, those studios have the money and developers to ask questions like "what happens if the user's TV is far away from them?"

Indie studios don't. And the fact that there's a divide between indie and AAA games on something as basic as resizing text, something that is supported on every single website -- that should be enough to show you that this "individually supported device" concept is just not workable in the real world. The games industry can't even get universal text scaling and you think that's a success story?

> But we gave up on "user stylesheets" ages ago. And the cascading nature of how things interact is almost certainly not well understood by a large portion of the practitioners

Sure, training is difficult and the web is counterintuitive to UI designers that are used to working in Photoshop, but I would still maintain that I have far fewer interface problems on the web than I do on native devices and in games, and that's not even taking into account that I see websites put up by far worse developers and far smaller teams with far smaller budgets than any of the native apps on my computer or phone.

We're never going to be perfect at this. One issue is that ironically many UI problems on the web when you dig into them often end up being due to concessions to developers on device-specific breakpoints. The web allows you to decide that you aren't going to care about being responsive and to act like you're building a video game that will only ever be displayed full-screen. If you really want to, you can design your interfaces like you're an indie developer using Unity and you can absolute position all of your divs. And there are problems with having those escape hatches, but the concessions are important because this is an unsolveable problem and sometimes devs need those escape hatches. So we add even more complexity onto an unsolveable problem to help cover use-cases that we can't cover any other way.

But solveable or not, complex or not, ignoring the problem is not the solution.

And it still is just very clearly the case to me that if we're looking at what platform does responsive design the best and which platform has the best compatibility stats between multiple devices, the web is going to win every single comparison with every other platform. It's not even close.

Yeah, things could be better, and yeah, CSS has problems, but the alternatives are just so, so much worse for actual end-users. Getting the vast majority of content on a platform to work across every single device from voice assistants to desktops to tablets to phones to VR is an achievement that no other platform can point to. And CSS does that without requiring you to have a AAA game budget when you build a website.

[taeric]

The number of supported games on Valve is minuscule? We clearly play different games. :) (In seriousness, sucks that you are having bad experiences there. Good luck on that changing!)

That said, you seem to be taking the strongest version of my claim here. I don't think they have solved things any more than anyone else. And I fully grant that video games are largely not accessible.

My argument would lean more into the way that photoshop and other visual tools had done things. If you want to visually layout something, using visual tools is almost certainly the correct answer. Back in the day, you would start with grid paper and literally draft out what you wanted. From there, you would have a relative coordinate system that you would then code against.

CSS and a ton of developer created things almost always focus on symbolic ideas. And it turns out jumping straight to the symbolic gets you into a ton of naming and aliasing issues ridiculously quickly. That and general purpose cascading of rules is just not that useful for the vast majority of things that we do. Is why design tools such as Figma let you put the properties directly on what you are designing. It is how people design.

And, again, I /agree/ that CSS is workable how it is today. There has been a ton of manpower put into it. But I don't know that we are comparing apples to apples in alternatives. Someone mentioned turbo pascal earlier and the form builders they had. People were doing better designs with dream weaver than I typically see online today. We didn't like it because it made the documents basically unreadable. But, we left that goal behind years ago, and missed out on the design tool that we had at hand.

[danShumway]

> (In seriousness, sucks that you are having bad experiences there. Good luck on that changing!)

To be clear, I'm not having bad experiences on the Steam Deck, it's a fantastic device. Highly recommend it, I feel like Valve built a computer specifically for me. :) But compared to the web, it's minuscule. Compared to the web, the number of games on Steam in general is minuscule. The web is so big. Nothing that Valve is doing compares to the size and scope of what the web supports.

And in terms of support, the percentages of games that are playable across all of these devices out of the total number of games that Steam has is much lower. Again, doesn't mean that Valve isn't doing great work, but if Valve went into overdrive tomorrow and got 80% of the games on Steam working on the Steam Deck -- the web does better than that.

It would be great, I'd be very happy about it, I'd have a ton of games to play. But the web just so thoroughly outclasses that, there is no platform success story that comes close to the compatibility that the web has, and this is even with the web being a far bigger platform with a wider range of content than basically any computing platform I can think of.

It's not so much that everyone else is terrible, it's that the web is so wildly successful at getting apps to be cross-device compatible that you basically need to hit 95-99% to start comparing to it. Valve is nowhere close to hitting those kinds of numbers, even with Steam which is (as big as it is) minuscule compared to the amount of content on the web.

Valve's approach and the approach of games on Steam just wouldn't scale to the size of something as big as the web, a platform where anyone can publish anything without going through a Greenlight process or doing compatibility checks for every device.

----

> My argument would lean more into the way that photoshop and other visual tools had done things. If you want to visually layout something, using visual tools is almost certainly the correct answer. Back in the day, you would start with grid paper and literally draft out what you wanted.

Right, but I think that's just been proven to not work if you want to get a lot of people (including low-code developers and content-producers) on the scale of the web to design interfaces for multiple devices. I would argue that as inconvenient as they are, symbolic ideas are just the only way to do it.

Note that CSS allows you to do multiple interfaces depending on the device/resolution/etc... but what's important about CSS is that it doesn't allow to ignore the symbolic part, because (opinion me) the symbolic part is just part of designing interfaces.

Even forgetting about the multi-device support (which I think any platform that focuses on pure visual layout with fixed resolutions will when examined turn out to have worse multi-device support and smaller numbers of multi-device apps than the web has) -- but ignoring that, I will also argue that if you can't think symbolically about your interface and you can't lay it out as a pure-text hierarchical interface, you can't really effectively build accessible apps. One of the other reasons why I think Photoshop is kind of a bad tool for building interfaces is that I see UI developers jump into it and design interfaces based purely on "I want this to show up on this pixel" and they're not thinking about grouping, they don't have constraints to force their interfaces to be more consistent, they're not thinking about what's going to happen when the app gets translated into multiple languages, they're not thinking about screenreader support or keyboard controls.

Genuinely, I believe that forcing yourself to design interfaces in text before you sit down and look at the visuals makes you a better UI designer, because UI design cares about affordances and grouping and concepts that are being translated to the user. And without being too harsh on designers that are used to those visual tools, I can tell the difference between a designer that works in Figma and a designer that works in Photoshop because one of them will hand me a design that still works if I change the font size, and one of them will give me a blank look and not know how to react if I ask them whether we can change the font size.

I don't want to be harsh about it or put people down or be extreme, but like... I keep coming back to, I know it would be nice if we could just lay out everything visually in Photoshop. It would be great, it would make UI design so much easier. But UI design is all the difficult stuff, it's not hard to lay out things out in Photoshop, it's hard to design UIs that work in the real world. And sometimes the complaint about "why do I have to think symbolically" feels like a traffic designer saying "why do I need to worry about rush hour why doesn't everyone just drive uniformly like they do in my simulations." I'm sorry, but they don't. They do weird things and run red lights and clog intersections, and we pay UI designers to be able to handle the messy details of the real world.

> Is why design tools such as Figma let you put the properties directly on what you are designing. It is how people design.

I'll push back on this a bit; one of the strengths of Figma is that it pushes UI designers (gently, but still pushes them) in a symbolic direction. Sure, not everyone needs to sit down and write CSS by hand. Not everyone needs to learn Javascript, they can use template libraries. Not everyone needs to learn how to design websites, they can use Wordpress. There's no shame at all in building tools on top of things to make them more accessible, that's part of the web's DNA.

But Figma is CSS from the start. The CSS might not be in your face, but Figma is designed to force designers to care more about responsive design. It just has low-code options, the same as Unity of RPG Maker does for game design. But it's still thinking symbolically and logically about interfaces and not just thinking about pixels.

[wruza]

All that said, there’s still no way to just make a layout and it be compatible with all screens. You still have to do mobile, tablet, pc modes. (And there’s enough sites that are pc-only or mobile-only.) You still have to make 2-3 layouts, but in one source. Well, what’s the argument against gp’s point again? Sorry, but this statusquoism and rationales that essentially change nothing drive me mad sometimes.

[danShumway]

The web and CSS make it reasonably feasible to support most of those layouts well with at most 2-3 layouts in one source.

My point is that it is impossible to get the same level of results doing fully device-specific and domain-specific languages without considerably more work -- more work than would ever be undertaken by the majority of people building for the web today. If you want an indie web, if you want websites that aren't just built by corporations and professional development teams, HTML and CSS is what enables those indie websites to exist and to work across every device you own.

The proposal of using interface-specific languages and abstractions wouldn't work. Doesn't work, in fact, when you look the places where it's being attempted as a UI strategy.

Like democracy, universal design abstractions such as CSS are the worst way to design interfaces that work in the real world for real users across diverse devices and configurations -- except for every other way. If we asked devs to actually use separate domain languages for mobile devices and desktop devices, the web would be a lot smaller and a lot more limited and a lot less flexible and a lot worse for end users.

[wruza]

I don’t think our common ancestor in this subthread suggested separate languages for different screen sizes. Did they?

[danShumway]

> The problem with css is almost entirely self inflicted, though. Yes, layout is hard. Why make it harder by aiming for the model we now have? Specifically, why aim for one major model that will fit all pages?

It's possible I interpreted that incorrectly? But if their problem is just making different layouts then I don't see what the issue is. CSS has breakpoints. You can already make different layouts for different screen sizes. You're not required to have one set of rules that apply to every page size.

The only criticism that makes sense to me as a reading is that they don't want a common set of UI paradigms and language features that allow targeting multiple devices and they want a more specific language targeted at describing a subset of those interfaces -- because that's what CSS is. That's the only thing that CSS is, it's just a universal rules-based language.

You can design different layouts for different page sizes, you can even on the serverside serve entirely separate HTML pages for mobile and desktop devices. The only issue I can think of left to complain about with CSS being too general is that CSS is a common language designed to be used in all of those situations instead of in only one of them.

Did they mean that they wanted CSS to have separate terminology and paradigms and ways to tackle those problems built into the language? It does! And that's exactly what people complain about, that's exactly where the "why are their 5 ways to do this" complaints come from, they come from CSS having lots of different ways to achieve the same effects based on the individual unique needs of the specific interface being created. What's the alternative, have one way of doing everything for every interface? The original commenter I was replying to said that they didn't want that.

They want multiple models for different formats, and CSS has that and lets you use them and target as many interfaces as you want, and there are ways to detect and serve different CSS and HTML based on device agents, and so... I don't know, if they don't want different languages, then what is the complaint?

[taeric]

I wasn't necessarily proposing separate languages. I don't see the benefit in having a single source, though. The vast majority of designs do not need to have every single element recalculated at the client.

To that end, I confess I would encourage leaning more heavily into absolute positioning of elements than most places go with. Is what I did for stuff such as https://taeric.github.io/cube-permutations-1.html, and seems to work just fine. I remember I did something similar on the job once, and the next developer came in and was against the idea of using absolute positioning. The rewrite did not go well. :(

My push is the "model" for what a page is showing should be dominated by concerns of what the page is showing. It should, ideally, not be too heavily influenced by how you want to write the styling for it. We rebelled against using tables for styling years ago. Nowadays, we shrug at the number of divs necessary.

[danShumway]

So, I would push back against this as a design pattern, but I do want to re-emphasize, if you really want to absolute-position all of your divs, and if you want to serve even completely separate HTML for different devices -- you can.

That is a thing that CSS allows. Flexbox, responsive design -- it's all optional. There is going to be a sense when you use CSS that way that you are swimming against the grain, and that's on purpose because it's important that the instinctive default way that new designers think about the web is in those responsive terms. But even if the web pushes you in that direction a bit, it's not a requirement -- you can still design interfaces the way you're talking about, and you can heavily use breakpoints and you can have different layouts depending on the situation.

One thing that I see websites do fairly often (which I don't think is great practice but I'm throwing it out as a common practice and I understand why people do it) is literally have two versions of their menus for mobile and desktop in the same interface in the same DOM tree and just throw a "display: none" on one of them depending on the width of the screen.

So it's not even necessarily that you have to serve different HTML, you can have different versions of components even on a completely static website with no JS that swap out seamlessly depending on the user's device size.

[sfn42]

You can just make one layout that works totally fine on all screens. Problem is you're basically just making a mobile layout and scaling it up so it'll be shit on larger screens

[danShumway]

Heavy, heavy disagree. Tiny example, but just because it's on my mind that I need to rewrite it soon: https://danshumway.com/resume.

This is almost per-pixel identical to the resume layout that I used to have laid out in a normal editor exclusively for PDF and print, but without making a single concession with my normal print layout, it also seamlessly collapses into single columns perfectly fine on mobile devices, doesn't require Javascript, and the entire layout is ~160 lines of CSS.

And to be clear, this is bad CSS. This is not CSS I'm proud of, this is CSS I wrote ages ago that I'm going to be tackling very differently whenever I get around to rewriting the resume. But it's still perfectly reasonable to have document layouts that feel like normal print layouts that collapse down well on mobile devices.

And sure, this is a trivial example, but I think the same principles scale up. I don't believe that applications are different. Most application UIs can be represented as trees, and trees are well-suited for multiple-column layouts and collapsing rules based on width. That many sites work on mobile and don't scale up is a result of developers designing primarily for small screens and not thinking about large screens at all.

Even here, this resume should handle wider screens better, it doesn't take enough advantage of available width. But the other thing about the web compared to native is that with native toolkits if a developer designs for mobile and then doesn't think about desktop, the app just doesn't work on desktop at all and you can't use it.

On the web, if a developer designs for mobile and doesn't think about desktop, at least the interface is still usable on desktop. And vice-versa: there are desktop interfaces on the web that are miserable on mobile devices. But they work. None of the alternatives that people are proposing have that advantage.

[sfn42]

I don't really see how this disagrees with me at all. Yeah, you can make a layout what "works" on all sizes, I said that. For something trivial it can even be great on all sizes.

But a more complex website like let's say amazon.com is much better with thought-out styling for different widths.

[danShumway]

> is much better with thought-out styling for different widths.

When people talk about responsive design, we don't mean that you shouldn't be thinking about styling for different widths. We mean that what you come up with is a singular design that responds to changes in screen size and font size, whether that's using breakpoints, wrapping, hiding and showing elements, or a combination of all of these things -- as opposed to building a completely separate interface that the user can only access through a separate URL or application (if it's even available on their device in the first place).

Yeah, you'll get bad interfaces if you only think about one screen size, but responsive design is explicitly about not only thinking about one screen size.

Amazon is maybe a bad example here; their site doesn't implement great responsive design as far as I can tell. Scale down a window too far on Desktop and the site just throws a horizontal scrollbar at you. This is despite the fact that Amazon absolutely could collapse down into a single-column view. I disagree that Amazon's interface is so complicated that it needs a full browser width, it's a vertical list of horizontally floating elements, it's a great candidate for wrapping listings and for collapsing down the menus based on a breakpoint.

But I'm left sort of feeling like we're talking past each other. I agree that you should think about multiple sizes. I don't see what that has to do with whether or not CSS is well-suited for building interfaces, I would argue that CSS makes it easier to think about multiple screen sizes when building interfaces. I think that's CSS's strength as opposed to static layout tools that lack the expressiveness to describe what you want to happen when a column gets too narrow or to set things like margins based on text size instead of pixels or on and on. Those tools are all really useful when building interfaces that actually adapt to different settings/resolutions.

[sfn42]

I agree that we're talking past each other. I completely agree with everything you've said here.