The spacing seems way too small on some of these, and there's no coherent relationship between the different amounts of it. The web is basically 99% text and spacing, so it's important to get this right.
Apart from that, it's pretty clean, and I like the logo.
CSS frameworks are worthless. CSS should be written on a case-by-case basis. CSS frameworks are bloated and contain unused styles and provide no benefit to the developer but instead provides frustration when trying to write selectors to override CSS framework selectors. PLEASE STOP MAKING CSS FRAMEWORKS!
Why is this targeting full stack developers? Seems like a quite simple CSS framework.
To be honest, it's also really quite simple. I don't have much feedback - it's basic and it works to that level - except for that "maximalist" and "for full stack developers" didn't register with me, a full stack developer, so you might want to try a different branding
"fast" can (and I would say "will be") often associated with runtime performance. "Quickly" instead is less confusing to know it's about development speed.
why css frameworks gain so much traction when there is so much out in there. what is so wrong in existing css frameworks that we cannot improve ? why would someone go to new one when they have invested heavily on some existing frameworks ?
I see that in the README, you give an example that uses `hstack` and `vstack` tags. Can you just declare you own tags that are essentially wrappers for CSS? If not, I'd love an explanation what what they do.
You can define your own arbitrary HTML < /> tags and style them or use JS with them in modern browsers (which is what hstack and vstack are, which seems to be inspired by the pylon framework and SwiftUI).
If you need to support really old browsers than using an HTML5 shiv will be sufficient for any <tag /> to work:
I have a feeling this is one of those things that will become more common with this broader support for HTML5 and web components but at the moment it's not very common and there are some debates on whether you should break web standards/specs.
Reasonably clean, attractive and maintainable, but what makes this particular framework "maximalist" and for "full-stack developers", especially in comparison with other CSS frameworks?
That definition of "maximalist" doesn't make a lot of sense to me, but okay.
Your "full-stack" definition is... more or less in the right ballpark, I suppose, but doesn't that imply that Ridge actually integrates an HTML templating language as well?
At this point there are multiple "classless" CSS "frameworks" posted on HN daily and subsequently hitting frontpage. This fad has become quite boring, no offense to the author of this particular framework.
What's so hard about just throwing a few lines of CSS in a file and adding a link element to the <head>? You can get the same amount of mileage by spending 10 minutes writing generic rules with the benefit of knowing exactly what part of the page is affected by which rule (more valuable to me than the instant gratification of classless frameworks).
This particular framework is kind of a shortcut if you don't want to start from a blank css file and want to throw a web app together quickly.
Also, there are differences here from most other classless css frameworks because this mixes classless, atomic css and some swiftui like helpers for maximum html impact
Classless css helps you get going quickly with just html, think a <form> with <input> and <label> and everything looks decent. You haven't written any custom css.
Atomic css helps you add some customization, things like padding, margin, colors, borders as classes, again without writing any custom css, you are still in the same html file.
Swiftui helpers are <vstack>, <hstack> and <spacer />. you don't have to mess with bootstrap grids or custom css grids, just slap your elements in an hstack and they are now laid out horizontally as one example.
To sum it up, I would say the mix of these different approaches to css help you ultimately write no custom css yourself, you can focus on writing html, a few classes and that's it.
That's why I'm leaning toward TailwindCSS in almost every project. It's just a collection of classes. No prebuilt components, no big decisions being made for you, etc. It feels a bit freeing after 15+ years of CSS.
Be careful when using semantic elements purely for presentation purposes. For instance, the <aside> element gives the element a landmark role 'complimentary' telling assistive devices that this is not part of the main content.
That's not really true for your cards, though, they are part of the content.
Also, having multiple complimentary landmarks in the same context (main, footer) is really confusing. Having 3 <aside> elements next to each other would be like having three <header> elements next to each other.
It's a bit anarchic, but the idea of using semantic elements for presentation purposes is why I did this.
I think there doesn't need to be a distinction
Edit: I didn't notice the bit about accessibility, I need to educate myself about this but the next release will fix any weird roles.
Usually when debugging accessibility things I turn on the screen reader and hear how the site feels as I navigate around. I'll definitely do this before each release going forward.
IMO, this is the most interesting comment here so far (the second most interesting one being the rant saying "don't use CSS frameworks").
What other potentially unexpected consequences are there for using semantic markup? I would definitely not want to use the <aside> element if it makes my site less accessible to the visually impaired. Are there any other potential traps lurking here?
I'm not sure precisely what you mean, but, given the number of sites that use Bootstrap alone, I suspect many visually impaired people are, indeed, browsing sites made with CSS frameworks.
Yeah, I'd expect maximalist to be heavyweight and complex. It seems to be an unsatisfied niche with so many minimalist systems out there. There's loads of applications out there for which there's a captive audience of enterprise users who don't mind waiting an extra 3-4s to load scripts if they'll provide better function.
Very impressive framework, lots of well-made components, totally ready for enterprise use.
When I experimented with it briefly, though, it seemed pretty heavy, and I wasn't able to just use a small part of it without bringing in a whole jungle.
There’s a lot of critical reception in this thread, mostly people complaining about bandwagoning. However, there’s a lot to be said for eliminating the unnecessary “div all the things” mindset of websites today, it makes html much easier to read and eliminates unnecessary typing. As a css framework, this is also agnostic to rendering frameworks.
I wouldn’t consider classless a trend, just another useful methodology we still should be exploring.
On this particular page, it’s been split up into two stylesheets: the base part, and a theme; and JavaScript is required to load the theme, without which it looks awful. It would be nice for that to be fixed.
My usual complaint about these things is hijacking of existing semantic elements for presentation purposes. AbsoluteDestiny has dealt with that, so I’ll lay off this time. Beyond that: you have followed one of the routes I usually suggest, which is using your own elements (e.g. <vstack>). Good! I approve! Just one thing: if you want your markup to be valid HTML, put a hyphen in your element names so that they’re proper autonomous custom elements rather than just unknown elements that could theoretically be assigned meaning in the future. <v-stack>, <r-vstack>, <ridge-vstack>, something like that.
Other matters of HTML validity, mostly pretty harmless and about the markup shown on the sample page:
• You have some stray end tags: </img>, </input>. These are empty elements, so they don’t have end tags (that is, it’s actively wrong to write them, though in practice it’s completely harmless).
• You’re not allowed to put buttons inside links, though it will probably work almost properly in all browsers. The notable interactivity problem is that the link and the button are both focusable, so it messes up keyboard navigation a little. (A related case is links inside links, which is actively forbidden in the parser, and not handled by browsers. My vague recollection is that Firefox was the only one that did what a sane person would expect in the past, and no one else wanted to implement it, so they ripped the functionality out of spec and browser, to the regret of some.)
• tab-index="1" looks like you may have meant tabindex="1", though I suspect you don’t want either.
• The radio button label for attribute is wrong. Should be something like this (or you could just drop the `for` attribute, though allegedly some few accessibility tools are stupid and wrong and make a mess of things if you omit it, even though that’s perfectly valid and has been forever):
<label for="radio1">
<input type="radio" name="radio" value="true" id="radio1">
Radio 1
</label>
I actually like <v-stack> although it could be confusing coming from vue.js, but that's something I can live with.
Thanks for pointing out everything, it should all be fixed if you take a second look, except for the button in a link thing, that's going to take a little bit.
46 comments
[ 3.3 ms ] story [ 89.3 ms ] threadApart from that, it's pretty clean, and I like the logo.
Luckily it’s easy to change on future themes and even the default one with a few css variables
https://github.com/swlkr/ridgecss/blob/master/ridge-dark.css...
To be honest, it's also really quite simple. I don't have much feedback - it's basic and it works to that level - except for that "maximalist" and "for full stack developers" didn't register with me, a full stack developer, so you might want to try a different branding
The original branding ended with "for making web apps fast"
Languages are another one where you can stop making new ones, but why would you?
There isn't one, but I will definitely add it!
https://ridgecss.com/examples.html
There's also the original inspiration for them here:
https://almonk.github.io/pylon/
They are essentially swiftui-ish helpers to lay things out with even spacing vertically (vstack) or horizontally (hstack)
https://github.com/swlkr/ridgecss/blob/master/ridge.css#L970
but since they aren't for you, it's the first bug!
If you need to support really old browsers than using an HTML5 shiv will be sufficient for any <tag /> to work:
https://johnresig.com/blog/html5-shiv/
There's a longer discussion here about pros/cons:
https://stackoverflow.com/questions/16867332/html5-why-not-u...
I have a feeling this is one of those things that will become more common with this broader support for HTML5 and web components but at the moment it's not very common and there are some debates on whether you should break web standards/specs.
It really is meant to be used kind of like a bootstrap substitute with less !important and more reactivity coming from alpine.
Full stack developers used to mean "render html on the server and spruce it up with javascript" so that's kind of where I was going with it.
Your "full-stack" definition is... more or less in the right ballpark, I suppose, but doesn't that imply that Ridge actually integrates an HTML templating language as well?
What's so hard about just throwing a few lines of CSS in a file and adding a link element to the <head>? You can get the same amount of mileage by spending 10 minutes writing generic rules with the benefit of knowing exactly what part of the page is affected by which rule (more valuable to me than the instant gratification of classless frameworks).
Yeah I don't wanna target the author in particular but the daily releases of these `frameworks` is getting a bit comical.
This particular framework is kind of a shortcut if you don't want to start from a blank css file and want to throw a web app together quickly.
Also, there are differences here from most other classless css frameworks because this mixes classless, atomic css and some swiftui like helpers for maximum html impact
Do you have a one paragraph summary of what those are and why they are good?
Atomic css helps you add some customization, things like padding, margin, colors, borders as classes, again without writing any custom css, you are still in the same html file.
Swiftui helpers are <vstack>, <hstack> and <spacer />. you don't have to mess with bootstrap grids or custom css grids, just slap your elements in an hstack and they are now laid out horizontally as one example.
To sum it up, I would say the mix of these different approaches to css help you ultimately write no custom css yourself, you can focus on writing html, a few classes and that's it.
Edit: capitalization
That's not really true for your cards, though, they are part of the content.
Also, having multiple complimentary landmarks in the same context (main, footer) is really confusing. Having 3 <aside> elements next to each other would be like having three <header> elements next to each other.
I think there doesn't need to be a distinction
Edit: I didn't notice the bit about accessibility, I need to educate myself about this but the next release will fix any weird roles.
Usually when debugging accessibility things I turn on the screen reader and hear how the site feels as I navigate around. I'll definitely do this before each release going forward.
What other potentially unexpected consequences are there for using semantic markup? I would definitely not want to use the <aside> element if it makes my site less accessible to the visually impaired. Are there any other potential traps lurking here?
I need to look into it more, it's still early and the code isn't set in stone, so I will be tackling accessibility issues
To nitpick for feedback:
- I'd prefer more spacing for headers, labels, input fields
- The checkbox and its label might look better if they aligned perfectly with radio inputs.
- Clicking on checkbox label changes the selection, but it doesn't with radio labels.
- Clicking on range input makes the whole thing go down a pixel or two. That effect looks OK on buttons, but not for range (in my opinion).
Good point about the range, the whole thing moving down doesn't make sense
https://ant.design/components/overview/
Very impressive framework, lots of well-made components, totally ready for enterprise use.
When I experimented with it briefly, though, it seemed pretty heavy, and I wasn't able to just use a small part of it without bringing in a whole jungle.
I wouldn’t consider classless a trend, just another useful methodology we still should be exploring.
Yeah the classless thing AND atomic css both struck a chord with me, so I wanted to try and make something that combines the best of both worlds.
My usual complaint about these things is hijacking of existing semantic elements for presentation purposes. AbsoluteDestiny has dealt with that, so I’ll lay off this time. Beyond that: you have followed one of the routes I usually suggest, which is using your own elements (e.g. <vstack>). Good! I approve! Just one thing: if you want your markup to be valid HTML, put a hyphen in your element names so that they’re proper autonomous custom elements rather than just unknown elements that could theoretically be assigned meaning in the future. <v-stack>, <r-vstack>, <ridge-vstack>, something like that.
Other matters of HTML validity, mostly pretty harmless and about the markup shown on the sample page:
• You have some stray end tags: </img>, </input>. These are empty elements, so they don’t have end tags (that is, it’s actively wrong to write them, though in practice it’s completely harmless).
• You’re not allowed to put buttons inside links, though it will probably work almost properly in all browsers. The notable interactivity problem is that the link and the button are both focusable, so it messes up keyboard navigation a little. (A related case is links inside links, which is actively forbidden in the parser, and not handled by browsers. My vague recollection is that Firefox was the only one that did what a sane person would expect in the past, and no one else wanted to implement it, so they ripped the functionality out of spec and browser, to the regret of some.)
• tab-index="1" looks like you may have meant tabindex="1", though I suspect you don’t want either.
• The radio button label for attribute is wrong. Should be something like this (or you could just drop the `for` attribute, though allegedly some few accessibility tools are stupid and wrong and make a mess of things if you omit it, even though that’s perfectly valid and has been forever):
Thanks for pointing out everything, it should all be fixed if you take a second look, except for the button in a link thing, that's going to take a little bit.
[1] https://marvinblum.de/
[2] https://concrete.style/
https://news.ycombinator.com/item?id=20155098