3 ms·

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

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.

awb 4y ago
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/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. 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/aside 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?
- d1sxeyes 4y ago
  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/ 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).

awb 4y ago

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

d1sxeyes 4y ago
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/ 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).