> One functionality of CSS often abused without awareness are selectors [...] How elements are selected within CSS affects performance, including how fast a page renders
This assertion used to be thrown around as one of the supporting arguments for using OOCSS, but I'm sure I later read that it was largely debunked; the performance implications were negligible and so it was just making CSS less legible/maintainable for no real reward. Has that changed? Have you any recent benchmarks to share?
My understanding is that performance is a negligible factor next to maintainability when writing CSS in virtually all cases. The best post I've seen on the subject is by Steve Souders[0], which does include some numbers.
>> This assertion used to be thrown around as one of the supporting arguments for using OOCSS.
I've never seen selector performance used as an argument for OOCSS.
>> ...and so it was just making CSS less legible/maintainable for no real reward.
That's a pretty broad sweeping statement that I think you'd be very hard pressed to back up. OOCSS is all about maintainability. Legibility is debatable, but I've seen OOCSS examples that are just as legible, if not more so, than old-school CSS (leaning more on tagname selectors/DOM structure - if that is the opposing stand-point, sometimes it's hard to tell what OOCSS dissenters are really arguing against).
> That's a pretty broad sweeping statement that I think you'd be very hard pressed to back up.
I'll admit it's an opinionated statement, but I don't think that in itself makes it invalid. Opinions are certainly divided when it comes to how to structure CSS selectors, and I am firmly in the camp that OOCSS is bad stuff.
I've had a half-baked article on the whys of an alternative structure to OOCSS drafted for about 18 months now, so I guess it might be time to dust it down and fully write it up.
Does anyone know of any guides or books for really advanced HTML/CSS? I find a lot of these guides target regular websites, which I have experience with, whereas I'd love to know how to create much more advanced layouts (e.g. Gmail, Grooveshark). Does anyone know where I can find information on that kind of stuff?
Learn a front-end MVC framework. JavaScript plays a huge roll in creating applications like Gmail or Grooveshark. Addy Osmani's blog is probably as good a jumping off point as any (http://addyosmani.com/blog/).
Sure, I've worked with Backbone and advanced JS - this isn't the problem. What I'm talking about is the rich, fluid layouts that these sites have and which distinguishes them from a 'regular' website.
Edit: changed Bootstrap to Backbone - always get those two mixed up.
Not really sure what you mean by 'regular' website, it sounds like you're talking about a variety of different things.
Google the following:
Responsive Design,
Object Oriented CSS,
SASS,
Compass,
Susy Grids. Any help? I don't think you're going to get tutorials on how to create something like Gmail because AFAIK it's JavaScript generated from JAVA.
Nicole Sullivan writes a lot about this sort of thing.
I think the best way to describe the difference between a 'regular' website and the advanced layouts I talk about is that an 'advanced layout' often looks similar to a desktop application.
Remember the first BaseCamp? Given designs, I reckon I could build the front-end for that. However given designs for GrooveShark, icloud.com or the new spotify web-app - I wouldn't know where to begin.
I've tinkered with responsive designs, Backbone, LESS, grid layouts and such (by the way, I will check out Compass, it looks interesting) - yet still I feel like I lack the knowledge to build more advanced apps.
Because front-end development is changing so fast, what I've had to do is simply start looking at website galleries and find sites where I like how they've implemented certain features.
Then I try and replicate it, switch it up and work with it. For me, this is a lot better than waiting for someone to show these techniques in a basic tutorial.
You might interested in learning about parallax scrolling as well. It's getting more popular, but its Achilles heel is its not mobile friendly at all.
It's actually not that hard. iCloud and GrooveShark are quite graphic-heavy which gives them that extra edge. Frontend technologies are pushing forward at an incredible rate.
Have you played with Sencha Touch or Google's Angular JS or Ember or Backbone?
These are all great starting points and will teach you a lot about how to structure your code, but for anything large like iCloud, you're going to probably need to write your own libraries because nobody else is doing exactly what you want.
Get good at using jQuery to animate stuff, then re-work your UI using CSS3 transitions (because jQuery suffers performance issues on mobile).
Design for mobile first and scale upwards; by design I don't mean PSDs I mean open an HTML document and just start chopping it up.
I posed what I think is a similar question to a friend of mine that I'm designing a node.js app with. I thought that being in JavaScript, it would handle everything a lot more fluidly, like web apps such as koding.com. In reality, it's just another MVC framework entirely based in JS (let me know if I'm phrasing this wrong).
I'm unsure if for the type of apps we're talking about it's just the way they handle the loading of their site or if it's the framework it is based upon, but he forwarded me to Meteor (http://meteor.com/) and told me that that was probably what I was looking for.
If someone could chime in on this - and sorry for being so obtuse - I'd be super grateful.
Surprised nobody here has mentioned Google Web Toolkit yet. It's the tool Google uses to build interfaces like Gmail and (I believe) Docs. Freely available: https://developers.google.com/web-toolkit/
That said, it's not something I would want to use myself (not a Java fan).
It's also worth noting that Gmail especially appears to rely very heavily on Javascript for positioning and styling, rather than pure CSS. Many elements have, eg; `style="width: 123px"`. This is a practice I strive to avoid, so it's interesting to me that Google makes such use of it.
I think I get what you're asking here. I work for a startup as the sole front-end guy and we have a mess of SASS/JS. It was never really rebased since the beginnings and definitely wasn't structured for performance, reusability, or neatness. I'm going to be reorganizing it soon and I'm reading up on things like this, object oriented CSS, and SASS best practices.
There's a big difference from creating a simple/moderate website vs an application that has many facets but same styles. It's a tough chore to get everything right but I'm excited to do it.
I inherited a similar beast at my last startup. The company ended up going under before I could fully untangle the mess, but when I was researching, I found little out there to give me good advice. All of our HTML, CSS, and JS needed to be addressed and we were on a 2-week release cycle, so I found breaking this debt work into release-size chunks to be a real challenge and still am without a real solution for.
I'd be interested in hearing your approaches to your current project and would definitely be willing to give whatever advice I can based on what I found through trial and error.
I would recommend Alex Maccaw's javascript Web Applications. Sure it's about Javascript, but how really big can your HTML/CSS get before you modularize? :) What I like about the book is that it explains the fundamentals of MVC in a framework agnostic way, which I think is helpful if you are trying to refactor and MVC-ize your code base without throwing in a heavy dependency like Backbone or Spine.
There's no 'really advanced HTML'. There are the standards. Personally, I found that writing a parser for a language does a good job at exposing you to the low-level details, which is what the 'advanced' part usually relies on. Otherwise, you're probably looking for HTML (architectural) design patterns.
I would say that ignoring implementation dogma and going for the best solution to a problem definitely falls under advanced development. It's certainly not something you see coming from developers with a few flavor of the month tutorials and maybe a site build or two under their belt.
Gmail uses tables for the list of mails, which makes sense, but there are also tables for things like the logo. I'm not qualified to assess the work of the team behind Gmail, but it's curious notheless.
I'm not really seeing why I would want the label of the section in question hidden when I'm dealing with it, and at least for me there's not really a parity between 'dealing with' and 'hovering over with my cursor' anyway, unless I'm copying the text. The bright orange color and the constant flashing on/off just adds visual noise and makes it difficult to really read the labels anyway, imo.
Yup I definitely tried to click them a couple times... they don't fad away for me in Chrome, they just disappear, left me wondering if I needed to play some sort of game to get to them properly.
They don't fade away in Chrome because he's using a pseudo-element in the form of content: attr(title). Gecko supports transitions on generated content and WebKit does not.
Also, looking at the ::selection example, it should mentioned that it's not safe to group vendor prefixes in the selector portion of a declaration block, as, unlike with properties, the whole block will be skipped if an unrecognized selector is encountered by a UA's CSS parser.
I disagree on "Lovely" -- I find it hard to read. Dark-gray text on light-gray background throws away several levels of contrast. I had to ctl-+ twice to get a comfortable type size. And the wide blue nav-band on the left is just a waste of space once you get past the second paragraph or so.
I can appreciate the layout, organization, and design of the site (as a frontend developer myself, this is very well executed), but personally, I have an immensely difficult time learning from a structure like this:
<definition of a term that is difficult to grasp out of context>
<loose context / example for said previously defined term with no real world application>
Stuff the whole thing with formal copy coupled with lorem ipsum placeholder text, and I can't force myself to endure the boredom through the first lesson. I have a similarly difficult time learning by reading textbooks (of which this guide feels reminiscent). It just doesn't click for me, but it does seem to work for many, many people.
The first thing that the chapter regarding Performance and Organization takes up is establishing a structure for your CSS.
Whilst I'm well aware that the approach made towards separation of similar classes into multiple files is a good one, I've seen it argued that the usage of @import or linking multiple stylesheets has a significant impact on performance.
The guide even mentions the important practice of combining all styles into one stylesheet in order to avoid multiple http requests, but only later on, in a different section.
I don't think the first section does a good job at stressing this. It ought to at least mention that some form of preprocessing should be present here, if only to minify and combine the files.
To me, it seems a bit counter-intuitive that this first section of the guide could be interpreted incorrectly by a newcommer (''I should separate everything and include it all in a nice, fancy list of link tags!'')
Just some feedback. I must say that I feel like the guide so far is representative of most of the gems I came across whilst trying to improve my webdev, doing small-company websites on the side whilst studying, starting with some basic HTML3/4 and CSS2 knowledge and working on 3-4 projects over the course of 2 years.
It's what I now wish I had known before diving into my first project.
Looks great, and reading the first lessons shows it's also written well and very useful.
One small question, why did you chose a non responsive layout? It is pretty unreadable on mobile (at least for me). I'm sure it's work in progress, but this is the first thing I've noticed.
Again, thank you for posting (and creating) I find it useful and looking forward for the next chapters.
Making the guide responsive is an absolute must, and something I am looking to do right away. For now I just wanted to get it out there and start collecting feedback.
This is truly awesome. What's even more awesome for me as a noob is to see what the web design/dev community is like out there. People really and truly care about educating others and sharing the knowledge they have...now imagine if the people in every industry were as open and awesome?!
The 'Learn Advanced HTML & CSS' button takes me to a password protected area, I'm guessing that's non-standard behaviour?
Site looks really nice, not got much time to check the content whilst I'm at work but I'll have a better look at it. It certainly seems very clear from the quick scan I had.
Hear, hear. That's exactly the nature of my intended comment. There's a disadvantage to being an old Web veteran, in that you tend toward the grooves you have created over the years.
It's not that it fades in, it's that the way it does so loads the sidebar information first, and then awkwardly displays all of the main information staggered, but still quickly enough that the animation has no purpose. If you're going to fade content in, do so in a manner that makes it a non-issue for me to know which content is most important.
As it stands, the primary content page has no visual hierarchy. Everything is the same size and loads at approximately the same exact time. On refresh, sometimes everything under ul.breakout flashes first before hiding again. The border-radius on the images is also giving them some awful-looking jagged edges which appear to be coming from the filter property.
I haven't taken an extensive look at the current unlocked lessons, but as someone with extensive CSS experience, these little things are what makes me hesitant about the rest of the information contained therein. Additionally, as others have pointed out, the palette is bland if not going to be hard for a lot of people to see, so I don't think a little skepticism is snobby.
Their first lesson is "performance and optimization". A page-delaying animation raises question-marks. The stuttering of my mouse as I pass over elements in the list (due to the slow fade-to-colorized animation) raises more.
The rest of the site looks pretty good, but why do all that on the one page where you're trying to sell your highly-tuned-techniques lessons?
This looks great, and on first glance has a lot of useful tips. I'm pretty sure I'll discover a lot of things I'm doing inefficiently, and hopefully this will help me put them right.
The content seems just great - even in a current work-in-progress state it reads like a solid, proper, well structured and thought out book and not just like a typical set of more or less random posts on HTML/CSS. The presentation wakes a grumpy rebel[1] in me, though =)
Also, I think that having the ability to play with some code and see results right there on the site (e.g., tweak all the included numerous demos) would bring even more awesomeness to the project.
Edit: formatting. (Thanks, saraid216, you are right.)
I just want to praise you for it NOT looking like that awful look Win 8 is now designed in. That style must have a name but I dont want to dirty my mind by knowing it. ;)
Grumpy old git moans aside, what I really want to say is that layouts like this are so, so easy to come up with on paper, as it were. Lets face it, there is nothing new there at all. But making something so basic look so elegant is the real art.
Yeah, there are nitpicks, but I'm sure you'll smooth those out. The bulk or core is bang on.
As a lazy useless git, I wouldn't mind a template of it!!!!
The style is commonly referred to as "metro", inspired by the design of metro signs. The idea is to reject skeuomorphism, and use large, clean typography to deliver something that is 'digitally native'. You could think of it as a direct rejection of Apple's adoption of decorative skeuomorphic designs that bring things into the digital space which really don't belong here.
It's not exactly a bad idea, though it is possible to take things a little too far. Certainty if you observe the trends in web designs recently sites appear to be "flatter", less cluttered and more focused, without the Apple inspired "Web 2.0" glossiness that has taken over from circa 2006 onwards
> what I really want to say is that layouts like this are so, so easy to come up with on paper, as it were. Lets face it, there is nothing new there at all. But making something so basic look so elegant is the real art.
Which was exactly Microsoft's rationale for Metro.
Whether or not they achieved that goal, though, is another matter.
This is such a great resource, thanks for this! I have been looking for a good consolidation of some of the more advanced features just to keep around. Can't wait to see this finished!
This is really awesome work Shay - I love your intro to html and css guide as well, and have used it as a resource for many of my students (they loved it too). Fantastic work. If you ever need help with any piece of this, I'd be more than happy to pitch in.
I noticed one really strange thing - when you hover over any of the circles on the homepage, all the ampersands change font. Never seen this before and I'm sure it can be fixed quickly, just a heads up.
In all honesty this should be called a beginner or intermediate guide, no?
When I saw it I was thinking an advanced guide would cover some of the details found here: http://www.html5rocks.com which I find somewhat hard to digest (especially all new semantics).
In no way do I mean to be negative towards what you have done, it looks awesome, I just expected something else.
I agree with you, but even in 2009, web developers had to worry about IE6. It had enough of a market share, because so much of web browsing is at-work by people who either aren't allowed or don't know to install a better browser.
I already knew about the topics, but I still found the table introduction to be incredibly useful. I haven't seen many who worked on creating beautiful, semantic tables like this.
None of the guides online basically have tables with rounded borders.
This is a wonderful guide and concisely brings together all the key elements you need to cover in web design, but without the being burdened by the huge mass of material you see in beginner guides. Cheers!
I recently spent the better part of a day trying to figure out this seemingly-straightforward problem, so if you do go down this road I'd recommend a tool called wkhtmltopdf: http://code.google.com/p/wkhtmltopdf/
I thought image files were already in a compressed format and the gains would only be seen for extremely large files (think MB in size.) Is this really needed for mobile first design? Honest question.
There's compressed and there's compressed. Two PNG-8 images may be perceptually identical (or at least close enough that youd need to overlay and switch between them to see the differences) but one has a 16-color palette and occupies less than 1K (and may be neatly tucked into a stylesheet as a data URI, saving a request) while the other is over 20K. Some JPEGs can barely take 4:1 compression, while others can stand 20:1 without artifacting. It depends on the amount of detail and local contrast. (Oh, and killing any extraneous EXIF data can save huge amounts of space without affecting compression.)
Is this really needed for mobile first design? I'd be inclined to say that it's more important for mobile-first since data transfer tends to be slower and more expensive. Remember data caps, whether hard or soft, and overage fees. Every byte you can save is worthwhile to a mobile user. Think of them as the modern equivalent to a dial-up user whose host connection is a long-distance number.
The main thing being discussed on the page is optimisation of compression (http://learn.shayhowe.com/advanced-html-css/performance-orga...). They mention gzip, and yes it's not going to gain you much (and can lose) for small files or particularly gifs (that already use similar compression AFAIR).
Optimised compression is re-compression of the images, e.g. applications like pngcrush or optipng take a brute force approach and try several different compressions of PNG (all lossless) and give you the best one. Same approach can be taken for JPEG, see eg smush.it, re-compressions here as I understand it provide the same final image data and so this approach differs (and is complementary) with using a Save-for-Web tool in your graphics program.
Best thing IMO is to try something like Google's Pagespeed / Yslow / showslow / webpagespeed / gtmetrix / ... and see if it will give a worthwhile gain on paper - then test with some actual web clients.
I'd say mobile-first is going to be more focussed on bytes than those sites targeting primarily desktop users. I've never seen any metrics on rendering speed of different compression regimes though - small files that are doubly compressed seem like they might take longer decompressing than any saving you'd make in downloading.
I love these guides. Even as an experienced front-end web developer, I always learn something new and insightful as well as design patterns I can improve on. Bookmarked.
I've seen it used most commonly for framework assets (e.g., icons in profiler bar, exception handler pages, etc.) so that you don't have to clutter up your public directory with assets that will never be served on production. Otherwise, spriting + a pre-processor/asset pipeline gives nearly the same main benefit (reduced HTTP requests) with a lot less developer work + allows for caching.
This assertion used to be thrown around as one of the supporting arguments for using OOCSS, but I'm sure I later read that it was largely debunked; the performance implications were negligible and so it was just making CSS less legible/maintainable for no real reward. Has that changed? Have you any recent benchmarks to share?