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.
As an Amazon Associate we earn from qualifying purchases.