> No class names, no frameworks, just semantic HTML and you're done.
The trouble with this claim is that MVP.css abuses semantic HTML badly, using completely inappropriate elements all over the place (e.g. aside for cards, and b/strong/i/em inside links to make them look like buttons of various kinds), and the author has declined to change these things despite acknowledging that they’re wrong.
> the author has declined to change these things despite acknowledging that they’re wrong
I mean, if they already have projects running with this, it makes sense. If I learned one thing in my professional life is that while being a perfectionist already is not the best way to approach the vast majority of the problems, it's especially true when it comes to HTML.
Also, I hate to be that guy, but seriously, this thing seems like one of the easiest open source projects to get into, so why not fork?
I enjoy reviewing things like this and pointing out the problems in the hopes of improving them, or at least teaching others who will hear—when I post detailed reviews, I normally get positive reviews on the reviews (whether from the original author or from others), and feel I have helped people. But I don’t actually use things like this; I’m far too strongly opinionated and will do my own thing every time. (And for anyone else thinking of forking something like this: there are already a very large number of things like this, consider whether it’s worth the bother, maybe just find another one that has a different set of problems. :-) )
The problem is that that (bad) thing, is the core idea of their project. So from their view you're basically saying "Yo, your project sucks. Make a better one."...
I'd say it's way more nuanced than that. I appreciate the comment since I gained knowledge on both HTML and about this project's particular usage of it. If a project is based on an unconventional idea and this is undisclosed it's nice for everyone to point this out, it doesn't have to be interpreted as an attack.
On the one hand, in the first instance it seems a lot easier to remember the syntax.
But thinking about it for longer, I realise that actually if I'm having to learn to put an <aside> inside a <section> for a card, but an <aside> inside an <article> becomes a callout, then perhaps it's not quite as intuitive as it seems, and if I have the mental overhead of remembering all that, perhaps I might be saving myself more energy just to write a CSS class.
One framework I've used recently which floats in between these two is Bonsai.css. It does quite a lot 'out-of-the-box' in terms of minimising boilerplate and basic styling, and uses CSS variables as a shorthand for style properties. It's also a bit of mental overhead, but you can of course just write inline styles if you can't be bothered to learn the shorthand.
I’d honestly prefer <card> to <aside>. <aside> is very non-obvious, and is semantically wrong in a way that will cause (very) mild accessibility trouble. <card> is nominally invalid HTML (a reserved element name, basically), but will cause no accessibility trouble, and it’s rather unlikely that it’ll break in any way in the future. You could resolve the invalidity by spelling it <mvp-card> (at the cost of being an inline element in the absence of stylesheets). But frankly <div class=card> is just all-round more sane.
I thought about this when I was writing my comment, my mind wandered down the track of:
'hey, maybe you could create a web component <card>? That would be cool. It's a shame you can't create web components without JS, wouldn't it be great just to have an HTML only syntax for creating a web component, like <template tagname="card"> or something?'
Then I realised that I still have to learn something else to write a 'card', so I might as well just keep it simple and use div.card. If I want anything more complex, I can use one of the many component frameworks that exist.
No need for JavaScript unless you want your element to have additional behaviour attached to it. <mvc-card></mvc-card> would be perfectly valid with no JavaScript required. But yeah, there’s not generally particular value in doing it that way rather than a div or span with a class attribute.
I would concede that the use of ‘a strong’, ‘section aside’, etc. does require some learning and the styling is perhaps unique, but I don’t think it’s invalid in any way.
> The <aside> HTML element represents a portion of a document whose content is only indirectly related to the document's main content. Asides are frequently presented as sidebars or call-out boxes.
I think cards are basically “call-out boxes”.
But at the end of the day, this style sheet doesn’t have to be for everyone and it’s really designed for someone who’s rapid prototyping.
That said, I do think buttons and cards are important to most web page layouts so if there’s a better semantic way to codify those, I’m open to pull requests.
One thing that I think is very difficult to do in your position is to determine what benefits others and what does not. However, I think you're wrong here to be trying to defend this as 'correct', because it's not—or at least the spec doesn't support what you're doing. You should be proudly saying 'this is what I can build out of the most basic building blocks available in HTML. It's as semantic as possible, but there are some tweaks needed to enable particular high value features'.
Ultimately a lot of the modern web trends don't fit perfectly into the HTML5 syntax, and cards particularly are one. They're not 'articles' because they're not 'complete, or self-contained, composition[s]'. They're not 'asides' because they're not 'tangentially related' - although callout boxes I agree are. They could potentially be considered 'sections' although I'm not sure you would list individual cards explicitly in a document's outline - plus from a technical perspective how do you differentiate a 'section' card from any other type of section.
I think it's important to understand that there's no way to make everyone happy here, and there simply isn't a good semantic way to create cards using the tags that exist. I think in most cases, cards are a presentation of an item of sorts (perhaps even a 'list' item?) but HTML doesn't have a simple 'item' tag, and the spec warns that although headings are valid inside li tags, it's probably not correct semantically.
Key is, there will be some people this helps. There will be some it doesn't. For every (completely valid) concern that people (including myself) are raising, the only fix is to add more complexity, which makes it less easy to use.
FWIW, I think you've done a great job building something usable and useful, thank you.
> The <aside> HTML element represents a portion of a document whose content is only indirectly related to the document's main content.
There's nothing in the spec saying how that tangentially-related content must be displayed. It simply says it's frequently a sidebar or call-out box.
So, if a user writes semantically correct HTML and writes tangentially related content using an `<aside>` tag, MVP.css then chooses to render that visually as a "card".
So, I think in this respect, it's up to the user to use the tag semantically correct or not. Or am I missing something?
I think it's also semantic HTML to have more than one `<aside>`, unless I missed that rule somewhere as well.
For example, in the "Little Mermaid" example (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/as...) the fact "The movie earned $87 million during its initial release." is written inside an `<aside>`. But wouldn't it also be valid to include a 2nd fact as a 2nd `<aside>` and then have those visually represented as cards or call outs?
Fair point that it’s dependent on usage, but I think most uses of cards are not tangential - the cards themselves are the core content (e.g. a pricing table, feature list, real estate/product listing, etc.).
I think you’re right, there’s a case that for some situations where a card contains tangentially related information, <aside> is correct, but I think the majority of cases, it won’t fit.
I don’t think either of those uses could really be described as “tangential” to the main page content (perhaps you could argue the toss for the form with suggestions).
* I think everything regarding the `aside` elements has already been said in the GitHub issue: It's context specific and you can't determine in advance if a certain (card) element is part of the main content or not. Therefore, `aside` should only be used if needed. (The top three cards on the MVP.css homepage definitely are part of the main content for example.)
* Your `a i` and `a strong` solutions are pretty unusual and they show the limit of what is possible using a classless CSS. I would have preferred staying even more minimalist and simply pass on button-like links.
I'm not trying to be a dick about it since it's your personal project and I am not forced to use it – but I am not sure why the framework had to be classless and usable for a MVP all at once. I absolutely love classless CSS for simple/personal websites, but I associate MVPs (products) and rapid prototyping with more extensive and interactive interfaces than the typical text-based onepager.
> you can't determine in advance if a certain (card) element is part of the main content or not. Therefore, `aside` should only be used if needed
Good point, I agree.
> Your `a i` and `a strong` solutions are pretty unusual and they show the limit of what is possible using a classless CSS
100% agree. This was a loose interpretation of semantic HTML IMO.
> I would have preferred staying even more minimalist and simply pass on button-like links.
Sure, from a purist perspective, but from a productivity one, the vast majority of product / service sites have a button somewhere, so I thought it was important to include it even if I had to abandon a strict-constructionist view of semantic HTML and go with a more progressive, interpretative one.
I agree. I think it's a strong candidate to implement this in a v2 if that happens down the road.
> I associate MVPs (products) and rapid prototyping with more extensive and interactive interfaces than the typical text-based onepager
Sure, modern day MVPs look far more polished and interactive, but this was kind of in response to that. I was working through YC's Startup School (https://www.startupschool.org/) at the time and they were pushing the definition of an MVP as something that just barely works so you can test out a specific idea. So, while it won't work for an AirTable MVP, I think it should work for an API MVP, or most single-form MVPs. Beyond that, I agree it might not be a great fit for the project.
cards are better represented as <article> elements: independent blips of content that are regular and largely self-contained (in a given section). an aside is literally something that's not part of the regular flow of information. it's not included in reader mode for instance.
especially with rapid prototyping, you don't want your stylesheet dictating quirky usage of html.
Besides a few accessibility things to be aware of, like clicks and tabs for example.
The rest has zero impact on the browser and user experience. It was a nice idea but never got off the ground precisely because most of them hardly had any real difference from a simple div.
I never knew why semantic HTML stuck so closely to the print metaphor and didn’t better reflect how websites are used. It always seemed to involve shoehorning an interactive website design into print concepts, so losing much of the meaning anyway.
It is not true that they do have hardly any impact on accessibility. But if you want to go that way: MVP.css uses `<label>` instead of `<fieldset>`/`<legend>`. See https://www.w3.org/TR/WCAG20-TECHS/H71.html.
Nah they don't. I've had accessibility tests done and checks by Foundations for government. Even they don't care about it, it's all about: contrast, letter size, tabs and titles/labels.
I'm not sure why you are so insistent. Of course it is important for accessibility. I have also worked for government sites, conducted a11y tests myself, and worked with independent auditors from Canada and Germany. Semantic HTML is a very basic but critical part. See https://www.w3.org/WAI/WCAG21/Understanding/info-and-relatio....
At the same time if you just take your MVP and copy paste it to production and don't fix it... that's the problem, not what they did for an MVP.
Personally, if I'm hacking out an MVP for something and someone wants to get nit picky ... I'm going to be kinda unhappy. It's an MVP there's going to be A TON to nit pick about, that's the nature of it.
The problem of using semantic elements incorrectly remains. The front page states "just semantic HTML and you're done" which is wrong.
I know that it is called "MVP", but firstly the term viability can mean different things and secondly there's no indication that the markup is implemented incorrectly. I love to check out example/demo pages from CSS frameworks and it's not uncommon to see glaring semantic errors in the HTML. People just copy everything that is presented to them and you should make sure to give them a good introduction.
This reminds me of a css switcher project I found on GitHub [1] while I was messing around with classless style sheets.
Makes it just so easy to switch and select. Embed in your html page, select an item from the drop down and see what it does to the page, when you’re happy, remove ! Simple. Genius. Wonder why I never thought of it.
Of course! I took this idea from the milligram project [1], but if you feel like it is a downside I am open to hearing your arguments. Feel free to open an issue [2] so we can discuss it.
Tacit is most appealing to me to whip something together. Hits the best look/byte ratio for me and seems to be hardly an abuse of HTML at a glance.
I normally use actual semantic HTML with classes as styling hints and minimal CSS/JS. But I don't make anything "real", am definitely not a front-end guy, and my stuff is probably ugly to most.
I remember loving a similar stylesheet for my personal blog, but ended choosing Tachyons because I wanted to have images alongside text(images aligned left, center right alongside text) that I couldn’t figure out how to do with such minimal css..
if anybody knows how, I’d be grateful!
No, it didn’t. The images always showed up big and occupied the whole width of the div. Not sure what I missed. I will have to try to do it again later today.
That’s not a "pro tip"; that’s a very bad advice: you should always use versioned URLs. What if I find this project cool; add this URL in my HTML; and then the author changes things in ways I don’t like? It’ll break my website. If I used something like `https://unpkg.com/mvp/v2.3.45/mvp.css` I’d be sure it wouldn’t happen.
True, but given the use case I think it's fine. Another commenter pointed out that they abuse HTML semantic elements which also isn't great. But if you're using this for the intended purpose (building an MVP app), all those things really don't matter. Sure the next version might break things, but by then you would have in all likelyhood moved on.
I use this framework a ton and it's great for things like building an API where you need an absolutely minimal frontend. For things like this I'm already writing minimal CSS, this just lets me slap a one liner in the head and make the frontend look marginally nicer. Issues like the version and semantics are not a concern because the "point" is to build the API and the frontend will get tossed (and yes I realize I can use Postman/Hoppscotch, i use those as well).
Embedding external styles may also violate users privacy and may not be okay with the European GDPR. To be on the safe side, you should only load external resources after the user agreed in a consent dialog. Or just host them on your web server!
This is amazing! Exactly what I was looking for when I was building my MVP, just a responsive, standard looking stylesheet I could plug-in.
All the supposedly JS-free CSS frameworks use JS for their most basic components.
I bought a template on one of those template sites but it needed like 20 JS scripts just to display the landing page.
I thought of trying the Zengarden stylesheets but they didn't cover the components I needed for a saas website, and they were also way too characterful.
I'm past the MVP stage but I would have paid for this if I had seen it 6 months ago, at least the price of a template: 20-50$.
Having such a stylesheet not automatically work in dark mode defeats the purpose. It says "no classes" but then it demands that you add an invalid attribute on your HTML to trigger it. OK, that's a no for me.
Dark mode is a really cool CSS feature, but it requires a level of maintenance that goes above and beyond an MVP IMO, so I decided to remove support for it.
I had it included originally, but it meant 2x the QA and 2x the icons in some cases.
If it’s important to you there are other libraries that might be a better fit.
I love mvp.css This made shipping my side project so much easier. I like that it’s opinionated and gets you going fast. You’re not really spending time picking colors, and you can focus on the content.
I have used it, and like it. But! It is no easier than a class based CSS framework. Instead of guess the classname you play guess the element name. And by attaching style to elements 1-1 you can end up with something less semantic than using a regular CSS framework or a utility based CSS framework.
On the demo page [1], the <main> element starts with an <hr>. That doesn’t seem right. The <hr> element is meant for section breaks (where there is content both before and after the <hr> element), not for decorative horizontal lines.
True, but soooo minor. The element has no impact on the document outline, and many sites use it decoratively today.
If we're really being pedantic, all uses of <hr> elements on that page are contrary to the spec's desires.
> The hr element represents a paragraph-level thematic break, e.g. a scene change in a story
> There is no need for an hr element between the sections themselves, since the `section` elements and the `h1` elements imply thematic changes themselves
One pro-tip though — I found that using unpkg slowed down the page a ton sometimes. I serve the file myself and it's been much faster. YMMV but thought y'all should know just in case.
> Out of the box CSS styling for HTML elements. No class names, no framework to learn.
Well it’s still a framework. A light one, but still a framework. You still have to learn how it works. For example, `<section><aside>` is interpreted as a card and `<sup>` is a "notification bubble". The worst part is you have no way of disabling this behavior: `42<sup>2</sup>` will always show a "bubble" with `2` next to `42`. What’s "semantic" in that?
Short question: Does anyone know about any performance issues using semantic vs class-based css?
I ask, because in the early days of css we also tried to use semantic style and had strange rendering issues on huge data tables and everytime, when the page had a lot of content. After trying a few things we came to the conclusion, that (especially but not only) IE had huge performance issues with semantic style. After switching to classes, everything worked fine. It technically made no sense, but since we did not change anything else, we came to the conclusion, that class based is faster than semantic...
You’re referring to “tag selectors” vs “class selectors”
Engines are now good enough you don’t really have to worry about selector performance unless you’re using ridiculously complex selectors, and even then the least efficient part is actually the layout calculation and painting.
This site is super simple and is super laggy on Safari Mac because they use awkward effects and animated gradient backgrounds, for example: https://colorjs.io/
I came across this blog post which talks against styling HTML tags and using classes for performance reasons and scalability. I'm not sure if the impact is noticeable on web browsers, I'd love to see an objective comparison.
Just found the stylesheet for my website's redesign, thank you :)
I'm surprised that Tacit is missing from the list though. When it comes to modern design using classless CSS my order of preference is normally water.css, tacit, and then MVP.css. It just looks great and uses the HTML5 semantic elements to their full potential.
I always use this if I need to quickly make some structured info visible on the web. Works on mobile, works in dark mode, looks inoffensive and professional and is super small.
The problem with some of these is that they are terrible for accessibility. There is extremely low contrast, missing focus styling, invalid non-semantic HTML, ... Having a list of good examples only would be much more interesting than a list of everything.
I'd also say https://classless.de should be on the list - I use it quite heavily and really like it, as well as being able to theme it more easily too!
I enjoy finding stuff like this, and kudos to the author for making it. I remember hand-writing HTML going back to using BBedit in 1995 and just enjoy the simplicity of semantic html elements. Sometimes, less is more.
.
I spend more of my time doing back-end work and some ops type work.
Later on (early 2000s) obviously I'd have to use tables for laying stuff out, then relying on the good work of Jeff Zeldman and the like to beef up CSS knowledge, then finally using stuff like Bootstrap and Tailwind.
Most of all it's exciting to see that HTML supports more and more input functionality for which people used javascript and native apps. What took us so long
Not putting your page header and footer inside the <main> element is a giant pain in the ass. Both ways are semantically correct and accessible, but putting them inside the main gives you more flexibility to control your page margins/padding for various display sizes and lets you set up a grid for the whole page.
But putting the `<header>` and `<footer>` inside the `<main>` element is not semantically correct. If it would be, you wouldn't need `<main>`. That's exactly why there's a very basic limit to classless CSS frameworks.
That's incorrect. You can have a header and footer for each sectioning element/sectioning root (eg article) in your doc [1] (but you can't have a main element in header or footer content [2]).
In general, I don't think "HTML semantics" are really as stringent as assumed by some commenters. After all, HTML was just intended as a vocabulary for casual academic publishing, but is of course abused for text that could be much, much more simply and adequately described using other, more targeted or customized SGML vocabularies rather than HTML.
I was referring to the global page header/footer you were talking about, should've made that more clear. Obviously you are allowed to use multiple `<header>` and `<footer>` elements on the same page.
While it is true that HTML semantics aren't as stringent as often assumed, there certainly are more or less universally accepted best practices. They depend on the complexity of the site itself. (It may also be unclear what a "page header" actually is. It could contain your logo and navigation, but the `<h1>` should rather be in the `<main>` element.)
So this is what my most basic structure inside the `<body>` would look like:
<header></header>
<main></main>
<footer></footer>
If you're doing this with the global page header/footer, there would be no reason to use `<main>` at all:
Also, I can't really reproduce your initial issue regarding the flexibility of page spacing. You are pretty limited when using classless CSS, but where's the problem using the body selector for that?
It is hard to take any stylesheet seriously when their website doesn't even properly use meta color scheme tags. Also, their examples are like the opposite of normal element approaches to what you're trying to accomplish.
<blockquote><footer> for quote attribution? How does that even make sense?
I think blockquote attribution recommendations are perhaps the least stable part of the HTML spec I can think of. There have been at least three, I think at least four, completely different and mostly mutually-incompatible recommendations in the past decade. `blockquote > footer` was the recommendation a few years ago. Now they say <https://html.spec.whatwg.org/multipage/grouping-content.html...>:
> Attribution for the quotation, if any, must be placed outside the blockquote element.
… and suggest things like `blockquote + p` and `figure > blockquote + figcaption` instead. I will also note that that use of figure would have been semantically inappropriate a decade ago, when figure was supposed to be something that could reasonably be taken out of the document flow, but now that’s been downgraded to just being a self-contained unit, though it may be able to be taken by itself and it’s generally suggested that you refer to figures by their captions.
> It is hard to take any stylesheet seriously when their website doesn't even properly use meta color scheme tags.
I did my best looking at the source in my mobile browser, thinking they’d somehow misused the meta theme-color feature, but they haven’t used that at all. It seems your gripe is that they haven’t provided dark mode styles. Which is a reasonable gripe (and I provide them for my site even though I prefer light mode), but clarity is really helpful especially when criticizing someone’s work in a detailed way.
As far as the blockquote/footer tag combination, it’s definitely not ideal but it is semantically valid.
Anyway, HN has enough people quick to criticize so I’ll leave it at this: you have valid complaints about the submission, but I imagine the authors would be receptive to them as suggestions which take no more effort.
Yes, my gripe is that they are not using a prefers-color-scheme so that my browser properly uses dark mode and that some of the elements they use are not best practice. It is fair to say that I am not the most constructive person in doing so, but I also feel that by offering it as a framework they should already be aware of this.
I used this for a project. I was working with somebody who didn't know HTML and had them overwriting an HTML file and uploading it to an S3 bucket over the course of 3 days, maybe twice a day, and I wanted code as simple for them as possible to prevent errors.
But that table. I'm not even sure what to say. How come custom CSS doesn't support semantic HTML? Or makes you use class names? Or is hard to customize? Sure, the last one might be controversial but I'm pretty sure most would agree that the other ones just make no sense.
• https://news.ycombinator.com/item?id=25167928 (21 November 2020, 82 comments)
• https://news.ycombinator.com/item?id=22681270 (25 March 2020, 91 comments)
—⁂—
> No class names, no frameworks, just semantic HTML and you're done.
The trouble with this claim is that MVP.css abuses semantic HTML badly, using completely inappropriate elements all over the place (e.g. aside for cards, and b/strong/i/em inside links to make them look like buttons of various kinds), and the author has declined to change these things despite acknowledging that they’re wrong.