[OT] Was: totally satisfied :D

[Nick Sabalausky]

On Tue, 25 Sep 2012 18:05:01 -0700
"H. S. Teoh" <hsteoh at quickfur.ath.cx> wrote:
> On Tue, Sep 25, 2012 at 08:19:00PM -0400, Nick Sabalausky wrote:
> > 
> > A "web browser control" is pretty common, AIUI. I know IE and WebKit
> > can be used as controls that you just plop into a window. Then you
> > have to add in all the bells and whistles like address bar,
> > bookmarking, etc., which all still adds up to a lot of extra work,
> > though.
> 
> No no, that's still part of the monolithic system. I find that kinda
> silly, actually. It's a system that lets the user to illogical things
> like put the "forward" button to the left of the "back" button
> followed by the "next" button with "rewind" interspersed between
> them. It gives you the illusion of control, but hides the fact that
> you still can't do things like rip out the entire dang UI and
> sticking a totally new one in its place.
> 

Hmm, one of us is still not understanding the other, maybe both.

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.

> 
> But on a more serious note, *all* programs should be written as though
> they're intended for a library. The frontend, be it main() or whatever
> the toolkit substitute for it is, should just be wrappers that call
> the library functions. The key idea behind this is automation and
> scripting, which is something sorely lacking in GUI-centric
> applications. To me, it is stupid that just because a program that
> solves problem P with algorithm X comes with a GUI, you're stuck with
> having to use the badly-designed GUI instead of just plugging into
> algorithm X directly. The whole point of the program is to solve
> problem P, so X should be in a library that you can call directly
> from an external program without having to jump through GUI hoops
> just to get at it.
> 

Totally agree.

In fact, I specifically tried to make sure, as much as
I could, that all the tools in my Goldie <http://semitwist.com/goldie>
system were basically just thin front-ends over a D API. (Except for
the JsonViewer thing because I didn't write that, I just hacked it up
with some extra features.) You can even check all the 'main.d' files in
the src repo <https://bitbucket.org/Abscissa/goldie/src/master/src>,
they're mostly just thin API wrappers.

I generally try to do that with all my tools. Definitely the way to go.


> I mean, this is just basic computer science. It's function
> composition. Something that most software of today seems to have
> forgotten.
> 

Good way of putting it.

> 
> [...]
> > > > > The result is that people revert to using table-based
> > > > > formatting and
> > > > 
> > > > Hey, I *like* table-based formatting :). Beats the hell out of
> > > > trying to kluge together sane layouts/flowing with CSS. And
> > > > nobody's ever going to convince me that HTML isn't the
> > > > presentation layer.
> > > 
> > > I say trash it all, tables, HTML, everything. Markdown is good
> > > enough for email. If you need more than that, go buy a real
> > > website and post it there instead of transmitting that crap over
> > > SMTP.
> > > 
> > 
> > Well, I just meant on the web, not email. Death to HTML emails!
> [...]
> 
> LOL... If I had my way, the web would be formatted with LaTeX (or
> equivalent) instead of that crappy HTML+CSS+JS which makes it so easy
> for clueless people to create webpages that make your eyes bleed.
> 

I've been meaning to look into latex.

> HTML was never intended to be used for the kinds of stuff people use
> it for these days,

Absolutely. +1

> and while CSS has some nice points, it's also
> insufficient to express some basic page layout concepts, which
> necessitates hacks to make things appear the way you want it to. Yes
> the hacks are clever, but a complete and consistent layout language
> shouldn't need hacks to express basic layout concepts. Like an
> explicit horizontal centering for containers that doesn't need half a
> dozen different shenanigans with auto margins and padding and
> text-align and what-not to accomplish. Or basic container alignment
> between two elements that aren't immediate siblings. Or a true fluid
> layout that doesn't require hard-coding to specific browser
> resolutions (like seriously... you'd have thought CSS should've
> obsoleted that, but no, it's still happening). Ad nauseum.
> 

Yup.

I do like HTML/CSS for documents, could be less verbose, could use
to not suck at diagrams and math formulas, 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.

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. A modern web browser is no different from having "applications" run
inside Acrobat Viewer or MS Word using PDF or DOC for i/o. It's
literally the same thing, just using a different format (but,
thankfully, with no page breaks or multi-column text, neither of
which make sense in electronic form).