Hi all,
I have done many years of server-side programming with PHP and decide to round up my skills, I would like to master client-side web UI programming too, such as drag and drop UI elements about, loading progress bar in HTML, pop-up dialog boxes and etc.
What is the collective term for this type of programming? I understand that AJAX is involved. Is it Javascript/DOM coding, or Dynamic HTML or just 'generic Web 2.0' programming?
Also, where is a good place to begin? I have learned Javascript before; so where I should be look at next (DOM? Dynamic HTML?) Are there already existing libraries like for the fanciful stuff you see in LightBox gallery and etc?
Sorry for the barrage of questions
How do I get started with client-side UI?
Moderator: General Moderators
-
LonelyProgrammer
- Forum Contributor
- Posts: 108
- Joined: Sun Oct 12, 2003 7:10 am
- JAB Creations
- DevNet Resident
- Posts: 2341
- Joined: Thu Jan 13, 2005 6:44 pm
- Location: Sarasota Florida
- Contact:
Re: How do I get started with client-side UI?
Good questions! While you're at a web developer forum mostly for PHP and MySQL I'm actually a web designer learning web development.
Let me clarify how I use terminology and get you rolling along because there are a lot of things you can choke on that just need to be pointed out before hand.
Web Design = Client Side = XHTML, CSS, JavaScript
Web Development = Server Side = PHP, MySQL, Apache
Roles simplified...
XHTML = Noun language.
CSS = Adjective language.
JavaScript = (A)Verb language.
As a web developer you already know the roles of PHP, MySQL, and Apache.
Before you jump in to advanced clientside GUI it's a good idea to get used to the correct terminology to reference things.
XHTML
<element attribute="value" />
CSS
selector {property: value;}
If you really want to learn it correctly you'll want to avoid existing libraries/frameworks. You should know all about overhead (making minimal use of regex in example) as this leads to issues.
If you don't learn the languages and how they all work together but instead opt to use a framework to do the heavy lifting then you'll always be dependent on that framework. You don't need to pile on 40KB of compressed jQuery library files to change a simple class (CSS appearance) of something which can be done in probably less then 100 bytes.
Understanding the DOM is important too. In example JavaScript and W3C DOM aren't actually the same language though they pretty much are...confusing? Yeah but if you pay attention to things you'll be ok. Basically think of the DOM (document object model) as in what the browser is able to actually see for sure. Now you can do something like add a little JavaScript like when you flip through the themes on this layer on this page on my site (themes don't work but the script does)...
http://www.jabcreations.com/blog/?promp ... s-official
...however if you try to interact with any XHTML element via it's ID (the default way to interacting with the page) in other ways it won't work...why? That version of my site uses responseText, not responseXML like the next version already is (currently in alpha). So since I'm able to learn all this stuff on my own I don't have to depend on any libraries/frameworks whatsoever. That means you're not limited to waiting for answers for a small limited community (even though in example as much as I like jQuery and it's very popular) you'll be able to find more answers quicker if you know how to deal with JavaScript directly. It also greatly increases your value as a programmer to be able to write something that others can't.
There are some practices that I highly recommend such as using the base element and at least developing your work locally using the application/xhtml+xml media type (or mime). Why? I explained it earlier this evening here...
viewtopic.php?f=19&t=97302#p528873
It's also important to understand what browsers support and don't...but even more important about rendering engines. There are four main engines (five if you want to be kind to KHTML)...
Gecko - Firefox, Camino, Flock, Mozilla Suite (deprecated for...) Mozilla SeaMonkey, etc.
Presto - Opera...and only Opera.
Trident - Internet Explorer and non-browser "browsers" such as AOL, Maxthon, etc. (It's a single line programmers drop in which explains why it's so (unfortunately) wide spread)
WebKit - Safari, Chrome, OmniWeb browser (which is a good way for OS X uses to test old versions of Safari since they won't run but OmniWeb has the WebKit engine built inside and is not system based. IE's Trident engine is system based in example though it can (3.0, 4.0, 5.01, 5.5, and 7.0 but not 6.0 or 8.0) be made to run as a standalone application (with bugs due to OS entanglement to create a monopoly).
If you're using Firefox 2 and Mozilla SeaMonkey 1.1 you've got two browsers using Gecko 1.8...no reason to since they'll render the XHTML and CSS exactly the same since it's the same engine.
JavaScript is a little different. Safari and Chrome while they share the WebKit engine for XHTML/CSS use different JavaScript engines. The only engine you need to worry about dealing with is whatever it's called in Internet Explorer. Until you get modestly advanced you won't notice any issues.
Now a massive mistake everyone makes that you can avoid: do not test your work in Internet Explorer by default! While IE 8 has made considerable CSS 2.1 progress (it's exceptionally but not absolutely CSS 2.1 compliant though it does not have many Gecko bugs) I test my work in Firefox first and foremost. There are some Gecko bugs so I test my work in Opera and Safari...then I test it in IE 8. When I'm ready for backwards compatibility (as far as CSS is concerned) then I'll run a copy of XP with IE6 as the system IE version. If you install IE8 as the system version you can't run IE 5.0, 5.5, and 7.0 as standalones. I have IE8 on my system as the system IE version so I run XP emulated in VMware Server with IE6 as the system IE version with 5.0, 5.5, and 7.0 each running standalone in that emulated copy of XP.
As far as dealing with Internet Explorer there are two things. First and foremost don't bother to muck up your main style sheet. CSS stands for CASCADING style sheet...so going top to bottom...if you define a rule twice the last occurrence of the rule override all (with !important as a rare exception).
div.color {color: #ff0;}
div.color {color: #f0f;}
div.color {color: #0ff;}
If this was in your style sheet then the color would end up rendering as #0ff.
Since you can link multiple style sheets when you load up IE7 or earlier all you're going to need to do is use conditional comments. I have an IECCSS tutorial that explains this.
So remember, do not try to fix IE's CSS bugs in your main style sheet, fix them by rewriting the rules (you don't need to redo the color code in example if you just need to adjust the width) in the second style sheet and serve it after the main style sheet. Visit my site in IE (ha! that's a rare request!) and look at the source code for an example.
As far as JavaScript issues in IE while they've slowly been getting better it's still a nightmare at advanced levels. So you'll want to do object detection. As far as JavaScript is concerned the alert method is your best friend just like print_r and dump_var are in PHP. All you have to do is a simple if condition...
Any way those are a few pointers for you and should be kept in mind.
As far as resources I highly recommend Google.
You really should learn to do a simple page structure using divisible elements (<div></div>) in CSS 1.0. In example while the CSS 2.1 properties aren't supported on my site the main content will generally appear just fine in older versions of Opera 4.0+ as well as Internet Explorer 4.0+. You can download Opera 4 if you search for "old versions" on Google. You can also validate your CSS at certain levels. Here are some links to get you moving along...
CSS Validator...
http://jigsaw.w3.org/css-validator/
(X)HTML Validator...
http://validator.w3.org/#validate_by_input
Remember use that base element to ease your local versus live work (read my post I linked to). Use application/xhtml+xml at least locally. Some guy here posted the other day lost hours of time because he was missing a quote. If he had been using XHTML as application/xhtml+xml Firefox would have broken and given him a big fat error...but he'd know exactly what he would have had to fix. This sort of stuff takes seconds not hours.
As far as extensions for Firefox I highly recommend looking at my list on my site's links page. Minimally I recommend Chris Pederick's Web Developer toolbar for Firefox (it should actually be called Web Designer but the terms are unfortunately interchangeably used). I have also found IE8's developer tools (not available in IE7 or earlier) useful. Safari has a developer menu but you have to manually set it to display in Safari's advanced options. Opera has a great back-trace debugger for JavaScript.
I also recommend making sure you code completely error free. Any error can easily debacle hours worth of work and leave you wondering why something isn't working in one browser or another...or all of them...etc.
Once you have a solid foundation you'll very easily be able to tackle on bigger things. I'll subscribe should you need and clarifications. Good luck and feel free to ask more questions.
Let me clarify how I use terminology and get you rolling along because there are a lot of things you can choke on that just need to be pointed out before hand.
Web Design = Client Side = XHTML, CSS, JavaScript
Web Development = Server Side = PHP, MySQL, Apache
Roles simplified...
XHTML = Noun language.
CSS = Adjective language.
JavaScript = (A)Verb language.
As a web developer you already know the roles of PHP, MySQL, and Apache.
Before you jump in to advanced clientside GUI it's a good idea to get used to the correct terminology to reference things.
XHTML
<element attribute="value" />
CSS
selector {property: value;}
If you really want to learn it correctly you'll want to avoid existing libraries/frameworks. You should know all about overhead (making minimal use of regex in example) as this leads to issues.
If you don't learn the languages and how they all work together but instead opt to use a framework to do the heavy lifting then you'll always be dependent on that framework. You don't need to pile on 40KB of compressed jQuery library files to change a simple class (CSS appearance) of something which can be done in probably less then 100 bytes.
Understanding the DOM is important too. In example JavaScript and W3C DOM aren't actually the same language though they pretty much are...confusing? Yeah but if you pay attention to things you'll be ok. Basically think of the DOM (document object model) as in what the browser is able to actually see for sure. Now you can do something like add a little JavaScript like when you flip through the themes on this layer on this page on my site (themes don't work but the script does)...
http://www.jabcreations.com/blog/?promp ... s-official
...however if you try to interact with any XHTML element via it's ID (the default way to interacting with the page) in other ways it won't work...why? That version of my site uses responseText, not responseXML like the next version already is (currently in alpha). So since I'm able to learn all this stuff on my own I don't have to depend on any libraries/frameworks whatsoever. That means you're not limited to waiting for answers for a small limited community (even though in example as much as I like jQuery and it's very popular) you'll be able to find more answers quicker if you know how to deal with JavaScript directly. It also greatly increases your value as a programmer to be able to write something that others can't.
There are some practices that I highly recommend such as using the base element and at least developing your work locally using the application/xhtml+xml media type (or mime). Why? I explained it earlier this evening here...
viewtopic.php?f=19&t=97302#p528873
It's also important to understand what browsers support and don't...but even more important about rendering engines. There are four main engines (five if you want to be kind to KHTML)...
Gecko - Firefox, Camino, Flock, Mozilla Suite (deprecated for...) Mozilla SeaMonkey, etc.
Presto - Opera...and only Opera.
Trident - Internet Explorer and non-browser "browsers" such as AOL, Maxthon, etc. (It's a single line programmers drop in which explains why it's so (unfortunately) wide spread)
WebKit - Safari, Chrome, OmniWeb browser (which is a good way for OS X uses to test old versions of Safari since they won't run but OmniWeb has the WebKit engine built inside and is not system based. IE's Trident engine is system based in example though it can (3.0, 4.0, 5.01, 5.5, and 7.0 but not 6.0 or 8.0) be made to run as a standalone application (with bugs due to OS entanglement to create a monopoly).
If you're using Firefox 2 and Mozilla SeaMonkey 1.1 you've got two browsers using Gecko 1.8...no reason to since they'll render the XHTML and CSS exactly the same since it's the same engine.
JavaScript is a little different. Safari and Chrome while they share the WebKit engine for XHTML/CSS use different JavaScript engines. The only engine you need to worry about dealing with is whatever it's called in Internet Explorer. Until you get modestly advanced you won't notice any issues.
Now a massive mistake everyone makes that you can avoid: do not test your work in Internet Explorer by default! While IE 8 has made considerable CSS 2.1 progress (it's exceptionally but not absolutely CSS 2.1 compliant though it does not have many Gecko bugs) I test my work in Firefox first and foremost. There are some Gecko bugs so I test my work in Opera and Safari...then I test it in IE 8. When I'm ready for backwards compatibility (as far as CSS is concerned) then I'll run a copy of XP with IE6 as the system IE version. If you install IE8 as the system version you can't run IE 5.0, 5.5, and 7.0 as standalones. I have IE8 on my system as the system IE version so I run XP emulated in VMware Server with IE6 as the system IE version with 5.0, 5.5, and 7.0 each running standalone in that emulated copy of XP.
As far as dealing with Internet Explorer there are two things. First and foremost don't bother to muck up your main style sheet. CSS stands for CASCADING style sheet...so going top to bottom...if you define a rule twice the last occurrence of the rule override all (with !important as a rare exception).
div.color {color: #ff0;}
div.color {color: #f0f;}
div.color {color: #0ff;}
If this was in your style sheet then the color would end up rendering as #0ff.
Since you can link multiple style sheets when you load up IE7 or earlier all you're going to need to do is use conditional comments. I have an IECCSS tutorial that explains this.
So remember, do not try to fix IE's CSS bugs in your main style sheet, fix them by rewriting the rules (you don't need to redo the color code in example if you just need to adjust the width) in the second style sheet and serve it after the main style sheet. Visit my site in IE (ha! that's a rare request!) and look at the source code for an example.
As far as JavaScript issues in IE while they've slowly been getting better it's still a nightmare at advanced levels. So you'll want to do object detection. As far as JavaScript is concerned the alert method is your best friend just like print_r and dump_var are in PHP. All you have to do is a simple if condition...
Code: Select all
if (addEventListener) {alert('I can do this code standards compliant');}else if (!addEventListener) {alert('your browser irks me');}As far as resources I highly recommend Google.
You really should learn to do a simple page structure using divisible elements (<div></div>) in CSS 1.0. In example while the CSS 2.1 properties aren't supported on my site the main content will generally appear just fine in older versions of Opera 4.0+ as well as Internet Explorer 4.0+. You can download Opera 4 if you search for "old versions" on Google. You can also validate your CSS at certain levels. Here are some links to get you moving along...
CSS Validator...
http://jigsaw.w3.org/css-validator/
(X)HTML Validator...
http://validator.w3.org/#validate_by_input
Remember use that base element to ease your local versus live work (read my post I linked to). Use application/xhtml+xml at least locally. Some guy here posted the other day lost hours of time because he was missing a quote. If he had been using XHTML as application/xhtml+xml Firefox would have broken and given him a big fat error...but he'd know exactly what he would have had to fix. This sort of stuff takes seconds not hours.
As far as extensions for Firefox I highly recommend looking at my list on my site's links page. Minimally I recommend Chris Pederick's Web Developer toolbar for Firefox (it should actually be called Web Designer but the terms are unfortunately interchangeably used). I have also found IE8's developer tools (not available in IE7 or earlier) useful. Safari has a developer menu but you have to manually set it to display in Safari's advanced options. Opera has a great back-trace debugger for JavaScript.
I also recommend making sure you code completely error free. Any error can easily debacle hours worth of work and leave you wondering why something isn't working in one browser or another...or all of them...etc.
Once you have a solid foundation you'll very easily be able to tackle on bigger things. I'll subscribe should you need and clarifications. Good luck and feel free to ask more questions.
-
LonelyProgrammer
- Forum Contributor
- Posts: 108
- Joined: Sun Oct 12, 2003 7:10 am
Re: How do I get started with client-side UI?
Thanks for the explanation! I would definitely try to pick up CSS/XML/DOM/Javascript from the ground up but from experiences, when it comes to doing live projects, it's better to use blackboxes. So I guess after learning those I will then go look for the libraries.
On Edit: I know this is a great site for PHP/MySQL. What other places would you recommend me to take a look?
On Edit: I know this is a great site for PHP/MySQL. What other places would you recommend me to take a look?
- JAB Creations
- DevNet Resident
- Posts: 2341
- Joined: Thu Jan 13, 2005 6:44 pm
- Location: Sarasota Florida
- Contact:
Re: How do I get started with client-side UI?
What you want to do determines what you need to use...and therefor will determine what you'll be searching for.
If you want to learn about CSS 1.0 to get the basics covered simply learn about clear, float, width, height, display (block|inline), and how it effects the box model.
If you want to learn about CSS 1.0 to get the basics covered simply learn about clear, float, width, height, display (block|inline), and how it effects the box model.
-
crazycoders
- Forum Contributor
- Posts: 260
- Joined: Tue Oct 28, 2008 7:48 am
- Location: Montreal, Qc, Canada
Re: How do I get started with client-side UI?
I'm not entirely happy with the fact that you said not to use frameworks. At least not any renowned ones. The framework i'm developping is very flexible for now and doesn't rely on any specific mumbo jumbo syntax and doesn't output anything extra that you wouldn't do by yourself. Be careful when you say that... it hurts the feelings of the framework developers 
Re: How do I get started with client-side UI?
well, there is some truth to what he said.
that said, i quite disagree with the following ...
ultimately, you would end up in some kind of framework. otherwise you will not have any structure at all.
this example is very good. lots of time frameworks use large overheads in order to try and outdo competing frameworks. this led to very heavy use of scripts to such an extent that when you want something simple done, you need a PhD in the framework. it's utterly mad.JAB Creations wrote:If you don't learn the languages and how they all work together but instead opt to use a framework to do the heavy lifting then you'll always be dependent on that framework. You don't need to pile on 40KB of compressed jQuery library files to change a simple class (CSS appearance) of something which can be done in probably less then 100 bytes.
that said, i quite disagree with the following ...
existing libraries and frameworks provide excellent ideas on how people solved various issues. not looking at them means you will loose out on major issues which have been solved eons ago. i am not suggesting using them, but certainly look under the hood. there are are tons of good quality coding done by several thousand people, its a sheer waste if you ignore them all. and of course, not all the solutions are good, but you get the idea of what options are available.JAB Creations wrote:If you really want to learn it correctly you'll want to avoid existing libraries/frameworks. You should know all about overhead (making minimal use of regex in example) as this leads to issues.
ultimately, you would end up in some kind of framework. otherwise you will not have any structure at all.