It never fails to amaze me that I've been doing this for a decade, and I keep learning things that seem basic at first glance. I have literally never heard of this at all.
Right? All of the starting from scratch I've done! All of the projects I've put off because style is one of the first things I've have to decide on (e.g. blogs).
Classics right there! We've got a long linage of this kinda stuff now from browser resets to full stylesheets to well specified content just for testing any of the above on. I love it! Simple. Consistent. And now more powerful than ever with the help of variables.
Might be fun to take all the w3 core styles rebuild them with modern CSS features. Maybe add some HTML5 elements to the test docs as well.
I remember, when Firefox still had a menu bar, you could actually select a different named stylesheet from within the browser! It was in the edit menu.
Firefox (on Windows) never lost the menu bar: if you press F10 or Alt (or Alt+some letter from menu) it will pop from top.
Style switcher you are referring to is located in View > Page Style, in English localization quickly accessible by Alt+V,Y. You can choose from "No style" (effectively disabling all author level styles) and "Basic Page Style" (enabled author styles). If you are lucky and stumble upon page with linked alternate style, you can still switch to it.
The last detail this nice feature lacks to this day and that presumably doomed it to current obsolescence is that your choice does not persist during navigation and even page reloads. Never understood why this native switcher stuck half way to be usable. Back in day alternative style sheets were (at least a bit) "hype" author had to recede to JavaScript solutions to provide persistence, so it lost much of its charm.
Speaking of ancient CSS features that looked overwhelmingly promising but never caught up as successfully as they deserved, it is probably worth mentioning User Styles. CSS was initially meant as a "dialogue" among User Agent, User, and content Author, with styles as a tool to express individual preferences. User agent sets some "browser defaults", Author sets their styles and User can participate with their own sets of preferences that can be "weak" like those defaults or even stronger than author's. It is the (or at least mayor part of) "THE 'C' for 'Cascade' in CSS".
Browsers to this days are required by specs to give user a way to participate in the cascade, but it never wasn't easy or even pleasant experience - it mostly involved editing some magic file and restarting browser (for "native" user styles) or using some extension, what feels like a poor excuse to not support it natively and mostly is implemented an a way that does not comply with specs anyway - because it mostly just spams author origin level and does not create user origin level. (I miss the old days when web was young and "userstyles" and "userscripts" seemed like natural development of tech what every user will use daily.)
This is a great idea but the sentence on the demo / example page really irks me, "cross design off your list and get back to working on the hard stuff"
I think I know what you mean but I can't help but feel like that sentence is denigrating the work of an entire discipline that _also_ works on "hard stuff" like figuring out how to address user need with usable interfaces.
Author here. I'm a designer and it wasn't meant to be denigrating, but more of a statement that launching is hard and that it's OK to be embarrassed by the design of your MVP so you should ideally put very little time into it and more time on the core value of your product.
I can see how that doesn't come across the way I worded it though. I'll try to wordsmith that line. Thanks for the feedback!
Exactly. Every time I have to do UI work for personal projects (I almost never do it for pro projects), they look like a-ess-ess. Design is very hard. I try to copy the looks of things I like and I get the rough feel of it, but the details, man. The detail and the subtle things. That's where the pros who know how to do UI earn their worth.
> cross design off your list and get back to working on the hard stuff
That sentence made me consider Poe's Law for a while, considering the weird fruits HustleSpeak is bearing quite often. Going by the author's bio, I'm most likely wrong.
The markup for the callout buttons/links on the example page [0] is just <a href="#"><em>Button text</em></a> (for outlined) and <a href="#"><strong>Button text</strong></a> (for filled). That's a pretty creative solution that I definitely haven't seen before.
Giving opinionated styles to unclassed HTML elements is definitely not the right fit for every website. But, given this project's goal of being a minimalist, quick-start stylesheet that requires no classes, I think this use of `a em` and `a strong` selectors to create button-y links is pretty ingenious.
I think it undermines the semanticity of the markup though. A hyperlink isn't supposed to render as a button, or vice versa. If this was just a bolded word in normal inline link text, the button presentation would be very unwelcome.
Just thinking the same thing. Got A good laugh out of that!
However, it seriously looks like this could be pretty useful. I’m lazy, and the idea of just writing some semantic markup and have it look great out of the box is very appealing. Especially for a random toy project, where I want to put as little effort into the front end design as possible.
@awb Your approach is smart and the HTML is a breeze to read. What a fresh change from the class-itis of frameworks like Tailwind!
Although the targeting is MVPs as you also mention on the site, it could possibly evolve to a very powerful HTML/CSS framework, far more than setting up a MVP :)
What I'd like to throw in as an idea is that in a future v2 of mvp.css you could consider using custom HTML tags to allow for inserting new tags in the mix for better positioning/layout, typography and more.
Again, this is just an idea. If anyone's to learn 200 CSS classes to use something like Tailwind (et al), they might as well learn custom (prefixed) HTML tags that potentially make more sense.
And as for search engines, technically speaking it doesn't matter to them if you use custom HTML. SEO-wise, if one wants to be Google-friendly, it's either way preferable to use structured data over semantic HTML.
> you could consider using custom HTML tags to allow for inserting new tags in the mix for better positioning/layout, typography and more.
That might work for another stylesheet project, but I'm trying to keep MVP.css as "add and forget" as possible without having to learn anything unique.
I suggest giving a link to the rendered version of the quickstart sheet or some other "at a glance" list of the rendered elements.
While I appreciate the dogfooding and clever presentation style, it's adding some unnecessary steps when I want to see how you chose to style specific elements.
Regardless of how you feel about Bootstrap, I think their documentation[0] does this well. water.css[1] linked in another reply here does it even better (admittedly it's less complex).
Wow, over a decade doing frontend and TIL: <samp>, used to enclose inline text which represents sample (or quoted) output from a computer program. Its contents are typically rendered using the browser's default monospaced font.
The treatment of <samp> in mvp.css is incorrect. It’s treating <code> as inline monospace, <samp> as block monospace, and completely ignoring <pre>, which is actually block monospace (with no defined semantics). Rather, <code> and <samp> should both be inline, and placed inside <pre> for block usage. This matters because it’ll mess things up if the stylesheet doesn’t load, as your blocks of code won’t be formatted properly.
https://chrismorgan.info/blog/rust-fizzbuzz/ demonstrates use of <pre><code>, <pre><samp> and <code>, though not just <samp> or <pre>. (I use bare <pre> elsewhere on my site, but haven’t had cause to use bare <samp> yet.) What can I say? I’m a snob. Also there are subtle differences in style between the two. (I have <samp> be truly monospaced, because terminal output is more typically visually aligned, but <code> be only mostly monospaced, because it’s seldom visually aligned and I find Triplicate’s Poly variant generally nicer for code reading.)
Also potentially of interest to you: <output>. Plenty of other interesting semantic tags to use or not, as well. I like to use <var> carefully.
I'm guessing because they were inconsistently supported by browsers, because me too!
I was even more surprised to see it in the HTML 4.01 spec, but if you look it makes more sense. I'll quote every mention of it here but the table of contents line:
9.2.1 Phrase elements: EM, STRONG, DFN, CODE, SAMP, KBD, VAR, CITE, ABBR, and ACRONYM
<!ENTITY % phrase "EM | STRONG | DFN | CODE |
SAMP | KBD | VAR | CITE | ABBR | ACRONYM" >
SAMP:
Designates sample output from programs, scripts, etc.
CODE is equally well defined -- neither even mention monospace!
> The other phrase elements have particular significance in technical documents
HTML never ceases to amaze me. This also explains why I still prefer <pre> even though I can never remember why it's <pre> and not <code>.
<pre> is for preformatted text such that whitespace characters in it including tabs are preserved, whereas it's collapsed/whitespace-normalized at other places. <code> is for semantically denoting a span or block as "programming language code", which might or might not have whitespace characters preserved. You typically use <code><pre>...</pre></code> for a code block, and just <code>...</code> for an inline code span.
Edit: props for citing the actual HTML 4.01 SGML DTD!
I pointed out the irony of not giving an example|intended use in a technical document because if a line or two like that was in the HTML 4.01 specification I probably would have written more-correct HTML since sometime in the early-mid ~2000s. I guess I'm glad my reading comprehension has improved but it also shows pretty clearly why it's the old spec.
But how relevant is html 4.01 to HTML5 (which is presumably what ppl are authoring these days)? If I'm not mistaken, even Google amp is considered valid HTML5?
HTML 4.01 is relevant to HTML5 in that it was the direct precursor to HTML5.
Put another way, when I learned a lot of the HTML we all use every day there was no HTML5.
By agreeing with the original reply and looking into why, I saw that it was defined in a specification I have read several times (HTML 4.01[0]). I knew CODE being vague was a thing and was part of why I didn't use it much, so seeing SAMP was similar explained why it would have slipped my mind or I totally glossed over it.
Another reply pointed out that <pre> is the block-level styling element I want and that <code> or <samp> make more semantic sense inline and nested. This does make sense to me and I thought it was funny that in a technical document like an HTML specification they would note the importance of the elements in technical documents but not give any example or further explanation.
Yet another reply corrected me again, that SAMP is defined with a monospace font-family in the CSS2 specification[1]! Now I can complete why I used to be wrong and now am not: <pre> always worked by default to get a monospace font and preserve literal whitespace in rendering. <samp> may have, I'd be interested to know but not interested enough to do research into old browsers' specific rendering. The entire <samp> thing was effectively unknown to me. <code>, while similarly defined in HTML, did not have that default font set and thus would not work in a spec-compliant browser by default unless they extended the specification in that browser. That is why in my head I used to prefer <pre> over <code> and that was all; and also why I enjoy posting in communities like these!
> If I'm not mistaken, even Google amp is considered valid HTML5?
So far as I know (I haven't kept up with this level of detail in AMP) it is entirely implemented via some subset of HTML/JS/CSS: presumably any Google AMP would then include valid HTML5.
Thank you for pointing that out! <samp> does indeed have a default font-family of monospace there.
And <code> isn't defined at all! I'm not disputing this is all internally consistent or that I used to write what I'm now learning is incorrect HTML, this completely explains what I used to know about the tags and I love it:
I didn't know or forgot <samp> was a thing for whatever reason. I know HTML5 is big and I don't know it all, HTML4 is much less so and I usually do.
I always prefer <pre> when I'm writing HTML to show intentionally-monospace blocks like code or code output because <code> is inconsistent, importantly for me it meant sometimes it didn't|doesn't work. Here I now know why: The CSS2 stylesheet doesn't define anything for <code>!
Other replies have described how it makes more literal/semantic sense to nest these things together and I agree completely; many times I am surprised at how elegant these old specifications are, if indirectly.
I agree, looks like I misread it -- then some of this is still a mystery that's probably left to how things like Netscape and Internet Explorer used to work. Too bad!
Remember the days when you simply had to add bootstrap to your website to make it look great?
Now I feel like anytime I start a new project and want to add some simple, light styling, it is just impossible to find anything. bootstrap is pretty convoluted and I can't figure out which bootstrap lib to use with react, and everything else seems to be built for the next facebook.
I just want something simple with some form elements and layouts pre designed and easy to modify.
Half the reason why most websites look awful is because somebody tried to be too clever and missed an edge case. Basic HTML renders fine in most cases.
So cool. I hate how I have to add so much markup to my basic html just to get bulma looking good, I don't know what I'm doing as a designer but I have an idea of the layout I want. This is going to save me a lot of time scrolling through bulma docs looking for whatever weird combination of divs and classes I need to make a 'card' or a good looking button.
I find this project wonderful. Front-end has become sophisticated and the learning curve to someone like me, who does only backend projects, is too steep to have a decent knowledge.
Nevertheless, many times I need a front-end facade for my ideas and this seems to do the trick.
Very glad to see another classless CSS stylesheet appeared! It’d be great if there is a rendered sample of each element next to the tag in the listing, and also some sample full pages with rendered results.
Maybe a better RTL support could be added as an extension in later versions.
You can definitely put it into production. It's just not a "pixel-perfect, cross-browser, fully tested on all devices back to iPhone 4" kind of stylesheet. It's a "looks decent with no effort" kind of stylesheet.
It's more to help you launch quickly so you can test an idea, like a hackathon, side project or MVP.
I don't understand why people use css frameworks. This stylesheet will make your site look like this other site. Cool, but what if I want to make my site look different than other sites? Then I have to override a lot of over specific selectors and make my own CSS even harder to read/write.
This is for when "shit I just want my website to look good like those other websites I see on the web but I don't know how or don't want to put in too much effort"
CSS frameworks—I hear—are mainly aimed at individuals or small teams with a proof of concept, demos or other quick short lived projects that don’t need custom designs, or for small teams that don’t have a skilled designer and just need the thing to look well enough.
That said I have had to defend non-framework CSS to other front end developers in the wild, who insist that material design, bootstrap or whatever is worth writing all this CSS your self.
Immediately starred(even if I never use it)!!! I love that more and more people are making these simplistic and minimalistic frontend stylesheets and steering clear of the whole "REACT EVERYTHING! HTML BAD CSS BAD!" mentality and those 40mb javascript files! Thank you!
maybe i'm missing something here, but I see 2 fails here.
1. i'm using firefox and the select dropdown isn't styled so it looks like the plain old unstyled select.
2. i don't see anywhere on the page where it shows all of the elements and what they will look like as an example, like bootstrap does. that example form at the bottom doesn't cut it as far as i'm concerned.
so call me a jerk... i failing to see why would i use this instead of something like bootstrap or tailwinds. where exactly does this "fit". is this something i use in adjacent to other css framework or on it's own. i'm very confused.
Also for reference, behold W3C Core Styles (since 1997): https://www.w3.org/StyleSheets/Core/