You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Donald Ball <ba...@webslingerZ.com> on 2000/10/19 05:38:23 UTC

[kinda OT] browser capabilities database

hi guys. we're getting ready to launch our new corporate site, served by
cocoon naturally, with both HTML and a DHTML skins. i've been tasked with
the tricky problem of choosing the optimal skin for each user. my initial
thought was to do client-side javascript detection, by testing to see if
either document.layers or document.all exist and setting a cookie - not a
perfect test, but a pretty good one. unfortunately, that approach only
works if users enter the site via the splash page with the javascript, and
if they allow me to set cookies.

my next thought was to check the browser's user agent string against a
capabilities database. unfortunately, i'm not aware of any such database
that's open and maintained. php has support for a browscap.ini file, but
they don't maintain it apparantly. you can download one sort of for free
from a company, cyscape, but it's many months old, incomplete, and had
some weird license restrictions. cyscape _does_, however have a javabean
component called browserhawk which can tell you all sorts of information
about a browser's capabilities, given an HttpServletRequest. pretty nifty,
works well with all of the browsers i've tried, but it's not open, and
it's not exactly cheap. (interestingly enough, it comes with an obfuscated
version of ibm's xml4j parser - hope they licensed it legitimately!)

i'm kind of torn. on the one hand, it's a great little component and it's
got a comprehensive database (much better than their free browscap.ini
file). on the other hand, it boggles my mind that there is no open browser
capabilities database out there. am i missing one, is there in fact
something good out there? if not, two questions:

1. would anyone be interested in helping start such a database and a set
of libraries to access it?

2. will it be fairly straightforward to use a browser capabilities library
(browserhawk or something else) to do flow control in the c2 sitemap?
(e.g. apply this stylesheet if the browser supports DHTML, otherwise apply
this one)

thanks. i'm looking forward to apachecon so i can get a sitemap/c2 brain
dump from those of you who've been working so hard on it.

- donald


Count siblings

Posted by Rob van der Zeijden <r....@tiscon.de>.
I want to count the number of siblings a element has in XSL.
How???

Re: [kinda OT] browser capabilities database

Posted by Stefano Mazzocchi <st...@apache.org>.
Donald Ball wrote:
> 
> hi guys. we're getting ready to launch our new corporate site, served by
> cocoon naturally, with both HTML and a DHTML skins. i've been tasked with
> the tricky problem of choosing the optimal skin for each user. my initial
> thought was to do client-side javascript detection, by testing to see if
> either document.layers or document.all exist and setting a cookie - not a
> perfect test, but a pretty good one. unfortunately, that approach only
> works if users enter the site via the splash page with the javascript, and
> if they allow me to set cookies.
> 
> my next thought was to check the browser's user agent string against a
> capabilities database. unfortunately, i'm not aware of any such database
> that's open and maintained. php has support for a browscap.ini file, but
> they don't maintain it apparantly. you can download one sort of for free
> from a company, cyscape, but it's many months old, incomplete, and had
> some weird license restrictions. cyscape _does_, however have a javabean
> component called browserhawk which can tell you all sorts of information
> about a browser's capabilities, given an HttpServletRequest. pretty nifty,
> works well with all of the browsers i've tried, but it's not open, and
> it's not exactly cheap. (interestingly enough, it comes with an obfuscated
> version of ibm's xml4j parser - hope they licensed it legitimately!)
> 
> i'm kind of torn. on the one hand, it's a great little component and it's
> got a comprehensive database (much better than their free browscap.ini
> file). on the other hand, it boggles my mind that there is no open browser
> capabilities database out there. am i missing one, is there in fact
> something good out there? if not, two questions:
> 
> 1. would anyone be interested in helping start such a database and a set
> of libraries to access it?

I won't have to time to help directly on this, but this is a great
idea... for sure we need such a tool and I know a couple of persons that
can tell you if a particular tag or javascript hack works on netscape
4.07 on macos rather than ie5.01 on win2k.
 
> 2. will it be fairly straightforward to use a browser capabilities library
> (browserhawk or something else) to do flow control in the c2 sitemap?

are you kidding? of course :)

> (e.g. apply this stylesheet if the browser supports DHTML, otherwise apply
> this one)

how about something like this 

 <select type="browser-lib">
  <when test="supports javascript 1.2">
   <transform src="dhtml-stylesheet.xsl"/>
  </when>
  <otherwise>
   <transform src="html-stylesheet.xsl"/>
  </otherwise>
 </select>

