The front end of a website is composed of three layers. A layer of architecture built by XHTML that includes structured and semantically labeled tags, as well as the content of a Web site. You can add a presentation layer (CSS) and a Behavior layer (JAVASCRIPT) above this layer to make the site look prettier and more user-friendly. These three layers should be kept strictly separate. For example, there should be the possibility that you can rewrite the entire presentation layer without touching the structure and behavior layers at all.
In addition to this strict separation, both the presentation layer and the behavior layer require instructions from the structure layer. They must know where to apply styles and when to initialize behavior--in other words: they need triggers.
CSS triggers are well understood by everyone. Class and ID attributes allow you to completely control the performance of your site. However, you can work without using these triggers by using inline style attributes, which are written in the style= "..." attribute in the XHTML tag, but this usage should be strongly objected to. When you want to redefine the performance of the site, you will be forced to break even the XHTML structure layer. Their presence destroys the separation between performance and structure.
JavaScript triggers
The behavior layer should also be able to work in the same way. By discarding the use of inline event handlers (such as onmouseover= "switchimages" (' Fearful ', 6,false)), we can separate behavior from structure. Like CSS, we should use triggers to tell the script where to deploy the behavior.
The simplest JavaScript trigger is the id attribute.
<div id= "Navigation" > <ul> <li><a href= "#" >link 1</a></li> "<li><a href=" # ">link 2</a></li> <li><a href=" # ">link 3</a></li> </ul></div> var x = document.getElementById (' navigation '); if (!x) Return;var y = x.getelementsbytagname (' a '); for (Var i=0;i< y.length;i++) Y[i].onmouseover = Addbehavior;
As a result, the script is triggered by the presence of id= "navigation". If there is no id= "navigation", then nothing happens (if (!x) return), and if it does, then all the link elements that surround it (a tag) will get a mouseover behavior. This solution is simple, elegant, and works in all browsers. If this approach already meets your needs, then you don't need to read it anymore:
Advanced triggers
Unfortunately, in some cases you cannot use IDs as triggers:
An ID can only appear once in the document, and sometimes you may want to add the same behavior to several (or a group) of elements.
In some cases, the script needs more information than simply pointing out "deploy here" (translator: For example, passing some parameters).
We use the form script as an example of the above two questions. Adding a form validation trigger to XHTML is useful, such as specifying "This input field (translator Note: text input box, password input box, etc.) is required". In order to implement such a trigger, we are likely to get the following script:
function Validateform () {var x = document.forms[0].elements; for (var i=0;i<x.length;i++) {if ([this input field is required] && !x[i].value)//notify User of Error}
What triggers do we need to create to tell the script which input fields are required? It's obviously not possible to use IDs: the ideal solution should work on a whole host of input domains. It's natural to think about whether you can use class to trigger behavior:
<input name= "name" class= "Required"/>if (x[i].classname = = ' Required ' &&!x[i].value)//Prompt user to enter this field
However, strictly speaking, the class attribute is used to define a CSS trigger. It's not impossible to put CSS and JavaScript triggers together, but doing so is likely to confuse the code:
<input name= "name" class= "Largefield required"/>if (X[i].classname.indexof (' required ')!=-1 &&!x[i].va Lue
In my opinion, the class attribute should only be used for CSS. Class is the primary trigger for the XHTML presentation layer, and it complicates the problem if it is allowed to host information about the behavior layer. Using the class attribute to trigger two layers at the same time is inconsistent with behavior and performance separation, but it is up to you to decide what to do.
Information delivery triggers
In addition, triggers can become more complex, not just a command that declares "deploy here (behavior)". Sometimes you might want to add a variable to the trigger so that the behavior layer becomes more generic, and you can respond to the needs of each XHTML element, rather than executing a standard script foolishly.
Take a form for example, this form includes some text input boxes with a maximum string length. The original maxlength attribute is no longer working on the TEXTAREA element, so we have to write a script to do it. In addition, not all text input boxes in this form have the same string length caps, so it is necessary to store their own upper bound lengths somewhere.
We want to have a thing like this:
var x = document.getelementsbytagname (' textarea '); for (Var i=0;i<x.length;i++) {if ([This text input box has a length limit]) x[i].onkeypress = Checklength;} function Checklength () {var max = [value of read length]; if (This.value.length > Max)//notify User of Error}
This script requires two key pieces of information:
Does this text input box have a length limit? This is a very general trigger that tells the script that some of the actions should be added here.
What's the ceiling? This is a value that allows the script to correctly check user input.
Here, it is no longer appropriate to use a class based approach. Although technically not impossible, the required code becomes too complex. For example, let's give a text entry box with a class called "large" with a trigger to tell the script that it is required and that the length limit is 300:
<textarea class= "Large required maxlength=300" ></textarea>
This not only mixes the presentation layer with the behavior layer, but also the script used to read the value becomes more bizarre:
var max = this.className.substring (this.className.indexOf (' maxlength ') +10); if (This.value.length > Max)//reminding the user of an error.
It's easy to notice that this script only works when we put Maxlength=x on the last one. If we want this script to be able to handle not the last maxlength=x (this is often the case, like we want to add a trigger with a value), it becomes more complex.
The problems facing
This is the problem we are facing now. How can I add perfect javascript triggers so that we can easily pass the general declaration ("Deploy behavior here") to the script along with the value for the element?
Technically, it is possible to add this information together to the class attribute, but is the class designed to do this?
Custom properties
I turn to another solution. Let's take a look at the example of the textarea length limit mentioned earlier. We need two pieces of information:
Does this text input box have a length limit?
What's the ceiling?
Expressing this information in a natural, semantically way requires adding a custom attribute to textarea:
<textarea class= "Large" maxlength= "></textarea>"
The MaxLength property notifies the script to check the user's input and pass the length cap to the script through the value of the property. Similarly, we can change the "required" trigger to a custom attribute. For example: Required= "true", regardless of the value assigned to it can be, because it is only the role of a notification, without any additional information.
<textarea class= "Large" maxlength= "a" required= "true" ></textarea>
Technically, there is no problem in doing so. The GetAttribute () method of the Consortium DOM can read the values of any property from any one label. Only 7.54 editions of the previous opera did not allow reading of an error attribute (such as SRC) from a label such as
Here's my solution:
function Validateform () {var x = document.forms[0].elements; for (var i=0;i<x.length;i++) {if (X[i].getattribute (' req Uired ') &&!x[i].value)//notify user of error}}var x = document.getElementsByTagName (' textarea '); for (Var i= 0;i<x.length;i++) {if (X[i].getattribute (' maxlength ')) x[i].onkeypress = Checklength;} function Checklength () {var max = This.getattribute (' maxlength '); if (This.value.length > Max)/notify User of Error }
In my opinion, this approach is easy to implement and is consistent with JavaScript triggers: A pair of "variable name/value" provides the name of the trigger and the value required by the script, while allowing you to define the behavior for each individual element. Finally, this way of adding triggers to XHTML is also fairly straightforward for beginners.
Custom DTD
But there's another problem here, and pages made with this kind of solution can't pass the checksum. The inspector considers required and maxlength illegal. The inspector is absolutely right to do so, there is no previous attribute in XHTML, and the latter attribute is only a <input> element.
The solution is to make them legitimate: Define a custom Document type definition (DEFINITION,DTD), and make XHTML a small extension that contains the attributes we define. This custom DTD defines the correct location of the new attributes that they should appear before, and the validator verifies the document according to our custom XHTML flavors. If the DTD says these attributes are correct, then they are correct.
If you do not know how to create a DTD, read this j.david Eisenberg published "Create a Custom DTD" (Translator note: See everyone's opinion before deciding whether to translate ^_^), in this article he will tell you all you want to know.
In my opinion, using custom attributes to trigger the behavior layer--together with custom dtd--that make these attributes legitimate--can help us separate the behavior layer from the fabric layer while maintaining concise code and efficient scripting. In addition, once you have defined these attributes and scripts, even the most novice can easily add triggers to the XHTML document.
