Typophile

Webheads - A Call for Help

AndrewSipe

Howdy Web gurus and masters of the code. I’m hoping to illicit a bit of direction from the masses on getting my web game in order.

A few years ago, I designed a website, and only one website. It was a chaotic mess built mostly of images and HTML. It’s still in use, but it’s falling apart. (view here) Sorry, about the front page, the client tried to make changes and messed it up something awful. (This was not posted as a critique, just an example of my current level.)

This being my infant step into the wondrously humongous world of web, it was extremely overwhelming to me. I’m still frightened by web design, but understand that if I’m going to develop and expand as a designer, it’s an important tool to have in my arsenal.

That’s why I’m calling for help. I know that if I’m going to have a passing chance at web design, I’m going to need to understand more than making pretty images and some basic HTML. I also know I can’t rely solely on my web development software to make designs that are both web friendly and work. So, I need to at least learn CSS, if I’m going to make a run at this.

I’d like to find some literature (be it web based or hard copy) that gives a no-nonsense approach to the building blocks of web design. I don’t want to learn advanced techniques until I understand the basics. Something that instills good markup and semantics would be also appreciated.

The W3C (World Wide Web Consortium) have a site that is a cornucopia of information, but it’s a bit daunting in the beginning. Ok, very daunting.

W3 School are easier to approach and are aimed at teaching, rather than being a place to look up information.

There are literally thousands of books written on how to learn to code web design, and it’s hard to give recommendations on specific titles—try browsing through whatever your local library has and see which ones seem the best. Just make sure they’re new, ’cause (X)HTML standards and mores have evolved quite a bit over the past few years.

And there is of course always the time-honoured way of learning: go through the source code on Web sites you like and learn from their greatness.

I would suggest that you first learn XHTML (don’t bother with plain HTML, it’s still supported, but is being phased out as a recommended standard) and CSS. These two are both fairly simple and straightforward to learn, since they’re both markup languages. And of course learn them the right way to begin with: by using XHTML for structuring information, and CSS to control all layout.

A very good place to get under the skin of CSS (not really to learn it, but to understand it on a deeper level) is the CSS Zen Garden. Click on some of the designs on the right and see the power of CSS—the XHTML markup is precisely the same for all pages, only the CSS is changed.

Once you feel good and comfortable with XHTML and CSS, I’d suggest learning some basic JavaScript and PHP. These two languages are the two most widely used ways of creating dynamic content and database interaction, at least in *NIX-based server environments. In Windows-based environments, ASP is probably more common than PHP, but I’d learn PHP anyway, since it, unlike ASP, is platform-independent.

Take a class taught by a working web designer. Learning how XHTML/CSS actually do work (as opposed to how the W3C or designers want them to work) will make life a lot easier.

When it comes to reference works, nothing beats Web Design in a Nutshell and The Zen of CSS Design.

W3 School are easier to approach and are aimed at teaching, rather than being a place to look up information. Easier is best!

There are literally thousands of books written on how to learn to code web design Ain’t that the truth. I’ve looked at a lot of literature and websites over the past few years. It was always difficult to know what to look at and focus on though, since I don’t have any formal web training outside of an HTML class I took 7 years ago. I didn’t know about XHTML being the better mark up language, and I’ve only recently learned of the power of CSS, but not really how to implement it.
I’ve read articles from http://www.digital-web.com, http://particletree.com/ and http://www.sitepoint.com/ but a lot of the information just went over my head.

Take a class taught by a working web designer. Learning how XHTML/CSS actually do work (as opposed to how the W3C or designers want them to work) will make life a lot easier. This is ideal, but not realistic in my area. All the colleges/schools that offer web classes require enrollment. I can’t just take them piece meal or as extended learning. I might be able to take a weekend seminar though my work, but I’m still waiting on approval from the higher-ups.

Hi Andrew, when learning the wonders of CSS I found this site to be a nice resource:

http://www.alvit.de/handbook/

I recommend this book: Bulletproof Web Design by Dan Cederholm.
Eric Meyer’s books on CSS are very good for starters, too.

learn XHTML (don’t bother with plain HTML, it’s still supported, but is being phased out as a recommended standard)
I don’t claim that this is wrong … but it’s a little bit like saying ‘Don’t learn InDesign – learn InDesign CS3!’. No? ;-)

