● Browser native styling for elements.● Screen readers, Mobile Devices, etc... devices with other user inputs. Semantics very important.● Focusable elements (tabindex does not solve it all)● Navigable through keyboard tab key.
● Specific events. ex: visited/clicked/etc.... for anchor tags.● - anchor tags get crawled, button tags do not ("nofollow" rule is not followed 100%)
<a href=#a> The Anchor Tag </a>● A link is a connection from one Web resource to another.● The link starts at the "source" anchor and points to the "destination" anchor, which may be any Web resource (e.g., an image, a video clip, a sound bite, a program, an HTML document, an element within an HTML document, etc.)x.html c.html<a href="#b">..</a> <html....> ...<a id="b" href="c.html">...</a>
<button> The Button Tag </button>● form inner element● Defines a push button, submission of form.● Inside the element you can put content, like text or images.
<input type=submit value=Submit/>● form inner element● Defines a button for submission of form.● Label of the button is defined by its value attribute. No option to change background image natively.
<input type=button value=but /input>● form inner element● The input buttons represents a button in a form with no default behavior.● Input buttons and input submits are styled similarly (the same difficulties, therefore).● Typically associated to client-side behaviour.
ConclusionLinks vs. buttons- Links must never change state, while buttons could potentially change state.- similar to RESTful semantics; GET vs. POST/PUT/DELETE
Use case: the post action links Like/Comment/Share
Semantic AnalysisLike ActionAdds a new “Like/Follower” to a post -> changes state in the server.Comment ActionMakes the comment form visible to the client -> client side flickering.Share ActionFacebook: Opens a pop-up formRestorm: Loads an inline form
Use case: the post action links semantic match 3-1
Questions?Possible Topics:● discuss the nofollow attribute;● web-crawling implications in our HTML documents;
Intro● Design and Appearance decisions sometimes drive the Architectural Design.● Clients sometimes (most of times?) base their requisites on something they saw, like how it looked, but dont know what it does. Developers tend to sometimes follow that lead. Should it be the other way round? Is there a balance?
Why you should use? (form elements)● No need to provide script that handles functionality● Works for JS and no-JS forms ( <3 )● All reasons described in Part 1 that apply to them
Why would you run away from it?● Form native elements are usually hard to style.● Cross-browser styling on top of that (<3 your IEs)(please interrupt me if you have something to add to this list)
Radio Buttons and CheckboxesRadio Buttons: - used for selection of an item from a list of items.Checkboxes: - used for selection of multiple items from a list of items.checked: Gives the default checkedness of the input element.name: Gives the name of the input element.required: When specified, the element is required.value: Gives the default value of the input element.
Radio Buttons and CheckboxesIssues:● how to style them like tag buttons?● how to make the radio/checkboxes disappear and leave only the label?● And how to make them work in every used browser?
Checkbox Tags: OutputFirefoxChromeOperaIE9IE8IE7Safari (it will work in IE 10)
Appearance over Functionality orFunctionality over Appearance?
Questions?Possible Topics:● Why doesn’t the checkbox disappear in the IEs 8-?(hint: IE is evil)