4 ms·

No it isn't. If the whole "page" is Flash or Java - and this absolutely used to be a thing - then if that's blocked you've got nothing. With Javascript the page

by mrec 7y ago

No it isn't. If the whole "page" is Flash or Java - and this absolutely used to be a thing - then if that's blocked you've got nothing. With Javascript the page author has at least the option of doing it properly i.e. semantic markup plus (optionally) progressive enhancement.

tabtab 7y ago
Developers loved Flash: you controlled the layout, not some greedy browser vendor and their screwy CSS anti-rules, and Flash had a lot of interactive options that have be emulated in HTML browsers using ugly work-arounds. Flash just wasn't able to solve security problems. Java applets also suffered under the security ax. Flash was based on absolute coordinates, not client side auto-flow the way browsers usually are. This means consistency across browsers. And it doesn't rule out layout engines, for you could hook any layout engine you wanted to up to it; it just happened on the server side. But doing it on the server side means consistency: you have one and only one layout engine, not IE 6,7,8,8.5,9 and Chrome 2,3,4,5 and Safari 3,4,5,6 etc. That's bad factoring of UI and testing, a huge DRY violation at the industry level. Humans, you screwed that up! Admit it, Web is a mass labor drain.
- kevin_thibedeau 7y ago
  > you controlled the layout You don't control the display which is the entire point of a hypertext reflowable render engine. There were a ton of crappy designery flash sites with inscrutable navigation and "works best in 800x600" inflexible layout.
  - tabtab 7y ago
    If you can query the monitor's size and/or preference, you can adjust as needed. Just because many applications didn't doesn't mean they can't. Most web-based apps get it wrong also. One-markup-fits-all is very difficult to do well such that usually one has to emphasize a given monitor size or use a lowest-common denominator, meaning C- quality for all sizes. Even the big vendors like MS and Google often do it poorly. For example, on big monitors you can do more in a single step (screen). On small devices you generally have to break big UI activities into multiple steps (screens). That means more going back and forth for big screen users, which they find annoying and unnecessary. That's not JUST a widget "re-flow" issue, that's an entire UI design difference. On real GUI's you can have pop-up dialogs or pick-lists that don't hide the underlying form, or at least that you can slide around to see the underlying form. For phone-centric UI's, you can't do this, so you have to back up to get prior-entered info and then move forward and redo your half-filled sub-form. Maybe someday somebody will invent a way to do both well without a different code base, but until then, doing both well at the same time is either a pipe dream or takes an expensive rock-star UI designer and fragile dependency-causing JS libraries.

by mrec 7y ago

tabtab 7y ago

Developers loved Flash: you controlled the layout, not some greedy browser vendor and their screwy CSS anti-rules, and Flash had a lot of interactive options that have be emulated in HTML browsers using ugly work-arounds. Flash just wasn't able to solve security problems. Java applets also suffered under the security ax. Flash was based on absolute coordinates, not client side auto-flow the way browsers usually are. This means consistency across browsers. And it doesn't rule out layout engines, for you could hook any layout engine you wanted to up to it; it just happened on the server side. But doing it on the server side means consistency: you have one and only one layout engine, not IE 6,7,8,8.5,9 and Chrome 2,3,4,5 and Safari 3,4,5,6 etc. That's bad factoring of UI and testing, a huge DRY violation at the industry level. Humans, you screwed that up! Admit it, Web is a mass labor drain.

kevin_thibedeau 7y ago
> you controlled the layout You don't control the display which is the entire point of a hypertext reflowable render engine. There were a ton of crappy designery flash sites with inscrutable navigation and "works best in 800x600" inflexible layout.
- tabtab 7y ago
  If you can query the monitor's size and/or preference, you can adjust as needed. Just because many applications didn't doesn't mean they can't. Most web-based apps get it wrong also. One-markup-fits-all is very difficult to do well such that usually one has to emphasize a given monitor size or use a lowest-common denominator, meaning C- quality for all sizes. Even the big vendors like MS and Google often do it poorly. For example, on big monitors you can do more in a single step (screen). On small devices you generally have to break big UI activities into multiple steps (screens). That means more going back and forth for big screen users, which they find annoying and unnecessary. That's not JUST a widget "re-flow" issue, that's an entire UI design difference. On real GUI's you can have pop-up dialogs or pick-lists that don't hide the underlying form, or at least that you can slide around to see the underlying form. For phone-centric UI's, you can't do this, so you have to back up to get prior-entered info and then move forward and redo your half-filled sub-form. Maybe someday somebody will invent a way to do both well without a different code base, but until then, doing both well at the same time is either a pipe dream or takes an expensive rock-star UI designer and fragile dependency-causing JS libraries.