Related
What is the point of these CSS Frameworks? I don't understand them. When I look at them, all I see is boring layouts that seem overbearingly-difficult to adapt to your own unique designs.
Is this the case, or am I just missing something here? I'm referring to (frameworks in general) things like Blueprint, Less, Skeleton, 960 Grid system, Base, Gridless, etc etc etc.
I know this is a really simple thing but I just don't get it. I have searched but have not found anything that helps me to understand what the big deal is. When I look at their code, all I see is mess. Weird class and id names all over the place.
(This isn't a rant or complaint by the way, I just really don't get it.)
CSS frameworks are pre-prepared software frameworks that are meant to
allow for easier, more standards-compliant web design using the
Cascading Style Sheets language. Most of these frameworks contain at
least a grid. More functional frameworks also come with more features
and additional JavaScript based functions, but mostly design
orientated and unobtrusive. This differentiates these from functional
and full JavaScript frameworks. -Wikipedia
Advantages
They can help you learn CSS. You might just literally not know how to pull off a solid multi-column layout. A framework may be a
good place to get your feet wet understanding how CSS works.
They provide code that you just don't need to write from scratch every time, like resets. I've long been a proponent that the star
selector (*) margin/padding reset is a fine reset. I use it all the
time. But... if you are starting a major new project that is going
to be loads of pages, live for years and years, and will grow over
time, you should invest right away in a more robust reset. All
these frameworks start with brilliant resets that cover all the
bases and will have you covered for years to come.
They relieve cross-browser concerns. You can't undervalue this. We've all felt the burn of finding out our sites are borked
in some browser or another at a hugely inopportune time. Frameworks
are built to bring their magic to all browsers.
It helps you build good habits. Like including a print stylesheet in your projects. I always intend to build one, and I
often do, but the chances are a lot higher that I do it if I have
one there from the get-go.
They encourage grid based design. Which is a good thing. Grids don't mean boring! They just help you achieve better
readability, scanability, balance visual weight, flexibity,
expandability, and just overall page page cohesiveness.
They come with documentation. If you need help getting started, framework generally come with some support files. This can be
particularly nice if you are designing a site you will be handing
off to a client. You can just let them know what framework you used
and refer them to that documentation for support requests.
They lay groundwork. If you are using something like YUI, your life will be a lot easier if you use All-YUI-Stuff-All-The-Time.
It's built to work together and built for expandability.
CSS-Tricks
Also see: Comparison of CSS frameworks
I've been using XHTML for about 3 years now, and didn't care much about HTML5 and CSS3 arrival. Several months ago I've stumbled upon HTML5 Boilerplate and I'm starting to get very interested in it right now.
The only thing I can't find yet is drawbacks of using this set of best practices. I know, that the main goal of it to make site look the same on wide variety of browsers, but is there something I should be aware about?
Is there something I should be aware about?
Yes, definitely. It's not a plug-and-play thing. Or at least, it could be like that but it hasn't been conceived for that. And if you use it this way you can't enjoy its best. Boilerplate is very flexible and you have to learn how to customize it. Full stop.
My personal suggestion is to start experimenting with it and study the features it has to offer. Luckily for us it's well documented and you can learn a lot. Not only the boilerplate itself, but also the rules and best practices about HTML5, CSS3, resources loading and related issues/workarounds on performances, browsers quirks and how to fix them, tricks for mobile development, polyfills and conditional loading and a lot of other crazy stuffs. Once you are aware of its possibilities, if you'll find drawbacks you'll be able to customize the base boilerplate.
Start from here, read the docs, follow every link and don't be tempted to take shortcuts. It takes time, but you'll be rewarder very well. If you have troubles ask.
For something more concrete, a drawback I found very quickly (but someone consider this a plus) is that the boilerplate doesn't provide a CSS grid. Not a huge problem, I discovered that adapt.js is easily integrable, so I replaced normalize.css with adapt.js's reset stylesheet and used the grid.
Two things I noticed couple months back is the way javascript gets loaded at the bottom of the body. I'm not a big fan of this if not only it looks dirty. Also I tested the loading myself and didn't notice any better loading of javascript. In fact it ran a couple ms slower on a huge script.
Also the normalize.css I tried couple of times but found myself restyling more paddings and margins than before. Which is normal ofcourse since it's goal is somewhat similar but a different approach. I changed this to Eric Meyer's reset.css just because I'm used to it.
I really like the modernizr script and the way to implement things for x-browser results.
Google Analytics implementation for example.
Another small thing I remember was the placing of the title tag. I changed it to the top position for SEO reasons.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I'm working on a little html/css framework that I can use for most of my websites, at least to have a basis to build on. Here's what I've been using so far:
CSS framework
Reset.css - I use the one by Eric Meyer, www.meyerweb.com.
Typography.css - All main typography styles for the site (from blueprintcss.org)
Forms.css - basic form styles (from blueprintcss.org)
Wireframe.css - Here I set up the wireframe for one, two and three columns plus a header and footer. I used the Holy Grail technique, and implemented it so that by setting a class of 'onecolumn', 'twocolumns' or 'threecolumns' to the container div I can switch between the three.
Basic techniques
Some techniques I have some pre-fab examples of for me to re-use in any website:
Suckerfish dropdown menus - Horizontal and vertical in various versions
Sliding Doors tabs - although I try to use CSS3 where possible
Scripting
jQuery - I try to use it as little as possible (that is, if there's css solutions at hand, like the Suckerfish dropdown menu vs. jQ menus)
Plugins
None, yet. I looked into css3pie yesterday and it looked real promising.
Yet to look into
What I haven't used so far but might be interesting is css and js minifiers. Also, currently I include the 5 css files mentioned above in the main.css with #import, maybe I should have them merge automatically before I upload?
Also there's CSS grid systems of course. I never got the hang of those, but maybe I should give it another try. I know the 960 grid is very popular, but I'm not sure if I want to use classes purely for markup (grid_4, column_5, etc.) To me it's a bit like <span class="red"> to make a text red, that's just as bad as using inline style.
Anyway, this is just a basic setup and there's plenty of problems in websites that are not yet incorporated in this framework. So, what should I really check out to improve my framework? (HTML5 and CSS3 welcome, no flash please :P)
Suggestions
I'll make a list here of suggestions made below that I'll check out.
HTML5 Boilerplate
IE 7/8/9.js
Modernizr
I highly recommend the HTML5 Boilerplate
HTML5 Boilerplate is the professional
badass's base HTML/CSS/JS template for
a fast, robust and future-proof site.
After more than two years in iterative
development, you get the best of the
best practices baked in: cross-browser
normalization, performance
optimizations, even optional features
like cross-domain ajax and flash. A
starter apache .htaccess config file
hooks you the eff up with caching
rules and preps your site to serve
HTML5 video, use #font-face, and get
your gzip zipple on.
Boilerplate is not a framework, nor
does it prescribe any philosophy of
development, it's just got some tricks
to get your project off the ground
quickly and right-footed.
The best thing you can do is use it. That's the only way you're ever really going to build a framework that does everything you're going to need. Afterall, you don't know everything it'll need until you actually need it.
Where I'm working we have our own PHP Framework and it's been a contsantly changing entity where bits get added when they are required because they weren't originally needed in the spec.
As long as you have something that works for your first project you're underway. Just try it out, add to it when you need something, and optimise where and when you can!
If you are looking into minifiers, you're probably willing to run your code through some sort of build script before testing and deploying. If that's the case, I'd suggest looking into LESS for your css: http://lesscss.org/docs
LESS is pure awesomeness.
I don't know how much client-side scripting your projects require, but if it's anything extensive you might want to look into using something like M4 or the C++ preprocessor to add support for includes, ifdefs, etc... this can help keep your code organized and allows you to maintain debug code that doesn't appear in the production build. This post sort of takes that idea to an extreme, but it might give you some ideas.
Out of curiosity, what server-side language are you using?
Drop Suckerfish.
With the growing number of touch-only devices (mobile phones, tablets), using hover-based UI elements will just piss off the users.
I can't believe I forgot (and nobody has mentioned) fontsquirrel. I've used it to embed a few fonts now and it really works like a charm.
From a performance perspective, I'd use Compass and SASS with the built in BlueprintCSS framework, it mainly takes care of all reset needs to render the same cross browser, you get to use mixins instead of inline classes for your grid. And most of all you end up with one tiny css file that loads real quick. I also use modernizr, html5boilerplate, css browser selector only with serverside php, faster rendering. If your torn between SASS and LESS, the blueprint integration with Compass+SASS is spectacular. Hope this helps!
why create one more when there are so many out there already.
I would rather suggest you to contribute to the frameworks you are referring if you feel something is wrong or missing. That way you will also help everybody who are already using it.
I agree with Alex here you should start with using it, this will make sure it has everything you want,
and let me know when it is ready for us to use ;)
The Blueprint CSS grid technique is better than the 960gs in my opinion. The thing I dislike about 960 is that the the gutters between columns are formed by two "half gutters" on the left and right of each column. It's bizarre; you wind up with half-gutters on the left and right of your layout.
There's also the CSS browser selector jQuery plugin. This uses a few simple selectors in your CSS to tell which browser to do what:
.ie .myClass
{
background-color: #f00;
}
.ff .myClass
{
background-color: #00f;
}
I use it on my website and it's a much better solution than having CSS hacks or Conditional Comments.
Question asked a couple minutes ago gave me this idea... If you were to teach someone HTML today, it would be significantly more difficult than a couple years ago.
For example, the <font> tag is simple, straightforward, and easy to understand. But it's now slated for the chopping block in future versions of HTML. I couldn't imagine trying to learn HTML today the "right" way with CSS and style:-type markup.
So where's the line? Should someone learn tags that are easy to understand but deprecated? Or should you insist on "getting" CSS and validation-passing styling from day one?
Learn the correct and valid way. It will reduce the bad habits and in the long run you will have to learn less.
I disagree. I think HTML is simpler today. You look at modern, clean HTML and that's what you see: clean, HTML, with minimal markup.
Presentation wise, it's nothing to shout at. But CSS fixes that.
CSS makes it even better. Simple changes have dramatic effect. Those dramatic effects lead to quick satisfaction and feedback. It also lets folks make sweeping changes, that affect "everything" rather than having to run through and propagate those changes.
That makes "mistakes" cheap to fix, which, again, leads to quicker success, and faster confidence.
Are there a lot of tricks of the trade in CSS and HTML? You bet. But most folks don't need that right level of expertise right away.
So, IMHO, HTML is a much better animal today than in the "old days".
It would depend on the situation. I can see possible cases where I may want to teach someone as little as possible. Say they have to learn a litle htnl in order to to edit some content on a page every so often, and I know this person to be someone who won't bother to learn more than he or she needs to.
However if I were teaching someone who was serious about learning definitely I would definitely try to have them learn the right way. I learned too many bad habits of my own and am still having to learn the "proper" way of doing things. I feel responsible for anyone I teach, and would like to spare them that hassle.
And learning to do things properly is really not that hard and it's a heck of a lot harder than unlearning the wrong way and bad habits.
HTML has been trending away from style-markup and toward semantic markup for many years now. There are lots of good reasons for this; I don't think you asked this question to get a separation-of-style-and-content lecture :)
In terms of learning HTML, I think people learning HTML can understand the simple lessons about how tags turn into webpages using elements like <p> and <ul>. When they inevitably get the "ew its ugly! how do I fix it!" itch, introducing CSS via the style attribute is not the worst thing in the world, as long as people eventually learn to style elements from an external stylesheet.
I certainly learned HTML in the days of table-based layouts and font tags, so maybe I am underestimating their usefulness as teaching tools. But I think driving home the point that HTML isn't layout early will pay dividends later.
Actually, I think the OLD way is harder for a new person. Perhaps you don't see it that way because you're used to thinking in old patterns. It's like this almost-retired DOS/QuickBasic programmer I work with sometimes might say: "Programming is so much easier to understand when all you have is one file and you just read down the file from top to bottom." Most people would agree it's not best to learn programming by starting with QuickBasic.
So why is the NEW way easier?
Because it separates concerns. Content and presentation are neatly broken into separate places.
You can start by teaching basic markup with <h1>, <p>, <b>, <div> and all of the basic tags. Give them a chance to understand the basics by creating HTML that Mosaic can display just as easily as IE8 (OK... bad example probably... you probably have to enable some sort of compatibility mode in IE8 for that ;-)
Once content has been mastered, move on to presentation. Show them how they can edit a separate file (the CSS file) and change the presentation of the entire document (or website) without ever touching the original file.
Now THAT'S simplicity.
Definitely do not teach outdated methods. You used to teach in just one step, HTML with styling tags.
Now, just teach in 2 steps. First teach a few basic semantic tags such as headers, paragraphs, and lists, then teach them how to make a stylesheet to style those. Then move on to more tags and more advanced styling from there.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
For design websites is it better to do it your self by learning HTML/CSS or using web design programs? and why?
I've bounced back and forth between hand coding and Dreamweaver in my history as a web developer.
I originally started out hand coding HTML. This was back in the day when table layout was king, and editing nested tables became a real headache. Couple this with a lack of good tools for visualizing hidden elements and this quickly became a nightmare.
I started using Dreamweaver primarily to speed up my table design workflow. Soon, however, Dreamweaver's templating system became a godsent when I started producing static websites that had no server backend. Being able to update one template and have it propagate across the entire static site cut down my cross-page inconsistencies to nearly zero.
More recently, the whole web 2.0 push has got me, and almost everyone else, back into the hand coding game. I found Dreamweaver wasn't really suitable for the compliant designs, since it was heavily table-centric. I find that most of the HTML I write these days is so straightforward and simple there's little need for an editor. Additionally, all my development is now dynamic once again, so there's no need for a static html generating template system anymore.
Learn for yourself so you can figure out how to do things exactly how you want them to be done, and not have to rely on some sort of program to figure it out for you.
Like anything else in technology, learn the core concepts first, and then use a tool to automate the things you have mastered. By doing so, you will gain a better understanding of how everything works together, and you be able to easily tell when something goes wrong. In this way you will not be bound to any one design tool, and can use whatever works best because you understand the core concepts.
In the words of Richard Feynman,
"That which I cannot create, I do not
understand."
They really serve two purposes, and either one is "better" for it's purpose.
If you learn to do it by hand, you will:
Have more control over exactly what is happening
Have less extraneous code
Be able to maintain your code more easily
If you use a program, you will:
Be able to design visually
Possibly be able to design more quickly
Not have to learn to write CSS by hand
It really depends on what your goal is.
I prefer HTML/CSS by hand because you have the most control over the code. Most design programs will add additional markup that is not required. Even simple WYSIWYG JavaScript editors add extra markup. Although, not a huge difference in file size, the additional markup will add up over time. I would also argue that its easier to maintain code when you know what went into its creation.
Additionally, you'll learn a lot more by taking the time to do it by hand.
Personally, I always edit my HTML/CSS by hand using editors with auto-completion if I can, because that always makes life easier. You should definitely always learn a language as much as you can before you start relying on any program to generate code for you, because most of the time you end up fixing what they gave you.
I tend to do it all by hand.
Doesn't matter what IDE or
server-side language I'm using.
Mark up is markup. Being able to do
it rapidly by hand is valuable.
More often then not, you'll have to
edit some markup manually. By
writing it from scratch, you're
already very familiar with the structure of the markup.
You don't have to spend any time
orienting yourself to the
designer-generated markup.
Although not necessarily a rule,
those who live in the designer I've
found to be less sharp in their
markup and code craftsmanship.
I prefer the by hand approach. That way you know exactly what you're getting. Plus I haven't found an editor that produces HTML/CSS that doesn't need some tweaking especially if you are targeting multiple browsers.
Doing it by hand. Using design programs tends to insert a lot of extra markup you don't really need, which will just complicate your ability to learn.
If you do it by hand you at least know what was inserted where, and why. Plus there are a lot of good websites out there that can walk you through the basics.
IMO you will still learn using web design programs like Dreamweaver, since you have to look at the source and make it fit your exact desires,and its quicker. But doing it by hand will give you the more you write the more you learn type of thing that I agree with 100%
This is a bit vague.
I think that "better" (qualitatively) depends greatly on (1) the competency of the designer, and (2) the sophistication of the application.
Regarding "better" (as in "advisable"): using an application can be a crutch that may fail to save you in all cases. Knowing how to "raw code" html and css is valuable in understanding the limitations of the application and working around those limitations. For that reason alone I suggest knowing how to do it by hand and then keep a sharp eye on the output generated by the application, should you choose to use one.
The absolute best is when you understand what you are doing - you can only do this by coding by hand.
If you don't know HTML or CSS and you use a WYSIWYG editor then how can you be sure everything is right? You can't!
If you have a good understanding of HTML and CSS why would you use a WYSIWYG editor? They make things harder because you can't see the code and extra tags and rules get inserted without you knowing.
Coding by hand is always the best.
Why should you know about xhtml/css ?
Here is some reasons:
Respect semantics meaning
DOM compliant (you know the javascript mess)
Easier to maintain
Search Engine Optimization
You still think it takes a longer time to design/integrate a website ?
Think of use vi, eclipse, quanta, and probably some others...
By hand is the obvious answer, because your website/application will be, well, better. (And also because, if you use JavaScript, it's good to traverse through the DOM of a document you've written yourself, versus a generated one that you have to examine beforehand.) But that's mostly only because the visual tools that exist today really suck (I'm thinking of Dreamweaver). It's definitely possible to create a good visual editing (WYSIWYG) program that actually generates good HTML/CSS/JavaScript, but nothing even close has come up yet, so right now hand-coding is much, much better.
I'm not going to read the responses, so its quite possible someone has already said this, but oh well.
First and foremost, you should always write out your HTML / CSS by hand. The reason for this is that no matter how advanced an HTML editor is, it will never be as good as it could / should be. For "good" html / css, you will actually end up writing your page in a different order than what you see.
For example, a page that is displayed like:
________________
|logo |
|----menu------|
|..............|
|...content....|
|..............|
|....footer....|
----------------
"should" actually flow as follows:
<h1>title of site</h1>
<div id="content">.....</div>
<ul id="menu">....</ul>
<div id="footer">...</div>
which an HTML editor would simply throw a hissy fit if you did it through the nice pretty gui. What may be advantageous is to use Web Expression 2 or Visual Studio for its intellisense. It may help speed up (or maybe slow down) your learning curb.
I really recommend Transcending CSS Design if you are already familiar with HTML / CSS. Otherwise grab a CSS book first even over an HTML book. Styling through CSS will teach you proper semantic HTML (or should,anyway).
I like to code by hand because i can keep my code clean and tidy that way. HTML is not very hard anyway.
If you decide to code by hand you will need an editor that supports syntax highlight, and you will need to validate your code as often as possible to avoid errors (this is good practice anyway). This extension for Firefox will ease your work a lot: users.skynet.be/mgueury/mozilla/