Hacker News Reader

Hacker News

Comment by chrismorgan | Hacker News Reader

Parent Full thread

chrismorgan

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/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.

View on HN

> 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.

I have to say I'm on the fence on this.

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.

Interesting, thanks, did not know that would be valid!

https://www.bonsaicss.com/

Hi, author of MVP.css here.

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 <strong> 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 <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.

I agree with you, that there's a 80/20 objective here for an MVP stylesheet.

However, I think wether `<aside>` is semantic HTML or not is specific to the content inside it.

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/as...

> 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.

For example, you use cards in two places on https://andybrewer.github.io/mvp/.

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).

Hey, thanks for commenting!

* 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.

* You could think about adding the underlining for links in continuous text. See https://www.w3.org/TR/WCAG20-TECHS/F73.html.

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.

> You could think about adding the underlining for links in continuous text. See https://www.w3.org/TR/WCAG20-TECHS/F73.html.

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.

There's nothing specifically wrong with it, but it's still learning a system, not semantic html.

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.

I see you pretend to use buttons using styles. https://www.buttoncheatsheet.com/ That is bad, and you should fix bad.

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).

Once could argue, we all should care about accessibility, hence we should all care about Semantic HTML.

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.

That's a nice way to say "I don't care about accessibility".

Aside, article etc hardly has any impact on accessibility. Labels, titles, contrast, tabs do have a big impact.

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....

aside is a landmark role.

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.

I agree that's what happens.

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.

> The trouble with this claim is that MVP.css abuses semantic HTML badly

It seems you are not in a position to be making these claims, since by your own admission you don't even use the project:

https://news.ycombinator.com/item?id=32807145

Reply on news.ycombinator.com