www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - [OT] HTML: div/iframe hybrid?

reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
(Pardon the ot, but I know there are other webdevs here). For various 
reasons, I like to keep my html...uhh...let's say "non-bleeding-edge" 
:), downside of course being I tend to not be quite as up on what's out 
there as I should be. So just tossing this question out there:

I know (at least historically) iframes don't normally resize based on 
their internal content, but only based on the the outer html page. Aside 
from the obvious JS, does modern HTML/CSS provide any way to have 
something like an iframe (ie, embed content from another URL), but 
otherwise behaves and flows more like a div, expanding (at least 
vertically, even if nothing else) as the embedded content expands?

Would it be too kludgey or questionable-compatibility (or just fail) to 
just use CSS to set the iframe element to block-style layout?
Feb 25 2015
next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
Not that I know of. The way I do it is to set a static height in 
the css based on what I expect should be good enough, then do 
javascript to resize. There's a newish postMessage function that 
works pretty well for it.

It is a pity you still can't get it to automatically size though, 
I'd use the heck out of that.
Feb 25 2015
prev sibling next sibling parent reply "Kagamin" <spam here.lot> writes:
AFAIK, <div src="..."> syntax was proposed for this purpose (with 
fallback) in early editions of html5, don't know if it made it 
into the standard.
Feb 26 2015
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 02/26/2015 03:30 AM, Kagamin wrote:
 AFAIK, <div src="..."> syntax was proposed for this purpose (with
 fallback) in early editions of html5, don't know if it made it into the
 standard.
Hmm, just looked that up, but all I found on that was one page that implies (sadly, with no sources referenced) it did not make it in: http://hannah.wf/why-dont-all-html-elements-have-a-src-attribute/ However, looks like what happened instead was iframe grew a "seamless" attribute, which frankly looks pretty damn sweet: http://benvinegar.github.io/seamless-talk/#/12 Still researching browser compatibility and adoption though. TL;DR: New in HTML5: <iframe seamless src="url" /> is the answer (assuming it isn't still *too* new, not sure yet)
Feb 26 2015
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 02/26/2015 02:59 PM, Nick Sabalausky wrote:
 On 02/26/2015 03:30 AM, Kagamin wrote:
 AFAIK, <div src="..."> syntax was proposed for this purpose (with
 fallback) in early editions of html5, don't know if it made it into the
 standard.
Hmm, just looked that up, but all I found on that was one page that implies (sadly, with no sources referenced) it did not make it in: http://hannah.wf/why-dont-all-html-elements-have-a-src-attribute/ However, looks like what happened instead was iframe grew a "seamless" attribute, which frankly looks pretty damn sweet: http://benvinegar.github.io/seamless-talk/#/12 Still researching browser compatibility and adoption though. TL;DR: New in HTML5: <iframe seamless src="url" /> is the answer (assuming it isn't still *too* new, not sure yet)
Well, it appears seamless iframes are basically useless despite (from what I can tell) apparently being in the spec for a few years now. Doesn't work at all in even the latest FF. Didn't bother testing the others, but according to this, even today seamless iframes are still supported in exactly *nothing*: http://caniuse.com/#feat=iframe-seamless Setting the "display:block" on the iframe's css doesn't help, it just affects placement, not how it gets sized. There are a few basic CSS settings that help a *little* bit though: border-width: 0px; background-color: transparent; padding: 0px; overflow: hidden; Too bad :( Is it just me or does the moniker "HTML5" seem pretty useless since there doesn't appear to have ever been any *actual* HTML5 spec, just an ever-changing target with piecemeal browser adoption?
Feb 27 2015
parent reply "Kagamin" <spam here.lot> writes:
Just posted: http://jonrimmer.github.io/are-we-componentized-yet/
Is it what you need?
Mar 06 2015
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 03/06/2015 07:16 AM, Kagamin wrote:
 Just posted: http://jonrimmer.github.io/are-we-componentized-yet/
 Is it what you need?
No, what I was looking for was a way to do "Just drop these few lines of code into your HTML" a la Disqus, but without relying on JS. Iframes have always fit that (along with other benefits that "shadow DOM" is merely re-inventing), but only problem is iframes (still) can't auto-expand downwards as the internal content grows - hence, awkward internal scrollbars. I haven't looked at the details, but "HTML Imports" sounds like something that might have been able to fit that, but according to that page, not only do Safari and IE not support them, but apparently Firefox is INTENTIONALLY not doing them because (if I understand this "polyfill" thing right) it seems Mozilla deliberately wants to force basic things like that to always rely on JS. (Just a general overall observation: I seriously don't understand what the hell goes on in people's minds over at Mozilla).
Mar 07 2015
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Saturday, 7 March 2015 at 17:01:14 UTC, Nick Sabalausky wrote:
 I haven't looked at the details, but "HTML Imports" sounds like 
 something that might have been able to fit that, but according 
 to that page, not only do Safari and IE not support them, but 
 apparently Firefox is INTENTIONALLY not doing them because (if 
 I understand this "polyfill" thing right) it seems Mozilla 
 deliberately wants to force basic things like that to always 
 rely on JS.
