[OT] Was: totally satisfied :D

[H. S. Teoh]

On Tue, Sep 25, 2012 at 10:29:54PM -0400, Nick Sabalausky wrote:
> 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.

OK it's probably my fault. I'm acquiring this bad habit recently of
responding before I read, and writing before I think. My bad.


> 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? Or was that just an
illustration?


> > 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.

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.


[...]
> > 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.

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

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.
However.  The *concepts* that it is based on are rock solid, and its
layout engine beats any WYSIAYG app hands down. You cannot beat LaTeX at
paragraph layout. It is optimized to prevent "running rivers" of spaces
when adjacent lines in a paragraph has inter-word spaces in the wrong
places -- the kind of stuff that browsers spew out every day until
hardly anybody notices how awful it looks anymore.

And math!! Once you've tasted the power of math layout in LaTeX, you'll
want to dash every other math layout format (esp. web-based ones)
against the rocks.  Presently no combination of browser hacks + MathML +
whatever other feeble attempt at math notation, etc., can beat LaTeX at
math formatting. You can write insanely complex math expressions *and*
have it all come out like it was designed by a professional math
typographer.  *And* you can do this just by a relatively simple
plaintext format that doesn't require clicking through 150 nested menus
and hand-picking symbols from a 20-page character map.  You can embed
math in your text or have it displayed separately, and in each instance
it comes out appropriately formatted. You have symbols that
automatically scale (like matrix parentheses that doesn't require stupid
manual and ugly resizing, tall brackets, hats and underscores that
stretch over multiple symbols, etc.). It's math notation heaven.

I mean, once I (ab)used math mode's amazing diacritic-placing ability to
invent a writing system for an artificial language that involves
multiple stacked accents over and under letters, and they always come
out right. Try that on a modern-day browser with UTF combining
diacritics and your eyes will bleed by the time you get to two accents
on a single letter, possibly before that. My LaTeX macros could handle
up to 5 diacritics above and below a single letter (*and* with some
accents side-by-side while being stacked with others) without losing its
composure. I mean, I could've formatted Vietnamese diacritics with math
mode alone, if there hadn't already been a Vietnamese port of LaTeX,
it's that powerful.

You've no idea how much I wish for the day when the web could even come
up to 50% of the formatting power that LaTeX provides. My eyes would
bleed so much less when I'm online.


[...]
> 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.


> 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.)


> 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*). The
markup for these monstrosities make no sense at all, for the simple
reason that these are *user interface widgets*, not document
fragments!!! So you end up with nonsense like the baroque dance of
(ab)using id's and what-not to link disparate elements of a radio button
set/select/whatever, <select>'s that have to be modified in real-time by
JS mostly by rewriting HTML with string fragments (unless you're crazy
enough to actually use native DOM operations for creating individual
elements, in which case you're probably beyond help), to mimic what a
*real* GUI does with a few lines of code that reads much more sensibly
than any JS + HTML string fragments nonsense ever will.

Then you have this nonsensical way of simulating popup dialogs by
appending <div>s to the end of the "document" and (ab)using CSS to make
it appear like a "real" dialog. Which is all fine and dandy until you
start scrolling the document, then all of a sudden a random subset of
the form elements in the dialog scrolls off the fake dialogue window
while the rest stay on screen -- because the developer forgot to apply
certain CSS attributes to said form elements so their positioning got
out of sync. (I've actually witnessed this first hand. This is no
exaggeration. You can argue this is just a careless bug, but my point
is, how did any of this convolution even make any sense in the first
place? This is a *document* format, not a windowing toolkit, for crying
out loud.)

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.


> 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).

Yeah the biggest beef I have with PDF (and LaTeX, for that matter) is
that you can't break out of the page paradigm. It's just a holdover from
the dead tree print days, which is quickly becoming obsolete in spite of
objections from aging book lovers. It doesn't make sense for electronic
documents.  This is one thing where HTML is actually better than other
generally-more-superior formats.

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.


T

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