Shoelace.css – A back to the basics CSS starter kit | Hacker News Reader

Shoelace.css – A back to the basics CSS starter kit

shoelace.style

257 pointsnicc122 comments

May I suggest another great back to basics CSS framework: http://bootstrapdocs.com/v1.4.0/docs/

It's only 12K minified and it includes everything you've come to expect from Bootstrap (that's now 120K minified). As a bonus, you get full _IE7_ support for all your friendly third world enterprise customers -- and no worries about responsive design because that's not supported at all!

Agreed - I made the mistake of using a small CSS starter framework and regretted it a few weeks into the project. CSS size isn't usually a problem for anything I do (internal backends typically) so I tend to just put bootstrap in and go.

I think things like this (Shoelace) are a great learning experience for the developer(s) in question or for fun throwaway stuff. You could make an argument for them for a team project where there's wide agreement, but for anything I will need to maintain or share with someone or hand off I pretty much only use Bootstrap as a starting point. Saves a lot of headaches down the line.

You're not really agreeing though. The poster is suggesting Bootstrap v1.

I am IMO; V4 might be a total rewrite but there's still some commonality between it and V1 with class names & concepts. I wasn't suggesting that current bootstrap and v1 are the same thing. For anything that I would need to support or work with others on, using a well-established CSS framework like Bootstrap (v-whatever) has always been safer and more productive in the long run. YMMV.

Use the term "third world" with your clients and they may wish to no longer be your clients. It's pretty outdated and almost never used in a professional context any longer. http://www.npr.org/sections/goatsandsoda/2015/01/04/37268443...

The conclusion of the article you cited is that the authors can't find a way to conversationally distinguish between wealthy and poor nations without somebody being offended.

I think this is a great illustration of the fact that, although some people intend to be derisive in their speech, we shouldn't assume that any designation whatsoever is intended as derision. That is, everybody needs to chill and assume the other person is making a good-faith attempt to be reasonably polite until proven otherwise.

Fair enough. As somebody who has spent the past 15 years working in global health and international development, I can tell you that "third world" is considered pretty pejorative these days. While there might not be a convenient way to linguistically group together all those "friendly third world countries," I suggest you avoid using the term "third world."

Can you suggest an alternative? LEDCs? Developing countries? Newly industrialized countries? TPLACs (in jest)?

I think your best bet is just to refer to regions or specific countries. The "developing" part of developing countries creates a false dichotomy. The World Bank doesn't even use it anymore (https://qz.com/685626/the-world-bank-is-eliminating-the-term...). Just say South East Asia or Sub-Saharan Africa, or whatever you mean.

I don't think anyone would take offense to that term. It is used in a professional context quite frequently. Everyone knows what the word means.

There is also Preboot[0] which is a "precursor to Bootstrap" and allows you to use just what you need.

Don't know how big it is but it's very small and it's based on LESS so you can pick and match what you really need.

Used it with pretty good success since I like to roll my own (sorry!) and Bootstrap and others was a little to much Batteries Included.

[0] http://getpreboot.com

> Bootstrap and others was a little to much Batteries Included.

Don't really agree with that as Bootstrap is also modular, especially if you use it from Sass or LESS source, which IMO is the 'right way' to use it.

(You can also make a customised build at http://getbootstrap.com/customize/ if you want to pick and choose modules but don't use a preprocessor like Sass/LESS).

You know what, you're right, I guess I just like starting from a small footprint.

Bootstrap is a small footprint though, e.g. typography module is 2.8kb gzipped. Add modules as needed, they're all well designed/thought-out. Shrug.

Indeed, with Sass, just comment out what you don't need. I rarely use much beyond the grid and normalization, it nice as its a predictable setup that you can plug in front end devs, and almost everyone knows the media queries vars (if they don't, they can google them) and such.

Bootstrap 3 or 4 are much more sophisticated and cover a lot more edge cases. Just comment out what you don't need in Sass. There are few projects that require the legacy browser support from v1.

Problem is like I described here: https://davidwalsh.name/shoelace-css

TL;DR – most people just use the bundle because they don't want to setup a preprocessor.

Certainly hasn't been my experience, I can't think of a single project in the last 5 years that didn't use a preprocessor. Personally I would never go back to not using one. It's incredibly easy to set up and you have to set up a postprocessor anyhow.

This sounds like a statement made by a professional web developer. A lot of non-web-developers find themselves needing to throw up or maintain a basic website for this or that, but the web development scene is a freaking nightmare.

> It's incredibly easy to set up

Yeah, once you've spent a few hours reading up on the latest docs. That's like me saying saying to you "Building a customized linux kernel for any hardware is incredibly easy with Yocto Project"

There are GUIs for Sass now that require 0 knowledge of the command line. I think Prepros lets you drag and drop a folder and click a folder watcher button. `gem install sass` + a basic Gulpfile isn't that hard either.

https://github.com/joe-watkins/gulp-sass-starter/blob/master...

Although you're correct, I meant in a professional environment. Id be quite surprised if I caught one of my devs not using a preprocessor.

Many of us pro devs have boilerplate build scripts that make setting up a new project easier. I've done this for many projects — but one day I look forward to NOT using one.

For enthusiasts, most really do load the entire bundle via CDN. For Bootstrap 4-alpha6, that's 192KB of CSS and another 47KB of JavaScript.

They just copy and paste and override the raw CSS. Many don't even know what a preprocessor is, much less how to set one up. Now they don't have to.

Bootstrap 4 Full CSS over CDN is 23k minified & gzipped. There are Sass GUIs for novices, but you're correct I was referring to professionals. I don't understand the appeal of not using a build script, and, say going back to adding browser prefixes manually one-by-one? There's no benefit other than the hour you save at the beginning of your 3-month-long project editing your gulpfile.

Totally agree. Preprocessors still have a place in many projects and there are tools such as CodeKit that make them easier to manage for non-devs.

But I never said this project wasn't bleeding edge. It will only become more relevant as browsers evolve :)

BTW - Shoelace is only 7.9KB min/gzipped.

What is the CSS framework equivalent of: "expand until it can read mail"?

And here I thought that http://motherfuckingwebsite.com was the basics and http://bettermotherfuckingwebsite.com was a more "advanced" starting kit for styling.

bettermotherfuckingwebsite makes some good points, whilst completely avoiding the rather large elephant in the room - pictures.

    img {
        display: block;
        max-height: 98vh;
        max-width: 100%;
        width:auto;
        height:auto;
        margin: 0.6rem auto;
        padding: 0;
        outline: 1px solid #333;
    }

https://thebestmotherfucking.website/ covers having images, among a few other tweaks on the motherfuckingwebsite and bettermotherfuckingwebsite formula.

> Doesn't load massive images or scripts. We should all care about people who still use IPoAC

That makes no sense. IPoAC doesn't really care if you add a few megs of scripts and images. Hell, it doesn't care if you add a few gigs. It will load at more or less the same speed as a single text document.

What really annoys me is that the says his total site has a size of 34.97 KB + 27.83KB in an image, but JQuery with 32kB is to much.

I wouldn't really believe that 60kb vs 90 makes a huge difference. Website get bloated at a different place.

Bootstrap gzipped is also only 20kb.

Why does this motherfucker touch the contrast of the text in my browser???? :D

I wish more sites would follow those principles. One of the reasons I made the switch[0] was because people from countries with limited internet access wanted to use things I was posting as a reference. Unfortunately I don't have a good replacement for MathJax right now. A side effect is that everything displays nicely even on a phone, with no work. I am aware that my website is ugly but I'd rather have one that is readable.

[0] For example https://lancebachmeier.com/computing/j-b-test.html

What about KaTeX? It doesn't suit my needs (I need to use the unofficial Xy-pic extension for commutative diagrams) but few users have those constraints, and KaTeX is significantly faster.

I've tried it in the past. It struggled with, among other things, properly putting subscripts on variables. I plan to try it again in the future.

I think https://bestmotherfucking.website is the best one. It's got HTTP/2, good contrast, minimal styling, gzip, and uses a CDN.

"Back to basics":

> css variables

> 32KB (unzipped)

That said, I do love it though -- I have yet to dig into the CSS variables spec but I like that it offers near-bootstrap level functionality for a lot less size.

Compared to my usual go-to, https://purecss.io/ though, it's super duper heavy, a factor of 10. Then again, pure doesn't have as many nice-to-haves.

Also, I really like the height utilities... I find myself writing these two utility classes ALL the time:

  .full-height { height: 100%; }
  .full-min-height { min-height: 100%; }

I used Pure in one project and this thing drove me insane:

https://purecss.io/grids/#using-grids-with-custom-fonts

Am I really the only one who want to use another font than sans-serif with Pure? I had to hard-override the font on so many places just because sans-serif had such high specificity already.

When it comes to css frameworks you're not supposed to override the styles. Most of them give you an option to customize the setup or can be modified easily by changing a few SASS variables.

While that might be true, I do take it as a dis-advantage that the frameworks can't be easily overridden. I can just imagine the wasted minutes now, setting a font on the page only to watch it not change and wondering why pure would pick such specificity only to set the font to sans-serif. Imagine if they'd done that with the other bits? Made the styling so specific that you couldn't easily style on top of it.

Also I believe that Pure doesn't do the whole configure-with-sass thing -- though it can be customized, it's CSS only (https://github.com/yahoo/pure).

I wasn't aware of this shortcoming of Pure (maybe because I haven't used so many custom fonts), but I'm going to be keeping it in mind for the future.

I'm not sure about this one. Got my doubts how well it'll hold up after 4 months of development, under deadlines, with multiple people on the team.

My gut tells me you'll end up not using half the components that are included, and bend over backwards to make the config do what you want it to.

I much rather subscribe to the thinking in http://tachyons.io/ - just enough helper classes to create any layout you desire, and doesn't mess with defaults which means you can extend it to cover all edge cases.

A lot of styles are being applied without you having to set a class. For example, all tables are styled. This can get in the way really fast if you want to do your own styles for a element.

Good point. Styling h1-h6 is good alongside the typography look and feel, but styling <table> without a class is misguided.

Someone else asked this so figured I'd share my response: https://github.com/claviska/shoelace-css/issues/12#issuecomm...

I think you're exactly right about this. The <tag class="tag"> idiom has always annoyed me.

>I've never used a <table> without <table class="table">. It's redundant.

It's not redundant, an element selector has a different specificity than a class selector. Much easier to maintain when Everything Is A Class (especially when paired with BEM, for very flat selectors). It's the reason Bootstrap stopped doing this.

Who cares if it's redundant? Classes are cheap and repeated strings cost you almost nothing after Gzip.

How is it much easier to maintain?

Because when everything is a class (even better, every selector is a single class like BEM strives for) overwriting rules is much easier because they all have the same specificity.

When you mix element selectors with class, ID, and multi-class (.foo.bar) selectors the specificity of each is different, and overwriting them means writing needlessly complicated selectors that are then in turn harder to maintain.

Bootstrap 4 goes as far as eliminating most sibling/child combinators (>, +, etc) because they add specificity. Anyone that's tried to write custom classes for list elements in Bootstrap 3 (.list-inline>li) has experienced this.

http://v4-alpha.getbootstrap.com/migration/#navs

So should we use <h1 class="h1"> and <a class="a">? It's redundant. Shoelace provides a reset + minimal, default, and customizable styles. You can use variables and also modifiers to change those styles. It's not Bootstrap. Different paradigm.

Yes! First I should point out that "reset"-style element selectors are usually ok. But for component CSS classes are king. It's why BS4 styles naked <table> tags with reset styles, but offers the .table class as an option if you want the look and feel of their Table component.

BS has actually has an .h1 class. Eventually a design calls for an <h2> that needs to have the visual appearance of an h1 but for SEO or HTML semantics reasons needs to be an h2.

Maintaining any site of a certain size it spirals into a nightmare quite quickly. Look at how Bootstrap 4 can add a dropdown to a <div> or a <nav>. If your rule was just `nav {}` you wouldn't have that portability, `.dropdown` is clearly superior. On sites of scale modular CSS wins every time.

>It's not Bootstrap. Different paradigm.

Could have fooled me as a lot of the class names and styling are identical. If the m-* and p-* spacing utilities are identical, is it really a different paradigm? BS has (Sass) variables as well.

This is certainly true for components, and Shoelace does style components this way (look at switches and tabs, for example). But for basic elements (non-components) IMO a clean reset is reasonable to expect.

Agreed, it's inconsistent. What if I want a <table> without borders?

Should I expect an <a> with `.text-success` to overwrite `.tab-group a`? Or do I need a new class for `.tab-group .text-success`?

Look at how BS4 broke up Navs from being `.navbar > li > a` to being .navbar, .navbar-item and .navbar-link and think about why they did.

Definitely some good arguments. Nothing is perfect, of course, and I'm always open to feedback like this.

In the meantime, a borderless table could be a modifier: table-borderless (i.e. like table-striped or table-bordered).

Just a different approach than what a lot of folks are used to :)

