Well canvas.capabilities is supposed to be our standardized way.
Granted, it is our own standard, but I don't know of any other.
The idea is that when you have a core facility that can't be supported
on all platforms, you add a capability for that, so that user programs
can test for the capability before trying to use it.
I think it just needs to be documented better.
On 2009-09-02, at 08:05, Raju Bitter wrote:
Right, I forgot about that!
But what I mean, is more a standardized way of doing that. There's
already a lot of complexity in OpenLaszlo for app deployment and
runtime-specific features - with much of that not well documented. A
standardized way of telling an app "I need features x,y and z in my
app, and please call a method if some of those features is not
supported."
The problem I see is that the knowledge about which browser
currently supports a certain feature requires a lot of research -
feels a bit like the early DHTML times. In the end it all comes down
to how easy it is to use new features in the DHTML runtime. If two
different versions of the an app (SWF and DHTML) are available, the
developer still has to figure out which browser should get the SWF
version, and which one the DHTML version.
But maybe you think there's no use case for that.
On Sep 2, 2009, at 12:43 PM, P T Withington wrote:
There is (perhaps not documented?) canvas.capabilities, which is
intended to cover this. It's initialized from
LzSprite.capabilities, which is initialized on a per-browser
basis. So, I think you just need to add to that.
On 2009-09-02, at 06:20, Raju Bitter wrote:
I got a good comment on my last blog post showing the CSS text-
shadow features.
http://openfuture.rajubitter.com/2009/08/25/openlaszlo-dhtml-css-3-demo-to-flash-or-not-to-flash-is-no-question/
A guy called Mike said: "Also, I’ve rarely encountered a cross-
platform issue with the Flash Player, which is one of the many
reasons that developers use it. The DHTML/CSS version above
doesn’t display for me in IE7 (I just get the spinning “Powered
by…”) but the Flash below it does."
I thought about that and came to the conclusion - that even for
demos showing the features of HTML 5 and newer CSS standards - I
don't want IE users to only see the spinning "Powered by...".
I added some code to the demo I built, and now - based on the
browser version - you'll see the following message if you access
the application with an old browser or IE:
<OpenLaszlo-CSS-BrowserCheckWarning.png>
That's a much more positive way of informing the user that his
current browser doesn't support the features required for this
app. But I'd be interested in your oppionion, how should we handle
unsupported browsers for DHTML demo apps, especially in future
releases of OpenLaszlo? I thought of a class where you can
register which capabilities your application needs for the full
user experience, with a rating for importance: some features could
be left out, and the application doesn't look as good. Some other
features might be required, and then the user will have to access
the app with a different browser.
For technically interested folks we could have an info button on
the warning message, giving more information about what feature is
not supported in the current browser.
Of course, all of this is not for consumer facing applications in
production, more for the OpenLaszlo demos and docs. In production,
I'd just check the browser and capabilities, and then deliver an
SWF version for the older browsers.