Florian, I’ve looked at all of those books. While they seem very rich in content, and I’ve heard nothing but praise from the community. They’re way above my current skill level.

Neil, that’s a massive resource. I’ll bookmark that for later scrutiny.

«I don’t claim that this is wrong … but it’s a little bit like saying ‘Don’t learn InDesign – learn InDesign CS3!’. No? ;-)»

You’re right, that was sloppy wording. What I meant was of course that it is better to learn the HTML 4.01 Standard through the filter of the XHTML 1.0 specification, and to specify doctypes as XHTML, rather than HTML 4.01. :-)

I’m still a bit miffed that they decided to only publish the change in the XHTML 1.0 Specification, rather than the full thing. It’s so tiresome having to go back and forth between the HTML 4.01 specification and the XHTML 1.0 specification to check if something still applies or has been amended in XHTML 1.0. Lazy bastards, they are.

What I meant was of course that it is better to learn the HTML 4.01 Standard through the filter of the XHTML 1.0 specification...

I started going through the W3Shool on XHTML, and from I’ve gathered, it doesn’t seem too much different from HTML, other than it’s more strict in the actual coding. (which seems better practice anyway.) I’ve learned basic computer coding when I was in high school and you had to be strict or your functions wouldn’t work right. XHTML goes the route of it’s “better to be safe, than sorry.” Personally, I’d like to learn it that way, it gives more visual reasoning behind why a function (or in this instance an element) is set up, it would keep things more uniform and organized. Dot all my i’s and cross all my t’s.

That is precisely the difference: XHTML is stricter than HTML. Sloppy coding that worked in HTML (neglecting to close tags, using semi-proprietary or even fully proprietary tags, &c.) will not fly in XHTML—at least not if you want your document to validate, which is always a good thing, though never a replacement for extensive browser testing.

If we’re in agreement, I’ll take that as a good sign that I’m learning something.

I finished the surprisingly short tutorial on XHTML (and got a 19/20 on the quiz), now I’ll move onto the CSS tutorial.

Eventually, I’d like to take the site I posted originally and try recreating it using XHTML and CSS (it’s all built in code from Dreamweaver MX). The site is simplistic enough that the transition shouldn’t be too difficult (though I will probably have to rebuild all the pages.)

I really appreciate all the input guys!

«Eventually, I’d like to take the site I posted originally and try recreating it using XHTML and CSS (it’s all built in code from Dreamweaver MX).»

As you guess, that shouldn’t be too hard, though you will have to rebuild every page, that’s true. If nothing else, then at the very least to get rid of that horrendous light blue text on the beige background in the :hover state defined for the footer links. ;-)

Might I suggest waiting until you’ve grasped some basic PHP to redo the site, though? Or, alternatively, ask someone who does know some PHP to give you a hand. The include() function is, in my view, absolutely indispensable when making the menu system, since it enables you to define the menu in one single file and then simply include that file in every other page. That means that any site-wide changes to the menu system (or any other site-wide element, of course) can be changed once and then propagated to the entire site.

If nothing else, then at the very least to get rid of that horrendous light blue text on the beige background in the :hover state defined for the footer links. ;-) I’m glad you pointed that out (is having a footer like that still necessary I wonder?) Honestly, I’m not a fan of the color scheme (it was selected by the client) and would love to change it. Hopefully with the addition of CSS this won’t be too difficult to do in the future (if necessary at all.)

Might I suggest waiting until you’ve grasped some basic PHP to redo the site, though? Right now, I have no clue what value PHP offers to a website other than it’s used in database coding. From what you’re suggesting, it does sound like a valuable feature though. However, for this site I won’t be too concerned about having to change the menu system (or the work involved in doing it manually for all the pages.) The client hasn’t shown interest in investing in any major updates or a site wide overhaul at this point. I’m going to update it only to learn from it (since it’s available, simplistic and finished.)

Ethically, I don’t feel right charging the client to learn on their dime. If things go well, I’ll equal out the time invested as an educational discount and sell the updated site to the client finished. Anyway, that’s a discussion for another thread at a different time.

If you have suggestions on how I should start the update, I’m all ears.

