Content vs presentation.

That's pretty well it.

As you work out the CSS you are going to use you may find you need to add some additional containers to provide for some styling features. Normally these would be <div> and <span> with either a class or an id attribute.

With experience you'll get to know what containers you need and you'll add them in as you make your original HTML. With more experience you'll see the patterns in your HTML and you'll probably end up with a standard set of containers that cope with most layouts. By then, you'll have a standard template file which you'll use as the basis for most of your work.

Is it really really required to design for css-disabled users? How often do you get one? Why would CSS be disabled? It is like Javascript being disabled, you just shouldn't do it is it for PDA's and such perhaps?

Hi Chris,

Thanks for the reply - I appreciate it.
Sounds to me like the question I should be asking is....

Show me ya CSS and HTML templates!
I'll be certain to continue asking questions as I move along the path!

If you're using a screen reader to access a site, CSS might not be disabled but you're certainly not digesting the content in the same way a sighted user would. Search engines also don't particularly care what your site looks like but do like sites whose markup is well-formed which means it still makes sense if styles are off.

so basically, if you make sure your site works nicely without CSS enabled, your search engine results would generally be better?

Exactly.

Obviously there's a whole range of other things that affect search engine rankings but all other factors being equal, a well-formed CSS-based site should do better than one made from lots of nested tables for example. It's hard to say whether a CSS site made with images with appropriate alt attributes would do better than a corresponding one using image replacement.

The aim is to make your site readable to both humans and machines. Machines do a good job but they can only go so far.

There's also the consideration of images off rather than CSS off. You might not think many people do this either, but it is a concern for people with bandwidth restrictions (mobile, dialup users).

And apart from assistive technologies, there's also older browsers which (if you use @import to call your stylesheets) will see the page with no styles applied.

great info.

isn't it a really big chunk of work to keep this in mind when creating the pages?

offtopic; personally I'm very bothered by the small paragraph-spacing

Not really, no. Just create the page with proper HTML and the rest automatically follows.

It isn't a "big" chunk of work. But it is extra. Some of it you can do by habit. Learn the arguments for it and use them to convince your clients to pay you to make their site to a much higher standard.

Get in the designer's face and convince them to produce designs which make this easier for you.

On the text image thing. Try converting the site to spanish or in contintental europe making a site with native language + english. Not speaking english isn't even a disability in some parts of the world

Yeah, that and:

• cross browser compatibility
• different screen/window sizes
• different text sizes/text size scaling
• javascript disabled
• images/CSS turned off
• user stylesheets
• code validity
• WAI guidelines
• assistive technologies
• those who don't use assistive technologies but still have trouble accessing sites, e.g. keyboard-only users (or people who choose to only use the keyboard out of preference)
• what it looks like when printed
• what it looks like on handheld devices

And that doesn't even touch on usability issues, actual content and whether it looks good or not.

Sure that's a lot to keep in mind and how much of that you take into consideration will come down to how good a job you want to do with how much you know and how much time/money you have.

All those things Tyssen mentioned? Just work with well structured, semantic and valid html.

The trouble lies in letting yourself not be concerned with how the output looks. Ask a writer what the most difficult thing about writing clear, concise, understandable English is, and he'll tell you it's writing the simple declarative sentence. HTML markup, like writing, has authors stumbling over the simplest thing. You absolutely must begin with the simple, non-presentational html. All else is layered on top.

The css that makes your page so attractive works against the Document Object Model (DOM) to add presentation rules to the elements. If it is not supported, the underlying structure and functionality remain.

Likewise with javascript and its little brother, AJAX. Both depend on the DOM, which has been defined by the html markup. It is layered on top so that non-support does not affect the structure and functionality.

If your html is a pig on roller skates (javascript), wearing lipstick (css), it's still a rollerskating, red lipped pig. If your html is well structured, semantic and valid, and you add lipstick and skates, you've got a good looking hardbody rolling down the Venice boardwalk. She can take the skates and lipstick off and I'd still rather kiss her than a roller skating, red lipped pig.

cheers,

gary

LOL! You're totally insane. Will you be my mentor?

but really, is it worth the extra time or money to have that extra user who has css or js disabled, or is willing to use user stylesheets, or any of those other things?

I have the feeling it's such a small portion of the visitors that I don't know if you should really invest that extra time.

