4 ms·

We should also make caniusebutdoesitactuallywork This to refer to my annoyance of browser makers leaving incomplete implementations stagnant for years. As an

by fleddr 5y ago

We should also make caniusebutdoesitactuallywork This to refer to my annoyance of browser makers leaving incomplete implementations stagnant for years. As an example, the <dialog> element, a browser-native standardized spec as promising replacement for alert. Except that it doesn't work, it's inaccessible at its core. And nobody fixes it, it's just left in this broken state forever. <section>, the element that was supposed to cut up an HTML document into multiple outlines, hence making componentized SEO-optimized headings easy and better, do nothing at all. CSS columns, a simple and easy way to distribute text, were unusable for 8 years because Mozilla refused to fix their own small bug. Which pales compared to the extraordinary amount of Webkit bugs that are absolutely never ever fixed. Form controls, since the very invention of them, are terrible. It has cost the world billions, as worldwide every single developer and project has to reinvent some of them, often breaking basic accessibility in the process. I could go on, but I'll sum it up as the failure to address extremely common real world problems, and to just let broken buggy solutions linger. When you accept a standard and implement it, bloody finish the implementation. Fix bugs. Otherwise, what is the point? I'd call this hardening the web. There's no reason I can see why you can't harden it whilst also making progress on new features.

dylan604 5y ago
Fixing bugs vs adding new features doesn't bring in new users, so it doesn't get prioritized. And if as you say these bugs are in features that nobody uses, why bother? Nevermind nobody might be using them because of the bugs, but the PR buz over those features has already been had, so on to the next.
- fleddr 5y ago
  Not sure I fully agree. The features we're talking about here are in the developer space, not the end-user space. When a browser maker implements a brand new web standard, I don't think the correlation with new end-users is that strong. It takes forever before any new standard is popularized and widely used. Check release notes of browsers, almost all features no user will ever directly experience.
  - dylan604 5y ago
    I don't disagree with this so... sed "s/users/devs/g" previousComment
eyelidlessness 5y ago
> caniusebutdoesitactuallywork MDN/caniuse cover quite a lot of this already. > <section>, the element that was supposed to cut up an HTML document into multiple outlines, hence making componentized SEO-optimized headings easy and better, do nothing at all They do a lot for Reader view and I’m fairly certain they help with screen readers where heading hierarchies might otherwise be ambiguous. - - - Overall, I share your concerns but feel they’re overstated. Mostly because I remember the bad old days of NS4, IE4-6, etc. The web as a set of reliable standards isn’t perfect but it’s worlds better than I ever anticipated. Just as a matter of perspective: when I started web dev, I learned and used by rote dozens upon dozens of hacky incompatibility workarounds. I moved more backend in recent years, but have had more web work over the last year. I can count on one hand the number of browser compatibility issues I’ve had to address (yes, all Safari). And not because build tools are helping. If anything build tools are the biggest source of frustration for me now.
- fleddr 5y ago
  Overstated in comparison to darker times? Very much. I started web development in 1996, so I know what you mean. But it doesn't lessen my annoyance. How can you deliver a 90% implementation, and then let it rot for a decade? Effectively delivering 0%, because it's unusable. It just doesn't make sense to me.
- fleddr 5y ago
  Looks like I missed your remark on sections. I'm not sure about Reader view, but <section> does nothing for screen readers as it comes to headings. It doesn't start a new nesting level. You can label a section and this way mark it as a landmark to a screen reader, but that's something you can do on any element. Meanwhile, developers trying to keep up incidentally may use <section> in an effort to produce more semantic value over a <div>, but they all use it incorrectly. Perhaps because just understanding how to use it correctly seems impossible. Or, better said, it has no function at all: https://www.scottohara.me/blog/2021/07/16/section.html https://www.scottohara.me/blog/2021/07/16/section.html
handrous 5y ago
> Form controls, since the very invention of them, are terrible. It has cost the world billions, as worldwide every single developer and project has to reinvent some of them, often breaking basic accessibility in the process. We're close to being down to two browser engines that matter, one of them with well over half total market share, and they still don't bother to fix forms. You're right about the costs, they're immense. Billions isn't an overestimate for ball-parking the figure, I'd say. Shit, Firefox, you want to do something to stay relevant, be the first to do that right. Go nuts with some (well-considered) non-standard extensions, behaviors, and tags, worst case no-one uses them and no other browsers adopt them, best case you achieve arguably the greatest thing your project ever has (which is saying something—early FF, especially, was awesome). It may be too late (like every other idea I can come up with to save FF, they should have started at least a decade ago) but it's worth a try.
- fleddr 5y ago
  They actually did do something on forms: https://blogs.windows.com/msedgedev/2019/10/15/form-controls-microsoft-edge-chromium/ https://blogs.windows.com/msedgedev/2019/10/15/form-controls... It's a restyle into the timely (cough) flat design. I guess any progress is good progress, but it's meh. Firefox can't do anything regarding relevance. It's not an engineering problem, they can't push their browser, they have no reach.
  - handrous 5y ago
    > Firefox can't do anything regarding relevance. It's not an engineering problem, they can't push their browser, they have no reach. I don't think that's true, considering they became popular originally though features and overall program quality. I wasn't using it and recommending it to (and/or installing it for) everyone I knew back in the Phoenix/Firebird/FF1.x days because of advertising or whatever, but because it was excellent and solved a lot of problems for people, and that exact mechanism is how they gained a foothold to begin with—every power-user and nerd was doing exactly what I was, and pushing everyone who'd listen to switch to Firefox. There are other ways to gain relevance, obviously (say, promoting your browser prominently on your search engine) but simply being better than alternatives definitely can work. The proof is that it already did, for Firefox in particular, once.
