My Personal Experince,

A normal day on my office desk. I was assigned a job of doing Advance Level SEO for one of our clients. During that, I was navigating the code structure of individual files and in course, I launched w3c html validator to see if everything was syntatically correct. First I was amazed to see there were 48 errors and 3  warnings (the site was of course not designed by neolinx) to be corrected. In addition to that, what spinned my head around was a simple message(info) from w3c that beautifully said

"Note: file upload may not work with Internet Explorer on some versions of Windows XP Service Pack 2, see our information page on the W3C QA Website."

LOL. My point of expression is that "Why dont Micorsoft admits that it's got some headaching bugs on it's Internet Explorer browsers even if w3c (the rule maker) clearly indicates - Hey boy, you got some problems in there ?".

To view this message live, follow this link -http://validator.w3.org/#validate_by_upload

Thats all for today.

Bhupal

 Want some randomness on your website? Try out this PHP image rotator. This script will display a random image every time the user re-loads the page or starts navigating. A very nice effect that can help you make your website a little bit more interactive.

Installing on your site

To install the script, simply download it and place it in any folder of your server. In the default configuration, all images from the folder where the script is located are used.

Example:

images/header/rotate.php
images/header/abstract.jpg
images/header/bird.jpg
images/header/butterfly.jpg
images/header/happy.jpg
Now direct the source to the PHP file and you're done.

Now direct the source to the PHP file and you're done.
 

That's it. Now any random image file located in the same directory as the script will be displayed.

Advanced configuration

Change this variable in the script to locate the directory where your images are placed. When the default is selected, the script wil randomly use any image file that is located in the same directory as the script.

$extList = array();
$extList['gif'] = 'image/gif';
$extList['jpg'] = 'image/jpeg';
$extList['jpeg'] = 'image/jpeg';
$extList['png'] = 'image/png';

In this variable you can set which image types are used. For example, remove all the default $extList values and add a $extList['css'] = 'text/css';. Now a random CSS file be selected. This way, you can play a little bit with your websites CSS, making it fun for the visitor every time he reloads the page. You can actually random any file you want.

CODE

$folder = '.';


    $extList = array();
	$extList['gif'] = 'image/gif';
	$extList['jpg'] = 'image/jpeg';
	$extList['jpeg'] = 'image/jpeg';
	$extList['png'] = 'image/png';

$img = null;

if (substr($folder,-1) != '/') {
	$folder = $folder.'/';
}

if (isset($_GET['img'])) {
	$imageInfo = pathinfo($_GET['img']);
	if (
	    isset( $extList[ strtolower( $imageInfo['extension'] ) ] ) &&
        file_exists( $folder.$imageInfo['basename'] )
    ) {
		$img = $folder.$imageInfo['basename'];
	}
} else {
	$fileList = array();
	$handle = opendir($folder);
	while ( false !== ( $file = readdir($handle) ) ) {
		$file_info = pathinfo($file);
		if (
		    isset( $extList[ strtolower( $file_info['extension'] ) ] )
		) {
			$fileList[] = $file;
		}
	}
	closedir($handle);

	if (count($fileList) > 0) {
		$imageNumber = time() % count($fileList);
		$img = $folder.$fileList[$imageNumber];
	}
}

if ($img!=null) {
	$imageInfo = pathinfo($img);
	$contentType = 'Content-type: '.$extList[ $imageInfo['extension'] ];
	header ($contentType);
	readfile($img);
} else {
	if ( function_exists('imagecreate') ) {
		header ("Content-type: image/png");
		$im = @imagecreate (100, 100)
		    or die ("Cannot initialize new GD image stream");
		$background_color = imagecolorallocate ($im, 255, 255, 255);
		$text_color = imagecolorallocate ($im, 0,0,0);
		imagestring ($im, 2, 5, 5,  "IMAGE ERROR", $text_color);
		imagepng ($im);
		imagedestroy($im);
	}
}

?>

sudo apt-get install curl libcurl3 libcurl3-dev php5-curl

