* course text, chapter 2, and chapter 6 sections 6.1 and 6.2, are a NICE "strict" HTML5 intro for basics and forms; hyperlinks! * a element - a for ANCHOR with an href attribute whose value is where the hyperlink should lead that destination can be expressed as a relative file name (relative to the location of the containing page) OR as a URL This is a link to <a href="http://www.w3c.org"> W3C</a>. * style: use link text that DESCRIBES the page being linked to; line breaks -- <br /> * class style: use <br/> <br /> lists! (these are block-level) * unordered list ul ordered list ol definitions list dl both and ul and ol: the list items are li elements but definition lists, dl element, contain dt elements for the terms being defined, and dd elements for the definitions you can nest these * there are ways to express special characters usually either by a unicode or a symbolic means; < for the plain < characters when you DON'T mean opening a tag! & is an ampersand...! * for content where you just want the line breaks you typed, use the pre element for "short snippet" of code, the code element is preferred, but does NOT preserve spaces and line breaks -- for blocks of code, this is a good idea: <pre><code> for (int i=0; i<3; i++) { cout << "Hello world!" << endl; } </code></pre> tables... * appropriate for tabular data * table element tables tend to have rows, put in tr elements, and rows are made up of table data, td elements, and table headers, th elements you CAN use a caption element -- right after the table start tag -- to indicate the caption of a table; td and th elements can have rowspan and colspan attributes to indicate a column that spans multiple rows or a row that spans multiple columns FORMS! URL browser/client --------> web server/application HTML+ browser/client <-------- web server/application form data browser/client ---------> web server/application ^ |---> data server response/output browser/client <-------------- web server/application * so -- since we're going to be using a web interface on the client tier in our particular n-tier applications, we'll be using HTML forms frequently on the client tier; * [course text, p. 206] "An HTML form is a group of controls that allows a user to submit information to a web server" * make sure you note: only control elements WITHIN a form element are "part" of that particular form instance...! * the form, when submitted, may provide query parameters to the application tier -- name=value pairs, if you will -- when these are transmitted using a method of "get", you actually see these at the end of the URL: ? then name=value pairs separated by & http://www.google.com/search?q=miserable+failure&start=10 form element: * numerous optional attributes, but one required attribute: action attribute, whose value is the web server's target URL to which the form data should be submitted <form action="http://blah"> </form> * if you don't have a method attribute, a method of "get" looks like the default, and that's when you get the query parameters at the end of the the action URL when the form is submitted (use method value of "post" when you'd like that information sent "separately") some form controls: * a submit! (because a CS 318 code style standard is going to be (at least until we get to Ajax...) that ALL forms should have at least one submit button!! the input element is used for SEVERAL controls; ...you indicate which with a type attribute (if you omit, you get a single-line textfield) <input type="submit" /> * want different text than the default? set the value attribute to the desired label text * typically a submit button doesn't NEEED to send a name=value pair, SO they don't typically have a name attribute. (but if they do, then they will -- the given name as the name, and its label as its value) single-line textfield * input element with no type attribute, or a type attribute whose value is "text" * NEEDS to have a name attribute -- so that textfield's value when the submit button is clicked will have a name for a submitted name=value pair! * MANY optional attributes are also possible -- see p. 211