For the love of God, can we get BLOCKQUOTE on this damned system?> I know that if I’m going to have a >
> passing chance at web design, I’m going to need to understand more >
> than making pretty images and some basic HTML.

Basic (i.e., Web-standards-compliant) HTML is the most important thing to know.

> I’d like to find some literature (be it web based or hard copy) that
> gives a no-nonsense approach to the building blocks of web design.

The HTML Dog book will teach you basic semantics. Designing with Web Standards by Zeldman teaches separation of structure, presentation, and behaviour (HTML, CSS, and [usually] JavaScript, respectively).

> There are literally thousands of books written on how to learn to
> code web design, and it’s hard to give recommendations on specific
> titles

It’s very easy to give recommendations against certain titles, namely most of them.

> Just make sure they’re new, ’cause (X)HTML
> standards and mores have evolved quite a bit over the past few
> years.

Only the mores have evolved. The standards are fixed in stone, which is one of the problems. And the only evolution was from 1999 (tables and font tags) to 2000 (Web standards). We are still in the Web-standards era even if some of your friends, and Microsoft users, think otherwise.

> And there is of course always the time-honoured way of learning: go
> through the source code on Web sites you like and learn from their
> greatness.

Don’t do that unless you know up front that the developer is a standardista. Especially don’t do that for JavaScript.

> I would suggest that you first learn XHTML (don’t bother with plain
> HTML, it’s still supported, but is being phased out as a recommended
> standard)

That’s false. XHTML has no advantages whatsoever for general Web sites and many disadvantages (e.g., a single capital letter in an element name makes your whole page invalid). HTML Strict is much more forgiving yet semantically identical to XHTML.

XHTML is interpreted by browsers in all cases, save for XHTML 1.1 and XHTML 1.0 served with the right MIME type, as HTML with added slashes. Repeat: XHTML is not better than HTML. They are approximately the same thing.

> These two are both fairly simple and
> straightforward to learn, since they’re both markup languages.

CSS is not a markup language.

> A very good place to get under the skin of CSS (not really to learn
> it, but to understand it on a deeper level) is the CSS Zen Garden.

The Zen Garden book is a good visual place to start.

> Take a class taught by a working web designer. Learning how
> XHTML/CSS actually do work (as opposed to how the W3C or designers
> want them to work) will make life a lot easier.

The way the W3C wants them to work is generally the way they do work in all browsers that aren’t called Internet Explorer. While you were sleeping, Web standards took over.

> You’re right, that was sloppy wording. What I meant was of course
> that it is better to learn the HTML 4.01 Standard through the filter
> of the XHTML 1.0 specification, and to specify doctypes as XHTML,
> rather than HTML 4.01. :-)

Wrong in practice.

> I’m still a bit miffed that they decided to only publish the change
> in the XHTML 1.0 Specification, rather than the full thing. It’s so
> tiresome having to go back and forth between the HTML 4.01
> specification and the XHTML 1.0 specification to check if something
> still applies or has been amended in XHTML 1.0. Lazy bastards, they
> are.

Because next to nothing was invalidated. XHTML is HTML with self-closing tags, an all-lower-case requirement, quoted attribute values, and a small list of additional minor differences (like valid entity names, few of which come up in Unicode documents).

> I started going through the W3Shcool on XHTML, and from I’ve
> gathered, it doesn’t seem too much different from HTML, other than
> it’s more strict in the actual coding.

That’s not entirely true. It’s more accurate to say that HTML, even Strict HTML, is more permissive. For example, you can leave off </p> in most cases, and many elements, even HTML and BODY, just aren’t needed at all.

Nonetheless, you can write an HTML document (any flavour) with all its tags closed and all its attribute values quoted and all its element names in lower case. At that point, almost certainly the only difference between that an an equivalent XHTML document is self-closing tags.

> That is precisely the difference: XHTML is stricter than HTML.

False. HTML and XHTML both have document-type definitions, i.e., both have rules. Transitional and Strict document types constitute another subset of rules.

> Sloppy coding that worked in HTML (neglecting to close tags, using
> semi-proprietary or even fully proprietary tags, &c.) will not fly
> in XHTML—

