Hacker News Reader

This was definitely built to solve a very specific problem in a very specific way, I think you're asking too much of it.

It's just a handy shortcut for building a landing page in like 20 minutes or sprucing up your "haven't gotten around to writing the CSS yet" web app so you can kick it out the door.

The point is that the marketing is false. This CSS framework forces to you to abuse HTML semantics if you want to use it, which is exactly what it claims it doesn't do.

What's extra frustrating is that it would be so easy to fix, by just adding a few classes. But they wanted to be "semantic", so they forced their users to be unsemantic.

Or they could have just used arbitrary elements, like <myelement>. Folks forget that this is valid HTML, and it’s just treated as a div.

I don't think they forgot, because it was never true. It needs a dash `-` in it.

https://html.spec.whatwg.org/#valid-custom-element-name

It needs them now, but it wasn't always the case. In html5-20121025 User agents must treat elements and attributes that they do not understand as semantically neutral.

It was also in the grey area in HTML4.01 spec, note B.1 provides for user agents rendering any unknown elements.

Semantically neutral yes, but they are not divs -- they're "unknown elements", which have more annoying behavior (similar to pseudoelements from memory)

I think that's right. They start out life as inline-block elements.

A landing page with huge accessibility issues

I wonder how you justify your use of the word "huge" here, given that it'll most likely be far better than most landing pages out there and not everyone will use the problematic components.

I think this comment makes a pretty clear case for it:

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

For me personally, the accessibility issues would be with elements used out of their usual role.

For example: When I, blessed with being sighted at this time, but without a mouse, ask my browser to identify the clickable/actionable elements on the page, it mis-identifies both unclickable elements as clickable, and clickable elements as unclickable.

I would call that a serious usability issue. And if I was not sighted, using a screen-reader, I would be very confused indeed by this landing page.

I agree that whether this qualifies as a "huge" usability issue is indeed a matter of opinion. I would certainly argue that it is a huge usability issue.

Using the software you've got, would using role attributes be a sufficient workaround?

Accessibility is not something I know much about (I mostly work backend). What's the issue with this type of approach? I was tempted to use it as a starting point for a little side project, but Id rather not start with something with inherent accessibility issues.

The biggest issue I noticed right away is that it uses elements outside of their traditional use cases.

User agents rely on ``a`` elements being clickable, and ``span`` elements not being clickable, for example, to determine which actions to present to the user.

When you use them outside of these use cases, the user agent has to do extra work to figure out whether something is actionable or not, and not all can do it adequately.

Thanks, that makes sense.

The light grey text under "MVP.css works with the following HTML elements:" surely fails (WCAG2).

`section` has an `h2`, but no `h1` for some reason. Other failures like this.

Other than that what's wrong?

Is a lack of H1 a dock against accessibility?

I think it would be, because a screen reader will try to call-out the topic of the document accurately and quickly. You don't want a user to have to dig through elements to find the real title of the page they're on.

hm I've worked at plenty of places that touted accessibility, and we would often leave out h1 on a lander page (there might be a few h2 instead as the highest ranking headers)

I dont understand your objection. This is a lightweight starting framework aimed at rapid prototyping, there is nothing stopping you from adding your own classes to refine or override as necessary.

I agree that semantic only would be a big limitation in production, but that's always been the chasm of web dev: taking your hacky "bash it together" code and massaging it into something durable, without wasting time over engineering everything from day 1.

My issue with it is that it’s saying that only semantic HTML will be used in mvp.css. Thus, divs and spans and class attributes are forbidden (again, in mvp.css). I am not finding fault with semantic HTML elements (I choose my own markup very carefully), but with this abuse of semantic HTML elements—so that the touted “semantic HTML” is actually “HTML with incorrect (or at best convoluted and dubious) semantics”.

If you’re wanting a lightweight starting point for rapid prototyping, <div class="card"> is much nicer and more obvious than sticking an <aside> inside… hang on, was it an <article> or a <section> that I had to put it inside to make it a card?

So largely I’m saying that for something targeting the space mvp.css is targeting, rabidly avoiding classes is a bizarre and pretty much indefensible choice.

I built a site using this framework recently and that's exactly what I did.

Copied the css file into my source

    s/aside/\.card/g

Tada!

I viewed mvp.css as a starting point that'll get something looking nice enough on top of my raw html, and then I can (did) make tweaks from there.

When I think of semantic html, I think of lots of classes, but they describe the content instead of the presentation. Maybe I am thinking of an out of date defintion?

No, I share your sentiment and I work in the accessibility space myself. Presentation should always follow the content, presentation is always secondary and it needs to be flexible.

In cases of (color)blindness, vision loss or cataract, deafness, vertigo etc. the presentation needs to adapt to the user needs while ideally presenting the same content.

With OP's stylesheet it is possible to create a visual representation that is flexible and robust, but the classlessness nature makes it impossible to support certain type of content altogether.

The elements defined in HTML have meanings. That's the semantics. If you use the elements according to the meanings defined in the standard, then your markup is semantic. Whether you use lots of classes is neither here nor there, although how you use the classes matters.

Honestly I'd still rather start out with a really good classless theme and then start making things like custom buttons, containers of various types, dropdowns, modals, etc.

Exactly. You can still use classes all you want. But by including this css you essentially just get good looking defaults.

I don't think the use of classes is forbidden in any way. This is a just a drop in css file to quickly style an HTML document, if you think it's a good idea to style some more, just add classes.

It doesn't forbid classes explicitly but website mentions "No class names" twice which doesn't portray them in a very good light.

It means that you don't have to use 'mb-1--success-large' and things like that, but if @chrismorgan's point is that they've just swapped that for meanings encoded in element names rather than class names (in many cases not the usual meaning) then I think I agree.

I agree that "No class names" may me interpreted as "you're not allowed to use classes" but the main idea is to have a CSS file that is very loosely coupled with your HTML that you can just drop in your project and style it quickly. You can add classes at any time. "No class names" may be correctly interpreted as "loosely coupled". I don't think it doesn't portray them in a good light.

They should really be using <section><div> for those cards. They're divisions in the content - there's no inherent semantic meaning to them being styled to look like cards, so they should be using the 'this has no semantic meaning' <div> tag.

> There’s a reason why the class attribute exists. You can also validly use custom elements and attributes

To hammer this home - there is nothing bad about divs when it comes to accessability which, to be honest, is the only concern that "semantic html" should be about.

> there is nothing bad about divs when it comes to accessability [sic]

There certainly is. Prefer h1 over div, button over div, etc whenever appropriate.

https://www.w3.org/WAI/tips/developing/#use-mark-up-to-conve...

Sorry, yes you're right. Use semantic elements when they are available. But otherwise, there's nothing wrong with divs. Assistive technologies mostly ignore them untill you give them meaning.

The point of a no-class framework is not to have zero classes in your html. The point is to have something that looks good with almost no effort. Obviously if you want to further customize, you're going to have to either introduce classes or violate semantics.