151–160 of 191 posts
I’m a little confused by the title. Wasn’t nav introduced in HTML5? Anyway, agree with what’s being said here. K.I.S.S.
The XHTML default namespace URL is http://www.w3.org/1999/xhtml in W3C's HTML5 documents (the link resolves to a page that lists references).
Was I the only one who clicked this expecting React components for modern CSS layouts using markup like and Last Updated: June 1999 Otherwise you’re not writing HTML like it’s 1999, you’re writing HTML like it’s the web standards movement of the early 2000s before AJAX and Web 2.0 started trending. If you really want to write HTML like it’s from 1999, read this blast from the past: https://www.w3.org/TR/2018/SPSD-htm…
However, layoutwise HTML is at the moment much like it had been in 1999: The basic structure with banner, nav, main, footer is much like the standard frameset, if there had only been role/landmark-markup for frames, and CSS-grid in its basic form is much like table-layout (less those Daliesque "poles" for positioning). Where there had been those fancy CMS templates with modular components, there are now frameworks… (However, JS is "a bit" more powerful and has grown out of `document.write()`.)
That said,landmarks and aria-markup are really a great deal when it comes to accessibility and are probably the most underrated additions to HTML.
In 1999 I think I had just switched from HotDog to HomeSite. Honourable mention to HoTMetaL and Microsoft FrontPage, which I tried then abandoned for various reasons. Eventually I started using a plain text editor (BBEdit).
As someone who has a pretty serious visual impairment, I find the attitude of so many of these comments really... disappointing. You wouldn't believe how much effort people with poor vision have to go to, to consume the modern web. You can't even take simple things for granted like being able to zoom. So many websites pollute their page with pointless navigation elements that block most of the content when the page i…
+++ I'd like to throttle the first person who ever decided that if the window width would not 'comfortably' accommodate their vision of the page, certain elements would just DISAPPEAR. Like GONE. When you have to zoom out to make hidden elements (not just hanging off the edge, as in never drawn) appear... someone has been naughty.
/S
As someone who has a pretty serious visual impairment, I find the attitude of so many of these comments really... disappointing. You wouldn't believe how much effort people with poor vision have to go to, to consume the modern web. You can't even take simple things for granted like being able to zoom. So many websites pollute their page with pointless navigation elements that block most of the content when the page i…
Do you have a link(s) that summarizes these points so devs that are ignorant of these needs can reference?
Then see what happens when you view it at 400%.
Then find yourself some software that mimics various visual impediments and give it a shot.
I hope there will be a return to simple web pages where HTML is used for content, not apps. That’s the way the web was intended. Web assembly is nice and all, but it does smell an awful lot like Java applets in 1997. Proprietary, slow and hard to grok.
I'm interested in hearing what is proprietary about wasm? It's a standard[1] implemented in most browsers. [1]: https://www.w3.org/TR/wasm-core-1/
Earlier quoted context omitted.
Ever tried to use your pages with a screen reader? It's quite an interesting (and potentially maddening - screen readers are power-user tools, and quite difficult to get into if that's not how you normally operate) exercise.
I tried doing this once, and I wasn't even able to install the damned thing. If you've got any advice or instructions on how to get started with a screen reader for testing purposes, I'd be really interested.
Earlier quoted context omitted.
Borders still affect the positioning of things even with box-sizing set to border-box. For example, here "Block 1" is still two pixels taller than "Block 2": Block 1 Block 2 https://jsfiddle.net/t4rkvfzx/
Does that really matter though? A difference of 2px for something temporary doesn't seem like much concern. While I understand the implication is that these can accumulate and cause larger layout issues, the purpose of this practice is to highlight those areas to remove that accumulation anyway
Any reason it is bad to use divs with aria attributes over for a radio button choice? Because radio buttons are a pain to style and require all sorts of hacks to look nice. And in a real job you sometimes get asked to brand things, not just let the default styles come through.
Aria attributes aren’t enough to make an element accessible. You still need to set up listeners for keyboard navigation, you need to make the element focusable, you need to remember the aria attributes for labeling, etc. Chances are you are going to miss some of these. Better use a battle tested third party library for these, or—better yet—the native ` `. Edit: Radio buttons are not hard to style[1]. Just use `appear…
Also for styling, visually hiding the and using a custom radio-like icon with its associated can be a decent option. Use a CSS selector like this to "check" an icon with the label: #radio1:checked + label::before
Earlier quoted context omitted.
I tried doing this once, and I wasn't even able to install the damned thing. If you've got any advice or instructions on how to get started with a screen reader for testing purposes, I'd be really interested.
VoiceOver is built into OSX and is fairly full featured. Anything for Windows is either expensive or half baked IMO.