AFAIK, syntax was proposed for this purpose (with
-
Nick Sabalausky
(10/13)
Feb 26 2015
Hmm, just looked that up, but all I found on that was one page that
-
Nick Sabalausky
(18/31)
Feb 27 2015
Well, it appears seamless iframes are basically useless despite (from
-
Kagamin
(2/2)
Mar 06 2015
Just posted: http://jonrimmer.github.io/are-we-componentized-yet/
-
Nick Sabalausky
(15/17)
Mar 07 2015
No, what I was looking for was a way to do "Just drop these few lines of...
-
"Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
(6/13)
Mar 08 2015
No, I think they just want to make sure it is the right way to do
-
Nick Sabalausky
(9/21)
Mar 09 2015
Well, the problem with polyfill is that it defeats the whole point.
-
Dicebot
(5/11)
Mar 09 2015
Hate when websites do things like that. I will take JS any time
-
Kagamin
(4/8)
Mar 10 2015
I suppose, that's the point: you can't inject styles into foreign
Alix Pexton
(10/22)
Feb 26 2015
My understanding of the argument against doing this is that it would be
-
Nick Sabalausky
(18/23)
Feb 26 2015
Ehh, I'm not sure I buy that.
-
Adam D. Ruppe
(12/12)
Feb 26 2015
I don't think it is a security hole, but websites typically do
-
Nick Sabalausky
(14/26)
Feb 26 2015
Yea, that's kinda what I had in mind anyway. All these "embedded widget"...
-
Nick Sabalausky
(6/8)
Feb 26 2015
Yea. Speaking of, that mobile-directed "no zoom" css thing is seriously
-
H. S. Teoh via Digitalmars-d
(28/38)
Feb 26 2015
I find this trend extremely disturbing and exceptionally annoying. I
-
ketmar
(3/15)
Feb 26 2015
wow, another once-i-was-happy opera user! i'm still using opera 12,=20
-
Nick Sabalausky
(36/52)
Feb 26 2015
Yea. I'm a steadfast believer in the the design principle of "highly
-
H. S. Teoh via Digitalmars-d
(58/101)
Feb 26 2015
Making everything configurable is hard, though. Well, not *that* hard if
-
Nick Sabalausky
(58/94)
Feb 27 2015
Well, that's not just webdev, that's true in just about any commercial
(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?
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.
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.
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:
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)
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:
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?
Just posted: http://jonrimmer.github.io/are-we-componentized-yet/
Is it what you need?
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).
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
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.
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.
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.
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.
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
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".
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.
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.
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.
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.
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.=
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
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.
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
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 :)
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.
"Adam D. Ruppe" <destructionator gmail.com> 