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

[Raju Bitter]

Got it, thanks!

On Sep 2, 2009, at 3:32 PM, P T Withington wrote:

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