log_e.hixie.ch

2004-06-01 01:12 UTC Spring 2004 Travelog: Part 7 (Notes for the Workshop)

I've been reading through some of the position papers putting together some notes for the workshop tomorrow.

Applications and documents are distinct

Why are they distinct? Microsoft Word documents can be used as applications. Interactive encyclopedia multimedia applications can be viewed as documents. Spreadsheets have long been both simultaneously. Help systems now are able to interact with the user and control other applications to help them along, but are clearly still documentation.

In fact I would posit that users do not really understand the difference between "applications" and "documents" at this stage, and I would argue that they need not.

We need a virtual machine that is defined using declarative mark-up, rather than any particular language

How much is in the meta-language? Would you describe SVG in this language? Would you describe CSS in this language? XPath? XML Schema? XML itself? DOM?

Would this be able to describe XHTML2? XForms? What about XForms' custom XPath functions?

How is this better than XBL?

It also seems that this would encourage a much wider range of languages to be delivered over the Web, breaking the principle that the number of Web formats should be limited, which is important for accessibility.

Presently, three incompatible forms specs (Adobe eForms, Microsoft's Infopath, W3C's XForms) are out in public view, yet none are supported by assistive technology

What about HTML4 forms?

Scripting is bad for accessibility

It is not scripting that is inherently bad for accessibility, it is device-specific APIs that are bad for accessibility. Any technology that makes device-specific solutions easier than device-independent ones will result in poor accessibility, as authors use the simplest solutions.

With this in mind, the best solution might just be to redefine parts of the existing scripting APIs to be device independent. For example, redefine onclick to trigger whenever an element is activated, not just when it is clicked.

We need profiles for mobile devices

If desktop and mobile units have different profiles, then mobile units will not be able to view all the content aimed at desktops (as most content is). It seems that in fact device independence would be far better for mobile users than device-specific profiles.

SVG is the answer

SVG (or rather a drastically simplified version) is a possible solution for the vector graphics requirements of an overall Web Applications technology.

However, it would in my opinion be a bad solution for the core technology. SVG is poor in terms of accessibility and semantics. For example, how do you mark a part of an SVG application as an ordered list? As a paragraph or header? As a dialog box or tabbing control?

SVG is also much less suited for styling. For example, it is not possible, with SVG, to do the radical changes in appearance as seen in the CSS Zen Garden. The ability to do this (without changing the markup) is an important part of the Web.

XForms is the answer

XForms is not backwards compatible.

I'll probably be making some of these points during the questions part of the other presentations.

The more I read the position papers that are going to be presented, the more I wonder at exactly what is going to come out of this workshop.