No, I think they just want to make sure it is the right way to do it before it is implemented. The polyfill webcomponents-lite.js should give HTML import and templates for IE11+: https://github.com/WebComponents/webcomponentsjs#browser-support
Mar 08 2015
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 03/08/2015 04:31 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
<ola.fosheim.grostad+dlang gmail.com>" wrote:
 On Saturday, 7 March 2015 at 17:01:14 UTC, Nick Sabalausky wrote:
 I haven't looked at the details, but "HTML Imports" sounds like
 something that might have been able to fit that, but according to that
 page, not only do Safari and IE not support them, but apparently
 Firefox is INTENTIONALLY not doing them because (if I understand this
 "polyfill" thing right) it seems Mozilla deliberately wants to force
 basic things like that to always rely on JS.
No, I think they just want to make sure it is the right way to do it before it is implemented. The polyfill webcomponents-lite.js should give HTML import and templates for IE11+: https://github.com/WebComponents/webcomponentsjs#browser-support
Well, the problem with polyfill is that it defeats the whole point. Pretty much anything can *already* be done via cross-browser JS libs. But some things have no justification for requiring ANY of the bloat or bother of JS - hence "a href", ":hover", seamless iframes, html imports, and many other examples. So polyfill accomplishes nothing - it's little more than a new name for what we've ALWAYS had: over-reliance on JS libs for basic, basic functionality.
Mar 09 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 9 March 2015 at 19:23:10 UTC, Nick Sabalausky wrote:
 Well, the problem with polyfill is that it defeats the whole 
 point. Pretty much anything can *already* be done via 
 cross-browser JS libs. But some things have no justification 
 for requiring ANY of the bloat or bother of JS - hence "a 
 href", ":hover", seamless iframes, html imports, and many other 
 examples. So polyfill accomplishes nothing - it's little more 
 than a new name for what we've ALWAYS had: over-reliance on JS 
 libs for basic, basic functionality.
Sure, if you want safe inclusion then there is no alternative to iframes, html imports are not safe, I think? But I think polyfills are different from using JS in general, since it is a temporary replacement that allows legacy browsers to access your site while your design is using current an upcoming tech. So it is more like embedding a temporary emulation layer than actively using JS.
Mar 10 2015
prev sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Saturday, 7 March 2015 at 17:01:14 UTC, Nick Sabalausky wrote:
 On 03/06/2015 07:16 AM, Kagamin wrote:
 Just posted: 
 http://jonrimmer.github.io/are-we-componentized-yet/
 Is it what you need?
No, what I was looking for was a way to do "Just drop these few lines of code into your HTML" a la Disqus
Hate when websites do things like that. I will take JS any time over it. It has become slightly better with same origin policy but generally if website has iframe most likely it either looks horribly out of style or is abused for malicious means.
Mar 09 2015
parent "Kagamin" <spam here.lot> writes:
On Tuesday, 10 March 2015 at 05:08:53 UTC, Dicebot wrote:
 Hate when websites do things like that. I will take JS any time 
 over it. It has become slightly better with same origin policy 
 but generally if website has iframe most likely it either looks 
 horribly out of style or is abused for malicious means.
I suppose, that's the point: you can't inject styles into foreign iframe, while html fragment, injected into the page, inherits page's style.
Mar 10 2015
prev sibling parent reply Alix Pexton <alix.DOT.pexton gmail.DOT.com> writes:
On 25/02/2015 9:55 PM, Nick Sabalausky wrote:
 (Pardon the ot, but I know there are other webdevs here). For various
 reasons, I like to keep my html...uhh...let's say "non-bleeding-edge"
 :), downside of course being I tend to not be quite as up on what's out
 there as I should be. So just tossing this question out there:

 I know (at least historically) iframes don't normally resize based on
 their internal content, but only based on the the outer html page. Aside
 from the obvious JS, does modern HTML/CSS provide any way to have
 something like an iframe (ie, embed content from another URL), but
 otherwise behaves and flows more like a div, expanding (at least
 vertically, even if nothing else) as the embedded content expands?

 Would it be too kludgey or questionable-compatibility (or just fail) to
 just use CSS to set the iframe element to block-style layout?
