Html Dom Js Css

A "wiki-tized" name for HyperTextMarkupLanguage + DocumentObjectModel + JavaScript + CascadingStyleSheets. These four have become the cornerstone of "web programming" on the client-end of web applications, for good or bad, if not using proprietary tools, such as Flash or Active-X. HtmlDomJsCss is often used to more or less emulate "desktop" GUI's, which are UI conventions that existed before web browsers grew in prominence.
From: GuiMachineLanguage

Re: "Why not just add missing widgets to HTML 6.0 and continue using HtmlDomJsCss? Tell me: how long would it take for GuiMachineLanguage to become popular? How many revisions of HTML and advances to JavaScript libraries and DOM will likely come out during that time?"

There are two reasons I doubt extending HTML would work.

First, there are already HTML standards that browsers are choosing to ignore. More "paper standards" will not by themselves move browser makers. Second, Microsoft is unlikely to support a "rich GUI" standard, because it would cut into its desktop near-monopoly. Since IE is still the most common browser, if MS does not accept more non-proprietary GUI browser widgets in it, it will likely not become a de-facto standard. To get around this, the open-source industry may have to create a new kind of browser, perhaps dedicated to a desktop look-and-feel. Perhaps a plug-in to FireFox etc. may work, but many people won't want to download an entire browser just for the GUI kit. If it new GUI kit is a new browser which is smaller because it focuses on desktop-like GUI's and only desktop-like GUI's, it will be more palatable. Now, I cannot "prove" exactly what consumers will do; if I could I'd be a marketing millionaire. I can only describe consumer behavior as best I can based on similar past events and personal experience. If you disagree with my consumer- and MS-behavioral estimation, so be it. -t

I suspect your consumer- and MS-behavioral estimation involves more HandWaving speculation than research, observation, and analysis. I'm certainly not convinced by it. Anyhow, I'll ask: what do you know of the existing movements in this area? Mozilla Prism, XAML, XUL and Gecko, for example?

You are going to call anything that is not a double-blind $100 mil study "hand waving". Your request is unrealistic, Sir. And, it *is* based on observation of MS's behavior over the years.

I don't require $100 million double-blind studies. But I do consider your $0.02 opinions to be grossly insufficient. A minimal investment for a typical survey would be in the multi-$1000 range of valued time and effort, with $1000 being approximately 25 hours salary+overhead for a beginning IT professional.

You say your opinions are based on observation of MS's behavior. Which behaviors, specifically? and how up-to-date are they - i.e. MS has been trying to be less... evil... in the last several years. They've opened up many previously proprietary formats and protocols.

Most of it is window dressing (pun half-intended) so far.

Rough Melding

Further, things like adding an MDI interface may "break" existing web browser behaviors and/or conventions (such as pop-up blocking and tabbed browsing settings). It may be the case that simply adding "missing widgets" (WebBrowserMissingWidgetWorkArounds) cannot be done in a clean way. It may force changes or ugly compromises on existing browser behavior. Web interfaces and desktop interface just plain have a different "feel". Melding the two may not be smooth. Starting from scratch (such as GuiMachineLanguage) may be cleaner at this point because it could focus on desk-top-GUI-like behavior and only that without worrying about how to get along with existing web browser UI's.

HTML (well, HtmlDomJsCss) already does MDI. It's just called IFRAME.

And starting from scratch without giving a serious attempt is doubly a mistake: Your opinion is noted. Let's let them decide that.

I'm fine with that. You go ahead and implement your 'personal' approach, then convince other people to try it. It'll only take you a few years if you work hard at it and hire some help.

RE: You'll eventually want to have all the features from HTML, anyway. Giving it a serious try offers some significant lessons-learned for future attempts to combine the features, which abstractions and generalizations can be made, etc.

That may be the case, but why worry about the distant future?

Given that the context involves starting from scratch to produce something better than HtmlDomJsCss for applications (which is hardly a near-term proposal), it is already established that you are worrying about the distant future. But, since you asked, I'll turn your question back on you: why are you worrying about the distant future? Why not let the future settle itself?

Many companies use Java's GUI without worrying too much about it not being integrated with HTML. Thus, they've shown that they'll put up with the disconnection to get a better GUI.

RE: Unless you can say in no uncertain terms exactly why you can't simply add the features to HTML, you'll face extremely stiff resistance from the crowd you're hoping to motivate. [...]

I cannot provide a double-blind million-dollar mathematical study.

Who said you need one? All you really need is a good set of reasons. People will see through insubstantial words.

It may be possible, but it seems browsers are becoming too complicated and cluttered, and there are too many vendors involved now. It's easier for one vendor/product to make and manage the features of a GUI browser then getting 6-odd HTML browser vendors to keep up.

I'm curious from which perspective you believe that is a rational argument in your defense.

