Feedback on the CSS architecture for Cerca about cerca

[Thomasorus]

Did someone ask for themes, or is it something that we expect people to want to play with?

I do, I want them so much! And the thing is, theming is actually super cheap.

Even if we had no intention of doing themes we would still have to identify design tokens, list them and then use them in the code right after for the default theme. So all that is left for themes is just changing values. Of course people can set their own styles with browser extensions, but not all are technically capable of doing it, and would probably enjoy having a choice.

As for supporting older browsers, I think feature parity is important. There's no other reason for me, I just want all users to be able to enjoy everything even if they don't have the same technical/financial capabilities.

I think that node would be a bad dependency to have. It may be lighter/easier/faster to generate the css directly from a Go templates.

I was thinking about it today and how we could do this. Do you think about something like a custom parser that lists all our variables, scans the CSS and replace the values?

[cblgh]

There's a lot here, so I'll have to opt for the nit-picky type of discussion where I clip out parts you have written and respond to them—sooorry about that!

Some context: the minimal styling atm was done in the way it was because I anticipated us redoing the stack, so I wanted not to go nuts-o with classes and divs that would be restructured in the great sauropod epoch 🦕

The only solution then, is to build them using SCSS variables, and compile several themes in different files, and then let the user change its theme through a form and save it in his profile.

By making the code available and standardizing a config file with all variables in, we could also allow people to edit their own themes more easily and propose them to the community.

If we opt for using SCSS in taking this path—not super keen as it adds a lot of friction for me, the in-some-sense main developer, and for new people who also might not know SCSS—I would like to have a golang solution for generating the SCSS. But it might be that I don't understand what you are thinking; in the next couple of days I'll have to revisit the code you made for sr.ht and look at how that was done in detail to be better informed to help make a decision on this with you & the others.

---

My opinion: progressive enhancement is cool with me, but some experiences are better if they are less instantly gratifying. So I am less inclined to naively implement enhancement for e.g.

Insert new posts in a thread without reloading the page
Delete a post without reloading the page

Than e.g. changing fonts, or doing previews. If we hear or notice large parts of the community complaining about these parts being cumbersome, then I think that's trigger for spending time on implementing (and perpetually having to support the enhancements when APIs change) those types of features. But in the meantime, let's indulge in some nostalgia yeah? Hope that's not too draconic 🐲

ANYYWAY I'm +1 on themes and on the general methodology proposed! I am really super wary of dragging in a package.json into the project, or using SCSS, so I am super open to exploring ways of accomplishing the utility classes without that!

p.s written late at night when i'm sleepo, so sorry if the comms are less tight than they could be 🖤

[jrgarcia11]

Inlined SVGs can be replaced by background images with PNGs.

I disagree! Drawing the merveilles icon with vectors was cool. Also, isn't a few lines of vector data much better bandwidth-wise than having to create different colored PNGs of the same icon? The "fill" property <svg fill="black"> being especially useful for custom themes.

Unsure if the svg tag is supported in the barebone browsers.

[cblgh]

Unsure if the svg tag is supported in the barebone browsers.

that's the problem iirc :)

[JamieCrisman]

Since we are supporting very far back on the CSS/styling side of things. Are the backwards compatibility targets for JS the same? Do we have a good idea of how much we'd be restricted by it? At the very least, I think it should be defined what we're trying to target and have resources to what's supported and not supported. Netsurf isn't listed on caniuse.com which is a popular resource for checking JS/CSS compatibility. I don't want contributors to be discouraged because they can't tell them if their changes will be accepted or reverted because of the compatibility requirements.

[cblgh]

Well at the moment there is no JS, and I think what @Thomasorus is saying (please correct if untrue!) is that all the javascript we might add will only exist to make things that are already possible without it sleeker operations when JS is enabled. So in that sense, there are no strict backwards compat targets for JS, as I can understand it?

I agree with being mindful regarding maintenance burdens—I don't want this to become a job so much as I want it to be fun and joyful :)

So far, making things without javascript has been quite joyful! It's has been a fun constraint that forces new learnings on my part :3

