Browsers (Was: A very basic blog about D)

[Nick Sabalausky]

On Sun, 14 Jul 2013 20:56:40 +0200
"Adam D. Ruppe" <destructionator at gmail.com> wrote:
> 
> But I, believe it or not, have a soft spot for IE6. Its interface
> was simple enough, it did separate processes for each site way
> before chrome "invented" it 

Interesting, either I never noticed that, or I had totally forgotten.
Very good point.

> "Program X has detected an
> instance already running" should be a crime.

Yea, I'm not a fan of that either. There have been some cases where I
felt it was sensible: sometimes there's a very resource-hungry program
that doesn't make much sense to have multiple copies running anyway.
For example, a lot of games. But normally it's just an asinine pain.

The one that bugs me most is actually Win7 itself. On XP, if I tell the
start menu or quick launch to open a file manager window to a
particular starting directory, then it just does so. Always. But Win7
is just "smart" enough to be stupid, so it'll *only* obey that command
*if* it first goes behind my back and detects that none of my existing
windows just happen to be showing my chosen "starting point" directory.
If there is one, it'll *refuse* my command to open a file manager
window and instead just switch to the one I already know damn well I
already have open (Because clearly, according to my computer, I
apparently don't know what the hell I'm doing).

Which means *every* time I want to open two or more file manager
windows, I have fool this stupid fucking piece of shit NannyOS into
doing so, instead of you know, just clicking the damn button however
many times I need.

God dammit I fucking *hate* post-XP Windows.

> 
> Important note though: change the security settings to disable
> scripts on non-trusted sites.

Ah, good tip. I hadn't thought of that. (For me, it was just "IE
doesn't have NoScript, therefore I shouldn't use IE for anything unless
I have to.")

>But that's not just an IE6 tip,
> that is even more necessary today than it was ten years ago...
> computers have gotten faster, javascript has gotten faster, but
> websites have gotten slower.

Yup. So depressingly true. And what's really bizarre about it is that a
LOT of that JS is specifically in the name of speeding up the site
("Because you don't have to redownload *all* 1k of HTML on every link!")

Are these people really *that* incapable of perceiving the difference
between a 5-10+ second "JS extravaganza page" load and a <= 1sec static
page load? You'd think that would clue them in to "Gee, maybe this shit
*isn't* actually making my page faster like people are telling me it
should."

And what's the extra bonus for that pessimization? Broken "back",
broken "forward", broken bookmarking, and broken link sharing.
Congratulations, you've just "best practiced" your website into a
slow-motion garbage heap.

> I find news websites especially, but also other ones like
> dlang.org, are completely unusable without JS blocked.
> dlang.org's stupid hypenation thing drags it to a crawl. News
> sites put up 1,000 bars for twitter and facebook and whatever
> else that slow them brutally.
> 
> Hey, webmasters, if you have content I actually like and want to
> share, I'll copy paste the link. I don't need those useless
> buttons.... and if they slow the loading so much, I'll just close
> the site, so you lose.
> 

Yup. And speaking of:
https://semitwist.com/articles/article/view/we-need-browsers-with-built-in-share-on-site-x

> But with js disabled it isn't so bad.
> 

Exactly. And so much for the "Eh, it'll be fast because it's already in
most user's caches anyway." Yea, well, even if so it still has to get
executed. JS's bottleneck was never bandwidth.

> > As an example of rendering issues, the lack of
> > "inline-block" can be annoying, and so is the incomplete
> 
> YES. inline-block makes css useful. I'm not even really
> exaggerating there, that's how important I think it is. floats
> are waaay too painful to deal with.
> 

Floats are good for what they were originally intended for (wrapping
text around an image) and for nothing else.

I've fumbled around with layouts that involved float, and I don't
think a single attempt ever made it into my local VCS commits, let
alone production.

> The moz-inline-stack thing doesn't quite work the same iirc, I
> remember trying it and finding it didn't make it a real block, so
> you couldn't center text or something like that inside it. But
> meh, FF2 is virtually dead so I just ignore it.
> 

While I do code for FF2, I've accepted that I'm probably doing it only
for my own sake. Just so I can do as much as I can without putting up
with a unified forward/back, browser skin, address bar with
unicorn-rainbow-vomit Fisher-Price-sized text, or all that UI
over-minimalism.

But layout tables solve any issues I have easily enough, and nothing
ever chokes on them, so I don't really find it to be any extra trouble. 

> 
> inline-block btw was in CSS 2.0.

That's what I thought, but then I couldn't find any source for that
info so I started second-guessing it. Good to hear it's not just my
imagination then :)

> But the standards committee was always biased toward Netscape,
> and Firefox was Netscape's successor so they inherited that bias.
> This is a kinda strong charge that I can't prove, but I think the
> case is pretty good: look at how many times IE did something
> clearly superior to Netscape/early Firefox, the box model, the
> mouse buttons that you mentioned, and there's more too.... but
> the standard always seemed to prefer the NS/FF way. And when FF
> didn't implement something, you could count on the standard to be
> revised some time later. It happened with CSS 2.0 -> CSS 2.1,
> conveniently dropping features FF never implemented (thus making
> them "standards compliant"), and recently happened again with
> display: run-in, which they said was unimplementable, but
> Microsoft managed to do it right years ago. Firefox never did,
> and instead of being lambasted for not following the standard,
> the standard just got revised again to agree with FF.
> 