False some of the time. There are many HTML elements that don’t have to be closed, including P, LI, HTML, and BODY. Only the elements in the spec may be used for all HTML and XHTML documents, though technically you can define your own elements for XHTML. (Ask me about embed sometime.)

—
Joe Clark
http://joeclark.org/

«For the love of God, can we get BLOCKQUOTE on this damned system?»

Yes, please. Or at the very least set the cite elements properly apart from other text.

 

«Only the mores have evolved. The standards are fixed in stone, which is one of the problems. And the only evolution was from 1999 (tables and font tags) to 2000 (Web standards). We are still in the Web-standards era even if some of your friends, and Microsoft users, think otherwise.»

You’re right, of course. What I should have said was that mores and descriptions of the standards in web design books have changed, not the standards themselves. Even in books that are no more than three or four years old, it’s not uncommon to see authors advising against using CSS properly and using tables to create layout.

And what does “some of your friends” refer to?

 

«CSS is not a markup language.»

I wasn’t aware of that. I thought stylesheet languages were considered a subset of markup languages, actually. What I meant by that comment, though, was that both (X)HTML and CSS have very simple and limited syntax components, compared to most scripting or programming languages.

 

«The way the W3C wants them to work is generally the way they do work in all browsers that aren’t called Internet Explorer.»

That’s a bit Utopian, isn’t it? So far, to my knowledge, no other browser than Safari WebKit Nightly r30881 has even managed to reach the 90 per cent mark in the ACID3 test. And even for simple, normal, validating XHTML pages, there are plenty of small bugs that creep up, though to be fair, some of those represent gaps in the specifications, rather than aberrant browser behaviour.

 

«Wrong in practice.»

How do you mean, “in practice”? It’s still not worded very well, but I don’t see why it’s any more wrong in practice than in theory.

 

«Because next to nothing was invalidated. XHTML is HTML with self-closing tags, an all-lower-case requirement, quoted attribute values, and a small list of additional minor differences (like valid entity names, few of which come up in Unicode documents).»

That doesn’t mean the entire Recommendation shouldn’t be available as a single document. Laws are constantly amended, small bits at a time, but that doesn’t mean the original document should not be updated whenever such an update takes place. Most commonly, unfortunately, they are not; but that does not mean they shouldn’t be.

 

«False. HTML and XHTML both have document-type definitions, i.e., both have rules.»

And the rules in XHTML impose more restrictions or demands on the layout of the document than the rules in HTML do, whether we’re talking Strict, Transitional, or Frameset. I would call that being stricter, or more restrictive.

 

«False some of the time. There are many HTML elements that don’t have to be closed, including P, LI, HTML, and BODY. Only the elements in the spec may be used for all HTML and XHTML documents, though technically you can define your own elements for XHTML.»

I’m not sure how that makes what I said false some of the time?

By “work”, I was referring to validation, not actual browser behaviour, which is of course a topic entirely divorced from validation. Failing to close a p tag in HTML will not cause the page not to validate; it will in XHTML. I don’t consider that a disadvantage, by the way, in the same way that I don’t consider JavaScript’s permissiveness compared to many other scripting languages to be an advantage. If anything, the permissiveness is the disadvantage.

XHTML doesn’t say anything about “the layout of a document.” HTML doesn’t, either.

—
Joe Clark
http://joeclark.org/

Well, what’s a better word for it, then? The … physical shape? No. The way the document is built? No.

The word I’m thinking of (which fits perfectly) is udformning, but I can’t think of a proper English word for it, if there is one. Something like the way that each element in the whole of the document is expressed/typed/put. Or something.

When typing an element in an XHTML document, there are tighter restrictions that must be adhered to than when typing an element in an HTML document. Thus, XHTML is more restrictive than HTML. That’s the best way I can word it.

udformning

I suppose in Swedish this means more than just “design”.

It doesn’t mean anything in Swedish (where it would be utformning). ;-)

But in Danish, yes, it means more than ‘design’. In fact, it rarely means just ‘design’. It’s more to do with the structural form, design, and order of the individual components that make up a larger whole.

“That is precisely the difference: XHTML is stricter than HTML. “

Not really. You can have strict OR loose HTML OR XHTML.

XHTML is simply HTML that follows the XML standard. As for learning one or the other, there really isn’t much of a difference. Most would argue that there’s little point in using XHTML these days *unless* you have a specific need for your HTML to be XML compliant.

