Bad Practice in Video - Suggest a Standard is applied to example code shown

@Andrew - Those are some really good points.

I'm not 100% about on points 2 & 4 of your "such as" list:

• Don't use self-closing tags
• Don't use (most) entities references

But I'm open to having my mind changed

2 great resources on best practices for writing HTML & CSS

• HTML5 Style Guide
• Google HTML/CSS Style Guide

Hi James,

While you can have void elements with or without the forward slash to make them self-closing, the practice (which is what I'm encouraging discussion about) of being mindful to close what you open encourages fewer mistakes than having one rule for void elements and one rule for elements that could contain content. My preference is to encourage the practice of deliberate closing. You can also look at the problems created by not having to have a head or body tag in your document. It will still parse and render, mostly, correctly, but it's discouraged. For the same reason, I would encourage a stricter practice for coding, even if it's not a practice required by the standards body.

When I write CSS, I don't need a semi-colon following the last property's value, but I add it because it's good form to stick to one rule, consistently. If I add another rule, I don't need to remember to add a semi-colon to the previous last rule. Similarly, if I move the rule, I don't need to worry about invalidating the css rules that follow.

In html5, the looser html parser (as opposed to xml) also allows you to avoid putting closing tags in, avoid putting quotes in to attributes and allows you to put in properties as booleans.

However, these practices can lead to more mistakes. And those learning here need the fewest mixed messages while learning.

So, while having less stringent rules allows you to get away with making your code less rigid, it's usually through experience that a developer can apply those rules consistently and have a lower chance of making a mistake when employing the looser syntax rules.

I think students should be taught the most strict syntax rules to encourage good practice and then encouraged to read about where they can loosen up, rather than provide a mixed set of examples without context. If the lessons are taught one way or the other, for these points, it would be fine, but don't mix and match, is the message I'm trying to get across.

When you read the guidelines by google, you'll see a mix of 'best practice' and opinion, such as the CSS one above, adding new line characters, etc. If you gzip your code, those new line characters are removed, but gzipping is encouraged to speed up delivery where supported.

So, their guidelines are not rules, but things to help developers code more consistently. I suggest a set of references or standard be promoted along with the courses, even if those references are on opposite sides of a particular view point. It will help encourage a 'way' of coding that's consistent.

Indentation by spaces should be indentation by tabs. Tabs take fewer characters and are configurable by almost all IDEs to represent a number of spaces that the user feels comfortable with. The reverse is not true with spaces, so this presents a usability issue when changing environments or working with other coders that's not presented by using tabs.

In the common world of web development, you can't rely on your server and your meta tags being in sync' with each other or to be sending utf8 at all.

So, in the lessons we should encourage the use of utf8 AND the use of the appropriate character OR make it clear that you can use the entity if you're not using utf8, but not, again, mix and match in the examples.

Consistency and standards help students achieve an appropriate quality, but mixing the messages can lead to haphazard quality in the code produced by students of the same course.

Do you think we could encourage the addition of more authoritative reference material or videos that follow a style-guide just for consistency's sake?

Thank you for your feedback. Extra credit for both of you :)

(I'll add the transversal/traversal point to QA fixes.)

Hi Andrew!

Keep up the good work :) I love the content. I'm just picky because I teach web development to my brothers and I see little things like these trip them up so often that we've got some standard practice guidelines I make them follow while they are learning.

The fewer points of distraction there are, the fewer points of failure while learning.

Thanks! Andrew

@Andrew - What do you think of these coding guidelines for teaching those new to HTML.

Always do the with HTML

• Self-close tags
• Use double quotes for attributes
• Use UTF-8
• Use entities only for characters which have a special meaning in HTML such as &, <, > & "
• Indent nested tag with one tab
• Use semantically meaningful names for classes & IDs
  • E.g. Use this <p class="warning">...</p> over this <p id="big1">...</p> `

Hi James,

I 100% agree with those guidelines :)

I might suggest, practice and maintain a consistent form of indenting of your code and possibly naming classes and ids as close to the purpose of an element as you can rather than naming it based on its styling.

E.g. <p id="big1">...</p> vs <p class="warning">...</p>

Love it :)

@Andrew - I updated the list guidelines for indenting nested tags & semantic naming of IDs & classes.

I open to the idea of, adding a suggestion about configuring an IDE to convert tabs to spaces, if so use 4 spaces.

Agreed - as long as it's standardised, most people can work with it, and it makes it easier when you return to your own work later.

Love it :) Part of good coding is good habits - I like your list.

Thanks James :)

The very first programming class I took back in high school, one of the things we were graded on was the readability of our code that instilled in me a very strong views on consistent indentation & naming conventions.

A few weeks ago I put together this HTML5 style guide which might interest you.

Hi James,

That's an excellent resource - if it can be presented to treehouse members as a guide - I think it would be a brilliant reference!

I agree with all the statements there :)

@Andrew - I'll write it up

James,

Not sure if it's been posted somewhere else on the site but that style guide is awesome! Not what I came into this thread for but I am stoked that I did!

Kris