I am interested in improving my understanding of CSS. I have been making web pages for a while, but I am still constantly thwarted by bizarre behavior that I can't explain when I try to get things to look the way I want. I have a good bit of development experience and I have no trouble understanding the finer points of Javascript, PHP, or even C. But when it comes to CSS and HTML, I find I am always trying to "trick" my code into working.
This must betray a lack of understanding on my part about how web pages and CSS actually work. Are there any good books or resources I could look at toward the end of truly understanding what is going on under the hood? I always feel like I'm at a loss, but I suspect I could get over that if I just cracked down and did some good reading.
I find I am always trying to "trick" my code into working.
Yep. CSS is often about creating the illusion of the effect you intend, rather than actually doing what you intend.
That said, there are very specific rules, as specified by the W3C. Understanding the visual formatting model can do wonders for your understanding as well. These specs are dense, and often confusing, however, so figuring out specific properties and building knowledge step by step is often the easier way to go. Find tutorials (see links below), or just play with them and see what happens (that's how I learned float and clear).
Even though it's often dead, there are a few SO users who will check the CSS Chat Room regularly (myself included), so if you have general questions (inappropriate for an actual SO question), feel free to ask there, and someone will eventually ping you back.
Also, I've created a Useful CSS Links document with links to official documents, several tutorials, and other CSS resources.
You might be getting mesmerized by the pretty blinking lights and forgetting to watch how everything is connected together. Just like you can get too focused on how a node in the DOM is affected by your javascript, you can't forget about the parents and siblings and how they all fit together. Your biggest problems are probably positioning. Remember how all the elements are connected together and that will solve a lot of confusion.
I'm sure you've already been here, but just in case:
Learn CSS:
http://w3schools.com/css/default.asp
Learn CSS3:
http://w3schools.com/css3/default.asp
However, the best way to learn this stuff is by trial-and-error. HTML and CSS are unique in their forgiving approach to malformation/errors. This, along with the fact that no two browsers render HTML/CSS exactly alike, presents a certain ambiguity that even experienced HTML/CSS developers occasionally grapple with.
Still, learning this stuff is a blast, and really rewarding once you get a handle on it. Happy coding!
I wanted to know what various guidelines state about the usage of this. Sometimes I use "this." to get the auto popup help versus to make any distinction of the code. I feel this is sorta bad style but can't say for certain.
What do various C# and .NET style guidelines state about trivial this usage?
(Editors please don't remove this post. This is a legitimate question because I am phrasing it as what style guidelines state about this and not opinion where style guidelines are formal guidelines, i.e that one can find on the net and are published.)
You can use control space in the editor to pull up the intellisense box. You should reserve using this explicitly to situations where not using it would cause confusion.
It makes more sense to use 'this' than to resort to a naming or prefix scheme in order to be less ambiguous. Since the point is usually to make code more readable using 'this' allows for clearer interpretation and less chance of bugs.
What is the benefit of writing meaningful css .class and #id names? Do screen readers speak to help the user understand the meaning and purpose of content inside the tags?
Generally-speaking, it's beneficial for the developer/designer only.
Again, as all your recent questions on semantics, the answer stays the same:
It all depends on the data-context of the entity in question.
If your element holds a meaningful field, it is useful to assign it a class (even if you do not want to apply CSS to it) just to easily define that particular field:
<span class="username">Andrew Moore</span>
Doing so has the following advantages:
It easily identifies the field's content in your code.
It increases maintainability.
It helps parsers and third-party applications to fetch this field's value.
Microformats are just a larger example of this. Simply put, they are a set of pre-defined elements and attributes that hold a particular set of data, meant to ease parsing by third-party tools.
Other answers are good, but I will focus on the scraping/third party tools aspect here.
Case 1 is spiders and crawling like search engines. If they parse your page and see something like id="username", they will be more likely to figure out some meaning in that than id="div-style-32". Granted, I'm not sure Google is doing this sort of thing now, but it could be if more people were better about it.
Case 2 is people writing scripts to pull down the HTML and process it in order to extract its content as data. Pretty much anyone who wants to do this can with any markup, its just a matter of how annoying it is. Cleaner and more well described markup allows the scraper script to more easily find the information it needs due to it's increased semantics.
This also includes things like browser extensions or Greasemonkey scripts that allow users to alter the behavior of the site. It will be easier to create these modifications with cleaner markup.
But if you don't want people scraping or modifying your site with client side extension, there is little you can do about from a technical standpoint. You can't stop it, you can only make it more of a pain in the ass. And the benefits of maintainability for the site developers are huge. So really, why not?
In short it makes all the different things you or others could do with your site easier to do.
You don't do it for the machines but for the humans.
If we only cared about machines we'd still be coding in assembly :)
this is my firts post here ever.
I have to develop an aplication for a group of people with special needs. The functionality is really trivial, however, i have no clue of how to do the interface for them to be able to use it.
Their intelectual habilities are perfect, they are actually studying high school, but one of them types with his nose which needless to say, is very dificult and another one types reaaaaaaally slowly with only one of his fingers and neither can use the mouse.
I was wondering if i could use javascript to develop a usable interface, based on huge grids or something like that or maybe you guys have a better idea.
Political incorrectness aside, why don't you ask them? You're talking about accessibility here, if they're using computers they must be able to tell you about what they like or dislike about user interfaces that they've encountered.
I'm going to split my answer into two parts - design and implementation.
From a design perspective, it's important not to be intimidated by the fact that the users use a computer in a different manner. Treat this like any other project. Observe how they currently use other apps, and ask about the kind of things that they find helpful, or have difficulty with. If they claim nothing is difficult, ask a teacher or assistant, who will be familiar with the kind of things they struggle with.
Once you've started implementation, try an idea and get initial feedback. If you simply ask how they find the prototype, they'll likely say it's ok. Instead, try observing them using it without saying anything or giving guidance. If they get stuck, let them find their own solution to the problem. If appropriate, you could ask the user to speak their thoughts out loud (e.g. "I need to save this form, so I'm scrolling to the bottom, and clicking save").
On the development side, try to use web standards (valid HTML, CSS and Javascript). People often point to the "Web Content Accessibility Guidelines 2.0" (WCAG2) but this is quite turse and hard to understand; there are many more friendly articles on "Web Accessibility".
Someone with a physical disability is likely to use an alternate input device, such as a "Switch", onscreen keyboard, head-tracking device, a device for pushing keys on the keyboard, or speech recognition. Many of these methods involve simulating the keyboard, so by far the most important thing is to consider the accessibility of your site without using a mouse. For example, try tabbing through the page to see if you can access all elements in a reasonable amount of time. Consider using the acesskey attribute to provide an easy way to jump to different parts of the page (using 0 through 9 is often recommended so you don't interfere with browser shortcuts).
Also make sure that no part of your site is time-dependant, as different users may take different amounts of time to perform a task. For example, don't use the onchange Javascript event to update a page based on a listbox selection. Ensure you have alt text for images, so it's accessible for speech recognition. make the pages short enough so that excessive scrolling isn't required, but not so short as to require following lots of links.
Those are just some ideas to get your mind going in the right direction - but there are many accessibility resources on the internet - steal freely, and don't reinvent the wheel.
I realise I haven't addressed your question about Javascript - that's because I think it's probably one of the less important considerations. If possible, use Progressive Enhancement techniques to make the site work with and without Javascript. You might also look into the WAI-Aria standard for giving semantics to your Javascript.
And finally, to reiterate my initial point - make something simple, show it to the users, tweek, and show again.
It doesn't really matter what technology you use. Use whichever suites you.
But, make sure that you make UI components BIG in size(Bigger buttons, bigger font, bold font, coloured font(are there any colour blind?). This is for the ease of use of people (you said someone types with nose).
Also, better to have audio as informative source along with the usual screen display whenever some wrong action is performed on the application. This way visually impaired people will be assisted more.
Do it well, you are doing a divine job.
The first thing that you should read up on is the Web Content Accessibility Guidelines written up by the W3C.
In a nutshell this document describes the basic principles for people with disabilities in general.
For your needs regarding persons with special needs, you might want to look at Jakob Nielsen's article on Website Usability for Children, wherein principles of web design for young children or people with otherwise limited cognitive ability are outlined.
Many frameworks seek to abstract away from HTML (custom tags, JSFs component system) in an effort to make dealing with that particular kettle of fish easier.
Is there anything you folks have used that has a similar concept applied to CSS? Something that does a bunch of cross-browser magic for you, supports like variables (why do I have to type #3c5c8d every time I want that colour), supports calculated fields (which are 'compiled' into CSS and JS), etc.
Alternatively, am I even thinking about this correctly? Am I trying to push a very square block through a very round hole?
What I found works best is to really learn CSS. I mean really learn CSS.
It can be a confusing language to learn, but if you read enough about it and practice, eventually you'll learn the best way to do things.
The key is to do it enough that it comes natural. CSS can be very elegant if you know what you want to do before you start and you have enough experience to do it.
Granted, it is also a major PITA to do sometimes, but even cross-browser issues aren't so bad if you really practice at it and learn what works and what doesn't, and how to get around problems.
All it takes is practice and in time you can become good at it.
If by some chance you happen to be using Ruby, there's Sass. It supports hierarchical selectors (using indentation to establish hierarchies), among other things, which makes life easier to an extend from a syntactical perspective (you repeat yourself a lot less).
I am certainly with you, though. While I would consider myself a small-time CSS expert, I think it would be nice if there were tools for CSS like there are with Javascript (Prototype, JQuery, etc.). You tell the tool what you want, and it handles the browser inconsistencies behind-the-scenes. That would be ideal, methinks.
You can always use a template engine to add variables and
calculated fields to your CSS files.
This elaborates on my previous answer.
When I first started using CSS I also thought it was a pain that it didn't support variables, expressions, etc. But as I started to use it more and more, I developed a different style to overcome these issues.
For example, instead of this:
a { color: red }
.entry { color: red }
h1 { color: red }
You can do:
a, .entry, h1 { color: red }
You can keep the color declared in one spot by doing this.
Once you use CSS enough you should be able to overcome most browser inconsistencies easily. If you find that you need to use a CSS hack there is probably a better way to do it.
Sorry to say that guys, but all of you missed the point.
The word abstraction is the key. Say you and Sally are making a website. You are styling forms while she makes the corners round. Both you and she have defined a handful of selectors.
What if, unknowingly, you picked class names that clash with the ones of Sally? You see, you can't "hide" (abstract out) the details when you work in CSS. That's why you can't fix a bug in IE then create a self-contained solution that others can use as-is, much like you call procedures in a programming language only caring about pre- and postconditions and not thinking of how it works on the inside. You just think of what you want to accomplish.
This is the biggest problem with the web: it completely lacks abstraction mechanisms! Most of you will exclaim, "It's unnecessary; you stop smoking crack!"
You will instead do the job of say, fixing layout bugs or making round corners or debating on the "best" markup for this or that case over and over again. You will find a site that explains the solution, then copy-paste the answer then adapt it to your specific case without even thinking what the hell are you doing! Yes, that's what you will do.
End of the rant.
Then comes the multiple browser issue
There is this that helps remove some inconsistencies from IE. You can also use jQuery to add some selectors via javascript.
I agree with Dan, learn it and it's not so much of a problem, even fun.
See, this is the problem with SO-- every answer so far has made a valid point and should be considered the final answer. Let me try to sum up:
CSS is good! To expand further, there is a learning curve but once you learn it many things will be much easier.
(Some) Browser inconsistencies are solvable generically.
(Some of your) Variable and calculated field functionality can be taken care of through whatever templating engine you use.
I think a combination of all these certainly solves a large sum of problems (although to be fair deeply learning CSS is not an option for everyone; some people just don't use it enough to justify the time).
There are some problems none of the above points cover (certain types of calculated fields would require writing a JS library for, me thinks) but it's certainly a good start.
For variable support, I have used PHP with CSS headers to great effect for that. I think you can do it in any language. Here is a php sample:
<?
header('content-type:text/css');
header("Expires: ".gmdate("D, d M Y H:i:s", (time()+900)) . " GMT");
$someColorVar = "#cc0000";
?>
BODY {
background-color: <?= someColorVar ?>;
}
Solutions to problems seem to often involve jiggering numbers around like some chef trying to work out exactly how much nutmeg to put in his soon-to-be famous rice pudding
I only get this when trying to make stuff work in IE.
If you learn CSS to the point where you can code most things without having to look up the reference (if you're still looking up reference regularly you don't really know it and can't claim to complain I think), and then develop for firefox/safari, it's a pretty nice place to be in.
Leave the pain and suffering of IE compatibilit to the end after it works in FF/Safari, so your mind will attribute the blame to IE, where it damn well belongs, rather than CSS in general.
CSS variables are coming (relatively) soon, but I agree they are long overdue. In the meantime, it is possible to use a CSS templating engine such as Sass, or even the dynamic web language of your choice, to generate your stylesheets programmatically.
For CSS frameworks, you could consider YUI Grids. It makes basic layout a lot quicker and simpler, although used in its raw form it does compromise on semantics.
The key to a real understanding of CSS (and the browser headaches) is a solid understanding of the box model used by the CSS Standards, and the incorrect model used by some browsers. Once you have that down and start learning selectors you will get away from browser specific properties and CSS will become something you look forward to.
Also check out BlueprintCSS, a layout framework in CSS. It doesn't solve all your problems, but many, and you don't have to write the CSS yourself.
I believe the common errors beginners have with CSS are to do with specificity. If you're styling the a tag, are you sure you really want to be styling every single one in the document or a certain "class" of a tags?
I usually start out being very specific with my CSS selectors and generalize them when I see fit.
Here's a humerours article on the subject, but also informational:
Specificity Wars
CSS takes a bit of time to learn, but the thing I initially found most discouraging was the fact that so many hacks were needed to get all browsers to behave the same way. Learning a system which doesn't adhere to logic seems dumb... but I've clung to the vague belief that there is logic behind each browser's idiosyncrasy, in the form of the W3 spec. It seems that the new generation browsers are slowly coming into line - but IE6 still makes my life hell on a daily basis.
Maybe creating an abstraction layer between compliant/valid CSS code and the browsers' shoddy implementations wouldn't be a bad thing. But if such a thing was created - would it need to be powered by JS (or jQuery)? (and would that create an unreasonably burden, in terms of processing cost?)
I've found that it useful to 'level the ground' when scripting with CSS. There are probably loads of different flavours of reset script out there - but using YUI resets has helped me to reduce the number of quirks I'd otherwise encounter - and YUI grids make life a little easier sometimes.
#SCdF: I think your summary here is fair. But the argument that some people don't have the time to learn CSS is bogus - just think about for a second. Substitute a technology that you've mastered and you'll see why:
I. Hate. Java. Is there something out there that will just write it for me? Not everyone has the time to master Java.
CSS is certainly an imperfect technology - I have high hopes that 5 years from now we won't be dealing with browser incompatibilities any more (we're almost there), and that we'll have better author-side tools (I've written a Visual Studio macro for my own use that provides the the sort of variables and calculations that you describe, so it's not impossible) - but to insist that you should be able to use this technology effectively without really understanding it just isn't reasonable.
You are thinking about this correctly though, you're probably still going to need to understand the different browser implementations of CSS. This is just understanding the environment your application lives in.
To clarify: this isn't about understanding CSS. If you know the language well, you've still got to handle the redundancy, duplication and lack of control structures in the language.
Ive been writing CSS solidly for more than 10 years and I've come to the conclusion that while the language is powerful and effective, implementing CSS sucks. So I use an abstraction layer like Sass or Less or xCSS to interface to the language. These tools use a syntax similar to CSS so you're solving the problem in the problem's domain. Using something like PHP to write CSS works but is not the best approach.
By hiding the problems in the language through an abstraction layer, you can deliver a better product that will maintain its integrity throughout the full life cycle of your project. Writing CSS by hand accelerates software rot unless you're providing solid documentation which most CSS coders aren't. If you're writing a well documented CSS framework, you probably wouldn't write it by hand anyway. It's just not efficient.
Another problem with CSS is due to it's lack of support for nesting block declarations. This encourages coders to build a flat, global set of classes and handle the name collisions with a naming convention. We all know globals are evil but why do we write CSS in such a way? Wouldn't it be better to give your classes a context instead of exposing them to the whole document model? And your naming convention may work but it's just another task you must master to get the language written.
I encourage those of you who pride yourselves on writing good CSS to start applying some of the best practices from programming to your markup. Using an abtraction layer doesn't mean you lack the skill to write good CSS, it means you've limited your exposure to the weaknesses of the language.
You don’t need an abstraction away from CSS—you need to realize that CSS itself in an abstraction. CSS isn’t about putting pixels just so on the screen. Instead, it’s about writing a system of rules that help the browser make those decisions for you. This is necessary, because at the time you write CSS, you don’t know the content the browser will be applying it to; neither do you know the environment where the browser will be doing it.
Mastering this takes time. You can’t pick up up CSS in a weekend and be good to go. It’s a bit deceiving, because the language has such a low barrier of entry, but the waters run deep. Here is just a few of the topics you should seek to master to be proficient in CSS:
The Cascade and Inheritance
The Box Model
Layout methods including floats and the new flexbox
Positioning
Current best practices such as SMACSS or BEM to keep your styles modular and easy to maintain
You don't need to know this all up front, but you should continue pushing forward. Just as with other languages and programming in general, you need to continually seek to learn more and master the craft. CSS is a fundamental part of web development, and more developers need to treat it with the same respect they afford other languages.