With the recent browser statistics, that show Internet Explorer 6, Mozilla/Firefox, Safari/Konqueror and Opera combined at around 95%, it is finally feasible to write modern, CSS-based websites. For many years, this was not possible due to the vast number of legacy browsers, Internet Explorer 4 and 5 and Netscape 4 deployed on the computers around the planet. But with these browsers vanishing, we can finally start to ignore them.
And it’s not just the declining number of these browsers. I recently talked to two people that still surf the web with these old browsers, and they both basically said the same: "We’re used to having problems with websites, our browsers are old. No problem, that will simply go away when we buy a new computer." While this is of course not representative, it supports my growing opinion that we can start to ignore old browsers. The tipping point for me was that Gecko-based browsers have overtaken IE4/5 and Netscape 4 recently (this is probably a safe bet according to recent web statistics). So it’s already more important to have your website work with Mozilla than with any old browser. Basically, if you code standards-compliant HTML and CSS, your site will look the same in Mozilla, Opera and Safari. And while Internet Explorer 6 does have certain problems with stylesheets, it certainly is "good enough", if you know its quirks.
So, today, I want to talk about various aspects of modern webdesign. This may be helpful for all of you who want to write HTML by hand and not use WYSIWYG-tools like Dreamweaver and Frontpage. In case you don’t know: WYSIWYG stands for "what you see is what you get". With WYSIWYG-tools you work on your actual website, the program writes the code itself while you put images on the site, create text, and so forth. You may ask: "What is the advantage of writing code by hand?" Well, in my opinion, there are several differences. Dreamweaver MX 2004 actually produces far better code than his predecessors, but you simply can’t compare designing with a WYSIWYG-tool to writing code by hand. The latter gives you much more control over the design of your page. Basically, you know, at any time of the design process what you have done, what you are doing and what the consequences of your actions are. "Debugging" your website is a lot easier that way. The code you produce is a lot smaller, thus more efficient. All webdesigners out there will have to deal with HTML and CSS at some time. So it’s better if you are prepared! Also, Dreamweaver costs money and may not exist for your platform.
Anyway, designing websites with Dreamweaver is not the topic of this article. All you need today is a text-editor and a browser. Preferably you have more than one browser, at best you can test your website constantly with Internet Explorer 6, Mozilla, Opera and Konqueror. I’d say: at least IE6 and Mozilla are required. Also, a good book about HTML helps a lot. I use this compendium constantly. Good books about CSS and webstandards are "Eric Meyer on CSS" and Jeffrey Zeldman’s "Designing with Web Standards".
So, first of all, let’s explain what we are talking about: HTML is the Hypertext Markup Language. Most of the modern websites are written with HTML (an alternative way to create a website would be Macromedia Flash). CSS stands for "Cascading Stylesheets". HTML is meant to contain all your (preferably well structured) content, stylesheets are there to control the design of your website. "Rendering" is the technical term for what your browser does when it displays a website.
Well, let’s get started: open a text editor (preferably one that can highlight syntax, like Bluefish or Quanta+). The first thing you will want to do is put in this text:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title></title>
<meta http-equiv="content-type" content="text/html;charset=iso-8859-1" />
<meta http-equiv="Content-Style-Type" content="text/css" />
<link rel="stylesheet" type="text/css" href="link/to/your/stylesheet.css" />
</head>
<body>
</body>
</html>
Wow, that was a piece. What’s that? Well, the first line is the "Doctype" definition. What we do here is tell the browser that it is about to display an XHTML 1.1 file, this is the most recent HTML standard. If we do this, the browser will expect perfect, well-formed XHTML 1.1, thus rendering our site in standards-compliant (strict) mode, so the results will be a lot more predictable. If we don’t include this Doctype, the browser will render the page in "compatibility"-mode, that means it expects old, "bad" HTML and will try to guess what to do with it. Unfortunately, this is exactly what browsers have to do most of the time nowadays. After the Doctype definition, we start out HTML-file with the opening "html"-tag. After this, there’s a "head"-section and a "body". Basically, HTML and all Markup languages work the same way: you open a "tag", with <tag>, then do something, then close it with </tag>. You "mark up" what is between this beginning and closing tag. The head contains some information about the document, the body contains the information that is displayed on the screen. Enter some information into the "title"-tag. This will be what you can read at the top of your browser if you open your website. The following "meta"-tags are not important right now, just be sure to include them. The "link"-tag is interesting. Here you will link to your stylesheet (that still does not exist right now) to make sure that your HTML-file finds the stylesheet. Afterwards, the "body" starts. For now, just write anything into the body (like "Hello, World!"), save your document as "index.html" and open it with your browser.
At first, we will talk about the HTML part. Before you start with your website, you should plan what you want to do. Most of the sites are happy with 2-3 sections. A classic layout will include a header, a menu and the content. You can view a simple example for this on my site. A tip: view the source code of pages you like. Sometimes you can get really useful information out of it.
There are not too many HTML commands. Here’s a short list of the most important tags: div, p, br, a, h1, (h2-h6), img, ul, ol, li. I don’t even include the dreaded "table", that was used for old-school webdesigns, because i personally rarely ever use it. Probably the first decision you have to make is how to divide your website. Use the "div"-tag to make some basic divisions. The "body"-section of your document could now look like this:
<div id="header"> <h1>Welcome to my Website</h1> </div> <div id="menue"></div> <div id="content"> <p>Here goes all my content, but I don't have any yet.</p> <p>Let's make another paragraph.</p> </div>
The "id" is an identifier. We need it so that our divisions make sense later on. You can apply this "id" to ANY tag. The stylesheet will use this identifier to assign styles to the document. But we’ll talk about this later. So, now we have a website with three sections. We use "h1" (heading nr.1) to write a fat "Welcome"-message into the header-division of our file. No stuff in the "menu"-div, because we don’t know yet what menu items to include. In the content, we use the "paragraph"-tag "p" to write some text. Just to make sure, I will emphasize on this: you have to close EVERY tag that you opened, and you have to close it IN THE CORRECT ORDER. Let’s talk about the tags I mentioned: we already know that "div" does nothing but define a certain section of your document, "p" creates a paragraph, "h1" (and his smaller brothers "h2" through "h6") are used for headings. "br" creates a simple line break, it’s the "smaller brother" of "p". "ul" stands for "unordered list", "ol" for "ordered list". If you use "ol", your browser will automatically add numbers in front of the items. They both need "li" ("list item") to mark up the specific items. Lists look like this:
<ul> <li>item</li> <li>item</li> <li>item</li> <ul>
Possibly good for our menu, eh? Now we only have "a" and "img" left: "a" ("anchor") is used for hyperlinks. Use it like this:
<a href="http://www.somepage.com">text about somepage</a>
Again, the only thing that is actually displayed in the browser is what stands between the tags. In the opening tag, you tell the browser where the link actually goes to. Quite simple, isn’t it? You will need "a" tags to "weave" your websites together: linking to another document in the same folder would work this way:
<a href="dog.html">View more information about my dog</a>
That doesn’t restrain to websites, you can also create simple mailto-links, by using
<a href="mailto:[email protected]">mail me!</a>
Be careful, these links only work if your viewer has a mailprogram that the browser can call! Now the only thing that’s left is "img" (obviously for "image"): we have already learned that HTML is a markup language. So, we can’t simply put a picture into our HTML-file. We’ll have to put the picture somewhere and tell the file where it is. The according syntax would be:
<img src="dog.jpg" alt="my dog!" />
Explanation: "src" ("source") tells the browser where the picture is, the information in "alt" is displayed when the picture can’t be accessed, or by text-only browsers. One word about the trailing slash: XHTML 1.1 requires you to close ALL tags, even those that are standalone-tags like "img". So, you’ll have to write <img src="blah.gif" alt="blah"></img>, but you can do this a bit shorter by using the above syntax – space and slash. The only other item of our list that needs this special syntax is "br", which should always be written <br />.
So, now, we know the basic ingredients of a HTML file. I encourage you to view the source code of my website, it will be much clearer now. I used "dl" and "dt" ("definition list" and "definition title") instead of "ul", but that’s a matter of choice. I added a comment into the body so I don’t forget how things work. It’s generally a good idea to use comments. They are added within the "body"-section by using <!–comment–>. Pretty arcane, eh? Well, once you’ve remembered that, it’s easy. The browser will ignore everything between the opening <!– and the closing –> when rendering the page. On another note, as you can see in the end of my code, it’s easily possible to use images as links. The syntax should be logical to you (if this was a good article until now):
<a href="http://somewhere.com"><img src="picture.png" alt="picture" /></a>
Now, you have a basic introduction into HTML, but, as a matter of fact, we haven’t done any actual designing yet. Let’s get it on! First, we go back to the "head" of our file. I have talked about the "link"-tag, that goes to a stylesheet.
<link rel="stylesheet" type="text/css" href="link/to/your/stylesheet.css" />
Now it should be a little clearer what it actually does: it’s a standalone-tag, so it needs the special closing that "br" and "img" have. The "href"-part should also be clear now, it works just as in a normal "a"-tag. So, we have to put our stylesheet exactly where this reference tells our HTML-file where to expect it. We also define a type "text/css" (this is just standard).
The big advantage of a stylesheet is that we have a central place to control the design of our website. Your website can be composed of thousands of HTML-files, as long as each of them has this link-tag in the head, you control their design from within a single file. HTML is only here to structure the information. Thus, HTML mostly consists of tags for headings, paragraphs, lists, tables, divisions. The clearer the structure of your document is, the better. Stylesheets on the other hand are there to design all these elements. Now, we’ll have a short look how stylesheets are constructed. Stay with me, it’s a lot easier than you might guess!
/* Stylesheet for my new Website */
body {margin:0; font-family:serif; background-color:red;}
h1 {font-size:24px; text-align:center;}
a {text-decoration:none;}
#header {position:absolute; left:20px; top:20px; width:300px; height:50px;
border:3px solid black;}
Let’s clear all this up: first of all, comments in stylesheets are added by /* and */. That’s different to HTML-files. Sucks, eh? Well, unfortunately, there’s nothing I can do about it… The basic syntax of a CSS-entry is item {attibute; attribute;}. In the first row, for example, we tell our browser that it should use serif-fonts for the whole "body", that our HTML-file has a red background and that it has no margins (you will want to set that to 0 to be sure that your website starts in the upper left corner, most browsers will set a margin of 10 pixels by default if you don’t set it explicitely). The next row defines some styles for our "h1"-headings: the font-size should be 24 pixels and the text should be centered. Then we have a very popular definition for hyperlinks: "text-decoration:none" is used to get rid of the underlines of links. Starting to get it? Well, the last one is a little different: remember the "id=header" we used for our first div? Well, with the # in front, we now refer to exactly that division: we tell it something about its positioning, its width and height. I don’t want to go into detail too much because I don’t want to overwhelm you with CSS commands. There are not too many of them, but you’ll have a far easier time with a good book about CSS on your desk (preferably one you even have read once). Trust me, as soon as you have grasped the idea of CSS (which you probably have right now, because, refreshingly, there really is not much more to it than what I have told you), it’s easy to read through a small book and get to know all the commands. Again, there are only a few really important ones: margin (distance from an items border to the next item) and padding (distance of the item towards its own border), border (self-explanatory, I guess…), position, top, left, width, height (to put an item somewhere on the page), font, font-weight, font-size, font-family (for assigning special font properties), color, background, text-align are basic examples.
A word on the "cascading" part of the name: it is, for example, sufficient to tell your CSS something like: body {font-family:verdana;}. Your browser will assign the verdana font family for every item on the page, you don’t have to repeat this for "h1", "p", "a" or whatever. If you, however, decide that you want arial for your hyperlinks, you just add a {font-family:arial;} to your stylesheet. Your page will now still be all verdana, with the exception af the hyperlinks, which will be in arial.
In the end of this article I want to illustrate what is possible with stylesheets on the basis of an example that I used for my website. Let’s look at the code first. In the HTML-file, we merely have:
<div id="header"><h1>/home/chris</h1></div>
In the Stylesheet, we have:
#header {position:fixed; top:0px; left:0px; height:136px; width:100%;
background:url("background.jpg") no-repeat;
border-bottom:4px solid #a00;}
h1 {font:italic bold 32px serif; text-align:right;
margin:10px 10px 0 0; color:#a00;}
Explanation: while I only use two tags in my HTML, a "div" and a "h1", I use the stylesheet extensively to design the header and the heading: first, I assign a position to my header, a height of 136 pixels and a width of 100% (yes, percentages are possible). Also, I define that the header-div should use a jpg as background. "no-repeat" means that this jpg should be displayed just once (you can also use a small picture and repeat that over and over again to get some kind of a muster). Finally, I define a border on the bottom of the div with 4 pixels, solid (versus dotted, dashed and a few other possibilities) and this border should be some kind of red. Then I define for my heading, that it should have an italic, bold, 32 pixels big serif-font. It is text-aligned on the right side, but with a margin of 10 pixels to the top and the right (and zero pixels to the bottom and left, this works clockwise), so that it doesn’t "glue" to the upper, right corner of the browser-window. The heading gets the same color as the border of the div, a00. So, with some heavy stylesheet use, I was able to completely seperate design and content. If i want to redesign my website today, I do not have to touch any file except for the stylesheet!
Almost done, there are just a few more things that I want to mention at the end of this article. You can use more than one stylesheet at the same time. You can, for example, use a second stylesheet to control the print layout of your site. Just add this to your header:
<link rel="stylesheet" title="standard" media="screen" href="screen.css" type="text/css" /> <link rel="stylesheet" title="print" media="print" href="print.css" type="text/css" />
We just added a "media"-attribute. A browser uses the first stylesheet to display the site on the computer monitor and the second stylesheet on the printer. Both styles may look completely different and can exist completely independently from each other. You can even add special divs (or any other items for that matter) that get the attribute display:none;, so they don’t get displayed either on the screen or on the printer. The possibilities are endless. A final tip for all webdesigners out there: test your code constantly. Often, when I do something difficult, I just add one attribute at a time and immediately look what changes on screen occur before I change/add another attribute. Probably the biggest advantage over designing with a WYSIWYG-tool is that you retain complete control over the design and creation process. Arcane errors that are difficult to debug almost never happen.
So, that’s it for now. Some more eyecandy can be found at csszengarden.com, another interesting site with great articles is alistapart.com. I really hope that some of you could put this to good use. Thanks for your attention!
About the author:
Christian Paratschek is 28 years old and lives in Vienna/Austria/Europe. If you liked this article, go check out the other stuff he wrote here … but if you’ve made it this far, you probably already have visited this site anyway 🙂
If you would like to see your thoughts or experiences with technology published, please consider writing an article for OSNews.
Fedora is doing the internet a service by ensuring that customers do not accidentally stick with old versions of software by dropping support after six months. The general binary incompatabilty seen between minor versions of most Linux distributions further ensures the need to upgrade. Not only is this upgrade cycle beneficial for consumers, but it’s also a driving force for broadband adoption in many developed countries. This is why we have seen a major push from many broadband vendors like IBM and HP.
People will upgrade free software, but they will resist forced upgrades.
I’m running FC3 now, and is it ever sweet.
I created my personal site from scratch, using the Bluefish editor (or emacs remotely). I like Bluefish because it is pretty to look at with regard to the fonts and the syntax highlighting (emacs isn’t bad with the php-elisp package installed). This allowed me to have complete control over every detail when designing the layout of the site. The only tricky part is trying to get the site to render uniformly in all of the different browsers, especially with many floating div elements and stuff like that.
http://www.nerdsyndrome.com
My PHP powered site is fully XHTML 1.0 Strict compliant, and makes use of CSS for the layout. There are _no_ tables at all. Because my site is one of my primary hobbies now, I work on it all the time, and the layout constantly changes.
My favorite elements on my site are the random image collage on the index page, and the new blog engine, which is easy now quite easy to search.
Recently, I have been learning more PHP and MySQL stuff, and have a full SQL backend for the blog and the gallery, both of which I wrote from scratch.
Fun times.
Currently, I am working on a new front-end that will allow me to submit new blog entries in a nicer way (using phpMyAdmin to do that now) as well as attach images, and automatically generate thumbnails for images I attach. I am hoping to have that done by the end of the year.
Internet Explorer is the new Netscape 4.
Nice website, and this guy is learning new things. That’s much better than going the FrontPage route.
Unfortunately, if you run an e-commerce site, 5% is not a negligible quantity. So you still have to be careful using fancy code.
It’s one thing to be coerced in to downloading new versions of what you already have for free. It’s a whole other deal when you’re coerced in to paying a few hundred dollars for the same service. Linux distro’s are in the good column here while Microsoft is in the bad column.
About auto updates: In most Linux distributions, you can get a good, detailed list of changes that happen in every update you download. You can also choose not to install an update and not worry about it. Windows? You get a blurb, and an unacceptable amount of the time, you later find application breakage.
Now, again, this would be a whole different issue if in Windows, the OS and applications were all free. Fixes would be made. Workarounds released. Better testing. But no, not only do you pay big bucks for this software, but it’s harder to fix problems that come up when your vaguely described security update breaks your mission critical app.
Guys, wasn’t this thread meant to be about creating webpages?
The little difference is that you don’t have to pay for Fedora upgrades. Also, your Fedora will not stop working after six months, there will not be any updates for it.
(pun intended 😉
Take modern browser, and see what it supports: HTML4 (with tables, frames, you name it), XHTML, XML, CSS1, CSS2, JavaScript, and plugins for common things like Flash, Java, Quicktime, etc. etc.
Add to that server-side stuff like CGI, PHP, and all the other things one could run on modern webservers.
It always amazes me how so-called professional webdesigners put together sites that just don’t work, or are worthless from a usability point of view, when they’ve got all this software tech at their disposal. Some text-based content, but left side outside of screen, unnecessary scrollbars, non-working navigation-buttons, half the screen empty, text too small to read, painful color combinations, you name it. Beautiful looks, but content is hard/impossible to access, and thus useless to visitors.
Designers should start with the content, and wrap it into a suitable format for presentation. Unfortunately, it’s often done the other way: start with nice looks, and squeeze content in it somehow. Yeah, good site design remains a fine art, and some designers still have much to learn.
Oh yeah, I forgot: use basic stuff (HTML, CSS) for content access/navigation, and JavaScript, Flash etc. for adding looks. Requiring JavaScript for navigation buttons to work, or a Flash/QuickTime intro without “skip intro” link is just bad design (and pissing off users)
Problem: The author is using XHTML 1.1.
!NO! version of IE is able to properly understand XHMTL in any version. See: http://www.hixie.ch/advocacy/xhtml .
I simply cannot understand the blind focus on XHTML as being the holy grail of website publishing when the first thing you do after having made and validated your beautiful XHMTL pages is to break them and get them treated as HTML 4.01 in quirks mode by serving them as text/html instead of application/xhtml+xml. And note that XHMTL according to W3C *should*not* be served as text/html: http://www.w3.org/TR/xhtml-media-types/#summary
I’m considering Christian Paratschek dangerous because he advocates serving XHTML 1.1 as text/html.
Having said that, I fully agree with him on dropping support for any v4 browser and making standards compliant web pages. !BUT! I’m sticking with good old HTML 4.01 until more than 95% of my visitors can handle XHTML properly.
On my *personal* ( http://mozilla.mathiesen.info , http://webadmin.mathiesen.info ) pet project pages, I’ve allowed myself to use XHTML 1.0 served as application/xhmtl+xml which excludes visitors from using IE when visiting those sites.
And please note that all of the good coding practises that XHTML forces you to do can be done just as well completely voluntarily in HTML 4.01.
True. However, it’s not that hard to make your web pages degrade gracefully. The problem is of course that NS4/IE4 understand some CSS, ignore other parts of it and missunderstand a lot of it. A simple solution is to simply hide the CSS from older browsers. Those users will still be able to use your pages even though they might look a bit funny.
It might also be a good idea to politely indicate to such visitors that using a modern browser might make things look less ugly.
Create the webpages however you want. Put whatever content in them that you want. But please please please don’t make a 100% pure flash only webpage. I find those to be the most irritating. Some text is good, some colors are good, and some flash is good, just not all flash. Ok, I might be a bit of a html nazi here, but should the article use the ALT tag instead of the TITLE tag? Or has the ALT tag become common practice and it dosen’t matter much?
Didn’t many OSS supporters say Microsoft forced people to upgrade? I find it highly ironic that it’s laudible when Feora (Red Hat forces full upgrades) while Microsoft is tarred and feathered for trying to make Automatic Updates (for security patches and OS fixes) the default option for Windows.
The big difference is that Fedora is freely available, so the cost of upgrades is the cost of downloading. When Microsoft forces people to upgrae, it is to fatten their pockets. The motivation is different. If you have entitlements with Redhat, upgrades are free.
I’ve outlined a method of serving XHTML as text/html to IE and application/xhtml+xml to compliant browsers here – http://www.everything2.com/index.pl?node_id=1527197
Ofcourse using styles based on ID’s is bad practice. Since ID’s are used for more things than making a block of some kind of class. You’d be much better off using:
<b style=”font-family : courier; font-weight : normal;”>
<b style=”color : #cc0000; font-weight : normal;”><div class=<b style=”color : #0000cc; font-weight : normal;”>”anyclass”<b style=”color : #cc0000; font-weight : normal;”>></div>
<b style=”color : #cc0000; font-weight : normal;”><style>
.anyclass { <b style=”color : #0000cc; font-weight : normal;”>background : white; }
<b style=”color : #cc0000; font-weight : normal;”></style>
That way you can have more than one block of the same class. An ID should be a unique identifier and the whole idea of stylesheets is to recycle layout. Otherwise we’d still be using <font>-tags.
Otherwise nice simple tutorial. Hopefully we’ll get rid of most Netscape 4 hacks still floating around on the net sometime soon.
hmmm that worked better in the preview … the idea was colored html:
<div class=”anyclass”></div>
<style>
.anyclass { background : white; }
</style>
Read this faq entry to learn how to serve XHTML as text/xml to modern browsers but remaining compatible with IE
http://www.w3.org/MarkUp/2004/xhtml-faq#ie
This is comment rather negative, but I feel this article is really below the norm for OSNews features. It’s full of inaccuracies and should not have made it up. OSNews isn’t really the right forum for this kind of tutorial in the first place.
I sincerely hope that the OSNews team takes an objective view to submissions and doesn’t just post everything that gets sent in. Perhaps a better approach for this particular one would have been to introduce the concepts of standards compliance on a higher level and then provide some links to resources with proper treatments for visitors who want to explore the subject in more depth.
Well, In beginning of the last year, I was creating the BlueEyedOS website with Notepad XP, IE6, Mozilla, and NetPositive. I wasted three months only working in my spare time with HTML, CSS and JavaScript.
The result you can see here:
http://www.blueeyedos.com
Now, I’m preparing a huge update, since that it was one year old.
This article will help me a lot!
Thanks!
Michael VinÃcius de Oliveira
~ BlueEyedOS.com Webmaster ~
dude, your website looks awesome. Makes me realize I should learn newer stuff, I still do tables and HTML3/4 webpages.
Yourp age looks simpler. Awesome stuff. And all made by hand too, so I can actually understand the code* and learn from it .
*granted, it’s not because the code is made by hand that it’s automatically easy to comprehend – but rather it’s because it’s not auto-generated by say, frontpage, AND Chris has made a good job of writing it.
I think newer technologies should be used if:
a) They save bandwidth by requiring less code to render a webpage
b) They make the job of the developer significantly easier
Other than that, I’d say keep it simple – especially where eye candy is concerned. I’d rather see a site with great content in nothing but plain text than I would a gussied up, flash-infested monstrocity that has nothing of value to offer.
I don’t know what planet you guys are from, but on planet earth the latest version of IE still isn’t fully CSS capable.
“XHTML 1.1 file, this is the most recent HTML standard”
Firstly XHTML 1.1 is not HTML, although it does resemble it. XHTML is “family of current and future document types and modules that reproduce, subset, and extend HTML, reformulated in XML“.
Secondly, XHTML is only a recommendation, it is not really a standard. However a good web developer will treat it as such, however to mislead the public is questionable.
@BjarneDM, you appear to be an uninformed zealot. There is no harm serving XHTML as text/html to browsers that dont understand application/xhtml+xml. In fact when I have done so with MSIE, the page loads/works/looks perfectly – identical to the application/xhtml+xml served to Mozilla. Or as another reader mentioned, the W3C recommends a way of getting around MSIE not accepting application/xhtml+xml:
http://www.w3.org/MarkUp/2004/xhtml-faq#ie
@BjarneDM, the main reason you create a website it to serve informational content to an audience. Preventing anywhere between 95% and 50% of your target audience from viewing your website is ludicrous, especially since there is no valid reason to do so. This is definately a case of stupidity to laugh about with the other coders at work 🙂
There is no reason not to code XHTML 1.1. HTML 4 is deprecated. It will never be updated. The latest minor change was 5 years ago, the latest major release was 7 years ago. XHTML 1.0 is 5 years old, people should be using it, or even better XHTML 1.1.
One thing that would have been good in this article would have been to show how [form…][input…/][/form] isn’t allowed, and the way around it. And also how to use [a onclick href] to open documents in various target windows and frames. And how align and vertical align can be implemented using CSS instead of tag attributes. These are the big gotchas that catch out many people who are new to XHTML 1.1 IMHO.
An unusual article for OSNews, but welcomed. Writing pages by hand is the best way to go. None of this non-compliant GUI driven stuff or ASP.NET auto generated code that by default serves HTML 3.2 to any non MSIE (5?)5.5+ browser, even to the latest Mozilla browsers.
i actually asked eugenia if she wants this one for osnews because i knew it was pretty much offtopic. i would have written it anyway, because some of my friends want to learn more about html and css. she said, she wants it, so it got posted. simple as that.
also, i really find it offensive that you call my article “below osnews standard” without backing up your opinion with any kind of facts. of course, this is not very in-depth, but it also wasn’t meant to be in the first place. i will possibly write follow-ups, who knows.
i don’t mind being critizised most of the time, especially when you back it up with some arguments. but the way you do it, you are just whining. if you don’t want articles like that on osnews, go and write some yourself…
christian
well, i didn’t want to put too many things into the article. i felt that it would lose focus that way. so i pretty much left “class” intentionally out… for that special case, it is pretty much irrelevant. but i should have put “class” in. it’s really missing…
christian
You’re awfully haughty for someone who let’s php code slip through to the client.
And you shouldn’t be serving different content based on user agent string. What happens when someone writes a plugin to handle XHTML mime type in IE or people set the Firefox user agent for compatibility or MS upgrade IE.
I’m actually kinda looking forward to XHTML 2.0. To my mind XHTML 2.0 should be a vast simplification, which should make web design tools much easier to create.
Of course I’m resigned to waiting 10 years for it to appear.
As for bad web design, most bad web design exists because a lot of designers don’t really know HTML/CSS/Javascript very well.
Sending XHTML as text/html Considered Harmful
http://hixie.ch/advocacy/xhtml
Whoever posted the link to http://www.w3.org/MarkUp/2004/xhtml-faq#ie
Right after that, it gives a few special cases where documents will be treated differently as text/html and application/xml. That sets off warning bells in my head…
Hixie is a HTML guru. One of the best. Unlike the W3C, he’s coded major parts of major real-world browsers. So if he says that you shouldn’t do something, you probably shouldn’t.
Not at my work. My boss (he runs a web design company) still demands I use tables because every site we make must work in NS4.
Somewhere he has the idea that people still use NS4 more than Mozilla. He’s an IE user and will never use Mozilla in his life ever I think.
I, too, am fond of ‘low level’ control of web pages. But not too low..
For this reason, I married HTML and Lua, a dynamic scripting language. The end result ( http://www.sci.fi/~abisoft/lumikki ) is something like PHP but as a non-server side tool. Basically, it is a very powerful macro language to generate HTML pieces ‘on the fly’.
Marry that -wow, too many spouses..?
– still with ImageMagick ( http://www.imagemagick.org ) and you get full GIMP-like but programmable picture processing tools.
Lumikki can be used with or without JavaScript, PHP, CSS, or whatever extra spicies you like. Or with just bare HTML pages as I do. I hope you try it & like it.
-ak
If you want to create websites by hand, be my guest. I’ll stick to tools that enhance my productivity. Kinda like the difference between a manual typewriter and a word processor. Both will output text, but you’ll be much more productive with the word processor.
If you want to create websites by hand, be my guest. I’ll stick to tools that enhance my productivity. Kinda like the difference between a manual typewriter and a word processor. Both will output text, but you’ll be much more productive with the word processor.
The analogy doesn’t work, because the problem is that most WYSIWYG tools don’t mark up the HTML very well. You lose a lot of control as to how the final product looks, especially if you target more than one browser.
That is like telling Linus and the other kernel hackers that they should ditch their text editors and start using a point and click visual IDE.
Easier isn’t always better.
M$ does not adhere to CSS completly, it has some subset of css with still makes using CSS a pain.. man what you smokin..
The analogy doesn’t work, because the problem is that most WYSIWYG tools don’t mark up the HTML very well. You lose a lot of control as to how the final product looks, especially if you target more than one browser.
That is like telling Linus and the other kernel hackers that they should ditch their text editors and start using a point and click visual IDE.
Easier isn’t always better.
I agree that being dependent on a WYSIWYG editor to write code for you is bad. However, these can also enhance your productivity if used right i.e. use it as a shortcut, but not as a replacement for writing code.
It’s actually not that bad. Once you get to know the limitations, you shouldn’t have any big troubles compensating for them. Some “minor” flaws in the margin/padding section makes life a little harder, though… It’s of course not like IE supports CSS3 or any really fancy stuff (like Aural style sheets), but then again, there aren’t very many browsers that do. What’s really annoying is the MSHTML DOM… Hopefully WebForms 2.0 will make life good again.
http://www.blueeyedos.com
hmmmmm…. Looks an awful lot like the old Be Inc. webs ite layout.
just messing with you though.
I’m writing this becasue it’s an interesting topic and I’d just really like to hear what others think:
I’m aware of the XHTML arguments being thrown around. It’s very interesting how all the web standards advocates jumped on using it and wrote books on it – pushed it to web designers – and now this issue with not serving it as HTML. I don’t even know if many people will need the XML benefits it can provide. It just seems anyway you choose to develop is in preparation for the future that may or may not come to be. And here I took the word “Transitional” at face value ; ) As far as explaining don’t serve XHTML as HTML “because it’s bad” just isn’t a decent enough argument. This really needs to be expained with real world examples. I mean, what is “bad” – will your house blow up? Is “bad” just that it’s not intended to be used that way?
Just so you know, I really am interested in a explanation – It’s been a bit of a mystery.
No matter how you play it. The W3C is making recommendations to browser developers – not writing law. The fact is, most browsers have gone on their own picking what is convenient or interesting to their agenda. IE once commendable in this department (while it was still facing competition) has just been miserable and slow to bring any useful updates. Their stranglehold on the market has made these kinds of standards – and some very cool CSS features – linger mostly underused or in the monority like project sites or blogs where there is not a commercial necessity to support certain browsers.
It’s amazing how many corporate intranet-type sites will still use proprietary Microsoft tags within their sites – why? because they know that the whole company is standardized on the IE browser. And, the important thing – some of these tags make their development easier (shudder).
Try telling your boss or client that you won’t support a certain browser because you have some strange moral objection to it. yeah right! You can do that, but its a good way to put yourself out of work. For the most part I design with seperation of presentation (CSS) and content and well-formed HTML, but if a client wants tables-based layouts I won’t complain. The best I can do in those situations is try to bridge the gap a bit – use tables for the basic layout structure and CSS for as much of the presentation as possible.
The same kind of situation goes for browsers. Very few companies will code so strictly to the standards recommendations that malformed HTML will simply not render. Why? because it means so little to the end user what the standards are no company wants the user saying “This browser sucks!” It’s unfortunate, but it is a stituation somewhere between a rock and a hard place. You can still leave closing tags off and fill in all sorts of depracated font and presentational tags and your site will still render – usually perfectly.
As for WYSIWYG web design programs, I started in web design before they really existed and then I used them to help speed development. What I’ve found is through the years I’ve used them less and less – more for when I need to quickly visulaize something like a form or table layout, but even that is becoming easeir to just code in a text editor. It just comes with experience.
The only time I really care about WYSIWYG editors one way or the other is when I’me working with a team of people. Handing them that stew of tags that a lot of editors produce just seems embarrasing and unprofessional to me. While you can usually go through and decipher it – it certainly can take longer. Time is money after all.
The way I see it. If you’re a good web design citizen and believe in standards, make every attempt to sell it and push it, but it won’t always be your decision to make.
Personally, I remain optomistic and excited about web design and where it is headed.
Not a great article. Why do so many self-styled designers have to start off by saying that only babies use WYSIWYG tools? Real web developers write programs to generate HTML; they don’t write HTML by hand.
Coding by hand is sometimes necessary and often preferable. The only way to learn HTML and CSS in-depth is to get into the code. But if you’re going to make a case for hand-coding, at least make a good case.
> Dreamweaver MX 2004 actually produces far better code
> than his predecessors, but you simply can’t compare
> designing with a WYSIWYG-tool to writing code by hand.
Why can’t you compare them? I’ve seen a lot more crappy hand-written code than bad Dreamweaver or FP code. Bad WYSIWYG code is simply mediocre, but bad hand coding is much worse, because Dreamweaver and FrontPage know more about HMTL and CSS than a bad web page coder. You have to deliberately break a Dreamweaver table, for example, or hand-edit to get invalid CSS. Your text editor won’t stop you from making even the most obvious blunders.
> The latter gives you much more control over the design
> of your page.
Not true at all. Unless your WYSIWYG tool is missing HTML or CSS features you have exactly the same control over the design. And what modern WYSIWYG tool doesn’t support round-trip hand-coding anyway? Dreamweaver has more HTML and CSS expertise built into the autocomplete feature than 90% of hand-coders will ever learn.
> Basically, you know, at any time of the design process
> what you have done, what you are doing and what the
> consequences of your actions are. “Debugging” your website
> is a lot easier that way.
WYSIWYG tools are by definition showing you what your page looks like at all times. And you can preview your page in a real browser just as fast from Dreamweaver as you can from your text editor. Debugging is a lot easier when the WYSIWYG tool highlights HTML and CSS errors, too. And nothing prevents you from using HTMLTidy or other validators on Dreamweaver code; in fact some WYSIWYG tools come with validators built-in.
> The code you produce is a lot smaller, thus more
> efficient.
Not necessarily. A really competent HTML & CSS coder can do better than a WYSIWYG tool, but not by much anymore. Most people just trying to build a site will do much worse on their own, and won’t get the advantage of seeing how the WYSIWYG tool does things.
> All webdesigners out there will have to deal with HTML
> and CSS at some time. So it’s better if you are
> prepared!
True if you want to be a web designer. But not everyone putting up a web site aspires to be a designer — more often they have something better to do and just want a site that works in the major browsers.
> Also, Dreamweaver costs money and may not exist for
> your platform.
That’s true. Mozilla has a built-in WYSIWYG designer, free. It’s not as feature-rich as Dreamweaver or FrontPage or GoLive but it’s not bad, either. And there are other decent free WYSIWYG tools.
IE is the only one that create headache to me when dealing with CSS. Even IE6 with SP2. Simple div with position & right set will not expand beyond its content’s width. So div’s width must be set. But then we can’t have fixed width for right side panel. Firefox & Opera show it correctly.
Workaround is to use floating div with margin right set.
I hope they release IE7 soon with greater CSS compatibility.
I haven’t even read more that a few posts, but I can say this…
First: If someone (i.e. billdo) can make enough cash to be as rich as he is.. more power to him him. NO!! I’m not a widows/linux/<insert OS here> freak, but damn get over it.
I prefer what suits my needs at the moment. If I can make a few bucks using windows at one moment then make a few more because I can use linux the next the right on. Right now I am making decent cash because I can use windows and migrate otheres machines.. in a week or two I might be making the same or better because I understand and can use linux.. who knows. Get real people, it all comes down to being able to pay the bills… Does the comp at Jiffy Lube use Windows or Linux.. Does the Bank One a mile away use windows or linux.. oh well I made enough to pay the bills and have enough to buy a new ps2 game RIGHT ON!!
Anyway.. I’m glad we can start making web pages all can enjoy.
I code pages for a living.
I do a 50-50 mix of hand coding and Dreamweaver. If it’s a quick fix or a “nuts and bolts” page, text html editor all the way. I like coffee cup HTML edtior on XP — yeah, I know that I can use notepad, but I rely a lot on color coded tags and the auto complete.
At home I use TACO HTML on my mac. It’s got tag color coding, but it’s a beta so it’s got some glitches.
Despite the fact that I don’t like to use the CLI to interact with my computer, I like the sheer control provided by hand-coding. (Mainly because if I bork up a tag, then it’s quick and simple fix. Not so at the CLI)
On the other hand, you couldn’t pay me enough to hand code a page like this:
http://www.library.unlv.edu/collections/micro/newsshrt.html
It’s Dreamweaver and the table tool all the frelling way.
I think that learning (x)html should be done without the use of WYISWYG editors. Once you know how to do it, then a WYISWYG editor can help you to be more productive. Think of it as just an editor with the ability to view changes in real time, and the ability to select portions of the code by selecting elements visually. Want to apply changes to a whole column in a table? A WYSIWYG editor enables you to select the relevant td’s and make the changes in a few seconds.
Need to build a complex form? Just knock one up quickly by using the visual tools, then tweak the code. Need to apply a css class to multiple elements? Select them visually and apply the class from a drop down list. It’s the ability to select multiple elements and applying changes to all of them that makes WYISWYG editors convenient. Other than that, the way in which you build a page with a WYISWYG editor is the same as the way you do with a non-WYISWYG editor.
On the other hand, you couldn’t pay me enough to hand code a page like this:
http://www.library.unlv.edu/collections/micro/newsshrt.html
It’s Dreamweaver and the table tool all the frelling way.
I’m really surprised if they handcoded that, or even did it statically in dreamweaver or some other WYSIWYG editor. It’s really simple to tell Apache to assign the .html extension to php, jsp, asp, etc…it looks like a static HTML page, but it’s dynamically generated, which means the table itself was built on the fly. I could be wrong, but i fail to see why anyone would do this on a static basis anyway.
If you want a static, dumb site with a few glitzy images, a couple of flash in the pan buzzword de jour garbage inclusions, then by all means, use one of the many code spewing, mangling, incredibly impossible to maintain, applications.
If you want a real web site, that actually does things like allow credit card transactions, aligns inventory and costing data systems to client requests – you know – actually does something for your business, then get real – hire a programmer. There are many who will contract for a decent rate of exchange.
If it’s for your business, you get what you pay for, and if you don’t want to pay for a properly functional web site, then why bother with one in the first place. A static web site generated by these useless applications are no better than Tiny Timmie’s grade 2 home page.
What I see is many supposed web hosting sites, who use these applications to give their suckers^H^H^H^H^Hclients a mediocre static electronic brochure. IMO, these people are not getting anything near the service they should expect for what they are paying for it.
A properly designed and implemented site can be hosted at the business location, maintained with local admin scripts allowing full content control for the business, without waiting for their ‘host’ to make changes (after paying for another crappy static page).
Many of these applications are optimized to 800×600 resolution. If you view in a browser on a higher resolution, the pages are blank on the right edge. A properly designed page will wrap to the browsers resolution width. Tables can be sized based on screen width percentage rather than 22 <td size=1> entries at various positions.
Code generators are for sissies? NO, they are for useless wannabees who haven’t a clue what they are doing, and need someone to hold their hand and say good boy/girl, when you move an image onto the page. In other words, your normal MS trained, Pavlovian PHB.
You want to do web work, then get into the guts of the code, learn how to make it smart, fast, reliable and interoperable. Learn how to code HTML, CSS, Javascript, PHP , Perl and XML by hand. Learn how to authenticate users, apply key encryption, access data systems, and parse incoming data for malicious content.
When you have figured that out, then you will know what you are doing. Until then, leave the kindergarden pages where they belong – pasted to the fridge door with a magnet.
In defense of these applications, I don’t expect artists to be code geniuses, so they usually submit pages to me for encoding that they have designed in these applications. I take the submitted work, and clean it up, and implement it reliably in HTML or PHP. Many clients are better artists than me (hell a brain damaged monkey with broken fingers is a better artist than me), so these applications allow them to show me what they want without having to go through the grief of actually making it work.
@Robert:
I do know how to do that – I’ve just chosen not to on my own sites. (also – see further down in this answer)
@Mike:
I’ve chosen to serve xhtml as application/xhtml+xml on my own pages because I don’t care about users using IE on those sites. One of the sites is for advanced users of Mozilla and the other for Mac people where IE can be considered for a dead and gone product since Safari entered the picture – and Safari can handle my sites just fine.
As to being un-informed, please read the article that Hixie has written. And take a look at http://www.w3.org/TR/xhtml1/#guidelines about the problems you get into when trying to accomodate both text/html and application/xhmtl+xml
The w3c trick for IE makes IE accept application/xml which is not the same as application/xhtml+xml
And please see your own reference a little bit further down: http://www.w3.org/MarkUp/2004/xhtml-faq#mime11
@Matt:
If I let PHP code slip through that’s definitely an error on my part !!! I’ve just checked my sites, and off-hand I can’t find any pages where this is happening. Please send me the URL of the page where this error occurs.
Mozilla/Firefox with a user-agent of IE will get my pages, as they are still sending information in the headers that they are accepting application/xhtml+xml.
I don’t look for specific browsers but for capabilities of the browsers:
<?php
if ( stristr($_SERVER[“HTTP_USER_AGENT”],”Mozilla/4.0″)
&& !stristr($_SERVER[“HTTP_ACCEPT”],”application/xhtml+xml”) )
{ header(“Location: http://mozilla.mathiesen.info/sorry.html“); /* Redirect browser */ }
?>
XHTML aware browsers are sending ‘Mozilla/5.0’ so a plugin that modifies IE to send this will get my pages. This is a modifed idea of a PHP script originally found here: http://www.xml.com/lpt/a/2003/03/19/dive-into-xml.html
I have a philosophy. I allways use the lowest technical solution that can do the job.
CSS might be good to use for things you can’t do in any other way, but there are issues with IE and CSS still, so I just use that when I absolutely need to and I test it with all major browsers before I publish it.
Javascript, I think, should not be used without also coding a non-javascript-alternative.
I am currently building a new site for myself ( http://sandbox.nalle.no/ ) . There I’m using tables – I don’t see anything wrong in that, but no client based technology. Tools: jed – I like the editor and it can color code PHP.
I stopped using WYSIWYG-editors years ago. It’s the details that make the difference. Like the difference in putting the <HR> before or after the <BR>. There is a difference in most browsers, but WYSIWYG-editors don’t allways destinct between them, so when you’ve got it wrong, you’ll have to hand code anyway. I also find that if I use WYSIWYG to create the design, but hand-code the function of the page, the design code will be rewritten anyway, since either the code allready in the script don’t fit with the fuctionallity code, or it doesn’t fit with my way of thinking. That way I don’t save much time anyway.
WYSIWYG-editors are, if you ask me, best for throwing together quick pages to show as an example to the customer. Then I handcode the actual page.
In defense of these applications, I don’t expect artists to be code geniuses, so they usually submit pages to me for encoding that they have designed in these applications. I take the submitted work, and clean it up, and implement it reliably in HTML or PHP. Many clients are better artists than me (hell a brain damaged monkey with broken fingers is a better artist than me), so these applications allow them to show me what they want without having to go through the grief of actually making it work.
Spot on. In the end both designer and developer have to work together though. I wouldn’t necessarily want a designer to be a code guru, just as long as they are able to break their design down into proper html/css. I’d rather have a designer who’s great at design and a developer who’s great at coding.
nice response, but i want to make something clear: i never said that WYSIWYG-tools are for “babies” and the “real men code by hand”.
i just wanted to write a small article about how i am doing it. not more, not less.
@everyone who complained about the text/html-thing. sorry, basically i just didn’t know. but really, i don’t think that it matters that much…
christian
I’ve read 80% of the posts in this thread and I still see nobody mentioning Accessibility, WAI or RNIB. I know for one that these play a huge part in my development role. We aim for AA 90% of the time and AAA depending on the target audience and the client’s requirements. Most of the development work I do is for FTSE100 companies and you just can’t be too careful
Most development tools don’t account for any of the above issues, so I believe handcoding is still the way forward for any designer/developer.
Also, theres a difference between someone who can handcode and someone who actually know’s what they’re doing. Any monkey can code HTML
dos MSIE render styl=”border: black dotted 1px” correctly?
e.g.
<div style=”border: gray dotted 1px”>border: black dotted 1px</div>
<p>
<div style=”border: gray dashed 1px”>border: black dashed 1px</div>
<p>
<div style=”border: gray solid 1px”>border: solid dashed 1px</div>
no. ms ie 6 renders “dotted” as “dashed”. if you are refering to my site – well, i knew that, i don’t think it’s a big problem… i also used position:fixed, so the header and the menu stay in place when you scroll down one of the articles. this also doesn’t work in ie6, but i didn’t really care. ie-users can certainly view my site, they just don’t get the full potential…
christian
so your site is not “optimized for Internet Exploder” 🙂
btw.: Did one mention http://selfhtml.org/ yet?
i also used position:fixed, so the header and the menu stay in place when you scroll down one of the articles. this also doesn’t work in ie6, but i didn’t really care. ie-users can certainly view my site, they just don’t get the full potential…
Well, I wasn’t going to mention it, but since you did… I don’t like gimick. Why did you want to prevent the header/menu from scrolling anyway? It’s like using frames, except that it’s made worse by the scroll bar that actually extends to the top of the browser window (people would expect the header to move). The fixed header is taking up screen real estate that can’t be overcome by scrolling down.
Why don’t ppl use UTF-8 like they should ?
Btw, everyone should write HTML in (X)Emacs, and of course make sure it passes teh W3 validator =)
Jamie Zawinski, famous Netscape hacker, wrote a nice short comment:
http://www.jwz.org/doc/markup.html
So guess we are really surrendering to the we want pixel control layout guys, sigh.
Why then not drop HTML and use flash or PDF?
Regards,
Marc
Yes! It’s the old Be’s website with more content in you code. But the work is mine, not?
And I wrote that in HTML, CSS and JavaScript, by my hands
Thanks!
Michael VinÃcius de Oliveira
~ BlueEyedOS.com Webmaster ~
text/html v. application/xhtml+xml:
That’s the problem – most people don’t know that there’s a distinction between the browsers and the mime-types. If you just serve your pages as text/html you are actually just serving HTML 4.01 with some fancy XHMTL markup in the mix. This will of course not give you any problems !UNTIL! you try to switch to the correct mime-type, and your pages break horribly (cf. Hixie). The biggest problems occurs when you introduce javascript into the mix: some things are plain not allowed under XHTML, some things work differently, the available DOM techniques are different (cf. w3c). Also, if you’ve gotten any XML-prolog before the DTD-declaration IE6 breaks horribly and: doesn’t see the DTD at all, behaves like IE5 inclusive of the CSS box model error.
And it has to be considered a serious error to serve XHTML 1.1 as text/html : XHTML 1.1 is pure XML, and only intended to be XML. It cannot reliably be sent to legacy browsers.
Try these links:
http://dturunners.mathiesen.info/Deitel/test1.xhtml
http://dturunners.mathiesen.info/Deitel/test1.html
http://dturunners.mathiesen.info/Deitel/test2.html
in IE5 and IE6 and then try any standards compliant browser.
i did my templates and css with vi, just hand editing. no frontpage, dreamweaver… check it out http://mkpaul.freeshell.org
Yes. I am a big fan of CSS. I tend to avoid CSS positioning because of unreliable behaviour across implementations. I must admit, I still use tables for layout…
The neat thing is you can write a page like with the simplest of stuff: H1/2/3, A, P, IMG and nothing much else, so it will work fine in old and text browsers (might not be so pretty). Then, apply a style, and it can look really great.
I haven’t touched a WYSIWYG HTML editor for years, and I’ll never go back. Content and structure override look and feel 😉
Writing a multi browser complaint site now days is imperative. Most people are ignorant and just don’t care so the ignore compliances and just develop for IE. I like the way this article is going in pushing people to be more wiser and informed when coding their sites.
I do web application development for my school I create mainly data driven web applications for use by our OITS department. My department follows compliance to the T but you would be amassed at how much of the school systems just don’t care. I remember hearing in school that government institutions had to have a certain level of complacency. But if you test many of the *.edu sites they fail miserably.
The site my department has which is http://thehub.clayton.edu , and my personal site http://www.brianhursey.com both follow complacency standards. Both are database driven using MySQL and a hand coded PHP/XHTML back end.
>>>This will of course not give you any problems !UNTIL! you try to switch to the correct mime-type, and your pages break horribly (cf. Hixie).
Precisely.
The problem occurs when you switch to full application/xhtml+xml in the future. You get blank pages because the majority of your pages don’t validate correctly under application/xhtml+xml. Your carefully constructed CSS behaves differently in xthml. Your carefully constrcuted DOM scripts behave differently in xhtml.
<<I’m really surprised if they handcoded that, or even did it statically in dreamweaver or some other WYSIWYG editor. It’s really simple to tell Apache to assign the .html extension to php, jsp, asp, etc…it looks like a static HTML page, but it’s dynamically generated, which means the table itself was built on the fly. I could be wrong, but i fail to see why anyone would do this on a static basis anyway.>
Which is quicker and cheaper:
(a) hiring somebody with oracle or mySQL skills to build a database with under 100 entries and then have that person code a page?
or
(b) hiring somebody with HTML skills to copy and paste from a word file into tables?
Which is quicker and cheaper:
(a) hiring somebody with oracle or mySQL skills to convert a 800+ entry Access database into a dynamically generated, searchable front end?
or
(b) hiring somebody to copy and paste 800+ entries into a series of tables over a series of pages?
I’ve tried a lot of different webpage creators. In the beginning, when using those on the Amiga, the only one I found that I thought was worth a damn was from this guy in Italy, and while it had html features that were already added by the time I got to it, it was primarily a text editor. ProgED.
Since using the PC, I’ve used FrontPage Express–the cheapy…okay, free…version that I think must now be long extinct(?)
It lets me go into view and change the html directly, even beyond the simple WYSIWYG layout machine it presents.
My website, The City of EyeAm (created mostly with FrontPage Express): http://s87767106.onlinehome.us
Add to a very rudimentary, though sufficient webpage creator, a variety of simple scripts (DHTML, Flash, gif animations, Java/Javascript/JavaApplets, CSS, Perl…) and something decent can be made.
–EyeAm
http://s87767106.onlinehome.us
I suggest you take a look at Nvu – http://nvu.com
It’s an open-source WYSIWYG HTML editor based on Mozilla.
I bet it’s much better than FP Express
Actually if you think about it, you hire someone at $30 an hour to create this table by copying and pasting a table from word, it won’t work in many browsers, it won’t conform to standards and it will look like spaghetti code.
And when it changes, you need to hire someone to do it again…and again and again…
While paying someone $60 an hour for 2-3 hours to do something so simple in PHP, ASP, etc…which will read from the database and generate it on the fly. For an extra 3-4 hours you get a nice administration page to actually enter data.
so $30 an hour for as long as you want that page updated or $300-$400 for one time…and it will rarely need updating providing your data remains the same.
The second one is cheaper in the long run…
actually whenever you deal with repetitive tasks, automation is always the better solution. One less person to have to contact to work on it everytime.
I still fail to see why anyone would do this on a static, update everytime procedure.
I don’t understand what’s wrong with using ID tags for CSS positioning…I’ve seen comments that basically state: You lose the point of css because it’s meant to be reusable…
well i counter with: we use HTML right now for something that it was never meant to be, we use tables for something they were never meant for (layout and positioning of images, maps, formatting). HTML was never meant to be used for page layout, the web wasn’t designed to be an interactive magazine…
But we still do it. Using CSS this way actually removes the content from the layout, which is good. It’s simpler to work on, it’s cleaner….god forbid I had to code C++ applications without included header files…my code would instantly jump to a hundred thousand lines extra…
CSS positioning, tableless layout is a step, a good step. Yes older browsers don’t work, but i can’t use newer hardware on my windows 95 box because drivers don’t exist. I upgraded. It’s time people upgraded to get rid of the browsers that are depricated, IE 4, NS 4, IE 5…
Come to think about it, most companies shouldn’t really care about IE4, etc…because chances are if those people can’t spend $200 on a new computer, they aren’t a targetted market for most companies. I try to push this to my employer, should we actually spend money breaking standards to support a group of people that won’t spend $200 on a new computer in order to sell them something that is $300+…?
Is it just me, or is it kinda stupid that the content type makes that big of a difference? I mean, there is such a thing as a doctype tag, which it would be darn nice if it used instead. Especially since you then don’t have to worry about file extensions either, if you for instance slowly migrate from one to the other, without wanting to rename files.
BjarneDM, I guess I have to respectfully disagree.
Similar to you, I don’t look for specific browsers but for capabilities of the browsers:
if (isset($_SERVER[‘HTTP_ACCEPT’])):
//use stristr because stripos is less often available
if (stristr($_SERVER[‘HTTP_ACCEPT’], ‘application/xhtml+xml’)):
header(‘Content-type: application/xhtml+xml’);
else:
header(‘Content-type: text/html’);
endif;
else:
header(‘Content-type: text/html’);
endif;
Whilst serving XHTML as text/html is not the correct/intended way to serve XHTML to MSIE, it serves the purposes for me.
* MSIE users see exactly the same as what Mozilla users see (almost down to the pixel)
* the page functionality (navigation, JavaScript validation, etc.) is identical.
No “harm” is caused doing it this way, neither to MSIE/Windows, the user, the user experience or the server.
My site is about Fedora, and OSS to a lesser extent. Yet 39% of hits to my site are by MSIE 5/6 browsers (compared to Gecko browsers at 37%, Safari @ 4% and Opera at 1.8%). I am happy my site is written in XHTML, and I am happy to accomodate browsers that are not modern enough to understand application/xhtml+xml.
It is a tiny piece of PHP code, a very minor inconvenience. But accessibility is an important feature of any site IMHO.
To change the topic briefly, I quite like Dreamweaver MX 2004’s syntax colouring and the way it shows the parameters to a function when I type “function(“. However, it really irritates me how it changes onclick to onClick, and the same for onblur, onmouseover, onmouseout, etc when I write XHTML. The preferences are set to use lowercase tags and lowercase attributes, yet this still occurs. I am thinking strongly about uninstalling it.
>>>No “harm” is caused doing it this way, neither to MSIE/Windows, the user, the user experience or the server.
The problem is that the “harm” comes later to the web site designers. Unless you are like Ian Hickson, Eric Meyer or Jeffrey Zeldman — who knows how all these little things behave differently under html and under xhtml — then the transition into the real xhtml+xml world is going to be painful.
Ian Hickson was so mad at this application/xhtml+xml mess that he and a bunch of other interested web designers have formed the “Web Hypertext Application Technology Working Group” outside w3c.org and is working on the specs for Web Applications 1.0 (aka HTML 5.0). When the specs are more finished — they will present it to w3c.org.
http://www.whatwg.org/specs/web-apps/current-work/
get creating…
The problem is that the “harm” comes later to the web site designers. Unless you are like Ian Hickson, Eric Meyer or Jeffrey Zeldman — who knows how all these little things behave differently under html and under xhtml — then the transition into the real xhtml+xml world is going to be painful.
I do not understand what you mean? (What are all these little things?) Maybe the “harm” you speak of only concerns the use of certain tags/elements, which I do not use?
I have a site that is valid XHTML. The only concievable change needed in the future will be to remove a few lines of PHP from the top of one file (the code that sends the text/html header to MSIE)… at a time when 95%+ of user agents accept xhtml+xml. The whole site will keep working. It will still validate. It will still look/operate the same in MSIE as it does in Mozilla.
Sending XHTML with the header text/html to MSIE allows me to have an XHTML site that works in all browsers. Because Mozilla accepts xhtml+xml, if my page doesn’t validate, I get a yellow screen with a red error message. Neato. Everything works now. Everything will work in the future. I’m failing to see a problem?
Sending XHTML with the header text/html to MSIE allows me to have an XHTML site that works in all browsers. Because Mozilla accepts xhtml+xml, if my page doesn’t validate, I get a yellow screen with a red error message. Neato. Everything works now. Everything will work in the future. I’m failing to see a problem?
That’s sort of what I’m trying to get out of those who say that it’s harmful, but don’t really say why. First of all, why the big secret ? If this is such an issue that everyone needs to know about it why won’t someone just give a quick laymen’s explanation of the problem. Why be so vague?
From what I’ve read on the subject, there are certainly different, more strict ways that a standards compliant browser that understands XML will treat XHTML markup served as XML. Things like how JavaScript can be handled and how CSS can be applied. I haven’t personally tried serving as XML yet, so I can’t really comment on what happens.
What I would submit to those saying it’s bad to serve XHTML as HTML, please, just take a moment and explain what will go wrong when the switch is made.
It’s amost as if these people think that some grand WWW administrator will flick a switch and make people conform strictly to serving XML documents on the web and everyone will be left scrambling to fix whatever errors arise. Point being, there is time to learn about this and slowly migrate to the new ideas.
If anyone has a decent explanation here, I’d really love to know. I mean that in all sincerity.
1) In XHTML no tag has special status, thus you can (and should) apply a css style to the <html> tag. This style of course doesn’t work when interpreted as HTML
2) Using html comments (<!– –>) inside <script> and <style> is potentially *very* dangerous as the browser is allowed to ignore what’s between the html comment tags anywhere when served as application/xhtml+xml. That’s what leads to those convoluted nested comments that hixie is complaining about
3) Under XHTML you need to use the XML <![CDATA[ ]]> inside embedded <style> and <script> to exclude the styles and scripts from being parsed. Under HTML embedded <style> and <script> just aren’t parsed. The problems arise when you use eg ‘>’ (seen as a premature closing tag) and ‘&’ (seen as the start of an entity) inside these tags under XHTML. And some browsers (I can’t remember which off hand) completely choke when getting raw <![CDATA[ ]]>. That’s why you usually see it nested inside another comment tag to protect text/html browsers from themselves. Again, see hixie
4) Under XHTML the <meta http-equiv=”content-type”> ought not to be there. If you need another content-type than utf8 you’ll have to declare it in an <xml> declaration before the document type declaration or send it as a part of the http headers. Unfortunately, including a xml-declaration at the start of a XHTML document triggers a bug in IE6 making IE6 completely ignore the document type declaration and enter IE5 quirks mode inclusive of the IE5 erroneous box model (see my test links in a previous post)
5) Strictly, using named entities (like å) isn’t allowed under XHTML without specifically including this functionality. Mozilla (erroneously) allows you to do it, but the last time I checked (just now under Mac OS X 10.3.6) Safari didn’t recognise named entities when receiving XHTML served as application/xhtml+xml. You have to use numbered entities instead (like å)
6) The name attribute has been depreceated in XHTML 1.0 strict and you must use id instead. Using <a id=”link”> doesn’t work in some browsers when you try to reference it in an URL
7) document.write isn’t allowed in javascripts when your pages are served as application/xhtml+xml. You’ll have to use the w3c DOM methods for inserting instead.
See http://www.w3.org/TR/xhtml1/#guidelines for all of the troubles you can get into when you try to accomodate both text/html and application/xhtml+xml.
Because of all of these problems and differences, my advise is to stay with HTML 4.01 if you need to serve your pages as text/html. And as stated previously: all of the nice coding practises that XHTML forces upon you can be done voluntarily under HTML 4.01.
Look, the important thing is !NOT! to use valid XHTML. The important this is using valid markup as such and include a document type declaration. And if you include a HTML 4.01 doctype declaration and your pages validates as HTML 4.01 everybody ought to be happy – including zealots like me 😉
@Mike:
Your PHP script will serve you pages as text/html to Safari. Safari uses : _SERVER[“HTTP_ACCEPT”] = */* . That’s the reason why I primarily check for Mozilla/5.0 and use the http-accept as a secondary check for Mozilla/4.0 browsers (or Opera) that might be able to recognise application/xhtml+xml
“Come to think about it, most companies shouldn’t really care about IE4, etc…because chances are if those people can’t spend $200 on a new computer, they aren’t a targetted market for most companies. I try to push this to my employer, should we actually spend money breaking standards to support a group of people that won’t spend $200 on a new computer in order to sell them something that is $300+…?”
It’s sad that some people here think that computers are the be all and end all of life. To some people a new computer is way down their list of priorities in life. Why target them? Because maybe they’ll spend thousands on a product when it’s something they’re interested in. I don’t really give much of an ass about computers even though I’m a full time developer. It’s my day job, not my life, so I’ll spend thousands on a holiday or a new bike etc. but rarely on a computer. Should I be ignored by business? You should get out more in the real world mate.
Great – so layout tables are out… But they’re not being replaced with anything with equivalent flexibility and ease-of-use, but we’re continuing with a flawed and over-complicated sysetm of DIVs.
Instead of making tables accessible, accessibility ‘experts’ are taking down a route where web-pages become fixed-width due to the inability of DIVs to handle variable space properly.
I’ve heard a 3 column layout – with two fixed outer columns and variable inner column – described as a “holy grail” for CSS layout. This is absurd when a beginner can create such a layout in a minute using tables and it will work across all browsers.
Yes, you can re-order DIVs visually so that they are read by screen-readers in the correct order. But isn’t this the opposite of how we should be approaching it?
It is much easier to say to a screen-reader “read this, then read this, then read this” than it is to say to a graphical browser – move this up 200 pixels and to the left of this element. The people that benefit are not blind or partially sighted users, who like everybody shouldn’t care about the actual implementation, but the makers of screen-readers and braille outputers that don’t have to update their software to incorporate a simple read-order attribute.
As I’ve said, DIVs are no good at variable with. If you say the column widths are 10%, 78%, 10% then that 2% gap expands with everything else.
If we’re going to have a fixed-width web then we might as well be designing our pages in Quark. Is it a coincidence that most modern sites are fixed-width? I think it’s a shame we’re losing that aspect of the web. Perhaps I should expand this into an article, because I’m not reading this stuff anywhere.
Well said, Mr. EyeAm.
Yes, I use FPE for e.g. photo albums of pictures with text captions, linked in sequence and to a contents page. For my needs, the vintage ’95 wibbly wobbly web is fine. (I do get so annoyed by links that fail!)
I also save electronic press cuttings from news sources. Use FPE to remove all the yellow blobs (unrecognised tags) and save a simple basic text with bold, italic, and pictures.
1) In XHTML no tag has special status, thus you can (and should) apply a css style to the <html> tag. This style of course doesn’t work when interpreted as HTML
I use css all time so I don’t see the problem
2) Using html comments (<!– –>) inside <script> and <style> is potentially *very* dangerous as the browser is allowed to ignore what’s between the html comment tags anywhere when served as application/xhtml+xml. That’s what leads to those convoluted nested comments that hixie is complaining about
Therefore it is imperative to use (<!– –>) as it was meant, comment.
3) Under XHTML you need to use the XML <![CDATA[ ]]> inside embedded <style> and <script> to exclude the styles and scripts from being parsed. Under HTML embedded <style> and <script> just aren’t parsed. The problems arise when you use eg ‘>’ (seen as a premature closing tag) and ‘&’ (seen as the start of an entity) inside these tags under XHTML. And some browsers (I can’t remember which off hand) completely choke when getting raw <![CDATA[ ]]>. That’s why you usually see it nested inside another comment tag to protect text/html browsers from themselves. Again, see hixie
Hence the reason to avoid using <style> tag at all cost. I haven’t used <script> yet for either javascript. However, I am only use them to call an external file to ease the readability and flexibility.
4) Under XHTML the <meta http-equiv=”content-type”> ought not to be there. If you need another content-type than utf8 you’ll have to declare it in an <xml> declaration before the document type declaration or send it as a part of the http headers. Unfortunately, including a xml-declaration at the start of a XHTML document triggers a bug in IE6 making IE6 completely ignore the document type declaration and enter IE5 quirks mode inclusive of the IE5 erroneous box model (see my test links in a previous post)
I haven’t encountered that problem on either IE5 and IE6.
6) The name attribute has been depreceated in XHTML 1.0 strict and you must use id instead. Using <a id=”link”> doesn’t work in some browsers when you try to reference it in an URL
Care to name these browsers?
7) document.write isn’t allowed in javascripts when your pages are served as application/xhtml+xml. You’ll have to use the w3c DOM methods for inserting instead.
I haven’t used javascript on my website as my goal is the minimal use of that script. It is replaced by php.
Because of all of these problems and differences, my advise is to stay with HTML 4.01 if you need to serve your pages as text/html. And as stated previously: all of the nice coding practises that XHTML forces upon you can be done voluntarily under HTML 4.01.
Look, the important thing is !NOT! to use valid XHTML. The important this is using valid markup as such and include a document type declaration. And if you include a HTML 4.01 doctype declaration and your pages validates as HTML 4.01 everybody ought to be happy – including zealots like me 😉
Sorry to disappointed you, I already use XHTML 1.1. Because I know what I am doing, I often test my website on different browsers. The small price to pay are the incompatibilty with some old browser. However, browser like Firefox can be downloaded for free so that will be no big deal. It is about the way you write the xhtml.
That you haven’t encountered one of the problems I mention doesn’t mean that the problem isn’t there. They are all well know and well documented by the links previously posted.
Have you tried the test-links to my homepage in my previous post in IE6 ? in IE5 ? The box-model problem is documented here in gory detail: http://www.positioniseverything.net/articles/box-model.html
Have you accessed the information in the w3c links previously posted … or the link to hixie ?
Sorry to disappointed you, I already use XHTML 1.1. which it according to w3c is an error to serve as text/html.
>>>I have a site that is valid XHTML. The only concievable change needed in the future will be to remove a few lines of PHP from the top of one file (the code that sends the text/html header to MSIE)… at a time when 95%+ of user agents accept xhtml+xml. The whole site will keep working. It will still validate. It will still look/operate the same in MSIE as it does in Mozilla.
@Mike
If you have a validated xhtml 1.1 website that is served as text/html, by its definition this can’t happen. It’s either that you validated your code and then change the MIME setting (which defeats the validation process) or that the validation software ignores the MIME setting (which is a bug in the validation software).
>>>Sorry to disappointed you, I already use XHTML 1.1. Because I know what I am doing, I often test my website on different browsers. The small price to pay are the incompatibilty with some old browser. However, browser like Firefox can be downloaded for free so that will be no big deal. It is about the way you write the xhtml.
@Finalzone
By its definition, xhtml 1.1 can’t be text/html. And anything that is served as text/html (even if it’s written in xhtml format) is treated as tag soup by the UA.
I’m not asking you to spend thousands on a computer, you can get a really decent comp now for $200+ by building it yourself using pricewatch, all i’m asking is that those who are using win95 and win98 stop…
they are not supported, you’re potentially polluting the internet with viruses, your system is probably riddled with spyware and other malware. I mean come on, use a little sense. If you don’t care about the inconvenience you are causing others, get the hell off the net, because you’re really not wanted anymore.
@Mike
If you have a validated xhtml 1.1 website that is served as text/html, by its definition this can’t happen. It’s either that you validated your code and then change the MIME setting (which defeats the validation process) or that the validation software ignores the MIME setting (which is a bug in the validation software).
Read what he said – it’s valid XHTML, delivered as application/xml+xhtml to anything that supports that. That’s why it passes validation as XHTML, since presumably the validator understands the correct MIME type. It’s just that IE gets text/html as a workaround for it’s inability to read the correct type.