Comments (9)
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?
from cerca.
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 🖤
from cerca.
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.
from cerca.
Unsure if the svg tag is supported in the barebone browsers.
that's the problem iirc :)
from cerca.
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.
from cerca.
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!
from cerca.
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.
from cerca.
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.
from cerca.
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.
from cerca.
Related Issues (20)
- Add --base option to css compiler
- "Jump to Bottom" Link is Missing HOT 2
- Edit support for posts HOT 9
- Verification link's host is not in the allowlist HOT 1
- Lowercase usernames HOT 2
- Invite tree system HOT 2
- More granular relative time HOT 2
- customize templates HOT 1
- Pinned threads
- err404 and other error pages return 200 status code
- Feature Request: Support for external/proxy authentication HOT 4
- The password reset tool linked from the reset page doesn't exist HOT 1
- Go 1.22 Routing HOT 2
- "Prod readiness" -> anti spam and input validation HOT 7
- Localization on error strings HOT 1
- "Topics" discussion HOT 2
- Open singups discussion HOT 3
- "Admin" link missing on some pages HOT 3
- Private threads HOT 7
- Reducing binary size HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from cerca.