Introduction, and some questions

Hi,

I´m back in web design after a few years and I found out everything has changed so much... from HTML 4.1 to 5, from CSS2 to CSS3, lots of versions of new software.... I´m quite lost.

I used to transform the psd designs into Dreamweaver, first with the slicing tool, after a few years, using layers and CSS. And I can remember, I used to set the layout by "drawing" the divs direct in dreamweaver and adjusting their properties later. Now I´ve been tasting the Dreamweaver CC and I can´t find the drawing tool and (the tool bar, any of the tools) just a CSS panel to "insert" the divs, but no draw them... It isn´t possible anymore?

In the other side, I discovered the new Edge Reflow Adobe´s software, and I think it has a huge potential, but they don´t let you export the code, so you hace to copy every piece os CSS code and paste it into a Dreamweaver DIVs layout... I find ita bit absurd... Why do they do such thing? IMHO, it should be a lot easier to be able to export the code, or even better, to implement the reflow capabilities into Dreamweaver directly, am I wrong? what do you think?

 

Now, just to warn you I'm brutally frank, and the types of things I say might not sound nice to a bunch of little old ladies at a tea party; but that's because I don't rap, I don't jive, I just get right down to the truth of the matter in as plain folks a way as possible.

Now, don't take this the wrong way, but it sounds like you NEVER learned to build a site correctly. Dicking around drawing goofy pictures in Photoshop is NOT web design, no matter how many ignorant halfwit artsy fartsy types claim otherwise. In that same way that fat bloated steaming pile of manure known as Dreamweaver should never have been allowed to see the light of day in the first place. MORE SO if you are screwing around with the absolute GARBAGE the WYSIWYG (the part where you can drag stuff around) vomits up and has the giant brass monkey balls to call HTML. The only thing you can learn from Dreamweaver is how NOT to build a website, and to be frank that hasn't changed since long before Adobe bought out Macromedia. The only way to theoretically build a website properly with DW is to only use the code view, and even then I've NEVER seen a site built having DW even involved in the process that wasn't an absolute disaster in terms of code, efficiency or accessibility!

Using Adobe products in the manner you mentioned has ALWAYS been "doing it all wrong"! You need to get your head out of the presentational mode of thinking and get down into the code. That means using a flat text editor like notepad++, editplus, gEdit, Crimson Editor, TextWrangler, or what I use -- Flo's Notepad2 (which is Scintilla based). Excuse me as I go into broken record mode, but:

1) Take your content (or a reasonable facsimile) and put it into a logical document order. Basically set it up as if HTML and CSS didn't even EXIST in a flat text editor.

2) Mark it up semantically -- which is to say use the tags to say what things ARE, NOT what it looks like. This way you have an accessible baseline for screen readers, search engines, legacy pre-css browser users (which DO still exist, they also don't track very well), and every other device that could care less about your visual screen layouts. (It's often even a good fallback for print!). Use UL for short unordered lists (like menus), OL for ordered lists, P for GRAMMATICAL (not typographical) paragraphs, and most importantly numbered headings (h1, H2, H3) and horizontal rules (HR) to divide the page into sections... remembering the logic rules of numbered headings as per professional writing; a H1 being the heading under which the entire page is a subsection (which is why site title is usually the logical choice for this no matter what the SEO-tards and their scam artist bullshit claims), H2's indicating the start of subsections of the h1, h3 being the start of subsections of the H2 and so forth down the line to H6. (Though really if you reach H6 there's something wrong with your page). This is why skipping over numbers going down in priority (up in value) -- H2 to a H5 for example -- is gibberish. Likewise HR should be used when there's a change in topic/section where a numbered heading is undesired or unwarranted. (like right before a headerless footer?). Of course, logical document structure rules are why HTML 5's allegedly semantic new tags are pointless code-bloat idiocy, and just part of why I don't advocate the use of HTML 5. (we'll get to that in a minute). In any case at this point you should NOT be thinking what it's going to look like, just what it should BE. ANYTHING that says what it looks like -- and that INCLUDES class names, ID's, the STYLE tag and the STYLE attribute -- in all but the rarest of cases have NO BUSINESS IN YOUR MARKUP!!!