But, yea...in summary, the key to understanding any medium is to understand the tools and process. That’d be HTML and CSS to begin with. Add some Javascript, Flash and back end stuff to taste.

I’d forgo a tech-school class. Most of them will teach you DreamWeaver and not really teach you HTML.

It’s not rocket science...but it can take some time. As stated, the biggest hurdle will be fighting the Microsoft flavored web browser rendering engines (though with IE8 on the horizon, we may FINALLY be reaching a point where that’s a moot issue in the next several years).

Can someone answer this question then,

If HTML is the content on the page, and CSS is the style on that content, which controls the layout/location of that content?

«Not really. You can have strict OR loose HTML OR XHTML.»

Like I already said, I wasn’t referring to flavours.

 

«(though with IE8 on the horizon, we may FINALLY be reaching a point where that’s a moot issue in the next several years)»

I wish I shared your positivism, but I fear a, “Keep dreaming” is more in order.

 

«If HTML is the content on the page, and CSS is the style on that content, which controls the layout/location of that content?»

How do you mean?

If HTML is the content on the page, and CSS is the style on that content, which controls the layout/location of that content?

CSS does. It can be used to ‘style’ elements – to specify colours, fonts, borders, background-colours, background-images, all kinds of typographic formatting etc pp.
But you can also arrange the elements with CSS – define the size, the margins, the padding, whether they are ‘inline’ or ‘block’ (whether they trigger a new line or not), even the exact position within the viewport.
Does that answer your question?

F

«If HTML is the content on the page, and CSS is the style on that content, which controls the layout/location of that content?»

How do you mean?

This is what’s really confused me about web design, the actual visual layout of the data and how the code controls that layout. The WYSIWYG end of web design. I know I can set up a row of images and buttons and text boxes with HTML, but apparently (from what I’ve gleaned) it’s better to do it in CSS, which could change the layout on the fly if need be. So, from a visual design perspective, understanding CSS would be more beneficial than HTML. Correct?

«I know I can set up a row of images and buttons and text boxes with HTML, but apparently (from what I’ve gleaned) it’s better to do it in CSS, which could change the layout on the fly if need be. So, from a visual design perspective, understanding CSS would be more beneficial than HTML. Correct?»

I’m still not entirely sure what you mean. You can’t understand only either HTML or CSS. Well, you can, of course, but it won’t do you much good.

In your example, you would define a sequence of images, buttons, and text boxes in HTML. In HTML, you would specify at which logical point in the undisrupted flow of the document each of these elements comes, as well as the source of the images, whether the buttons were selected by default, and whether any text appears in the text boxes when the page is loaded.

After you had done this, you would create a CSS file that contains information on how these elements should be presented: should the images have borders, what should the background colour of the text boxes be, should they all appear on one long line or each with their own line, &c.

I think Asvetic has identified a key point on the web design learning curve here, and one that colleagues and I have had problems with. This is how I see many individuals grasp of HTML/CSS develops (I’m writing quickly between jobs so hope it makes sense):

One discovers early on that writing HTML *does* determine both layout and appearance of a document - because browsers have inbuilt stylesheets, invisible to the user, thus ways of rendering it.

This confuses right from the start by conflicting with the “correct” model of HTML being purely structural.

Re Oisin above, the buttons, images and text would show up in the right place on screen with no use of CSS at all.

CSS is then found to be a convenient way of globally specifying fonts and colours, maybe margins, but not much more - it’s a fairly superficial layer which *adds* to the appearance of plain HTML.

People often find that more complete uses of CSS fail to render as they expect, so abandon further experimentation. For example, trying to lay out complex forms. Or when trying to put together an HTML email. Tables-for-layout work better for both, so are seen as a reliable method, and the individual’s understanding of the HTML+CSS model stalls - this is why they are sometimes seen as alternatives.

I think use of ’reset’ stylesheets can help with this by eliminating the inbuilt browser styling.

So a better analogy could be HTML is the skeleton, nervous system, and all the organs (where they’re located mostly) and CSS is the skin and hair and color of the organs and blood. Depending on how the HTML is set up, I could have a foot where my hand is, and a heart where my brain is. CSS doesn’t control this, but it controls how tan my skin is and how far set my eyes and ears are.