moron4hire 5y ago
I was just talking with someone today about how Fetch API is now 10 years old and still isn't a complete replacement for XmlHTTPRequest (or is it XMLHttpRequest? I can never remember) because it can't do file upload progress tracking. It's been a decade of "the spec doesn't support that yet". Yet? Will it ever? At what point do you admit you're just not going to do it?
- fleddr 5y ago
  Indeed another fine example, forcing developers into massive packages like axios. Since we're in a salty mood, let's keep it going. jQuery, the much despised jQuery. Inspired by jQuery, browsers now have native DOM APIs that are somewhat equivalent, reducing the need for jQuery. Except that their syntax is terrible, and chaining isn't possible on most methods. So an elegant chained one-liner in jQuery becomes a blob of ugly syntax spanning many lines using native methods. A massive regression.
runarberg 5y ago
Can you elaborate on <dialog>? It is currently implemented behind a feature flag in Firefox, and not implemented at all in Safari. So the answer with caniuse is maybe with a polyfill. How exactly is it inaccessible at the core? As far as I know a <dialog> is required to have at least one focusable element inside it (I usually have a close button in the dialog’s <header>), and then the user agent is supposed to trap focus inside it. Is it not usable for users with assistive technology? Is it a bad UX for them? Is it broken or buggy? Does the polyfill not workk? etc.
- fleddr 5y ago
  Have a look at this: https://www.scottohara.me/blog/2019/03/05/open-dialog.html https://www.scottohara.me/blog/2019/03/05/open-dialog.html To sum it up, <dialog> is a specced standard of which the first implementation appeared 8 years ago. It is a perfect example to illustrate my original rant. It is a feature in high demand, almost every web application needs it. Hence it makes sense to have a native control and for each browser to implement it, eventually. No such thing happened. A broken implementation is delivered, and more importantly, never fixed. It doesn't work cross browser and in the browser where it works, it actually doesn't. And now, nothing happens, they just gave up on it. Which indeed leaves us with custom implementations, but my point is that we shouldn't need those. It was specced for a reason, it's high on the list of developers needs.
  - jrochkind1 5y ago
    That is distressing. > tldr; I’m just going to say right now that the dialog element and its polyfill are not suitable for use in production. And it’s been that way since the dialog’s earliest implementation in Chrome, six-ish years ago. With the announced intent to get rid of window.alert/confirm (discussed elsewhere in this HN post comments), it would be nice if dialog got some attention as a replacement... I'm not sure what we're going to do when it goes away; everyone has to roll their own replacement? Doh.

by fleddr 5y ago

dylan604 5y ago

Fixing bugs vs adding new features doesn't bring in new users, so it doesn't get prioritized. And if as you say these bugs are in features that nobody uses, why bother? Nevermind nobody might be using them because of the bugs, but the PR buz over those features has already been had, so on to the next.

fleddr 5y ago
Not sure I fully agree. The features we're talking about here are in the developer space, not the end-user space. When a browser maker implements a brand new web standard, I don't think the correlation with new end-users is that strong. It takes forever before any new standard is popularized and widely used. Check release notes of browsers, almost all features no user will ever directly experience.
- dylan604 5y ago
  I don't disagree with this so... sed "s/users/devs/g" previousComment

eyelidlessness 5y ago

> caniusebutdoesitactuallywork MDN/caniuse cover quite a lot of this already. > <section>, the element that was supposed to cut up an HTML document into multiple outlines, hence making componentized SEO-optimized headings easy and better, do nothing at all They do a lot for Reader view and I’m fairly certain they help with screen readers where heading hierarchies might otherwise be ambiguous. - - - Overall, I share your concerns but feel they’re overstated. Mostly because I remember the bad old days of NS4, IE4-6, etc. The web as a set of reliable standards isn’t perfect but it’s worlds better than I ever anticipated. Just as a matter of perspective: when I started web dev, I learned and used by rote dozens upon dozens of hacky incompatibility workarounds. I moved more backend in recent years, but have had more web work over the last year. I can count on one hand the number of browser compatibility issues I’ve had to address (yes, all Safari). And not because build tools are helping. If anything build tools are the biggest source of frustration for me now.