3) Bend it to your will with CSS -- THIS is where you think about what it looks like. You may end up adding a few DIV or SPAN at this point, but those are semantically neutral hooks to say style is applied, WITHOUT saying what that style IS. You use a media target for screen type devices as your first of many possible targets. Something like:

<link
	type="text/css"
	rel="stylesheet"
	href="screen.css"
	media="screen,projection,tv"
/>

Code (markup):

I include TV in the media target because there are still a lot of devices that recognize it -- MSN TV, Wii Browser, so forth. Projection is for certain browsers kiosk modes, where they use that instead of screen. Generally speaking it is incorrect to omit a media target, and piss poor coding to EVER use "all" as a target since it's extremely unlikely any of your CSS would make sense to "all".

The layout should be built in the CSS, not dicking around in some goof assed paint program or inaccessible train wreck "preview pane" bull. The first layout I suggest building is an elastic (measurements based in EM's) semi-fluid (max-width to prevent lines of text from being too long, auto-adjusting to smaller available space, min-width so non-query browsers don't screw up) one for non-media query capable browsers. Any column techniques used should be able to be disabled for 'media queries' to create the later responsive layouts. Again the layout should be elastic, which also means all fonts should be declared in either %/em, and any 'fixed' widths should be in EM's so it's based on the user's default font size choice; means users like myself don't have to spend so much time screwing around with zoom we get fed up and visit some other website. Usually at this stage I like to have one fluid (auto-adjusting) column and any other columns declared in EM's so they auto-expand to the content.

Then of course you make your media queries -- these are REALLY new, and REALLY when cool used properly. Basically you can set 'break-points' like this:

@media (max-width:44em) {
	#contentWrapper,
	.hasExtras #content,
	#content,
	#extras {
		float:none;
		width:auto;
		margin:0;
		padding:0;
	}
}

Code (markup):

...anything you declare for CSS inside a query only applies when that case is true - the above is from a site I'm working on right now that strips off the columns when the site is narrower than 44em, turning a multi-column layout into a single column one. That's called a "responsive layout" -- and we'll talk more about that in a moment.

4) then and ONLY then do you start up the paint program to make the graphics to hang on the layout or try to 'enhance' the page with scripting -- since people don't visit websites for the goofy graphics or "gee ain't it neat" scripttardery you hang around the content, they visit FOR the content!

That's content-first web development in a nutshell -- and why most people who screw around in photoshop or WYSIWYG editors and have the brass to call themselves "designers" usually don't know enough about HTML, CSS, Accessibility, emissive colourspace, progressive enhancement and graceful degradation to be design jack {string of expletives that would make patrons at a truck stop say "hey watch it, there are mechanics in here" omitted}!

... and that process I just outlined? That's called "progressive enhancement" -- you start out at the most accessible baseline (semantic markup of content), make it fit the screen as best possible with your layoutS using CSS, make it pretty with CSS and images (if any on the latter of those -- thanks CSS3), then further enhance it with scripting (if any - please for the love of ghu, use an eyedropper not a 80 gallon oil drum). The reason to use progressive enhancement is so that should any of those enhancements be blocked or unavailable or just plain not apply to the target device, the page will 'gracefully degrade' so that it's still useful to the visitor. Accessibility 101.

As to more modern bits, when it comes to CSS3, it's a godsend. It adds all sorts of 'easy graphics' to reduce the number of images used on a page and to make the creation of fast loading pages easier, AND so that they gracefully degrade better.

More importantly it adds media queries/responsive layout which for those of us who spent the past decade building ACCESSIBLE websites is just the next logical step... unfortunately all the people who spent the same period of time sleazing out PSD's, crapping out fixed width layouts, declaring absurdly undersized fixed metric (px) fonts, and in general failed to extract their head from 1997's rectum by vomiting up HTML 3.2 and slapping 4 tranny on it, well... the very notion of responsive layout might as well be an alien language.

