HTML Tags

HTML consists of tags—special directives that let the browser know how you want elements on the page to display. HTML tags are enclosed within angle brackets (< >). For example, at the very beginning and the very end of an HTML page, you would have the <HTML> and </HTML> tags, respectively. By convention, tags that require a start tag and an end tag (as the <HTML> tag does) are identical except for the leading slash (/) in the end tag. Within the <HTML></HTML> tags, every HTML page should have <HEAD></HEAD> tags and <BODY></BODY> tags. The <HEAD></HEAD> tags can contain <META> tags, which can offer hints of what the page will be displaying. (<META> tags are useful for automated tools that roam the Web looking for pages to include in search engine results.) The <TITLE></TITLE> tags mark the beginning and end of the title of the page. This title will appear in the browser's title bar.

Note Although most people capitalize the text in HTML tags, HTML isn't case sensitive. This is one of many contrasts between HTML and the newer, but related by heritage, Extensible Markup Language (XML), which is case sensitive. With the exception of the <META> tag, all the tags mentioned so far are always used in pairs, with a start and an end tag. Some tags don't require an end tag. The most common is the line break tag, <BR>. With some tags, the end tag is optional. For example, some folks don't use the end tag for the paragraph tags, <P></P>.

HTML Links

HTML allows you to create links, also known as hyperlinks, within your pages. A link enables you to jump from one page to another. These links are marked by <A></A> tags. For example, to create a link on a page that will enable you to jump to a page named test.aspx, you would use code like this:

To get to test.aspx, <A HREF="test.aspx">Click Here</A>

The Click Here link would appear on most browsers as underlined text, although you can control and modify exactly what links look like. Generally, changing what a link looks like isn't a good idea. Users have grown to expect that underlined words and phrases allow them to jump to another page, so working against that expectation can lead to frustration and confusion. The <A> tag is unusual in that it can be used as a link, as in the example here, or as an anchor that defines a named section of a document. If the name of an anchor is appended to a URL, the browser will jump to the anchor of that name. If the <A> tag has an HREF attribute, it is a link. If the <A> tag has a NAME attribute but not an HREF, it is an anchor. If both NAME and HREF attributes are present, the tag is both an anchor and a link.

If you wanted to jump to another page but also pass in an argument that could be used inside the page, you could use the following code:

To get to test.aspx, <A HREF="test.aspx?arg=1">Click Here</A>

To pass multiple arguments to a page, the same syntax is used, but with an ampersand between arguments, like this:

To get to test.aspx,

<A HREF="test.aspx?arg1 = 1&arg2=2">Click Here</A>

HTML Widgets

HTML provides text boxes, drop-down lists, list boxes, check boxes, and radio buttons. Although ASP.NET uses slight variations on these widgets, understanding how the base HTML widgets are used is helpful. To get an idea, take a look at Listing B-1. Listing B-1 HTML listing showing the use of common HTML widget

HTML Widgets

HTML provides text boxes, drop-down lists, list boxes, check boxes, and radio buttons. Although ASP.NET uses slight variations on these widgets, understanding how the base HTML widgets are used is helpful. To get an idea, take a look at Listing B-1. Listing B-1 HTML listing showing the use of common HTML widget

<TITLE>Example HTML Widget Page</TITLE>

What follows is a form. <B><I>This text is outside the form.</I></B>

<FORM action="appendixb.htm">

This is a text box. The <I>value</I> attribute means that there is a default value for this text box:

<INPUT type="text" id=text1 name=text1 value="Hello HTML"><BR>

This is a text box that displays "*" for each character, commonly used as a password entry box:

<INPUT type="password" id=password1 name=password1><BR> This is a text area. I have set the rows to 2, and the columns to 20: <TEXTAREA rows=2 cols=20 id=textarea1 name=textarea1> </TEXTAREA><BR>

This is a check box:<INPUT type="checkbox" id=checkbox1 name=checkbox1><BR>

This is a group of radio buttons:<BR>

