I couldn't agree more. HTML is so basic that you have no excuse to not do it in the ballpark of right (accessibility can be tricky and right is not always completely clear, but in 90% of cases you should have a good idea). Using a solid css reset solves most of your visual issues with using semantic elements/structuring following proper standards. Use the reset and then write css however you want to. The current state of the web (being nothing but an advertising platform for the most part) is what is driving a lot of people to other protocols. A return to sanely structured CONTENT over pretty/fancy/neat/whatever looking would be, in this writers opinion, a wonderful thing. I know in a perfect world we'd have both, but that is not how things have played out for the most part. Maybe the next thing, that replaces the web eventually, will get it right. :-/
HTML is the Web
151–160 of 341 posts
Re: HTML is the Web
#152> It’s all about what gets consumed by the consumer.
It's not about the what. It's about how it's delivered and consumed.
One could provide a web-like experience using any number of proprietary technologies. It's only "The Web" when you deliver that experience in an open and standards-based way, and consumers consume it using their standards-supporting client of choice.
Podcasts are another great example of "The Web". What makes a podcast a podcast isn't what gets consumed, but how it's delivered and consumed. You can post an audio show on proprietary platforms that require proprietary clients, but those aren't podcasts any more than a web page saved as PDF is still a web page. If you can't play it in a podcast app, it's not a podcast.
Re: HTML is the Web
#153My take is; everything will always get more complicated and you can write your nice simple articles but it will not help.
Re: HTML is the Web
#154Earlier quoted context omitted.
I think what the author is saying is that paradigm 2 is built _on top of_ paradigm 1 and if you can't do #1 right, then by definition _neither_ can be right. It's astounding the number of interview candidates who are super-fluent in JS but can't tell you to save their lives why it's a bad idea to put a click handler on a div. React will die (It's already started to) and we'll migrate back to the actual Web at some po…
> It's astounding the number of interview candidates who are super-fluent in JS but can't tell you to save their lives why it's a bad idea to put a click handler on a div. Go on?
Because you've literally just described what a is.
Re: HTML is the Web
#155Earlier quoted context omitted.
The reason browsers use the document as a building block is to provide a consistent and accessible UI to everyone using your site. This is the exact same thing that Windows, Apple, Android, etc do with their UI frameworks that they recommend you use. It also provides the ability for websites to safely degrade on older browsers because unknown elements can still be rendered in the correct hierarchy. Now in both cases,…
Platforms should provide the necessary low-level APIs to hook into their accessibility- etc... features without having to use their high-level UI frameworks, and they should provide lower-level services like high-quality text rendering. Mostly this already works, I can open a standard file dialog, or copy data into or out of the system-wide clipboard. If there are any APIs for accessibility missing (e.g. for hooking…
There's no way a platform can provide accessibility for arbitrary pixels you throw onto a screen. You could, by yourself, using the low-level accessibility APIs, but you likely won't since it's a lot of work. Hence the push for using platform UI components: they inform the framework of your intention, and in return this information helps it provide you with better accessibility.
Re: HTML is the Web
#156Earlier quoted context omitted.
Web pages that don't show anything without JS are broken. Ones that show only a message about enabling JS are worse. It seems JS;DR was already a thing long before I felt the need for it yesterday, when I simply missed that article about synths at ableton.com because it was broken. https://indieweb.org/js;dr
What about web applications? I am the office champion of accessible web, but recently we made a web based game, in canvas. Without js, there's no game engine, so we had a noscript tag. That synths article uses built in JavaScript synths (using audio apis). I agree the text should display without JavaScript but the purpose of the article (get hands on with synths) is eliminated without JS. Basically, the web not only…
> but the purpose of the article (get hands on with synths) is eliminated without JS.
If there is nothing to read, there is no way to know there is any app, let alone decide that I want it to run.
> why should web applications (beyond ones that are simple documents) work without JavaScript?
I imagine that the other kind of web app does everything with POST and forms and such like it's 2003, and I can understand that you'd prefer not to. I'm not saying they should or that they must all do without JS. I'm saying that if the article was a document that (also) documented the proper use of the web app within it then I would have liked to have been free to read it first. NoScript blocks ded things all the time and I temporarily allow them all the time. That workflow would have worked here, but if (as you seem to suggest is reasonable) the entire article was blocked because its app would be useless, then my strategy wasn't even considered, and someone is doing it wrong.
However, if a goal was to teach everyone to just run anything and everything and stop caring about privacy and security because it's a PITA, then someone is doing it right. I sure miss the good old days of Weekly_Report.doc.exe
Re: HTML is the Web
#157Earlier quoted context omitted.
I think what the author is saying is that paradigm 2 is built _on top of_ paradigm 1 and if you can't do #1 right, then by definition _neither_ can be right. It's astounding the number of interview candidates who are super-fluent in JS but can't tell you to save their lives why it's a bad idea to put a click handler on a div. React will die (It's already started to) and we'll migrate back to the actual Web at some po…
> It's astounding the number of interview candidates who are super-fluent in JS but can't tell you to save their lives why it's a bad idea to put a click handler on a div. Go on?
Putting a click element on a div is transparent to accessibility systems. And no, it isn't possible to consider an element with an onclick the same as a button, because events bubble, which means the element with the event listener isn't necessarily the element being watched for a click. IIRC there even used to be a "good practice" where people would attach a single click handler at the root and use it to dispatch events based on the `event.target` instead of attaching a separate handler to each target.
Re: HTML is the Web
#158Earlier quoted context omitted.
I think what the author is saying is that paradigm 2 is built _on top of_ paradigm 1 and if you can't do #1 right, then by definition _neither_ can be right. It's astounding the number of interview candidates who are super-fluent in JS but can't tell you to save their lives why it's a bad idea to put a click handler on a div. React will die (It's already started to) and we'll migrate back to the actual Web at some po…
I’ll bite: Why is it bad to put a click handler on a div? Because we’re losing the semantic content of the markup?
For one, it won't play nice with accessibility helpers... screen readers, keyboard interaction, etc.
Re: HTML is the Web
#159Earlier quoted context omitted.
I think what the author is saying is that paradigm 2 is built _on top of_ paradigm 1 and if you can't do #1 right, then by definition _neither_ can be right. It's astounding the number of interview candidates who are super-fluent in JS but can't tell you to save their lives why it's a bad idea to put a click handler on a div. React will die (It's already started to) and we'll migrate back to the actual Web at some po…
> It's astounding the number of interview candidates who are super-fluent in JS but can't tell you to save their lives why it's a bad idea to put a click handler on a div. Go on?
Because the user can't hover over it and see where the link goes. Because the click handler represents a Javascript program that has to be downloaded. Because it can't be used with Javascript turned off -- which is increasingly necessary these days since ad networks abuse Javascript.
But mostly because it's usually unnecessary and smacks of laziness on the developer's part.
Re: HTML is the Web
#160Earlier quoted context omitted.
I think what the author is saying is that paradigm 2 is built _on top of_ paradigm 1 and if you can't do #1 right, then by definition _neither_ can be right. It's astounding the number of interview candidates who are super-fluent in JS but can't tell you to save their lives why it's a bad idea to put a click handler on a div. React will die (It's already started to) and we'll migrate back to the actual Web at some po…
> It's astounding the number of interview candidates who are super-fluent in JS but can't tell you to save their lives why it's a bad idea to put a click handler on a div. Go on?
Using a button here would be more appropriate for a few reasons:
Buttons by default have keyboard support for focusing and clicking. You’d have to manually add this to a div.
Screenreaders, scrapers, and other automated tools reading your html understand buttons and treat them differently from divs.
It’s easier for other devs to understand your code at a glance if clickable elements are buttons.