The tables bashing was because it resulted in tag soup, even though it was conceptually easy.
This doesn't suffer from the same problem.
This doesn't suffer from the same problem.
<table> is a rigid display value taking up an entire tag. So the argument is why not push that into the CSS eg in a div instead and get rid of an entire unnecessary tag. This is why display:table doesn't get the same kind of hate thrown at it that <table> does.
Much like yield vs await in Python3 asyncio.
In the Python 2.7 days, people used generator functions to implement async in Python. When Python3 first came out, you couldn’t do both generator and async in the same function. I assume it’s because they used the same mechanism internally.
I think it was Python 3.5 which added support for async generators.
For devs who don't care so much about accessibility, and are more just interested in getting the layout they want, I guess that argument may not resonate so much. I personally don't care much for taxonomic/teleological arguments around REST methods, but I'm a bit more willing to follow fashion with Grid if it means people on screen-readers will have a better time.
3.5 released true asnyc/await based on the `yield from` form and then 3.6 allowed for async generators.
You were close and your point remains. Although I don't think new tags are the right choice. I think HTML learnt a while ago that more tags doesn't solve everything.
I do really enjoy python async. It's cool to see a feature develop from a hack like that but a language first approach could have avoided some headaches. This is where Grid wins, it's a fresh take without requiring to maintain backwards compatibility with previous attempts.