[OT] Was: totally satisfied :D

Nick Sabalausky SeeWebsiteToContactMe at semitwist.com
Wed Sep 26 02:19:16 PDT 2012


On Tue, 25 Sep 2012 23:00:41 -0700
"H. S. Teoh" <hsteoh at quickfur.ath.cx> wrote:
> On Tue, Sep 25, 2012 at 10:29:54PM -0400, Nick Sabalausky wrote:
> > With what I'm talking about, all of the back/forward/etc buttons and
> > everything are completely gone. Think Scintilla, but for HTML/CSS
> > instead of text.
> > 
> > Ie, imagine you make a trivial HTML page that's nothing but a purple
> > background and no content. Now load it in a web browser. The purple
> > part (and maybe the scroll bars?) is the *only* part that's
> > included. Anything else, forward, back, addr bar, etc., must be
> > *created* by you, the developer and made to call whatever API the
> > control exposes to do such things.
> > 
> > Or at least, that's my understanding anyway. Perhaps I'm mistaken.
> > 
> > The result does admittedly end up being another monolithic system
> > though, just with the same layout engine.
> 
> Wait, so you're using HTML to make a browser UI?

No...

> Or was that just an illustration?
> 

Let me try putting it a different way (Sorry if it sounds patronizing,
I'm not trying to be):

Most GUIs are made of common re-usable widgets, right? The "button"
widget, the "checkbox" or "radio box" widgets, the "menu bar" widget,
the "text box" widget, "image", "list", "grid", "treeview", etc. So
then you make a GUI by plopping those widgets into a window, adjusting
their exposed properties, and providing actions for stuff like
"onClick". Basic stuff, right?

So if I take a text-edit control and plop it onto a window, I haven't
recreated the entire GUI and functionality of Windows Notepad or Kate
or Gedit or Eclipse or whatever. It's just a text box. No menu bar, no
toolbar, no "save button", no "currently opened files list", no status
indicators, no nothing. Just a box you can type into. You have to add
those widgets in, and add code to make them cause the right things to
happen to the text box widget (or as a result of the text box widget).

But then there's fancier widgets, too. Like WebKit (used by Safari,
Arora, Chrome IIRC, and likely others), or a similar one from IE, and
maybe FF too, I dunno. These are "HTML/CSS Viewer" widgets: You give
them HTML/CSS and they show it and, I assume, give you an API for
accessing the DOM somehow. I imagine you can probably give them a URL
too. They may or may even do other stuff too, like offer an API for
"goToPreviousPage()". I'm sure it all varies from one to another, and I
honestly don't know how far any of them go because I haven't used them
personally. Although I *think* with WebKit it's up to you to wire up a
JS engine yourself (just as an example).

But what they *don't* do, AIUI, is provide any GUI *at all* for
anything besides the final rendered HTML/CSS. (Although I do have a
vague recollection that there *is* an IE widget you can use that *does*
give you all of that.) So...

...suppose you made a GUI program, gave it a window, and filled that
window with one of those HTML/CSS/Web widgets. It'll show *nothing*.
Blank page. So in code, you tell it to go here (Go ahead and visit this
link for real right now):

http://semitwist.com/blank-purple.html

(Or maybe your code just downloads that URL and hands the raw HTML to
the control. Or something.)

Then...Your program will be *nothing* but a big purple rectangle, maybe
with scrollbars, and whatever window-frame is added by your system's
window manager. That's it. The user won't even be able to type in a
URL or go forwards/back without you putting in code and widgets (or
keyboard accelerators, or whatever) to let them do that. The widget may
or may not have a simple "browserView.goBack();" that you can call, I
don't know, but even if it does then YOUR code has to actually bother
to call it.

Interestingly, there are add-ons for FireFox that let you use the IE
renderer instead of FF's renderer *in* one or more of your FF tabs.
There's even some obscure browser out there that lets you choose
between IE, FF and some other (WebKit?) for each of it's own tabs.
Might be called Trident or something like that, IIRC?

At least...that's my understanding of it all, having never actually
dealt with browser code myself. I apologize if I happen to be totally
wrong ;)

> 
> You're doing better than I am. :-P  I whine and groan about it, but
> then very often my own programs are monolithic monsters. Hopefully
> once I start having more D projects replace my C/C++ ones, I'll
> improve in this area. D does make it a lot easier to design software
> in this way, which is one of the reasons I like it so much in spite
> of the current implementation flaws.
> 

D is seriously so awesome. I had to go back to C++ for the iOS/Andorid
game I'm doing, and man do I miss D
<http://semitwist.com/articles/article/view/top-d-features-i-miss-in-c>.

I miss D whenever I do maintenance on my Haxe-based webapp (one of my
real-world projects). I miss D like crazy anytime I have to use any
language other than D. It's so totally spoiled me :)

> 
> And here's a quote for you:
> 
> 	Those who've learned LaTeX swear by it. Those who are learning
> 	LaTeX swear *at* it. -- Pete Bleackley
> 

I think I heard that once before. I do like it :)

> My own take on it is this: LaTeX itself is quite old, and its age is
> starting to show. There are many things about its implementation
> details that I don't quite like. Lack of native UTF support is one
> major flaw (though there are imperfect workarounds).  Also some
> holdovers from the bad old days of trying to squeeze out every last
> byte from something, causing a zoo of command names that you pretty
> much have to memorize.

Might be fun to make a front-end for it. Something that spits out raw
latex given a modernized equivalent.

> [...LaTeX rox stuff snipped...],

