web notes - a blog

This rewrite rule allows CSS requests to run through css.php, which can substitute color attritubes on the fly to allow a single application to be supported by multiple skins, and have greater immunity to cross-site scripting attacks.

RewriteEngine On

RewriteRule ^(.*)\.css$ css.php?d=$1

Key considerations:

• sed may be the best substitution strategy, instead of PHP, because it is probably faster, and little to no development would be required
• Caching should be done carefully to ensure the files are not recreated unnecessarily, and files that don’t exist should be created. If the source .css file has changed, the recolored one must be updated.
• One may use the REQUEST_URI to select the .css files
• Backend management of the .css file identifiers will be required if they are dynamic. This implies the ability of a user to be able to select colors and store the scheme. If they are fixed, it is simpler.
• This is not really intended for individual user customization and user experience, but to allow a single installation of an application to support multiple skins. With that in mind, it is assumed there would be a fixed set of .css files, with a default used in the event of an invalid file request, and the .css files would be managed manually by the design/engineering team.

It may be difficult for HR personnel to determine which web development candidates to interview.

Candidates for any web position should always submit URLs of their work and a description of their contribution to the project. If they don’t, either their work is not on the public net, or they are not proud of it. In the former case, they should have some web presence, a blog, or work they have done on the side, or even posts in a forum. In the latter case, there are many reasons a person may not be proud of their prior work. It may be the nature of the site - selling products that are controversial or working with a company that is not well-liked. If may be that the overall project was done poorly. Regardless, some demonstration of work should be required. Sample code may be the best solution, it allows the person to present their work and describe it. Often, the quality of their description and the enthusiasm are worth more than the technical discussion, for the initial interview.

The link above checks a web page for some common issues that can make page maintenance extremely expensive, and usually indicates a page that was not coded properly. It can be used to evaluate the work of ‘designers’ and ‘developers’ - people who are responsible for creating the visual presentation for a website. Unless an engineer claims full responsibility for the site, the above link should not be used to examine the page. Back-end/Internet/LAMP/PHP engineers should bring sample code.

To use the tool, enter the URL provided by the candidate and click ‘Go’. The tool will display the issues it found in the code. The final score is a reasonable indicator of the quality of the page.

This link will run the tool on http://wirehopper.com. This is an older page, and would be more difficult to maintain. You can see this with the final score of ‘Danger’.

The remaining sections of the check provide additional insight into the way the page was coded, but the rating system has not been established for them.

If a candidate submitted three URLs, and all were ‘Dangerous’ - in the absence of other outstanding qualities, they should not be considered further.

As is the case for any automated evaluation, this is not an absolute indicator. Entry level employees should be given some latitude, especially those who promptly admit their inexperience and appear eager to accept direction from more senior team members.

Never forget that the quality of web work, including the underlying code, is visible to all site visitors. It is vital that pages be coded well.

The link above scans a web page for common issues.

It is not a validator.

It allows you to very quickly identify the following:

• Use of deprecated HTML tags. This indicates the code on the page is either old or written by someone who is not up-to-date with their web skills
• Use of tables. Tables should only be used if there is tabular data displayed, or if the data really requires it. If you don’t see anything on the page that looks like it needs a table, the person that coded the page may not have a good understanding of divs and CSS layouts.
• Font style tags. CSS is far more powerful and most cost-effective to maintain for enhancing text.
• Use of deprecated HTML attributes. As with font style tags, these should be replaced with CSS equivalents.
• Use of inline style attributes. These may make a page very expensive to maintain.

Where possible, a link to a reference is given to help readers understand why the issue was reported.

This isn’t a comprehensive report, it can be used as a quick check for a page, to help you decide if you would like to examine the code further. The page may validate, but valid code doesn’t ensure a quality page that is cost-effective to maintain.

The URL scanned is not stored, the page content/text is not stored.

The link above provides a nice hover effect, done with CSS and a tiny bit of javascript.

The approach is to use two divs. The outer or container div has a background image assigned through CSS. The inner div contains the text, and is hidden (display:none) on page load. The inner div uses a white background, with opacity to mute the background image and make it easier to view the image.

On hover, the inner div is changed to display:block.

Both divs have an id and class. The outer div id is required to assign the background image, the class is used to set float:left, and any other common attributes. The inner div id is used to identify it in the javascript, so the display attribute can be controlled, and the class is used to describe and position the text and opacity.

The code was written to run within a loop, hence the 1 on the ids.

Tricks for debugging web pages under IE, if you don’t have any tools.

• Comment out all but the code that doesn’t work. Often the code that’s not working is broken because of something else.
• Have a separate CSS file, just for IE
• Use alert to halt javascript execution. This lets you see which command was executed prior to the failure.
• If you have a complex page, use View Source, then paste the text into a file under vi. Use grep “<div” | wc -l, and grep “</div” | wc -l to count the number of open and close divs.
• If you are using a template language such as Smarty, hard-code values for quick tests.
• Be sure to clear the cache, aka delete the temporary Internet files. Otherwise, CSS and javascript changes may not take effect.
• Refer to w3schools.com to check for supported attributes for various browsers.
• Be creative. If .style.display=’none’ doesn’t work, try removing the node.
• Limit the versions of IE you will support, and alert the user. IE6 is a good starting point.
• Accept some problems. For example, IE6 and Apache sometimes have trouble with .png transparency. Either make those images a different filetype, or allow them to display as the server delivers them and the browser displays them. It is not worth striving for perfection to support software that will eventually become obsolete.
• Use server-side logic to deliver the best code for the browser. Again, this should be limited to that which is absolutely necessary, but it is often easier to prepare the page well on the server, than to adjust it once it has been delivered to the browser.
• Use FireBug. It is bundled with dojo, and probably available as a stand-alone component.