On Tue, 25 Sep 2012 23:00:41 -0700 "H. S. Teoh" <[email protected]> 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 :)
