Re: Deploying (accessible) XForms today?

Erik Bruchez ha scritto:
> 
>  Stefano Debenedetti wrote:
> 
>> It's not the same thing, XForms relevance is a declarative
>> (i.e. much more easily statically analyzed) way to have stuff
>> disappear from your page, while a "dynamic HTML DOM update changing
>> a CSS property" is by definition something that requires a dynamic
>> engine noticing that stuff may be subject to disappearing no earlier
>> than at run-time.
> 
> Your XForms engine follows a certain processing model. At a certain
> point, a Model Item Property (MIP) will change and be evaluated. Upon
> XForms refresh, the XForms engine will be in charge of reflecting the
> change of the MIP in the model to a change in the visible user
> interface controls. Some code, somewhere, will translate this
> declarative MIP into a piece of code saying "please, hide this stuff
> on screen".
> 
> This is exactly the same that will happen with the HTML DOM and CSS
> properties when a piece of Javascript code says "please, hide this
> stuff on screen".

It's not the same thing, you already know what controls bound to that MIP are subject to disappearing and what conditions in your data need to be satisfied for that to happen before you start executing the form. While if a random piece of CSS-controlling Javascript code says "please, make z-indexes of these two things be inverted" you still might have a hard time knowing what controls are going to be inside the containers the z-index applies to and what z-index do the containers have at any given moment and if they will be anyway covered by something else unless you are executing the script.

Like Victor says, semantics get lost and that matters.

Like John says, you're not willing to accept to solve a set of problems for some amount of money and then to have somebody translate them non-surjectively into another set of problems and ask you to solve them for the same amount of money.

It makes little difference if you are an implementor, a user or an author, it's about the amount of calculations and variables you need to keep track of for understanding how even the most simple functionality is acheived. And to reduce the probability and chances that other stakeholders get some detail differently than you, destroying interoperability.
 
> If I was to implement a smart (i.e. integrated with a browser,
> XForms-enabled or not) screen reader, I would probably use the hooks
> that IE and Firefox doubtless provide in their DOM to detect such
> visibility changes. 

This clearly restricts the availability of implementations to the ones having insight over what the "smart" guys would doubtlessly do, while this is actually not at all a thing the "smart" ones can predict themselves nor even guarranteeable to exist by itself in my experience, so much for third-party insights about it.

XForms was designed to make a wide range of implementations possible by keeping the requirements for implementors low and well-defined semantically AFAIK. Or at least by trying to, and still years after there is debate on very basic topics among the lead implementors, so much for how easy it is for casual authors, but most importantly so much for how easy it would be for everybody if it hadn't been designed in that way and it used random DOM+CSS instead of a small set of clearly spottable MIP.

>Whether the XForms engine tells me "hide this
> stuff" or whether I have to detect a CSS property change doesn't seem
> to make much of a difference.

Then again, why isn't XForms just allowing random dynamic setvalues all over the place? That would solve quite a lot of problems and introduced very little unfamiliar novelty, wouldn't it? According to what you say it would just be a matter of detecting all possible CSS (the cascade is hard enough to properly figure out by itself) and DOM changes and figuring out what that means at run-time, so where would the problem be?
 
> I think the above supports the opinion that "declarative" and
> "script-less" are primarily important for the developer, but not so
> much at the implementation level.

Ah there we wanted to end, OK I already said elsewhere I disagree on this one in many ways.

I'll just add I am amazed that one can not consider that one of the primary values of the web was and still is that the distinction between users and authors and system integrators and content providers and spec writers and spec implementors tends to be very blurred. Quite the opposite of the television mindset: push my button and stop wanting, server will take care of driving you how it wants.
 