My understanding of the argument against doing this is that it would be a potential security hole. If the content of an iframe could control its size it could theoretically hijack the parent page. Instead, I would consider using JS to load and insert the content, or generate the composite page on the sever. A... --- This email has been checked for viruses by Avast antivirus software. http://www.avast.com
Feb 26 2015
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 02/26/2015 04:34 AM, Alix Pexton wrote:
 My understanding of the argument against doing this is that it would be
 a potential security hole. If the content of an iframe could control its
 size it could theoretically hijack the parent page.

 Instead, I would consider using JS to load and insert the content, or
 generate the composite page on the sever.
Ehh, I'm not sure I buy that. 1. I don't see how the inner content could "squeeze out" the outer page unless the iframe/external-div/whatever is the very first piece of content on the page. Which is highly unlikely since pretty much every site at least has some header logo/banner/menu or something. 2. Using JS to fill an element or server-side compositing suffers from the same theoretical issue too. So really it has nothing to do with iframes and everything to do with embedding external content (which has become ubiquitous anyway, what with ads, jquery, various google tools, disqus, twit/face share widgets, etc.) Sure, with JS or server-side compositing, there's at least the possibility of sanitizing the inner content first, but that'd be a heuristic mess, and perhaps a pointless bother anyway since... 3. Even if all else fails, the outer page's author should easily be able to mitigate such a problem with a reasonable max-width/max-height. I think the big thing though is the "really it has nothing to do with iframes and everything to do with embedding external content".
Feb 26 2015
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
I don't think it is a security hole, but websites typically do 
not get to set their viewport - the window size is under the 
user's control. (one of the few things they have left under the 
user's control!)

So if you told a site to set its own size... it wouldn't really 
know what that is most the time. At least widths tend to be fluid 
and variable. Heights sometimes are set dynamically too.

There's solutions to this - the containing page might set it to a 
width, then let the height be fluid. That's what most the JS 
solutions do and it works pretty well. But maybe that still feels 
too hacky for the standards committees, or is just messy to 
implement for the browser developers.
Feb 26 2015
next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 02/26/2015 02:51 PM, Adam D. Ruppe wrote:
 I don't think it is a security hole, but websites typically do not get
 to set their viewport - the window size is under the user's control.
 (one of the few things they have left under the user's control!)

 So if you told a site to set its own size... it wouldn't really know
 what that is most the time. At least widths tend to be fluid and
 variable. Heights sometimes are set dynamically too.

 There's solutions to this - the containing page might set it to a width,
 then let the height be fluid.
Yea, that's kinda what I had in mind anyway. All these "embedded widget" things are such a major thing now, and I totally get their appeal and value (want X feature on your site? Just copy/paste this snippet into your page REGARDLESS of your server's language/engine!) But so much of it is done with JS, which is totally unnecessary. Most such things can easily be no-JS iframes (and I guess some are), but one problem is stuff like disqus that needs to grow/expand vertically. Traditional iframe can't really handle that. Looks like HTML5 iframes, thanks to the seamless attribute, WILL be able to handle something like disqus just fine with NO js, but looks like seamless is still rather cutting edge and spotty compatibility despite having been a thing for several years already. Maybe it can be managed well enough with CSS tweakery though, for browsers that aren't ultra cutting edge.
 That's what most the JS solutions do and
 it works pretty well. But maybe that still feels too hacky for the
 standards committees, or is just messy to implement for the browser
 developers.
