Honestly for me it's all over the blasted place. As a large font user, the willy-nilly mixing of font-face, serif fonts on screen media, broken layout issues, and so forth means I have to override a good deal of this site's style with user-css now. It didn't use to be this bad, but the past few revisions to the site skin have had major issues for me. Other things -- like the "white on way to bright a blue/green" on buttons or in the new chat feature -- run completely contrary to the basics of accessibility norms only further exacerbating the problem.
Much of that is just how broken REM still is, despite wild (unfounded) claims on how well it works. Gecko ignores the system or even browser font choice, always treating 1REM as 16px defeating the entire huffing point of using EM, whilst blink's decreasing what it does on a curve and adjusting a minimum font-size that's set off the system/browser metric really doesn't help.
It's like... just use EM! and seriously, if the "math" of using just plain old compatible "EM" is "too hard" for developers, they probably shouldn't be developing.
Though the biggest problem is the use of bootstrap which assumes you're going to be slopping together a layout in inaccessible pixels when the layout is built with --- again a willy-nilly seemingly random -- mix of PX, EM, and REM. Pick a metric, preferably EM, an stick with it.
But as always, finding a stick to scrape the bootcrap off with wouldn't hurt; that way they could back away from the "endless pointless JS for nothing", "nothing but CSR" approach that tells a lot of users to sod off -- I know people who would be interested in this site if not for the fact that scripting off the site doesn't work, and have an overall faster website using a fraction the bandwidth written in a fraction the code.
Since as I often say, if you don't know what's wrong with code like this:
You might want to back up a bit and learn how to use HTML and CSS properly.
For those of you who don't know what''s wrong with that, 1) that's presentational use of classes reducing things to the worst of the HTML 3.2 style development mindset, and 2) an equally pointless data- attribute indicating it's being used for scripting in which case it doesn't even belong in the markup as a tag.
But what can one expect when even the logos are inlined in the markup -- 99% of the time you see a SVG tag in your HTML someone is doing something wrong. I would suggest moving all those logos, icons, and so forth into a custom font that way it's a single more compact file. I'm not saying SVG is inefficient and has no business in the HTML; no, wait... that's exactly what I'm saying.
I'm willing to bet that between the markup bloat, poor use of caching models, endless CSR for nothing, this site is using five times the bandwidth it would if it were built with normal SSR with proper separation of presentation from content.
Love the place, but the implementation could use some help. You'd almost think it was built with "frameworks" or something. The font-size issues are only an symptom of deeper rooted problems.
Honestly, given the technologies I'm seeing client-side being loaded if I were to do a standard "analysis" like I do for my clients, I'm kind of shocked it works as well as it does; that's more a testament to the persistence and perseverance of those working on the site than it is those technologies. Shame though, as it's all making them work harder and harder as the site ages.
Buit that's the trap of frameworks; they look easy at the start and then they hobble you as time passes. They have an illusion of ease mated to false simplicity. The end result is most always a broken bloated mess with accessibility issues galore. Sadly it's hard to offer soft soothing syrup words when the majority of what needs fixing can be boiled down to the old Groucho Marx joke of "Doctor doctor, it hurts when I do this". People don't want to hear "Well don't do that."
Don't use bootstrap, don't use presentational classes, don't use REM or PX, don't willy-nilly mix metrics, don't use the new allegedly "structural" HTML 5 tags, don't use JS for nothing, don't put JS only elements static in the markup, don't put scripting static in the markup, don't use the STYLE tag, don't use illegible colour contrasts, don't use CSR except as an enhancement to an already working page... it's a laundry list of "don't" that far too many dev's right now don't want to hear and take even the mention of as a personal attack. It isn't. I'm just telling you what I see wrong.
I'd offer to help fix things, but I doubt they'd like my "throw bootstrap, react, and pretty much 90%+ of the code client-side in the trash" solution -- since Christmas knows what that would entail server-side.
Jason Knight
The less code you use, the less there is to break
Honestly for me it's all over the blasted place. As a large font user, the willy-nilly mixing of font-face, serif fonts on screen media, broken layout issues, and so forth means I have to override a good deal of this site's style with user-css now. It didn't use to be this bad, but the past few revisions to the site skin have had major issues for me. Other things -- like the "white on way to bright a blue/green" on buttons or in the new chat feature -- run completely contrary to the basics of accessibility norms only further exacerbating the problem.
Much of that is just how broken REM still is, despite wild (unfounded) claims on how well it works. Gecko ignores the system or even browser font choice, always treating 1REM as 16px defeating the entire huffing point of using EM, whilst blink's decreasing what it does on a curve and adjusting a minimum font-size that's set off the system/browser metric really doesn't help.
It's like... just use EM! and seriously, if the "math" of using just plain old compatible "EM" is "too hard" for developers, they probably shouldn't be developing.
Though the biggest problem is the use of bootstrap which assumes you're going to be slopping together a layout in inaccessible pixels when the layout is built with --- again a willy-nilly seemingly random -- mix of PX, EM, and REM. Pick a metric, preferably EM, an stick with it.
But as always, finding a stick to scrape the bootcrap off with wouldn't hurt; that way they could back away from the "endless pointless JS for nothing", "nothing but CSR" approach that tells a lot of users to sod off -- I know people who would be interested in this site if not for the fact that scripting off the site doesn't work, and have an overall faster website using a fraction the bandwidth written in a fraction the code.
Since as I often say, if you don't know what's wrong with code like this:
<button type="button" class="btn btn-primary dark-shade dropdown-toggle dropdown-toggle-split" data-toggle="dropdown"></button>You might want to back up a bit and learn how to use HTML and CSS properly.
For those of you who don't know what''s wrong with that, 1) that's presentational use of classes reducing things to the worst of the HTML 3.2 style development mindset, and 2) an equally pointless data- attribute indicating it's being used for scripting in which case it doesn't even belong in the markup as a tag.
But what can one expect when even the logos are inlined in the markup -- 99% of the time you see a SVG tag in your HTML someone is doing something wrong. I would suggest moving all those logos, icons, and so forth into a custom font that way it's a single more compact file. I'm not saying SVG is inefficient and has no business in the HTML; no, wait... that's exactly what I'm saying.
I'm willing to bet that between the markup bloat, poor use of caching models, endless CSR for nothing, this site is using five times the bandwidth it would if it were built with normal SSR with proper separation of presentation from content.
Love the place, but the implementation could use some help. You'd almost think it was built with "frameworks" or something. The font-size issues are only an symptom of deeper rooted problems.
Honestly, given the technologies I'm seeing client-side being loaded if I were to do a standard "analysis" like I do for my clients, I'm kind of shocked it works as well as it does; that's more a testament to the persistence and perseverance of those working on the site than it is those technologies. Shame though, as it's all making them work harder and harder as the site ages.
Buit that's the trap of frameworks; they look easy at the start and then they hobble you as time passes. They have an illusion of ease mated to false simplicity. The end result is most always a broken bloated mess with accessibility issues galore. Sadly it's hard to offer soft soothing syrup words when the majority of what needs fixing can be boiled down to the old Groucho Marx joke of "Doctor doctor, it hurts when I do this". People don't want to hear "Well don't do that."
Don't use bootstrap, don't use presentational classes, don't use REM or PX, don't willy-nilly mix metrics, don't use the new allegedly "structural" HTML 5 tags, don't use JS for nothing, don't put JS only elements static in the markup, don't put scripting static in the markup, don't use the STYLE tag, don't use illegible colour contrasts, don't use CSR except as an enhancement to an already working page... it's a laundry list of "don't" that far too many dev's right now don't want to hear and take even the mention of as a personal attack. It isn't. I'm just telling you what I see wrong.
I'd offer to help fix things, but I doubt they'd like my "throw bootstrap, react, and pretty much 90%+ of the code client-side in the trash" solution -- since Christmas knows what that would entail server-side.