fleddr 5y ago
Overstated in comparison to darker times? Very much. I started web development in 1996, so I know what you mean. But it doesn't lessen my annoyance. How can you deliver a 90% implementation, and then let it rot for a decade? Effectively delivering 0%, because it's unusable. It just doesn't make sense to me.
fleddr 5y ago
Looks like I missed your remark on sections. I'm not sure about Reader view, but <section> does nothing for screen readers as it comes to headings. It doesn't start a new nesting level. You can label a section and this way mark it as a landmark to a screen reader, but that's something you can do on any element. Meanwhile, developers trying to keep up incidentally may use <section> in an effort to produce more semantic value over a <div>, but they all use it incorrectly. Perhaps because just understanding how to use it correctly seems impossible. Or, better said, it has no function at all: https://www.scottohara.me/blog/2021/07/16/section.html https://www.scottohara.me/blog/2021/07/16/section.html

handrous 5y ago

> Form controls, since the very invention of them, are terrible. It has cost the world billions, as worldwide every single developer and project has to reinvent some of them, often breaking basic accessibility in the process. We're close to being down to two browser engines that matter, one of them with well over half total market share, and they still don't bother to fix forms. You're right about the costs, they're immense. Billions isn't an overestimate for ball-parking the figure, I'd say. Shit, Firefox, you want to do something to stay relevant, be the first to do that right. Go nuts with some (well-considered) non-standard extensions, behaviors, and tags, worst case no-one uses them and no other browsers adopt them, best case you achieve arguably the greatest thing your project ever has (which is saying something—early FF, especially, was awesome). It may be too late (like every other idea I can come up with to save FF, they should have started at least a decade ago) but it's worth a try.

fleddr 5y ago
They actually did do something on forms: https://blogs.windows.com/msedgedev/2019/10/15/form-controls-microsoft-edge-chromium/ https://blogs.windows.com/msedgedev/2019/10/15/form-controls... It's a restyle into the timely (cough) flat design. I guess any progress is good progress, but it's meh. Firefox can't do anything regarding relevance. It's not an engineering problem, they can't push their browser, they have no reach.
- handrous 5y ago
  > Firefox can't do anything regarding relevance. It's not an engineering problem, they can't push their browser, they have no reach. I don't think that's true, considering they became popular originally though features and overall program quality. I wasn't using it and recommending it to (and/or installing it for) everyone I knew back in the Phoenix/Firebird/FF1.x days because of advertising or whatever, but because it was excellent and solved a lot of problems for people, and that exact mechanism is how they gained a foothold to begin with—every power-user and nerd was doing exactly what I was, and pushing everyone who'd listen to switch to Firefox. There are other ways to gain relevance, obviously (say, promoting your browser prominently on your search engine) but simply being better than alternatives definitely can work. The proof is that it already did, for Firefox in particular, once.

moron4hire 5y ago

I was just talking with someone today about how Fetch API is now 10 years old and still isn't a complete replacement for XmlHTTPRequest (or is it XMLHttpRequest? I can never remember) because it can't do file upload progress tracking. It's been a decade of "the spec doesn't support that yet". Yet? Will it ever? At what point do you admit you're just not going to do it?

fleddr 5y ago
Indeed another fine example, forcing developers into massive packages like axios. Since we're in a salty mood, let's keep it going. jQuery, the much despised jQuery. Inspired by jQuery, browsers now have native DOM APIs that are somewhat equivalent, reducing the need for jQuery. Except that their syntax is terrible, and chaining isn't possible on most methods. So an elegant chained one-liner in jQuery becomes a blob of ugly syntax spanning many lines using native methods. A massive regression.

runarberg 5y ago

Can you elaborate on <dialog>? It is currently implemented behind a feature flag in Firefox, and not implemented at all in Safari. So the answer with caniuse is maybe with a polyfill. How exactly is it inaccessible at the core? As far as I know a <dialog> is required to have at least one focusable element inside it (I usually have a close button in the dialog’s <header>), and then the user agent is supposed to trap focus inside it. Is it not usable for users with assistive technology? Is it a bad UX for them? Is it broken or buggy? Does the polyfill not workk? etc.

fleddr 5y ago
Have a look at this: https://www.scottohara.me/blog/2019/03/05/open-dialog.html https://www.scottohara.me/blog/2019/03/05/open-dialog.html To sum it up, <dialog> is a specced standard of which the first implementation appeared 8 years ago. It is a perfect example to illustrate my original rant. It is a feature in high demand, almost every web application needs it. Hence it makes sense to have a native control and for each browser to implement it, eventually. No such thing happened. A broken implementation is delivered, and more importantly, never fixed. It doesn't work cross browser and in the browser where it works, it actually doesn't. And now, nothing happens, they just gave up on it. Which indeed leaves us with custom implementations, but my point is that we shouldn't need those. It was specced for a reason, it's high on the list of developers needs.
- jrochkind1 5y ago
  That is distressing. > tldr; I’m just going to say right now that the dialog element and its polyfill are not suitable for use in production. And it’s been that way since the dialog’s earliest implementation in Chrome, six-ish years ago. With the announced intent to get rid of window.alert/confirm (discussed elsewhere in this HN post comments), it would be nice if dialog got some attention as a replacement... I'm not sure what we're going to do when it goes away; everyone has to roll their own replacement? Doh.