Actually, my studies shown in the article linked to before prove that,
in fact, you can develop solutions faster when you single out each
client, take the base solution that works for a majority of the cases,
and then spend your time debugging each browser, instead of trying to
write one solution that fits all.
I have quite literally watched a project take 6 months longer than it
should have because they were dead set on making one code base work on
all browsers. If they had stood back and found the common ground the
could rely on, to then fine tune for each of the supporting browsers
(there are only four major browser engines (although in the case of
Mozilla there are several implementations -- but they still use the
same engine) - IE, Mozilla, Safari/Konqueror, and Opera 9.0 PR1/2, and
eventually the final - that support client side XSLT -- but this
constitutes well over 99% of all browsers in use. Of course there are
versions as well, but this in fact is one of the primary problems with
creating a one size fits all solutuion -- browser versions introduce
an entirely new layer of developer hello that i, generally speaking
the biggest problem in regards to time consumption.
Take a look at both my own article on this:
http://www.xsltblog.com/archives/2005/12/finally_someone_1.html
And more importantly, the newly "Browser Grading" guide published
study by Yahoo!: http://developer.yahoo.net/yui/articles/gbs/gbs.html
Coming from someone who has just spent the last year of his life
studying the intimate details of each and every browser on the market,
I have come to the absolute conclusion that the notion of developing a
one size fits all (or most) simply does not make sense any more. The
cost of attempting such efforts is so disproportionate to the cost of
fine tuning the standard base on a per browser basis, its not even
funny. In many cases (speaking at the corporate development level)
we're speaking in terms of several million dollars in additional cost,
and a range of between 3-9 extra months of development. I have
personally been able to develop individualized solutions that use a
common core code base, that is then tweaked for each browser, in less
than a weeks time on my own.
It just doesn't make sense any more. I will admit that this has been
a recent change (Safari gains XSLT support last January, Opera 9.0 PR1
on October 20th of this year) -- but recent or not, its still a
change, and a necessary one to maintain any sort of competitive
advantage.
In my mind, the day this all became a true reality was October 20th.
Opera has had significant political resistance to implementing an XSLT
solution within their browser. The fact that they now have I believe
speaks volumes in and of itself. Why go to that expense, and give up
the politics, if its not seen as crucial to their ongoing competitive
success?
On 3/4/06, Michael Kay <mike(_at_)saxonica(_dot_)com> wrote:
I am, today, very very surprised that this basic
functionality is still not
there, is it because:
a) Actual players have vested interests in a mainframe like
architecture?
b) People lack imagination with XSLT based technologies and
nobody thought
about this simple feature?
c) software producers are sleeping on the switch?
d) XSLT is unpopular
e) an asteroid felt on earth and anybody with the will to do it was
destroyed?
It's none of the above: it's because of costs and risks.
I think most of us can see that doing transformation on the client makes
sense in principle. But the problem is that you have much more control over
the server than you have over the client. As soon as you do things on the
client you have to cope with a bewildering variety of versions and variants,
and this is a nightmare for quality assurance and potentially for support
costs. Also, it means you have to put up with using highest-common-factor
technology: you can't use technologies like XSLT 2.0 until five years after
they emerge, despite the huge productivity gains they bring. (XForms and SVG
suffer from the same issues.)
So it's not an easy choice, and there's no single answer that's right for
every project.
The option of doing both - client side when possible and server side
otherwise - is one way forward, but it adds to your overall system
complexity and cost.
Michael Kay
http://www.saxonica.com/
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail:
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--
<M:D/>
M. David Peterson
http://www.xsltblog.com/