Agreed. Most of the time, it's great and leads for a cleaner DOM. But it could cause issues. A workaround I use in my own styles is doing something like class="plain", then the table rule would be table:not(.plain).

that's a great trick! thanks for pointing it out.

Personally, if I have to slap a bunch of classes on everything, then something is seriously wrong. HTML should be declarative, and it should be declarative of the content, not necessarily the presentation. Classes should therefore describe what something is, not how it's supposed to be presented. It's CSS' job to describe how it's supposed to be presented.

For that reason, I'll generally choose a <table>...</table> with a default style over having to do <table class="shoelaces-table">...</table> every time.

If you really do want to completely override the table style, it looks like it's just a matter of removing the respective line in https://github.com/claviska/shoelace-css/blob/master/dist/sh... and rebuilding.

Also, most modern browsers have a "developer" mode that shows exactly what CSS rules come from where. If the provided style really is getting in the way, it should be (relatively) easy to figure out what specifically is getting in the way (and then addressing it in your own CSS) instead of just blowing away the whole table style and starting from scratch. Looking at https://github.com/claviska/shoelace-css/blob/master/source/..., it doesn't look like it's doing all that much that'd be likely to conflict with anything in a way that would absolutely necessitate starting from scratch.

>Classes should therefore describe what something is, not how it's supposed to be presented.

