Newest at the top
| 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) |
| 2024-10-01 10:16:11 +0200 | merijn | (~merijn@77.242.116.146) (Ping timeout: 244 seconds) |
| 2024-10-01 10:14:40 +0200 | lxsameer | (~lxsameer@Serene/lxsameer) lxsameer |
| 2024-10-01 10:14:36 +0200 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
| 2024-10-01 10:13:00 +0200 | misterfish | (~misterfis@84.53.85.146) (Ping timeout: 246 seconds) |
| 2024-10-01 10:11:32 +0200 | <haskellbridge> | <thirdofmay18081814goya> is responsiveness just an effect like any other? |
| 2024-10-01 10:11:14 +0200 | <haskellbridge> | <thirdofmay18081814goya> probably would like to distinguish some sort of "core" of the program from responsiveness, which doesn't seem essential to determine the meaning of the program |
| 2024-10-01 10:10:42 +0200 | <haskellbridge> | <thirdofmay18081814goya> what's a way to think about UI responsiveness? reponsiveness here understood as automatic reformating/rerendering of the program to be well-suited to the viewer's screen, e.g. in a mobile app |
| 2024-10-01 10:00:09 +0200 | merijn | (~merijn@77.242.116.146) merijn |
| 2024-10-01 09:52:55 +0200 | td_ | (~td@i5387093B.versanet.de) td_ |
| 2024-10-01 09:51:42 +0200 | szkl | (uid110435@id-110435.uxbridge.irccloud.com) (Quit: Connection closed for inactivity) |