Newest at the top
| 2024-10-01 11:22:12 +0200 | gmg | (~user@user/gehmehgeh) (Quit: Leaving) |
| 2024-10-01 11:21:49 +0200 | <tomsmeding> | "responsiveness" is a term from web development |
| 2024-10-01 11:21:42 +0200 | <tomsmeding> | that sounds like something broader than just layout adaptation |
| 2024-10-01 11:21:26 +0200 | <eugenrh> | Quote: "Convergence can also refer to being able to run the same app across different devices and being able to develop apps for different devices (such as smartphones, TVs and desktop computers) at once, with the same code base." https://en.wikipedia.org/wiki/Technological_convergence |
| 2024-10-01 11:21:08 +0200 | <eugenrh> | thirdofmay18081814goya, for what you mean by responsiveness, I've seen in use the term 'convergence'. |
| 2024-10-01 11:20:35 +0200 | <tomsmeding> | (and hence I wouldn't be annoyed about it) |
| 2024-10-01 11:20:25 +0200 | <tomsmeding> | I guess with typographical restrictions like that it makes much more sense to do this |
| 2024-10-01 11:20:12 +0200 | <tomsmeding> | probably other people find that even more unsightly |
| 2024-10-01 11:20:00 +0200 | <tomsmeding> | no underlining available? |
| 2024-10-01 11:19:07 +0200 | <geekosaur> | (physical lead type; phototypesetting wasn't a thing) |
| 2024-10-01 11:18:51 +0200 | <geekosaur> | books didn't have many other options back then |
| 2024-10-01 11:03:39 +0200 | vglfr | (~vglfr@2601:14d:4701:3b30:c3ef:3b3e:5ca1:502f) (Ping timeout: 276 seconds) |
| 2024-10-01 10:59:12 +0200 | <tomsmeding> | (to be honest I always find it somewhat unsightly to see upright text within italics as meaning emphasis, but that's perhaps just me) |
| 2024-10-01 10:58:11 +0200 | <tomsmeding> | I just know that TeX does this |
| 2024-10-01 10:57:56 +0200 | <tomsmeding> | I have seen emphasis-within-italics few enough times in my life that I cannot judge that :p |
| 2024-10-01 10:57:35 +0200 | <geekosaur> | which has been the convention in books for over a century |
| 2024-10-01 10:57:32 +0200 | <haskellbridge> | <thirdofmay18081814goya> that's a great example ty will be thinking about it |
| 2024-10-01 10:57:15 +0200 | <tomsmeding> | not sure if you'd have something like this in layouting, but I wouldn't be surprised if you do |
| 2024-10-01 10:56:38 +0200 | <tomsmeding> | "emphasis within italics is upright text" |
| 2024-10-01 10:56:30 +0200 | <tomsmeding> | in TeX, the italics command makes its argument, well, in italics font; the emphasis command does the same thing (output is indistinguishable), but _nesting_ emphasis commands makes the inner text upright again |
| 2024-10-01 10:55:53 +0200 | <tomsmeding> | a classical example, though about text formatting and not about layout, is emphasis vs italics |
| 2024-10-01 10:55:20 +0200 | <tomsmeding> | it just feels like an unnecessary restriction on the layouting process |
| 2024-10-01 10:55:12 +0200 | <tomsmeding> | not sure! |
| 2024-10-01 10:55:06 +0200 | <haskellbridge> | <thirdofmay18081814goya> tomsmeding: hm an interested in this, would you have a short example? |
| 2024-10-01 10:55:02 +0200 | misterfish | (~misterfis@094190207253.static.ipv4.heldenvannu.net) misterfish |
| 2024-10-01 10:54:29 +0200 | <tomsmeding> | is it not possible for multiple "content trees" to result in the same layouts? |
| 2024-10-01 10:54:18 +0200 | <tomsmeding> | is that reverse a function at all? |
| 2024-10-01 10:53:35 +0200 | <haskellbridge> | <thirdofmay18081814goya> oooooo if we reverse the direction we get a function that's surjective but not injective and the immutable tree can be thought of as some sort semantics |
| 2024-10-01 10:53:31 +0200 | ljdarj | (~Thunderbi@user/ljdarj) (Quit: ljdarj) |
| 2024-10-01 10:39:15 +0200 | <tomsmeding> | sounds reasonable |
| 2024-10-01 10:39:09 +0200 | <haskellbridge> | <thirdofmay18081814goya> i don't know, maybe these domains are also trees? |
| 2024-10-01 10:38:54 +0200 | <haskellbridge> | <thirdofmay18081814goya> maybe then responsiveness could appear as some sort of map from this order-of-appearance tree to something else? e.g. if an application has three possible layout readjustments, responsiveness could be modeled as a map from the order-of-appearance tree in one of three domains, and each of these domains internally model continuous deformations on the GUI within a certain threshold? |
| 2024-10-01 10:35:07 +0200 | <tomsmeding> | but then that solution is not necessarily very specific to "responsiveness" :) |
| 2024-10-01 10:34:24 +0200 | <tomsmeding> | if you sufficiently abstract the content from the presentation, and allow writing a bespoke renderer, then sure you can do this |
| 2024-10-01 10:33:52 +0200 | <haskellbridge> | <thirdofmay18081814goya> can we not think first of some sort of tree which models, not layout, but order of appearance to a user? this is then is an immutable tree which could capture the core, non-responsive aspect of the application |
| 2024-10-01 10:33:46 +0200 | <tomsmeding> | s/websites/UIs/ |
| 2024-10-01 10:32:34 +0200 | <tomsmeding> | for simple websites, heuristics based on rearranging the tree may work well, but if you have precise requirements then that may not cut it |
| 2024-10-01 10:32:03 +0200 | machinedgod | (~machinedg@d50-99-47-73.abhsia.telus.net) machinedgod |
| 2024-10-01 10:31:46 +0200 | <tomsmeding> | (never mind that it's often implemented as page width check, meaning that a narrow desktop browser window may trigger the mobile UI, which is not ideal) |
| 2024-10-01 10:31:03 +0200 | <tomsmeding> | some people don't like that, but it's a valid design decision that has reasons behind it (conforming to the UI expectations of a different platform) |
| 2024-10-01 10:30:47 +0200 | down200 | (~down200@shell.lug.mtu.edu) down200 |
| 2024-10-01 10:30:30 +0200 | merijn | (~merijn@77.242.116.146) merijn |
| 2024-10-01 10:30:29 +0200 | <haskellbridge> | <thirdofmay18081814goya> hm..... right |
| 2024-10-01 10:30:28 +0200 | <tomsmeding> | think also of things like: having a collapsible menu on mobile instead of a toolbar at the top on desktop |
| 2024-10-01 10:29:33 +0200 | <tomsmeding> | i.e. a layout that cannot just be achieved by inserting or removing line breaks between tree elements |
| 2024-10-01 10:29:26 +0200 | <probie> | I doubt it. Minor changes to the tree can have drastic changes to the UI |
| 2024-10-01 10:29:09 +0200 | <tomsmeding> | do note that many a (well-designed) website switches to a significantly different layout when viewed on a small enough screen |
| 2024-10-01 10:27:54 +0200 | down200 | (~down200@shell.lug.mtu.edu) (Ping timeout: 276 seconds) |
| 2024-10-01 10:26:16 +0200 | <haskellbridge> | <thirdofmay18081814goya> hm DOMs probably provide a good justification to model GUIs as trees, and then responsiveness can be treated as some sort of embedding of such trees into a context |
| 2024-10-01 10:25:06 +0200 | ft | (~ft@p4fc2acce.dip0.t-ipconnect.de) (Quit: leaving) |