Feb 26 2015
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 02/26/2015 02:51 PM, Adam D. Ruppe wrote:
  the window size is under the user's control.
 (one of the few things they have left under the user's control!)
Yea. Speaking of, that mobile-directed "no zoom" css thing is seriously fucking evil. If browser devs had any basic integrity whatsoever they'd deliberately ignore that abomination of an attribute, or at least let any B&D users who enjoy being told what they can't do on their own miniature device just opt-in to it.
Feb 26 2015
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Feb 26, 2015 at 03:36:04PM -0500, Nick Sabalausky via Digitalmars-d
wrote:
 On 02/26/2015 02:51 PM, Adam D. Ruppe wrote:
 the window size is under the user's control.
(one of the few things they have left under the user's control!)
Yea. Speaking of, that mobile-directed "no zoom" css thing is seriously fucking evil. If browser devs had any basic integrity whatsoever they'd deliberately ignore that abomination of an attribute, or at least let any B&D users who enjoy being told what they can't do on their own miniature device just opt-in to it.
I find this trend extremely disturbing and exceptionally annoying. I wish every browser would come with an option to override everything the author tries to shove down your throat and using what YOU, the user, specify as default instead. Opera used to have an "author mode" and "user mode", where you can set up custom CSS that completely replaces the website's CSS at the touch of a key. Whenever I come across an annoying site with unreadable fonts, garish colors, way too many ads, or text that's unreadable unless you turn on JS (ha! nice try!), a single key-combo discards that whole nonsense and restores power to the user. Bam. Sadly, after they ditched Linux, the Presto engine, the original devs, and jumped on the Chrome bandwagon, Opera is pretty much dead as far as I'm concerned, so these days I'm using Vimperator/Firefox instead. While it *is* possible to setup user CSS, it's more tedious than it has to be, and I'm not sure if it's possible to make it switcheable via a key without having to edit .css files manually. Although, on second thoughts, that's not necessarily a bad thing... a universal stylesheet that removes all useless font changes, colors, extraneous images, and formats everything into fixed-width 80 column paragraphs, now that could the ticket to pure bliss! :-P Just give me the content, m'am, keep all the frills to yourself. Oh, you mean there's nothing left after the frills and eye-candy are gone? Well, then, I'll move on to another site that actually sports content, thank you very much, have a nice day. T -- Lawyer: (n.) An innocence-vending machine, the effectiveness of which depends on how much money is inserted.
Feb 26 2015
next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Thu, 26 Feb 2015 13:34:53 -0800, H. S. Teoh via Digitalmars-d wrote:

 Opera used to have an "author mode" and "user mode", where you can set
 up custom CSS that completely replaces the website's CSS at the touch of
 a key. Whenever I come across an annoying site with unreadable fonts,
 garish colors, way too many ads, or text that's unreadable unless you
 turn on JS (ha! nice try!), a single key-combo discards that whole
 nonsense and restores power to the user. Bam. Sadly, after they ditched
 Linux, the Presto engine, the original devs, and jumped on the Chrome
 bandwagon, Opera is pretty much dead as far as I'm concerned, so these
 days I'm using Vimperator/Firefox instead. While it *is* possible to
 setup user CSS, it's more tedious than it has to be, and I'm not sure if
 it's possible to make it switcheable via a key without having to edit
 .css files manually.
wow, another once-i-was-happy opera user! i'm still using opera 12,=20 'cause all other browsers can't give me the features i want.=
Feb 26 2015
parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, Feb 27, 2015 at 12:31:43AM +0000, ketmar via Digitalmars-d wrote:
 On Thu, 26 Feb 2015 13:34:53 -0800, H. S. Teoh via Digitalmars-d wrote:
 
 Opera used to have an "author mode" and "user mode", where you can
 set up custom CSS that completely replaces the website's CSS at the
 touch of a key. Whenever I come across an annoying site with
 unreadable fonts, garish colors, way too many ads, or text that's
 unreadable unless you turn on JS (ha! nice try!), a single key-combo
 discards that whole nonsense and restores power to the user. Bam.
 Sadly, after they ditched Linux, the Presto engine, the original
 devs, and jumped on the Chrome bandwagon, Opera is pretty much dead
 as far as I'm concerned, so these days I'm using Vimperator/Firefox
 instead. While it *is* possible to setup user CSS, it's more tedious
 than it has to be, and I'm not sure if it's possible to make it
 switcheable via a key without having to edit .css files manually.
wow, another once-i-was-happy opera user! i'm still using opera 12, 'cause all other browsers can't give me the features i want.
I clung on to Opera 12 for as long as I could, but in the past few months its age is becoming increasingly obvious (and inconvenient), and clearly that's only going to get worse with time. It's also becoming clear that the complete lack of security upgrades is an ever-expanding security threat, so I had to look for something else. Firefox was the natural alternative, but I resisted it for a long time because I hated the interface (esp. the Chrome-wannabe parts, and the pervasive rodent-dependence). With Vimperator, however, it has finally become usable (for the most part), so I started using it side-by-side with Opera. It took a while to get used to, but one day I found myself subconsciously reaching for Vimperator key combos even while using Opera, and I knew it was time to finally let Opera go. Farewell, Opera. Thanks for the ride -- while it lasted. Boo to the people who twisted it into the caricature of its former self that is the Opera of today. T -- The best compiler is between your ears. -- Michael Abrash
Feb 26 2015
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 02/26/2015 04:34 PM, H. S. Teoh via Digitalmars-d wrote:
 On Thu, Feb 26, 2015 at 03:36:04PM -0500, Nick Sabalausky via Digitalmars-d
wrote:
 Yea. Speaking of, that mobile-directed "no zoom" css thing is
 seriously fucking evil. If browser devs had any basic integrity
 whatsoever they'd deliberately ignore that abomination of an
 attribute, or at least let any B&D users who enjoy being told what
 they can't do on their own miniature device just opt-in to it.
I find this trend extremely disturbing and exceptionally annoying. I wish every browser would come with an option to override everything the author tries to shove down your throat and using what YOU, the user, specify as default instead.
Yea. I'm a steadfast believer in the the design principle of "highly configurable with reasonable defaults". Ideally, everything should be configurable and nothing should NEED to be configured. Or as close to that as possible. Unfortunately, it seems that most developers either don't see that possibility, or believe it to be far more difficult than it really is. Hence the trend towards Apple-ified software: "You'll take whatever we let you have and you'll like it. Because it makes things easier for us. Because our time is more important than yours. If you don't like it, you're wrong. Any dissatisfaction simply proves you're an unreasonable complainer." What baffles me is that many modern developers seriously seem to HATE the idea of ever having to take any real-world user needs and use-cases into consideration. So why the F are they even writing any software in the first place? They obviously aren't writing it for the user, they make it quite clear they RESENT the user. So isn't it even easier still just to release nothing at all? One of these days I still want to make an FF addon to just bring sanity back to the whole freaking thing. Maybe later split it off into its own Webkit/Chromium-based browser. I'm seriously fed up with Mozilla's BS (like you mentioned in a later post, way too much Chrome-envy, among other issues), but the only alternatives are worse.
 Just give me
 the content, m'am, keep all the frills to yourself. Oh, you mean there's
 nothing left after the frills and eye-candy are gone? Well, then, I'll
 move on to another site that actually sports content, thank you very
 much, have a nice day.
And "content" does NOT mean "A barely-meaningful slogan or two and a vaguely related image tossed onto a mostly-blank page. Scroll down to get a few more slogans and clipart." (*cough* mobile-first design *cough*) But yea, that's the thing I don't get about the JS proponents: The argument always goes back to "It allows sites to be more dynamic!"[1] Umm, ok, and that's a good thing why exactly? They never seem to have a real reason of course, it's just taken for granted that "more dynamic" is unquestionably better, because it just is, and because we can. Oh yea, and call something "passe" because that'll REALLY prove some sort of worthwhile point. [1] Then they also like tossing around the meaningless buzzword of "richer experience", thus proving they're only regurgitating groupthink and haven't actually thought through much of anything.
Feb 26 2015
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Feb 26, 2015 at 11:50:04PM -0500, Nick Sabalausky via Digitalmars-d
wrote:
 On 02/26/2015 04:34 PM, H. S. Teoh via Digitalmars-d wrote:
On Thu, Feb 26, 2015 at 03:36:04PM -0500, Nick Sabalausky via Digitalmars-d
wrote:
Yea. Speaking of, that mobile-directed "no zoom" css thing is
seriously fucking evil. If browser devs had any basic integrity
whatsoever they'd deliberately ignore that abomination of an
attribute, or at least let any B&D users who enjoy being told what
they can't do on their own miniature device just opt-in to it.
I find this trend extremely disturbing and exceptionally annoying. I wish every browser would come with an option to override everything the author tries to shove down your throat and using what YOU, the user, specify as default instead.
Yea. I'm a steadfast believer in the the design principle of "highly configurable with reasonable defaults". Ideally, everything should be configurable and nothing should NEED to be configured. Or as close to that as possible.
Making everything configurable is hard, though. Well, not *that* hard if you design your code properly, but in the webdev world, sometimes it's all about unreasonable deadlines and shipping it as fast as possible. Good design -- what's that?? As a result, making things configurable is harder than it ought to be, and the returns are low 'cos most people won't even bother configuring anything in the first place. Result: nobody cares, and nobody implements it. [...]
 One of these days I still want to make an FF addon to just bring
 sanity back to the whole freaking thing. Maybe later split it off into
 its own Webkit/Chromium-based browser. I'm seriously fed up with
 Mozilla's BS (like you mentioned in a later post, way too much
 Chrome-envy, among other issues), but the only alternatives are worse.
When Opera ditched Presto, I died a little inside. Back in the day, Presto was the only serious alternative to the other major offerings (I even introduced Opera to my non-techie cousin and she liked it!), and was the only one that offered the level of configurability that I liked. In the early days it was also slim and fast, though it started bloating up toward the final days. But then Opera died and went the way of Chrome and now we're stuck with the IMO inferior choices. At least Vimperator made FF tolerable. Not enough, though. Perhaps one of these days when I have time (har har) I'll take it even further, and fully eradicate the rodent dependence and other Chrome-envy and replace it with something useful. Like a D REPL, I dunno. j/k :-P
Just give me the content, m'am, keep all the frills to yourself. Oh,
you mean there's nothing left after the frills and eye-candy are
gone? Well, then, I'll move on to another site that actually sports
content, thank you very much, have a nice day.
And "content" does NOT mean "A barely-meaningful slogan or two and a vaguely related image tossed onto a mostly-blank page. Scroll down to get a few more slogans and clipart." (*cough* mobile-first design *cough*)
I've already given up that fight. I used to think time machines were fictitious, but clearly *somebody* has invented one and is seriously screwing with our timeline, it's now the 90's in 2015 and contentless splash pages are all the rage. Only, instead of Flash or Java like in the real 90's, it's now CSS and HTML5 canvas. I don't know where all the lessons learned in the 90's went -- y'know, all those webpage design tutorials advising against contentless splash pages and recommending delivering oh, y'know, actual content? And sane navigation? -- but clearly the guy with the time machine has seriously screwed things up and nobody remembers the past to learn from its mistakes. Except users, whose memories were left intact so that they'll suffer for it needlessly. Sigh...
 But yea, that's the thing I don't get about the JS proponents: The
 argument always goes back to "It allows sites to be more dynamic!"[1]
 Umm, ok, and that's a good thing why exactly? They never seem to have
 a real reason of course, it's just taken for granted that "more
 dynamic" is unquestionably better, because it just is, and because we
 can. Oh yea, and call something "passe" because that'll REALLY prove
 some sort of worthwhile point.
It's just like how in the bad ole days, MS would label something "smart" because it sells better that way, yet everytime people hear MS say "smart" they go on the alert for something really dumb. Or "active" (aka "public arbitrary code execution service"), "dynamic" (aka "<marquee> repackaged in a less offensive name"), or any of those overused, beaten-to-death adjectives that have been bleached of all traces of actual meaning.
 [1] Then they also like tossing around the meaningless buzzword of
 "richer experience", thus proving they're only regurgitating
 groupthink and haven't actually thought through much of anything.
Yep, caveman-style "point-n-grunt" is obviously "richer experience" because it's "more intuitive" and therefore points the way to the future, whereas an actual HCI language like a CLI is "passť" because it actually requires thought and constructing grammatical sentences to represent complex ideas rather than monosyllabic grunts for "me want, me no wait, give now". Ah, the signs of progress! :-P And TBH, I also despise the word "content"... because it makes it sound as if there's anything else that matters. Back in the day, the whole point of going online was to get what people nowadays call "content", or more accurately, "information". The 'net back then *was* primarily just "content". Nowadays, however, "content" is a rare commodity, a mere tool to be hogged, controlled, and exploited to lure hapless netizens to poorly-designed sites and keep them there so that they can suffer needlessly by being force-fed eye-candy, pointless animations, and lately, the ever more trendy Empty Space. Keep those 0x20's coming, Bob! Fight the good fight! ^W^W^W^W^W^WI mean, those U+00A0's... T -- People say I'm indecisive, but I'm not sure about that. -- YHL, CONLANG
Feb 26 2015
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 02/27/2015 02:17 AM, H. S. Teoh via Digitalmars-d wrote:
 but in the webdev world, sometimes it's
 all about unreasonable deadlines and shipping it as fast as possible.
Well, that's not just webdev, that's true in just about any commercial software development. "Hey, the sales guys just sold (nonexistent) feature X and promised it by (absurd) time Y, so go do it."
 When Opera ditched Presto, I died a little inside. Back in the day,
 Presto was the only serious alternative to the other major offerings (I
 even introduced Opera to my non-techie cousin and she liked it!), and
 was the only one that offered the level of configurability that I liked.
 In the early days it was also slim and fast, though it started bloating
 up toward the final days.  But then Opera died and went the way of
 Chrome and now we're stuck with the IMO inferior choices.
Yea, choice is good. Can't say I was surprised by what happened to opera though. I was more surprised (impressed) that a paid web browser managed to stay afloat for as long as it did, in the face of free browsers packaged with every OS.
 And "content" does NOT mean "A barely-meaningful slogan or two and a
 vaguely related image tossed onto a mostly-blank page. Scroll down to
 get a few more slogans and clipart." (*cough* mobile-first design
 *cough*)