I have the feeling it's such a small portion of the visitors that I don't know if you should really invest that extra time.
I guess it all comes down to whether you have integrity or not. Only you can answer that question.

Your sort of missing the point that is being made a few times , you are thinking that this all equates to work or extra work on your part which is looking at things the wrong way.

You do all this and pay attention to the points mentioned as this is the proper professional way to approach coding (X)HTML/CSS and of site building in general, you must have valid semantic code it's your framework on which everything else is built it is first and foremost, prime, the bedrock, without it you have built your home on subsiding soil without proper foundations.

To view your markup sans styling is just to get a good picture of how your code actually stacks up, makes sense. CSS is just cosmetic fluff and not a requirement; valid semantic markup is though and through it you will arrive at your goal of good search engine placement, but don't code just with the belief that your gaining better search engine spidering think of that as a side benefit of coding cleanly and properly.

Accessibility also mustn't be thought of as a chore it is a necessity and again one that is arrived partly through coding well it also always has been part of the standards.

Hugo.

ok well I work with standards all of the time, I think that's best to start with. What is left after that is debugging for IE for proper display. I understand the use of alt's and title's, and most other HTML elements and attributes. Following these directions saves time and improves the quality by big big steps, as I have noticed.

Creating a site which would work without JS for example, would really cost me dozens of hours extra (since most of my work is application development). It would mean I have to adjust so much things, that it is hardly doable, especially when it's work paid for by someone else. I'm having problems selling stuff at half the rate of what it should cost them, as if people don't know how much work I put in to it. It would really seem undoable to tell them I need 50% more time to make sure it works without JS, which would give them maybe 2% profit.

I don't see how it's going to pay off..

But you don't build sites that rely on javascript do you? sites have to work without it, what happens if I have it disabled and visit your site? What do you have on the site that relies on javascript and that doesn't degrade gracefully in some fashion?

Desdinova you're right. But at least now you are able to make the decision fully informed of the facts. You can also bring those facts to your clients and 99% of the time they'll probably say, no don't bother. But just one or two will agree. Just maybe, you'll find those jobs and those clients particularly lucrative.

Hugo's also right. If you approach this in the right way from the beginning you can keep the user informed of what's going on - even if the site owner doesn't care what happens to them.

well for example I have a javascript / ajax based webshop. cart, products, categories, everything is dynamically loaded on request without page refreshes.

turning off javascript would mean I'd have to basically create a second webshop, but then not based on ajax. and considering I can't even begin to picture a clean image of how to do that in the best way possible, I'm presuming it's a *beep*load of work

so that's basically the biggest 'problem' I'm running against.

There are ways to make AJAX more accessible (James Edwards is one of the leading authorities on the subject) but in your case, if it were me, I would've thought long and hard about going down the route you've chosen in the first place.

I would be extremely wary and cautious of predacating any design model on JavaScript/Ajax, in fact personally I'm very wary of Ajax altogether and of the whole 'buzz' around 'new' technologies and am starting to worry with the work I'm comming across that is stuffed to the gunnels with script library after script library, multiple css stylesheets, and the beginnings of markup bloat to handle it all.

I think it was said earlier but Javascript/Ajax is just a layer sitting over the fundemental jobbing aspects of a web site, and as such must be regarded as secondary to the main aspect which must function without any of these overlays, the core of web site development is pretty simple revolving around server side processing and HTML output of generated content or static, you are dealing with DB, scripting to process that information and generate content, HTML to provide the language the browser can interpret and CSS/JavaScript to style and present that information in a pleasing maner but that last aspect is not essential to the fundemental purpose and ability of the web site to fullfill it's intended function.

You just need to outline the problem at the beginning, you'll find the solution is not really much different that what you are doing already.

Ajax is like a cut down way of only supplying the information to the browser that has changed in response to their most recent action. Really, what's the difficulty in regenerating the rest of the page along with that changed information?

The point is, Desdi, that you have to build your commerce site, or whatever, using html and a server-side script+db no matter what happens client side. Everything you get from the client is untrustworthy, especially data that has been collected, cookied, manipulated or otherwise massaged by javascript. So you have a base PHP (say) application to begin with. The javascript, if enabled, can simply capture the the html events and reroute them. Used as a progressive enhancement, it adds value to those who can use it, without reducing the functionality for those who can't.