Which of course speaking of 1997, there's HTML 5. While CSS3 and the new scripting stuff is quite welcome, on the whole HTML 5 seems carefully crafted to undo all the progress of the past sixteen years. I jokingly call it "the new transitional" since it re-introduces redundancies HTML 4 strict was about getting rid of, introduces all new redundancies of it's own, and pisses all over the markup with pointless crap like SECTION, NAV and so forth. Some of it like ASIDE has all the semantics of tags like CENTER and FONT (unless you actually were to use it for a literary aside... which of course NOBODY does). My advice? Stick with the RECOMMENDATION doctypes of HTML 4.01 STRICT or XHTML 1.0 STRICT, it's not like the new scripting and CSS3 can't be used with them. Apart from Apple being total pricks about media delivery with the idiotic redundant VIDEO and AUDIO tags sending media delivery back to the WORST of the realplayer vs. WMP vs. quicktime browser wars, and of course RUBY language support, HTML 5 offers NO legitimate improvements over HTML 4.01 Strict. Quite the contrary. It's why I say it's target audience is all the idiots who until recently were sleazing out HTML 3.2 with 4 tranny on it now just wrap 5 lip-service around the same buggy bloated broken inaccessible trash code.

Now, sorry if that seems harsh, but it's better to tell you the truth than to pat you on the back, tell you "everything's ok", slap the rose coloured glasses on your head and lead you down the garden path to failure... which of course is what all the Dreamweaver apolists, jQuery script-tards, and PSD jockey nitwits are now going to do with their "me too" one sentence wonder-posts.

 

First of all, thank you for your help, wow, that´s what I call an answer. It took me a while to read and understand it all, but it worthed it definitely. So I´m going to try not to miss a thing:

And this is precisely the reason I decided to ask for help here!

You nailed it!. That´s exactly what it happened to me. When I started designing webs (back in 1994) there wasn´t the amount of tutorials, videos, books, etc... we can find all around today. So I started to try, and learned a few things copying from here and there, but never got an structured learning process. So I spent some time on every stage of the web design evolution since then, from big images with sensitive areas, to slicing and intensive use of tables. And when I was beginning to deal with html 4.1 and css, trying to validate my code, and giving importance to a real separation between content and appearance, and trying to get some clean code, I stopped (on family and life matters)...

But It´s never late...

You may be right, but you are really funny.

I think DW it´s not as bad as Frontpage used to be (example). I mean, if you know to write net code, I think DW can help you to structure and speed up the development. Sure If you dont know how to write clean and semantic code, and you trust DW will do it for you... then you are in a problem, cause DW probably put some blurred, mixed-up and messy code. It´s just a tool, how you use it it depends on you...

So:

1.- Content
2.- Semantically mark up
3.- CSS
4.- Graphics

But what happens when the graphic designer (or a client) gives you a photoshop already designed mockup of the frontpage and you have to keep it (getting stuck on it)?
We (developer side) know the importance of content, but clients only (or mainly) pay attention to appearance usually. Specially when it´s about a image based company, such luxury products companies (where what matters is the brand image more than all those essence empty texts... I dont know if you know what I mean).

That´s why I was mentioning Edge Reflow and this kind of software, cause maybe (if they would write clean and right code) they could be useful tools to speed the work, to test, etc...

And here comes another doubt: I thought the new HEADER, NAV, ARTICLE, ets tags, were invented to add some semantic content to the code. And you tell me I´m wrong now! So the only improvement of HTML5 is around the videos and multimedia area?

Naaa, believe me, I prefer sincerity, Nobody can learn and grow when is falsely flattered. Thank you for your time and help

 

4.01 -- there is no 4.1. common mistake.

For me it just gets in the way -- I don't see how it offers anything in terms of speeding up the process other than all the things you shouldn't use. Restricting yourself to the parts that 'work' guts it's functionality down to that of pretty much any notepad replacement/programmers editor.

Then your job becomes to educate them. Point out all the design elements not compatible with a responsive layout, explain to them how with the plethora of target devices, resolutions and font-scaling that their 'pretty picture' will translate into being useless for visitors. Further explain the massive background images, images for nothing, and space wasting crap gets in the way of users getting to what's important on the page -- CONTENT! WORSE, most of what they vomit up and then have the massive brass to call themselves 'designers' with are a complete waste of bandwidth and result in slow loading sites -- that if slow enough will just make people go "screw this" and go somewhere else.

Generally speaking, anyone who starts out with a PSD doesn't know enough about the Internet to be allowed to have a website. If you cannot convince them of that, do yourself a huge favor and run... run fast, run far, run now, but most importantly -- RUN. They will be more trouble than they could possibly be worth!

