×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
So I still wonder, does the use of these clients make something NOT an
HTML5 solution?
A browser-based "client" is a generic utility, which could have implemented
some HTML 5 elements, and thus be labeled as an "HTML 5 solution".
If something results in presented pages that abide by HTML5 principles,
seems to me it's an HTML5 app - or maybe I should say, it "uses HTML5
principles" - was that the distinction you were making?
I don't think "principles" applies to HTML 5 , which is a bundle of HTML
elements and DOM objects. But I think I get your drift. You appear to be
alluding to the idea of extending a display-file interface to include
things like audio, video, maps, etc. which a typical HTML 5 interface might
support.
The real question is not a matter of labels and semantics, but how
effective the "client" may be at improving the user experience, or
alternatively degrading it. There are trade-offs. Additional overhead
degrades the user experience, while new types of visual components may
enhance it.
Screen scrapers, OA handlers, and "clients" which support the display file
paradigm are attractive for implementing a GUI interface quickly. But they
have constraints and performance concerns which would be better handled by
implementing a different paradigm - that is to create HTML 5 applications
as opposed to using a client designed to extend the display file paradigm.
midrange.com