sudo /etc/init.d/apache2 restart

To Enable a rewrite Module

sudo a2enmod rewrite

sudo /etc/init.d/apache2 restart

To Disable a rewrite Module

sudo a2dismod rewrite

sudo /etc/init.d/apache2 restart

Now if you want to use .htaccess working, you must set the directory permission accordingly. You have to edit /etc/apache2/sites-available/default. For this, open this file in your preferred text editor. For me, its gedit.

sudo gedit /etc/apache2/sites-available/default

Then set the permission as shown below i.e. change AllowOverride None to AllowOverride all 

<Directory /home/kahwee/projects/whatever>

  Options Indexes FollowSymLinks MultiViews

  AllowOverride all

  Order allow,deny

  allow from all

</Directory> 

sudo /etc/init.d/apache2 restart

And enjoy!

We've often maintained that 2008 will be the official "Year of the Mobile Web". But I've always thought that it's also the year when it comes out of the technical shadows - and web designers start to take it seriously.

Mature mobile web design has been a long time coming, of course held back by usual gripes like browser capabilities, device diversity and network speeds. But life moves on, and now it's time to make the mobile web look amazing.

It's a exciting new visual canvas, with plenty of chance to innovate, explore and defie convention - that of desktop sites particularly.

I'm no designer myself, but I think there's also something very refreshing about having to create elegant, concise sites and pages that still retain the qualities of good graphic design and appeal to users in the mobile context.

Mark Twain famously said, "If I had had more time, I would have written a shorter letter". Similarly, there's a real art to creating a compelling and visually thrilling mobile site - particularly in contrast to just lamely hacking an existing desktop site up into small pieces.

Designing a beautiful mobile site is like writing a haiku: a craft belied by the size of the result alone.

So anyway, with this in mind, I'm thrilled to see we made a list of 30 Essential PDF Document Every Designer Should Download. Now, I'm not sure why being a PDF is so important :-) ...but still, you'll see our popular Mobile Web Developer's Guide made the cut - along with some other great texts.

Be sure to check it out if you're at all interested in modern web design.

Source : mobiforge.com

Size does matter

While screen resolution is an issue with regular Web browsing, the actual screen dimensions are important when dealing with mobile devices. Screen size limitations are an issue because the majority of Web sites are designed to be viewed on desktop size displays. Their page layout assumes that users can view large portions of a page at once. The much smaller page excerpts displayed on a handheld device screen interferes with page functionality and user comprehension. The result is that users have to spend an inordinate amount of time awkwardly scrolling up and down as well as left and right.

Content is king

Due to the space limitations, developers should be conscious of the following tips when targeting mobile devices:

• Limit graphics: Graphics are an excellent way to spice up a Web site, but their use is questionable when working with small screens. Also, many handheld devices feature monochrome displays, so rich color graphics are lost. The most important text or information should take center stage. If you must use graphics, limit their size to control download times. In addition, effectively use every pixel of a graphic and avoid unnecessary elements. On a final note, take advantage of the alt tag for images so graphic functionality is conveyed when/if images are not displayed.
• Limit download times: Travel back in time to the initial days of the Web where dial-up connections with a 9,600 baud modem was cutting edge, and you will understand the bandwidth limitations for wireless devices. So, you should develop scaled-down pages that eliminate the bells and whistles and deliver only what is necessary to mobile clients.
• Carefully select content: Tailor the content specifically to the target user group by displaying only the most essential data.
• Minimize page length and size: Scrolling on handheld devices is often limited, awkward, and hard for users to keep track of their place with scroll keys and other pen input devices. With that in mind, you should limit the amount of scrolling required in a Web application. This may involve splitting normal pages into multiple pages for handhelds. Architecting the site for handheld devices demands information that is effectively organized to maximize user experience.
• Utilize standard HTML: Stick with standard HTML tags to ensure proper functioning of an application.

