Optional widened main column #402

Riedler · 2024-06-16T15:05:42Z

Riedler commented

2024-06-16 15:05:42 +00:00

this necessitated some major layouting changes, so please tell me if there's anything broken that I didn't catch 😅

before	after (off)	after (on)

part of DNS#1

also, default is for this setting to be on, since I've personally heard only positive feedback for this change, but I wouldn't mind turning it to off if necessary

this necessitated some major layouting changes, so please tell me if there's anything broken that I didn't catch 😅 | before | after (off) | after (on) | | --- | --- | --- | | ![image](/attachments/7c806344-683d-45f3-90c4-1c725cfae6e9) | ![image](/attachments/23b8cf4a-a905-48aa-a758-f011c29d30b3) | ![image](/attachments/150bd427-76ca-4ecd-8570-20809bcea983) | part of [DNS#1](https://git.sakamoto.pl/domi/akkoma-fe/pulls/1) also, default is for this setting to be on, since I've personally heard only positive feedback for this change, but I wouldn't mind turning it to off if necessary

image.png

2.7 MiB

image.png

2.6 MiB

image.png

1.8 MiB

Riedler added 6 commits 2024-06-16 15:05:43 +00:00

made columns use more space, fixed minor bug 21fe7d76d3

made attached images max size scale with font size 74b651a3a2

meta-comment: eliminated corner-case weirdness by replaced cursed CSS with slightly less cursed CSS

fixed media attachment heights dd32a33d59

fixed sizing issues with attachments in some non-status containers 45fe334cd7

reverted audio attachments to 4:1 aspect ratio 1b4df9e79d

made wide column layout optional

ci/woodpecker/pr/woodpecker Pipeline was successful

Details

4abddf5e6a

Riedler referenced this pull request

2024-06-16 16:16:50 +00:00

(arguably) improved layouting of user profile page #403

Oneric reviewed 2024-06-17 01:02:25 +00:00

Oneric left a comment

I don’t know CSS and the frontend specifics well enough to be able to tell which subtle breakages this might or might not bring. But one comment re what’s visible in the screenshots:

This apparently extends the underlay to always cover the whole screen rather than just the area with columns. Personally i have the underlay disabled anyway, but i’ve always assumed it is to distinguish the content area and possibly add some additional damping to the background and make posts more readable with translucent text backgrounds while still showing the background image in its original vibrancy in the padding area. If the underlay just applies to the whole area this purpose gets lost and one might as well just set a pre-mixed background colour or image

I don’t know CSS and the frontend specifics well enough to be able to tell which subtle breakages this might or might not bring. But one comment re what’s visible in the screenshots: This apparently extends the underlay to always cover the whole screen rather than just the area with columns. Personally i have the underlay disabled anyway, but i’ve always assumed it is to distinguish the content area and possibly add some additional damping to the background and make posts more readable with translucent text backgrounds while still showing the background image in its original vibrancy in the padding area. If the underlay just applies to the whole area this purpose gets lost and one might as well just set a pre-mixed background colour or image

Riedler commented

2024-06-17 09:20:17 +00:00

I can change that somewhat easily I think, will do that in a bit

Riedler added 2 commits 2024-06-26 14:44:05 +00:00

reverted visual changes to underlay b2af067fd3

expand underlay to screen edges when TL is widened

ci/woodpecker/pr/woodpecker Pipeline was successful

Details

2e2e87db75

Riedler commented

2024-06-26 14:44:40 +00:00

the underlay problems should be fixed now

Oneric commented

2024-06-30 21:53:02 +00:00

Thanks!

Seems to work fine for me in testing, but as mentioned before i’m not familiar enough with the frontend’s (and in general) CSS to give this a more thorough review

Thanks! Seems to work fine for me in testing, but as mentioned before i’m not familiar enough with the frontend’s (and in general) CSS to give this a more thorough review

Oneric reviewed 2024-06-30 21:55:01 +00:00

src/App.scss

					
				@ -172,6 +172,10 @@ nav {

				  background-color: rgba(0, 0, 0, 0.15);

				  background-color: var(--underlay, rgba(0, 0, 0, 0.15));

Oneric commented

2024-06-30 21:55:01 +00:00

unrelated to your changes, but do you happen to know why background-color is defined twice here? iiuc the second parameter in var already is a fallback value. Is this for old browsers which don’ŧ support var at all, or something else?

unrelated to your changes, but do you happen to know why `background-color` is defined twice here? iiuc the second parameter in `var` already is a fallback value. Is this for old browsers which don’ŧ support `var` at all, or something else?

Riedler commented

2024-07-03 14:45:37 +00:00

I would assume it's for older browers that don't know the var syntax, since invalid values get discarded, in which case line 172 would be in effect. At this point though, do we still want to support that? That's basically just for IE11 and other really really ancient browsers.

image source: https://caniuse.com/css-variables

I doubt akkoma works on these browsers at all tbh. If not for all of the grid and flex, definitely for our fairly modern javascript (though I'm less knowledgable there, so don't ask me for specifics xD).

I would assume it's for older browers that don't know the `var` syntax, since invalid values get discarded, in which case line 172 would be in effect. At this point though, do we still want to support that? That's basically just for IE11 and other really *really* ancient browsers. ![image](/attachments/b1aae1ef-c2b4-41b9-ab74-e7307b4f9ef6) image source: https://caniuse.com/css-variables I doubt akkoma works on these browsers at all tbh. If not for all of the grid and flex, definitely for our fairly modern javascript (though I'm less knowledgable there, so don't ask me for specifics xD).

image.png

303 KiB

👍 1

Oneric commented

2024-06-30 22:07:23 +00:00

Actually there’s one thing: with this patch and wide mode turned off, the TL is slightly narrow than without the patch on non-wide (but not yet mobile) screens, e.g. 5:4

The difference is minute however and i only noticed in direct comparison, so imho nothing to worry about but documenting it here just in case

Actually there’s one thing: with this patch and wide mode turned off, the TL is _slightly_ narrow than without the patch on non-wide (but not yet mobile) screens, e.g. 5:4 The difference is minute however and i only noticed in direct comparison, so imho nothing to worry about but documenting it here just in case

Riedler commented

2024-07-03 14:47:36 +00:00

hmm, the difference is probably due to the changes I made to padding, since the rest should be 1:1 the same as before in terms of width in non-wide mode.