<INPUT type="radio" id=radio1 name=radiotest>Yes?<BR>

<INPUTtype="radio" id=radio2 name=radiotest>No?<BR>

This is a drop-down list:<SELECT id=select1 name=select1>

<OPTION>Option 1</OPTION>

<OPTION>Option 2</OPTION>

<OPTION>Option 3</OPTION>

<OPTION>Option 4</OPTION>

This is a list box. This is a multi-select list box, because the "multiple"

directive is inside the &lt;SELECT&gt; tag.

<SELECT size=3 id=select2 name=select2 multiple>

<OPTION>Option 1</OPTION>

<OPTION>Option 2</OPTION>

<OPTION>Option 3</OPTION>

<OPTION>Option 4</OPTION>

<INPUT type="submit" value="This is a Submit button" id=submit1 name=submit1>

Notice first the general structure of this simple HTML page. Surrounding everything are the start and end <HTML></HTML> tags. Inside the <HTML></HTML> tags are <HEAD></HEAD> tags, which contain <TITLE></TITLE> tags. Next are the <BODY></BODY> tags, which contain the HTML code that will drive the browser's display.

In the text at the top of the <BODY> section, I've used <I></I> and <B> </B> tags to create italic and boldface text. Notice that the end tags for the italic and boldface text are properly nested. Although current browsers generally will accept HTML code in which the start and end tags of such blocks aren't nested, it's a good idea to properly nest your tags.

All the widgets are contained within <FORM></FORM> tags. HTML widgets outside a form are of no value and generally won't do what you want them to do. A <FORM> tag can also contain an attribute describing what action to take when the form is submitted as well as a method attribute to specify how the information from the form is transmitted to the server. The method attribute can be one of two values, Post or Get. The Get method is the default; however, Get is deprecated in HTML 4 because of internationalization problems. The Post method is a two-step method (transparent to you, as the developer of the page) that sends all the information entered in a form to a standard location, where the server reads it. The Get method appends the form contents to the URL as arguments. For example, if a form has a single text box, name, that contains the value "Doug", and if the form is using the Get method and the action is a page named test.aspx, this is the resulting URL that will next appear in the browser's location window (barring any processing error):

http://<host>/<directory>/test.aspx?name=Doug

So which method is best to use—Post or Get? As is often the case, there's no simple answer. For small forms with little data being passed back and forth, Get can be more efficient. For larger forms, some servers will break if the URL is too long, and so it's often best to use Post. In addition, if you're sending a password back from the form, you should use Post so that the password won't appear in the URL as plain text. Each widget is fairly self-explanatory once you've seen the code in Listing B-1 and then the resulting browser screen, shown in Figure B-1. For the text box, I've provided a default value for the control. In virtually all cases, the value attribute in an HTML control determines either what is initially displayed or what is returned when the widget is selected and the form is submitted. The ASP.NET controls use a more Visual Basic-like structure, so the Text property of a control maps to the HTML value attribute. Some users may not like the fact that the ASP.NET objects have properties with different names than the HTML attributes they are mapped to, but Visual Basic programmers should feel comfortable with the ASP.NET objects.

Also, in the description of the list box, I wanted to display the text "<SELECT>". Rather than using that literal, I used &lt;SELECT&gt;. If I'd used less than and greater than symbols (< or >), <SELECT> would have been interpreted as the beginning of a list box, which isn't what I wanted.

X— 'rv^ r., ji I**.

£3

f

■* J J 3 jU'iwha J*» > .J- _1 J -

•k

■J fli» kH* "

'¿flud i e» A fete r*in JrirJ id .<ut>i.ir thrform.