When developing applications for mobile or handheld browsers, your main focus is on the content. The reduced screen size relegates the extra items to the scrap heap. This includes needless graphics, as well as all other nonessential page elements. It forces the design team to clearly define or pinpoint what is most important to the target user group.

Dealing with user input

Another issue you face when interacting with a Web application via a handheld device is user input. A user may type on a miniature keyboard, use buttons for scrolling and selection, or use a pen-based device like the ones found with a Palm device. After all, including an input form is not a good idea when the user has only a few input buttons and no keyboard.

Testing

An important part of every development project is testing, but this can be quite a chore when targeting handheld devices. There are so many devices on the market, it is almost impossible to test with every conceivable application. Most manufacturers provide a Software Development Kit (SDK) to test applications on their platforms. A few notable platforms include Symbian, Palm, Motorola, and the BlackBerry.

Development options

A few years ago, there was a lot of hype around Wireless Markup Language (WML), but it has dissipated as devices now support HTML and CSS. While most mobile devices can easily handle regular HTML pages, there are other options available.

You may opt to develop a mobile application as opposed to a Web application. Mobile applications are actually installed on the device. They run inside the mobile device and use its memory and disk space. The difference between mobile and Web applications is they can run without Internet connectivity.

The .NET Compact Framework and Java ME are two examples of mobile development platforms. They allow you to utilize programming languages to deliver mobile functionality. While they may include Web functionality, they most often do not rely on it.

A whole new set of users

The cell phone market has fueled the explosion of the market for mobile devices. It was only a matter of time before Internet capabilities were extended to these devices. It began with e-mail retrieval and now includes Web browsing. While it is great to have the Web at your fingertips, developing applications for these devices requires a different set of considerations from normal Web applications. The key is focusing on the content and screen size when targeting handhelds.

source: techrepublic.com

CSS has long allowed web developers to use images as the backgrounds for elements. Background images can be repeated in either or both directions, their position can be adjusted from a default top-left position, and they can be attached to the element or fixed with respect to the browser window. Add in the ability to specify a background color that underlies the background image and you can do quite a bit using only CSS 2-level features supported for years in all browsers.

One thing you can’t do with CSS 2 background support, however, is resize the image. Consider, for example, adding a background image to your personal site and stretching it to cover the width of the page, or the height of the page, or both: it’s impossible. You could fake up such a background using an <img> element, z-index, and absolute positioning, but if the window is resized you’ll have to manually resize the image to accommodate using JavaScript — hardly a clean separation of content from display. It may even be impossible if you can’t shoehorn an extra <script> into your site’s page templates.

CSS3 to the rescue with background-size! (-moz-background-size for now in Mozilla)

The good news is that CSS2 is not the end of the world, and CSS3 Backgrounds and Borders adds support for resizing images used in backgrounds through the aptly-named background-size property. Even better: now that bug 189519 is fixed, the Mozilla tree includes support for it, under the name -moz-background-size (prefixed because the specification is still in flux, although we think this part of it shouldn’t change much going forward). With background-size, you can stretch or compress the background image horizontally or vertically, either absolutely or relative to the dimensions of the background area in which the image resides, with the option to preserve image proportion if desired. The effect is as though a scaled version of the image were being used directly.

The syntax

The syntax for background-size is pretty simple:

background-size: <nonnegative-width-or-auto> [ <nonnegative-height-or-auto> ];
background-size: contain;
background-size: cover;

The first syntax allows the author to specify a specific width and height for the image. Each dimension is the keyword auto, a length, or a percentage; if the second dimension is omitted, it is implicitly auto. The meaning of auto is to stretch the image in the relevant direction as needed to preserve its aspect ratio; for example, if a 50×100-pixel image is to be scaled to 75 pixels wide and the height is given as auto, the image’s rendered height would be 150 pixels. (The initial value for background-size, auto auto, renders images with their intrinsic dimensions, just as previous CSS levels would have rendered them.) Lengths have the obvious interpretation. Percentages are a little trickier to interpret because they specify that dimension relative to the corresponding dimension of the background positioning area (as CSS 3 calls it), hereinafter abbreviated BPA.

