91–100 of 122 posts
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. This is the landing page I built: https://figmage.com
This is interesting, do you have paying customers ?
Earlier quoted context omitted.
In their defence they openly state its not for the final product but rather to get _something_ shipped.
There's nothing more permanent than a temporary solution.
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.
> [pro tip] Add this code to a new HTML file: > https://unpkg.com/mvp.css "> 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.
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).
Earlier quoted context omitted.
Html semantics is really for purists. 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.
Semantic HTML is useful for search engines and people who need accessibility (e.g. people who use screen readers).
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.
Previous discussions: • 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…
For those interested in the discussions around this, please refer to:
https://github.com/andybrewer/mvp/issues/26
https://github.com/andybrewer/mvp/issues/2
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.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/st...
> The HTML element indicates that its contents have strong importance, seriousness, or urgency. In MVP.css links are already in bold by default, so ‘strong’ text inside a link requires more “urgency” than bold text, which is styled as a button. Sure, I’ll grant that it’s atypical, but I don’t think it’s obviously wrong in some way. Same with ‘aside’: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/as... > The 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.
> [pro tip] Add this code to a new HTML file: > https://unpkg.com/mvp.css "> 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.
Fair point. I’ll update the site soon to explicitly use a version.
Thanks for pointing that out!
On the demo page [1], the element starts with an . That doesn’t seem right. The element is meant for section breaks (where there is content both before and after the element), not for decorative horizontal lines. [1]: https://andybrewer.github.io/mvp/mvp.html
If we're really being pedantic, all uses of 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
https://html.spec.whatwg.org/multipage/grouping-content.html...
If it isn't clear, I find it a bit silly :)