Yea, the non-IE browsers always went off doing their own thing, too.
But IE's the one that gets condemned as "non-standard" just because web
standards are pretty much defined as "whatever big bad MS *isn't*
doing".

Not that MS doesn't deserve the "big bad" label, but standards need to
be a meritocracy - there's no room for politics. Unfortunately, the W3C
clearly hasn't been doing that consistently. Now I don't know, it may
not have anything to do with bias against MS, maybe MS just hadn't been
very active or very sensible in W3C proceedings, or whatever, but
whatever the reason, W3C hasn't been a case of "the motion with the
best merit wins".

> 
> > But whatever, even with most of those issues, layout tables 
> > easily solve like 95% of HTML/CSS problems anyway, and with 
> > zero non-imaginary downsides
> 
> 
> I can't agree with you there, I dislike layout tables and here's
> why: one week, the client says 3 columns are in. Next week, he
> changes his mind and wants it back to 2 columns. Not too hard
> with the css things. A lot of boring work with tables. Or "add a
> row there", not too hard when you can just throw it in with a
> clean html file, but very difficult to find the right place in a
> mess of nested tables.
> [...]
> With <table> is a pain. But with the css, you can change it form
> display: table-cell to display:block in the appropriate place and
> be done with it. (Now display: table still leaves some to be
> desired, I prefer inline-block when I can, but still it is a good
> step.)
> 

I do actually see your point there, and can relate to a certain extent
(particularly with "inline-block"). But my experience has been that
manually re-jiggering HTML (including layout tables), while imperfect,
has always been pretty minor and quick when compared to most of my
other tasks.

And those minor annoyances have been more than made up for by all the
times I've banged my head against the wall over some PITA HTML/CSS
problem, then decided "fuck this shit, I'm using tables" and wound up
with a working, ultra-compatible, (and often conceptually simpler!)
solution within minutes.

YMMV, I guess. And I'll admit I have been lucky lately with minimal
nitpickery from clients and armchair-expert designers.


> > In fact, I never even allow Chrome to touch my computers.
> 
> I wish I could, but one of my big clients uses it religiously so
> I need to have a copy every so often to track down the bugs he'll
> inevitably find.
> 

I use SRWare Iron in place of Chrome (as I said, it literally is
Chrome), but if you have to put up with Chrome's "bug of the day" junk
then yea I guess that wouldn't work. Although at that point I would
reach for VirtualBox. If I ever have to run the real Chrome, it's
getting its ass sandboxed.

> > Yea maybe. But I figure if someone's going to try to browse the 
> > web on a freaking *capacitive* touchscreen, of all things (and
> > such an orwellian one at that), then they can just be happy 
> > with whatever just happens to actually work.
> 
> 
> Aye, but again, what the bosses use, I have to use. And he went
> so far as to buy me one of those ipads so I wouldn't have any
> excuses to ignore it any more too :(
> 

Certainly true. I had a similar thing last year: A project I was
getting involved in needed to work on iOS (for very valid business
reasons that I do actually agree with), so the guy got me a loaner
iPhone that I pretty much ended up having to tote around for much of
the year. I don't miss that thing one bit.

> (On the bright side though, I do like watching sports on it.
> Almost completely useless for doing actual work with it,

Heh, I can't stand tiny TVs (I don't even like using portable game
systems). They do have some nice uses (Shazam is just as awesome as its
name is awful), but I've been spoiled enough by some of the best
aspects of the now-dead PalmOS that I can't help seeing them as
dumbed-down orwellian toy versions of what an internet-connected Palm
could have been. I just don't like the iOS/Android interfaces *at all*,
and the iOS lock-downs are just inexcusable.

> touchscreens are terrible, 

The capacitive ones are the worst. (And they're all capacitive now.)

And it really gets me how touchscreen devices are promoted with the
idealized concept of "touch" even though they *eliminate* tactile
sensation.


> > I do think iOS deserves some kudos for having the balls to 
> > finally kill off Flash
> 
> Blargh, I wish Flash was dead, but it keeps coming back up.
> There's the ogg vs mpeg format war that is a huge hassle that
> means now all my work sites are forced to write even more code:
> 
> <video>
> <source mp4> (most things)
> <source mp4 lower res> (the iphone refuses to play higher res)
> <source ogv> (firefox)
> <object> (flash fallback)
>    <embed /> (i think this is useless)
>      <a href="download"></a> (finally the only one that should be
> there IMO)
>     </object>
> </video>
> 

True...There was one point on a site I was doing where [strongly
against my normal design principles] we needed some pages with embedded
audio. I tossed in an <object> tag pointing to an mp3 and it worked
great on every browser I threw at it...except Chrome. Ugh.

The site already required Flash for some other stuff (things that JS
just wasn't up to, certainly not at the time), so not wanting to deal
with any browser-conditional stuff, I ended up playing the audio via a
trivial flash applet. "Ugh" again.

> 
> Blargh. And then "the ipad video UI doesn't match the Chrome
> which doesn't match the Firefox which doesn't match the Flash"
> 

Actually, I think that's preferable as long as the UI matches (or
rather, *is*) that of the user's associated video player program. One
of the things I loathe most about the modern web is how choice of
viewer application has been stolen from the end user and given to the
content provider instead. I still blame YouTube for kicking off that
awful trend.

Although if you're actually creating, for example, some sort of
multimedia thing where video is simply part of a bigger whole (Like the
old Phillips CD-I stuff), then that's a completely different matter and
UI then *does* belong under the control of the creator (aside from any
matters of matching the local device's look-and-feel).