Hacker News Reader

> One thing I consistently dislike in these efforts is the misappropriation of HTML tags with certain semantics.

As a counterpoint, I don't understand people pushing strict semantics in html elements where they're not really strictly defined or generally useful. Because of how loose the spec with how these things can be used (it it weren't it'd be like schema.org meets html) scraper and other UI tools don't really look for these things and are very flexible in parsing and identifying structure. It'd be foolish to implement a html parser for the general web that strictly expects articles to be in article tags.

Browser default CSS for these things mostly suck and are rarely used, in this case they're overriding them anyway. So why stay pseudo-semantic?

Besides general accessibility (which is tag attribute based mostly), its not obvious to me how this critique is repeated so often with such little value.

"you don't need CSS classes, but instead need to add aria-tags overriding the accessibility semantics" kind of invalidates the point of something like this IMHO.

Creating true accessibility is very difficult in my experience and involves a lot more than tag attributes. Screen readers like JAWS can be, again, very difficult to work with - so being as semantic as possible and maintaining "flattened" HTML are often necessary to get them to work properly for blind users.

The problem of semantics is two-fold: you’re abusing one thing’s semantics (built-in HTML elements, ending up with something unsemantic in name or functionality), in order to avoid using one of the two mechanisms that are designed for naming semantics in styling and potentially functionality (which are: classes and custom elements).

The effects of the semantic abuse are admittedly slight, but they are still present, so all else being equal you should care at least a little about them. Tools like screen readers do distinguish between section, article and div in their landmark handling. By abusing these things, you are making life just a little bit harder for users of screen readers.

I think <article>the</article> right way to do it is to have <article>the</article> parser figure out which words are articles rather than explicitly tagging them. There are only three of them in English, and it's not a hard NLP problem. Of course, it's harder with Chinese, where there are countless measure words. And easier in <article>a</article> language without articles.

I am not sure if this is misunderstanding, satire, or trying to make a point.

The article tag refers to the other definition of article -- "magazine article", not "article of speech".

Well, I think it's definitely not satire. Satire generally has <article>an</article> "intent of shaming individuals, corporations, government, or society itself into improvement." (source: Wikipedia). In other words satire has <article>a</article> target; it's making fun of someone or something, often with <article>the</article> goal of change. I definitely wasn't trying to mock anyone, affect change, or do anything ill-natured.

So I guess it might be one of <article>the</article> other options? :)

Boring question - could you spell out the point you were trying to make? I'm interested to hear it but it's currently kind of vague.

I made a dumb joke. It wasn't sarcasm, satire, snark, or any sort of point. It was a bit of wordplay. That's all. People liked it, and it got a few upvotes.

Someone asked a question, and I posted a response. Then everything got downvotes, so perhaps the response was no longer funny. I probably took it to far. So now I'm posting a clarification.

Or perhaps I'm reading too much into things.

> Besides general accessibility (which is tag attribute based mostly)

I was under the impression that semantic html elements imply certain aria tags (I read some mdn pages on this recently so I'm pretty confident in this impression, unless I confused proposed and actual specs). So, they can help with the ease of writing accessible UI.

Yes, the first rule of ARIA is if you can use HTML instead of ARIA attributes, do so; e.g. use <button>, not <div role="button">.

Some roles inherent to HTML elements are only conditionally exposed; e.g. the <section> element has the ARIA landmark role of "region" but assistive technologies that list landmarks should not include such section elements unless it has also been given an accessible name, e.g. <section aria-labelledby="contact-info"><h2 id="contact-info">Contact Info</h2> ... </section>. I've read that the <aside> element is not really an ARIA "complementary" landmark if it's the child of another landmark but in practice it still seems to be treated that way.

My point wasn't to replace the classic class grid, just to give basic HTML5 grid if necessary. You can always add any other CSS Framework for grid formatting. About <section> and other HTML5 tags.. you can always personalise the code to your standards.

The grid is based on this: parent element {display: flex; flex-flow: row wrap} child element {flex:1}

Replace the parent element (container) with any HTML element, replace the child element with your preferred semantic element.

Great reply, Vlad. Your code is really small and tight, and it's easy to modify, just as you say. That's one of the benefit of writing in the style that you did: modern, using all of modern CSS's native goodness. Which means its small, static, no build, and easy to modify. Very nice work.

What is a card? For me that is purely stylistic and should live in the CSS alone. What does a card mean to a blind user?

This is all very easy when you're in the business of marking up documents. It turns out that the handful of element types defined in HTML are good enough for the vast majority of documents. It's quite rare to need to introduce a new tag. The difficulty starts when you're actually trying to create a "user interface" rather than a document.

For me, cards are usually lists of self contained items (usually summaries). So the cards parent is usually a `<ul>` or `<ol>` and the card them selfs are `<li>` with a single `<article>`, `<aside>`, or `<figure>`.

Agreed. A good classless CSS file should work as a drop-in replacement for the native browser spreadsheet, it should definitely not try to invent it's own semantics.

Not that you can't do that, but if you do you are creating a CSS framework, not a stylesheet.

Funny enough, I often mark up grid cards as an unordered list of articles:

    <ul>
      <li>
        <article>Card 1</article>
      </li>
      <li>
        <article>Card 2</article>
      </li>
    </ul>

Since grid cards are often complete stand-alone items with their own headings, footings and body content.

Agreed with your overall point that HTML tags should not be misappropriated.

This can be a challenge for purely classless CSS because a style can correspond to different semantics in different scenarios. For example, the cards as used in Basic.css [1] are semantically <section>s. But in a different context, cards could be used for an <aside> [2] or for a social media post which would indeed be an <article> [3].

[1]: https://vladocar.github.io/Basic.css/

[2]: https://getbootstrap.com/docs/4.5/components/card/

[3]: https://html.spec.whatwg.org/multipage/sections.html#article...

You're not wrong, but I'll note that the definition of <article> you are referring to seems pretty useless, and I don't think it's wrong for people to generally decide what <article> should mean.

I don't see anywhere that defines <aside> as being used for cards. But <aside> should be used for cards if the card itself is an aside.

> Here, have an article within a section. … what? That ain’t semantic.

What's not semantic about that? An article =/= a page. A page can have multiple articles; the idea of an "article" is pretty abstract.

> But <aside> should be used for cards if the card itself is an aside.

That's exactly how I treat cards with MVP.css. Note: "aside" doesn't mean it visually needs to be "on the side", just complimentary to the body content.

https://andybrewer.github.io/mvp/

I still strongly oppose your use of aside there. (And it was indeed that that I was referring to in my original comment here.) Those cards are part of the flow of the document, not tangentially related to the adjacent content.

I don't think it's that dissimilar to Mozilla's usage here: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/as...

The 1st `<p>` talks about the movie and the `<aside>` talks about a feature/statistic related to the movie.

In mine, the main content talks about the what the library is and how to use it and `<aside>` is used to call out specific features related to the library.

In either, the "feature" content could be part of the main content or called out separately and both would seem reasonable to me.

Sure, if there was a `<card>` element, that would be a better fit, but the definition of an `<aside>` is broad enough IMO ("indirectly related content") that feature callouts don't seem totally counter to the spirit of the tag.

Asides have nothing to do with document flow.

“Document flow” was perhaps a poor choice of word because of its overloaded meaning. I meant “the flow of content and writing within the document” rather than the layout term.

I started reading what you wrote with the complete disagreement of what I thought you are saying and finished agreeing completely. :)

I find a good starter defaults good.