I've already given up that fight. I used to think time machines were fictitious, but clearly *somebody* has invented one and is seriously screwing with our timeline, it's now the 90's in 2015 and contentless splash pages are all the rage. Only, instead of Flash or Java like in the real 90's, it's now CSS and HTML5 canvas. I don't know where all the lessons learned in the 90's went -- y'know, all those webpage design tutorials advising against contentless splash pages and recommending delivering oh, y'know, actual content? And sane navigation? -- but clearly the guy with the time machine has seriously screwed things up and nobody remembers the past to learn from its mistakes. Except users, whose memories were left intact so that they'll suffer for it needlessly. Sigh...
Hah! :) You're right of course. Another part of the time warp: Remember how developers used to actually *care* about from-click-to-fully-rendered page loading times? My how I miss that. My library's (off-the-shelf) web inventory system, when viewed on my phone, takes about a full minute to respond to clicks (erm, "taps") - even just on ordinary form fields. 'Course, that's an extreme example, but more generally, devs don't pay one bit of attention to page loading times. The theory is that AJAX's partial-page loading speeds things up because, well, you decrease the page download size by half of a kilobyte, and that's automagically faster than downloading a partial page, downloading a JS script, executing the JS script which then performs one of more AJAX requests to download other parts of the page separately, and then the browser finished piecing it together. Yea, brilliant "optimization". Sites loaded and performed faster back when I was on 56k. No exaggeration. And forward/back/bookmarking *always* worked correctly. Not too long ago, when discussing page load times, I actually had one web developer try to tell me that none of time spent executing onLoad JS and such actually counts because page loading is different from onLoad processing. I'm amazed that anyone could convince themselves that technical distinction would actually matter to the user. But I'm convinced the time warp extends back to the 80's (or more). Remember when content used to be inseparably tied to the specific application it was created with? Then we got standardized data formats and interoperability. It was an ENORMOUS improvement. And now that's nearly gone. I can install any of a hundred different video players, music players and image viewers. But they're all nearly useless because (without hacking) YouTube videos only run on YouTube's player, NetFlix videos are only viewable on NetFlix's player, Spotify is only playable on Spotify's player, Flicker images are only viewable through Flicker, etc., and they all actively PROTECT their lack of interoperability. This allegedly "modern" shit has sent us straight back to the computing stone age before there was such a thing as widespread interoperability. But the extra bitch of it is: All these wonderful B&D services are BUILT ON and RELY ON the interoperable stuff (like mpeg4, SQL DBs, etc) as their base! They couldn't realistically EXIST without taking advantage of interoperability!
 And TBH, I also despise the word "content"... because it makes it sound
 as if there's anything else that matters. Back in the day, the whole
 point of going online was to get what people nowadays call "content", or
 more accurately, "information". The 'net back then *was* primarily just
 "content". Nowadays, however, "content" is a rare commodity, a mere tool
 to be hogged, controlled, and exploited to lure hapless netizens to
