[nycphp-talk] was Presentation URL--cross-browser compatibility
inforequest
sm11szw02 at sneakemail.com
Thu Aug 26 00:21:46 EDT 2004
Susan Shemin susan_shemin-at-yahoo.com |nyphp 04/2004| wrote:
> Jay, and the group,
>
> Most people (I've seen the figure of 85%) use IE, and that's why I
> develop for it. Am I wrong to have the understanding that only
> Netscape (using the Mozilla engine) can display the WUL programming?
> I'm working on a PHP/MySQL site where the no refresh feature would be
> useful, but again, it will have to be cross-browser, or it would mean
> I'd have to develop two sites, one for IE and one for Netscape.
>
> Hey, guys, be gentle if I'm a bit confused here...
>
> Susan
>
> ------------------------------------------------------------------------
Here's how I nutshell Xul's place in the world:
*You would use XUL where you would have used HTML. So you can use Xul
(page coding) with CSS (for stylin) and js (for action).
*Xul gives you more features than HTML; some of the features you used to
embed large js scripts to get
*If you make web sites, you won't want to replace your HTML with Xul
unless you want to limit your website to Gecko-only visitors.
*Xul runs in Gecko. Think of it as an application language, not a
website coding language. What does that mean?
Let's say an application is a collection of pages which must share
common "memory" --kinda like they need access to a collection of
variables at all times. HTTP is called "stateless" because the server
only knows the client web browser when a page is requested. Between page
requests, the server doesn't keep any "memory" of that browser client.
That is why any variables that must be "remembered" between pages have
to be passed as hidden vars, or stuffed into session cookies, or written
to a file. An "application" requires state -- the more vars you are
passing around between your pages inorder to make your website function,
the more your web project is starting to look like a web "application".
But if you write an *application*, you will start needing features like
instance-programmable pop-down menus, which you will have to go to java,
js or ActiveX to get (browser compatibility problems there as well). In
your application you need alot of access to your variables, so you will
find yourself going back and forth to the server alot. You will struggle
with GET vs. POST because sometimes you need to pass vars but can't
restrict the order in which a multi-part form is to be completed, for
example. In fact, sometimes only some parts of a multi-part form are
needed, based on what the user has already entered. That will require
another hit to the server, for each examination of entered data --
unless you decide to use js.... or Xul. Get it? It becomes difficult to
make an "application" out of a string of web pages.... and Xul provides
a means to do multipart screens without excessive refreshes to the
server, and less dependence on the use of sessions/cookies/hidden
vars/and all the other techniques of coping with a "stateless" HTTP
protocol.
Xul lessens your dependence on complex js, by enriching the features
available inside the page description language (which was HTML and is in
this case Xul). It does so only for Gecko browsers.
-=john andrews
More information about the talk
mailing list