When I wear my "I'm an application service provider" hat, I see that someone needs to write and maintain the browser that can display my applications. Supposing even just one of the established WebBrowser vendors shouldered that task - Mozilla company and FireFox, say - I'd be assured of a widespread potential user-base, continuing support for the application language, and both portability and distribution of the browser platform. Would I be able to expect the same of TopsGuiMachineLanguageBrowser?

When I wear my "I'm an application user" hat, I'm somewhat picky. I want something that works on my OperatingSystem, with good regular 'security' updates. I want something that's available when I go to the Internet Cafe, that's readily available on many machines other than my own, that isn't likely to require installing new products. IwantaPony, but a FireFox will do. It has most of these properties. I might prefer a different browser, but I'm certainly better off with FireFox than with TopsFlyByNightGuiMachineLanguageBrowser.

When I wear my "I'm an application developer" hat, I want to develop applications that will work robustly, will work everywhere, will have acceptable or better performance, and will continue to work in the future without continual support on my part. For me, established standards maintained by some slow-moving monolith that concerns itself with compatibility, such as like WorldWideWebConsortium, are a really, really GoodThing. For me, a popular browsing platform with a good long-term prognosis on its lifetime is a GoodThing, and even if 5-odd HTML browser vendors have yet to implement the standard, the fact that they are expected to do so is also a GoodThing. I can't expect any of these from TopsWhatchamacallitBrowser.

When I wear my "I'm a competing browser developer" hat, I'm not going to bother supporting some new 'standard' until it is well and thoroughly developed. I really hate coding to a moving target. I also am not going to implement anything that isn't in demand, though if my browser is a 'WebBrowser' I'd probably treat a new version of HTML as a mandate. I may also support a plugin extensions mechanism for my browser, but the plugin will be somebody else's problem. EmbraceAndExtend pisses me off when I'm wearing this hat, so I don't really like pioneers, but if they're courteous enough to at least utilize a distinct <DOCTYPE> field I can tolerate them.

When I wear my "I'm the pioneering browser developer" hat, I see extending HtmlDomJsCss as favorable to many alternatives. It allows me to leverage the existing display framework, existing optimizations, existing DOM and networking protocols, etc.. The HTML has a <DOCTYPE> field, so I can use that to select the interpreter for the document. To keep app-developers happy, the guy wearing the standards developer hat can negotiate with me to promise to continue maintaining select 'stable' versions of the experimental language. Unless I can find some really good reasons for tossing HtmlDomJsCss and starting from scratch, I'd rather not do so. There is a lot more work that goes into a browser than that idealist with the standards developer hat is imagining.

When I wear my "I'm the new standards developer" hat, I want to create something that will be implemented and used. There are two basic choices for me here: (1) I start from scratch and try to develop something much better than the competition - enough to defeat incumbency and inertia. (2) I extend an existing standard and try to develop something that has a chance for long-term adoption by an established standards committee. If I go with option (1), I had better be able to say why my new standard is so much better. In fact, I had better be able to do so on stage, at conferences, in blogs, and on WikiWiki, and I had damn well better be convincing, because I need app-developers to join me despite my apparent lack of initial stability. I'm fighting inertia. A good implementation would help. If I go with (2), the burden is much smaller, the implementation is easier, the app-developers are happier, and the probability of success is much higher.

So, from each of six perspectives, I should, rather than start from scratch, choose to extend HtmlDomJsCss until it breaks. Well, that's unless I've got something that can overthrow skepticism and inertia both.

Now, putting BlackHat back on, I must ask you, TopMind, exactly why you think it relevant that all 6-odd WebBrowser developers would need to follow you from the start? Which engineering 'hat' were you wearing when you made your argument?

Based on passed behavior, I find it highly unlikely that MS would put in enough desktop-like features into IE to risk challenging Windows. The desktop is their bread-and-butter. At best, they'd do it half-ass, just enough to claim compliance, but it would be sluggish and buggy and take advantage of holes in the spec. This, we can count MS out, and they have roughly 70% of the market.

Besides, it's fairly easy to just release a "GUI Browser" as a stand-alone browser. You download and install it like any other application. If it's open-source, then the other browser makers may be able to incorporate it anyhow if it starts to catch on. -t
See Also: AjaxWebApplications, WebBrowserMissingWidgetWorkArounds, SeasideFramework, LimitsOfHtmlStack, CurlLanguage

{EditHint: perhaps Curl should be moved to a product list page}

I disagree. CurlLanguage is not just a product. (Technically, CurlIde? would be the 'product'.) Curl is a language that was specifically developed to address the polyglot problem of HtmlDomJsCss.

CategoryWebDesign, CategoryInternet, CategoryUserInterface


View edit of January 27, 2011 or FindPage with title or text search