Related: Stop Pushing the Web Forward (2015) https://news.ycombinator.com/item?id=9961613
I do freakishly experimental webdesign at times (like for designer portfolios, where freakishly experimental webdesign is kinda part of the thing), but for everything where it is much more about the info and the content I will bend over backwards to use semantic html (and even with those freakish sites I will try).
If you never looked at your website via lynx or used a screenreader I highly encourage it. It will give you a different perspective on things.
It’s been open-sourced and forked here if people would like to help keep it alive:
...which the text-to-speech reader probably pronounces as "ay eleven why".
Similar to i18n and l10n for internationalisation and localisation.
Interestingly unlike w3c, so it's not standing for aaaaaaaaaaay :)
A11y is probably the easiest one to remember because it looks like ally. Which is what you're being by worrying about accessibility when you yourself don't rely on the standards.
Agree with you re: screenreaders.
Look at <select multiple> for example—the browser built-in is borderline unusable. Anything that requires combining a click with the shift and ctrl/cmd keys is not going to go down well with the average user. Same goes for <select>s that need more advanced behaviour like filtering. There's <datalist>, but it's incredibly basic and pretty useless for most cases you'd want that sort of input.
The web is an app platform whether we like it or not, and I'd like to see a robust set of browser-native controls with mechanisms to customise styling and behaviour. It would improve accessibility, improve performance, reduce page sizes (because we wouldn't be re-implementing the whole world in JS), and it would at least go a little way to offsetting the slow erosion of quality desktop software that web technologies are bringing.
Now, if you wanted to say that HTML's standard widgets should be allowed to reflect the platform-native look-and-feel (for example, adding a "selected" checkbox on touch-screens, or supporting long-press to select items, or whatever) instead of being tied to Windows 95 appearance and behaviour by backwards-compatibility concerns, then yeah, I'd agree with that.
Even in the early desktop era when it was popular, many non-enthusiasts probably just didn't know how to use a UI control like that. It just didn't cause a problem because most people didn't use computers much.
I would bet that most internet users today have never even used a UI where that control is popular.
Never done tech support I take it!
It makes me think when I'm designing things. If I have problems with stuff like that, how can I make it better.
Then there's the way styles are so different, especially on the web. Horribly user-hostile. How does this site mark something as important, assuming it bothers in the first place? Who knows. And if I'm only planning to be on it for 30s, I'm not going to learn that.
It's a standard UI control and it is used pretty often.
Or you could just use a better control.
Many users don’t even know you can use a key shortcut to copy/paste.
"‡ On a phone or tablet or whatever, ignore us, we're just confusing you."
And it's also completely not discoverable. I only know how it works when I read from HTML book back in the day.
Just because it was the standard doesn't mean it's easily learned.
If you absolutely have to put words in my mouth, please make them at least a little less stupid ones. Maistuivat vähän paskalta.
This is part of the problem. Your average user at temporal point X has difficulty combining mouse clicks with keyboard modifiers. You build interface around that notion and in a later temporal point Y your average user cannot combine those at all and you have lost input mode. Your average user has problem distinguishing single click from double click. You install debounce logic, train them there is no difference between the two and lose input mode.
The web is a shitty platform for apps, because currently it is supposed to be used from at least proper PC, touchable handheld device, embedded in controlling container and in relatively near future virtual environments. Game developers have tried for literally decades to bridge the gap between PCs and consoles and mostly failed at that with both platforms being relatively static. The web being a moving target is much more difficult to fit on different device classes. Yet we try to do that and as a result are moving to the lowest common denominator.
For grand strategy / RTS, yeah, that's kind of a function of the complexity. Most other game genres are fairly well defined in the expected control schemes on both platforms now though.
This is how computers have worked since pretty much day 1, not just the web. I remember getting computing classes in school, but it seems the current generation is completely ignoring all of that and instead just plays on their phone.
More built-in widgets would be great though.
I like to imagine that if browser makers had collaborated better on standardising CSS hooks into the default widgets, we would not have seen such strong adoption of tools like bootstrap. We possibly would have had a different pathway through template+controller libraries too.
As a FED, I didn’t help. I rode the gravy train along with Backbone, Angular and React. I wish I had fought harder and spoken more eloquently on the practicality of a11y-first semantic mark-up and progressive enhancement. I caved in to the demands of the agencies who took me on to get stuff done in the trendy stacks.
Is there a reason the element has to be implemented that way? Correct me if I'm wrong, but aren't the details of how it works up to the browser? It only works that way because every OSs native select widget worked that way and once upon a time browsers actually tried to integrate well with the OS and used native widgets.
These users need to retake the computer literate 101 class.
When I'm in elementary school, we learned how to multi-select in the tutorial system that comes with Windows 3.1.
I don't know why Windows XP deleted these very important tutorials and replaced them with a webpage.
Seriously, I've seen pages that create links by using a styled <span> tag with an onclick even that merely called a function that set document.location using a hard-coded value.
Did developers forget that `<a href=....>` exists?
If you're prioritizing looking at new things over accessibility and cross-browser support then you are making that choice; browser vendors are not forcing it upon you.
Browser vendors do a lot to make it possible to write robust code that doesn't break in the future. Maybe they could do more, but if web devs are failing to leverage the features that are there already then why would they? A whole lot of the responsibility for the broken ass nature of the web is not due to browsers.
For instance Safari on iOS reports support for drag and drop events, but they aren't actually triggered. Another I encountered recently is the "accept" attribute on input file type. On iOS, you can't set specific file type, just mime type, but you have no way to detect that except by using the user agent. Then you have the buggy releases that make a feature seemingly supported, but is actually unusable in practice (looking at you IndexedDB on Safari).
This means using a library like Modernizr is almost mandatory. Also, what do you feature-test? Everything? Feature-testing something that has been available for 20 years sounds like a waste of time on the face of it, but the "alert" case has shown us that if you really want to do it correctly, you can't assume anything. I am not saying it is not possible to do it properly, but it is not that simple. For anything non-critical, I understand waiting for things to break then fixing them instead, it's way less efforts.
This reminds me of Spolsky's blog post about Fire and Motion. [0] He gives the example of Microsoft creating an endless stream of new technologies which kept their competition busy (eg: ODBC, RDO, DAO, ADO, OLEDB, ADO.NET, ...). Get the competition to spend their resources keeping up rather than competing.
0: https://www.joelonsoftware.com/2002/01/06/fire-and-motion/
I've done it by testing with historic browsers alongside modern, and challenging myself to make it work with all of them, JS and noJS, without errors, reliably.
In the process, I found a set of "lowest common denominator tags which work across almost anything. I use these to build the "base" HTML. Then, I add JS with feature-checks to allow older browsers with JS enabled to still run it, though it doesn't do much at the moment.
I think it's a worthwhile exercise to learn where the roots of the web are, and how it evolved, and allows you to write much more resilient code in general. The reason for this is that the longer a technique or syntax has been in use, the longer it's likely to continue to be used.
Lindy effect is the name of the trend.
Most of the older browsers are covered by three VMs: Windows 95, Windows ME, and Windows NT 4.0.
Most Windows Netscape can run in Wine, so I can use symlinked .wine directories to switch versions.
I also do occasional testing at Best Buy or Walmart (many thanks to those places) at a cross-section of their available devices -- a couple of desktops, a couple of phones and tablets of each flavor, etc.
I also often ask people if I can test out my website with their device (or if they want to participate in a 5-minute user study)
For difficult things like Mac IE, I just have a couple of devices e.g. G4 Macs and iOS 7 iPad.
Of course, there are text-mode browsers, which I usually install with apt or whatever.
I also use online emulator services like BrowserStack, they have a pretty good slice in their free tier, and a couple of minutes is enough for smoke testing.
Also, I sometimes come across public devices, such as desktops in survival center, library, hotel, or public community space, and I test on those.
With my own devices, I test across various public wifi locations, so that I can provide workarounds for e.g. content blockers or inadequate proxying.
I use Charles Proxy locally to simulate low-bandwidth connections and other common issues.
I have also asked rare use-case users, such as visually impaired, to test using a script, usually through topical Facebook groups.
That's about all I can think of for now, there's probably more.
Yes the classic memory-related bugs come from the engine, but the comment explicitely mentioned leaks and I don't think that was about the memory ones. Many of the new "features" turned out to leak sensitive or at least identification-enabling information. Imo having remote code execution without a big red warning that this is stupid and you should not do it that users can't click away without being forced to think about it just isn't a good idea, even if it is sandboxed. At the very least we should have a permission-based system where users need to authorize every single Javascript API, for every single connection/file/database/whatever and be unable to ignore it without disabling the APIs. That would imo be the best compromise since web-devs would be forced to think about what they are doing to users computers¹ while still allowing applications to be built.
¹ My hope being that they wouldn't include [bullshit fontend framework] except when absolutely necessary
https://twitter.com/JimMcKeeth/status/692596120464150528/pho...
Indeed, users don't read error messages, and will just click whatever they think they need to click to move on.
Few years ago, at revolution, Chrome told us about MITM attack and refused to connect to Google servers, while Firefox noticed nothing.
Few years later, attackers used my Chromium, which I used for work, to spy on my Firefox window, which I use for private browsing, by capturing of whole screen when Chromium sit unused. (I have it recorded on video).
[0]: https://www.quirksmode.org/blog/archives/2021/08/breaking_th...
See jQuery (both Ajax and selection), Moment/Temporal, etc
I think it's OK for Google to make Chrome into an OS and cram whatever they want into it as fast as they can.
Regular web browsers don't necessarily need to be on the same feature treadmill/death march (assuming they could keep up.)
We seem to be trying really hard to reinvent the applet systems of the 1990s, but in a way that brings systems with 10-100x the memory and CPU resources to their knees and requires huge armies of programmers to implement. I guess JavaScript/webasm is better than Java in some ways.
> Regular web browsers
Chrome is a "regular web browser". It holds a 70% market share among web browsers.
> Regular web browsers don't necessarily need to be on the same feature treadmill/death march (assuming they could keep up.)
They either don't need to be on the same death march, or keep up. You can't have both.
Currently, it's a major problem, because Chrome churns out 40-70 new web APIs with every release which happens every two months or so [1]
So, no, it's not OK for Google to convert Chrome into an OS.
It certainly is an insane amount of feature churn.
But the right perspective might be to look at the impact on end users.
The issue for end users seems to be that they occasionally encounter "web sites" (really web apps) that only work properly with Chrome. This is sort of a bummer for iOS users, but for the most part they seem to get by just fine. Perhaps there will be a tipping point where the "web" becomes unusable from iOS, but it hasn't happened yet.
I consider this a comparable problem to encountering web sites that only worked with Internet Explorer, or Flash, or Silverlight, or Java. Certainly annoying, but not really catastrophic.