Show HN: Basic.css – Classless CSS Starter File(github.com) |
Show HN: Basic.css – Classless CSS Starter File(github.com) |
In this instance, the <article> elements should not be articles: they’re not complete, standalone items. To be sure, as https://html.spec.whatwg.org/multipage/sections.html#article... says, there’s subjectivity in deciding whether to use <section> or <article>, but I’m content to say that <article> is wrong here.
(Last time I looked into one of these classless CSS starter files, it was <aside> being used for cards, which was very wrong.)
In a case like this, I’d prefer the inner elements to be <section> or <div>. Or better still, just start using custom element names which are perfectly valid, e.g. <grid-card>. There, no class. I will permit you to claim that that’s cheating and avoiding the point of classlessness; I don’t mind.
But the big pitfall of trying to go fully classless (if you interpret that as also meaning you can’t use your own custom element names) is when HTML just doesn’t have tags for the semantic concepts you’re trying to express. You want a quote, table numbered list? Yeah, we’ve got tags for those things, go knock yourself out. But you want a card? Here, have an article within a section. … what? That ain’t semantic. How’s an author supposed to guess that those tags will present like that? That’s what classes or autonomous custom elements are good for, indicating intent.
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.
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 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.
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.
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.
Not that you can't do that, but if you do you are creating a CSS framework, not a stylesheet.
<ul>
<li>
<article>Card 1</article>
</li>
<li>
<article>Card 2</article>
</li>
</ul>
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...
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.
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.
I find a good starter defaults good.
The weird part is that by wrapping an article within a section now I'm designing with columns (which btw, it seems there's no way to control them). And section > article turns out to be the suggested semantics for a blog.
It's a nice effort, but what I'd look for in a starter file might not be a uncontrollable grid.
<meta default-element="div">
<.card>
<div class="card">
It's cool, but I'll stick to just writing my own, light-on-classes CSS.
- https://github.com/dohliam/dropin-minimal-css
The cards of this one look neat, but in case I need something like that I would add it myself to concrete. Nice place to start never the less.
Imagine what you could get it down to if you just wrote CSS instead of using a framework.
If you wanted to make that page really fast, you’d inline all the CSS and the avatar image, and get it under 14KB so that the entire HTTP message could be transmitted in one TCP packet.
I did a proof-of-concept last week with MVP.css and it was so quickly put together that it was almost as convenient as from writing the content in a Google Doc (where I use borderless tables for the columns). Google Docs are usually my second step in the process, as I don't like to get feedback on sketches, but this might be it now. (My first step is that I sketch on receipt paper, it's the perfect width for mobile, super cheap, and can be as tall as you'd like for your design. Highly rec.)
A great tip was to use an appropriately colored shadow for focus and errors in the forms. It improved legibity a lot.
[1] https://golang.cafe [2] https://github.com/yegor256/tacit [3] https://tailwindcss.com
Give MVP.css a try: https://andybrewer.github.io/mvp/
It had some good community support (2.5k stargazers and about a dozen contributes).
(disclaimer: I'm the author)
Congratulations on releasing this!
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 loopback has MTU of 16kb, everything else is 1500 or less
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.
The article tag refers to the other definition of article -- "magazine article", not "article of speech".
So I guess it might be one of <article>the</article> other options? :)
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.