Im soooooo stoked because Im starting to take a web design class on may 27th. Im trying to get a feel for the local community college and need an easy course or two this summer. I want to be able to master xhtml, dhtml and get a good way into php, by the end of this summer. Sound like a good plan?
pah you could learn them in a day if u tried be careful some webdesgin courses may have their own agenda and therefore may be a little *dated*, check the course syllabus ie. don't bother with a course that teaches html if u want to learn xhtml and not one that teaches perl if u want to learn php...... sure they might be useful but they aren't what u want but i hope it is a good course and u should have some fun
so you're saying that learning html (which I have been doing, done! ) is pointless because xhtml is different? Or its pointless because its old compared to xhtml.........
well what i was saying was that if u want to learn xhtml theres no point being taught html (as u have already pointed out u know it already) well xhtml is designed to supercede html and be a transition betweeen html and xml... so doing a course whch does xhtml/xml if you already know html would seem more sensible arg i'm confuzzling myself now...... basically check the syllabus... its all very well wanting to learn xhtml,dhtml and phtml () but what i was saying was that if you want to learn them makesure the course covers them... theres not much point in spending money on a course which will teach you what you know already or teach you what u don't want to know just makesure the course is what u want... i'll shut up now i do go on sometimes
phtml is php... some webhosts have/used to have php files with phtml extension.... i was just mocking the pattern between xhtml and dhtml
In the beginning, There was SGML, the Standard Generalized Markup Language. It is an international standard, very complex, rigidly stuctured, and it's actually a tool for describing markup languages (it's a metalanguage). HTML is kind of a ******* son of SGML, but it carries some of the genes. The idea (which seems not to get used much) of a Document Type Definition comes from SGML, and the concept of stuctural markup (<P>, <UL>, <H1>) is from SGML as well. The markup was intended to describe the function of the text, and leave the user agent (that's a browser usually) free to interpret it according to local user preferences. Well, that's not what happened at all. Users subverted the structural purpose of tags and used them for layout control. For example, there's an <EM> tag that is supposed to indicate emphasized text, which may be rendered in bold in a graphical browser, but in all caps on a text terminal. But no one uses that, they reach for the <B> tag instead. The browser companies threw gasoline on to the fire with more tags for manipulating layout. First <TABLE>, <BLINK>, and body background images, then <FONT>, table background images, GIF transparency (which got abused to do layout). Before long, everyone was whining about how HTML was a crappy layout tool. And it is, you know. If you've ever worked in a real page layout tool, trying to do artistic things with HTML is very painful. But that didn't stop anyone from trying. The next wave included Applets and embedded multimedia gizmos, and animated GIFs which just made everything more tacky and less functional. The original idea of functional markup appeared to be dead in the water. Enter Cascading Style Sheets. Some smart people said "remember the original concept of markup was to separate the data from its presentation." And CSS is a great tool for that. You can completely decouple what the data is and means from how it's presented. That's important. Not only do you have better tools with CSS to do real layout, but you can do real layout without severely mangling the text you are presenting. I know you've seen pages where the ratio of markup to content is amazingly high. Tools like Dreamweaver would just keep wrapping tags as you make changes, so you see stuff all the time that looks like this: And the brilliant "designers" that produce the pages that look like that were billing $100/hr. Dreamweaver lets them get more done in a billable hour but only by producing code that is hugely bloated. In the above example, our genius "designer" changed her mind just once about the color and once about the size of that text. It can get a lot worse, and I've seen it (and had to maintain it). So what's so bad about font tags? They have no relationship to the structure of the data, just to the presentation. Compare this to a CSS approach. I want to do exactly what the genius designer does, and make my text big bold red Arial. Let's say it's a warning notice on my page somewhere. Thanks to CSS1 and HTML4, ll I need to do is: and have an appropriate selector and rule in my properly linked stylesheet (a separate document, which the client can cache for efficiency): Code: .warning { font: bold large Arial, Sans-serif; color: red; } Now we're getting somewhere. This is a real advance in technology. I can streamline the actual markup (33 bytes versus 145), and the style info is stored ()and transmitted and cached) separately from the content, and I get a self-documenting structural markup tag, and I can reuse the warning selector freely thoughout my whole site, and I can update them all with a single stylesheet change. Pay attention to that last one. I said "I can update them all with a single stylesheet change." Who cares? You do. Creating cool websites is fun, but maintaining them is anti-fun. It's like Kryptonite. CSS is the antidote. If you do your design job well, and embrace functional markup and observe rigorous separation of style and content, maintaining your site will be as much fun as building it was. Or if you do this professionally, the person who follows in your tracks and has to maintain your code will sing songs of joy instead of firebombing your home. OK, what about XHTML? Remember SGML, our grandaddy? He's a randy type and gave birth recently to another offspring called XML. XML was created around the idea that machine-readable, functional markup (sounds a lot like the original goals of HTML) was a worthwhile thing, but that HTML was to flabby for the job while SGML was too complex to be useful. Hence, XML. It is a metalanguage like its parent, in that you can use XML to define your own markup language. That's useful in business-to-business situations where you need to update inventory with a trading partner. Once you've adopted an agreed-on markup language (an XML DTD or schema) your machines can talk to the partners machines in a direct way about your inventory. It's a universal data interchange format of sorts. Well, XHTML is a redefinition of HTML4 as an XML DTD. Not only can you impress your friends at parties by saying that, but it has some benefits. HTML has typically been a pretty well-defined syntax, but the user agents haven't insisted on synactical correctness, and all sorts of hilarity (not) ensued as things like DHTML came into common use. Browsers had to deal with an increasingly wacky Document Object Model, a scripting framework to let ambitious programmers and designers manipulate that DOM, several versions of HTML syntax and the kicker is that they all had code to try to "do the right thing" when faced with malformed, syntactically incorrect (like nested <A> tags) and genereally bozotic HTML (about 90% of all markup fits this description). XHTML changes that. Sort of. An XHTML document is required to be a well-formed XML document, which means no syntax errors allowed. Some weirdness about empty versus non-empty containers was resolved, which brought about the new syntax for empty tags (like <br/> It's a ggod thing. You can chhose to look at it like HTML4 with some syntax ambiguities clarified if you like. But the real benefit is still over the horizon a ways off. As I said, XHTML documents (if they validate) are well-formed XML documents. We could eventually see the advent of sophisticated new web robots that do useful things like scour the web to find you the best price on a motherboard, or locate an eye doctor near you. Those things are still in the future, but they represent the original promise of the web (no, it really wasn't pr0n). Getting on the XHTML bandwagon now is healthy because it advances the state of the design art toward that ultimate goal of a semantically marked up web.
Linear. You need to write some articles, a book. You cleared up quite a few things for me. Now all I have to do is read all the W3c tutorials. very informative post, brotha.
wow sweet post linear.... that should go in a sticky or something ..... can't say it was new to me but its a nice history of html/xhtml/xml
OK, it's in a sticky now. I edited it for consistency and fixed my own XHTML syntax error and expanded it slightly.
..Not to ruin your hopes, but I took a web design class over the summer and it was a complete let down. We strictly used Microsoft Frontpage and didn't mention XHTML, CSS or even HTML for that matter. Be careful, and try to talk to some people that have taken the class before. The advanced topics are a lot of fun if you're lucky enough to find a class that goes that far.
You know that's a good point Amadeuss. Last time I had to hire a web developer, I did my usual stunt of requiringa URL where I culd view a sample. 95% of the submissions came from 'web designers' whose sole experience appeared to have been using FP to whack something together for a class project. I skipped the page and went straight to the source--presence of a META tag with generator="frontpage" was automatic disqualification. The guy I ultimately hired had written a set of Perl scripts that manage the online inventory for a medium-sized used car dealership.
the rude instructor never contacted me back so Im gonna go ahead and take the class anyway. Wish me luck !
