* 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.
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.
> 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.
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/) 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.
* 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.
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.