Related
Looking for help on the HTML/CSS side of things. Obviously light, lean code is ideal...But does the styling of these elements really matter for a small web-app?
Generally speaking, are there any HTML form elements you wouldn't touch because of the hit?
From a loading perspective, you'll be fine with just adding some css. It shouldn't be very noticeable.
That said, you can get in trouble quickly by trying to style input elements to look a specific way. Honestly it depends what your trying to accomplish. For example putting a border around a radio button is close to impossible. Also making custom select boxes can be difficult pending the design. Styling these elements can get time consuming to make sure they work cross browser. I'd recommend keeping them standard whenever possible to ensure your site looks good across the board and saves you development time.
CSS loads very fast, and is very light compared to pretty much everything else you can do to a web page, so I wouldn't be worried about it. This answer assumes that you didn't mean styling with images.
There is really no need to worry about speed when sticking to pure html and css. I feel like the trend with javascript webapps is to reduce the amount of html tags used to a minimum and do a lot of javascript programming. In a nutshell when you write html code try not to use obscure tags for the sake of readability but as for loading time they are all just text and generally load very fast
Keep accessibility in mind as well: some folks have a hard time with some color combinations, and some folks need to bump up the size of text to make it readable. Your controls should deal with both issues.
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/
This question already has answers here:
Why not use tables for layout in HTML? [closed]
(66 answers)
Closed 5 years ago.
I have been pondering on this over the last couple of days. I'm currently writing a web application (actually adding a screen to an existing, extensive application). I know that using "tables" for layout is a big no-no. But in this app, all of the pages use tables for layout. I decided to do my new page using divs instead.
But I came across 2 hurdles.
A lot of the layout stuff that I need to do were already done on the other pages and if I use divs instead, I cant reuse any of that (CSS's and JS and that kinda stuff). That leads to more work and pushes out my completion date.
Some of the more complex parts of the layout are really difficult to do using divs and are really easy to do using tables. Maybe its just me being "old-school"y as I am not much of a web/html kinda guy (I get by).
So, why can't I use tables? I'm not trying to be argumentative, just want to see if there are any compelling arguments beyond the "Its the right thing to do" type stuff. I know it is the right thing to do. I'd like to know why?
Implementing your layout with divs, spans, etc, offers a ton more flexibility over tables. Consider floating, auto wrapping of block content vs. horizontal scrolling, specifying where an element should exist on a page, etc. Content is just plain easier to manipulate via CSS when not using tables.
When using tables you're pretty locked in to a strict structure.
Now that doesn't mean it's absolutely the wrong thing to do. From your information I'd likely stick with the theme of the application for consistency sake and implement using tables. Make the best choice for the situation vs. following "the rules" on what's popular right now.
Hope that helps!
Ian
Doing css layouts make it easier to change the layout of your page later on.
Tables also make your html harder to read and edit.
According to this page..
make your redesigns more efficient and less expensive
help you maintain visual consistency throughout your sites
get you better search engine results when you minimize your markup and use header tags properly. This reduces ratio of code to content.
make your sites more accessible to all viewers and user agents.
your pages load faster, file sizes will be smaller because table information isn't needed in every page.
and give you a competitive edge (that is, job security) as more of the world moves to using Web standards.
I'm going to post a contrarian view, just so you have some ammo. I realize this doesn't answer your question (why not use tables) but it does address the other responses you will see.
The future of CSS never gets here (note: from 2005)
Everyone else uses tables and there are valid arguments against every response others have listed.
You might find some middle ground by using "display:table" to turn DIVs into TABLEs. Of course, you can't do this because IE doesn't support it until v8.
I read a good point somewhere: when people are referring to side-by-side columns of equal height as the "holy grail", something must be wrong with the layout engine.
I mean, just look at the unmaintainable contortions some people go through to make it work: negative margins, pixel counts that must correspond throughout five different rules, etc.
So be practical.
That said, most of my designs use pure CSS. Nearly everything can be done in CSS just as easily as with tables (or even easier.) Start with the assumption that DIVs can do it, and maybe fall back on 1 table for a tricky multi-column layout. Even then, someone has probably found a solution for your layout so search first.
They are also bad for accessibility reasons i.e. screen readers don't read them correctly, but this is only if the data you are representing is not tabular data.
Saying that, due to deadlines etc. (the real world) I've resorted to using them for form layout because it's just so much easier.
Because the tag <table> implies it should contain tabular data.
Like Peter said, the universe won't implode if you do create table-based layout, but semantically, this should be avoided.
Semantics become increasingly important, since web pages are not always shown in a desktop browser anymore. Web standards are developing in a way that HTML describes the semantic structure of the document, not the markup; and as said: using <table> tags for tabular data is semantically correct.
Interesting related reads:
Should Tables be avoided in HTML at any cost?
http://en.wikipedia.org/wiki/Semantic_Web
First, you can usually convert a table layout to divs without too much trouble once you know the necessary CSS.
But more to the point, some of the reasons why tables are bad:
Not all your users are going to see the page using the browser's rendering engine. Some are going to use a screen reader, which may assume that when it encounters a table, it should actually read the contents out as tabular data. Essentially, you should think of it as a coincidence that tables have a certain layout "look" in a browser.
tables can't be rendered until the table and all its children have been parsed. A div can be rendered independently of its children, so you avoid the page contents jumping up and down on the page as the page is parsed, and get to show contents sooner.
There are good and valid reasons to prefer tables, but when you're used to tables, there's also a certain learning curve, so if you're pressed for time, this might not be the time to make that switch.
If you have the kind of constraints you mentioned, deadline looming, large existing code base, then use tables, the universe won't implode, but in the long term using css and welformed markup will allow you to create a nicer, cleaner, more maintainable website.
Tables are pretty ugly if you want to support text to speech readers (if you've got any kind of accessibility requirements, you pretty much have to use tables for tables and nothing else).
There is an SEO aspect of this as well. For SEO, it's better to have your content at the top of the page than at the bottom. (Sadly, studies suggest appears that putting a menu first is actually a good idea for accessibility, so the two imperatives clash.)
If you are having trouble with cross-browser support, I can suggest that you develop using Firefox. Its support for CSS development is much better than other browsers, and it's more standards-compliant (and hence more predictable). Later on, you can patch up for down-level browsers.
And, as Peter says, the universe won't implode. But using CSS for layout is cleaner in the long term. Redesigning something with the layout hard-coded can be a real pain. Check out the CSS Zen Garden for examples of what you can do. Of course, in the future, we'll have CSS table layouts, the best of both worlds.
Tables also affect the behaviour of search engines. Using CSS instead of tables is actually an SEO technique as well. The reason I heard for this is that search engines stop indexing after a certain level of tags, and layout using tables can become very deeply nested.
Using CSS for layout, rather than HTML tables provides a level of separation between your page content and the layout of that content.
With tables, your HTML markup has both your content and layout intermingled within the HTML code. This means is you ever want to have a different layout for the same content, you'll need to edit the intermingled code heavily.
By using a CSS stylesheet over your HTML markup you separate the code that provides the content (HTML) from the code that provides the layout (CSS). This makes it far easier to completely change the layout aspect of a web page without having to edit the content code.
The best example of this is the CSS Zen Garden website.
All that said, it's still far easier to do some layout techniques in tables rather than CSS, so there's definitely a "balancing act" there. (For example, even Google uses tables in it's page layouts!)
By using tables for layout you tie the content to the formatting, this is the main point that most of the disadvantages come from. It messes up the source, complicates site-wide formatting updates that could be easily done with CSS, etc. Using tables for layout also often means slicing images on weird places just to fit them in the cells, yuck.
you can use tables, but divs have more advantages.
but it's all in perspective.
Like you say, you are precious for time, so probably (on short notice) tables will be the choice to make. However, if you manage to make it div-wise, you will have a more maintable page, which you can use to refactor the other pages as well.
Jeffrey Zeldman wrote a great book on this topic: Designing With Web Standards. This book should be mandatory reading for every web designer.
Here are some reasons why tables for design are bad
Tables generate more markup -> More bandwidth usage
Tables makes it harder for search engines to index your pages -> Your site becomes less "searchable"
Tables makes it harder to change and tweak the visible appearance of your site -> More costly redesigns
...But most importantly: using tables for design adds presentation logic to your markup
That is bad because you want to separate your presentation from your content! HTML should only define WHAT your content is, not HOW it should look.
If you obtain this level of separation your site will...
...be more accessible by different kinds of browsers and other kinds of user agents.
...make redesigns much easier
The best you do not listen to the fanatics of CSS. These purists live in some imaginary world and will feed you the arguments of some abstract purity, semantics and the rest. You would not want to have this kind of people in your team. For now I've only seen yellow-mouth students to run around with "pure CSS design" ideas. They'll show you examples of very primitive CSS-designed sites, ignoring you whenever you ask them how you can accomplish some complex enterprise software design with it. Experienced developers already know this perfection is not possible.
What should you do? Follow the KISS principle. If CSS can help you implement your particular design idea, fine, the problem is solved. If you need to resort to some relatively uncomplex hack, it may be okay. But when it comes to some huge piece of code with dozens of rules to make a basic thing, which you easily and naturally achieve with tables, drop it.
It serves no purpose to create an incredibly complex and sophisticated tricky CSS design that noone else (and yourself after a couple of months) will be able to understand and support.
As for the "easy redesign", unless you only want to change colors and fonts, you will enevitably have to restructure your markup whether it is done with tables or without them. In the latter case, a high portion of your markup will serve no purpose except implement CSS trickery which will be useless for you new redesign idea.
Honestly, it's not your fault that the people responsible for further development of HTML/CSS don't do their job properly. You should not waste your and other people's time trying to find workarounds for something that should have been there ages ago.
HTML/CSS is a good example of how poorly some committee could do their job and brake the development of technology as compared to a single company with resources and commitment.
"The right thing to do" depends on your situation.
Yes, divs offer more flexibility, but at the end of the day, do you really need it? As far as the number of lines of code goes, I have found that a simple table is often quite a bit smaller that an equivalent div design.
It's faster to put together, and it works as reliably as possible in pretty much all browsers, which means you don't have to write a zillion hacks to make it work consistently AND it doesn't break down when a new display engine comes out.
Using tables for display is technically a hack, but it does the job, is easy to understand and maintain and is to a large degree future proof, so for a simple layout, considering that the rest of the website already uses tables for layout, I would keep using tables.
Besides, turning a Table into a "div" table which uses the new "display=table" attributes can easily be done with a few regexes (if you rack your brains, you can probably even do it with a single pass). If you know your regexes, you can replace a table with divs through an entire website in a matter of minutes, so the whole issue of flexibility is really not that big: when (if) you actually need to use divs and CSS positioning, just run a few regex, and you are set. And if you need more control than what you can handle from regex, you can spend a couple hours to write a quick & dirty parser that will convert your tables to div exactly as you want them.
Bottom line is that despite the stigma, for simple layouts, tables still do the job, they do it fast and are reliable, and if you don't have to contend with CSS purists, you can save yourself a lot of work.
CSS layouts make it easier to alter the layout through stylesheets (separation of data from display).
Also, browsers often can't render a table until the </table> tag has been parsed. This can be a problem if you are using a table with a large amount of content. CSS layouts can often be rendered as they go.
Given an HTML page that has a complex table-based layout and many tags that are duplicated and wasteful, e.g.:
td align="left" class="tableformat" width="65%" style="border-bottom:1px solid #ff9600; border-right:1px solid #ff9600; background-color:#FDD69E" nowrap etc.
Are there tools to aide the task of refactoring the page into a more compact form? For instance, a tool that automatically generates CSS styles and selectors? That converts tables into div layouts?
Just to give a sense of the order of the problem, the page I'm looking at is >8000 lines of HTML and JavaScript, which is 500Kb not counting images!
Update: In re. "give up and start from scratch" comments. What does that mean, in the real world? Print out the page, scan it, set it as the background image in Dreamweaver, and start with that? Seriously? Would that really be more efficient than refactoring?
Update: I'm not denigrating "trace it from scratch" nor did I mean to imply that Dreamweaver is by any means my tool of choice. I'm just very surprised that refactoring a layout is considered to be an intractable problem.
I agree with TimB in that automated tools are going to have trouble doing this, in particular making the relational jumps to combine and abstract CSS in the most efficient way.
If you are presenting tabular data, it may be reasonable to attempt to refactor the inline CSS to reusable classes.
If you have a lot of similar tables with inline styles you can gradually refactor the CSS by simple search and replace.
This will give you lots of classes that match a subset of similar tables and lots of somewhat similar classes.
Breaking this up into layout and presentation would be a good start, then overriding these with specific classes for each theme or semantically related item.
I would still recommend starting from scratch, it's probably going to be quicker, and you can recreate only what you need to present the page, and can reuse elements or collections of elements at a later date.
The time spent will also pay off significantly if the page is ever needed to be modified again.
But that's not at all likely is it? :D
I'm not aware of specific tools, only the generic ones of caffeine and Firebug, which anyone doing CSS work should be aware of.
I think that the problem is sufficiently hard that automated tools would struggle to produce good, maintainable markup and CSS.
It seems as if you are looking for more automated means of re-factoring an old table-based layout to CSS standards. However, I agree with some of the other comments to "start from scratch".
What this means to you is that you should try to rebuild (using CSS) the look that was achieved using an HTML table. If this concept escapes you, then I would suggest Googling for some beginner CSS tutorials, maybe even some focusing on teaching the concept of Table->CSS layouts..
Another tool to consider (that could possibly aid you even further) would be some sort of CSS "framework". I recommend Blueprint CSS for this, as it helps in the creation of grid/table-like layouts with minimal effort. Another good one is Yet-Another-Multicolumn-Layout, which has a really neat multi-column layout builder.
Don't just throw it in dreamweaver or whatever tool of choice and slice it up. Write the HTML first, in purely semantic style. eg, a very common layout would end up being:
<body>
<div id="header">
<img id="logo"/>
<h1 id="title">
My Site
</h1>
<div id="subtitle">Playing with css</div>
</div>
<div id="content">
<h2>Page 1</h2>
<p>Blah blah blah..</p>
</div>
<div id="menu">
<ul>
<li><a>Some link</a></li>
...
</ul>
</div>
</body>
Do the HTML in a way that makes sense with your content. It should be usable if you have no CSS at all. After that, add in the CSS to make it look the way you want. With the state of browsers/CSS now, you still probably have to add some decorators to the HTML - eg, wrap some things in extra divs, just to be able to get the content the way you want.
Once you're done though, you'll have a very flexible layout that can be modified easily with CSS, and you'll have a page that is accessible, to both disabled people and search engines.
It does take quite a bit of learning before you get the knack of it, but it is worthwhile. Resist the temptation to give up and go back to table based layouts, and just work your way through. Everything can be done with semantic HTML and CSS.
You denigrate this approach in your question, but I'd recommend taking a screen shot of your page in the browser whose rendering you like the best, declare that to be your reference, and start trying to recreate it. It's easier than you think. I've had to take skanky old table-based layouts and turn them into CMS templates done with modern techniques and it's not that bad a job.
I am tackling a similar problem at the moment, not quite as messy as what this sounds, but the product of really bad asp.net web forms, overblown view state, and deeply nested server controls that format search results from a database. Resulting in ~300 - 400K of markup for 50 DB rows - yeek.
I have not found any automated tools that will do a half way reasonable job of refactoring it.
Starting with a tool like visual studio that you can use to reformat the code to a consistent manner helps. You can then use combinations of regexs and rectangular selecting to start weeding out the junk, and stripping back the redundant markup, to start to sort out what is important and what is not, and then start defining, by hand, an efficient pattern to present the information.
The trick is to break into manageable chunks, and build it up from there.
If you have a lot of actual "tabular data" to format, and is only a once off, I have found excel to be my saviour on a few occasions, paste the data into a sheet, and then use a combination of concatenate and fill to generate the markup for the tabular data.
Starting from scratch means going back to the design drawing board. If you need to refactor such a monstrosity, then for all the time you will spend making it better, you might as well have done a full redesign.
If you want to get away from duplicated and wasteful tags, you need to escape Dreamewaver. A good text editor (jedit, emacs, vim, eclipse, etc.) is really all you need. If you customize your editor properly, you won't even miss Dreamweaver. (Emacs with nXhtml and yasnippets is my favorite.)
The Separation of Layout and Content is the domain of CSS and HTML - so far well understood. Now about separating...
I'm looking for hints and Best Practices to get started with the task of providing a "skin" or "theme" for a content management system.
Background:
We are starting to embrace a Portal Server/Content Management System and are starting to change the look and feel to match our needs.
Our designer has so far mainly worked with full control over HTML and CSS, tweaking either one in order to get pixelperfect layout. With adoption of the cms there's a lot precreated HTML (very semantic, almost no tables :) that needs to be skinned with CSS and Images. Though it is possible to change the HTML fragments, I'd prefer to do so only as a last resort.
As this provides the challenge of "how to get started" my question is about any tipps how to proceed or articles that can help managing or organizing this task - e.g. best practices in designing, how to slice this task or what tool to use.
It seems bad practice to just save a dynamically generated page to disk and make changes locally. This would be somewhat ok for the CSS files but changes to HTML elements must be retrofitted to the fragments that they are generated from. I'd like to keep this out of the designer's realm if possible. Also, the thought of Dreamweaver (or any similar tool) making implicit tweaks to the HTML structure is frightening for me.
For the curious: The mentioned CMS/Portalserver is Liferay, but the question is really language- and tool-agnostic.
Edit: FireBug (as Josh suggested) is awesome for trying on-the-fly changes to css. Is there more - either in the area of tools or in-process and self-organization?
If you're looking for practical examples of separating style and content, then I'd suggestion the CSS Zen Garden. Trawling through the HTML and CSS is inspirational and enlightening and should help with what you're trying to do.
My #1 tip would be be to make everything as semantic as possible and use lots of classes and ids to hook your styles onto.
Usually, Whenever I am in a situation Like this, I bring up the page in FireFox, inspect the different elements using FireBug and see exactly what css is applied to them. THen I'l just modify the existing css until I get what I like. You can even play around in firebug and modify the CSS without "saving" those changes.
Have look at CSS Tidy, we normally use this to clean up the CSS and reorganise for development and production. However, I personally prefer writing HTML/CSS by hand before using this. It is just a matter of individual preference I guess.