Slashdot Mirror
Web 2.0 Recipes With PHP + DHTML
An anonymous reader writes "Take a look at these full simple code examples for dynamic elements for your web apps, including: Ad boxes, Pop-ups, Spinners, and Tabs. Easy ways to show and hide content on the page." From the article: "Incorporating JavaScript into your page makes the page dynamic and creates a more compelling user experience. Users can get more data more quickly, look at information from different aspects, and seamlessly navigate the site -- and the site doesn't have to go back to the server for lots of pages. However, there's also a reason to avoid using JavaScript: browser compatibility. In the early days of flat HTML, Internet Explorer rendered pages differently from Netscape. Those problems were fixed, but when support for CSS was added, new compatibility issues arose. Now most of the CSS issues have been solved, but JavaScript compatibility issues have cropped up. These compatibility problems have no easy solution. You need to weigh the benefit of what the JavaScript is doing against the number of browsers you'll need to test against and support."
This will make for some interesting comments. Begrizzled hippies whining about Javascript. Puzzled newbies arguing the merits of PHP. Flamefests over ruby on rails and other frameworks. Etc.
"including: Ad boxes, Pop-ups, Spinners, and Tabs. Easy ways to show and hide content on the page." Then you just mix it in the bowl and BAM! You have upset customers and lost respect!
I already hear all those people who disabled Javascript to avoid XSS-exploitation mutter in frustration because the perty "Web 2.0" pseudo-hype renders most pages useless.
What's so new about JavaScript?
Wow, he's using Apple to view/code his site. He might already be riddled with a ton of viruses (I read the McAfee Feigns Fear at Mac Security article). Better not try this at home without McAfee!
Spinners make the bitches hey-neener-neeners go neener-neener-squish!
Web 2.0 recipes? If that is Web 2.0, my homepage is Web X (or Web Vista).
My biggest hesitancy in using javascript is the IE warning bar that makes any page containing script look threatening. It's no problem with Foxfire, but most people still use IE. How many of them would see that warning and just assume something bad is lurking if they click Allow?
This article's been on the front page for a couple of minutes, with no comments. Perhaps Web 2.0 is tired?
For me, I really like JavaScript and AJAX when it helps to actually improve the user experience. Dynamic tabs? What's the point? How is it really functionally than just heading to a different page, or using some middleware to control what content is served, after a page reload?
Now, on a website I built, I've used AJAX (shudder) to create a commenting system that doesn't require the user to initially be logged in. The user can visit a page, submit a comment through the form, and if the user isn't logged in, they're presented with the ability to login right then and there, without losing their comment, and without even being shuttled off to a different section of the site, wondering if their comment will post when they're finished. If they don't have an account, they can create one right there. I think those kinds of tricks make remote scripting worthwhile.
Plus, I think adding new widgets to HTML through JavaScript is pretty keen - like the sliders and calendar that Yahoo is making available under the BSD license at their developer area.
concrete5: a cms made for marketing, but strong enough for geeks.
Am I missing something, or is this an article about javascript tricks that have been well characterized for several years? Must be a slow news day...
"These compatibility problems have no easy solution. You need to weigh the benefit of what the JavaScript is doing against the number of browsers you'll need to test against and support.""
Flash!
I wonder - we should have a competition to see who can make the most obnoxious web 2.0 page. Sort of like 1997 web "1" style - "under construction" gifs, flashing text, and scrolling status bars.
Get your own free personal location tracker
Same goes for Flash...
I can't believe how many companies spent tens of thousands of dollars on a CMS package, or to a "web designer" that rendered them invisible to the search engines.
The article does recommend a fallback for unsupported browsers. Take this to heart, because "GoogleBot" is an unsupported browser.
My ZooLoo
Stop calling it Web 2.0, you are making a total fool out of yourself. I thought meaningless buzzwords were for managers?
I'm Rocco. I'm the +5 Funny man.
Ruby on Rails is included in the definition of Web 2.0
Thanks you f'king PHP wankers, have a nice day!
Except for the tabs, these all seem like a pretty bad idea. Nobody wants to click all over to get at information that could have just been displayed in the first place.
hi mom!
It is just another article on doing DHTML on webpages. I read articles like this five years ago. This is not news. Zonk is not a nerd.
Great, instructions for ad-boxes, pop-ups, and spinners (I stopped reading the article before I got to what spinners were, but I'm sure they're obnoxious). This is almost as bad as the fact that Macromedia has a forum on their site dedicated to creating ads. Some people just give humans a bad name.
Next week: Your first phishing page with php and dhtml in just minutes!
I was hoping for some good code, it is from IBM after all, but its nothing more than crappy javascript from '99. Someone buy this guy the DOM Scripting book (http://www.domscripting.com/) and teach him what the seperation of structure (XHTML), presentation (CSS) and behavior (javascript) is all about.
most, adj.
Oh god, won't someone please think of the end users?
Javascript is for fluff, and arguably performance. But never for core functionality.
Ad boxes, Pop-ups, Spinners, and Tabs
Are the biggest reason to not use Java Script most of the time.
I have a couple PC's. One for trusted sites, and the other for general internet browsing. Some sites display a blank page. Too bad the site doesn't check what the client is running. A blank page does not provide any information including any reason I might want to visit with scripting turned on.
The truth shall set you free!
I ask because there are whole sites ( http://www.dynamicdrive.com/ ) that provide many more examples along with compatibility information. There are also huge sites with tutorials about developing your own scripts.
So why choose this seemingly random PAGE that offers (as far as I can tell) nothing new?
is for XULRunner to be released so we won't have to deal with the ugly HTML mess anymore.
IBM's JavaScript articles are usually high quality. But this one is awful. It uses invalid code, it doesn't degrade gracefully, it mixes HTML, CSS and JavaScript into the same file instead of separating them, and it breaks when you try and do things as simple as open a link in a new tab.
Don't be fooled by the "senior software engineer with more than 20 years of experience" author, this guy doesn't know the most basic, newbie things. I can only imagine that his 20 years of experience was with something other than HTML, CSS and JavaScript. For example:
That's just the tip of the iceberg. This is an exceptionally poor article.
Bogtha Bogtha Bogtha
They can't be indexed by search engines.
At least not true JavaScript sites, like http://www.worldspace.nu/
You can fix a pretty good browser compability -- if the site works in IE, Opera and Firefox you are rather safe (and in time safer). But it's not easy to know when the search engines will be able to index true JS sites.
And if the browsers back/forward buttons can't be used (like on the site I mentioned) a lot of people will get very annoyed.
This is why I don't think dynamic content will be mainstream any time soon (at least not sites with JavaScript that handle all the content).
Customers who use websites might not like that stuff, but customers who buy websites often love it and ask for it by name, and pay by the hour!
This issue is a bit more complicated than you think.
Those examples don't need PHP, they are simple copy and paste jobs. Adding PHP did nothing for the code. Sure, you could argue that using PHP would allow you to add features, but if that were the case, the article should explore possible additions.
..with the ActiveX Weasel. Bam! Instant security nightmare. Or maybe you want to knock it up a notch with the Java Snow Globe - old skool flavour!
*cough* *sputter*
... I'm sorry... this isn't Web 2.0, this is Web 1996... this is... this is... I couldn't even cope with TFA, it was giving me horrible flashbacks from back when I wrote IE-only webpages because I didn't know any better.
...who are you people, and what have you done with Slashdot?
Seriously, I'm not trying to troll, I'm genuinely at a loss for words here... how... what...???
Firefox does pass the Acid 2 test: https://bugzilla.mozilla.org/show_bug.cgi?id=28948 0#c98
In the early days of flat HTML, Internet Explorer rendered pages differently from Netscape. Those problems were fixed, but when support for CSS was added, new compatibility issues arose. Now most of the CSS issues have been solved, but JavaScript compatibility issues have cropped up.
Aaaaaaaaaaaaaahhh. My eyes are bleeding. What the fuck are you talking about?
In the early days of HTML, Internet Explorer did not exist.
Only IE and Netscape render pages differently?!
Most of the CSS issues have been solved?!? What?!
Javascript compatibility problems are new?@#$?@#$!?
From a practical point of view the information provided by the site in question is useless (not to take away from the efforts of those involved). The focus really should be on the convenient, useful aggregation of content, while providing ease of use for visitors to the site.
I was roped in by the "wowee zowee" stuff as IE battled Netscape in the 90's. Eventually we all realized that coding to the lowest common denominator was the key to creating a consistent, error free experience for our end users.
The bottom line is to make our sites useful. If done properly the sites can look great, be secure, provide great functionality and be compatible with all platforms. The caveat is that we remain at the mercy of browser quirks, making standards compliance a serious inconvenience for both users and developers.
This is the direction that emerging (AJAX, for example, is not new. It IS emerging) techniques and technologies should be focused on. Such a focus could cause new tricks to enhance compatibility/usefulness across platforms.
Thanks for letting me participate in the discussion!
WTF? I ordered a CHEESEburger!
I would like to be able to click in some part of a comment to hide it and all its responses, so I can read the comments I like and not all the stuff that gets posted.
/. take this into account.
Please some of the CSS hackers submiting designs for the new
We are Turing O-Machines. The Oracle is out there.
I thought spinners were for 50 Cent's Escalade.
Per ardua ad astra.
"In the early days of flat HTML, Internet Explorer rendered pages differently from Netscape. Those problems were fixed, but when support for CSS was added, new compatibility issues arose. Now most of the CSS issues have been solved, but JavaScript compatibility issues have cropped up."
CSS compatibility issues have been worked around; they have not been "solved", and any quick trip through Position is Everything or A List Apart will show you that. JavaScript compatibility issues have also been around since the first days of JavaScript implementation in browsers.
Neither are going to "be solved", especially if Microsoft have anything to say about it. Right now, as in the past, implementation differences equal a certain degree of lock-in. The truth is that no rendering engine provides a complete, perfect-for-intents-and-purposes CSS2 implementation, and IE is easily at the bottom of that pack. Combined with its field dominance, it is largely responsible for "CSS compatibility issues".
IE 7 isn't going to provide a better rendering engine than Gecko, KHTML/WebCore, or whatever Opera's engine is called; it will simply address a list of the most important problems, such as the infamous box model fuck-ups. There will not be a "kickass" rendering engine in IE 7, and as much as I hate to say it, that's going to keep us in compatibility hack hell for the near future.
Now, if you ask me--and obviously you did, right, lol internet_rant--Microsoft have had more than ample time, people, and resources to produce a rendering engine on-par with Gecko and its peers. But that's not going to be the case. Only one reason for that.
CSS compatibility issues mostly solved? Not even close.
Mikey-San
Karma: +Eleventy billion (mostly affected by watching Celebrity Jeopardy)
Ok, I don't notice casalemedia very often, but that's because I block them and their spammy popups. Arrrgh...
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
This code is crap. Use of <a href="javascript:"> makes it same quality as <marquee><font color="#ggggg">OMG Web 2.0!</td></font>
Unlike TFA, here are some resources worth reading:
I spent years wading through the quagmire of DHTML/CSS/Javascript compatibility issues and eventually realised that it was a full time job getting it right. 'Trouble was the job went largely unrewarded as the end user was only interested in how pretty it looked and it's difficult to get a client to pay you properly for time spent working round compatibility problems. Eventually I got wise and realised M$ had screwed up the CSS and Javascript game beyond recovery and decided to concentrate my energies where my time would be rewarded. I've been working with Perl, PHP, MySQL and PostgreSQL ever since and haven't looked back. For front-end design I keep it simple - basic CSS and no Javascript. That way I can sleep at night and wake refreshed to concentrate on the aspects of web development which add real value to a site. "Web 2.0" won't tempt me back into the fray as IE5/6 issues will haunt web developers for many years yet, regardless of what Vista and IE7 brings.
One area of web development I think is very much neglected is semi-dynamic web development with Template Toolkit and cron. The content of many dynamic sites only changes periodically so it can often be better to have templates generate static pages periodically from your database with a cron script instead of coding the whole site in PHP, Perl/CGI or whatever.
But having Javascript as the scripting language (instead of Java or some other decently secure language) is dangerous and nasty for the user who reads your website, because you're requiring the user to turn Javascript on to see your cool stuff, so unless the user is willing to do the work to configure site-by-site Javascript-enabling permissions, that means that when he later visits www.perfectly-harmless-looking-trustme.example.com , he's going to get annoying popups, ANNOYING BLINKY STUFF, and whatever other tricks the bad guys are pumping out this week.
And yes, I know that Javascript lets you write perfectly safe code if you want to - it's also possible to write perfectly safe code in ActiveX, and I don't want to run that either. Java was written to provide safe ways to write code on web pages, with an underlying security model that AFAIK is still perfectly solid today, though as with anything there have been occasional implementation bugs. That's not an accident - Gosling's previous cool system, the NeWS windowing system, used Postscript as its native language, which gave you graphics that really rendered well, client-side scripting, much better control of dynamic actions that X (e.g. running the mouse tracking and rendering from the graphics server on your desk instead of running every mouse movement across the network twice the way X does), and the ability to write scripts that did all sorts of malicious things to the user. Because this was the 80s, and it was mainly used inside a few engineering companies and academia most of the maliciousness was limited to doing random blinky things to the victim's screen, like making all the pixels melt and drip down to the bottom of the screen or having cockroaches hiding under the windows that snuck out when you left them alone for a while, but the security risk was a real problem (and occasionally debugging could be difficult, because many of the opennesses in Postscript that allow malicious attacks also allow regular bugs to sneak in.)
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
No Script is Love
I'd go on a Vegan diet but the delivery time from Vega is too long. --brownkitty
I know this doesn't probably apply to you, given your target audience. But what you've done, I think, is generally a bad idea.
Reality check: most of the world (about 80%, if I remember corectly) is still on dialup.
That page comes in at 43K. The same page in HTML would probably be 2/3 less. When you're trying to sell stuff and keep people on your site, the difference between a 2-3 second download and a 8 second download is huge.
Would it necessarily be as "pretty" as the javascript (or php, ajax, or "buzzword") page? Maybe, maybe not - but that's not the point. It doesn't matter wtf the page looks like if nobody's looking.
I think this says it all:
<span class="h1">Who am I?</span>
Or the fact that you don't even have a <body>.
You are right and wrong.
It's true you need to keep an eye on the page size, but a standard slashdot frontpage with graphics is about 35 KB, so 44 KB is very close. And I do belive most of my audience read slashdot.
Very often sending raw html javascript data fills up much less than the formatted page. The unit list is written with a few lines of javascript code, but if it should have been formatted and build on the server it would end up with a size off more than 44 KB.
But you are right in the sense that you can't send a database with 2-3 MB. So it depends on the task rather than the audience.
-:) Oh no - not again.
www.rednebula.com
Agreed. I was just trying to make the *general* point. Too many people worry about the l33t way of doing things without taking into consideration the people who will be viewing their pages .... which is the whole point to having a page in the first place.
I think whaty ou've done is entirely appropriate for your application. But let's face it - if you put up a tutorial web page and used that as an example, it would only be a few days before we'd be flooded by 500 meg java pages that did nothing more than change the colour on some background somewhere.
I was doing some of this dhtml and java scripting 6 years ago. Where have these people been? (Oh! It's IBM. never mind)
...totally unreliable.