Yea. Like how there used to be article titles, but now links to articles will be truncated, making it look like they just ran out of space to fit the whole title. But the fact that it happens on literally *every* link, and that there obviously *is* enough space had they simply choosen to use it, proves it's a completely deliberate tactic to feign innocence while attempting to fool people into a click-thru to another ad-filled page because "Huh? Wait, what's the rest of it? 'Masquerada's gay characters are defined by...' By WHAT?!? Guess they couldn't fit something a short as a title, but I must know! I must click and find out!!" (ie, See the "See also" links at the bottom of every post on Joystiq or Engadget. It's every freaking link on... (see what I did there?))
 poorly-designed sites and keep them there so that they can suffer
 needlessly by being force-fed eye-candy, pointless animations, and
 lately, the ever more trendy Empty Space. Keep those 0x20's coming, Bob!
 Fight the good fight! ^W^W^W^W^W^WI mean, those U+00A0's...
Heh :)
Feb 27 2015
parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, Feb 27, 2015 at 01:53:10PM -0500, Nick Sabalausky via Digitalmars-d
wrote:
 On 02/27/2015 02:17 AM, H. S. Teoh via Digitalmars-d wrote:
but in the webdev world, sometimes it's all about unreasonable
deadlines and shipping it as fast as possible.
Well, that's not just webdev, that's true in just about any commercial software development. "Hey, the sales guys just sold (nonexistent) feature X and promised it by (absurd) time Y, so go do it."
Point.
When Opera ditched Presto, I died a little inside. Back in the day,
Presto was the only serious alternative to the other major offerings
(I even introduced Opera to my non-techie cousin and she liked it!),
and was the only one that offered the level of configurability that I
liked.  In the early days it was also slim and fast, though it
started bloating up toward the final days.  But then Opera died and
went the way of Chrome and now we're stuck with the IMO inferior
choices.
Yea, choice is good. Can't say I was surprised by what happened to opera though. I was more surprised (impressed) that a paid web browser managed to stay afloat for as long as it did, in the face of free browsers packaged with every OS.
Well, it was only paid for the first few years, and thereafter it became free (as in gratis). The desktop version, that is. IIRC they were trying to make their income by selling the mobile version on handhelds. They might have had prebundling deals with some manufacturers, I'm not 100% sure. [...]
 Another part of the time warp: Remember how developers used to
 actually *care* about from-click-to-fully-rendered page loading times?
 My how I miss that.