Sounds cool.

> [...]
> > I do like HTML/CSS for documents, could be less verbose, could use
> > to not suck at diagrams and math formulas,
> 
> Once you've tasted the power of math layout in LaTeX, you wouldn't
> want to go near HTML math formulas with a 20-foot sterilized
> asbestos-lined titanium pole. It's *that* bad by comparison.
> 

Even now I wouldn't even bother. I'd just use an image, or if not that,
then maybe try pre-baked MathML output. But you have convinced me to get
around to trying latex when I get a chance.

> 
> > and it has this linking problem
> > <http://semitwist.com/articles/article/view/html-fragment-linking-is-stupid-here-s-the-fix>,
> > but it generally gets the job done reasonably well...for
> > documents...ie, what it was *made* for.
> 
> I'm all for better ways of linking than the klunky baroque name= or
> id= dance, but one problem with overly-specific linking is, if the
> target page gets updated and stuff moves around, your link breaks.
> That's a bit too fragile for my tastes. (Though of course, one could
> argue that the same will happen if the id= gets deleted by the
> update, but at least if whatever it is you're linking to still
> exists, chances are the id= will stay, but unmarked elements can come
> and go at any time.)
> 

Yea, but at least it's something. And the "alternatives" feature
helps, too.

What might be a good complement to that would be a text-search
fragment. To go to the first instance of some short phrase. Again, not
perfect, but beats the hell out of "No 'id=' where you need one?
You're SOL!"

But in any case, the whole damn web is completely fluid anyway, so even
without the "id=" fragments that we *do* have, there's always still
links breaking. At least a broken fragment still goes to the right
page, instead of a 404 or "server not found" something.

> 
> > But it's *not*, by any means, a sane UI/general-presentation
> > description format (as it's increasingly being used as), nor was it
> > ever designed to be.
> 
> What never made any sense to me was the use of HTML for what amounts
> to a GUI (*cough*form elements*cough*JS/CSS popup dialogs*cough*).

*Exactly*

The "JS/CSS popup dialogs" (I call them "pop-ins") are probably the #1
thing that irritates me most on the web. Everything about it is wrong.
Not just the technical things you describe, but the whole user
experience even when it's *not* buggy. I mean, here we have a *popup*,
that *can't* be killed by popup blockers, *and* makes the page
underneath inaccessible! *And* it breaks the "back" button! Plus, on
top of all that, it's completely unnecessary 100% of the time and does
*nothing* to improve the user experience.

I had a *cough*fun experience with them recently, too:

I wanted to check the availability of some item at my local library
system, but their site insists on showing the availability info in one
of those "pop-ins". Ok, annoying normally, but I was out of the house
so I was doing this on the iPhone (which took forever due to the
barely-usable text-entry on the thing). So I finally get to what I
want, get to the "item availability" pop-in, and it's too big to fit on
the screen. Ok, to be expected, it *is* a phone. So I try to
scroll...and the pop-in *stays in place* as I scroll around the
faded-out page underneath. So I can't scroll the pop-in. So I try to
zoom out. Oh, it zooms out ok, but the part that was offscreen *stays*
offscreen, so that doesn't help either. Go landscape - that just makes
it worse because it everything scales up to keep the page width the
same, so I just loose vertical real estate.

Funny thing is, it works fine (ie without using pop-ins) when JS is
off. But I can't turn JS off in iPhone Safari.

So I don't know if it's an HTML/CSS/JS problem, a site problem, an
iPhone problem, or a combination of all, and honestly I don't even care
- it blows, and that's all that matters.

> [...]
> And using a (semi)transparent screen-filling <div> to simulate modal
> dialogs? Yeah it's clever. It also shows how stupid the whole
> enterprise is. That's not a "document" element at all. That's a
> windowing *system* that got transplanted into a *document* format.
> It's like implementing a flight simulator in an MS Word document.
> Very clever if you could pull it off, but also equally ludicrous.
> 

Exactly.

> 
> I'm on the fence about multi-column though. I find that an
> unfortunately large percentage of websites out there are overly wide,
> with text that stretch way past your eye's natural comfortable
> reading width, making reading said text a very tiring experience.
> OTOH if you just clip the width to a more natural width you have the
> problem that most screen these days are too lacking in the height
> department^W^W^W^W^W^W overly endowed in the width department, so you
> end up with large swaths of empty spaces on either side, which looks
> awful.  Standard support for multi-columns would be a big help here.
> (Preferably one that's decided by the *browser* instead of hard-coded
> by some silly HTML hack with tables or what-not.) I think CSS3 has
> (some) support for this.
> 

The problem with that is you're creating excess vertical scrolling.
Just to read linearly it's "scroll down, scroll up, scroll down", etc.
(Of course, that pain is hugely compounded when the multi-columns are
on page-based PDFs, like academic research papers.)

The root problem there is that the need for multi-column on the web is
artificially created by manufacturers and consumers who have
collectively decided that watching movies is by far the #1 most
important thing for anyone to ever be doing on a computer. Hence,
"decapitated fat midget" 16:9 screens for everyone! No matter how bad
it is for...just about everything *but* movies and certain games.
Which, I suspect, is also the main reason we can't have browsers
anymore with nice traditional UIs - because they have to be shoe-horned
into a movie-oriented half-screen.

Thank god they didn't standardize it all for those 1.85:1 films. Yet.

> If it breaks, you get to keep both pieces. -- Software disclaimer
> notice

Heh, that's awesome :)



More information about the Digitalmars-d mailing list