Aside: the background positioning area

The familiar CSS box model

For any background with background-attachment: fixed, the BPA is simply the whole browser window, not including space occupied by scrollbars. Otherwise, the BPA is determined by the background-origin property, whose possible values area border-box, padding-box, and content-box. (As this property isn’t finalized, and as Gecko’s support predates these specification names, for now the property in Mozilla is -moz-background-origin and its values are border, padding, and content.) padding, the default, is the light purple and white areas of the above diagram: the content plus the area occupied by padding. border is the outermost rectangle: content plus padding plus border. content is just the content, without padding or border.

Returning to background-size itself, we have two remaining syntaxes:

background-size: contain;
background-size: cover;

These syntaxes allow you to scale the image relative to the smaller or larger of the width and height of the BPA, even if you don’t know beforehand which is smaller and which is larger (or if you don’t know the same about the background image, although this seems less common). Stated more simply but less precisely, contain means, “Stretch this image until the BPA’s dimensions exactly contain it”. cover means, “Stretch this image until it covers the entire BPA’s dimensions.” Of course, if you know the element whose background is being set is always taller than it is wide (or vice versa), these keywords aren’t necessary, but when that’s not the case the extra functionality of these keywords is invaluable.

Examples

Regrettably, WordPress seems to strip unrecognized CSS properties, so you’ll have to click through to view the examples. This demonstration of background-size: cover and this demonstration of background-size: contain are meant to be opened in new windows so that you can see how contain and cover behave when the BPA’s width-to-height ratio is less than or more than one. Finally, this series of demos of how background-size works and interacts with other background-* properties should pretty much cover the remaining ground in how to use background-size alone and in conjunction with other properties. Unfortunately, for reasons listed below, these examples are Gecko-only (or, if such engines exist, they work in any engine which implements the background properties without prefixes) for the moment.

Keeping it short

Many of the background-* properties can be specified by the background shorthand. Eventually, background-size may be one of them; however, due to the partially-conflicting need to also support background-position in the shorthand and the ongoing unresolved discussions on the www-style list over how to address this, Gecko currently doesn’t support specifying background-size within the background. (Other browsers seem to be taking a similar approach to supporting background-size in the background shorthand.) Once this aspect of the spec becomes more stable we’ll add it, but for now we’re not including it in case the spec has more changes in this respect.

Browser support

Full support for -moz-background-size is now in the mozilla-central repository, and it will be in Firefox 3.6. Yay! However, web authoring features are generally useful primarily to the extent that multiple browsers support them in the same manner. Sadly, other browsers have varying levels of support for background-size (none as part of the background shorthand and none in unprefixed form, which is of course the same as Gecko now implements it).

Internet Explorer

Internet Explorer doesn’t support background-size in prefixed or unprefixed form.

WebKit

WebKit-based browsers support the property through the -webkit-background-size property. They have full support for an explicitly specified width and height. However, it appears that support for just a width, leaving height implicit, is based upon a roughly year-old draft of CSS 3 backgrounds that has different behavior from the latest draft. (A note to would-be early adopter web developers: this is one reason why Mozilla sometimes holds off on implementing features that are part of a working draft; implement it when it’s too new and you’ll find the carpet pulled out from underneath you. [Edit: To be clear, this particular change wasn't a carpet-pull; a pure painting change like this one probably wouldn't be. Modifications of features which interact with more complicated concepts like positioning, however, are still much more likely to have complex interactions that make substantial changes more likely. Also to be clear, this isn't a complaint about other browsers implementing things like this early; they can implement whatever they want, whenever they want, especially in CSS through the vendor-prefix mechanism. It's simply pointing out that a browser runs a risk of implementing something substantially different from the finalized form, which is also a potential, if perhaps small, source of confusion for web developers.]) Thus, instead of preserving proportions when only one value is specified, it applies the single value to both dimensions (-webkit-background-size: 50% is deemed equivalent to -webkit-background-size: 50% 50%, not to -webkit-background-size: 50% auto). WebKit-based browsers also don’t support the contain and cover keywords, apparently for the same reason.

