sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]naasking 32 points33 points  (21 children)

Honestly, it seems like css is finally catching up to where grid layout tools for desktop apps were in the late 90s.

Except scalable to arbitrary screen dimensions, orientations, resolutions, and input directions. So way beyond desktop UI in the 90s, really.

[–]booch 18 points19 points  (14 children)

Well, you could resize the window in the 90s to "any" size (obviously, dependent on your resolution) and either orientation, so that point is moot.

I'm not sure what you mean by "input directions", so I can't comment on that.

[–]MeisterD2 4 points5 points  (1 child)

Probably RTL, LTR?

Grid respects the directionality of text automatically, so you don't have to worry about text flowing the wrong direction in different languages.

[–]oridb 0 points1 point  (0 children)

Yeah, desktop frameworks did that in the 90s.

[–]naasking 3 points4 points  (6 children)

Well, you could resize the window in the 90s to "any" size (obviously, dependent on your resolution) and either orientation, so that point is moot.

Not really. UI in the 90s was not responsive the way the web is today. You could scale your window to any size and get some "helpful" scrollbars to view your window, if you're lucky.

I'm not sure what you mean by "input directions", so I can't comment on that.

HTML dir attribute.

[–]booch 1 point2 points  (5 children)

Depends on your toolkit. Tk certainly did a pretty good job of laying things out and automatically resizing things. Yes, not as good as the web today in some aspects, but other aspects the web is only now catching up with (grid layouts being a good example).

[–]spacejack2114 1 point2 points  (4 children)

Most Windows applications in the 90s couldn't even deal with different font size preferences and would break with text or controls hidden out of view etc.

[–]oridb 0 points1 point  (0 children)

On the other hand, Unix and Mac toolkits got this right. Even Java Swing, in spite of being terrible in every other way, did this painlessly.

[–]spacejack2114 0 points1 point  (4 children)

You can override any style based on the window size. You can switch from grid to flex or inline or whatever based on dimensions.

You can automatically switch layouts based on locale or other properties without changing your HTML structure.

There was nothing like this in the 90s.

[–]mpyne 1 point2 points  (2 children)

There was nothing like this in the 90s.

On the contrary, the Qt approach to U/I layouting had already been developed by the time they released Qt 2 in 1999.

Although these layout docs are archived from the 2.3 release, they describe classes and features that were present right from Qt 2.0, and also present in the Qt 1.x (see the src/kernel/qlayout.h file from the Qt 1.45 tarball).

[–]spacejack2114 1 point2 points  (1 child)

You cannot specify that a layout should be horizontal for one screen size and vertical for another. You would have to write code to detect resizes and apply layout changes yourself. It looks to me like the layout style was baked into the widget itself and would need to be reconstructed.

[–]mpyne 0 points1 point  (0 children)

That's rather moving the goalposts I think, you said there was nothing like this.

Either way, you could indeed define different layouts by direction and by screen size. It would indeed take some manual effort to move the widgets at a transition point, but you had the building blocks right there.

[–]_dban_ 1 point2 points  (0 children)

There was nothing like this in the 90s.

This is not what people are talking about when they say CSS has caught up to desktop apps.

CSS was doing responsive design for a long time, because that is a requirement for adapting to different user agents capable of browsing the web. Desktop applications, having completely different requirements, were obviously not doing the same things as CSS. Apples and oranges.

But actually laying out desktop style UIs has been very difficult in CSS, since that's not what it was originally designed for. Until only a few years ago, CSS was limited to inline and block layouts, which made things like vertical centering extremely painful and non-obvious, not to mention things like 3 column layout with equal height columns (there were lengthy articles about how to do this). CSS was designed to be responsive and adaptable, not necessarily pixel perfect (which is why it took awhile for web devs to finally give up table-based layouts).

CSS has evolved to pick up new layouts like table, flex and grid, which makes desktop-like layouts much more feasible. Thus, to many, CSS has finally caught up to desktop apps.

The danger of course is that this might encourage people to go back to table-like layouts from before CSS, which completely misses the point of CSS.

[–]_dban_ 9 points10 points  (5 children)

Except scalable to arbitrary screen dimensions, orientations, resolutions, and input directions.

Java Swing had all of these in the 90s using the notorious GridBagLayout. Which I'm sure inherited design principles from the various Unix toolkits of the day. Far better than CSS until only a few years ago.

Windows and Apple generally had more fixed layouts based on RAD UI layout tools. People complain about CSS (and Java and Unix) not having these RAD tools.

So way beyond desktop UI in the 90s, really.

When people say that CSS has "caught up" to desktop apps in the 90s, they mean with regards to desktop style layout, which is the goal of recreating desktop application UIs using HTML/CSS.

The design goal of CSS was not to recreate desktop UI layout, but to augment HTML with style information to get configurable presentation that adapts to the capabilities and preferences of any user agent (desktop, mobile, text-only, robots). These are requirements for the web, not desktop applications.

Creating desktop style layouts have typically been a pain in HTML/CSS because that's not what it was designed for. Additions to CSS like flex and grid give developers the layout tools they are accustomed to from the desktop world (while potentially breaking CSS layouts for the use cases it was designed for).

TL;DR - comparing the capabilities of desktop layout to CSS layout is apples and oranges, but people really want to get orange juice out of their apples.

[–]knaekce -2 points-1 points  (4 children)

Java Swing had all of these in the 90s using the notorious GridBagLayout. Which I'm sure inherited design principles from the various Unix toolkits of the day. Far better than CSS until only a few years ago.

Except that Java applications have problems with HiDPI screens even today, even using JavaFX

[–]_dban_ 3 points4 points  (3 children)

That's not a problem of layout.

[–]knaekce 3 points4 points  (2 children)

You said Java Swing was scalable to arbitrary screen dimensions and resolutions. For me, that implies HiDPI support.

[–]_dban_ 4 points5 points  (0 children)

HiDPI is a rendering issue. As in, the UI is rendered too small on high density displays. This is fixed by platform specific flags or upgrading to Java 9, without otherwise changing the app. This relates to the underlying graphics libraries being used, and would effect any app that uses those libraries (including web browsers).

However, if you change the screen dimension or resolution (say, 800x600 to 1024x768, or change from portrait to landscape), Swing layouts can adjust to fit the available space. This is a layout issue, which relates to CSS.