HTML is the broad layout, and CSS is the nudged version of that layout. And if I create the website with this in mind, HTML, then CSS... that would render a more exact visual design.

Print design is you take the content, and visually lay it out on the page. You end up with a single piece in the end.

Web design is you take the content, format it so it’s *meaningfullly* organized, and then you lay it out/style it for a particular display.

In otherwords, the ’content’ of HTML may be used in many different ways, so it’s important that it has some structure and meaning to it ’in the raw’.

For example, it may be shown in a visual web browser on your computer. It might be read to someone via an aural web browser. Some folks might parse the content sans any style. Someone might view it via their handheld device. Someone might be programmatically accessing the raw content (ie, google).

It’s a bit like architecture. You can’t ’WYSIWYG’ a house plan very efficiently. Unless you dive into the framing and plumbing and elecrtical BEFORE you start randomly laying out rooms and picking out wallpaper, it won’t be a very efficient product in the end.

“One discovers early on that writing HTML *does* determine both layout and appearance of a document - because browsers have inbuilt stylesheets, invisible to the user, thus ways of rendering it.”

That’s not the HTML determining that. That’s that one particular web browser’s default rendering of the HTML. I think you’re saying the same thing, but be careful stating it’s the HTML making that decision (as you state, it’s the browser’s built in style rendering).

“So a better analogy could be HTML is the skeleton, nervous system, and all the organs (where they’re located mostly) and CSS is the skin and hair and color of the organs and blood.”

It’s hard to find a specific analogy that works well for this, but if I had to try:

HTML = the movie script
CSS = directing, cinematography, acting, set design, etc.

“HTML is the broad layout, and CSS is the nudged version of that layout.”

No, HTML is the pure content. CSS is the rest.

Geez, we’re getting to far off the path. I understand that designing for web isn’t like designing for print. Prints more absolute, what you see IS what you get. Where designing for web, you can put the elements into places and hope that the format of your code keeps them there, but depending on who views it that will most certainly change. There are too many variables to create a single definite design and expect it to stay that way.

It’s something to keep into consideration when creating a design, but I just want to learn how to recreate my vision in web media. The syntax and the semantics of web design go over my head like low flying aircraft.

Sorry, I appreciate you guys running with the ball, but I have to pull the reigns in on this thread, you’re loosing me.

> If HTML is the content on the page, and CSS is the style on that content, which controls the layout/location of that content?

Actually, the hardest part of a web designers job is to realize that the user controls much more than the designer does (in the true spirit of HTML).

The user decides the size of the page, always. He can change the size of the window, and gets to choose what resolution the monitor is at.

The user gets to decide on the size of the type, ideally (if the designer is savvy enough to use ems, % or another scalable size, and not fixed dimensions like points or pixels.) Some people need larger type to read clearly they should be able to do so with the browser controls that allow for larger type.

The user can even control the default typeface, which is pretty terrifying to the print designer. If I want my default sans to be Comic Sans, and my default serif to be Algerian, I should be able to do so (although I would probably be able to be certified insane for doing so). Then all I have to do is get rid of the rest of the fonts on my system to see all your pages in their prime ugliness.

Learning these limitations exist, and then learning to design around them are the hardest parts of making the jump from print to web.

«Then all I have to do is get rid of the rest of the fonts on my system to see all your pages in their prime ugliness.»

Or use a browser that allows user styles to override page styles, so that all text on any page on the Internet is rendered in Comic Sans or Algerian.

And then you can scoot right along to the insane asylum, ’cause that would drive anyone up the walls in a day.

“It’s something to keep into consideration when creating a design, but I just want to learn how to recreate my vision in web media. The syntax and the semantics of web design go over my head like low flying aircraft.”

Well, you might be loosing us too. Is your aim to learn the syntax and semantics? If not, then the best way to ’recreate your vision’ is to team up with someone that can do that back end stuff for you. Might be the least painless/most effective path. I do that for a handful of very talented print/visual designers that just didn’t have the need/want to dive into the back end space.

Otherwise, if you do want to learn the syntax and semantics, I’d suggest looking at it from a slightly different angle. Get the semantic content down/in-place first (the HTML) and then build your vision from that.

