[whatwg] [web-apps] Some comments

[Matthew Raymond]

Olav Junker Kjær wrote:

>> Furthermore, all our "gracefully degradation" solutions so far have 
>> not required CSS.
> 
> I think the requirements for backwards compatibility of WAML should be 
> different that for WF2. With WF2 it makes sense to strive for graceful 
> degradation, since it is possible to implement most of the features 
> server-side.

    Untrue. For instance, you can't implement a date picker server-side. 
What WF2 markup does is to degrade to something that's reasonably usable 
and doesn't make it impossible to fill in or submit the form. It's true 
that some features can be implemented server-side for legacy support, 
but that doesn't apply to all WF2 markup.

> For WAML, however, I don't think graceful degradation as far as support 
> for browsers without CSS or script makes sense. As I understand the 
> spec, WAML is intended for complex applications with menus,

    Which can be implemented as a list with links or buttons.

> dialog boxes,

    I'm not convinced that dialog markup and app markup should be mixed, 
personally.

> complex controls,

    It would depend on the control. Tabs could degrade into <fieldset> 
or <div> elements. A tree could degrade into a <select>.

> lots off script,

    Obviously, unsupported Javascript objects can't degrade, but I think 
the only ones defined so far in WA1 are those that already exist and are 
widely used by multiple browsers.

> two-way communication with the server in the background and so on.

    This would probably be accomplished via scripting.

 > There is no way, that this kind of
> application will degrade gracefully on browser which doesn't support CSS 
> or script.

    That would depend on the feature. I think we owe it to users that 
don't have access to a UA with CSS or scripting enabled to create markup 
that degrades to the fewest standards whenever possible.

> Even if new elements were designed so that they wont show up 
> in those older browsers, the app would still be completely non-functional.

    The idea isn't to prevent webmasters from creating markup that 
doesn't degrade gracefully. The idea is to allow webmasters to create 
markup that degrades gracefully but still had the new functionality in 
compliant browsers. If the webmaster wants to create a WA1-only

> The position paper says:
> "Basic Web application features should be implementable using behaviors, 
> scripting, and style sheets in IE6 today so that authors have a clear 
> migration path. "
> I think this is a resonable requirement, however its a far cry from 
> requiring that web applications should degrade gracefully in Netscape 2 
> with scripting turned off.

    The point is not forced graceful degradation. The point is to allow 
the possibility for degradation on all user agents.

> If course you could implement a pure HTML version of the webapp that is 
> compatible with old browsers, but that version will likely have a very 
> different UI and flow. You won't implementet it *in the same page* as a 
> WAML-app. So I suggest non-graceful degradation for browsers that don't 
> support WAML: redirect to an alternative page.

    What, then, makes using WAML any different from using XUL + HTML4? 
If  WAML requires a compliant browser simply to be used, why even bother 
developing it when you can use XUL 1.0 right now? If you're going to 
throw graceful degradation out the window, better to create a 
standardized subset of XUL, a language which has already seen practical 
use in tandem with CSS and which supports just about any widget you 
might need. It should be noted, however, that this would be beyond the 
scope of the WHAT WG's charter.