Opera

Opera’s support appears very experimental at the moment. It lacks contain/cover support, but more oddly, specifying two values seems to treat the first as an aspect-preserving scale factor and the second as a vertical clipping dimension that also causes a non-repeating image to repeat in the vertical direction (!). Also, its determination of the BPA for fixed backgrounds appears wrong (vertical percents resolved with respect to the full height of a page, not with respect to the browser window size).

(If I had to guess, I’d bet the non-repeating image becoming repeating is due to swapping the “clipY” and “scaleY” arguments in a call to an image-scaling, -tiling, -clipping Swiss army knife function. If any Opera developers are reading, I’d be intrigued to hear what the mistake actually was after you’ve investigated it, because I don’t see an obvious explanation.)

But don’t panic!

Support may be spotty, but the differences in other browsers are probably not difficult to fix. With respect to the non-keyword forms, it should be fairly simple for browser vendors who partially implement background-size to adjust their code to match the latest working draft. contain and cover are probably more difficult (because they change the scale-storage from a pair of numbers to something conceptually larger), but they should still be reasonably straightforward. I’ll bet the other browsers can and will make the necessary fixes before their next releases.

Acknowledgements

Historically I’ve worked on very little layout code in Gecko (and nothing which changed rendering), and I needed advice and help from a handful of different people to implement this. As always, bz, dbaron, and roc were extremely helpful in answering questions, pointing out my occasional stupidities, and reviewing versions of the patch. I also understand that I owe a debt of thanks to Mozilla’s image and graphics maintainers for relatively recent changes which made the process of scaling an image for use in background-size extremely simple. Thanks everyone!

As in the past when I’ve implemented browser features, I implemented background-size to scratch an itch: using an image as the background of my own site and having it fill the browser window. The behavior prescribed by CSS for painting backgrounds is intricate, and I had to keep careful track of the details, but neither the code itself nor the changes I made were difficult to understand. Hacking layout features isn’t something only seasoned Gecko hands can do: other people with no prior knowledge of Gecko have done the same in the past when they needed something that wasn’t already implemented. If you’re a web developer in need of more CSS hotness, we’d love to help you implement it! Hop on Mozilla’s IRC server, irc.mozilla.org, and ask questions in the #developers channel; we’re always willing to answer any questions you might have about Gecko code or the development process.

With that, web developers, enjoy the new toy — I certainly will!

source: developer.mozilla.org

The original Gmail notifier for multiple accounts. Allows you to receive new mail notifications along with viewing account details including unread messages, saved drafts, spam messages, labels with new mail, space used, and new mail snippets.

What are the advantages of using web standards?

Accessibility

To software/machines

Complying with web standards can give your web pages greater visibility in web searches. The structural information present in compliant documents makes it easy for search engines to access and evaluate the information in those documents, and they get indexed more accurately.

Because use of web standards makes it easier for server-side as well as client-side software to understand the structure of your document, adding a search engine to your own site becomes easier and gives better results.

Standards are written so that old browsers will still understand the basic structure of your documents. Even if they can’t understand the newest and coolest additions to the standards, they’ll be able to display the content of your site. The same, of course, applies to robots – systems that collect information from your site on behalf of search engines and other indexers.

Compliant code gives you the opportunity of validating your page with a validation service. Validators process your documents and present you with a list of errors. This makes finding and correcting errors a lot easier, and can save you a lot of time.

Compliant documents can easily be converted to other formats, such as databases or Word documents. This allows for more versatile use of the information within documents on the World Wide Web, and simplified migration to new systems – hardware as well as software – including devices such as TVs and PDAs.

To people

Accessibility is an important idea behind many web standards, especially HTML.

Not only does this mean allowing the web to be used by people with disabilities, but also allowing web pages to be understood by people using browsers other than the usual ones – including voice browsers that read web pages aloud to people with sight impairments, Braille browsers that translate text into Braille, hand-held browsers with very little monitor space, teletext displays, and other unusual output devices.

