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.
Post a Comment
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 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.
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]<b style="color : #0000cc; font-weight : normal;">"anyclass"[/b]<b style="color : #cc0000; font-weight : normal;">></div>[/b]
<b style="color : #cc0000; font-weight : normal;"><style>[/b]
.anyclass { <b style="color : #0000cc; font-weight : normal;">background : white;[/b] }
<b style="color : #cc0000; font-weight : normal;"></style>[/b]
[/b]
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 800x600 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/
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 de