That's why I say that most "graphic designers", or as I would call them "PSD Jockeys" don't know enough about HTML, CSS, accessibility minimums, filesizes, encoding, emissive colourspace (that one's shocking at times) or any of the dozen other things one should know for them to be designing but two things.

Oh, and you can always use the selling point "It will cost less to maintain and to host" to speak to the suit's wallet. Nothing will make a client tell their PSD jockey where to stick it like pointing out it costs more, might cost them visitors, and limits the target audience! ESPECIALLY in the age of responsive layout and the sharp upswing in mobile users.

Again that's where you have to educate them, and remind them that they hired you because they don't know the web. Explain the folley of such thinking.

Also, be leery of overdoing branding. Name recognition and instant recognition are good things, but some people overdo it to the point that you can trigger what's known as "ad blindness". Where they start glossing over the content assuming there's nothing of value on the page. It's a fine line to dance -- rule of thumb, the moment you're looking at more than 140k of page size BEFORE you even add content, you're probably crossing that line and need to inform the client of that.

I have a somewhat different view from the mainstream on a lot of topics like this. They are allegedly semantic but I just don't buy it. HEADER is pointlessly redundant to numbered headings or is used to group things that aren't actually headings, ARTICLE and SECTION are redundant to numbered headings and horiztonal rules from a semantic standpoint, the "let's make everything a h1" that goes hand in hand with ARTICLE and SECTION pisses all over both logical document structure and the entire reason headings have priority/level numbers... NAV is redundant to that heading navigation nobody other than Opera bothered to implement since it's official purpose is to mark a section as "you can skip past this to the content" (NOT that ANYONE is using it for what it's FOR -- seriously, read the spec!)

It's not even improvements -- it's kowtowing to Apple being dicks about flash and freetards saying that freedom is nobody should ever use proprietary software and that somehow their "ogg" crap is actually worth using. The end result has been a return to the WORST of the 1990's style format wars of WMP vs. QuickTime vs. Realplayer -- a fight that much to Apple and Microsoft's chagrin was won by Flash, which wasn't even considered a contender.

Worse though, the new tags for it -- AUDIO and VIDEO -- are REDUNDANT to OBJECT!

When HTML 4 was created, a whole slew of tags were axed in favor of OBJECT -- APPLET for example. Likewise some tags like EMBED were rejected for being... you guessed it, redundant to OBJECT. The idea was for non-text content to have one tag -- and for plugins OR internal decoders to handle files from that ONE tag. For the next version of HTML (back then) even IMG was supposed to be on the chopping block. The whole idea being to fight vendor lock-in of format support.

So naturally, with HTML 5 it's all about supporting each browser makers favorite pet codec/container combination, two new tags redundant to OBJECT are added, and EMBED is now back in for some ****Tarded reason. (since if you know what you are doing it serves no legitimate purpose unless you REALLY care about supporting Nyetscape 4)... and then -- the joke to end all jokes, they claim their vendor lock in and pissing all over user and developer choice is... to FIGHT proprietary formats and vendor lock in. Almost as ****tarded as what the FSF tries to call freedom.

I could go on for a LONG time about everything wrong with HTML 5 (see the link in my siggy), it's quite literally the worst of '90's browser war HTML 3.2 all over again... which is why I cannot fathom how ANYONE is DUMB ENOUGH to see merit in it -- unless as I say quite often, the target audience are all the developers who never pulled their heads out of 1997's backside in the first place.

At BEST it's just being used as a sick pointless buzzword like "Web 2.0", at worst it's undoing a decade and a half of coding practice by legitimizing buggy, outdated, broken bloated coding practices!

But beware, I'm in the minority on this... but that's because the majority of people making websites who haven't said "screw this" to go do something else, "**** this" to land in an asylum, or "to hell with it" and just plain died, well... can't be bothered to do anything properly and/or aren't qualified to do their jobs.

...and sad to say, I can name a dozen or more developers that fit into those three groups -- some of the most talented people I know have given up and gone to flipping burgers to neglecting their health right into being worm food, to eating a bullet.

So instead we're stuck with the inept morons who generally speaking probably have no business making decisions on how to code in the first place.

Wow, I'm nice and cheery today...