Thanks for your voice @JamieCrisman!

[Thomasorus]

Hey folks, gonna take the time to answer everyone. 😃

If we opt for using SCSS in taking this path—not super keen as it adds a lot of friction for me, the in-some-sense main developer, and for new people who also might not know SCSS—I would like to have a golang solution for generating the SCSS.

OK so let's go back to the beginning! SCSS is a subset of CSS, which means it adds to the language while keeping its syntax and rules. Among the things SCSS allows the most commonly used are:

• Compiling to native CSS
• Imports several partials into a single file when compiling
• Adding variables using the $ sign
• Nesting declarations
• Reusing snippets of code or declarations when they don't fit in variables

SCSS is probably the most commonly used CSS tool in the world and has a veeeery low barrier of entry. It's not relearning a new framework or anything like bootstrap or tailwind. A lot of things modern CSS can do was actually inspired by SCSS, just like modern JavaScript took a lot of what made jQuery great at the time.

Than e.g. changing fonts, or doing previews. If we hear or notice large parts of the community complaining about these parts being cumbersome, then I think that's trigger for spending time on implementing (and perpetually having to support the enhancements when APIs change) those types of features. But in the meantime, let's indulge in some nostalgia yeah? Hope that's not too draconic dragon_face

Yeah I totally see what you mean and why you are against it. I have reasons why I think it's a good idea but that's not today's topic, so I'll try to convince you another day. Let's focus on the purely visual/CSS architecture for now.

ANYYWAY I'm +1 on themes and on the general methodology proposed! I am really super wary of dragging in a package.json into the project, or using SCSS, so I am super open to exploring ways of accomplishing the utility classes without that!

Unfortunately SCSS/SASS is a dart library and can't be compiled with Go. Actually most modern tools are made in Node, with a movement to Go or RUST binaries, but we're not there yet to replace the NPM ecosystem for CSS tooling.

If we want to avoid a build system entirely and write in pure CSS we can! But that means using modern CSS variables and JS activation for changing themes, which means no themes for older browsers or no-JS users. So it's basically choosing between complexity for the sake of all users, or a less tailored experience for a subset of users in favor of simplicity.

It's entirely you call.

Unsure if the svg tag is supported in the barebone browsers.

It's not.

Since we are supporting very far back on the CSS/styling side of things. Are the backwards compatibility targets for JS the same? Do we have a good idea of how much we'd be restricted by it? At the very least, I think it should be defined what we're trying to target and have resources to what's supported and not supported. Netsurf isn't listed on caniuse.com which is a popular resource for checking JS/CSS compatibility. I don't want contributors to be discouraged because they can't tell them if their changes will be accepted or reverted because of the compatibility requirements.

You can find more info here: http://www.netsurf-browser.org/documentation/progress.html#WebStandards

Well at the moment there is no JS, and I think what @Thomasorus is saying (please correct if untrue!) is that all the javascript we might add will only exist to make things that are already possible without it sleeker operations when JS is enabled. So in that sense, there are no strict backwards compat targets for JS, as I can understand it?

You got it right. JavaScript would 100% be to make the forum sleeker. No feature in the forum should require it. The main legacy browser we target is netsurf, and it doesn't have any JavaScript support: http://www.netsurf-browser.org/documentation/info.html#JavaScript

So basically if we want to support old browsers we should probably just... transpile down to ES5? Since we're probably gonna only do basic things like ajax calls and light dom manipulations, it should be working correctly on most browsers, even old ones. And again, it won't be required.

[sansfontieres]

I think that node would be a bad dependency to have. It may be lighter/easier/faster to generate the css directly from a Go templates.

[neauoire]

Did someone ask for themes, or is it something that we expect people to want to play with?

I personally am not going to use themes, I'll just use watever people decide is a good default, on Firefox I have stylus and Paper to theme websites which don't fit my aesthetics, I'm not sure if that's something we should implement at the website default, unless a majority is really into theming.

If we serve basic html, people can set their own browser defaults.