and in the future when CC/PP will be in place we could even do things
like

 <select type="browser-lib">
  <when test="screen greater than 800x600 and accepts SVG">
   <transform src="dhtml-stylesheet.xsl"/>
  </when>
  <otherwise>
   <transform src="html-stylesheet.xsl"/>
  </otherwise>
 </select>

> thanks. i'm looking forward to apachecon so i can get a sitemap/c2 brain
> dump from those of you who've been working so hard on it.

Yep, looking forward for that as well :)

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------



Re: [kinda OT] browser capabilities database

Posted by Ross Burton <ro...@lineone.net>.
On Wed, 18 Oct 2000, Donald Ball wrote:

[snip]

> my next thought was to check the browser's user agent string against a
> capabilities database. unfortunately, i'm not aware of any such database
> that's open and maintained. php has support for a browscap.ini file, but
> they don't maintain it apparantly. you can download one sort of for free
> from a company, cyscape, but it's many months old, incomplete, and had
> some weird license restrictions. cyscape _does_, however have a javabean
> component called browserhawk which can tell you all sorts of information
> about a browser's capabilities, given an HttpServletRequest. pretty nifty,
> works well with all of the browsers i've tried, but it's not open, and
> it's not exactly cheap. (interestingly enough, it comes with an obfuscated
> version of ibm's xml4j parser - hope they licensed it legitimately!)
> 
> i'm kind of torn. on the one hand, it's a great little component and it's
> got a comprehensive database (much better than their free browscap.ini
> file). on the other hand, it boggles my mind that there is no open browser
> capabilities database out there. am i missing one, is there in fact
> something good out there? if not, two questions:
> 
> 1. would anyone be interested in helping start such a database and a set
> of libraries to access it?
> 
> 2. will it be fairly straightforward to use a browser capabilities library
> (browserhawk or something else) to do flow control in the c2 sitemap?
> (e.g. apply this stylesheet if the browser supports DHTML, otherwise apply
> this one)

You must be psychic...  a few days ago I started playing with this
idea.  I started with the easy stuff (browser name, which is a simple
regexp on the userAgent string) but stopped on the more complicated
ability detection until I had more time to think about it. My plan was to
create a C2 Selector which can performs tests such as
"supports(XHTML)", "supports(FRAMES)", or "supports(DHTML)", which can be
trivially used in the sitemap to control pipeline flow.

So:  1) Yes and 2) Yes.

Obviously the database would be stored as a XML file - no point in writing
another parser when we have Xerces available.  Good arguments
against XML accepted though!  Questions remaining: what capabilities do we
keep; and how do we perform the matches.

(btw: I noticed when I first looked at Browserhawk that it can detect
whether the client has disabled Java/JavaScript etc.  How is this done
from the server side using a HttpServletRequest?  I thought that
BrowserHawk was a clientside javascript package because of this)

I think a document similar to this might be a good starting point for the 
database:

<browsers>
 <browser desc="IE4" ua="^Mozilla 4.[0-1]+.* \(MSIE,compatible" name="ie">
  <capability name="javascript">1.2</capability>
  <capability name="frames">yes</capability>
  <capability name="java">1.1</capability>
  ...
 </browser>
 ...
</browsers>

The desc attribute in the browser solely exists for editing the file and
the name attribute is a simple string for grouping browsers for
matching. The magic line is the ua (user agent) attribute, which contains
a regexp for matching a ua to set of capabilities (this example is
probably wrong,but it's not far out IIRC).  As we already have the Jakarta
Regexp library this is easy too.  By using regexps the plague of simple
substring matches (as in Cocoon 1 and the BrowserSelectorFactory in C2) is
avoided - ordering.

The browsecap.ini file supports inheritance of browsers, however I am not
sure if we will need it or not.  In browsecap.ini the matches are peformed
using a cut-down regexp parser - basically supports * and ? only. Because
of this, MSIE 4 and MSIE 4.01 have two seperate entries although they have
identical capabilities.  By using proper regexps this redunancy is
eliminated.  But then again defining the "typical" version 4 product and
inheriting from it for MSIE4, NS4 etc will make entries smaller.  But then
again, also slower.

Well, they were my thoughts anyway.  Felel free to ignore them or
comment upon them (preferably the latter however).

Regards,
Ross