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.
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.
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.
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.
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.
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).
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!
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.
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!
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.
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.
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.
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.
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.
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!
> 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.
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.
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).
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.)
@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.
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.
94 comments
[ 1.6 ms ] story [ 148 ms ] threadOk, it got me hook on the just use the standard tags concept, but the above quote implies, this shouldn’t go into production.
Is that accurate?
It's more to help you launch quickly so you can test an idea, like a hackathon, side project or MVP.
> - Andy Brewer, Author of MVP.css
Haha, that sold me.
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.
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.
(this is a jest of course, you can have a fast and pleasing website, but pure HTML only gives one)
https://developers.google.com/speed/pagespeed/insights/?url=...
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.
[0]: https://andybrewer.github.io/mvp/
I wanted to solve a similar problem when creating sakura.css [0], but I decided to not implement it and keep it even simpler.
[0]: https://github.com/oxalorg/sakura
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).
[0]: https://getbootstrap.com/docs/4.4/components/alerts/
[1]: https://kognise.github.io/water.css/
I usually go for water.css [0] which had been posted in Show HN here earlier [1].
But the use of <section> and <asides> really helps in placing elements one beside another.
Will try this for sure.
[0]: https://kognise.github.io/water.css/
[1]: https://news.ycombinator.com/item?id=19593866
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/sa...
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:
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>.
Almost forgot the link: https://www.w3.org/TR/html401/struct/text.html#h-9.2.1
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.
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.
[0]: linked in my original post
[1]: https://drafts.csswg.org/css2/sample.html
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’ve filed https://github.com/andybrewer/mvp/issues/1 about this now.)
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.
Do you have a go-to reference for tags and their meaning?
This blog post is actually a great intro to rust too :)
One example is this "hidden" gem. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ma...
Thank you! I'll take a look today.
And pull requests are always welcome.
Maybe a better RTL support could be added as an extension in later versions.
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.
Now that of course depends heavily on what you consider to be minimally viable but there's generally not an expectation of professional design work.
If you're the kind of person who reached for bootstrap or material UI or other not semantic, boilerplate frameworks this might be appealing.
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!
> cross _visual_ 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.
Also for reference, behold W3C Core Styles (since 1997): https://www.w3.org/StyleSheets/Core/
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.
[1] @dohliam's excellent "Drop-in Minimal CSS" collection mentioned here https://news.ycombinator.com/item?id=22683281
[1]: https://www.w3.org/StyleSheets/Core/preview.html
https://developer.mozilla.org/en-US/docs/Web/CSS/Alternative... https://developer.mozilla.org/samples/cssref/altstyles/index...
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.
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.)
(Hint: if you use the bookmarklet, you can quickly preview how MVP.css looks when applied to any HTML page.)
[0]: https://github.com/dohliam/dropin-minimal-css [1]: https://dohliam.github.io/dropin-minimal-css/?mvp
https://wmeredith.github.io/MercuryCSS/
EDIT: Ha! I should have checked first. It was added in Feb 2018 :)
[0]: https://github.com/dohliam/dropin-minimal-css/blob/gh-pages/...
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.
Two things I think could be improved:
1. You should consider using a CDN instead of GitHub pages to host the stylesheet on the demo template. Here is an example [0].
2. In the future it might be cool to explore the `prefers-color-scheme` media query so pages are responsive to color schemes too [1].
[0] https://cdn.jsdelivr.net/gh/andybrewer/mvp/mvp.css
[1] https://developer.mozilla.org/en-US/docs/Web/CSS/@media/pref...
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.
http://prntscr.com/rml1xf
Lightshot what you're seeing, maybe i'm crazy.