As the variety of web access methods increases, adjusting or duplicating websites to satisfy all needs will become increasingly difficult (indeed, some say it’s impossible even today). Following standards is a major step towards solving this problem. Making your sites standards-compliant will help ensure not only that traditional browsers, old and new, will all be able to present sites properly, but also that they will work with unusual browsers and media.

Some consequences of ignoring standards are obvious: the most basic consequence is that you will restrict access to your site. How much business sense does it make to limit your audience to only a fraction of those who wish be a part of it? For a business site, denying access to even small portions of a target audience can make a big difference to your profit margin. For an educational site, it makes sense to allow access not only to affluent, able-bodied school-children with graphical browsers, but also to children in regions with poorly-developed infrastructure who are best served by text-only browsing, or disabled students using specialized browsers.

The same principle applies to all types of websites — while straying from the standards and taking advantage of browser-specific features may be tempting, the increased accessibility which comes from standards-compliance will lead to far greater rewards in the long run.

Stability

Most web standards are generally designed with forward- and backward-compatibility in mind — so that data using old versions of the standards will continue to work in new browsers, and data using new versions of the standards will “gracefully degrade” to produce an acceptable result in older browsers.

Because a website may go through several teams of designers during its lifetime, it is important that those people are able to comprehend the code and to edit it easily. Web standards offer a set of rules that every Web developer can follow, understand, and become familiar with: When one developer designs a site to the standards, another will be able to pick up where the former left off.

Conclusion

As web developers, we are constantly trying to address the problem of inconsistencies between the renderings of web pages by different browsers and browser versions. This necessitates either time-consuming double/multiple coding, or coding for a single browser which makes it harder, if not impossible, for some of the public to use the site. This situation will be made even worse with the advent of additional hardware and software which will be able to browse the Web, such as telephones, pagers, and PDAs.

Web standards are not arcane laws decreed by ivory-tower organizations. As we have described, the standards are for the most part decided by representatives of the same people who use them — browser makers, web developers, content providers, and other organizations.

Writing web pages in accordance with the standards shortens site development time and makes pages easier to maintain. Debugging and troubleshooting become easier, because the code follows a standard. No longer do you have to worry about the coding and maintenance for several versions of code that are supposed to accomplish the same presentation. One version of your site, and that is it.

The universal adoption of web standards is becoming of paramount importance. The mission of The Web Standards Project is to make the Web a better place, for developers and for end-users, by encouraging browser and web page editor makers to follow the standards in their applications. This effort will be greatly helped when web developers use the standards as a matter of course, and insist that generators and renderers of their code comply with the standards.

The reasons we have given should give you, the web developer, plenty of incentive to begin using standards, and also plenty of ammunition with which you can encourage your place of business and fellow developers to use those standards.

The Web is evolving fast: new features, formats, user needs, continuously change the way we interact with websites. In this post I want to suggest you some interesting emerging techniques every web developer should know in order to build modern web applications.

HTML 5 Offline Application

The HTML 5 specification introduces a lot of new features that radically improve the way users interact with websites and web applications. With HTML 5 developers can build easily offline web applications by using a SQL database API and an offline application caching API for storing data locally (by using a client-side SQL database) and allowing applications are available even when users are offline. This technique use a .manifest file and JavaScript to get an update of the cached files when is not available a connection to the server.

You can enable offline application caching by using the manifest attribute on the html tag:

<!DOCTYPE HTML>
<html manifest="cache-manifest">

You have to create a .manifest file that specifies which files are to be cached offline. Here is a typical structure of a manifest file:

CACHE MANIFEST
index.html
about.html
style.css
logo.png
...

NETWORK:
server.cgi

According to the W3C Working Group Note about Offline Web Applications topic, server.cgi should never be cached in order to continuously get updates from the server.

Apple Developer Connection provides a full detailed, step-by-step guide to help you learning how to buit modern offline web applications. You can read the full guide here.