Yeah!!! Those were the glory days of Opera, that sported some of the fastest click-to-fully-rendered times. The original Presto engine was super lightweight too, compared to the lard-laden monstrosity that was Mozilla. *And* it was one of the most standards-compliant. (To the point MSIE fanboys were complaining that their "pixel-perfect" websites weren't rendering "correctly" in Opera. It was *too* standards-compliant!!)
 My library's (off-the-shelf) web inventory system, when viewed on my
 phone, takes about a full minute to respond to clicks (erm, "taps") -
 even just on ordinary form fields. 'Course, that's an extreme example,
 but more generally, devs don't pay one bit of attention to page
 loading times. The theory is that AJAX's partial-page loading speeds
 things up because, well, you decrease the page download size by half
 of a kilobyte, and that's automagically faster than downloading a
 partial page, downloading a JS script, executing the JS script which
 then performs one of more AJAX requests to download other parts of the
 page separately, and then the browser finished piecing it together.
 Yea, brilliant "optimization". Sites loaded and performed faster back
 when I was on 56k. No exaggeration. And forward/back/bookmarking
 *always* worked correctly.
Yeah, nowadays there's an alarming rise of websites that rely on JS-rendered controls that *already can be represented in HTML*. They don't work with NoScript, they are slow because it's (1) JS and (2) requires several AJAX roundtrips, *and* they are non-bookmarkable and break well-established browser navigation functions. All while *exactly the same thing* done in pure HTML works perfectly fine with NoScript, loads superfast because they're part of the page so when the page is downloaded they're all ready to go without needing additional JS interpretation time (spent in concatenating HTML snippets that could've been written into the page!) or AJAX roundtrips, and they integrate seamlessly into standard browser navigation functions. But they're not cool, because this isn't how people do things these days, and therefore they're passť and ought to be replaced with something inferior. This, we call "progress". Yup. Makes perfect sense to me! :-P
 Not too long ago, when discussing page load times, I actually had one
 web developer try to tell me that none of time spent executing onLoad
 JS and such actually counts because page loading is different from
 onLoad processing. I'm amazed that anyone could convince themselves
 that technical distinction would actually matter to the user.
