NYCPHP Meetup

NYPHP.org

[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