That's what we used to think when Semantic CSS was the big buzzword, lots of articles from '08-'11 preached it as the gospel. Turns out when a language is based on customizing presentation, presentation is semantic.

> I had a number of locations that I highlighted with a blue background and rounded corners. I called it `location` since it highlighted each of the locations

> When I opened the online store, I had a list of products and wanted to highlight each product using the same design pattern. Problem was, they weren’t locations. They were products. Being the lazy developer I was, though, I just reused the `location` class and applied it to my products. Clearly not ideal (but hey, it worked)!

> The design function was, of course, to highlight something. That was what I should’ve called it!

https://snook.ca/archives/html_and_css/semantic-css

> Being the lazy developer I was, though, I just reused the `location` class and applied it to my products. Clearly not ideal (but hey, it worked)!

The new problem, though, is that in this case, if the developer wants to eventually use a different style for locations v. products, he'll now have to do the thing he was trying to avoid in the first place and have to create the new style.

If he stuck to letting HTML describe the content and CSS describe the presentation of that content, then when his tastes inevitably change, he'd just need to change one or the other class' styles in his CSS and call it a day.

This is even more relevant if you're using some kind of CSS preprocessor language (or whatever the term would be) like SASS/SCSS or LESS, since you can define that style as a mixin and apply it to each of the styles for specific content classes as you see fit.