>> I might be wrong or inaccurate here but I think this is why Hixie
>> once said XForms is just one step away from being yet another
>> scriping engine (can't find a link to that right now sorry) instead
>> of saying XForms is yet another scripting engine.
> 
>> Luckily steps missing still are more than one.
> 
> This is not an issue if you don't look at the world with the ideas
> that "scripting is evil" and therefore "XForms cannot be said to do
> scripting or we are in big trouble" ;-)

Again, the only folks mentioned in this thread that were supposed to have that mindset were law-and-WCAG-prone accessibility zealots and they made a pretty good job of keeping themselves away from the discussion so this is not the point.

I love JS. I love XForms too. I love that they are different. I am happy that XForms did not try to be JS, this is what I meant. Other people may have regretted that or even feared XForms had the goal of making JS disappear but this is not at all my view.

I have tried to teach non-programmers to write useful forms with HTML+JS and I had a very bad experience. I feel I would be happier teaching them to do the same things with XForms but until client-side implementations are ubiquitous or at least totally independent from the form I fear I would need to do both things, this is my position.

Adding to the fun that if I worked for PA I would need to explain to them why the cool new technology designed for accessibility I am proposing to them is generating something very similar to their old HTML site and has not even been tested for being WCAG compliant, which would be illegal where I live.

So "W3C is evil" would quite as appropriate as "scripting is evil" for describing my view of the world, yet this is obviously not at all what I think.

> We know that XForms has great features for the developer. It not only
> formalizes, using declarative markup, some user interface patterns
> that are often done with Javascript, but it also provides us with a
> declarative event and actions system, an XML-based data model, a
> powerful submission mechanism; etc.
> 
> But here is where Ian Hickson is right: at some point, you will write
> something like this:
> 
> <xf:action ev:event="xforms-value-changed">
>   <xf:setvalue ref="my/node/a">Hello</xf:setvalue>
>   <xf:send submission="my-submission"/>
>   <xf:setvalue ref="my/node/b" value="instance('some-instance')/node-b"/>
>   <xf:toggle case="ok-case"/>
> </xf:action>
> 
> The above clearly *is* scripting. It doesn't use Javascript as far as
> the developer is concerned, and it uses a level of semantics above
> what you usually do with Javascript, but it's imperative scripting
> nonetheless: it gives the XForms engine instructions that must be
> executed in a sequential order.

Yes, it's still after all these years not clear to me if I agree that this is imperative scripting in the sense JS-in-HTML is nor if I consider this a bug in XForms, fortunately not too harmful. Thanks for reminding me to think about it.

Still XForms implementors, authors and users statically know what parts of the page are subject to disappearing and what are not.
 
> Now I for one don't see anything wrong with that. The set of actions
> provided by XForms is simple, well thought-out, and the small number
> of them actually allows you to accomplish, by combination, an amazing
> number of tasks. Instead of learning hundreds or thousands of
> Javascript APIs (without talking about the language itself), you get
> by in a very large number of cases just with those few actions that
> XForms defines.

I fully agree 100%. I still don't understand why the benefit of not needing to learn "hundreds or thousands of Javascript APIs" (suggesting that they might be a moving target for a while still) would be an author-only benefit. Screen reader implementors and end-users in general might appreciate not needing to as well.
 
> This just shows that XForms is not just about declarative
> vs. imperative: it's also about ease of use for developers, and about
> removing the temptation to use confusing Javascript.

Yes it's also about keeping that temptation away from developers, but not only from them.
 
> It also shows that the declarative vs. imperative debate is not
> necessarily a key to discuss XForms accessibility.

Well, I thought it was clear that declarativeness importance to accessibility was exactly what the spec said, I take it that you agree with John that the spec is either wrong or badly phrased over this specific issue, I wonder if the WG is planning to  make it clearer or to correct it and why this hasn't been done before if that declarative=moreaccessible claim is so blatanly wrong. From your arguments it's not even clear if you consider that claim plainly wrong or just relevant to developers, it seems to me that you are using it as better suits you and it's not surprising either, considering your previously stated low interest in accessibility matters.
 
>> as stated everywhere from the XForms design goals to all over this
>> and many other threads about XForms vs. script, it's supposed to be
>> much easier for implementors (be them of screen readers or of visual
>> browsers) and for everybody else too (authors, users) to deal with
>> statically declared markup (be it HTML or XForms) rather than with
>> dynamically, imperatively and much more arbitrarily generated stuff,
>> which could be directly DOM nodes but that could well be other
>> script tags then generating other DOM nodes and so on recursively,
>> for example.
> 
> But in the end, there is one main thing that matters: the user
> interface changes, and that's done through DOM updates. Hook-up your
> screen reader at that level.

I even seem to remember that XForms was initially designed for not needing DOM in its internal workings? Has that requirement made it to nowadays or was it dismissed at some point? (the API for accessing the instance from outside of the engine doesn't count)

Anyway, I really can't see the point in defending that semantics defined by the spec should be meaningful only to some of the ones who might read it and in at the same time pretending it mandates something it is very careful about not mandating at all.

ciao
ste
 
> Best,
> 
> -Erik
>

Received on Wednesday, 10 May 2006 22:53:28 UTC