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.
... 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.
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.
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.
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.
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.
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. 
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:
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.
borski above describes context pretty well too, since it depends on the commercial context in which you're operating
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.
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.
A website in flash got approximately zero of that for free, and it was a known issue in that era. Accessibility suffered.
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.
(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.
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.
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  application should be punished for not building assistive access into his GPLv2 project, and how he should have & could have actually done so.
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 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.
> 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.
... 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.
PDF's, for example, can be made accessible if created properly.
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 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.
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.
My next website project will be published in PDF, not HTML.
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.)
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.
In my view, we sacrificed a lot at the altar of “predictable layout”.
> 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:
Something like this could change the web.
 - Except maybe Firefox, but it has to follow Chrome on most things to stay relevant.
<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.
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.
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?
For as rough as PDF tooling is, flash is even worse.
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.
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 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,
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.
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.
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.
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.
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.
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.
Would a canvas and/or SVG GUI be acceptable?
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.
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.
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.
How about we quit ignoring the elephant in the room?
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.
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?
Hype is a desktop app that give you much more control and is targeted at Flash game devs, web designers and others.
Back in the day I worked with a team that created training modules for products. We had a team of animators that was creating beautiful stuff. We had a cast of characters, voice talent, the whole shebang. It was very popular, especially in Asia where they loved the animated training.
Then the iPad came out. Our customers informed us that they were going to adopt the iPad for their on the floor training. Well, the iPad didn't support Flash so we had to rebuild everything to be HTML/CSS/JS only. It has been nearly 10 years and we are still using plain text, images, and the occasional video. We tried bringing back the interactive animations over the years, but nothing has come out that comes anywhere close to working as well as Flash did. It really sucks that despite nearly a decade no Flash replacement has emerged. I really feel like we lost something when Flash died. Interactive animations have been replaced with youtube videos and boring text and image web pages.
I don't think it's as simple as "web secure, everything else bad". For the very longest time only Chrome and Safari had working sandboxes, and there wasn't a huge difference in the exploit stream between WebKit, Flash, Java and Adobe Reader. They all had somewhat similar feature sets.
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.
- Every page had its own navigation style.
- Every page had its own font which you could not change. Remember the trend with 8px bitmap-like fonts where you used a special setting so they would render very sharp?
- Every page had its own scrolling style. Want to use the mouse wheel? Nope.
- Caret navigation for the impaired or people who prefer keyboard navigation? Forget about it.
- Stop sound? Only if we give you a button for that.
- Here's our looping video intro, you must watch it before accessing this website.
- Deep hyperlink to the next "page"? That came very very late. A bit too late for Flash.
- View on mobile? Even if you had the plugin somehow installed (some people did back in the day on Android) pages would still be unusable.
- An error has occurred within this SWF blob, good luck debugging.
- Later came the exploits.
I was a fan for a while and used it since Macromedia Flash 4, but I'm glad it's dead and buried. It was poor tech which subverted progress in the HTML/CSS/JS space for many years.
Quite interesting if you think about it! A bit of an antithesis to the idea that what's on the web is preserved forever.
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...
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...
Looks like it got dropped from Ubuntu though.
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.
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.
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.
Technically, yes. Commercially, no.
remember that time when Steve jobs kept out flash from iPhone /iPad vs Google's stance to go full on support for flash on mobile :)
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.
I wonder what NewGrounds is going to do about all their older content?
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.
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.
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.
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.
1. Adobe announced Flash's EOL by the end of 2020. Google isn't killing Flash, it's already dead.
2. Indexing Flash means parsing site structure embedded within SWF files. When was the last time you saw a website with Flash navigation? Your SWF web games are embedded in normal webpages that will still be searchable via H1 tags, backlinks, and so on.
Surprising number of Flash lovers coming out of the woodwork after nearly a decade of Flash hate on HN (proprietary, security holes, etc).
But in the web era, IP isn't king; communications is.
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 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?"
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.
- 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.