> Résolution was taken into account in games, to compute a scaling factor, maybe add some screen bars, and that was nearly all - fundamentally, because hardly any program was going to be used in a small, top to bottom screen at all.
Are you comparing applications or games? Because games don't have a fluid layout anyway[1], whether HTML5 or native application.
> So html was just the first one to have to do it pervasively because of desktop + mobile web browsing of the same source - but it could have happened before.
No. All the GUI toolkits I have used to produce native GUI applications since at least 1998 had support for ensuring that elements were still accessible after resizing[2]. Even in 1998, Delphi's "anchor" worked better than anything in HTML today.
HTML was the last GUI development system to get this sort of thing.
[1] You can choose one of a dozen preset WIDTHxHEIGHT resolutions. You couldn't narrow the window and still expect to see all the game elements.
[2] I don't remember many native GUI applications that were broken when you halved the width, or halved the height.
Hmmm, HTML has had layout behaviour that works at all viewports since its inception -- it's just that web developers have often implemented markup that that is inflexible. Just as you could make static/inflexible layout in any of the tools you mentioned, so could you do so with HTML. The regular flow of content on a web page has always been basically equivalent to "word wrap" (I don't know the proper term if there is one). The only noteworthy feature specifically regarding viewport resizing for web pages is "media queries" which wasn't necessary for ensuring a flexible layout.
It was always technically possible to have a flexible layout, it just didn't become popular/"standard" until around when mobile started being a popular medium via which to view that content. The prevalence "best viewed at 1024x768 or higher" was just a symptom of inflexible design & implementation, not an actual technical limitation of HTML.
P.S. I will definitely agree that laying out content in HTML has always been awkward, tedious, and inconsistent across browsers, hahah :)
Do you remember a popular QT app that would turn a row of elements into a column of elements when shrinking a window, though ?
Was it also common to make sure your Qt app was working fine on the small portrait resolution of the mobile computers that were going to be invented any decade now ?
Flex is a layout system (a fairly good one, that I wish had existed on the web since the start. Rows, columns, wrap. Good.)
; responsive is a design considération (what do I as a human being decide should be visible when the screen is just too small to show everything.)
My claim is that "responsive" as a design issue is deeply linked to mobile computers, so it's not a surprise that it was not a big conxern before.
Are you comparing applications or games? Because games don't have a fluid layout anyway[1], whether HTML5 or native application.
> So html was just the first one to have to do it pervasively because of desktop + mobile web browsing of the same source - but it could have happened before.
No. All the GUI toolkits I have used to produce native GUI applications since at least 1998 had support for ensuring that elements were still accessible after resizing[2]. Even in 1998, Delphi's "anchor" worked better than anything in HTML today.
HTML was the last GUI development system to get this sort of thing.
[1] You can choose one of a dozen preset WIDTHxHEIGHT resolutions. You couldn't narrow the window and still expect to see all the game elements.
[2] I don't remember many native GUI applications that were broken when you halved the width, or halved the height.