1 / 43

(X)HTML Coding Standards

(X)HTML Coding Standards. Good coding conventions will show the logical flow and structure of the page more accurately, improving readability of your code and allowing you (and us) to find errors more quickly. File Formatting. Use proper indentation

skule
Télécharger la présentation

(X)HTML Coding Standards

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. (X)HTML Coding Standards Good coding conventions will show the logical flow and structure of the page more accurately, improving readability of your code and allowing you (and us) to find errors more quickly.

  2. File Formatting • Use proper indentation • Tabs should be 4 spaces (most modern editors will convert this for you) • Closing tags should be indented to the same level as their opening tag • Keep lines under 80 characters, if possible (120 characters maximum unless absolutely necessary) • Use Unix-style line terminators (\n) • www2 is a Unix server, so Windows (\r\n) or Mac (\r) line terminators may cause problems

  3. Coding Style (X)HTML Tags (Elements) • All tags must be lower case • i.e. “<title>” instead of “<TITLE>” • All tags must have an opening and closing tag • i.e. “<title>Your title here</title>” • Some tags are self-closing (see list on next slide) • Do not use deprecated tags • “Deprecated” tags are being phased out of the (X)HTML standard and should be avoided • Examples: “<b>”, “<i>”, “<font>” (See http://www.w3schools.com/tags/default.asp for a full list of (X)HTML tags.)

  4. Coding Style (X)HTML Tags (Elements) • Self-closing tags should end in “ />” • “<br />” • “<hr />” • “<link />” • “<meta />” • “<img />” • “<input />” • Notes: • “<link />” and “<meta />” are only allowed within the “<head></head>” section of your document. • “<script></script>” is not a self-closing tag!

  5. Coding Style (X)HTML Attributes • Always use double quotes to surround attributes • i.e. title=“title” instead of title=‘title’ or title=title • No attribute minimization • Wrong: “<option value=“1” selected>1</option>” • Right: “<option value=“1” selected=“selected”>1</option>” • Other commonly minimized attributes: • “checked”, “nowrap”, “readonly” , “disabled”

  6. Coding Style Comments • Use comments for: • “Templates” of reused code • Important page changes • Marking the end of long block elements • i.e. “</div> <!-- id=“ku_middle_rows” -->” • Do not use comments to hide real content • Users will still be able to see content hidden in comments with little effort • Some modern browsers will interpret two hyphens and a caret (“>”) as the end of a comment, even if they aren’t consecutive

  7. Coding Style Comments • Sample comment that will display to the user: “<!-- <p>Hide this -- it is <strong>date specific</strong></p> -->” • In this case, everything after the “>” in “<strong>” will be displayed to users of standards-compliant browsers.

  8. SSI & Conditional Comments SSI Conditional Comments • Use SSI to switch date-specific content “<!--#config timefmt=“%m/%d" --> <!--#if expr="$DATE_LOCAL >= 03/01 && $DATE_LOCAL < 05/01" --> <!-- Any content within this conditional will not be displayed (in any fashion) unless it is March or April. --> <!--#endif -->” • These can be as generic or specific as you need, including time • http://www.htmlgoodies.com/beyond/webmaster/article.php/3473351 • http://www.ssi-developer.net/ssi/conditional-expressions.shtml

  9. SSI & Conditional Comments (X)HTML Conditional Comments • If you need to serve specific content to Internet Explorer (and we only recommend this is for IE-specific stylesheets), use conditional comments • Conditional comments are only considered valid by Internet Explorer • All other browsers ignore the code as a normal comment.

  10. SSI & Conditional Comments (X)HTML Conditional Comments • Example: “<!-- This will serve a stylesheet to IE browsers below version 7 --> <!--[If lt IE 7]><link rel="stylesheet" type="text/css" href="ie.css" media="screen" /><![endif]--> <!-- This will serve a stylesheet to IE browsers with version 7 --> <!--[If IE 7]><link rel="stylesheet" type="text/css" href="ie7.css" media="screen" /><![endif]-->” • http://msdn.microsoft.com/en-us/library/ms537512(VS.85).aspx

  11. Other Best Practices Inline JavaScript and CSS • Avoid using inline JavaScript or CSS • All JavaScript and CSS should be outside the page to maintain consistency and make your pages easier to maintain. This also speeds loading time. • Include CSS files at the beginning of the document • Include JavaScript files at the end of the document (just before the footer)

  12. Other Best Practices • Do not use empty anchor (“<a>”) tags for page jumps. Instead add an “id” attribute to a nearby element: • Wrong: “<a href="#somepart">Page jump</a> ... (snip) ... <a name="somepart"></a> <h3>Some Part</h3>” • Right: “<a href="#somepart">Page jump</a> ... (snip) ... <h3 id=“somepart”>Some Part</h3>”

  13. Other Best Practices • Use HTML Entities in place of special characters • You can find more with the following links: • http://www.w3schools.com/tags/ref_entities.asp • http://www.google.com/search?q=html+entities

  14. Other Best Practices • Never use images as text. This reduces both your search engine optimization as well as your usability to users of screen readers and other accessibility software. • Note: As a government institution, we are required by law to meet accessibility guidelines. • If you have an image that you want to use for text, use CSS to replace the text with your image. • (Helpful links on next page)

  15. Other Best Practices • CSS Image Replacement resources: • http://phark.typepad.com/phark/2003/08/accessible_imag.html • http://moronicbajebus.com/playground/cssplay/image-replacement/files/ • http://wellstyled.com/css-replace-text-by-image.html

  16. CSS Coding Standards A well organized CSS file (or set of files) makes finding specific properties fast, simplifying the process of adding to or changing your CSS code.

  17. File Formatting • Just like with (X)HTML, good file formatting can go a long way toward making your CSS files more readable. • Use proper indentation • Tabs should be 4 spaces (most modern editors will convert this for you) • Closing braces should be indented to the same level as their opening declaration

  18. File Formatting • If a particular CSS rule has more than three properties, split each property onto its own line. This helps keep lines short and easy to read. • Alphabetize properties within CSS rules (examples on next page) • This makes finding a specific property extremely easy, especially if there are several properties within a single CSS rule.

  19. File Formatting • Wrong: “div#header h1 {z-index: 101; color: #000; position: relative; margin-right: 48px; padding-right: 54px; border-left: 2px solid #ccc; width: 10em;}” • Right: “div#header h1 { border-left: 2px solid #ccc; color: #000; margin-right: 48px; padding-right: 54px; position: relative; width: 10em; z-index: 101; }”

  20. File Formatting • Organize your CSS • Organize or separate your CSS rules into categories such as: • Basic Elements • Generic Classes • Basic Layout • Header • Content • Footer • Etc • This way, if you are looking for the CSS rule for, say, <ul> or <ol> lists, you can avoid sifting through much of your CSS

  21. File Formatting • BE CONSISTENT • However you choose to organize your CSS, maintain that same method across all of your CSS files. • Don’t touch your CSS until your (X)HTML page has been coded! • How do you know what something should look like if that something doesn’t even exist yet? • Good CSS builds upon the (X)HTML markup, not the other way around.

  22. SSTS CSS Library <div id=“wheel”> I’m inventing what now? </div>

  23. common.css pg.1 • http://www2.ku.edu/~ssts_lib/css/common.css • Holds our most commonly-used style rules that apply to just about every site we create. Examples: • .right and .left float classes • .center (text) and .centered (block elements) • .under (underline) - Avoid this, but still better than <u> • .half (left-floated, 50% width) • .block, .inline, and .inlineblock (sets display values)

  24. common.css pg.2 • List rules • .spacedlist (adds extra space after each <li>) • .pdflist (uses a PDF icon instead of the list bullet) • .windowlist (uses a window icon for the list bullet) • Tagging/labeling • .pdf (adds a PDF icon on the left) • .window (adds a window icon on the left) • .external (adds a “leaving” icon on the right, think Wikipedia) • .ku_email, .ku_phone, .ku_fax (not ours, but use them) • .error and .required (makes text KU Red)

  25. common.css pg.3 • Message Boxes – help the user see quickly what kind of information you are trying to get across. • .okBox - Ok/Success (green with “tick/checkmark” icon) • .noticeBox - Notice (yellow with triangular “warning” icon) • .errorBox - Error (red with exclamation point “error” icon) • .messageBox - Information (gray with blue “info” icon) • Examples: • http://www2.ku.edu/~ssts/knowledgebase/web/cssSample.shtml

  26. forms.css • Holds our shared style rules for HTML forms. • These support our standard form style (Bill). • .inputBox • .frozenBox (relates to HTML_QuickForm) • .staticBox • .noteBox • fieldset, label, legend, input (inc. select/textarea)

  27. tables.css • Holds our shared style rules for HTML tables. • Sets standard border width and color • Sets style for table header • No demo yet, mostly used for adding JavaScript functionality to reports in table format.

  28. Generic HTML Templates Form Template • Standard form layouts will improve form usability and completion rates. • Easy-to-read error messages help users quickly identify errors in filling out the form • See a complete example here: • http://www2.ku.edu/~ssts/knowledgebase/web/formSample.shtml

  29. Editors & Other Utilities Let the computer do the work for you

  30. Recommended Editors • ZendStudio 5.5.1 • Pros: • By the makers of PHP • Full IDE (integrated development environment) • Code completion (PHP, HTML, PHP comments) • PHPdocumentor built in • Syntax highlighting • Automatic error checking as you go • SFTP integration • SQL editor built in • Goto Source • Code Analyzer

  31. Recommended Editors • ZendStudio 5.5.1 • Cons: • ZendStudio 6+ is not yet recommended • Not free • Mediocre integration with versioning software • Focused on PHP (limited JS and HTML support) • Website: • http://www.zend.com

  32. Recommended Editors • UltraEdit (version 14 or so) • Pros: • Syntax highlighting • SFTP integration • SSH integration • Fast • Simple conversion functions built in • Column mode for edits • Can do just about anything to text • Great find/edit/replace support in folders/files

  33. Recommended Editors • UltraEdit • Cons: • Not free (but close, very cheap) • No code completion • No error checking • Not a true IDE, just a powerful text editor • Full IDE version is called UltraEdit Studio, more $$ • Website • http://www.ultraedit.com/

  34. Recommended Editors • Netbeans 6.5 • Pros: • Free • Full IDE • Code folding & code completion • Thorough HTML code completion • Includes attributes and explanations • Automatic error checking • Works on Windows, Linux, Mac

  35. Recommended Editors • Netbeans 6.5 • Cons: • No SFTP support yet • 6.7 is due in June 2009, or you could use 6.7 M3 now • May be more complex than necessary for basic (X)HTML & CSS development • Website: • http://www.netbeans.org/

  36. FileZilla (SFTP Client) • Benefits: • Open source (FREE!) • Easy to use • Works on Windows, Linux, or Mac • Good permissions support • Cascade permissions to subdirectories and files; customizable • Drawbacks: • Any (S)FTP client separate from your main editor adds extra steps when editing your website. • Website: • http://filezilla-project.org/

  37. PuTTY (SSH Client) • Benefits: • Open source (FREE!) • Easy to use. • Drawbacks: • Does not work on Mac • Logging directly into the server via command line can be dangerous if you don’t know what you are doing. (This is more a drawback of SSH in general than PuTTY specifically.) • Website: • http://www.chiark.greenend.org.uk/~sgtatham/putty/

  38. Code Helpers (Tidy) • Useful for automatic cleanup and standardization of old code. • Free • Does a lot of the tedious work for you • Available for HTML and CSS • Other tools can be used for PHP and JS

  39. Code Helpers (Tidy) • htmlTidy • http://www.w3.org/People/Raggett/tidy/ • Configurable output • Integrated with UE • Converts tabs to spaces (not an option)

  40. Code Helpers (Tidy) • cssTidy • http://csstidy.sourceforge.net/index.php • Variable output options (more/less white space) • Can sort (alphabetize) properties for you • We recommend Standard or High compression

  41. Browser Plug-Ins (Firefox) • Web Developer Toolbar – Tools to do just about anything • Firebug – all sorts of JavaScript and CSS functionality… so good people make other Firefox extensions just to add onto Firebug (FirePHP, FireCookie, Y!Slow, etc…) • ColorZilla – point anywhere and get the hex value of the color that’s under your cursor • Screengrab – easy screenshots of the whole screen or just a portion of it • NoScript – shows what your site is like without JavaScript available, also boosts security for regular browsing • All available from https://addons.mozilla.org/en-US/firefox/

  42. Other Useful Bits (may be discussed in a future meeting) • jQuery • Open source JavaScript library • Makes writing JavaScript code much faster • http://jquery.com/ • Smarty • Open source PHP template engine • Create dynamic templates to use with PHP code • Edit the “look” separate from the code • http://smarty.net/

  43. Questions? • Feedback? • Comments? • Concerns? • Ideas for future presentations? Bill Parrott and Brian Fenton sstsweb@ku.edu

More Related