I see new frontend developers using <div> for building buttons, and I've even seen people using <div> for doing titles! Us greybeards don't know how much apparent knowledge we're sitting on, it seems.
In 2004 I was at a company that dedicated a team of people to rebuilding a bunch of tables (lots of financial data) in to styled divs because... "tables are depreciated". The fact that they couldn't pronounce or understand the word "deprecated" should have been enough of a clue to ignore this person, but they were the 'lead' on the web team, and... had been there longer than other people. Obviously they must know what they're talking about. Weeks later after having converted dozens of spreadsheets to divs (instead of just using tables) they were 'done', but it was a tremendous waste of time that ignored all the semantics of tables. I was asked to 'help out' on that project to meet the deadline and refused, citing that it was not just stupid, but a big waste of time and against web semantics.
"table" was never deprecated in HTML at all, but was discouraged for general layout (we were aware of this even in the early 2000s). But for representing tabular data - like... data in rows/columns from spreadsheets (with column headers and such)... HTML tables were absolutely the right (only?) way to present this.
I recently discovered our frontend widget library draws an SVG to implement Radio instead of using <input type="radio">. I was looking at it because they forgot to add a "disabled" attribute.
Best case I'm hoping it's because they were required to get an exact design, but they really should have pushed back on that one if so.
And for the ones that remember to implement middle-mouse click to open new tabs, forgets that one can also do CTRL+click to open in new tab, or vice-versa.
Seems to me that we have redundant mechanisms for specifying semantics: tags and attributes (and classes as a specific attribute). Seems to me that tags are really just syntactic sugar for things like roles. Tables in particular are easily abused.
Of course I use the tag names, because they're idiomatic. But I feel like a newbie who identifies divs as the only true structure builder has a proper developer's intuition for separating presentation from content.
As long as you think about semantics and accessibility and does the extra work to add those things, then not really.
But why add those extra things when we already get those for free by doing <h1> and then customizing the style? Everything you'd need to manually add, automatically works fine then, so seems like a no-brainer to avoid putting more work on your table.
div-as-button/link leaves a lot of default interaction behaviour on the table. You'll need to handle all the keyboard interactions yourself, all the accessibility markup, etc.
I see new frontend developers using <div> for building buttons, and I've even seen people using <div> for doing titles! Us greybeards don't know how much apparent knowledge we're sitting on, it seems.
In 2004 I was at a company that dedicated a team of people to rebuilding a bunch of tables (lots of financial data) in to styled divs because... "tables are depreciated". The fact that they couldn't pronounce or understand the word "deprecated" should have been enough of a clue to ignore this person, but they were the 'lead' on the web team, and... had been there longer than other people. Obviously they must know what they're talking about. Weeks later after having converted dozens of spreadsheets to divs (instead of just using tables) they were 'done', but it was a tremendous waste of time that ignored all the semantics of tables. I was asked to 'help out' on that project to meet the deadline and refused, citing that it was not just stupid, but a big waste of time and against web semantics.
"table" was never deprecated in HTML at all, but was discouraged for general layout (we were aware of this even in the early 2000s). But for representing tabular data - like... data in rows/columns from spreadsheets (with column headers and such)... HTML tables were absolutely the right (only?) way to present this.
I was at that company less than a year...
And spans for creating links…
I recently discovered our frontend widget library draws an SVG to implement Radio instead of using <input type="radio">. I was looking at it because they forgot to add a "disabled" attribute.
Best case I'm hoping it's because they were required to get an exact design, but they really should have pushed back on that one if so.
Sounds like they either don't care about accessibility or like wasting money comprehensively reinventing things.
Thereby forgetting that some people like to open links in a new tab.
And for the ones that remember to implement middle-mouse click to open new tabs, forgets that one can also do CTRL+click to open in new tab, or vice-versa.
Just use <a> please :)
Is that bad?
Seems to me that we have redundant mechanisms for specifying semantics: tags and attributes (and classes as a specific attribute). Seems to me that tags are really just syntactic sugar for things like roles. Tables in particular are easily abused.
Of course I use the tag names, because they're idiomatic. But I feel like a newbie who identifies divs as the only true structure builder has a proper developer's intuition for separating presentation from content.
> Is that bad?
As long as you think about semantics and accessibility and does the extra work to add those things, then not really.
But why add those extra things when we already get those for free by doing <h1> and then customizing the style? Everything you'd need to manually add, automatically works fine then, so seems like a no-brainer to avoid putting more work on your table.
div-as-button/link leaves a lot of default interaction behaviour on the table. You'll need to handle all the keyboard interactions yourself, all the accessibility markup, etc.
I knew it existed but I figured it was only really useful for extremely data-table centric applications so I've never used it.