Of course, what he did can still be compatible with HTML being content-declarative if you use a class like "important" or "special" or something; that way, you're still describing what the thing is without polluting HTML with presentation details. You can likely even mix that together ("important product" or "important location"), which would then pave the way for having unimportant products/locations.

> Turns out when a language is based on customizing presentation

Except HTML (especially HTML5) is not based on "customizing presentation". HTML is based on describing documents and the contents thereof. There were a few violations of that principle once upon a time (<b>, <i>, <u>, <blink>, <marquee>, etc.), but these are vestigial at worst (and outright eradicated at best), leaving a language that really is meant to declaratively describe content.

CSS is the language that is based on customizing presentation, and always has been (and hopefully always will be, though I can't wait for the day when CSS becomes Turing-complete).

Nope, he just removes the `highlight` class.

>Except HTML (especially HTML5) is not based on "customizing presentation"

Right, I meant CSS, and the HTML classes you use to support it. h1.highlight is just as semantic as h1.

>CSS is the language that is based on customizing presentation

Right, so your CSS should be based on class names that point to their design function. Not "what something is".

I think you have things backwards. CSS is meant to support HTML, not the other way around. Given that, the "CSS" class names (really HTML; classes have uses beyond stylesheets) absolutely should reflect "what something is".

That's a overly broad statement that doesn't reflect the more specific one I made. Your HTML should be rock-solid and use semantic tags, regardless of CSS. The presentational classes you add to it are there, partly, to support your CSS.

>the "CSS" class names absolutely should reflect "what something is"

The example and article above goes to show exactly why that's wrong, if their function is design, they should reflect their design function. This is not theoretical, it is based on practice.

> The presentational classes you add to it are there, partly, to support your CSS.

Again: you have things backwards. Classes are there to describe what an HTML element is supposed to represent. CSS uses these to decide how that thing is to be displayed. JavaScript uses these to decide how that thing is to behave.

> The example and article above goes to show exactly why that's wrong

Except they don't, as I already explained.

> if their function is design, they should reflect their design function.

Yes, and the design function of an HTML element class is to describe what that element is. The fact that CSS is able to make use of them is a side effect of that.

If you really want to abuse HTML semantics, then go ahead; nobody's stopping you. Just don't pretend that it's the correct approach.

> This is not theoretical, it is based on practice

And the standard practice is a tangled mess of <div class="grid grid-3-7 highlight">. Doesn't mean the standard practice is actually good, or that there's no room for improvement.

>CSS uses these to decide how that thing is to be displayed.

I already agreed with you: "they should reflect their design function"

You seem to be conflating semantic classes with presentational ones:

If all your articles have a blue border, maybe it makes sense to have .article have a border property. If your events, articles, and recipes all share the same Card format, it makes better since to keep those styles in .card.

>Except they don't, as I already explained.

You didn't explain; I said just remove the `highlight` class.

>Doesn't mean the standard practice is actually good, or that there's no room for improvement.

Not on its own, but the fact that this arose out of the maintenance nightmare that was "semantic CSS" from 5 years ago explains why it is now a best practice.

Since there's a sprinkling of negative feedback I'll say something positive. Usually when I see something like this pop up it still looks horrible or does something rediculously glitchy instantly on a mobile phone when all I wanted to see was a table or a form and this looked great on a mobile phone. I used skeleton when I hated making CSS pretty in college and I probably would have dropped this in instead. I like to say I'm a minimalist when it comes to CSS and JavaScript but then I have to think about other employees and the garbage they can produce when not contained.

If you're gonna use some random CDN, you should use the integrity attribute to confirm the resource doesn't unexpectedly change.

I'd encourage users to generate their own CSS bundle, so you only pull in whatever styles you need. Myth looks to be unmaintained. You can achieve the same thing with postcss and cssnext [0].

[0] http://cssnext.io

I don't think CSSnext is actively maintained either :/

Also, related to CSSnext — isn't the @apply spec idea dead? Does that make CSSnext “yesterday's vision of tomorrow's CSS” but not what we think the future of CSS will look like now?

Relevant discussions to "@apply":

https://discourse.wicg.io/t/needed-new-champion-for-css-appl...

and the linked http://www.xanthir.com/b4o00 ("Why I Abandoned @apply")

The one time I tried postcss, I was pretty let down by how poorly plugins would interact with eachother. There's definitely a huge benefit to the less/sass model where e.g. variables are a first class concept that everything can appropriately make use of. In the first day of use I hit all sorts of edge cases that couldn't be solved with the sort of pipeline postcss does.

Skeleton.css is a treasure of a tiny css framework. http://getskeleton.com/

Skeleton.css is my current favorite bare bones framework. Its last update on github was 3 years ago though, so I'm checking around to see if there's any similar bare bones framework. I know an update to skeleton.css might not be necessary because everything works, but Shoelace looks promising.

This assumption/worldview is interesting. I recognize myself thinking this way too, but on the face of it, it's a bit weird: if a project does not see continuous updates then we consider it to be outdated and worthless.

This definitely applies more to some things than others, but I think it's worth questioning, too. Does the thing still work? Was it great 3 years ago? Is there a reason it's less great now (other than that it was created 3 years ago)?

FWIW I based my blog theme on Skeleton. I must admit that the 3 year age gave me pause (irrationally, probably) and that it's worked out nicely.

I like http://basscss.com/ - @2kb... and ace if more is needed...http://basscss.com/ace/

The BassCSS site (and ACE site) both contain 100% code samples, but 0 previews of what it looks like!

How are you supposed to look and see what you need or what's available?

Is the BassCSS website itself not a preview of what it looks like?

Good point, this irked me and then I forgot about it...

I make it a point that with every project I do, I never use the same CSS framework. This gives all my products a different look every time. I definitely love simple and unique. I've added this CSS framework as one I will be using. Thanks for sharing!

Sounds like a good and fun plan. You must have tested a few, so which of the not so obvious ones would you recommend?

Hey gorm, there are a few where once you get into them.. you realize they are a bit more complicated to use or just don't suit your needs. I tend to favor CSS the most and stay away from sass and less platforms, even though performance is supposedly better.

I think it really depends on personal preference. I have stayed away from using the larger CSS frameworks. I won't mention them because I don't think it's right to "call out" CSS frameworks when its just my own personal usage of some frameworks over others.

I will mention ones that I have used:

Bootstrap ( http://getbootstrap.com/ )

Semantic UI ( https://semantic-ui.com/ )

Skeleton ( http://getskeleton.com/ )

GetFlakes ( http://getflakes.com )

Milligram ( http://milligram.github.io/ )

HackCSS ( http://hackcss.com/ )

Furtive ( http://furtive.co/ )

BassCSS ( http://basscss.com/ )

w3.css ( https://www.w3schools.com/w3css/ )

Spectre ( https://picturepan2.github.io/spectre/ )

CaiuSS ( http://ionicabizau.github.io/CaiuSS/ )

I moved from using Skeleton to using Spectre with the Pure grid system.

I really like the stuff and fluff Spectre offers: cards, navigation bar, etc.

Pure's grid is what I use exclusively. Simple, easy, and targets the screen sizes I want,

Is the "you don't need a grid" meme true when you take into account support for IE10, Kitkat, IOS9 and Safari 10? Is the polyfill as painless as advertised?

Sure. If you need a grid system feel free to tack one on. There's a link in the docs to the Bootstrap grid system without any extras that works well and is familiar.

I know it's not fully supported across browsers yet but it would be cool, if the new css grid spec were supported.

The point of a library or framework is that I don't need to tack one on. I could spend time writing my own grid system that uses CSS Grid and only supports the latest browsers (without a polyfill) or just use Bootstrap 3 or 4's grid, which has been tested already, supports lots of browsers and requires no effort.

I know this bills itself as a "reset" but when you look at the buttons, text utilities, spacing utilities etc it's far beyond that. In many cases it's just re-using Bootstrap's naming conventions and code. As far as I can tell there's nothing like Bootstrap's theme customization tool for it, so I'd have to do it all by hand.

"If you need a grid system," Not "you need to add your own."

In the near future, grid systems will be more and more obsolete (https://rachelandrew.co.uk/archives/2017/07/01/you-do-not-ne...), and Shoelace is prepared for that. Why add the weight if you don't need it?

That link recommends for a grid system, it just advocates capital 'G' Grid instead of other solutions. There's an entire section where they encourage a framework for working with Grid. I have never worked on a site that doesn't need any concept of a grid.

It's referring to the CSS grid layout, not a grid system such as 960 or Bootstrap's grid system. https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Grid_La...

Correct that is what I said:

>it just advocates capital 'G' Grid instead of other solutions

I also said:

>There's an entire section where they encourage a framework for working with Grid

as a rebuttal to your claim otherwise.

Interesting project. However, the size is still big and it doesn't use flexbox. I'll stick on bulma.io

Big compared to what? Just downloaded 0.5.0 of Bulma and it's at 268KB while Shoelace.css seems to be 32KB

I don't use either, but Bulma appears to be modular.

Bulma is modular, and usually you end up with a ~20kb bundle

https://github.com/claviska/shoelace-css/pull/10

This PR will reduce the size down to 18KB.

Why is not using flexbox a bad thing? It recommends the new CSS Grid instead.

It's too soon to rely on CSS Grid. A lot of people don't (and sometimes can't) use a browser that's less than four months old. Can I Use estimates ~44% of users don't use a browser that supports the current syntax [0]. IE11 will never support the current CSS Grid syntax but does support Flexbox (with some bugs). Edge will support the current CSS Grid syntax but doesn't yet. Older phones and tablets won't support CSS Grid.

[0] http://caniuse.com/#feat=css-grid

It's soon depending on your requirements, but Shoelace is forward thinking and will only become more useful and relevant as CSS Grid adoption rises. As for Edge, it's 100% as of 16.

If you're developing sites for circumstances where you can control what browser clients use, fine. Very few sites developing in that situation.

Edge 16 hasn't been released yet.

I look forward to CSS Grid being widely available and in the meantime degrading gracefully in non-supporting browsers is often viable. My concern is for the users of sites developed by the many people who do not give any thought to how their site performs using anything other than what they personally use.

Irrelevant for a framework that wants to be future-proof and bleeding edge.

Anything widely implemented by browsers is future-proof. Being on the bleeding edge guarantees failure for lots of users.

Relevant, however for a framework to be used in production

I was under the impression this project also depends on CSS variables.

If your target browser can't support CSS Grid it's probably too old to support CSS Variables (CSSS custom properties) anyway.

Chrome, Firefox, and Safari added support for the current CSS Grid syntax in March 2017. CSS Variable support is older. Chrome and Safari have supported CSS Variables since March 2016, Firefox since July 2014. Edge only added support (with bugs) this year and of course IE11 will never support them. Older devices that can't upgrade to iOS 10 or later, like the iPhone 4S, can use CSS Variables.

http://caniuse.com/#feat=css-variables

For those less-than-brand-new browsers, there's at least one polyfill (https://github.com/FremyCompany/css-grid-polyfill).

Not ideal, sure (especially if you're JavaScript-averse, like I am), but it's a start.

For people who want to go smaller than Bulma, I recommend Milligram. It's very well organised and easy to craft in whichever direction you need

http://milligram.io

Very cool domain name! We should all start using `.style` TLD for css frameworks.

This is extremely cool and would definitely move the web forward. I would definitely use that for internal projects where compatibility requirements are not challenging and a proper ui kit is an overkill.

I like to use Spectre,css: https://picturepan2.github.io/spectre/

It has styling for a navbar, panels, and empty states, which is quite neat.

Spectre has a flexbox-based grid, which I ditched in favour of Pure's grid simply because it targets the screen sizes I want: https://purecss.io/grids/

Shoelace,css is interesting. Perhaps I'll choose it for my next project.

For CDNs, if you're running an open-source project then it's best to go with https://www.jsdelivr.com/

It'll automatically handle github or npm packages or any custom setup if you need it.

For example: https://cdn.jsdelivr.net/gh/claviska/shoelace-css@1.0.0-beta...

Also there's unpkg for npm projects.

https://unpkg.com

unpkg.com is nice but it's only really supported by cloudflare (who also back cdnjs and a few others) and just "best-effort" on reliability by 1 person.

jsDelivr has a lot more sponsors and a bigger network.

Thanks for the response. I found out about unpkg because of React.js and there was a discussion a few days ago regarding a "default" CDN here[0] where the author, mjackson, replies. No one mentioned jsdeliver :/

[0]: https://github.com/facebook/react/issues/10294#issuecomment-...

I'm glad to see another viable CSS non-framework and Shoelace looks very promising. I haven't put it through its paces yet, but found a nitpicky thing... why have a "table td" selector? You can't have a td outside of a table anyway. This is top of mind for me because I was just grappling with Bootstrap's lovely specificity nightmare ".table > tbody > tr > td"

Thanks for this. I've been working on something, if not just like this, quite similar as a learning experience - and to have as a starter kit. It isn't and was not going to be as 1/3 complete as yours, but am definitely going to be reading through your code.

Unless they have a rule like: Each commit must reduce the number of lines/size of code or at least keep it exactly the same. What is going to prevent this from becoming the next bootstrap if the project becomes successful?

>"<style> :root { --body-color: white; --body-bg-color: black; --color-primary: #09d; } </style>"

....what? Is this even valid CSS?

Yep!

https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_v...

https://developer.mozilla.org/en-US/docs/Web/CSS/:root

Unfortunately since IE doesn't use it, most of us won't be able to either, as much as we want to :(

The nice thing about Shoelace is that it will only get more relevant as browsers evolve and old ones go away. In the meantime, you can polyfill with Myth.io or cssnext.io.

Neat. It's cool to see how fast browser vendors are moving these days.

I like to use Marx https://github.com/mblode/marx

Just what I wanted, been looking at bulma/flexbox and bootstap which are great but not small/clean/simple enough - thanks!

Good to see minimal templates/frameworks. Most of them don't have many demos, here is one with 28 – https://radogado.github.io/natuive/#showcase

sakura? https://github.com/oxalorg/sakura

Thanks for nearly crashing my server this morning xD

If you like Shoelace.css, would you vote it up on Product Hunt? https://www.producthunt.com/posts/shoelace-css

Thanks :)

Reply on news.ycombinator.com