In otherwords, don’t start with the photoshop mock-up. Start with the content.

“Actually, the hardest part of a web designers job is to realize that the user controls much more than the designer does”

Yep. My favorite way to explain it:

print design = you dictate the visual design
web design = you’re just suggesting a visual design

This should help to put all of the above into perspective:

Well, you might be loosing us too. Is your aim to learn the syntax and semantics? If not, then the best way to ’recreate your vision’ is to team up with someone that can do that back end stuff for you. Might be the least painless/most effective path. I do that for a handful of very talented print/visual designers that just didn’t have the need/want to dive into the back end space.

I want to learn, I want to understand the developer’s end. Knowing the capabilities of web design will help me make decisions within a design. I’d be designing smarter.

Every now and then I get into these web learning kicks, and every time I get overwhelmed and eventually loose interest/focus. The unstructured approach and not knowing where to start doesn’t help either. I figure if I can learn and create sites with the basic understandings of the web, then adding to that would be natural. I was hoping I’d get responses from people that went through what I’m going through and would respond with their experiences/suggestions.

I appreciated the replies. When Janus suggested learning XHTML would be a better approach then learning the more forgiving and looser HTML 4, I thought that was a wise suggestion... then the debates started.

Perhaps I should have asked a question like this:
If YOU had to teach someone how to do web design/development, what would your teaching outline look like? Where would you start and what would come next?

Regardless, I’m going to follow the HTMLdog tutorials. It’s definitely shorter (and less overwhelming) than the books I’ve seen. Hopefully, by the end of the tutorials I’ll understand enough HTML and CSS to be able to take my original site and rebuild it (or at least optimize the code better.)

I did teach HTML, for about 10 years. I always started with a course in HTML, hard coding with Notepad (or the Mac text editor of your choice). CSS was a second course, and then, after the students knew code, they were introduced to Dreamweaver and FrontPage (this was back when the latter had a trace of relevance.)

Within the HTML portion, we spent considerable time building pages that were dynamic ... in other words, they would be workable at any size then current (640x480 was the minimum at that time, and later 800x600 was the minimum). The max was what the monitors at any time would take. I remember changing the screen background image so that it contained boxes of 640x480 and 800x600 as well as full screen so that the students would reduce their browser windows to those dimensions to see how the page would look to folk with older computers.

The other big concern I remember at that time was that pages had to work correctly in both the current IE and Netscape (today it would be IE and Firefox). The only other browser at that time with much share was Opera, but such a small usage that it could be safely ignored.

One thing I didn’t do at that time, that I would now, is to insist on validated code. Anyone wanting to submit invalid code would have to supply me with an essay explaining why the end results justified the invalid code.

Anyone wanting to submit invalid code would have to supply me with an essay explaining why the end results justified the invalid code. What would invalid code be considered, is that the same as deprecated code?

“If YOU had to teach someone how to do web design/development, what would your teaching outline look like? Where would you start and what would come next?”

Good question.

Not an entire course, but specifically the process to build an HTML page:

1) Get the content. All of it.
2) How to mark it up with HTML in a semantic manner and talk about issues like SEO and Accessibility.
3) How to layout out the page structure via CSS (and adding the necessary additional HTML as needed).
4) How to now bring your visual layout (photoshop mockup) into the mix.
5) Polishing it all up adding the images, typography, color, to the CSS file.
6) Now let’s talk about why it looks like crap in IE and how to fix it. ;o)

“What would invalid code be considered, is that the same as deprecated code?”

Invalid code is code that doesn’t validate:

http://validator.w3.org/

The closest analogy I can think of is pre-press flight checking.

Deprecated code is usually something that has been replaced with something ’newer and better’ though the ’better’ part can often be debated. ;o)

“1) Get the content. All of it.”
Check

“2) How to mark it up with HTML in a semantic manner and talk about issues like SEO and Accessibility.”
I think I understand the idea of semantic coding (it’s using the simplest code elements to describe the content). I don’t know what SEO is. Accessibility is coding for the disabled right, like putting in descriptions for images?

“3) How to layout out the page structure via CSS (and adding the necessary additional HTML as needed).”
This is what I’d really like to learn.

