3 ms·

Hi, author of MVP.css here. For those interested in the discussions around this, please refer to: https://github.com/andybrewer/mvp/issues/26 https://github.c

by awb 4y ago

Hi, author of MVP.css here. For those interested in the discussions around this, please refer to: https://github.com/andybrewer/mvp/issues/26 https://github.com/andybrewer/mvp/issues/26 https://github.com/andybrewer/mvp/issues/2 https://github.com/andybrewer/mvp/issues/2 I would concede that the use of ‘a strong’, ‘section aside’, etc. does require some learning and the styling is perhaps unique, but I don’t think it’s invalid in any way. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/strong https://developer.mozilla.org/en-US/docs/Web/HTML/Element/st... > The <strong> HTML element indicates that its contents have strong importance, seriousness, or urgency. In MVP.css links are already in bold by default, so ‘strong’ text inside a link requires more “urgency” than bold text, which is styled as a button. Sure, I’ll grant that it’s atypical, but I don’t think it’s obviously wrong in some way. Same with ‘aside’: 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. Asides are frequently presented as sidebars or call-out boxes. I think cards are basically “call-out boxes”. But at the end of the day, this style sheet doesn’t have to be for everyone and it’s really designed for someone who’s rapid prototyping. That said, I do think buttons and cards are important to most web page layouts so if there’s a better semantic way to codify those, I’m open to pull requests.

IYasha 4y ago
I see you pretend to use buttons using styles. https://www.buttoncheatsheet.com/ https://www.buttoncheatsheet.com/ That is bad, and you should fix bad.
clairity 4y ago
cards are better represented as <article> elements: independent blips of content that are regular and largely self-contained (in a given section). an aside is literally something that's not part of the regular flow of information. it's not included in reader mode for instance. especially with rapid prototyping, you don't want your stylesheet dictating quirky usage of html.
soperj 4y ago
There's nothing specifically wrong with it, but it's still learning a system, not semantic html.
d1sxeyes 4y ago
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?
zichy 4y ago
Hey, thanks for commenting! * I think everything regarding the `aside` elements has already been said in the GitHub issue: It's context specific and you can't determine in advance if a certain (card) element is part of the main content or not. Therefore, `aside` should only be used if needed. (The top three cards on the MVP.css homepage definitely are part of the main content for example.) * Your `a i` and `a strong` solutions are pretty unusual and they show the limit of what is possible using a classless CSS. I would have preferred staying even more minimalist and simply pass on button-like links. * You could think about adding the underlining for links in continuous text. See https://www.w3.org/TR/WCAG20-TECHS/F73.html https://www.w3.org/TR/WCAG20-TECHS/F73.html. I'm not trying to be a dick about it since it's your personal project and I am not forced to use it – but I am not sure why the framework had to be classless and usable for a MVP all at once. I absolutely love classless CSS for simple/personal websites, but I associate MVPs (products) and rapid prototyping with more extensive and interactive interfaces than the typical text-based onepager.
- awb 4y ago
  > you can't determine in advance if a certain (card) element is part of the main content or not. Therefore, `aside` should only be used if needed Good point, I agree. > Your `a i` and `a strong` solutions are pretty unusual and they show the limit of what is possible using a classless CSS 100% agree. This was a loose interpretation of semantic HTML IMO. > I would have preferred staying even more minimalist and simply pass on button-like links. Sure, from a purist perspective, but from a productivity one, the vast majority of product / service sites have a button somewhere, so I thought it was important to include it even if I had to abandon a strict-constructionist view of semantic HTML and go with a more progressive, interpretative one. > You could think about adding the underlining for links in continuous text. See https://www.w3.org/TR/WCAG20-TECHS/F73.html https://www.w3.org/TR/WCAG20-TECHS/F73.html. I agree. I think it's a strong candidate to implement this in a v2 if that happens down the road. > I associate MVPs (products) and rapid prototyping with more extensive and interactive interfaces than the typical text-based onepager Sure, modern day MVPs look far more polished and interactive, but this was kind of in response to that. I was working through YC's Startup School (https://www.startupschool.org/ https://www.startupschool.org/) at the time and they were pushing the definition of an MVP as something that just barely works so you can test out a specific idea. So, while it won't work for an AirTable MVP, I think it should work for an API MVP, or most single-form MVPs. Beyond that, I agree it might not be a great fit for the project.

by awb 4y ago

IYasha 4y ago

I see you pretend to use buttons using styles. https://www.buttoncheatsheet.com/ https://www.buttoncheatsheet.com/ That is bad, and you should fix bad.

clairity 4y ago

cards are better represented as <article> elements: independent blips of content that are regular and largely self-contained (in a given section). an aside is literally something that's not part of the regular flow of information. it's not included in reader mode for instance. especially with rapid prototyping, you don't want your stylesheet dictating quirky usage of html.

soperj 4y ago

There's nothing specifically wrong with it, but it's still learning a system, not semantic html.

d1sxeyes 4y ago

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?

zichy 4y ago

Hey, thanks for commenting! * I think everything regarding the `aside` elements has already been said in the GitHub issue: It's context specific and you can't determine in advance if a certain (card) element is part of the main content or not. Therefore, `aside` should only be used if needed. (The top three cards on the MVP.css homepage definitely are part of the main content for example.) * Your `a i` and `a strong` solutions are pretty unusual and they show the limit of what is possible using a classless CSS. I would have preferred staying even more minimalist and simply pass on button-like links. * You could think about adding the underlining for links in continuous text. See https://www.w3.org/TR/WCAG20-TECHS/F73.html https://www.w3.org/TR/WCAG20-TECHS/F73.html. I'm not trying to be a dick about it since it's your personal project and I am not forced to use it – but I am not sure why the framework had to be classless and usable for a MVP all at once. I absolutely love classless CSS for simple/personal websites, but I associate MVPs (products) and rapid prototyping with more extensive and interactive interfaces than the typical text-based onepager.

awb 4y ago
> you can't determine in advance if a certain (card) element is part of the main content or not. Therefore, `aside` should only be used if needed Good point, I agree. > Your `a i` and `a strong` solutions are pretty unusual and they show the limit of what is possible using a classless CSS 100% agree. This was a loose interpretation of semantic HTML IMO. > I would have preferred staying even more minimalist and simply pass on button-like links. Sure, from a purist perspective, but from a productivity one, the vast majority of product / service sites have a button somewhere, so I thought it was important to include it even if I had to abandon a strict-constructionist view of semantic HTML and go with a more progressive, interpretative one. > You could think about adding the underlining for links in continuous text. See https://www.w3.org/TR/WCAG20-TECHS/F73.html https://www.w3.org/TR/WCAG20-TECHS/F73.html. I agree. I think it's a strong candidate to implement this in a v2 if that happens down the road. > I associate MVPs (products) and rapid prototyping with more extensive and interactive interfaces than the typical text-based onepager Sure, modern day MVPs look far more polished and interactive, but this was kind of in response to that. I was working through YC's Startup School (https://www.startupschool.org/ https://www.startupschool.org/) at the time and they were pushing the definition of an MVP as something that just barely works so you can test out a specific idea. So, while it won't work for an AirTable MVP, I think it should work for an API MVP, or most single-form MVPs. Beyond that, I agree it might not be a great fit for the project.