I find that maintaining orthogonality means I end up saving time. I can make changes in one layer with minimal effect on the others. This is true client side with html, css and javascript, and server side with php, db and html. Compared to an intermixed model, maintenance becomes a dream.

Think back to the time you switched from doing table layouts to css controlled layouts. Were you slowed while learning the new stuff? I was. I can lay out a fairly complex page on the fly, now. Switching to unobtrusive layering of behavior will have its own learning curve, but you'll be ahead of it soon enough.

cheers,

gary

It took me three reads of this

The Practice of Orthogonal Design

To understand what on earth that word meant.

Ow, my head hurts.

Hah! It took me a couple of reads, and I already knew what it meant. Clarity is not that author's strongest suit, though a certain pedantic accuracy may be.

Total orthogonality is impossible, simply because there must be some point of interaction. If we can limit that point to the DOM, we've likely done as well as possible.

An interesting experiment to demonstrate that html, by its ownself, has nothing to do with how the final rendering will look can be easily done. Somewhere in your Firefox directory tree is a folder call "res". In that folder is a file called "html.css". Rename that file to, say, "html.css.hide". Now view an unstyled web page. The result is a stream of undifferentiated text.

Every browser has some sort of style sheet. Even Lynx adds formatting to headers, paragraphs and lists. Links are color-coded. None of that is inherent in the html.

Now go back and undo the renaming of html.css before you make yourself crazy wondering what's wrong with Firefox.

cheers,

gary

N.B. I'm sure Hugo thought I had simply misspelled "octothorpe"

mmhmm. points noted. I think I should just try working like that, starting with smaller projects and learning from that.

so basically,
start with plain HTML, no styles or whatsoever, making sure images can be disabled without losing functionality,
upgrade the looks with CSS,
upgrade functionality with JS (when required)

Treva I realised ages ago that I needed the OED and a plethera of reference tombes by my side when trying to interpret Gary's flights of wordsmanship.

My problem with Orthoganilty is - apart from spelling it - it's pronunciation, and how to slip it casually into conversation without sounding like a complete pillock "Of course othio.. orgona.. " it's just not a pretty word, definitely not 'Woody'

My problem with Orthoganilty is - apart from spelling it - it's pronunciation, and how to slip it casually into conversation without sounding like a complete pillock "Of course othio.. orgona.. " it's just not a pretty word, definitely not 'Woody'

haha that cracked me up

so basically,
start with plain HTML, no styles or whatsoever, making sure images can be disabled without losing functionality,
upgrade the looks with CSS,
upgrade functionality with JS (when required)

Essentially, yes.

With experience though you don't need to be ultra literal about non styling, I'll often have a good idea of what I want to do and although I start by describing the markup file next to that I'll have a styleshet already linked to it and be working between the both styling as I go, it's just that the markup file is the primary concern as it's the base point without that nothing happens without CSS I still have content rendered, but everything else client side (JavaScript)would definitely come after the layout and content was looking pretty much finalised.

What an interesting read this thread is, and how wonderful that all the forum 'old hands' are singing from exactly the same hymn sheet on this important and fundamental issue. As a web application developer, I feel the need to compliment Hugo's and Gary's posts above this one - wise words indeed, whatever orthogonality means

I only have one thing to add or expand upon, and that is in response to the original question of why separate content from presentation. Repurposing and updating. Okay, two things to add! By coding the basic web page in clean, semantic (X)HTML with all the styling in a separate CSS stylesheet, one can produce different stylesheets for different uses, tastes, media or abilities (or different rules within the same stylesheet).

This is as relevant to applications as it is to websites nowadays, as more and more client-end-users are using applications from home and via mobile devices, and the DDA (or whatever disability regulations are relevant in your country) applies just as much to business applications as it does to websites.

And when your client rebrands their business seemingly on a whim (which so many often do), how simple it is to change a single stylesheet and switch it over in an instant, compared to redesigning an entire website's collection of HTML pages.

For me, it's also an issue of pride in one's work. Most professional people spend years in training for their chosen profession (including me in my former role as an avionics technician), learning the right and wrong ways to do things, and all about regulations and why they are needed. The untrained builder who constructs house extensions will almost certainly leave a trail of damp walls, cracked render, leaking roofs and shifting foundations, leading to loss of recommendations, law suits and eventual bankruptcy; whereas the trained builder who understands 'best practice' will leave satisfied clients who will tell other people, which will lead to more work than the builder can cope with. Website and web application development works in the same way. So if you care about your future success, keep on top of 'best practice', practice 'best practice', and become the sort of person who deserves the name of 'professional practitioner'.

