Hi.
I would second both points. and add a third which is browser
compatibility/support.
A client side transform creates a situation that can also be created
using javascript DOM methods. The visual page you see in your browser
window is based on a "generated" dom for the page that's different from
the page source itself.
Google
--------------------------------
Google doesn't authoritatively address how it treats pages that behave
this way, I suspect because it can be a very complicated issue. I have
heard rumors that the google crawler is starting to execute some types
of javascript as it indexes and so certain kinds of generated content
may get indexed now when they previously had not.
Their guideline for webmasters suggests that looking at the page in lynx
is the best way to see what the crawler will do:
http://www.google.com/webmasters/guidelines.html
Accessibility
---------------------------------
As far as accessibility, it is true that JAWS reads the generated DOM as
displayed by IE. In that case the accessibility of the generated
content is what is important, as Didier pointed out.
However, if you have ever seriously looked into accessibility, you'll
know that it's not that simple. Satisfying the letter of the
accessibility regulations (section 508), to say nothing of actually
making a usable site, involves more than supporting blind users with
modern computers and the newest licensed version of the JAWs
screenreader.
For one thing, any content or functionality that depends on javascript
must be available in another form. There are numerous other hard
requirements, but to really get inside the requirements, it helps to
think about the users you plan to support. Here's a list of personas:
http://diveintoaccessibility.org/by_person.html
Browser Compatibility
---------------------------------
If you are supporting limited XSL functionality on either IE or firefox
you can probably do things client side. If you need to support complex
functionality on both IE and firefox, things will get expensive and time
consuming quite quickly. If you need to support other browser
platforms, you will probably hit a brick wall.
----------->N
.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:
||:.
Nathan Young
CDC Site Design & Development->Interface Development Team
A: ncy1717
E: natyoung(_at_)cisco(_dot_)com
-----Original Message-----
From: Neil Williams [mailto:linux(_at_)codehelp(_dot_)co(_dot_)uk]
Sent: Friday, March 03, 2006 8:04 AM
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
Subject: Re: [xsl] Is letting the browser transform XML to
XHTML using XSLT a good choice?
On Friday 03 March 2006 3:38 pm, Didier PH Martin wrote:
You said:
1) Google is based on the source code, and will ignore your
webpages.
I reply:
Are you sure of that? How do you know? Is this confirmed by
somebody else?
Put this into Google:
codehelp XML language syntax
The page you will get back has only a link to the HTML page.
There is an XML
page, using browser-side XSLT to convert to XHTML but Google
doesn't know
about that. If the HTML page had not been created for non-XML capable
browsers, Google would not know anything about it. For some
time, I had some
example pages that only existed in XML. Those pages simply
did not exist in
Google.
My way around this was to implement some PHP scripts that
output XML if the
browser claims to support it, HTML to others and WML to
mobiles. Google only
sees the HTML output.
You said:
2) Blind people's screen readers are based on the source
code, and will not
be able to use your webpages.
I reply:
Which browser are you referring to?
A good test browser is lynx. If your site isn't usable in
lynx, it will cause
difficulties for those with more limited browsers. It's not
nice to assume
that others have the ability or skill to use a "recommended"
browser. Build
for everyone, not just your friends.
Hence, if they are using
usual web browsers and Braille readers (like JAWS for
example), they will
have access to the text included in the web page.
In my case, the text of the XML alone can leave a visitor
stranded without
obvious means of navigation. XML isn't a web page, it's a
data document.
For instance, to get
access to the "title" or the "alt" attributes of an <img>
element. In other
words, they have access to the result of the transformation.
It's not always a good decision to expect everyone to have
such luxuries.
Braille reader. So, if people with this kind of disability you know,
actually use a browser accessing only the source of web
pages, then do them
a favor and tell them about more modern tools like, for
instance, the one I
mentioned.
IMHO it's better to provide content that visitors can use
without specialised
software.
http://www.anybrowser.org/campaign/
--
Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
--~------------------------------------------------------------------
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>
--~--
--~------------------------------------------------------------------
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>
--~--