Free Ebook: How to Code in HTML5 and CSS3
howtocodeinhtml.com
howtocodeinhtml.com
Although I suspect learning HTML and CSS to be manageable, with CSS having some weird corner cases.
However when it comes to JS and all its frameworks things get more complicated. Especially when deciding which JS framework to choose from. It's of interest to bet on something that will still matter in the next 3 to 5 years.
edit: This resource was posted some weeks ago on HN. Although it's more of a set of tutorials from different sources than an ebook.
I would also check out Codeschool (although they're not free) because they have some really great classes on everything from Rails to jquery and CSS.
http://webdesign.tutsplus.com/courses/30-days-to-learn-html-...
There is about 5 hours of material, you can work through it in about a week if you put a couple hours in a day. It is a good way to quickly pick up responsive design and html/css fundamentals. The videos are really good and functional. It is really good from an efficiency standpoint.
I think once you understand those, the rest is really quite simple. Media queries, clever nonsense with things like ":target" or ":not([class]) > div > img", it's all ultra-simple because there are no logic bugs you can introduce once you know the syntax – the only logic you need to think about is in the positioning of elements on the page.
As a backend web developer, you will find it all very simple. A bit of bloody-minded Googling will solve the majority of your problems, and the CSS answers on StackOverflow are more helpful & polite than they are in many other areas.
For HTML, some features I have found useful include definition lists, dfn, nav, header, section and article elements. It may also be useful to check out Schema.org.
So I guess my recommendation is to get the box model and positioning down pat for CSS, and get semantic elements down for HTML5.
If you like genuinely clever and awesome tricks, check out Lea Verou (http://lea.verou.me/).
*"seen" as in "made myself"
I know the basics of HTML/CSS too (I suppose all programmers do), but still I don't feel qualified to make a web page. It seems to me that it's more a designer than a programmer task, am I wrong?
https://github.com/othree/html5.vim
https://github.com/hail2u/vim-css3-syntax
Chrome Developer Tools are invaluable in my workflow.
https://developer.chrome.com/devtools
I can't speak to what the majority of designers use. I would guess that Dreamweaver is less popular today than it was before. I might be wrong, though?
I can do something like "table>(tr>(td>p{$}) * 3) * 4" and then press tab, which would generate for me:
<table> <tr> <td> <p>1</p> </td> <td> <p>2</p> </td> <td> <p>3</p> </td> </tr> <tr> <td> <p>1</p> </td> <td> <p>2</p> </td> <td> <p>3</p> </td> </tr> <tr> <td> <p>1</p> </td> <td> <p>2</p> </td> <td> <p>3</p> </td> </tr> <tr> <td> <p>1</p> </td> <td> <p>2</p> </td> <td> <p>3</p> </td> </tr> </table>
Edit: Except that there would be indentation too, which HN removes.
Generally, each page type (template) is drawn at a desktop and mobile resolution to dial in the responsive experience and visual elements on the page. Designers have personal app preferences but it's always something from the Creative Suite - Photoshop, Illustrator, InDesign or Fireworks. Some people tinker with wireframing or prototype apps but I've found them distracting.
We sketch wireframes on a paper and go right to coding for something small or internal. When client approval is needed there is always a polished design presented in PDF or PNG with notes explaining the intended functionality.
I like editing in Coda (paid) and Brackets (free). Classic WYSIWYG programs like Dreamweaver are being replaced with interactive apps like Adobe Muse or hybrid custom-hosted templates like Squarespace.
There are so many good CSS frameworks available that you can learn one and make an excellent page in a day. We use Bootstrap for the full blown responsive CSS/HTML/JS framework and Susy for a CSS-only Sass system.
Our new interns start by learning these paid HTML Foundations and Bootstrap courses. https://www.codeschool.com/paths/html-css
Grunt, Bower and Yeoman are the command line tools we use. Grunt helps you automate tasks like minifying your code to save file size or update your browser live while writing HTML, CSS and JS. Brackets has Grunt built in so local page refreshing already works. Bower lets you install lots of well tested CSS and JS (with version dependencies). Yeoman lets you create the shell of that "pro" web page or app from the command line, leveraging Grunt and Bower.
For example, the section on forms suggests you use the 'for' attribute to link a label with a form element, which is great, but it wouldn't take much extra text to give a short explanation why this is helpful to many users.
Thanks for your feedback! I will consider your points (very good) when working on the next releases.
Author
Support for older browsers -- I'd assume anything here will support evergreen browsers (including current IE) and emphasize how to always support that baseline. But what's involved in supporting older versions of IE, in particular? Easy mode: IE9+. Hard mode: IE6+. (I haven't had business reasons to support anything older than that, fortunately). There's obviously work involved (and not all sites need to do it) but it's worth pointing in the right direction for those who need to know.
Support for devices: how will it display on a phone? Tablet? What's likely to break? What main approaches are there? E.g., horiz elements wrap to vertical, different display entirely, let the user zoom/scan around, etc..
i18n/l10n: when you add multi-language support, some text will suddenly be three times as long, or even need to be displayed right-to-left. Numbers may align differently. What will happen to your menus, dropdowns, titles, etc.? Will they wrap in an ugly way, or be cut off? It's pretty common for things to just break, because the original site was built by someone who assumed "Home" would always be 4 chars.
And accessibility (already mentioned in another comment). Going into depth may be overkill, but I'd strongly advise covering the choices that ruin accessibility entirely. There are basic best practices that aren't too hard to follow that will make a site at least usable by people with non-standard browsers (even if it won't win any awards).
I'm cautiously optimistic about the Spartan project and I wish them all the best but if the new boss would be like the old boss, that would be the last nail in Microsoft's coffin when it comes to the web standards.
Fortunately, based on what we've seen so far, that doesn't appear to be the case.
Please no. The web industry has suffered enough because of IE. There's no reason for a book like this to even acknowledge it's existence. Of course I'm referring to older versions of IE. Newer ones at least support common use cases.
I'd maybe mention the use of something like Respond [1] to deal with media queries but I wouldn't go any further than that.
That's not right; of course there's are reasons, though you're welcome to debate how much weight those reasons have.
I don't know what percentage of sites have a business need to support old IE versions.
I know we do -- our site is used by medical staff in hospitals where the PCs are locked-down, upgrades are hugely expensive and difficult (the silent auto-upgrade approach just isn't safe), and so even though no one likes IE7 there are still plenty of hospitals who haven't yet succeeded in upgrading.
There are other industries besides healthcare that suffer from this effect as well -- think especially of cases where companies have paid serious money for custom-developed systems that were cutting-edge in 1999, and thus were fully-browser-based and used the leading browser technology at the time, which was IE 5 with a ton of ActiveX (or Java applets?). If they still fill the business need perfectly well, the options around upgrading are not at all clear-cut.
I'm not sure how big this need is; I'm obviously biased because it affects me directly.
Do you feel like the industry's support for older versions of IE perpetuates the idea that businesses can continue using such archaic systems?
But for a gut feeling -- no, not at all. No one wants to support old browsers, and if you pay for custom site development, it's a common practice to add seriously high extra fees if that's a requirement.
And so most sites don't support them.
But all of this doesn't really encourage or discourage a business that has really poor options around upgrading. In some ways it's just irrelevant; they're using the browser as a tool for employees to complete specific tasks, and if Facebook doesn't work (but the expensive internal tools do) that's just fine.
The two domains collide when there are new, external tools that are introduced to the environment. ...and this is why we need some support of old IE, because we really don't want our sales pitch to include "...but you'll need to also spend untold amounts of cash and effort to upgrade your browsers, first".
"It is reasonable to say that HTML markup is code (and writing HTML markup is coding), provided that people understand that it is comparable to using coded notations when talking or writing. Think about the use of product codes, or using special code books when sending telegraphs, so that short coded presentations stand for long statements, or using colors as codes so that red means "stop" or "warning" or "hot". It's a matter of using some notational system which has been specifically agreed upon. (Actually, natural languages are not completely different from codes; they too are based on agreements, just more vague and implicit.)"
https://www.cs.tut.fi/~jkorpela/prog.html
To be honest, it's a bit silly to argue this stuff to begin with. As long as the meaning "to write/type HTML and CSS" was conveyed, does it really matter? To look at a document as big as this and latch on to the code vs. not code distinction (an arbitrary one depending on how you look at it) in the title is to miss the document's greater value.
For example: <p>The quick brown fox jumps over the lazy dog.</p>
Here the markup does not change the fact that the dog is lazy. That is the markup does not give meaning to the sentence.
But with code, the meaning is "coded" in to the text. Lazy could be code for yellow, which in that case changes the meaning of the sentence.
With this definition couldn't you make the argument that code that defines structure isn't code, but markup?
To the uninitiated, "markup" may be even more intimidating than "code".
What is your reaction?
Externally, I make polite conversation by asking "What sort of stuff do you do?"
If you're targeting novices, perhaps you'll find some inspiration for the layout in O'Reilly's "Head First" series: http://shop.oreilly.com/category/series/head-first.do?sortby...
They have done incredible work to make not only the content, but also its presentation attractive for the beginners.
I'm teaching my small nephew basics of web development and from now on I'll be following your book.
Author
I use Pandoc to generate my EPUB and then Sigil to do a bit of tidying. Usually just the front matter etc.
Some other resources here, the slides from ConFoo are the most up to date http://rachelandrew.co.uk/presentations/css-books
I want to learn to code but every guide and how-to I read tells me to start with a different programming language and I never know who to trust.
If you are trying to build websites, then that's the way to go.
Not trying to be pedantic. There is a huge difference between the two.
If you can't go through a CS curriculum with it then it isn't coding? Maybe that's the distinction.
Yet I do see your point and there's probably nothing horrible about using it in your title. "Learn HTML and CSS Markup" may have been a better title, possibly even from an SEO perspective.
Again, not trying to be pedantic. Not a big deal. No data structures were harmed in the making of this title.
BTW, that aside, this nicely done. I am going to have my son go through it.
But that would also make things like basic SQL 'not coding', and any program you wrote where you didn't use an arbitrarily long loop.
That makes "print('Hello world')" not coding, and then it becomes clear that you're drawing an arbitrary line in the sand. "If you aren't writing compilers, you're not coding" or some such nonsense.
HTML and CSS are languages for encoding the semantics of webpage formatting and content. They are domain specific languages. They are not turing complete. But they are coding.