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.
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.
> 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).
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.
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.
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.
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."
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 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.
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.
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.
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:
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.
>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.
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.
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.
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.
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!
> 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).
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.
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).
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].
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.
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?
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 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!
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.
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.
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.
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 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.
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.
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.
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.
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.
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 :/
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?
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.
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!