One thing I consistently dislike in these efforts is the misappropriation of HTML tags with certain semantics.
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.
> 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.
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.
"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.
> 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.
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.
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? :)
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.
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.
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.
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].
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.
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.
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.
“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.
This feels weird. Classes exist for a reason. When I read the title, I thought about a kind of CSS reset, but what I'm seeing is also a template/grid framework?
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.
The yesod web framework's hamlet templates have this, albeit without the default as far as I know. <section .card> compiles to <section class="card">. If you omit the element, it uses div by default so you can use just <.card> if you prefer.
Yeah, if there were a way to have this without the grid stuff, I'd be all for it. But as it is, if I want to use this I'm stuck either ignoring tags (which I may want to use) to avoid the grid stuff, or I'm stuck using a grid system which isn't very controllable.
It's cool, but I'll stick to just writing my own, light-on-classes CSS.
In the examples, form labels are used badly in a few places. The textarea label lacks its for attribute, and the radio buttons are done quite wrong: for best results, the entire group should be wrapped in a <fieldset>, with the prompt text (“Number:”) being a <legend>, and then each radio button’s text should be a <label>.
I do like these frameworks. Far more sites should use one of those or the principle behind them. My page [1] uses concrete [2] and has a page load of 125kb (including my picture) and loads in less than one second. I don't need all that bloat that comes with a lot of pages (checkout wired.com for a negative example).
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.
11.5KB of CSS, looks like you could probably take it to under 1KB. But the biggest weight is the 93KB 460×460 avatar image which is used in a 100×100 circle. That can be reduced to an decent JPEG of about 10KB without even shrinking it to 100×100. At 100×100 (low-DPI displays), it’s under 5KB. I’d probably go for a single 200×200 image weighing about 8KB.
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.
Well speed was not the main goal of my site. I just wanted to build something quick. I sometimes use the avatar on my page to upload it somewhere else and a decent resolution is good for that.
Thank you! Brevity in code is underappreciated. People think it is about file size (and it partially is) but it is mostly about understanding what the code does so that you can extend it in the way that you want. This looks like a true foundation, unlike the namesake framework which is building on top of an existing buildings.
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.)
I am currently building my first website in Laravel. In the past I've just done WordPress. I was surprised at how much work went into styling the forms, both of general aesthetics and accessibility.
A great tip was to use an appropriately colored shadow for focus and errors in the forms. It improved legibity a lot.
User agents usually do this. This Basic.css demo does show an outline for Chrome and Safari, but not Firefox... odd, because that does appear if I remove Basic.css stylesheet.
another one i'm using for my site [1] is tacit[2] it's pretty basic but it works well - although i've been trying to find a well structured, well designed css framework with no classes - I haven't found one of my liking, I think the best way would be to use something very minimal like tailwindcss [3] which i still have to try
I thought CSS variables were still not fully supported enough to use in production. I know you can use a polyfill, but that seems to detract from the minimalist approach of these basic CSS frameworks: https://caniuse.com/#feat=css-variables
Good point. I just checked our company's web analytics and IE makes up about 2% of web traffic. So it's not dead yet, but I guess you can make a case for not supporting it.
These are cool, but I'd appreciate it if they covered every HTML element- <details>, <cite>, <kbd>, etc. I guess this one calls itself Basic so maybe it's just going for the 80/20 effect of the most common HTML elements.
This is a nice take on an old problem. If your project makes HTML creation more straightforward without introducing a tonne of baggage, I'm all for it.
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.