[jsr-314-open] JavaScript disabled support [Was: Outcome of JSFDays discussions]

[Martin Marinschek]

Hi Jeremy,

> We intentionally did not implement a smoother transition in
> the Spring Faces demo app because we wanted it to be clear what is
> happening when describing the progressive enhancement techniques to
> our community.

Well, if done in the body onload-callback, it should definitely not
hinder the visual appearance of the page.

> I am generally not in favor of baking either approach directly into
> the JSF APIs (though note that when using progressive enhancement,
> there is usually no need to do so in the first place).

I do see that if we only follow progressive enhancement, there is not
even the need for a boolean state variable which indicates JavaScript
is enabled or not.

However, I am not sure that for JSF this will fly. Two examples which
I would see as problematic:

1) Let's look at the simple case of the commandLinks: the problem here
is that links and buttons are no one-by-one replacement.

First, a link can have params, a button not. How do you handle this
with JavaScript only? Indeed, you will need to have different
rendering on the server to get this working - and a different handling
of the decoding. As the different handling of the decoding implies a
not too small performance overhead, I would really rather enable this
for 2% of the user-base, and not for everyone.

Second, a link can have free text and image combinations as children,
a (submit) button not (and buttons are not an option, as we all know).
So no approach in rendering a JSF commandLink as an input type=submit
will be perfect - and I don't see how such a link can be rendered into
valid HTML so that it will work with progressive enhancement (I
believe the only choice you have is to render different markup on the
server, and even then, it will not be perfect).

2) let's look at a more complex example: cs-JSF provides a split-table
for users of the component library. This split-table will (in the very
near future) be horizontally and vertically scrollabe, with fixed row
and column headers - something developers of highly dynamic intranet
web-applications do obviously expect from a component library.

What do we do in this case? To support the JavaScript in the browser,
we really have to render the table differently on the server: we
render not one table, but several tables. When JavaScript is switched
off, only one table should be rendered, and the horizontal and
vertical splitting would just not work. It gives me headaches to think
about the solution for this with progressive enhancement.

To sum it up, while I do think that progressive enhancement is the way
to go for internet facing applications which need to cater for a
heterogenous user base, I do think that with JSF, we will definitely
need the method of graceful degradation as well - at least from time
to time. And I do believe that without a proper solution for the two
issues with the command-link I highlighted above we will (sadly) need
graceful degradation for the command-link as well - but I would be
very, very happy if you could prove me wrong, so please do ;)

regards,

Martin







> I would love
> to see a progressive enhancement approach taken in the basic default
> components (most notably commandLink), but I'm not sure that
> necessarily belongs in the spec either as it is more of an
> implementation detail.

ok, agreed.

regards,

Martin