Wow, that's really ... wow. I'm speechless. I blame it all on that time machine!! :-P
 But I'm convinced the time warp extends back to the 80's (or more).
 Remember when content used to be inseparably tied to the specific
 application it was created with? Then we got standardized data formats
 and interoperability. It was an ENORMOUS improvement. And now that's
 nearly gone. I can install any of a hundred different video players,
 music players and image viewers. But they're all nearly useless
 because (without hacking) YouTube videos only run on YouTube's player,
 NetFlix videos are only viewable on NetFlix's player, Spotify is only
 playable on Spotify's player, Flicker images are only viewable through
 Flicker, etc., and they all actively PROTECT their lack of
 interoperability. This allegedly "modern" shit has sent us straight
 back to the computing stone age before there was such a thing as
 widespread interoperability. But the extra bitch of it is: All these
 wonderful B&D services are BUILT ON and RELY ON the interoperable
 stuff (like mpeg4, SQL DBs, etc) as their base! They couldn't
 realistically EXIST without taking advantage of interoperability!
Yeah, that's the 2015 version of Embrace, Extend, Exterminate... :-P [...]
Nowadays, however, "content" is a rare commodity, a mere tool to be
hogged, controlled, and exploited to lure hapless netizens to
Yea. Like how there used to be article titles, but now links to articles will be truncated, making it look like they just ran out of space to fit the whole title. But the fact that it happens on literally *every* link, and that there obviously *is* enough space had they simply choosen to use it, proves it's a completely deliberate tactic to feign innocence while attempting to fool people into a click-thru to another ad-filled page because "Huh? Wait, what's the rest of it? 'Masquerada's gay characters are defined by...' By WHAT?!? Guess they couldn't fit something a short as a title, but I must know! I must click and find out!!" (ie, See the "See also" links at the bottom of every post on Joystiq or Engadget. It's every freaking link on... (see what I did there?))
[...] Obligatory quote: It's amazing how careful choice of punctuation can leave you hanging: T -- There is no gravity. The earth sucks.
Feb 27 2015