2. Why bother? I can still do it
● I can do it all with client-side handling
● Every element is standard-natively clickable
● Prevent any native handling in every custom
element event scripting (e.preventDefault...)
● it only works with javascript in some cases.
3. Well, you kinda should bother!
● Yahoo: 2% of their users are jscript-disabled
● Statistics don't tell whole story: No-js-users
can't reach all pages in only-javascript
websites and tend not to come back if
nothing works.
4. ● 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.
5. ● Specific events. ex: visited/clicked/etc.... for
anchor tags.
● - anchor tags get crawled, button tags do not
("nofollow" rule is not followed 100%)
8. <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>
9. <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.
10. <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.
11. <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.
12. Conclusion
Links vs. buttons
- Links must never change state, while buttons could potentially change state.
- similar to RESTful semantics; GET vs. POST/PUT/DELETE
20. Semantic Analysis
Like Action
Adds a new “Like/Follower” to a post -> changes state in the server.
Comment Action
Makes the comment form visible to the client -> client side flickering.
Share Action
Facebook: Opens a pop-up form
Restorm: Loads an inline form
25. 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 don't
know what it does. Developers tend to sometimes follow
that lead.
Should it be the other way round?
Is there a balance?
26. 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
27. 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)
28. Radio Buttons and Checkboxes
Radio 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.
29. Radio Buttons and Checkboxes
Issues:
● 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?
30. Use case - Rightclearing
The Tags
● Multiple selection of items, orthodoxly represented by
checkboxes;
● styling concerns led to the decision of implementing
them with anchor tags supported by an hidden input
field and a javascript plugin;
31. Use case - Rightclearing
Pros:
● looks really good in all of the supported browsers!
Cons:
● a lot of client-side scripting (the better part of a custom
plugin of ours) was written to simulate part of the
behaviour that the checkbox natively provides.
● non-focusable, does not respond to keyboard events
(no mouse, no fun. could be part of the plugin
mentioned above, but it would just bloat it).
● javascript-dependent, main reason why the RC search
doesn’t work without script (correct me if I’m wrong).
48. Conclusions
Appearance
1 - Everything looks good. (unsupported css features in the IE <=9, like border-radius and text-shadow)
2 - Everything looks at least functional. Graceful
Degradation.
Functionality
1 - Works with javascript.
2 - Works. point.