ri ■ Itrtfl !.-.* Ibr VusW luri IIKII Li m itlmt vdx l-.f du kil In« [HwHM^^™

TUj uiHi t-:«tfjc -3tja" I« <iixb chaMHf.ii/amctir<tf*4 a ijmswiitirt t*i

'¿flud i e» A fete r*in JrirJ id .<ut>i.ir thrform.

ri ■ Itrtfl !.-.* Ibr VusW luri IIKII Li m itlmt vdx l-.f du kil In« [HwHM^^™

TUj uiHi t-:«tfjc -3tja" I« <iixb chaMHf.ii/amctir<tf*4 a ijmswiitirt t*i

^Ni1

Belli*!™ Ihiilim* iihtkt>.t«HfaWpP4BIOI lit I'"«:" ¡2j

Figure B-1 : The results of displaying the HTML from Listing B-1 in Microsoft Internet

Explorer

Many more character entity references that enable you to display special characters within the HTML stream are available. One of the more common character entity references is &nbsp;, which creates a nonbreaking space. This reference can be useful if you want to force some text to be displayed on a single line without a line break—for example, the first and last name in a proper name such as "George Washington". You can test for where line breaks might occur, but for a variety of reasons, the breaks might not occur on one browser in exactly the same place as on other browsers. For example, the fonts selected by one browser on one machine might not exactly match what another browser on another machine selects.

HTML Tables

One of the maddening things about HTML is just how flexible it can be and how forgiving many browsers are about sloppy HTML. The flip side of that flexibility is that other browsers are not so flexible, and so code that's not exactly correct might perform well in one browser yet produce nothing in another. One area in which it's easy to misuse HTML is with HTML tables.

If you use Microsoft Word, you might be familiar with the powerful table features. I've never done any serious work in the financial areas most often associated with tables, but I've used tables extensively to properly format many different types of documents, including some of the text for this book. Tables can be useful when you're using variable-pitch fonts and trying to get more than a single column to align. "But wait," you say, "I don't need to do that in my ASP.NET application." Well, I think you might.

As you've seen, the underlying metalanguage used to describe the user interface in an ASP.NET application is different from what you'd expect in a standard Visual Basic application. In addition, the underlying assumptions about what you can do and what the metalanguage was designed to convey are also quite different. In a Visual Basic application, you might drop a widget in a particular location and expect that it will always appear exactly there on any machine that runs the application. HTML is different. Remember, HTML was designed as a markup language that basically gave hints to the browser as to the location of various text and widgets. The browser was free to render these components as best it could, using widgets native to the underlying operating system to render an approximation of what you laid out. Unlike in Visual Basic, there's no convenient way in HTML to use absolute positioning to exactly locate a text box at, say, 1 inch below and 2 inches to the right of the upper left of the screen. Dynamic HTML (DHTML) and style sheets offer greater control over positioning, but not all browsers in use today support all the same DHTML syntax; even where the syntax is compatible, the results are often not identical across different browsers.

Look again at Figure B-1. Even though the underlying HTML text might be formatted in a particular way, with indentation and line breaks to allow the listing to appear correctly in this book, the browser simply ignores all formatting I implicitly add with indenting and line breaks, and uses only those directives it understands—in this example, <BR> tags.

What if I wanted the form to line up more like what appears in Figure B-2? In this case, all the text is conveniently aligned on the left, and all the widgets are lined up on the right.

LUj U «Icm toi "JL= MM JOTft Ar Lzin J Î^l bir i£ i jjLf ti l^u initie

Th" H tira twrCH ijf r*ih

[hxiilr:, : wr.—.■ rly -ir^i h m paaiwcr^ it£-v [

hi a., d ileu LLrfV WlfctlCWI I Ï.JfttfliF

Thru Ii* I

n-i(. u * kit!-, s Tbl "J P ff#L£,(.ftfi r kit Ml boruiir fix 'ca-iç-J-' trïtrr- lu ulr Ûr

r HaJ

Figure B-2 : The results of displaying the HTML from Listing B-2 in Internet Explorer, using a table to format the form

Listing B-2 shows how this alignment was accomplished, but in short, the answer is HTML tables. The <TABLE> tag marks the beginning of an HTML table. In Figure B-2, it's not obvious that a table was used because no table border is showing. (Many attributes can control the display of tables, and I encourage you to look at a book dedicated to HTML for more information on this subject.)

Listing B-2 HTML listing showing the use of common HTML widgets and HTML tables

<TITLE>Example HTML Widget Page with Tables</TITLE> </HEAD>

What follows is a form. <B><I>This text is outside the form.</I></B>

<FORM action="appendixb.htm">

<TABLE width=100%>

This is a text box. The <I>value</I> attribute means that there is a default value for this text box:

<INPUTtype="text" id=text1 name=text1 value="Hello HTML"><BR> </TD> </TR> <TR> <TD>

This is a text box that displays "*" for each character, commonly used as a password entry box:

<INPUT type="password" id=password1 name=password1><BR> </TD> </TR> <TR> <TD>

This is a text area. I have set the rows to 2, and the columns to 20:

<TEXTAREA rows=2 cols=20 id=textarea1 name=textarea1> </TEXTAREA><BR> </TD> </TR> <TR> <TD>

This is a check box:

<INPUT type="checkbox" id=checkbox1 name=checkbox1><BR> <ITD> <ITR> <TR> <TD>

This is a group of radio buttons:

<INPUT type="radio" id=radio1 name=radiotest>Yes?<BR> <INPUTtype="radio" id=radio2 name=radiotest>No?<BR> <ITD> <ITR> <TR> <TD>

This is a drop-down list: <ITD>

<TD> <SELECT id=select1 name=select1> <OPTION>Option 1<IOPTION> <OPTION>Option 2<IOPTION> <OPTION>Option 3<IOPTION> <OPTION>Option 4<IOPTION> <ISELECT><BR> <ITD> <ITR> <TR> <TD>

This is a list box.

This is a multi-select list box, because the "multiple" directive is inside the &lt;SELECT&gt; tag. <ITD>

<TD> <SELECT size=3 id=select2 name=select2 multiple> <OPTION>Option 1</OPTION> <OPTION>Option 2</OPTION> <OPTION>Option 3</OPTION> <OPTION>Option 4</OPTION> </TD> </TR>

<TR align=center> <TD colspan=2>

<INPUTtype="submit" value="This is a Submit button"

id=submit1 name=submit1> </TD> </TR> </TABLE> </FORM> </BODY>

Each row of the table is enclosed within <TR></TR> tags. These table row tags have additional attributes to control the background color, alignment, and other properties. Within each row, <TD></TD> tags control the individual columns of the row. To align the widgets in the second column starting in the middle of the page, I set the width attribute of the <TD> tag to 50%, meaning that the first column will take up 50 percent of the table, and because the table has only two columns, the second column will take up 50 percent of the table as well.

The last row of the table is different: it will contain only the single Submit button. To center this button in the table, I use another special attribute of the <TD> tag, the colspan attribute. In this case, I specify that the first column of this row will span two columns, meaning that it will take up the entire row. Using colspan and the related <TR> attribute rowspan, complex formatting can be accomplished in a way that retains the browser independence that's the hallmark of a good Web application. In addition, the align attribute of the <TR> tag is set to center, meaning that the contents of the row will appear centered. The <CENTER></CENTER>tags also enable centering, but the align attribute of the table row or column can be more convenient.

One problem with HTML tables is that if you omit an end tag or perhaps nest the tags improperly, the results vary depending on the browser in use. Internet Explorer will generally render the table correctly, albeit more slowly than a correctly formed HTML table. Netscape Navigator 4 and earlier might not display the table. Thus, while tables are almost essential to properly laying out the user interface for your ASP.NET application, they can be a source of some difficulties.

Note Other techniques are available for tricking HTML into laying out a document or form exactly as you want. One common way is to use invisible images sized to force text, graphics, and widgets to appear exactly where you want them to be. This approach isn't something I've found especially useful. In addition, in some examples in this book, I don't use tables to pretty up the display if the result is to obscure the underlying program logic. That said, in the real world, virtually every page I create has a specific structure that involves the extensive use of tables.

0 0

Post a comment