[Laszlo-dev] Dealing with unsupported HTML/CSS features in DHTML

[P T Withington]

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.
>>
>
>