/tech/ - Technology

Leftist Tech

Mode: Reply
Name
Subject
Message

Max message length: 4096

Files

Max file size: limitless

Max files: 3

E-mail
Password

(used to delete files and postings)

Misc

Remember to follow the rules


Lets Make a Responsive Imageboard Comrade 10/28/2019 (Mon) 20:06:19 No. 1002
Hey folks I had some time off again this morning so I was able to polish off a good chunk of the template from last week, fixing the issues I was having there and adding some new content. The following is a list of design ideas for the front-end, I probably have a morning or two more work to have this in a stable enough situation to start working on the backend which I have a number of ideas for as well.

Text formatting should be composable without errors, and should be subtle. There should be no text formatting that you would be surprised to see in a article or book.

Minimalism should be upheld. unnecessary forms, links, and elements should be removed. Adding complexity unnecessarily makes everything more difficult to implement for no reason and slower on account of having to process, serialize, and send additional information.

Responsive design should be implemented. I don't own a device with a touchscreen, but they are omnipresent, and there is no reason that you shouldn't be able to use a website with your touchscreen device well.

Web-fonts should not be used. Web-fonts don't improve the usability of the site but increase bandwidth usage and hinder performance for users.

JavaScript should be solely used for copying text into the reply form, automatically refreshing the page, and changing the page title when there has been a unseen reply due to automatic refresh. Possibly also for n file upload.

Compatibility should be strived for, I'd like to see 90% support at the minimum preferably greater than 95% along with a browser for more or less every desktop platform since ~2000. (Windows XP can be trivially supported due to PaleMoon MyPal for example, G3 and later Macs can be supported with TenFourFox, there isn't really a reason to have a outdated linux/bsd machine, mobile devices will likely be a different story.)
>>1002
Here's a photo of the site operating on a simulated smartphone of some sort with the menu open. The next step I think is going to be to rewrite the CSS in SASS to improve maintainability and such. After that I'll start testing with FiveFourFox, PaleMoon, and Chromium.
>>>>How does
>>>this
>>look
>like?
>>1004
I haven't selected a color for green-text yet I'll do this later. I'd be willing to take a suggestion on how you think this should be parsed though. Do you think the top three should be treated as green text? It's certainly possible if that's desirable.
>>1003
>The next step I think is going to be to rewrite the CSS in SASS to improve maintainability and such. After that I'll start testing with TenFourFox, PaleMoon, and Chromium.
My evening was free too so... I've moved over to SASS and done some tweaking to make the CSS very compatible with older browsers. It supports desktop and mobile browsers after 2012 flawlessly. Before 2012 there wasn't vh and vw which is used to make the menu extend fully. The menu is out of the way and still entirely usable without stretching across the screen though. To become pretty broken you've got to go back to before 2010 on mobile devices and 2006 for desktops at the minimum. They might not even be that broken then. I've also implemented the rest of the CSS for the text formatting.

I've got a little more dynamism I need to add to style sheet, mainly just using rem and friends instead of px, but after that I'll be ready to start working on the backend. The backend will be programmed in either OCaml or Scheme and will be served by a reverse proxy from your HTTP server of choice to some sort of HTTP server library in the program.
>>1005
Well, when I usually do multiple arrows it's supposed to be quotes within quotes (does nobody outside of mailing lists do that anymore?), so none of it should have the color of the normal text. It could be all the same green, that would be better than how it's handled at bunkerchan at least. What I'd personal prefer is more arrows making the text more faint.
>>1007
Well, when I usually do multiple arrows it's supposed to be quotes within quotes, so none of it should have the color of the normal text.
That sounds reasonable to me. I did do some more thinking on this though and you do actually introduce some ambiguity because you're effectively overloading ">>" and ">>>". That means that if you're quoting someone two replies back who starts their sentence with a number or three replies back and starts their sentence with a board name it's not clear how that should be rendered. It seems that quite often you would want it to be the way it is not regardless of which way you set it. I'll have to think more about the cost benefit.

>What I'd personal prefer is more arrows making the text more faint.
This sounds pretty cool, if I end up implementing the nested quoting I think I'll follow through with your idea here.

I'll post a update on the progress for the day shortly. This will likely be the last day of the week I'll be able to make substantial progress though.
>>1008
Okay so today was mostly about making mobile work 100% rather than changing anything about the style. I polished off the three other color schemes and made some minor changes to the main one but other than this any changes were just a product of making things work. Anyway as far as what I actually did I put in fallbacks for the custom-properties, converted the vh, and vw units to %, rewrote nearly everything in terms of rem and em, reduced the padding on mobile, added scrolling for the code blocks, changed the media query to something with greater compatibility, setup scaling for mobile, added browser prefixes to expand the reach, and cleaned everything up a bit.

At this point the only thing really left for the CSS to be basically complete is to make it where the mobile menu can scroll when flexbox is not available. Lastly I briefly looked at Ocsigen Eliom the OCaml web framework, I'll probably be using this although I'm still not certain.

see yah next week.
>>1009
Oh and by the way at this point the minified but not gzipped CSS is 3869 bytes. This site has many more pages to style than mine so it's not fair to compare, but even with the responsive design it wouldn't surpise me if this was as much as 6 times smaller than the CSS here.
How do spoilers work? Do they cover up EM🍩JI and also colored text and also links like https://bunkerchan.xyz for example?
>>1012
>Do spoilers work with other sorts of text formatting?
So, basically the only ways to get spoilers to work are to either remove colors when hovering, or to not spoiler colored text and links. I've opted to spoiler but remove the colors. I also don't plan to have any equivalent to the rage text, I think bold is a fine replacement. Attached is a image of this in action.
>>1012
>Do Emojis work with spoilers?
Emojis are even more tricky, as it stands only new chrome and safari builds support using transparency to hide them while having them still take up space. I've got a way that comes close to this while being backwards compatible but depending on the size of the emoji it's often going to be incorrect and lead to it resizing slightly on hover. I'm honestly considering banning emoji's although I likely won't do it.
>>1015
>depending on the size of the emoji it's often going to be incorrect and lead to it resizing slightly on hover.
You can actually see this in the image sizes of the two examples notice how one is "329x196", while the other is "327x196", that's because the span I'm using to fill while the emojis not there is 2px smaller than the actually emoji on my device. This fill can't realistically be dynamically changed because every font has different emoji designs and we've already ruled out using webfonts. By the way this requires a span for every emoji or block of emojis in the spoiler, along with a additional span for each spoiler block, not exactly pretty. If I'm being honest the possibilities are a webfont with emojis or to remove emojis, on some devices the current implementation will look quite bad.
>>1016
Apparently a sound way to deal with this is to swap all the emojis for SVG images, and maybe limit the number you can post per reply. Twemoji is one source of these SVGs. So the options are removal or SVGs, neither of which seem unreasonable to me.

I think when I start back to work this following Monday or Tuesday I'll focus on the back-end. Just for my own sake I'm going to have a brief list to remind me what still needs to be done on this page's template: overflow-y: auto; on mobile when flex-wrap isn't available for the navigation, add reporting/deleting posts, check if whited00r has a browser with rem support, add moderation tooling, consider "desktop first" CSS because all mobile devices have media query support, and setup a second position: fixed; form for easier posting.

Delete
Report/Ban

Captcha (required for reports and bans by board staff)


no cookies?