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/).
I'm also very interested in this. I'm a SW engineer who has worked mostly with C, C++, Java and Python. But now I would like to learn web development.
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.
Time spent on learning frameworks is mostly wasted. Except when there is an interesting concept behind. In 3-5 years things like web components will be mature enough so it may be worth to learn/use from now. Having a strong understanding of JavaScript, CSS, SVG/Canvas/WebGL will be much more valuable than learning a framework api.
If you're interested in getting your feet wet with JS, not in a web developer sense, Codewars.com has some cool coding challenges that can be done in JS. When it comes to frameworks, I've found that AngularJS is probably the most entry-level friendly but I absolutely love using React in my projects.
I made this journey recently. For css pick a framework(something small like pure/skeleton) and study the source code and read about each attribute you don't know about on MDN.
Related question: how do "pros" write web pages. Do they do it by hand or do they use some type of wysiwyg editor?
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?
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?
For sites created by an agency, making a web page is still a combination of designer and programmer tasks. Some people do both task types but it's usually a division of labor.
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.
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.
YMMV, but everybody I know uses a text editor of some flavor. Some use specialized text editors like Espresso or Coda, but the most common I see is Sublime Text.
I'm currently doing the Udacity Frontend Nanodegree. It's somewhat expensive but I'm learning a ton. The best part about paying for it is that you get graded exercises while building an actual portfolio along the way. As for the courses themselves I feel like I'm learning best practices and not just syntax.
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.
Looks easy to follow and the design is clean. It mentions accessibility in the 'What's next?' chapter, though, while I would have hoped this would be covered as part of the material in general.
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.
I haven't read through more than the ToC at the moment -- but here's a quick summary of what I'd be interested to see, aside from just putting together uncluttered (and as-semantic-as-possible) HTML and maintainable CSS:
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).
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.
> There's no reason for a book like this to even acknowledge it's existence.
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.
It's the sort of question that needs more data than just what I think about it.
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".
In summary, IE has been a disaster for the web community save for the XHR spec and something here something there and I can't wait for the day to come not to have to support IE9, IE10 or even IE11.
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.
"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.)"
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.
I think it does matter because code makes it sound complex, wheres markup explains what it actually is. I don't think everybody in this world should know how to program ("code") but I do think every person in this world should know the concept of markup, because essentially that's the same thing as knowing how to structure text which is just as important as spelling and grammar.
Does it pass the conversation test?
You're sitting in a diner and an old acquaintance walks in. Conversation begins and you ask what he does for a living and he responds that he's a "coder". You ask, "Oh? What language?" to which he responds, "HTML."
Not really. It's simply a reflection of how terms get tossed around where they are incorrect, such as the much over used "engineer". There are "sanitation engineers", "software engineers", and "civil engineers", and it's possible that any of these are truly engineers. It's also possible that they are not.
Seems to be really well crafted for the complete beginners with step-by-step, encouraging approach (LEGO, clear transition from text to HTML with side-by-side comparison etc.)
HTML to write a book. PrinceXML to generate a PDF out of it. Then calibre for Mac to generate epub/mobi from HTML. I had to edit manually the output from calibre though.
Whenever I see one of these free books or websites, I say "Oh boy! I'm finally going to sit down and learn how to code/build websites/etc." I start but after a while I begin to slow down and ultimately stop.
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.
Well, that is true when there are several languages that overlap (for example, you might want to do some server stuff and you find that there is C++, Java, C#, etc.); however, if you are trying to learn the web, then you definitely need to learn HTML and CSS, since those are the only languages available that do the thing they are good at.
If you are trying to build websites, then that's the way to go.
Certainly true, and when I teach I try and make sure the distinction is respected. However as time goes in, it's worthwhile to highlight the ways markup is slowly becoming like coding. Semantic markup acts a lot like an instruction for the crawlers reading pages. CSS and its robust pre-processor eco-system now allow variables, mixins and includes which make it a great introduction to programming concepts for those totally new.
If One can't write bubble sort, a genetic solver or iterate through data (array, list, dictionary, whatever) while making decisions I think it is safe to say it is not coding.
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.
If you want to explain how markup is different from a general purpose language, you can always refer to the fact that markup isn't turing complete, and can't be used to perform arbitrary loops and arithmetic.
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.
