On paper you’re right. The most interactive svg content I’ve seen are small demos and even those have to be hunted for. You don’t have to (or at least you didn’t in the past) have to look very hard to find large amounts of quality flash content. Good tools were ripped out of artists’ hands and the internet is worse for it. Where’s the replacement?
Yeah have you tried authoring and animating SVG in 2008? Full of (browser support) holes and extremely poor performance, even on the "powerful" iPad in 2011. Flash by comparison would have been a breeze even on mobile.
I wonder if it's because, if one needs an expressive language, for vector graphics or whatever, then redundant things like XML and JSON are horribly non-concise choices, whereas Flash didn't suffer such problems, along with having excellent authoring tools.
it was the right move. at that time flash was the biggest vector of attacks and the largest battery drain, why would you ever consider putting it in in the first place?
apple was just bold, big and loved enough to survive the backlash from flash fanboys who, outraged, went buying android phones and proceeded to never use flash there either.
Yet I’m not sure we would have reached that point now without the “dick move” then. Apple has always taken an aggressive stance to cut out things that reduce battery life. Blocking Flash and background processes were natural consequences
Not really, by 2005 or so we all knew flash was terribly problematic and making the web much worse. Some people embraced it for sure, but in my experience most people involved with the web at this time had objections to Flash (and Adobe more widely).
Flash was fine for specific purposes .. animations and games mostly. Doing your whole site in Flash was dumb, but Homestar Runner and Newgrounds used it in really good ways.
Eh, I remember traveling in the early days of tablets and being delighted that it worked as an almost complete replacement for a laptop (or at least, the limited use of a laptop that one needs whole traveling), in a way that iPads didn't remotely approach. They couldn't even play embedded video!
I'm not a big fan of the tablet form factor in general, but it didn't make a lot of sense to hamstring it further by removing Flash.
Good riddance, I remember when web browsing on Linux was obnoxious because every other site used Flash but the only plugin available was an older version for Firefox that had serious glitches like desyncing audio. It wasn't until like 2009 that Adobe started providing better binaries.
I wonder what NewGrounds is going to do about all their older content?
I worked on Flash when the iPhone came out. Back then it still only had software rendering and the performance on early mobile CPUs was atrocious. They had Flash and Flash Lite but they both were terrible on the early Android phones that supported them.
I love Flash games but putting it on the iPhone would've just made the users mad at the 5 FPS performance.
It was basically his revenge to Adobe, which hesitated to migrate Photoshop to Intel processors, requiring user to run Photoshop in powerPC emulation mode (slow).
I work in marketing and spent years trying to convince people to use less Flash ... but hey look at this snazzy thing a designer just cooked up. This got the to the point where they launched a site and were like "why isn't google indexing our home page?" and I'd have to say "well, I told you so."
Turned-out the creative people that matter listen to dicks like Steve Jobs where they don't listen to me. Note about 80% of where we were using flash were replaced by he trivial JS/CS or maybe a jquery plugin, it simply wasn't needed.
Are we really sure it was Apple's fault? Their browser market share was always rather small and smaller outside the US. But Adobe seemed to reeeeeally abandon the thing after apple's decision. They could have at least open sourced it
We'd be in a very different world of Adobe and Macromedia never merged. Adobe really killed flash, but maybe it was inevitable. From what I read, Flash's test suite was subpar to non-existent and people were afraid to touch anything in the codebase.
It's so sad too because Flash is still amazing when it comes to animating vector graphics in a crossplatform way. Nothing in the HTML5 world remotely comes close.
You can upscale Homestar Runner to 4k and it renders beautifully. Now that it's all YouTube videos, whatever resolution they rendered it at, there it will stay for forever (plus you lose all the clickable eastereggs in the Strong Bad e-mails!)
> From what I read, Flash's test suite was subpar to non-existent and people were afraid to touch anything in the codebase.
If that's the case, Flash should be held up as a case study for the utility of robust tests. Because the amount of refactoring needed to make it fit the mobile world was significant, and if the codebase was fragile because of lack of tests, that refactoring may have proved expensive enough to kill the whole technology stack.
Adobe claimed that it was Apple’s fault that Flash didn’t run on the original iPhone. But even if Apple has allowed it. Adobe still wouldn’t have been able to do it.
When Adobe finally did make it to Android, it required a gig of RAM and a 1Ghz processor. The original iPhone had 256MB of RAM and a 400Mhz processor. An iPhone with those specs didn’t come out until 2011.
One of the big selling points of the Motorola Xoom was that it would run Flash. Adobe was six months late leaving the Xoom in the embarrassing position that you couldn’t view its Flash enable home page from the device for at least the first six months.
Flash on mobile was always going to be shit because it was built without mobile in mind. It doesn’t support touch, it doesn’t make controls big enough to be usable by touch and it doesn’t implement the behavior people expect on a touch device.
Just running the plugin on a phone isn’t the hard part.
If the other problems would have been solved, the hardware has improved so much the performance issues wouldn’t have been much of an issue anymore. A modern phones performance can compete with a low end pc.
It was five years before an iPhone met the minimum requirements that Adobe gave for Flash on mobile. Even then, a VM based runtime per app would be more memory intensive and more battery intensive. iOS devices just this year have start coming with 3GB of RAM across the board. iOS was able to get away with less RAM precisely because all code ran natively.
Apple is able to optimize its OS, compiler chain, and processor in sync.
Not to mention that an even more stripped down version of the core OS with tighter constraints is running on the watch.
Not even mentioning that the average $250 Android device is much lower specced than the average iPhone. It wasn’t until last year that even high end Android phones were matching the performance of an iPhone 6s (released in 2015) in single core performance.
The adtech industry embraced flash in a big way, youtube was defaulting to the flash player until four years ago. Plus the dozens of flash ads and trackers that were (and still are) placed into many ad networks.
Now that the adtech firms switched to building the browser and the cluster of html5 technologies have matured it's easier to track people natively. That's really the only reason flash went away.
There was no Flash on the most popular smartphone (before Android took over). When ad tech went mobile they couldn't use Flash. So, ad tech shifted to web tech.
There are frameworks that let you compile flash games/apps/videos into native executables with pretty good compatibility (so minimal porting effort). That's probably the best we've got besides using an out-of-date insecure browser.
I'm sure there will be, there are a few implementations/emulators out there. Gnash, Shumway, Lightspark, and Ruffle. Ruffle seems to be pretty promising, it's being worked on by Newgrounds people and it's written in Rust to target the desktop and WASM. It looks like they can do animations and audio now, and they're working on the various versions of ActionScript.
Sadly Flash is incredibly hard to write a 100% implementation for. That's why there are so many attempts; they've all failed (but they can work well for specific Flash games/apps).
It would be great if Adobe could open source their existing Flash Player at some point.
I struggle to see how doing so would harm them commercially. Even if an open source player is available, browser vendors have no interest in supporting it, so it won't be supported with browsers. It isn't going to take away interest in their newer pure HTML5 authoring tools.
There's nothing to run Flash media outside a browser? Obviously that wouldn't help anything dependent on proprietary server functionality, but that's true of any software.
There's actually a project just for that. It aims to archive every single flash games on the internet in a playable format outside of the web browser. It can even simulate situations where the flash game needs to access asset files from the original server.
https://bluemaxima.org/flashpoint/
Steve was right very briefly but in hindsight it's pretty irrational to expect a piece of software to not run on a powerful CPU without contrived restrictions like being "banned". We'd have the full Adobe Flash IDE on the iPad next year if Jobs had no grudge and we just waited for the software and hardware to improve. Photoshop's halfway there and SQL Server made it to Linux and Windows made it to ARM.
The solution was to wait for the software to get better, the hardware to get better, the batteries to get better - today the Flash IDE could run on Windows tablets not much bigger than the iPad Mini, authoring content where before it couldn't even play it back.
Why should Apple wait for some other company when they were perfectly capable of shipping something way better? Adobe had the opportunity, and they missed.
I think a better question is why should Apple persecute anybody's software? Especially just because it's not yet performing well on a new, power-sipping processor and architecture. It will be years before anything complex runs well on their watches, that's a stupid reason to sabotage anyone's efforts.
Adobe could have made a great player for the Mac, but they deliberately chose not to. It was awful, power hungry and laggy on Apple desktops and Macbooks. Adobe didn't care about the Mac ecosystem, the player was/is closed source and Apple couldn't not do anything. Why on Earth should Apple invest on a tech that is proven to not work reliably on their platform. Adobe blew it, Apple just made the right decision.
For Apple, definitely. Jobs' opposition to Flash was rooted in the business case for the App Store and the technical limitations of the first couple of iPhones.
I remember when the first 7" Galaxy Tab came out in late 2010. Jobs mocked its size, saying you'd need to file down your finger to use it, while at the same time working on the iPad Mini, which wouldn't launch until after his death.
The triumphalist note in many of these posts makes me sad. Flash had a ton of warts, yeah I get that. But there is a failure to acknowledge the collateral damage done to Actionscript that I find troubling. Itemrenderers, the ability to inline functions in MXML components and a decent OO framework gave me a powerful platform for rapidly iterating UI designs. The tools I currently use just don't measure up (I'm looking at you, C#) and it's left a bitter taste in my mouth.
One of the first "commercial" games I worked on was a Flash (Flex) game that I licensed to a few of the big Flash games sites at the time. I haven't looked at that stuff in years and years... I wonder how feasible it would be to port those games to the modern web.
There's plenty of new browser games being made, but both developer and user interest in mini-games has shifted to native mobile apps, which wasn't really a thing in Flash's heyday.
To be fair, the absolute bulk of browser-based Flash games weren't imaginitive or fun either (and I can assure you, would probably not have been free if drop-in-and-use ad plugins for Flash had been around, if the ads that framed those apps can be taken as any indication ;) ).
Flash was arguably never part of "The Web" in the first place. Not the open web anyway. It's a proprietary technology with a single implementation controlled and developed by a single company (Adobe) which is now ending support for it.
The difference is that with Flash, you could write once and run it everywhere. This was huge at a time when cross-browser differences were major enough to require something like jQuery.
Sure, that's the advantage of having a single implementation. The disadvantage is what we're experiencing right now: once that implementation is no longer maintained you're left with no alternative.
That's true. My point was that even with Flash announcing several years ago that it would be sunset, nobody stepped up to build tools that worked with the open technologies of CSS, SVG and JS.
Instead, what we have is a situation where pretty much only corporations with designers and devs on staff (Stripe and Spotify being the major examples) are building the types of sites that used to be doable by a single person using Flash.
I predict that they will need to create extensions or exceptions that will bring back flash for people that need it. Thanks largely to the difficulty and bad functionality of HTML5 equivalents, there is still important stuff in libraries / public orgs / museums / archives / university sites etc. that is not ready to die, and unless google/MS are willing to pay the redigitization process, they 'll have to bring back flash.
Harsh. I'm sorry they invested their own time and effort into building a search crawler atop a closed-source, proprietary data format (risking not just capital and engineering time, but possibly lawsuits if Adobe had gotten pissy like Oracle) and, having looked at the field of users and decided that there is insufficient interest in the data format to justify maintaining that crawler, they're decommissioning it?
They made a product decision; they didn't shoot your dog.
And it's not even like their product decision removes the ability of the orgs you've listed to keep using Flash. Those orgs just can't keep relying on a free-but-proprietary search engine provided at the largesse of a corporation they have no business deal with anymore to index their proprietary-format media, for free.
Wouldn't unity qualify? Personally I think the decline in browser based games has more to do with a lack of interest in that gaming format, not the limitations of current web technology.
This is what I figured, that today's equivalent of Flash gamers are just on mobile games instead. I do miss the anarchic quality that the Flash ecosystem had in the 2000s, but I think that's more a function of the type of people who spent time online back then.
They did and it was pretty good 3 years ago when I last used it. It's possible to merge it with your own code, but it was bad at managing images and SVGs. Flash's strong suit, at the time, was the vector rendering.
The major components of Flash are a vector graphics engine, a timeline based video editor, and a scripting language. Leaning on browser SVG support and exec(), you could write an extremely bare-bones version in a couple of weekends.
It'd be a great open source project. As a commercial product, it'd probably be enough to support a small team, but I don't see a way for it to get huge.
I created quite a popular tower defense in flash back in 2007 and I’ve been thinking about redoing it in HTML5 but realized some major issues around tab backgrounding that will cause complexity in the remake vs Flash.
It's a lack of IDE. There's nothing stopping a game riding atop the browser's engine from being performant and fun, but the tooling to get there is nearly non-existant for a lot of people.
Now if only ADP would update their timesheet software so it did not rely on Flash, that would be great. I'm going to have to install Flash manually once Google drops it from Chrome.
Well, that will get momentarily interesting, then. Perhaps our company will finally abandon ADP for the last few services we still contract with them for.
iPhone apps were fast and responsive on low end hardware precisely because apps were natively compiled and didn’t run in a VM. Did you ever try running Flash on early high end Android phones?
I 'm sure they were slow. but i m talking about the authoring tool and scripting language. I presume apple could optimize that to be fast natively. Judging from how HTML UI frameworks evolved over time, it's as if we ended up reinventing Actionscript
So what was Apple going to do during the first 4 or 5 years? Every single mobile platform that tried using HTML frameworks for their apps failed and were slow.
Blackberry, Palm, and Microsoft all tried it. Android itself was slow as molasses for years because of its dependence on a VM instead of a completely native stack.
Adobe refused to make the flash player work reliable on OSX back in the day. It was Adobe's fault, and anyone that used the web on a Mac in the 2000's can confirm that.
Flash could have survived if Adobe open-sourced the codebase. But they kept it in-house and didn't have enough resources to mutate it in light of rapidly-evolving demands placed on web technologies by mobile architectures. I suspect there'd have been plenty of volunteers stepping up (including, possibly, from Apple itself) if Adobe hadn't decided to dragon-hoard its IP.
But in the web era, IP isn't king; communications is.
Google basically killed off Google Finance last year because it was Flash based. There's an HTML version of Google Finance but it doesn't have anything close to feature parity with the Flash version.
Designers loved Flash because it was WYSIWYG. It's also why PDF lives. You usually only had to test it on one computer, not different versions of different browser brands. The client-side "auto-flow" of HTML browser drives designers batty. I can relate: I make CRUD GUI's and different browser variations butcher their placement to hell and back, requiring me playing Whack-A-Mole to fix it. The online forums say, "Shut up and learn layout rocket science!" A few snotty Sheldons mastering auto-flow math doesn't scale well.
The browser should have a WYSIWYG mode for when your application needs it. The server could re-scale as needed for different devices based on a layout engine of the designer's choosing. That way one is dealing with one layout engine instead of say 50 (browser brand/version combos). Seems more logical to me. We don't need auto-flow rocket science if we just partition layout engines logically.
I believe Flash and Java Applets both made the same fatal mistake: tried to be an entire virtual OS. That made them too complicated, which invites hackers. If they had focused on just UI "serving", they could have been small enough to be manageable.
I haven't seen it work well. Part of the problem is that JavaScript is needed emulate many common GUI idioms, and the emulation or rendering is sometimes buggy on different browsers. It's back the the brand/version combinatorial explosion.
The industry really needs a dedicated GUI-friendly standard. Emulating GUI's keeps failing. If you fail 30 beauty contests, the blunt truth is you are ugly. Get a clue and change direction.
There's hope. If you look at the GUI for Figma (an Illustrator and Sketch vector drawing competitor), they've built it using the Canvas tag...and it works AMAZINGLY well. I don't know how they did it, but it feels more like butter than Sketch, and I love Sketch. I'm waiting for someone to come along and basically build the Flash equivalent of a canvas tag renderer. But it's going to take some serious smarts.
There is some precedence. Rich Harris (of Rollup & Svelte fame) has been toying with the idea of a precompiler for Web GL...
Context matters. If you're building essentially square box with interactions (essentially flash) , it would probably be fine.
But if you're trying to optimize across several displays HTML can re-flow for you and isn't generally terrible unless you're doing things that need to be pixel-perfect.
That's not my experience. It requires too much fiddling and diddling to get things right that wouldn't be drama under 90's GUI IDE's. (Early versions sucked, but they got better with time.) Maybe a few experts somehow master all the arcane CSS/DOM rules, but that's the exception. Arcane fiddling may be great job security, but it's not economically logical on a planet-wide view.
Doing it with canvas / svg is a bit like saying you can do a videogame because you have access to webgl and web audio API.
In the most technical sense, yes, but it's way too low level an abstraction to be practical. Flash's entrypoint abstraction was the timeline, which already bundles up a huge amount of complexity around time-based transformation of content that you'd have to build atop canvas to approach Flash's convenience.
In terms of predictable layout and control, Flash is still lightyears beyond HTML+JS; and that's nothing short of a catastrophic failure on the part of browsers.
That said, Flash was/is an accessibility nightmare. It broke screen readers, and the animations and custom interfaces regularly created unnecessary cognitive load and confusion.
I don't think that it's particularly difficult to make extremely predictable layouts in HTML+JS if you have the same constraints as flash (particularly a fixed canvas size).
This has been a very interesting change in Hacker News. Back in 2010 when I first learned about it, I was coming from Slashdot. And for me it was a (refreshing) surprise that people here were not anti-paid software, anti-business, etc. After all, it is a forum within a VC firm that looks to fund startups to make a profit. The discussion was more pragmatic.
Somehow nowadays the group think has kind of changed into what Slashdot was 10 years ago. Which is funny, since the objective of YC has not changed.
I like how both of you assume that just because someone wants free software they don't support developers. They may be donating, which is what I do, on the other hand I guarantee you that you're making use of several pieces of free software daily and yet your mindset seems to be, if it's not proprietary, or requiring payment, then it's not worth supporting.
I mean I knew this mentality exists, (after all Bill Gates was rather influential), but it's not the OP who is not willing to support developers...
The software isn’t the issue. The lack of an open standard for content presentation is.
This is not to claim that what we have isn’t less than ideal, but the fundamental problem with Flash is not the authoring tool itself, but that it effectively monopolized the space.
You know what's _really_ rough for open data standards? The information diaspora that is the modern web. We're in an archival and interoperability dark ages, despite that the presentation layer is "open".
The problem was that it was the only option and Adobe just wasn't committed to being a good software development shop so when you found a bug you were stuck living with it. I did a modest sized project a decade ago where we kept hitting this cycle:
1. Find a bug in the Flash IDE where something basic (e.g. the debugger) crashes or doesn't work in an obvious, easily tested manner.
2. Report it under the paid support plan (hey, that's what we're paying for, right?) with a straight-forward test case
3. A year later, get an email telling you that a new paid upgrade is out and could you pay another $800 to have the privilege of testing whether the problem is fixed?
I always thought one of the biggest plusses of the early web was that you didn’t have to hire a graphic artist and designers in order to publish. In fact best practice was just don’t worry about whether it’s pixel perfect.. just publish your data and organize it into headers and paragraphs. The browser will display it however the user wants it displayed. If that means turning your links orange, that’s fine. If it means displaying it as fixed width green text in a 40x25 terminal, that’s fine too. If the user wanted a textured brick wall background, fine, let them. If it would be read through a screen reader, great!
Later, the designers showed up and started abusing <table> and <img> and body background, thinking the web was a word processor or Photoshop, and everything started going to hell. Now we have JavaScript and <canvas> and I as a user have pretty much lost all control over my browser. It’s just been handed over to the web site publisher, who tries to get rid of my scroll bars and worries whether some element is rendered 3 or 6 pixels wide on different browsers.
In my view, we sacrificed a lot at the altar of “predictable layout”.
In the very early days, before Flash, making a website was a difficult proposition. HTML was an esoteric structural markup language, and much of the effort of early browsers was focused on "correcting" mistakes made by individuals attempting to build websites.
<map> was the true monstrosity, <table> and <img> were improvements upon it, but were burdened by padding and margins added by early browsers that were difficult to modify and retain consistency.
The situation hasn't really improved much; creating a website nowadays is a matter of dedicating yourself to a custom content platform, like Blogger/Squarespace/Wordpress, or learning the arcane language of HTML+CSS+JS.
That's a far cry from the drag, drop, click, publish or share of Flash. Just how does an individual create a .EXE of their animation/game/document and send it via email, nowadays?
I had forgotten about it. That takes me back though. My mom made a website using Dreamweaver way way back to post stories she'd written. She was so excited about it and the fact that she'd been able to do it all herself. It was fairly tasteful as far as sites from that era went, There were only one or two animated gifs at the top and the background was pretty easy on the eyes.
> I as a user have pretty much lost all control over my browser.
> It’s just been handed over to the web site publisher
This is an illusion. It is a fact that the evolution of the web as a medium empowered publishers with more control. However, the browser is running on our computers. The truth is we let them have control. We trusted the publishers and allowed execution of foreign code on our machines.
We gave them that power. We can take it away. It began with popup blockers. Then people created ad and script blockers. Now we have general content blockers. I bet one day people are going to make GPL'd custom clients for popular websites.
"I bet one day people are going to make GPL'd custom clients for popular websites."
People do, it's just hard to do so against any website that has an incentive to prevent you from creating a third-party custom clients, which is every site that serves advertising, which is... uhh... basically the internet.
If people can build and maintain huge ad blocking databases, I don't see why custom clients and APIs for sites would be out of reach. For example, youtube-dl has handlers for specific sites, gets constantly updated to deal with changes and has a generic video scraper it falls back on.
I posted about this idea on reddit and someone showed me this:
Except this time around, browsers are on the side of the publishers[0]. They keep removing useful functionality that gave users control, while adding more and more ways for publishers to impose their will on people. And every now and then you get blatant attempts at neutering the users' decisions, like e.g. Chrome's recent extension API changes.
[0] - Except maybe Firefox, but it has to follow Chrome on most things to stay relevant.
I've been building web applications since 1996, I don't really recall what you are describing ever really being the case in my own experience. Yeah, I could push back on some variance of "pixel perfect" as a meme, but in the end it really needed to be very close to as-designed. Before CSS became the norm (early 00's), it wasn't much fun at all on that side of the fence.
Re: "In terms of predictable layout and control, Flash is still lightyears beyond HTML+JS...That said, Flash was/is an accessibility nightmare."
The key question is if these are mutually exclusive goals or not. Can we take the simplicity of Flash's concepts and improve the accessibility, or will fixing accessibility inherently ruin the simplicity?
It seems to me that accessibility meta data can be supplied to the client independent of layout info. If Paragraph A comes after Paragraph B, the meta data can indicate that regardless of where A and B show up on the screen. Ideally they don't contradict, but my point is that they can be independent.
Conceptually think of two different markup tag sets. Set A is for visual positioning only, and Set B is for semantics (accessibility). The visual rendering engine would ignore tag Set B and an accessibility "reading machine" would ignore Set A. For practical/convenience reasons we may want to tie them together at times, but it's not a requirement for making both the visual screen "happy" and making ADA devices "happy" at the same time.
This is nearly the opposite of what I would want from HTML or the web.
A fixed layout is not going to work for all devices.
Such a choice is tantamount to deciding that some classes of devices are not going to be supported, which may be a reasonable choice but better to make good choices in the HTML and CSS and let the devices try to make something usable of it rather than giving them a fixed window into a layout intended for another.
> A fixed layout is not going to work for all devices.
Designers are also making their choice with HTML nowadays : Desktop is not supported anymore. Look e.g. at twitter, a billion dollars company switching to mobile web only. Flash could easily implement media queries to re-layout itself.
Just by the padding in the buttons it's obvious that twitter's current site was built for mobile. Sure, it's responsive, and i bet flash could become responsive if it was still alive. HTML games however are also non-responsive most of the time just due to the nature of their use case.
They might have meant mobile-first and not mobile only. Their desktop site is very clearly designed for mobile, the main content does not change at varying screen widths. The sidebar and header do a bit of restyling, but thats about it.
Flash could be used for responsive layouts. They were actually far easier to design in Flash than in HTML/CSS. No floating, flexing, grids, nesting HTML elements. You just set the objects x and y axis in Flash to the bottom center or wherever you wanted the object to remain, and you were done.
The layout engine in flash was REALLY well thought out, and allowed for simple constraints that would allow for things to grow or shrink based on screen size. You could anchor buttons and they would move properly, all without having to worry about things breaking across browsers.
If someone would re-implement just this feature along from flash i would be REALLY excited to use it!
So far i dont think there is really much in the way of "constraint based" layout engines that are easy to use for the web is there?
Almost all GUI toolkits work that way, except HTML, because HTML is not designed for GUIs.
For instance look at AnchorPane in JavaFX. You can lock things to the edges or offsets from the edges. You can nest layout managers if you want something different like a table or HTML style wrapping text flow.
In the end HTML is just being abused. It was never designed to be a Flash replacement. If the web was a more pluggable platform Flash would still be alive and kicking for sure, the creation tool itself was lightyears ahead of anything HTML ever had, but the browser makers have killed it pretty ruthlessly. Looks like groupthink to me, tbh.
Re: "A fixed layout is not going to work for all devices."
Agreed, but not all apps need watch-to-wall scaling. All our internal "productivity" apps run on desktops and nobody has complained. Certain check-status-of-project kinds of apps may be something people want on mobile, but not heavy data chomping/sifting.
Different things need different tools and standards. Even web apps don't really work right on mobile unless you test and adjust for mobile. Using Twitter Bootstrap etc. does not guarantee an app is usable on mobile.
And sometimes it seems it would be easier to make two different apps for different devices rather than one-size-fits-all, as it's nearly impossible to optimize the UI to automatically adjust to both using Bootstrap etc. Workable on both, maybe. Optimized for both, no. There may be handful of people in the world who can pull that off, but you won't find them.
HTML has <canvas> now. Flash is essentially no different than that , except for the security holes, which are not unfixable. The other HTML equivalents of it are just too heavy resource hogs, including video players.
What made Flash AMAZING was its authoring environment. Scripted multimedia content (via SWF) I could run and share in the browser in 1998! The first time I ever bought software was Flash 4. Watching, then sharing animations probably caused me to go to Art school. It was incredibly impressive stuff back then.
I just to make or consume that sort of content anymore though. I couldn't even tell you how to do it using HTML, or how to author it. Speaking of school,
<aside>I remember when I signed up for a Director course (Director!), and it was re-done into an advanced internet art class, and all I did was hand in HTML/Javascript assignments. I failed the class, as I worked on all that stuff during my job, the teacher didn't know anything about the tech, and I was inundated with questions on how to do cool stuff. </aside>
It got to the point where it was too annoying to visit all those different websites with animated intros, weird menus, sounds etc. It was like 1000000 cdroms on the browser. But yeah, thanks to 20 years of progress we can now stare at 1000000000 identical bootstrap homepages.
At the time, I remember being pretty OK with taking the terrible with the good - it all felt like experimenting to me, and I gravitated towards more of the designer-y/artsy sites, rather than the games and cartoons.
This was back when David Carson was highly influential designer (for good or ill), and I was coming from skateboarding/snowboarding culture, which (and I sound so old) was a lot different, 20 years ago. Like it was COOL to be really into Typography, and the messier, the better. Because, "The 90's" I guess.
I don't mind them either - i use bootstrap myself. But , i can't help to feel that i use it because i've given up on thinking i could do something functionally useful in today's web with my own CSS. It's become boring, tedious work, because mobile changes everything, you just can't do visually challenging designs there.
Flash was overused as well - it was annoying. However, i believe that something being removed without having a better HTML equivalent is a bad sign of technological regression.
This isn't some defense of Flash and its attendant problems but Flash is very different from that. Canvas is a drawing surface, Flash has a full-blown component model. You can't put a canvas in a canvas.
WYSIWYG mode, unfortunately, ignores the needs of screen readers and other methods of accessing content. The risk of WYSIWYG tools is they lie to you; not all your users can actually see what you see. And that's to say nothing of the less exotic scenarios like different screen sizes or devices.
... unless you're working in a space allowed to discriminate against users that need assistive access to your content of course, in which case you can spring for the WYSIWYG dream.
If screen reader accessibility was the only thing holding us back from a WYSIWYG dream, I would advocate just maintaining separate content-only versions of all pages.
I don't think that's actually where we are though. As you touch on, code is inherently necessary in order to build responsive pages. A static layout will never know how to reflow itself when the window size changes; it needs code to define that behavior.
>"A static layout will never know how to reflow itself when the window size changes; it needs code to define that behavior."
I know what you mean wrt fixed-width layouts, but want to point out that reflow is the default browser behavior in the absence of problematic markup and styling rules. That's the beauty of mobile-first RWD and progressive enhancement when done right; the starting point is just the content, full stop. The first media query is the absence of support for media queries. Then min-width rules to guide layout changes across progressively larger breakpoints.
I don't think it's realistic to declaratively define a UI that works well under both a 15 inch screen and a 2 inch screen. One is probably going to have to programmatically take different courses of action under each of those scenarios. For example, for mobile you'll probably want to split actions into multiple screens that are best done in a single screen with a big monitor.
Visually designing is by definition allways for people who can see.
And for those who cannot, there can and should be a simple htmltext fallback.
But that should not cripple the manority who enjoy nice looking things, which are way easier to achieve with WYSIWYG tools which is why flash was loved among designers.
One should not go using terms like "discriminate" against people who are clearly not doing so.
Assistive access to content is an afterthought for almost everyone in software, and that's perfectly fine. It's an extremely uncommon and unnecessary use case for nearly the entire device-using population.
Show me where the ADA says that software developers must think about assistive access to content, and that not doing so is illegal.
What you have cited here is an issue of compliance for certain public services and commercial products, and you are attempting to justify thought police and the private regulation of development of software standards/protocols with it.
EDIT: Also, would you care to explain how the ADA has any impact on anyone's behavior outside of the United States?
Going back to GG(G?)P, if you're writing software outside of the commercial or government space in the US, then maybe you're fine not complying with accessibility guidelines in the ADA, e.g. screen readers or what have you.
If you're outside of the US, then I don't know what protections there are.
But in the US, for commercial or government purposes, then yes, it's illegal in the above sense.
Edit:
borski above describes context pretty well too, since it depends on the commercial context in which you're operating
Edit 2:
also this latest ruling is new enough that we'll have to wait to see how the dust settles w.r.t. new lawsuits
That case has not yet been decided. There has been no ruling. The only thing SCOTUS did by denying cert was to allow it to proceed to trial.
Robles hasn't really shown that Dominoes failed to provide a _reasonable accommodation_, which is typically the key phrase in the ADA. Depending on the business, making a site accessible can be quite a costly project for quite a small number of customers. Finally, that case is only up for debate due to Dominoes' _physical presence_; Robles is arguing that he's being denied access to the physical stores, which pertains to prior rulings.
Robles claims Dominoes failed to comply with the Web Content Accessibility Guidelines 2.0. Keep in mind that this standard has been created by private industry and _not_ by the government.
Interestingly, if anything is going to get Dominoes, I bet it will be the coupons available only via the web site or app. Anything else they could probably make the case phone/physical options are fine.
The risk with making business decisions around language like "reasonable accomodation" is that the criteria for "reasonable" can change. I'm not an expert in the space, but the watchdogs I read are smelling a change in the wind direction towards increased scrutiny of web accessibility (relevant interest groups are watching the web eat e-commerce and are concerned about what that looks like if the accessibility drum isn't beaten hard early on in the process). Lawsuits like this are expected to increase in 2019.
> Show me where the ADA says that software developers must think about assistive access to content, and that not doing so is illegal.
The ADA is not software specific, but specifies that you must provide access. Courts have been increasingly interpreting that to include websites. See the recent Domino's case where the circuit court ruled the website must be accessible (the Supreme Court declined to hear the case, so it is technically only binding precedent within the 9th circuit - western states, including California) https://www.reuters.com/article/us-usa-court-dominos-pizza/u...
> EDIT: Also, would you care to explain how the ADA has any impact on anyone's behavior outside of the United States?
> Europe has explicitly adopted WCAG 2.1 accessibility standards
This is precisely how we get closer to the achievable goal of assistive accessibility becoming a non-concern in software. The WCAG is nowhere near the same thing as the ADA. In fact, as a person with one of the things that qualifies me as a person with a "disability" I consider the ADA an offensively non-viable and absurdly non-enforceable "law."
I'm curious in what way. Because I have friends who are very active in the local community ensuring compliance with the ADA, so if there's a blind spot they should know about, I would like to pass it on to them.
The blind spot is in using legal violence to coerce people into being "considerate" of people with disabilities. Assistive accessibility is a god damned gold mine for whichever company solves the problem in each industry. Flash's use on the web led to far more good things than bad, and this one bad thing is really just being heightened because the media places falsely high emphasis on being worried about people with disabilities.
The fact is that we have many, MANY advocates who are all a lot nicer, more helpful, and more effective than Washington, DC.
... which is why we have laws to force people to do the right thing even when they don't have the right emotions behind it. I think we're coming at this from two different directions; the people I work with have come to learn that if you don't beat the drum more or less continuously, things don't get better.
Not nearly enough folks are inclined to be considerate; consideration without force of law just isn't good enough.
The law says "reasonable accommodations". Spending 30% more on IT is not "reasonable" in my book. Spending millions to help a handful of people is not "reasonable".
Of course, it is situational. Your main product or service should be accessible, but ancillary and blue-moon information is too expensive to keep compliant.
One org provided statistical reports to the public. But the format was not ADA-friendly, and reworking hundreds of reports would cost tens of millions. So they stopped providing the reports.
That’s actually just straight-up not true, and there is case law that shows it. [1] [2]
In addition, the ADA wouldn’t apply to non-US entities, either way.
Not saying I disagree with the idea in general; in fact, I think we should make our websites accessible because there is a large population of disabled folks who use the internet and should have access. But it’s absolutely not illegal, unless your online presence very closely mirrors a physical store. [3]
So by that logic we shouldn't bother with wheelchair ramps because nearly the entire population has working legs. Nor should we bother with Braille on signs, since nearly the entire population can see just fine.
Any software professional knows just as well as I that these concerns are specialized and people with a particular interest in complying with these special use cases are paid for their particular interest and capability in worrying about, and complying with, regulations within the realm of assistive access.
Most software developers think about getting their software to work correctly, not about edge-cases dealing with the UI for tiny, specific disenfranchised groups of people.
EDIT: Even if we were just to stick to the US, only 2.7 million people use a wheelchair here. That's 0.9 percent of the US population. That's really, REALLY freakin' specialized. Don't stoop to heaving virtue my way when the facts hurt.
EDIT#2: Perhaps you can quantify your ridiculous statement by telling me how the developer of this [0] application should be punished for not building assistive access into his GPLv2 project, and how he should have & could have actually done so.
> Most software developers think about getting their software to work correctly, not about edge-cases dealing with the UI for tiny, specific disenfranchised groups of people.
The whole point of the ADA (and its counterparts in some other developed nations), is that building solutions that are also usable by people with disabilities should no longer be an edge case, but the default.
> building solutions that are also usable by people with disabilities should no longer be an edge case, but the default.
should be the thing we pursue. This will happen when people who care about assistive access technologies finally make solutions that are easy to implement into normal contemporary software development workflow. Online video had the same challenges but due to corporate and commercial interests we solved that problem already, arguably a much harder problem to solve than assistive access. I know because for many years I worked on precisely these kinds of assistive access concerns in the audiobooks industry. I am certain that we are not there yet, but we will get there one day.
BUT...
> The whole point of the ADA
None of this is the point of the ADA. The only "whole point" of the ADA is to regulate particular aspects to certain commercial and government services/products.
Why wouldn't I? Your argument appears to boil down to "well not caring about blind users is the status quo, so no reason to change it". I can guarantee you there were similar attitudes among construction workers and architects before wheelchair ramps became mandatory in various jurisdictions (and hell, even after): "well the vast majority of people wanting to enter this building have working legs, so why should I be assed to build a ramp when a staircase will do?".
If you can't be assed to write software that's accessible to blind people, then that is - by definition - discrimination against them. It's not even hard to make a web page reasonably accessible; plain HTML (with or without CSS) is typically perfectly usable with a screen reader, and it's only when that gets mucked up by a tangled mess of DOM-mangling JS (or Flash or Java or Silverlight once upon a time) that anyone needs to actually put any significant effort into accessibility.
The person who coded this cool and nifty website [0] is discriminating against someone for not making a webapp that a screen reader can parse adequately?
Worse, you think this kind of site would be in violation of the ADA and would subject the creators of the site to legal repercussions and/or litigation?
If so, you are - by definition - insane. Not to mention, illiterate.
More likely, you are not either of these things, but you are instead blinded by an exaggerated sense of concern/worry over this issue, largely impacted upon you by the media you consume. As someone who suffers from a disability which falls under the ADA guidelines, this comes off as being incredibly stuffy, ignorant, and tonedeaf. You're not doing us any favors with your insufferable inability to detach law and life.
> Even if we were just to stick to the US, only 2.7 million people use a wheelchair here.
Then you add people who push a stroller, pull a (personal) shopping cart, or use a walker, or walk unassisted, but can't lift their legs too high...
> That's 0.9 percent of the US population. That's really, REALLY freakin' specialized.
I can guarantee that 100% of the US population were unable to climb stairs at some point in their lives (except maybe for a few libertarians who emerged fully formed from Ayn Rand's forehead).
I love automatic door openers for those days I have to heft some big dumb package in and out of the office.
... and I'm extremely confident that without the law forcing them to, no office I ever worked in would have spent $2,200 per door on that feature, no matter how useful it is to everyone on the odd day.
At this point it would be cheaper to make a large investment into Boston Dynamics to develop walking chairs, instead of continuing with ramps and other things meant to accommodate wheelchairs.
Do you want fewer small businesses? Do you want everything to be more expensive for everyone? There are jobs where people realistically have to be able to carry over 50 pounds. Not everyone can do that, do you want anything over 50# to simply be banned?
Why are “number of small businesses” and “price of goods and services” relevant metrics here? We don’t create accessibility laws because of economics, we do it because it’s the right thing to do. If that means fewer small businesses, so be it.
Because not everything can, or should be usable by all of the population... Should all countertops have adjustable motors to change height before you can sell a house? Someone who is 6'7" tall can't really use the same counters comfortably as someone in a wheelchair.
The fact is, nothing is, has been or ever will be completely fair. And that's okay. Everyone makes decisions based on their environment. Most accessibility laws are only applicable to organizations of a certain size, which isn't even most
You're arguing scale, and I agree that it's probably not possible to make everything accessible (not until we get those brain-controlled robots, anyway ;) ).
But if the question is "Where do you set the bar," we already have laws for that. Are they too many?
I think in some cases yes, in others not so much... I mean in Cali, there are places that literally don't have a restroom for customers because of risk of suit over buildings nearly half a century old.
For others, maybe not as much. In the end, it's a balancing game, and I keep seeing discussion (especially political) lose all sense of nuance or negotiation.
It doesn't until the robots become cheap enough, but even before that baby strollers are much less sensitive to some amount of stairs than wheelchairs are.
I've had to do the reverse... building an accessible application meeting specification requirements because it's used by government bodies. On the flip side, the core functionality of the application (reviewing scanned documents) requires a sighted person to use it.
It really does and should be determined by the specific use case. Yes, most sites should be and many are pretty accessible by default. Using Axe, Wave, Lighthouse and other tools is easy enough and should absolutely be done as part of a web application's development. That doesn't mean that everyone who doesn't do it is someone who should be ostracized and cancelled by reactionary mobs.
Passive discrimination is still discrimination. Changing the terminology doesn't change the reality.
Which is why it's not a bad idea to stick close to the base HTML spec unless you have a real good reason to deviate from it or use advanced features, JavaScript based animation, etc. Because HTML is a document format not a render format, staying close to home on the spec gives you a lot of accessibility for free. Not all of it, images of course are still just binary blobs without more metadata, but you cover a lot of ground.
A website in flash got approximately zero of that for free, and it was a known issue in that era. Accessibility suffered.
Changing the reality should absolutely change the terminology, though.
Almost nobody writes software where assistive accessibility is both legally required and discriminatory when it is not provided. That's an outrageous statement to make that you should back up with evidence, not just platitudes.
The software developers who write the systems that stabilize airplanes in the sky, track radio emissions from space, monitor the nuclear reactor cores in power plants, and encode raw YUV video into tightly-compressed packets that can be transmitted over the web, all lack access assistance code. Why don't we go ahead and take these horrible people to task for discriminating against people who need to have their damned screens read to them aloud by software?
Seriously, I and almost everyone else on Hacker News have never THOUGHT ONCE about assistive access in our code, and you are a shitty person if you want to call us all discriminators.
a) the context of the entire conversation is Flash and the web. If you can point me to developers that are writing airplane autopilots, astronomy signal processors, reactor core monitors (oh God), or video compressors in Flash, you are welcome to bring those categories into the conversation.
b) you're applying moral judgement to a statement of fact. I'm not. Everyone discriminates. There is no such thing as universally-accessible software (if nothing else, it fails the first test "Not everyone has hardware to run it"). The reasons we discriminate and the consequences of that discrimination are what matter. I'm personally against the casual, thoughtless discrimination that can result from declaring the HTML render model "too hard" and throwing up one's hands without considering how all relevant user agents that can consume the model do, but if one has considered those user agents (and the users behind them), it can be a valid decision a company can make.
... all of that having been said, for at least the set of developers whose primary target is "the web," not having thought once about assistive access is a mark of an amateur. You can cover a lot of ground in this industry as an amateur, but you'll be held to a higher standard by huge swaths of potential jobs (banks care, universities care, government websites care, consumer websites that do enough business to notice if they lose ~2% of users care). And the nice thing about HTML as a technology is that more often than not, if you do almost nothing, you'll cover 90% of use cases for assistive access.
Ohhh, I came really close to finding that astronomy signal processor that I wrote in Flash in 1999, but nope.
(No, of course it didn't go into production; Flash VM was way more complicated than the custom hardware we were using. I did a Flash one because I wanted to see if I understood some of the details, and wanted a little animation. I didn't. I learned a few things, though.)
Nothing says accessibility needs to be immediately incorporated into the same content as the non-accessible content.
Restaurants can offer Braille menus. They aren't forced to put translations in Braille immediately next to every piece of text on the menu they give to everyone.
Sure, but if they offer Braille menus, but then they just render photographs of menus on their website (instead of the text itself), they're likely opening themselves up to a lawsuit.
... granted, they're also screwing themselves over because anyone trying to integrate something like UberEats against them to provide delivery is gonna skip them over for the competitor with the more-easy-to-scrape online presence. ;)
I disagree WYSIWYG or coordinate-based positioning inherently "can't do accessibility". It perhaps may take more discipline to make sure the necessary meta data is supplied to the client, but it doesn't outright prevent it.
PDF's, for example, can be made accessible if created properly.
PDF lives because it's ubiquitous and stable, despite really rough tooling. If you don't have Acrobat it's a bit of a nightmare to work with, simply because it's so opaque. Yes, you can decompress a PDF to text and look through it by hand, but you need to learn the syntax and know how to use an extensible text editor with the write add-ons; this isn't something your average person in an office will know how to do.
The lack of discoverability is evidenced by the number of posts on Stackexchange etc. that answer "how do I losslessly recompress a PDF?" by giving a command that actually performs lossy downsampling. Or the accidental inclusion of secret layers underneath what were supposed to be blackout redactions. Personally, it took me ages to figure out how to losslessly recompress a monochrome image using JBIG2, which provided an enormous space savings and should have been much easier with some tree-based GUI explorer.
I'm hoping that one day we'll get a good, stable, powerful, reflowable PDF-like format. HTML+CSS+JavaScript works, but it's a huge standard, rendering is not exact, performance (in terms of memory usage in particular) isn't great, it's best created by hand (requiring programming and/or technical knowledge), and it's not really self-contained or sandboxed from network access.
To this excellent defence of PDF I would like to add that it works perfectly well offline and, crucially, is just a plain old file that can be emailed, WhatsApp’d, backed up, etc. without anyone’s permission or any ongoing dependency on centrally managed servers.
My next website project will be published in PDF, not HTML.
> Personally, it took me ages to figure out how to losslessly recompress a monochrome image using JBIG2, which provided an enormous space savings and should have been much easier with some tree-based GUI explorer.
Can you write more about that? And what was the initial format of a monochrome image in the PDF, and why wasn't it JBIG2?
I can't recall exactly what steps I went through. It took quite a lot of time. It was one of those rabbit holes where I spend two hours thinking I'm just 10 minutes from being done. If I recall correctly, I did the conversion in hopes of getting my aged Chromebook and phone to load the PDF more quickly; scrolling and page turns were just choppy and slow enough to be an annoyance.
As to the conversion itself: I think every page was just an image (which was fortunate, as I'm not sure how I would do this otherwise) so I extracted all the images with something like mutool, converted them using jbig2enc after figuring out the flags to use to ensure lossless compression, then use some tool (ghostscript? imagemagick? some dedicated image-to-pdf program?) to smush it all back together.
So the flow was original.pdf -> [page1.png, page2.png, ...] -> [page1.jb2, page2.jb2, ...] -> new.pdf
I can't recall the original format of the images. Obviously it was something less efficient, but it was lossless. Presumably the images were compressed using the less efficient scheme because whoever scanned the pages didn't know they could twiddle some knob on whatever scanner or scanning software they were using. Or there was no knob for them to twiddle.
You can have WYSIWYG with HTML. You just have to use pixel values for everything and assume some fixed pixel width of your application. Flash can rescale also, but it runs into the same layout/rescaling problems as you do with HTML.
This is just not true. you did not have to specify fixed width in flash any more than you do with HTML. Flash's approach used something like a constraint solver to allow some areas to grow and some areas to have anchor points. It was reactive by design.
I think the key is that what the browser (client) gets should be coordinates. If the server side wants to use some wazoo auto-layout engine, that's fine. And that gives one a wide choice of layout engines/algorithms, unlike browsers.
Yes, browsers do have different layout engines available, but they all go through buggy and inconsistent JavaScript and CSS in the end: the chain is as strong as the weakest link.
Doesn't work well for text in my experience. Perhaps a bounding box can be defined as pixel coordinates, but there's no guarantee the text will fit right across browser brands or versions.
You are supposed to design your UI based on general principles ("three vertical blocks", "list of elements with a label", "text with paragraphs", etc.) and let the user agent lay it out as it wants and accept whatever result happens, and not attempt to test or micromanage it to get a preconceived result.
At any rate, HTML layout is determined by the spec barring rare bugs, so you can design something that lays out exactly how you want regardless of browser, except that you must decide and specify the layout for any possible width/height combination.
Layout isn't rocket science until someone makes it more complicated than it needs to be. I don't remember flash being very adaptive to different resolutions.
What you see might be what you get, but it's not what I get, for reasons that are innate to the web.
My mother still uses an iPhone SE with a 4.7" screen, while I use a gargantuan phablet. My grandmother has poor eyesight and runs her browser on a 720p screen at 175% zoom, while I have a large high-resolution monitor and normally open browser windows to 1280x2160 portrait. My monitor is color-calibrated and extremely bright during the day, but after sunset it's deep amber and very dim.
If you think that WYSIWYG for the web is desirable, you haven't understood the web.
Wasn't he talking about a "special mode" for places where WYSIWIG might be the better case? Not for ALL content, but for some web applications (complex CRUD apps maybe as a good example) I feel like there is still very much a case to be made for this.
Maybe the form it takes would be a good place for discussion, but really there is no reason things like this have to be inaccessable to screen readers any more than a native app would be.
I hate designers who think they are typographers. Typography is an engineering discipline. It is not something you want to leave to designers. Especially not insecure designers (and customers) who need constant novelty.
When web browsers support LaTeX-like hyphenation and justification with microtypography (tiny tweaks to the tracking tightness), then I will be obsolete and happy.
No, they are not. Thinking they are does not make it so and it just leads to poor typesetting. The typographers I know typically have a BA from an engineering college. The advent of desktop publishing and later other forms of electronic publishing has hollowed out the field.
> I believe Flash and Java Applets both made the same fatal mistake: tried to be an entire virtual OS. That made them too complicated, which invites hackers.
Let’s be fair here: every major web browser also implements an entire virtual OS by this metric, probably even moreso than Java or Flash ever did. Yes, they absolutely do invite hackers with their absurdly complex designs, but advances in security-in-depth have made them fairly hard targets (not invulnerable, though, as Pwn2Own demonstrates annually). Flash and Java never really had enough attention paid to real, in-depth security engineering by comparison, and browsers learned from those lessons and improved. The JavaScript engine and API scope in a modern browser is easily multiples of what you could access from ActionScript in Flash, but the security is much better.
Having worked on content in eLearning while Flash was king, it was far from a panacea. Especially for government related training content. Almost everything was meant to be run full-screen at 1024x768. Can you imagine if everything were still VHS quality today for video?
In the end, technology moves forward. And frankly, there are enough libraries for grid/layout that really close to just work. I find that material-ui with react is insanely easy to use compared to what came before. Every time I do anything more custom, yeah, I have to google it and play around witht he CSS rules. However, for CRUD guis, material-ui library all the way.
In the end, you aren't going to get away with knowing nothing. Even in the Flash days, if you wanted to do anything interesting you had to know ActionScript and the quirks that went with it. For forms and crud apps, you had Flex, which had its' own niceties but wasn't a panacea either and wasn't WYSIWYG either.
What could have saved Flash was opening the runtime and creating an interoperable specification and let browser vendors work with Adobe (Macromedia and I forget the company before that) etc. Silverlight was much closer, but still sucked in a lot of ways that held it back in the end. Flash's tooling still exists and iirc targets HTML5 these days, so you can still pay and use it.
If Flash had simply been a bundle spec for a zip archive with a manifest file, JS, SVG and MP3 (or other audio) and video files it could still be a thing. I had hoped that would be the direction it would go when Adobe bought Macromedia. It wasn't. It was the source of too many bugs and crashes and it died because of it.
There is tension between two fundamental ideas: is the server offering content and allowing the client to interpret it as they see fit; or is the server offering an experience that is out of the hands of the user?
Out of these two conflicting ideas come all sorts of issues. Accessibility is one, but so are things like scraping, copy/paste, DRM, confidentiality, artistic integrity, cross-platform compatibility, new devices, peformance & resource consumption, etc.
Agreed, but web standards don't support the second choice very well. Different groups, scenarios, or apps will want one or the other depending on circumstances, but we don't have "other" right now.
The server having more control doesn't necessarily harm accessibility. It's a matter of making sure sufficient meta-data is included. It's possible accessibility is more work under the second, but not outright impossible. (I've stated more about accessibility nearby.)
I worked on a WYSIWYG HTML editor (Pagedraw) for a while, and came to the conclusion it's overkill for the problem of browser layout.
For CRUD apps, you really just want HStacks, VStacks, and ZStacks like they have in SwiftUI.
They nicely express reflow behavior without driving you crazy or bloating your code. They're a bit more work than drag-and-drop because they make you be explicit about resizing/reflow, but you should be thinking about that anyway.
You'll want to skip that step when iterating quickly on design, but that's why you design in a separate design tool, which is visual and uses position:absolute.
When you're ready to parameterize the design over varying content and screen sizes you'll have to specify resizing constraints somehow, and in my experience, VStacks/HStacks in code are a pretty good way to do it.
I recommend adding building these abstractions on top of flexbox, and adding them to your standard library.
This is all specifically for CRUD apps. If you're making an animation, or something else that would feel wrong to call a "document", you probably want a completely different set of tools.
In other words, designers want to control my experience, which conflicts with my desire to control my own experience.
If the "designer" of a web page were able to send me plain text and links only, with my client application in control of the font, size, line width, layout, etc, I would prefer that to current state of the web.
Oof. Organizing the world's information, except the information that's unfortunately stuck in a file format we don't like anymore (for good reasons), that knowledge clearly isn't worth anything. I get disabling Flash support in browsers by default, but actively pretending Flash content doesn't exist so no one can find it anymore seems unnecessarily destructive.
Yeah, it's not great. I figure not being able to display specific things is something people who really need to can work around, but not even being able to find things means surrendering information to the void.
Just because one can't open the information by default doesn't mean the information doesn't exist - in this case, Flash content is exactly like your paywall and book examples. The searcher can decide if having access to the information is worth the added cost...regardless of it's buying the book, paying for the subscription to bypass the paywall, finding an old computer or setting up a VM to use flash.
I hope they meant just parsing swf-files or extracting their meta-data. Purging anything related to the file itself would be quite counter productive for a search engine.
Google operates on a live-code model. Anything running requires some level of active maintenance and support, so there's always incentive to trim. In this case, the Flash crawler is an obvious thing to trim (what's the point of indexing something that the average user lacks the tools to open and read?).
One thing I do wish they would / could do in situations like this though is open-source the core of that crawler, so if someone else finds a purpose for it, they could run their own on whatever corpus they care to index. But, such is the price of relying on closed-source software for things.
Information is still information. Sure I hate having to deal with flash, but if that information I need is nowhere on the web except this one flash or pdf deep down the interwebs, I will take a look.
I'm all for downranking it to the last page, but when your google results only has 2 pages total, every single result matters, including that flash content.
Is that going to run afoul of IP ownership? To my knowledge, Flash was never open-sourced, and Oracle v. Google casts shadows on API-compatible reverse engineering.
Not sure but that is a good question. Although the VM bytecode spec is published by them. Not sure why really, they even release the file format spec. I would link but the links I knew changed recently and did not work for me.
Sure you could, but you need to build a swf runtime first ... There were a few projects (one from Mozilla - Shumway), but nothing really great. SWF is a complicated format.
I'm not intimately familiar with the SWF standard but I think it's well defined, just complicated (because Flash did a lot) and with potential patent and licensing minefields.
Oh, it's not. Adobe themselves were too scared to change anything, and just shipped multiple versions of their runtime under the hood to account for all the different versions.
The flash player was awful on Macs back in the day. Adobe refused to support OSX properly, and Steve rightfully did not trust them to make a decent job.
Is up to the user to decide that, not the platform middle-man.
Its funny how many people are willing to give up their freedom to decide what works best for them, and let others decide, in the name of "im doing all this for your own good".
You should always have the right to decide what technology to use, what you install and download on your device.
The whole app store deciding what they allow or not, not giving you any other alternative, should be deemed inconstitutional in a society who knows whats happening, when people have nowhere else to go because the digital dictatorship is in control of your digital life.
This whole trend smells digital feudalism to me, and it was Jobs that started this whole dangerous trend to the bottom of our civil liberties.
Why are you defending this new feudal lord who are mining your right to choose what you do with your own property?
If after having bought a house, the guy(or company) who have selled to you, had made some demands of how you could use the kitchen, or the bedroom, would you think its within his right to do so?
> Is up to the user to decide that, not the platform middle-man.
Each and every time a costumer buys an iPhone they're deciding.
Adobe decided to do a half-assed flash player for the Mac. That decision proved to be wrong.
Or do you really expect that Adobe would do a decent job supporting an new platform when they couldn't even bother supporting the big cash cow Apple had at that time?
> Each and every time a costumer buys an iPhone they're deciding.
You can buy the house from the company defining rules of how you should use the house you bought from them and denying you access to the things they forbid.
Lets suppose you have options to buy a house from the ones that does not do this, ok.. until the company who are ruling over your property are making a big buck, and they decide to play by the same rules..
so hey, where are your options to buy a house without vendor rules? thats right, their gone..
Only that we are talking about something much more important here which has to do with data..
Private companies should never be allowed to do this, unless they offer options (other app stores should be possible), and have rules to filter who can offer apps to your device that dont damage your freedom of choice (dont forbid things on political views, taste, harassing competition, etc..).
Android is becoming more akin to Apple each day, and what you have in the end is a false sense of choice.
This is why the rule of law and a functioning government is so important.
> Adobe decided to do a half-assed flash player for the Mac.
Than if it will deliver a crappy experience, let the user decide for his own. Suppose the user agree with Apple/Jobs here and dont like to use it, but theres that tool that are available only in Flash, you need it for your mechanical enginnering job for instance.. You had a choice, a bad one, yes, but now you have none. Just because 'simon says' so..
And we are not even thinking about the small players with less resources than Adobe, that will not have the resources to make the "good experience" by whatever standards imposed by the overlord dujour.
And thats because we are assuming good faith, because the ruler of your own property, can even lie about be doing this for your own sake, and just use this to bar the competition.
By the way i never touch anything Apple because of this, but because they were the ones who leaded the smartphone industry, the rules they have specified in the beggining tend to be copied by the competition, and to become the norm.
Its not the same as creating a new car company in the XXI century where we have standards, good rules, etc..
The pioners have the power to define the reality of the industry in years to come. And giving its about our digital life, its becoming more and more important each day.
Data and digital platforms are in the XXI century what the oil was in the XX century. Pervasive, powerful, defining everything else.
> Google Search will stop indexing standalone SWF files.
Does Google no longer index .zip files and the like? Obviously they can't process any content in those formats, but if the file name contains the right keywords... shouldn't search be file type agnostic?
If the zip files not password protected I dont see why they cant crawl the filenames inside zip files. They probably keep all crawl info cause you are able to do Google searches for specific file extensions and I wouldnt be surprised if you could for specific file mime types too.
I've had .exe's show up in Google results. It was a long time ago—so maybe things don't work like that anymore—and it was never common, but I know I've seen it happen. I'm sure Google could look inside the binary for text strings, but I can't imagine they do.
There is perhaps an argument that standalone exe's shouldn't turn up in results for security reasons (how can you possibly verify its safety without some context?), but I liked to think that search results could at least theoretically include any file type at all.
10 years on after that Jobs letter, the market for WYSIWIG web animation is nearly non-existent. All I want is a tool that lets me draw animations, allow tweening controls and exports to HTML/JS, without needing to open a code editor.
The only tool that does this to my knowledge is Tumult's Hype: https://tumult.com/hype/. I'm glad it's using an old-school pricing model of one-time payment and not the subscription model that Adobe and everyone else switched to.
Adobe Animate used to be a thing, but that got sunset years ago. There is Adobe After Effects + Lottie, but that assumes you are a front-end developer and know how to integrate those tools together and use the resulting JSON.
No wonder then that the only visually interactive websites out there these days are things like "Spotify Year in Music" stuff that probably takes an entire team multiple sprints to build.
It is not. Google Web Designer is a very limited product with a specific audience: marketers who are building those banner ads that everyone of HN blocks anyway.
Hype is a desktop app that give you much more control and is targeted at Flash game devs, web designers and others.
My mistake, I was referring to Adobe Edge Animate, which was sunset in 2015. Animate CC is still around and kicking. Unfortunately, it renders to HTML5 Canvas, which is bitmap-based and thus unreadable by screen readers. Hype is a better option as it renders to SVG.
Flash, ActionScript and the associated IDE were amazing web development tools at the time (in the era of Macromedia) - way ahead of any competitors. No one/nothing has really filled those shoes.
Flash was incredible. Not just for the animation and games, but also for the audio and video streaming from a server to you, or from your mic/cam to a server, or between you and other users via P2P, all of that live and with the ability to embed arbitrary metadata as cue points at specific times in the stream. The feature set and creativity it unlocked were out of this world.
I hate Flash as much as the next guy who remembers web pages slowing to a crawl or crashing because of Flash.
But I also think this is a bad idea, just from an information retention scenario. What ever happened to "to organize the world's information and make it universally accessible and useful?"
What will Google decide the world doesn't need to know about next? HTML2? JPEGs? non-Google-hosted javascript?
This is what we get for allowing a private company to be the gatekeeper of our culture.
The gatekeeper here is Adobe, not Google. This is what you get when you store information in a proprietary format with a single implementation controlled and developed by a single private company. There's always the risk they'll kill the product (like they're doing here) and your information will become inaccessible.
Also, it's not just Google doing this. Pretty much every major browser vendor is dropping support for Flash in 2020.
After all.. I did like more flash than html5 .. browser APIs for videos and audios are really ruined. It's like chrome wanted build fast something to kill flash.. but now we have Totally ruined webrtc left. Thanks Google. Just what we want :)
348 comments
[ 2.9 ms ] story [ 145 ms ] threadremember that time when Steve jobs kept out flash from iPhone /iPad vs Google's stance to go full on support for flash on mobile :)
apple was just bold, big and loved enough to survive the backlash from flash fanboys who, outraged, went buying android phones and proceeded to never use flash there either.
I'm not a big fan of the tablet form factor in general, but it didn't make a lot of sense to hamstring it further by removing Flash.
Flash on anything but Windows was an awful experience.
I wonder what NewGrounds is going to do about all their older content?
Turned-out the creative people that matter listen to dicks like Steve Jobs where they don't listen to me. Note about 80% of where we were using flash were replaced by he trivial JS/CS or maybe a jquery plugin, it simply wasn't needed.
It's so sad too because Flash is still amazing when it comes to animating vector graphics in a crossplatform way. Nothing in the HTML5 world remotely comes close.
You can upscale Homestar Runner to 4k and it renders beautifully. Now that it's all YouTube videos, whatever resolution they rendered it at, there it will stay for forever (plus you lose all the clickable eastereggs in the Strong Bad e-mails!)
If that's the case, Flash should be held up as a case study for the utility of robust tests. Because the amount of refactoring needed to make it fit the mobile world was significant, and if the codebase was fragile because of lack of tests, that refactoring may have proved expensive enough to kill the whole technology stack.
When Adobe finally did make it to Android, it required a gig of RAM and a 1Ghz processor. The original iPhone had 256MB of RAM and a 400Mhz processor. An iPhone with those specs didn’t come out until 2011.
One of the big selling points of the Motorola Xoom was that it would run Flash. Adobe was six months late leaving the Xoom in the embarrassing position that you couldn’t view its Flash enable home page from the device for at least the first six months.
Just running the plugin on a phone isn’t the hard part.
Apple is able to optimize its OS, compiler chain, and processor in sync.
Not to mention that an even more stripped down version of the core OS with tighter constraints is running on the watch.
Not even mentioning that the average $250 Android device is much lower specced than the average iPhone. It wasn’t until last year that even high end Android phones were matching the performance of an iPhone 6s (released in 2015) in single core performance.
Now that the adtech firms switched to building the browser and the cluster of html5 technologies have matured it's easier to track people natively. That's really the only reason flash went away.
Quite interesting if you think about it! A bit of an antithesis to the idea that what's on the web is preserved forever.
I struggle to see how doing so would harm them commercially. Even if an open source player is available, browser vendors have no interest in supporting it, so it won't be supported with browsers. It isn't going to take away interest in their newer pure HTML5 authoring tools.
Looks like it got dropped from Ubuntu though.
Basically there is a program you can download from Adobe called Flash Player Projector Content Debugger, then you just point that at the .swf and go.
An open source emulator would be better in the long term, but for now this is easier than trying to find a browser that still supports Flash natively.
• Windows: https://fpdownload.macromedia.com/pub/flashplayer/updaters/3...
• Mac: https://fpdownload.macromedia.com/pub/flashplayer/updaters/3...
• Linux: https://fpdownload.macromedia.com/pub/flashplayer/updaters/3...
Download the version for your platform and open the swf file you want to run. That's it.
Linux users can also use the community-packaged Flatpak: https://flathub.org/apps/details/com.adobe.Flash-Player-Proj... All other links come from https://www.adobe.com/support/flashplayer/debug_downloads.ht...
https://bluemaxima.org/flashpoint/faq/
https://bluemaxima.org/flashpoint/datahub/Linux_Support
I remember when the first 7" Galaxy Tab came out in late 2010. Jobs mocked its size, saying you'd need to file down your finger to use it, while at the same time working on the iPad Mini, which wouldn't launch until after his death.
- Abobo's Big Adventure (abobosbigadventure.com)
- Super mario bros crossover (http://supermariobroscrossover.com/)
The fact that they weren't very imaginative or fun or free is what the hyperconnected mobile web brought us.
Instead, what we have is a situation where pretty much only corporations with designers and devs on staff (Stripe and Spotify being the major examples) are building the types of sites that used to be doable by a single person using Flash.
> Goodbye, Flash
- Fuck you, Google
https://labs.adobe.com/downloads/flashplayer.html
Just like I can'd to anything with a PSD file with a browser natively, I can't with an SWF either now. Not that horrible situation.
Harsh. I'm sorry they invested their own time and effort into building a search crawler atop a closed-source, proprietary data format (risking not just capital and engineering time, but possibly lawsuits if Adobe had gotten pissy like Oracle) and, having looked at the field of users and decided that there is insufficient interest in the data format to justify maintaining that crawler, they're decommissioning it?
They made a product decision; they didn't shoot your dog.
And it's not even like their product decision removes the ability of the orgs you've listed to keep using Flash. Those orgs just can't keep relying on a free-but-proprietary search engine provided at the largesse of a corporation they have no business deal with anymore to index their proprietary-format media, for free.
Technically, yes. Commercially, no.
Unity is just one example that can export to web. There's https://playcanvas.com/ too and a plethora of other stuff :)
Unity demo: https://wasm.bootcss.com/demo/Tanks/
It'd be a great open source project. As a commercial product, it'd probably be enough to support a small team, but I don't see a way for it to get huge.
https://www.scirra.com/
Same for Firefox: https://support.mozilla.org/en-US/kb/npapi-plugins
Not 100% sure about IE, but it doesn't seem like you'll be able to make Flash work there either: https://blogs.windows.com/msedgedev/2017/07/25/flash-on-wind...
I think Firefox ESR might still support Flash for a while, at least until the next release.
Blackberry, Palm, and Microsoft all tried it. Android itself was slow as molasses for years because of its dependence on a VM instead of a completely native stack.
The last thing I want is Electron for mobile.
But in the web era, IP isn't king; communications is.
It seems that Google is already using WebAssembly in its products, Google Keep [0], so it is likely that they will continue to use this.
[0] - https://webassembly-security.com/google-keep-webassembly-mod...
The browser should have a WYSIWYG mode for when your application needs it. The server could re-scale as needed for different devices based on a layout engine of the designer's choosing. That way one is dealing with one layout engine instead of say 50 (browser brand/version combos). Seems more logical to me. We don't need auto-flow rocket science if we just partition layout engines logically.
I believe Flash and Java Applets both made the same fatal mistake: tried to be an entire virtual OS. That made them too complicated, which invites hackers. If they had focused on just UI "serving", they could have been small enough to be manageable.
Would a canvas and/or SVG GUI be acceptable?
The industry really needs a dedicated GUI-friendly standard. Emulating GUI's keeps failing. If you fail 30 beauty contests, the blunt truth is you are ugly. Get a clue and change direction.
There is some precedence. Rich Harris (of Rollup & Svelte fame) has been toying with the idea of a precompiler for Web GL...
But if you're trying to optimize across several displays HTML can re-flow for you and isn't generally terrible unless you're doing things that need to be pixel-perfect.
1. Page and document centric (HTML may be close enough)
2. Productivity and data-oriented GUI's ("cubicle" stuff)
3. Games, art, and diagrams
Doing everything in HTML/CS/JS keeps proving too clunky. Even the big wealthy sites have odd rendering bugs that pop up.
Clunky, sometimes sure. It has largely been fine in my experience.
> Even the big wealthy sites have odd rendering bugs that pop up.
This will always be the case.
That's not my experience. It requires too much fiddling and diddling to get things right that wouldn't be drama under 90's GUI IDE's. (Early versions sucked, but they got better with time.) Maybe a few experts somehow master all the arcane CSS/DOM rules, but that's the exception. Arcane fiddling may be great job security, but it's not economically logical on a planet-wide view.
In the most technical sense, yes, but it's way too low level an abstraction to be practical. Flash's entrypoint abstraction was the timeline, which already bundles up a huge amount of complexity around time-based transformation of content that you'd have to build atop canvas to approach Flash's convenience.
That said, Flash was/is an accessibility nightmare. It broke screen readers, and the animations and custom interfaces regularly created unnecessary cognitive load and confusion.
Somehow nowadays the group think has kind of changed into what Slashdot was 10 years ago. Which is funny, since the objective of YC has not changed.
I mean I knew this mentality exists, (after all Bill Gates was rather influential), but it's not the OP who is not willing to support developers...
neither am I
This is not to claim that what we have isn’t less than ideal, but the fundamental problem with Flash is not the authoring tool itself, but that it effectively monopolized the space.
For as rough as PDF tooling is, flash is even worse.
1. Find a bug in the Flash IDE where something basic (e.g. the debugger) crashes or doesn't work in an obvious, easily tested manner.
2. Report it under the paid support plan (hey, that's what we're paying for, right?) with a straight-forward test case
3. A year later, get an email telling you that a new paid upgrade is out and could you pay another $800 to have the privilege of testing whether the problem is fixed?
Later, the designers showed up and started abusing <table> and <img> and body background, thinking the web was a word processor or Photoshop, and everything started going to hell. Now we have JavaScript and <canvas> and I as a user have pretty much lost all control over my browser. It’s just been handed over to the web site publisher, who tries to get rid of my scroll bars and worries whether some element is rendered 3 or 6 pixels wide on different browsers.
In my view, we sacrificed a lot at the altar of “predictable layout”.
<map> was the true monstrosity, <table> and <img> were improvements upon it, but were burdened by padding and margins added by early browsers that were difficult to modify and retain consistency.
The situation hasn't really improved much; creating a website nowadays is a matter of dedicating yourself to a custom content platform, like Blogger/Squarespace/Wordpress, or learning the arcane language of HTML+CSS+JS.
That's a far cry from the drag, drop, click, publish or share of Flash. Just how does an individual create a .EXE of their animation/game/document and send it via email, nowadays?
They also weren't nearly as good as Flash at creating layout and appearance that would be consistent on all browsers.
> It’s just been handed over to the web site publisher
This is an illusion. It is a fact that the evolution of the web as a medium empowered publishers with more control. However, the browser is running on our computers. The truth is we let them have control. We trusted the publishers and allowed execution of foreign code on our machines.
We gave them that power. We can take it away. It began with popup blockers. Then people created ad and script blockers. Now we have general content blockers. I bet one day people are going to make GPL'd custom clients for popular websites.
People do, it's just hard to do so against any website that has an incentive to prevent you from creating a third-party custom clients, which is every site that serves advertising, which is... uhh... basically the internet.
But, see Hacker News: https://play.google.com/store/apps/collection/cluster?clp=gg... (At least, I hope that link sends you to a search on "Hacker News" on the Google Play Store. If not, well... search for "Hacker News".)
I posted about this idea on reddit and someone showed me this:
https://weboob.org/
Something like this could change the web.
[0] - Except maybe Firefox, but it has to follow Chrome on most things to stay relevant.
The key question is if these are mutually exclusive goals or not. Can we take the simplicity of Flash's concepts and improve the accessibility, or will fixing accessibility inherently ruin the simplicity?
It seems to me that accessibility meta data can be supplied to the client independent of layout info. If Paragraph A comes after Paragraph B, the meta data can indicate that regardless of where A and B show up on the screen. Ideally they don't contradict, but my point is that they can be independent.
Conceptually think of two different markup tag sets. Set A is for visual positioning only, and Set B is for semantics (accessibility). The visual rendering engine would ignore tag Set B and an accessibility "reading machine" would ignore Set A. For practical/convenience reasons we may want to tie them together at times, but it's not a requirement for making both the visual screen "happy" and making ADA devices "happy" at the same time.
They can be independent info.
A fixed layout is not going to work for all devices.
Such a choice is tantamount to deciding that some classes of devices are not going to be supported, which may be a reasonable choice but better to make good choices in the HTML and CSS and let the devices try to make something usable of it rather than giving them a fixed window into a layout intended for another.
Designers are also making their choice with HTML nowadays : Desktop is not supported anymore. Look e.g. at twitter, a billion dollars company switching to mobile web only. Flash could easily implement media queries to re-layout itself.
Source? Twitter.com currently works just fine on Desktop. Even dynamically adjusts its layout to look good on a bunch of different screen sizes.
> The site has an updated look and feel that is more consistent with the Twitter you see on other devices
The layout engine in flash was REALLY well thought out, and allowed for simple constraints that would allow for things to grow or shrink based on screen size. You could anchor buttons and they would move properly, all without having to worry about things breaking across browsers.
If someone would re-implement just this feature along from flash i would be REALLY excited to use it!
So far i dont think there is really much in the way of "constraint based" layout engines that are easy to use for the web is there?
For instance look at AnchorPane in JavaFX. You can lock things to the edges or offsets from the edges. You can nest layout managers if you want something different like a table or HTML style wrapping text flow.
In the end HTML is just being abused. It was never designed to be a Flash replacement. If the web was a more pluggable platform Flash would still be alive and kicking for sure, the creation tool itself was lightyears ahead of anything HTML ever had, but the browser makers have killed it pretty ruthlessly. Looks like groupthink to me, tbh.
Agreed, but not all apps need watch-to-wall scaling. All our internal "productivity" apps run on desktops and nobody has complained. Certain check-status-of-project kinds of apps may be something people want on mobile, but not heavy data chomping/sifting.
Different things need different tools and standards. Even web apps don't really work right on mobile unless you test and adjust for mobile. Using Twitter Bootstrap etc. does not guarantee an app is usable on mobile.
And sometimes it seems it would be easier to make two different apps for different devices rather than one-size-fits-all, as it's nearly impossible to optimize the UI to automatically adjust to both using Bootstrap etc. Workable on both, maybe. Optimized for both, no. There may be handful of people in the world who can pull that off, but you won't find them.
I just to make or consume that sort of content anymore though. I couldn't even tell you how to do it using HTML, or how to author it. Speaking of school,
<aside>I remember when I signed up for a Director course (Director!), and it was re-done into an advanced internet art class, and all I did was hand in HTML/Javascript assignments. I failed the class, as I worked on all that stuff during my job, the teacher didn't know anything about the tech, and I was inundated with questions on how to do cool stuff. </aside>
This was back when David Carson was highly influential designer (for good or ill), and I was coming from skateboarding/snowboarding culture, which (and I sound so old) was a lot different, 20 years ago. Like it was COOL to be really into Typography, and the messier, the better. Because, "The 90's" I guess.
Flash was overused as well - it was annoying. However, i believe that something being removed without having a better HTML equivalent is a bad sign of technological regression.
Which hasn't gone anywhere, but has been renamed Adobe Animate.
https://www.adobe.com/products/animate.html
This isn't some defense of Flash and its attendant problems but Flash is very different from that. Canvas is a drawing surface, Flash has a full-blown component model. You can't put a canvas in a canvas.
... unless you're working in a space allowed to discriminate against users that need assistive access to your content of course, in which case you can spring for the WYSIWYG dream.
What a cunt you are!
I don't think that's actually where we are though. As you touch on, code is inherently necessary in order to build responsive pages. A static layout will never know how to reflow itself when the window size changes; it needs code to define that behavior.
I know what you mean wrt fixed-width layouts, but want to point out that reflow is the default browser behavior in the absence of problematic markup and styling rules. That's the beauty of mobile-first RWD and progressive enhancement when done right; the starting point is just the content, full stop. The first media query is the absence of support for media queries. Then min-width rules to guide layout changes across progressively larger breakpoints.
This is no longer true. CSS grid solves this completely.
https://youtu.be/7kVeCqQCxlk
And for those who cannot, there can and should be a simple htmltext fallback.
But that should not cripple the manority who enjoy nice looking things, which are way easier to achieve with WYSIWYG tools which is why flash was loved among designers.
That's... quite the Freudian slip. At least you have an idea where your jingoistic ignorance of other's needs comes from.
And apart from that, are you sure that I am the ignorant one, when I wrote "there can and should be a simple htmltext fallback."?
Anyway, since your needs seem to be, being self righteous, I won't interfere with that anymore.
https://www.adobe.com/accessibility/products/flash.html
Assistive access to content is an afterthought for almost everyone in software, and that's perfectly fine. It's an extremely uncommon and unnecessary use case for nearly the entire device-using population.
It's not perfectly fine - it's illegal.
https://en.wikipedia.org/wiki/Americans_with_Disabilities_Ac...
What you have cited here is an issue of compliance for certain public services and commercial products, and you are attempting to justify thought police and the private regulation of development of software standards/protocols with it.
EDIT: Also, would you care to explain how the ADA has any impact on anyone's behavior outside of the United States?
However because of the way US law works, you probably need context on court cases, such as the recent supreme court ruling:
https://www.scotusblog.com/case-files/cases/dominos-pizza-ll...
Going back to GG(G?)P, if you're writing software outside of the commercial or government space in the US, then maybe you're fine not complying with accessibility guidelines in the ADA, e.g. screen readers or what have you.
If you're outside of the US, then I don't know what protections there are.
But in the US, for commercial or government purposes, then yes, it's illegal in the above sense.
Edit:
borski above describes context pretty well too, since it depends on the commercial context in which you're operating
Edit 2:
also this latest ruling is new enough that we'll have to wait to see how the dust settles w.r.t. new lawsuits
Robles hasn't really shown that Dominoes failed to provide a _reasonable accommodation_, which is typically the key phrase in the ADA. Depending on the business, making a site accessible can be quite a costly project for quite a small number of customers. Finally, that case is only up for debate due to Dominoes' _physical presence_; Robles is arguing that he's being denied access to the physical stores, which pertains to prior rulings.
Robles claims Dominoes failed to comply with the Web Content Accessibility Guidelines 2.0. Keep in mind that this standard has been created by private industry and _not_ by the government.
Interestingly, if anything is going to get Dominoes, I bet it will be the coupons available only via the web site or app. Anything else they could probably make the case phone/physical options are fine.
9th Circuit's over-ruling of the dismissal by district; can't say I agree with all of it, but worth reading: https://cdn.ca9.uscourts.gov/datastore/opinions/2019/01/15/1...
The risk with making business decisions around language like "reasonable accomodation" is that the criteria for "reasonable" can change. I'm not an expert in the space, but the watchdogs I read are smelling a change in the wind direction towards increased scrutiny of web accessibility (relevant interest groups are watching the web eat e-commerce and are concerned about what that looks like if the accessibility drum isn't beaten hard early on in the process). Lawsuits like this are expected to increase in 2019.
The ADA is not software specific, but specifies that you must provide access. Courts have been increasingly interpreting that to include websites. See the recent Domino's case where the circuit court ruled the website must be accessible (the Supreme Court declined to hear the case, so it is technically only binding precedent within the 9th circuit - western states, including California) https://www.reuters.com/article/us-usa-court-dominos-pizza/u...
> EDIT: Also, would you care to explain how the ADA has any impact on anyone's behavior outside of the United States?
It isn't the ADA, but Europe has explicitly adopted WCAG 2.1 accessibility standards: https://www.w3.org/blog/2018/09/wcag-2-1-adoption-in-europe/
This is precisely how we get closer to the achievable goal of assistive accessibility becoming a non-concern in software. The WCAG is nowhere near the same thing as the ADA. In fact, as a person with one of the things that qualifies me as a person with a "disability" I consider the ADA an offensively non-viable and absurdly non-enforceable "law."
The fact is that we have many, MANY advocates who are all a lot nicer, more helpful, and more effective than Washington, DC.
... which is why we have laws to force people to do the right thing even when they don't have the right emotions behind it. I think we're coming at this from two different directions; the people I work with have come to learn that if you don't beat the drum more or less continuously, things don't get better.
Not nearly enough folks are inclined to be considerate; consideration without force of law just isn't good enough.
I take it back. You are a shitty person. Those of us in the disabled community hate people like you.
Of course, it is situational. Your main product or service should be accessible, but ancillary and blue-moon information is too expensive to keep compliant.
One org provided statistical reports to the public. But the format was not ADA-friendly, and reworking hundreds of reports would cost tens of millions. So they stopped providing the reports.
In addition, the ADA wouldn’t apply to non-US entities, either way.
Not saying I disagree with the idea in general; in fact, I think we should make our websites accessible because there is a large population of disabled folks who use the internet and should have access. But it’s absolutely not illegal, unless your online presence very closely mirrors a physical store. [3]
[1] https://en.m.wikipedia.org/wiki/Young_v._Facebook,_Inc.
[2] https://en.m.wikipedia.org/wiki/Ouellette_v._Viacom_Internat....
[3] https://en.m.wikipedia.org/wiki/National_Federation_of_the_B....
Any software professional knows just as well as I that these concerns are specialized and people with a particular interest in complying with these special use cases are paid for their particular interest and capability in worrying about, and complying with, regulations within the realm of assistive access.
Most software developers think about getting their software to work correctly, not about edge-cases dealing with the UI for tiny, specific disenfranchised groups of people.
EDIT: Even if we were just to stick to the US, only 2.7 million people use a wheelchair here. That's 0.9 percent of the US population. That's really, REALLY freakin' specialized. Don't stoop to heaving virtue my way when the facts hurt.
EDIT#2: Perhaps you can quantify your ridiculous statement by telling me how the developer of this [0] application should be punished for not building assistive access into his GPLv2 project, and how he should have & could have actually done so.
[0] https://github.com/falkTX/Carla
The whole point of the ADA (and its counterparts in some other developed nations), is that building solutions that are also usable by people with disabilities should no longer be an edge case, but the default.
> building solutions that are also usable by people with disabilities should no longer be an edge case, but the default.
should be the thing we pursue. This will happen when people who care about assistive access technologies finally make solutions that are easy to implement into normal contemporary software development workflow. Online video had the same challenges but due to corporate and commercial interests we solved that problem already, arguably a much harder problem to solve than assistive access. I know because for many years I worked on precisely these kinds of assistive access concerns in the audiobooks industry. I am certain that we are not there yet, but we will get there one day.
BUT...
> The whole point of the ADA
None of this is the point of the ADA. The only "whole point" of the ADA is to regulate particular aspects to certain commercial and government services/products.
Why wouldn't I? Your argument appears to boil down to "well not caring about blind users is the status quo, so no reason to change it". I can guarantee you there were similar attitudes among construction workers and architects before wheelchair ramps became mandatory in various jurisdictions (and hell, even after): "well the vast majority of people wanting to enter this building have working legs, so why should I be assed to build a ramp when a staircase will do?".
If you can't be assed to write software that's accessible to blind people, then that is - by definition - discrimination against them. It's not even hard to make a web page reasonably accessible; plain HTML (with or without CSS) is typically perfectly usable with a screen reader, and it's only when that gets mucked up by a tangled mess of DOM-mangling JS (or Flash or Java or Silverlight once upon a time) that anyone needs to actually put any significant effort into accessibility.
https://www.adaptivemobile.com/spamglobe/
If so, you are - by definition - a jerk.
Worse, you think this kind of site would be in violation of the ADA and would subject the creators of the site to legal repercussions and/or litigation?
If so, you are - by definition - insane. Not to mention, illiterate.
More likely, you are not either of these things, but you are instead blinded by an exaggerated sense of concern/worry over this issue, largely impacted upon you by the media you consume. As someone who suffers from a disability which falls under the ADA guidelines, this comes off as being incredibly stuffy, ignorant, and tonedeaf. You're not doing us any favors with your insufferable inability to detach law and life.
Then you add people who push a stroller, pull a (personal) shopping cart, or use a walker, or walk unassisted, but can't lift their legs too high...
> That's 0.9 percent of the US population. That's really, REALLY freakin' specialized.
I can guarantee that 100% of the US population were unable to climb stairs at some point in their lives (except maybe for a few libertarians who emerged fully formed from Ayn Rand's forehead).
... and I'm extremely confident that without the law forcing them to, no office I ever worked in would have spent $2,200 per door on that feature, no matter how useful it is to everyone on the odd day.
One thing I like about accessible websites is that writing scrapers for them are so much easier.
The fact is, nothing is, has been or ever will be completely fair. And that's okay. Everyone makes decisions based on their environment. Most accessibility laws are only applicable to organizations of a certain size, which isn't even most
But if the question is "Where do you set the bar," we already have laws for that. Are they too many?
For others, maybe not as much. In the end, it's a balancing game, and I keep seeing discussion (especially political) lose all sense of nuance or negotiation.
It really does and should be determined by the specific use case. Yes, most sites should be and many are pretty accessible by default. Using Axe, Wave, Lighthouse and other tools is easy enough and should absolutely be done as part of a web application's development. That doesn't mean that everyone who doesn't do it is someone who should be ostracized and cancelled by reactionary mobs.
Which is why it's not a bad idea to stick close to the base HTML spec unless you have a real good reason to deviate from it or use advanced features, JavaScript based animation, etc. Because HTML is a document format not a render format, staying close to home on the spec gives you a lot of accessibility for free. Not all of it, images of course are still just binary blobs without more metadata, but you cover a lot of ground.
A website in flash got approximately zero of that for free, and it was a known issue in that era. Accessibility suffered.
Almost nobody writes software where assistive accessibility is both legally required and discriminatory when it is not provided. That's an outrageous statement to make that you should back up with evidence, not just platitudes.
The software developers who write the systems that stabilize airplanes in the sky, track radio emissions from space, monitor the nuclear reactor cores in power plants, and encode raw YUV video into tightly-compressed packets that can be transmitted over the web, all lack access assistance code. Why don't we go ahead and take these horrible people to task for discriminating against people who need to have their damned screens read to them aloud by software?
Seriously, I and almost everyone else on Hacker News have never THOUGHT ONCE about assistive access in our code, and you are a shitty person if you want to call us all discriminators.
a) the context of the entire conversation is Flash and the web. If you can point me to developers that are writing airplane autopilots, astronomy signal processors, reactor core monitors (oh God), or video compressors in Flash, you are welcome to bring those categories into the conversation.
b) you're applying moral judgement to a statement of fact. I'm not. Everyone discriminates. There is no such thing as universally-accessible software (if nothing else, it fails the first test "Not everyone has hardware to run it"). The reasons we discriminate and the consequences of that discrimination are what matter. I'm personally against the casual, thoughtless discrimination that can result from declaring the HTML render model "too hard" and throwing up one's hands without considering how all relevant user agents that can consume the model do, but if one has considered those user agents (and the users behind them), it can be a valid decision a company can make.
... all of that having been said, for at least the set of developers whose primary target is "the web," not having thought once about assistive access is a mark of an amateur. You can cover a lot of ground in this industry as an amateur, but you'll be held to a higher standard by huge swaths of potential jobs (banks care, universities care, government websites care, consumer websites that do enough business to notice if they lose ~2% of users care). And the nice thing about HTML as a technology is that more often than not, if you do almost nothing, you'll cover 90% of use cases for assistive access.
Oh yes, one target of dozens! Perhaps the only one where this entire conversation of assisted-access technology even matters.
Thinking that software development === HTML & javascript is a truer mark of an amateur.
(No, of course it didn't go into production; Flash VM was way more complicated than the custom hardware we were using. I did a Flash one because I wanted to see if I understood some of the details, and wanted a little animation. I didn't. I learned a few things, though.)
No points. Dang.
Restaurants can offer Braille menus. They aren't forced to put translations in Braille immediately next to every piece of text on the menu they give to everyone.
... granted, they're also screwing themselves over because anyone trying to integrate something like UberEats against them to provide delivery is gonna skip them over for the competitor with the more-easy-to-scrape online presence. ;)
PDF's, for example, can be made accessible if created properly.
PDF lives because it's ubiquitous and stable, despite really rough tooling. If you don't have Acrobat it's a bit of a nightmare to work with, simply because it's so opaque. Yes, you can decompress a PDF to text and look through it by hand, but you need to learn the syntax and know how to use an extensible text editor with the write add-ons; this isn't something your average person in an office will know how to do.
The lack of discoverability is evidenced by the number of posts on Stackexchange etc. that answer "how do I losslessly recompress a PDF?" by giving a command that actually performs lossy downsampling. Or the accidental inclusion of secret layers underneath what were supposed to be blackout redactions. Personally, it took me ages to figure out how to losslessly recompress a monochrome image using JBIG2, which provided an enormous space savings and should have been much easier with some tree-based GUI explorer.
I'm hoping that one day we'll get a good, stable, powerful, reflowable PDF-like format. HTML+CSS+JavaScript works, but it's a huge standard, rendering is not exact, performance (in terms of memory usage in particular) isn't great, it's best created by hand (requiring programming and/or technical knowledge), and it's not really self-contained or sandboxed from network access.
My next website project will be published in PDF, not HTML.
And if your objection is that it can run JavaScript and make web requests, then I have some bad news for you about PDFs.
Can you write more about that? And what was the initial format of a monochrome image in the PDF, and why wasn't it JBIG2?
As to the conversion itself: I think every page was just an image (which was fortunate, as I'm not sure how I would do this otherwise) so I extracted all the images with something like mutool, converted them using jbig2enc after figuring out the flags to use to ensure lossless compression, then use some tool (ghostscript? imagemagick? some dedicated image-to-pdf program?) to smush it all back together.
So the flow was original.pdf -> [page1.png, page2.png, ...] -> [page1.jb2, page2.jb2, ...] -> new.pdf
I can't recall the original format of the images. Obviously it was something less efficient, but it was lossless. Presumably the images were compressed using the less efficient scheme because whoever scanned the pages didn't know they could twiddle some knob on whatever scanner or scanning software they were using. Or there was no knob for them to twiddle.
Yes, browsers do have different layout engines available, but they all go through buggy and inconsistent JavaScript and CSS in the end: the chain is as strong as the weakest link.
At any rate, HTML layout is determined by the spec barring rare bugs, so you can design something that lays out exactly how you want regardless of browser, except that you must decide and specify the layout for any possible width/height combination.
My mother still uses an iPhone SE with a 4.7" screen, while I use a gargantuan phablet. My grandmother has poor eyesight and runs her browser on a 720p screen at 175% zoom, while I have a large high-resolution monitor and normally open browser windows to 1280x2160 portrait. My monitor is color-calibrated and extremely bright during the day, but after sunset it's deep amber and very dim.
If you think that WYSIWYG for the web is desirable, you haven't understood the web.
Maybe the form it takes would be a good place for discussion, but really there is no reason things like this have to be inaccessable to screen readers any more than a native app would be.
I hate designers who think they are typographers. Typography is an engineering discipline. It is not something you want to leave to designers. Especially not insecure designers (and customers) who need constant novelty.
Computers are not paper. Get over it and adapt.
I would accept less than 60 frames per second.
Let’s be fair here: every major web browser also implements an entire virtual OS by this metric, probably even moreso than Java or Flash ever did. Yes, they absolutely do invite hackers with their absurdly complex designs, but advances in security-in-depth have made them fairly hard targets (not invulnerable, though, as Pwn2Own demonstrates annually). Flash and Java never really had enough attention paid to real, in-depth security engineering by comparison, and browsers learned from those lessons and improved. The JavaScript engine and API scope in a modern browser is easily multiples of what you could access from ActionScript in Flash, but the security is much better.
How about we quit ignoring the elephant in the room?
CSS sucks. It was designed for a time when Javascript wasn't required for every website.
Now that we've thrown in the towel and every single website is dependent upon Javascript, we should toss CSS, too.
In the end, technology moves forward. And frankly, there are enough libraries for grid/layout that really close to just work. I find that material-ui with react is insanely easy to use compared to what came before. Every time I do anything more custom, yeah, I have to google it and play around witht he CSS rules. However, for CRUD guis, material-ui library all the way.
In the end, you aren't going to get away with knowing nothing. Even in the Flash days, if you wanted to do anything interesting you had to know ActionScript and the quirks that went with it. For forms and crud apps, you had Flex, which had its' own niceties but wasn't a panacea either and wasn't WYSIWYG either.
What could have saved Flash was opening the runtime and creating an interoperable specification and let browser vendors work with Adobe (Macromedia and I forget the company before that) etc. Silverlight was much closer, but still sucked in a lot of ways that held it back in the end. Flash's tooling still exists and iirc targets HTML5 these days, so you can still pay and use it.
If Flash had simply been a bundle spec for a zip archive with a manifest file, JS, SVG and MP3 (or other audio) and video files it could still be a thing. I had hoped that would be the direction it would go when Adobe bought Macromedia. It wasn't. It was the source of too many bugs and crashes and it died because of it.
Out of these two conflicting ideas come all sorts of issues. Accessibility is one, but so are things like scraping, copy/paste, DRM, confidentiality, artistic integrity, cross-platform compatibility, new devices, peformance & resource consumption, etc.
The server having more control doesn't necessarily harm accessibility. It's a matter of making sure sufficient meta-data is included. It's possible accessibility is more work under the second, but not outright impossible. (I've stated more about accessibility nearby.)
For CRUD apps, you really just want HStacks, VStacks, and ZStacks like they have in SwiftUI.
They nicely express reflow behavior without driving you crazy or bloating your code. They're a bit more work than drag-and-drop because they make you be explicit about resizing/reflow, but you should be thinking about that anyway.
You'll want to skip that step when iterating quickly on design, but that's why you design in a separate design tool, which is visual and uses position:absolute.
When you're ready to parameterize the design over varying content and screen sizes you'll have to specify resizing constraints somehow, and in my experience, VStacks/HStacks in code are a pretty good way to do it.
I recommend adding building these abstractions on top of flexbox, and adding them to your standard library.
This is all specifically for CRUD apps. If you're making an animation, or something else that would feel wrong to call a "document", you probably want a completely different set of tools.
If the "designer" of a web page were able to send me plain text and links only, with my client application in control of the font, size, line width, layout, etc, I would prefer that to current state of the web.
One thing I do wish they would / could do in situations like this though is open-source the core of that crawler, so if someone else finds a purpose for it, they could run their own on whatever corpus they care to index. But, such is the price of relying on closed-source software for things.
I'm all for downranking it to the last page, but when your google results only has 2 pages total, every single result matters, including that flash content.
That runtime is likely to end up looking a lot more like a console hardware emulator than a data parser.
Its funny how many people are willing to give up their freedom to decide what works best for them, and let others decide, in the name of "im doing all this for your own good".
You should always have the right to decide what technology to use, what you install and download on your device.
The whole app store deciding what they allow or not, not giving you any other alternative, should be deemed inconstitutional in a society who knows whats happening, when people have nowhere else to go because the digital dictatorship is in control of your digital life.
This whole trend smells digital feudalism to me, and it was Jobs that started this whole dangerous trend to the bottom of our civil liberties.
Why are you defending this new feudal lord who are mining your right to choose what you do with your own property?
If after having bought a house, the guy(or company) who have selled to you, had made some demands of how you could use the kitchen, or the bedroom, would you think its within his right to do so?
Each and every time a costumer buys an iPhone they're deciding.
Adobe decided to do a half-assed flash player for the Mac. That decision proved to be wrong.
Or do you really expect that Adobe would do a decent job supporting an new platform when they couldn't even bother supporting the big cash cow Apple had at that time?
You can buy the house from the company defining rules of how you should use the house you bought from them and denying you access to the things they forbid.
Lets suppose you have options to buy a house from the ones that does not do this, ok.. until the company who are ruling over your property are making a big buck, and they decide to play by the same rules..
so hey, where are your options to buy a house without vendor rules? thats right, their gone..
Only that we are talking about something much more important here which has to do with data..
Private companies should never be allowed to do this, unless they offer options (other app stores should be possible), and have rules to filter who can offer apps to your device that dont damage your freedom of choice (dont forbid things on political views, taste, harassing competition, etc..).
Android is becoming more akin to Apple each day, and what you have in the end is a false sense of choice.
This is why the rule of law and a functioning government is so important.
> Adobe decided to do a half-assed flash player for the Mac.
Than if it will deliver a crappy experience, let the user decide for his own. Suppose the user agree with Apple/Jobs here and dont like to use it, but theres that tool that are available only in Flash, you need it for your mechanical enginnering job for instance.. You had a choice, a bad one, yes, but now you have none. Just because 'simon says' so..
And we are not even thinking about the small players with less resources than Adobe, that will not have the resources to make the "good experience" by whatever standards imposed by the overlord dujour.
And thats because we are assuming good faith, because the ruler of your own property, can even lie about be doing this for your own sake, and just use this to bar the competition.
By the way i never touch anything Apple because of this, but because they were the ones who leaded the smartphone industry, the rules they have specified in the beggining tend to be copied by the competition, and to become the norm.
Its not the same as creating a new car company in the XXI century where we have standards, good rules, etc..
The pioners have the power to define the reality of the industry in years to come. And giving its about our digital life, its becoming more and more important each day.
Data and digital platforms are in the XXI century what the oil was in the XX century. Pervasive, powerful, defining everything else.
Does Google no longer index .zip files and the like? Obviously they can't process any content in those formats, but if the file name contains the right keywords... shouldn't search be file type agnostic?
I've had .exe's show up in Google results. It was a long time ago—so maybe things don't work like that anymore—and it was never common, but I know I've seen it happen. I'm sure Google could look inside the binary for text strings, but I can't imagine they do.
There is perhaps an argument that standalone exe's shouldn't turn up in results for security reasons (how can you possibly verify its safety without some context?), but I liked to think that search results could at least theoretically include any file type at all.
so much is said and implied in those sad, sad words
The only tool that does this to my knowledge is Tumult's Hype: https://tumult.com/hype/. I'm glad it's using an old-school pricing model of one-time payment and not the subscription model that Adobe and everyone else switched to.
Adobe Animate used to be a thing, but that got sunset years ago. There is Adobe After Effects + Lottie, but that assumes you are a front-end developer and know how to integrate those tools together and use the resulting JSON.
No wonder then that the only visually interactive websites out there these days are things like "Spotify Year in Music" stuff that probably takes an entire team multiple sprints to build.
Hype is a desktop app that give you much more control and is targeted at Flash game devs, web designers and others.
https://tumult.com/hype/
Adobe Animate received two feature updates last year and at least one bug fix update this year.
So, it's not dead yet. Maybe wait until after Adobe MAX (which starts in a few days) to write its obit?
But I also think this is a bad idea, just from an information retention scenario. What ever happened to "to organize the world's information and make it universally accessible and useful?"
What will Google decide the world doesn't need to know about next? HTML2? JPEGs? non-Google-hosted javascript?
This is what we get for allowing a private company to be the gatekeeper of our culture.
Also, it's not just Google doing this. Pretty much every major browser vendor is dropping support for Flash in 2020.