On Mon, 05 Feb 2007 16:18:28 -0700, Robert Koberg <rob(_at_)koberg(_dot_)com>
I have been spending a good deal of time in the browser world and wonder
if this is the best place for MS to place their bet.
Oh, I don't think they're placing their bet on the browser, and instead
covering all of their bases.
I mean I see a very small amount of interest in client side XSL (even
though I use it alot).
Agreed, though I do believe that has more to do with the previous lack of
cross-browser support than it does with actual interest. When Apple first
introduced support in Jan. 2005 for Safari, and Opera then followed up in
October 2005 with their initial XSLT support, the lack of cross-browser
support is no longer a concern.
Of course, tools have every bit as much to do with this as anything else.
The more tools that provide default support for client-side XSLT, the more
use it would get, though that's obviously nothing profound -- This is true
in pretty much all cases for technology deployment > Go with what the
tools support by default.
What I am seeing is a bunch of ajax toolkits trying to find fast ways to
navigate HTML (not even XHTML) in the browser efficiently.
For what purpose? Navigating the internal tree structure, or for
something more along the lines of screen-scraping data? If the latter,
while I do recognize this to be a valid use-case, it's a brittle solution,
at best, and as we move forward into a more webfeed-oriented world, it
would seem to be that the use of proxies and/or JSON will become the
prefered method for traversing and rendering data on the client.
Firefox, Opera and Webkit are developing HTML XPath.
Cool! Wasn't aware of this...
Of course the 80% browser has the lead, but more and more browser devs
are going to really like HTML XPath. There will be XPath hacks created
for IE, but it will operate much more slooowly. As rich browser apps
become more prevalent people might notice the difference??
Well, for sure, though it seems to me that it really comes down to where
the data is coming from and how it's getting to the browser apps for
processing. If the world ahead of us is a world filled with
screen-scraping hacks to get data of interest, then HTML XPath becomes a
central focus to rendering data on the client. If it becomes more of a
proxied webfeed world, then it seems that the standard XML XPath tools
would be sufficient. Of course, even with web feeds, you still have HTML
embedded into the content payload, so from this perspective, HTML XPath is
Does anyone know if HTML XPath is in the works for IE?
Well, not specifically for IE, but as Oleg points out last Decemember
[http://www.tkachenko.com/blog/archives/000647.html], there's both the
HtmlAgilityPack and, of course, Chris Lovett's SgmlReader which has
been around for a good four+ years (if I am remembering correctly.) Both
of these *should* be usable inside of a WPF/e application, which would
provide some pretty powerful tools
M. David Peterson
http://mdavid.name | http://www.oreillynet.com/pub/au/2354
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>