Learning html

[lmth]

Looking for some advise on where to start learning html. I'm a print designer jumping into the web world. It seems that html 4 is the foundation where to build html5? Or better to start right on html5 and learn as I go? Thanks for any guidance.

[adtykfhyipoh]

I would absolutely recomend nothing other than
[url]w3schools.com[/url]

I learned all my web design mastery from the website in question.

-[random letters]

[zcorpan]

I strongly recommend against w3schools.

http://w3fools.com/

[JAB Creations]

I agree with Z. At best that site might be an occasional reference point by experienced coders who know what not to use though copying the code from there is something I wouldn't recommend regardless of your experience.

I'd recommend learning XHTML 1.1 served as application/xhtml+xml (create documents with .xhtml extensions and check Firefox --> View Page Info or Opera --> F4 --> Info for media type). The page will break and you'll immediately know what went wrong without having to constantly/manually validate your code (except for duplicate ID's). XHTML 1.1 is compatible with HTML4 for the most part. You can upload HTML4 / XHTML files here: http://validator.w3.org/#validate_by_upload

[zcorpan]

I'd recommend learning XHTML 1.1 served as application/xhtml+xml

I would recommend against that, too.

[JAB Creations]

You could use text/html however you could also blow hours if not days wondering why your page loads fine in all browsers except one when instead the page could break and you could fix the error immediately.

[shijutc]

http://www.w3schools.com is the best solution i find.

[Benner]

There is no such thing as "the best way" to learn anything, and that includes html. It all depends on somebody's personal learning style.
The best thing to do is look at a number of option found when searching for html and or css tutorial (no point learning html5 without learning css) and chose what suits you best.

I would advice against w3cschools though; pretty dire as a tutorial.

[Benner]

I'd recommend learning XHTML 1.1 served as application/xhtml+xml

I would recommend against that, too.

Interesting, why is that? I thought xhtml was the best of both worlds so to speak, and 1.1 now fairly well supported.

[zcorpan]

Because you get no new features and your users get to see error messages.

[JAB Creations]

The 'X' in XHTML stands for extensible. That means HTML5 features can be used in XHTML today.

Your users see errors if you don't code correctly.

Good code breaks when it's broken. If it doesn't then you should expect differences in rendering between browsers and they will be browsers you won't test and many of your visitors will notice though you won't. By serving your pages as application/xhtml+xml your testing if done correctly will easily catch these errors while you are developing locally so they won't make it to a live environment.

Lastly the HTML5 spec is not forward compatible as there is no versioning. After several iterations of HTML are released it will not be possible to know what version of HTML an HTML5/6/7 page conforms to other than to validate it and that can of course validate as a version other than what the author intended or it may not conform at all to any version.

[fulg]

Lastly the HTML5 spec is not forward compatible as there is no versioning. After several iterations of HTML are released it will not be possible to know what version of HTML an HTML5/6/7 page conforms to other than to validate it and that can of course validate as a version other than what the author intended or it may not conform at all to any version.

But this is the case only for the WHATWG spec, or am I wrong? Afair the W3C still wants to go with version numbers.

[JAB Creations]

But this is the case only for the WHATWG spec, or am I wrong? Afair the W3C still wants to go with version numbers.

There tends to be a good balance of ideas between the W3 and WHATWG though I can't say myself, Z or another member might be able to point that out. I know they would get rid of doctypes if possible and eliminate quirks mode if possible however most people for that are not supportive of application/xhtml+xml AFAIK thus quirks mode has to exist. Besides, there should always be versioning of software and standards otherwise you introduce ambiguity and the whole point of standards is to remove ambiguity!

[zcorpan]

The 'X' in XHTML stands for extensible.

Yes... Though really it's just a cheesy name for "reformulation of HTML in XML" and the name "XML" could just as well have been "MGML" (Minimal Generalized Markup Language) if the vote about the name had turned out differently, which might have resulted in "XHTML" being called "MHTML" (Minimal HTML) instead...
http://www.totalxml.net/history-xml.php

What's my point here? My point is that it's not useful to infer things from the name.

That means HTML5 features can be used in XHTML today.

No. HTML5 features can be used in XHTML today because the HTML spec specifies that it should work and because browsers that support XHTML and HTML5 obviously also support HTML5 features in XHTML (not supporting it would be stupid).

Your users see errors if you don't code correctly.

Yes. Most people fail at coding "correctly".
http://hsivonen.iki.fi/producing-xml/

Good code breaks when it's broken.

No. Good code isn't brittle. Good code is robust against errors conditions and doesn't punish end users for trivial bugs. Good code informs the developer about bugs without punishing end users.

If it doesn't then you should expect differences in rendering between browsers and they will be browsers you won't test and many of your visitors will notice though you won't.

application/xhtml+xml only gives error messages (to end users) for well-formedness errors. That's not the kind of error that gives differences in rendering between browsers these days. These days, browsers handle markup errors in HTML exactly the same (because the parser has been specced and browsers have implemented the spec). That doesn't mean it's a good idea to deliberately use invalid markup, but it means that browsers you haven't tested will produce the same result (assuming they conform to the spec) in case a trivial markup bug slips through your system.

What is more likely to produce differences in rendering is browser bugs with CSS, mostly because the CSS specs leave various things undefined. application/xhtml+xml doesn't help here at all, even if your CSS is littered with errors.

By serving your pages as application/xhtml+xml your testing if done correctly will easily catch these errors while you are developing locally so they won't make it to a live environment.

But it only informs you of a small category of possible errors. It is possible to catch more errors by having a validator running in your production pipeline, and that's equally possible with HTML and with XHTML.

Also, many sites are dynamic with user-generated content and stuff included from third parties and so forth, where the "develop locally, test, push" model doesn't really apply. With such a site, everything might be well-formed and OK one day and be broken the next. In this scenario, it's not helpful for the site to stop working until you get around to fix it, blocking end users from using your site.

Lastly the HTML5 spec is not forward compatible as there is no versioning.

Nonsense. You don't need versioning to be forwards compatible. You need defined error handling. HTML is forward compatible.

After several iterations of HTML are released it will not be possible to know what version of HTML an HTML5/6/7 page conforms to other than to validate it and that can of course validate as a version other than what the author intended or it may not conform at all to any version.

HTML has had thousands of iterations in the past decade, without "versioning" (well it's actually in version control, so you could say it does have versioning). Can you tell what version of HTML a page written last year conforms to? If you can, how is this knowledge useful to you? If you want to validate the page, why not validate to the latest HTML spec that has the most up-to-date bugfixes in? Surely the point of validating is to find mistakes? Why validate according to an old known-buggy set of rules (old spec)?

[zcorpan]

But this is the case only for the WHATWG spec, or am I wrong? Afair the W3C still wants to go with version numbers.

W3C HTML WG wants to publish a snapshot of HTML called "HTML5", yeah. The W3C version of the HTML spec has stopped getting updates because of this (since sometime in June this year). The WHATWG version continues to get bugfix updates. I guess we'll see what happens with that.

There tends to be a good balance of ideas between the W3 and WHATWG though I can't say myself, Z or another member might be able to point that out.

I'm not sure there's a good balance, actually.

I know they would get rid of doctypes if possible and eliminate quirks mode if possible

Yeah, wouldn't that be nice?

however most people for that are not supportive of application/xhtml+xml AFAIK thus quirks mode has to exist.

That's not why quirks mode has to exist. It has to exist because Web pages depend on it existing, and any browser that attempted to remove it would immediately lose all its market share because half the Web no longer works.

Besides, there should always be versioning of software and standards otherwise you introduce ambiguity and the whole point of standards is to remove ambiguity!

The point of standards is to get interoperability between independent implementations. It's just a means to that end. It is cheaper than not having standards and letting vendors reverse engineer each other (which is the usual alternative when there's no spec or there is a spec but it sucks or fails to match reality). Specs need to be unambiguous to do that, but removing ambiguity isn't the goal.