“4) How to now bring your visual layout (photoshop mockup) into the mix.”
I assume this is where Dreamweaver comes into play.

“5) Polishing it all up adding the images, typography, color, to the CSS file.”
Again, understanding CSS is still a major hurdle for me.

“6) Now let’s talk about why it looks like crap in IE and how to fix it. ;o)”
The FEAR is almost crippling.

SEO=Search Engine Optimization.

“I think I understand the idea of semantic coding (it’s using the simplest code elements to describe the content).”

It’s more about using the proper markup.

“I don’t know what SEO”

Semantic markup can help with Search Engine rankings.

“Accessibility is coding for the disabled right”

It’s a bit broader than that. It’s more about making sure your content is accessible by a wide range of people and devices. But, in a nutshell, yes, it’s related to things like the ADA.

Ultimately, it sounds like you really just need to start diving into CSS. Here’s some good books on it:

http://simplebits.com/publications/

I like the Tizag Tutorials http://tizag.com/ Most tutorials confuse me even more but these are so easy to follow. -Jess

> What would invalid code be considered, is that the same as deprecated code?

Basically, there are times that invalid code makes sense, perhaps in relation to javascript or other tools. I remember the W3 validator refusing to accept a link that was used on a site (due to the ? and # stuff within in). The sys admins were quite happy with their invalid links, and a mere designer could not force them to change their minds.

My goal as a teacher is (was?) to make the student validate the code, and correct anything that can be corrected. But in some cases invalid code is needed. I was trying to create designers, not autocrats.

microspective, that chart speaks right out of my heart!

I was just like you two years ago, Asvetic. Back then, I used to save web pages a lot so i can analyse the source code (both html and css) locally. And looking at CSS ZenGarden is a must at that time.

So, my advice is: save web designs that you think awesome, then try to imitate it (it’s normal for beginners). You’ll learn faster when you like it. Of course, always keep “the manual” at hand so you can quickly find out about unfamiliar tags.

Then, just exercise often. Try designing from scratch (writing code by hand) without Dreamweaver’s scripting aid.

Actually, I’m still just like you. Still learning about the new features of CSS3. :-)

I find that it is not much different than how type was spec’d back in the olden days of yore. You have your type-written page of text, with notes written on it about how wide the columns are to be, what kind and size of font, what kind of alignment, etc.

With HTML and CSS, the HTML is the typed out page of text, and the CSS is the notes telling the browser how to set it.

Easy as that.

Don McCahill’s post about the occasional need for invalid code is incorrect (save for embed, which you can make valid by XHTML) and can be safely ignored. In fact, the only way to stay safe is to ignore it.

—
Joe Clark
http://joeclark.org/

This weekend, I had a good buddy (and webhead) walk me through a simple CSS layout. He used the [http://csstinderbox.raykonline.com/?page_id=12] center box template to help illustrate things.

Things are starting to make more sense to me now. I’m definitely a visual learner, so this walk-through was a major eye-opener. He used a program called CODA to help illustrate things better, sadly it’s a MAC only program (I use a PC). I think I understand div and class better and he illustrated padding, margin and borders, explaining the Box Model more clearly. I loosely equated it to the stroke palette in illustrator.

Surprisingly, he didn’t know that you could use em and % for padding and margins. This was an easy concept for me to understand (thanks to understanding EM and EN widths in type). However, we’re not sure what the base is, or what 100% or 1em is equal to. (I assume it’s the browser’s default text size, which is usually Medium/ 16 pt/px, right?) I do recall reading something about if a container is in another container, then that is the new base. This concept sounds confusing, especially if there are several layers of containers.

Now all I need to learn is how to add rounded corners and rollover buttons that are CSS adapted, and I should be able to redo that website.

I’m definitely a visual learner, so this walk-through was a major eye-opener.

These two Firefox add-ons will make your learning even easier:
Firebug by Joe Hewitt and Web Developer by Chris Pederick.
Strongly recommended. :-)

Actually, you can easily found tons of CSS tutorials scattered on the internet these days. But maybe you might want to browse A List Apart’s archives for articles like this one.

In addition to the above Firefox add-ons, I also used this and this.

Glad you’re doing well Asvetic. :)

Captured from web.archive.org on 5 Dec 2008. view this capture