02-07-2005, 10:38 PM
My company is currently seeking freelance/contract help for a website we are creating using xhtml & css. We will build the interface design in Photoshop and provide all graphic elements -- we need someone to write the pages in xhtml strict using whatever hacks necessary to get the page to render in IE5+6 Windows, Mozilla, and Safari. Code must validate. Styles should be built using an external cascading style sheet to allow for multiple independent interface designs.
We're looking at 20+ pages, although some will be fairly similar in content (that is, on some pages only one or two div containers might change).
Does this make sense to you? Have you programmed sites like this before? Please e-mail at firstname.lastname@example.org with your rate (hourly? per page? per project?) and sample sites that you've built (I'll be looking at the technical sophistication of the xhtml code, not how pretty they are.).
Please note: This is a paying gig. I have not set a rate for it because I do not know what is appropriate for what I am asking and don't want to disqualify anyone by offering too much/too little. This is a fairly big project -- I'm guessing it will take several weeks to a month to complete; we are willing to pay a fair rate.
02-08-2005, 01:59 AM
Check your Private Messages
02-08-2005, 02:51 AM
02-08-2005, 06:03 PM
Why XHTML? Why not? Read Jeffrey Zeldman's "Designing with Web Standards." :cool:
02-08-2005, 08:06 PM
The answer depends on what your question is. If your question is why xhtml strict as opposed to xhtml transitional or html transitional, it's because I can't see any reason to build a website in 2005 that does not strictly adhere to web standards. There's no longer much of a reason to sit on the fence when it comes to standards; might as well build to them and use the various methods that have been discovered to keep older browsers from choking on the code.
If your question is why xhtml as opposed to slip-shod code that may or may not use css and still uses tables for layout, it really comes down to cost. It's cheaper to maintain a large site that is well written using xhtml than one poorly written using no standards -- even if they look the same. If I want to change the look and feel of the site, I shouldn't have to touch the xhtml page -- only the stylesheet. And if I'm only changing the stylesheet, it means that I can update every page on the site from one place. Change the color in the nav bar from blue to green everywhere in the site? I change one line of code on the css page and it's done. Move the navigation from the right side to the left on the entire site? Just change the stylesheet.
Sure it takes more time to make sure that an xhtml page not only validates but looks good across all browsers, but the time saved on the backend can be substantial.
By the way, I've only gotten a couple of replies to this post so far -- I'm far from overwhelmed with candidates. If you think you're right for this gig, please contact me!
02-08-2005, 08:20 PM
My question was why XHTML instead of HTML? HTML is a standard too, and you get the same benefits. Plus it's supported by Internet Explorer, which is one of your requirements.
Using a strict DOCTYPE is a given really.
02-08-2005, 08:35 PM
Right. And, as I replied, I can't see any reason not to build to xhtml standards. IE can be supported under xhtml if you know how -- so why not? Seems like less hassle to build to the latest standards then to rebuild the site later to meet standards.
02-08-2005, 08:51 PM
Right. And, as I replied, I can't see any reason not to build to xhtml standards.I just said HTML is a standard (http://www.w3.org/TR/html401/), and when coded correctly is almost exactly the same as XHTML.IE can be supported under xhtml if you know howNo, it can't. IE does not support XHTML at all. It doesn't even recognise the MIME type.
02-08-2005, 10:18 PM
Hemebond has some excellent points. As far as I know, the only CURRENT advantage to using XHTML over HTML is to satisfy the inner "web geek."
The argument about using web standards is an ignorant one; web standards refers to the separation of style from content, and coding structurally sound, semantic code. HTML 4 is all of that, the main exception being it doesn't have a trendy "x" in its name, and there are no self-closing tags. If HTML 4 validates and is coded structurally sound, there are no real advantages to XHTML.
The only way IE can understand XHTML is to use server-side instruction to change the document to HTML by replacing the doctype and stripping the slashes from the self-closing tags. It can be argued that if it's so simple to convert a document from XHTML to HTML, it would be as simple to change it the other way around when browser support is likely.
Speaking of browsers, the only browser out there right now that PREFERS to receive a document as xml is Mozilla, as far as I know. IE, Safari and Opera all prefer to receive documents as text/html, which is best delivered in HTML, otherwise you are just sending tag soup.
I build all my pages with XHTML, and have been using PHP to parse the pages tailored for each browser, but it's not because it's the right thing to do, it's because I am a big web nerd. The least you can do is admit it yourself. :D
02-08-2005, 10:55 PM
Again, my answer is the same: there's no reason not to build to the latest standards -- as you point out, all one must do to get an xhtml page to display correctly in IE 6 is to change the doc type. But getting a page that validates under html 4 transitional to validate under xhtml 1.0 strict may take more than changing a doc type. So, why build to the old standard if the new standard can function on non-compliant browsers by just changing a doc type or creating a special stylesheet?
02-08-2005, 11:16 PM
as you point out, all one must do to get an xhtml page to display correctly in IE 6 is to change the doc type. But getting a page that validates under html 4 transitional to validate under xhtml 1.0 strict may take more than changing a doc type. So, why build to the old standard if the new standard can function on non-compliant browsers by just changing a doc type or creating a special stylesheet?
No, that's not what I point out. IE reads everything sent as XHTML as tag-soup. It doesn't understand what XHTML is. It's not "rendering correctly," it's actually taking wild guesses at what all those wacky trailing slashes and closed tags are supposed to mean, not to mention it has no idea what to do with that doctype.
To get IE6 to truly display the page how you want it to display, you HAVE to send HTML. Internet Explorer only understands HTML sent as text/html. That's all it cares about.
I see your point, but I don't understand why you keep bringing up HTML Transitional. Code a page to HTML Strict. Avoid tags that were deprecated in XHTML. Validate your page. When it comes time to convert to XHTML, all you have to do is insert some trailing slashes in your self-closing tags and change the doctype.
There is no valid reason to code a page in XHTML Strict versus HTML 4.0 Strict other than sheer geek value.
02-08-2005, 11:24 PM
Again, my answer is the same: there's no reason not to build to the latest standards -- as you point out, all one must do to get an xhtml page to display correctly in IE 6 is to change the doc type. But getting a page that validates under html 4 transitional to validate under xhtml 1.0 strict may take more than changing a doc type. So, why build to the old standard if the new standard can function on non-compliant browsers by just changing a doc type or creating a special stylesheet?Woah, woah! There's a lot more to change than just that. Off the top of my head Internal Javscript and CSS in XHTML must be contained within CDATA sections closing slashes for empty elements DOCTYPEThere's bound to be some others as well.
02-08-2005, 11:51 PM
Look guys, not only is this completely off topic for this forum, you're not telling me anything I don't already know. If you'd like to continue the debate over whether to code a site in xhtml, html or pig latin, there are more appropriate places to do so.
You may see planning out a site to function in xhtml as having no useful purpose today, but it's not my job to plan for today -- but for tomorrow. The site I'm working on is launching with over 20+ pages (most dynamic) and will grow to hundreds. I do not see "insert some trailing slashes in your self-closing tags and change the doctype" as a minor fix at all. I want this site to have a strong structural foundation that follows, as closely as possible, the web of tomorrow's emerging standards. And I will not limit it by conforming to a browser (IE 6) that will disappear with the arrival of Longhorn and the growth of Firefox's popularity.
02-09-2005, 12:04 AM
And I will not limit it by conforming to a browser (IE 6) that will disappear with the arrival of LonghornIt still will not support XHTML or any of the latest technologies. Plus, changing your site once from HTML to XHTML, is much better than each page rewriting itself each time it's served.
BTW, your homepage doesn't validate. Had it been served as XHTML, I would have been able to read it at all.
02-09-2005, 12:37 AM
I appreciate your input. Thank you for taking the time to try to help better inform me about web standards. However, this thread was created with the intention of finding a skilled programmer to help complete a specific task. If you are not requesting more information about the position (which was, I thought, the intention of your original query), or applying for it, I ask again that you continue this discussion in a more relevant forum/thread.
02-09-2005, 01:02 AM
No, I probably shouldn't. I'd like to, but I can't. Is this a programming job or just XHTML+CSS coding?
02-09-2005, 01:15 AM
We have the "real" programming covered. We just need someone who can take Photoshop mock-ups and turn them into lean & mean xhtml/css.
02-09-2005, 01:56 AM
I include that as one of my favorite activities. PM sent
02-09-2005, 02:55 PM
XHTML has many advantages over HTML, but my favourite is the fact that since it is required that all tags are closed, you probably won't have any issues browsing such a site with a handheld device since there won't be any parsing issues.
Regarding this job, do you provide us with a tool which we can use to test how the site looks on Safari for us non-Mac users?
I generally use a Doctype of XHTML Transitional though my code is XHTML Strict valid because on some browsers, the CSS seems to render unpredictably for certain elements. If this is a problem, please let me know.
02-09-2005, 05:23 PM
In the end, I'm open to how the doctype is written, but I want the code to conform to xhtml standards. I'm actually kind of toying with the notion of serving entirely different headers for different browsers to avoid some of the ugly hacks required to serve separate stylesheets to some of the older browsers. What we're building has a pretty robust backend, so I'm open to this. I haven't discussed it with our lead programmer yet though -- I would defer to him.
As far as Safari testing goes, for the most part what works well in Mozilla will work well in Safari -- we have Macs here onsite and can double check the pages for compatibility. I don't forsee a lot of issues arising from this browser, so I don't see having access to a Mac as a necessity for this gig.