You see, I'd say essentially no.

That order maybe fine for a simple website, but its no good for an application. HTML is only the encoding you use to give your users a view of the information that makes up the application. You shouldn't go anywhere near constructing that until you know what that information is, how it is organised and what activities you will be performing on it.

Read up on design patterns. In particular, many web applications are instances of the MVC pattern. If you can separate the model (data, business logic, etc) from the view (what the user sees), then after each action by the user you send them the details they need to see the new state of the model. If AJAX is available the amount of information you need to send is reduced - you are able to leverage the unchanged parts currently on their screen. If AJAX isn't available you send them a whole new screen.

Interesting thoughts Chris.

When creating an application, I tend to cut to the chase and analyse the Inputs, Processes and Outputs (IPO's).

In the case of a server side web application for example, the Inputs come via a form for example (and a SQL db) the processing is the php (or whatever) and the outputs are the finished pages. At no stage of this process do I consider the appearance of the input forms or the output pages. In fact, when testing, I never have anything other than a plain text form page.

And when testing the output pages, again I always output to plain text. Once I have that working, I add the semantic html. I tend, with php, to have small html templates files that I import, pipe the output into and merge into a page. The styling comes only after I've got it all working.

CT

Maybe the following is just different semantics....

Pretty much, except for the above. The pages are the view of the underlying information that you are presenting to the user. The outputs (at least as I think of them) are more real, e.g. an order if its an online store.

In something like this forum, there aren't really any outputs, except maybe notifications. Inputs are new posts. After recieving an input (new post) and processing it you update the users view of the forum (show them the thread with the new post added). The web page is like a window on to a particular part of the information in the application. One part of the application should be responsible for ensuring that every user has an up-to-date view of the underlying information. Another part is responsible for enacting changes to that information. Your application will now have three parts.

- a series of routines to enact changes
- a series of routines to present a view of the underlying information to the user
- a routine which arbitrates incoming requests and determines what to send back to the client to ensure their view is up-to-date. (If you wish to call this output fair enough, hence my note about semantics at the top).

Ah You are taking it to a new level Chris with the MVC model/pattern

Cant argue against it as I've been looking at that recently with a view to starting to use 'Cake' or similar.

I think that the essential premise of previous points holds true though regardless; there was or seemed to be a fundamental problem with separating these various stages.

You might want to take a look at Code Igniter too (same people behind Expression Engine). I'm just having a play around with it at the moment.

tl;dnr

Cant argue against it as I've been looking at that recently with a view to starting to use 'Cake' or similar.

I think that the essential premise of previous points holds true though regardless; there was or seemed to be a fundamental problem with separating these various stages.

When it comes to application design I ALWAYS do the html / presentation first. The User interface IS the application to the user.

And that's regardless of whether or not you use some sort of domain model or MVC or any other design pattern that you ultimately end up coding in.

How can you possibly know what to code if you don't have a working front-end for the users to play with? It's a case of welcoming scope-creep into to your application.

I use the HTML-only prototype as the technical specification for coding against. Once the prototype "runs" the application can only be deemed a successful software project.

Coldfusion developers may well be aware of Fusebox and FLiP. What most non-CFML developers don't know is that FLiP is language independant and indeed Fusebox, is available for PHP and JAVA too - not just its original CFML flavour.

I don't wantr to get all evangelistic now either - but if you have the urge - you can get a blurb on FLiP at;
http://www.fusebox.org/index.cfm?fuseaction=fusebox.overviewFLiP

There's even a snazzy little brochure!
http://www.grokfusebox.com/downloads/FLiPRoadmap.pdf

It's a good point TroubZ at the end of the day all the user sees and is interested in is the rendered output, regardless of what backend may be occurring and in what fashion/flow/pattern I would be lost without some firm idea of how that information is structured and presented.

So FLiP decrees that know architecture be done before the front end complete, but am confused by the "so complete that the user can try out the software before it's actually built" :? I guess by that they mean view the visual interface?

Interestingly Tyssen I had been looking at both and dithering over which was the right choice, my initial inclination was for 'Code Ignitor' as I liked it's lightweight easy install/configuration and it's intended aim to be straightforward to get to grips with also I thought that it's documentation on it's site was excellent, but something worries me in it's decision to work with PHP4 rather than 5?.

Looking at Cake and noting comments it seems that it is a slightly more advanced offering and perhaps although a steeper learning curve the better choice? but I've slightly lost track of my mental pros and cons list for each.

But, an awful lot of servers still don't have 5 on.

No, but the better ones do. And more will.

Hugo, I have looked at Cake too. Recently someone recommended Symfony to me as being more advanced. They only use Cake when its php4 compatibility is required, prefering Symfony when php5 is available.

Troubz, I'd reckon what you're talking about is only possible because you have a pretty good idea in your head of what the application is, what it will be doing and you're building your pages against that idea.

now I have three to deliberate between, off to have a look at sympfony although I do still have a sneaking liking of code igniter

TroubZ hit the issue squarely. The interface is the application as far as the user is concerned. The UI must be developed early on in the process. If you follow an orthogonal approach, the UI cares not from where or how it gets its data. Data is the job of the behavior leg and is a black box as far as the UI is concerned.

The discovery process with the client will give you the specs for the UI (and the business logic). What does the user need to see, to enter and to get back? In a web app, you have enough to create your html templates with placeholders for dynamic data. A templating engine like Smarty will make it easy to keep the html separate from the backend logic.

On the client side, the css layer adds the presentation and an unobtrusive javascript/AJAX layer adds user convenience.

Keeping each layer separate means you can vary any of them without appreciable effect on the others. All any layer needs to maintain is the API.

cheers,

gary

He's using that word again!

So I think were all agreed on the fact that this generic issue of 'separation' is important to working well.

Can someone now tell me which framework I should use Code Igniter, Cake, or symfony?

I have Smarty installed but had sort of decided against the templating approach but then again the frameworks template to some extent.

There are lots of others, including one by Zend.

I'll probably go with Cake or Symfony

Didn't we debate the merits of templating before
I am sure all the frameworks will use some or other form of templating. Some can use different templating engines including smarty.

Yes we did indeed cover templating in a thread a while back.

Having spent most of the evening flipping back and forth between the three choices (well three after symfony had been thrown into the mix) I had pretty much settled on symfony as being the best, mainly due to the fact that I liked the views model approach over the other two offerings , niggles are that it requires PHP5 which means that I have to rule out one of my servers(not a huge problem) and I can not yet get a clear picture of the install routine and file path configuration or how I ensure that it will mirror a production site on a shared server , but that will become clear with testing I guess and it does have a sandbox quick install for playing with, but cake is still in the running as it will install with php4

Hey, what is this symfony? What are you guys getting me into now??? *sigh*

I was just about to buy a book about Smarty, but balked because it sounds rather boring. Whatever happened to the classics?

Hi Hugo,

So FLiP decrees that know architecture be done before the front end complete, but am confused by the "so complete that the user can try out the software before it's actually built" :? I guess by that they mean view the visual interface?

Lets just go with a simple search form for an example.
using JUST HTML you code up your search page.
You place logos in the place they're meant to be, any filters the form is required to assist searching and a footer - all the page furnishings that you would expect to see in the "completely finished" search form.

It is an EXACT replica of what the final page would like.

You then give the search form an action page of, let's say, dsp_search_results.htm and you go off and create the results page in HTML.

The search form - has no REAL action page. it does not verify the user's input for validity, it does not do a DB query to retrieve results. It is just a shell - that allows the user to fill in a search form and press the "search" submit button.

What the user expects to "see" after they press a "search" submit button - is the search results. So you display some search results with apparioate data for the application you're writing. The search reulst WILL NOT match the search form's input - but that doesn't mater. It's the look and feel you're getting right - and that is all the client cares about.

It is all smoke and mirrors - but with a couple of gotchyas.

You invite / beg /grovel the client to complain about the html you have just created. If they want round buttons - you give them round buttons.
If they want the order of form fields changed - you do it now - but you're doing it in plain HTML that is quick and cheap to work in.

Once youhave a completed application in HTML only and the client believes the application is ready for coding, you have reached the point of "prototype-freeze". There are no more changes after this. They go in V2. The Prototype becomes the requirements document for your coding.

When you deliver a "coded" prototype that runs, you have sucessfully completed the application.

And that's exactly how I do it.