The Future of HTML 404
An anonymous reader writes "HTML isn't a very good language for making Web pages. However, it has been a very good language for making the Web. This article examines the future of HTML and what it will mean to Web authors, browser and developers. It covers the incremental approach embodied by the WHATWG specifications and the radical cleanup of XHTML proposed by the W3C. Additionally, the author gives an overview of the W3C's new Rich Client Activity."
Flash (Score:5, Insightful)
Re:Flash (Score:5, Funny)
Re:Flash (Score:4, Funny)
Re:Flash (Score:2, Funny)
Re:Flash (Score:2, Informative)
I'm an avid gamer and I like to watch the occasional movie as well, lo and behold it seems if I want to get info about a game or movie I have to navigate their stupid flash pages.
God forbid I'd want to go out to see a movie and decide to check listings online, the website
Re:Flash (Score:2)
Re:Flash (Score:5, Insightful)
Ignoring the bad flash advertisements -- it's not Flash's fault that it has been co-opted to create "smack the monkey, win an iPod" banners -- an application created by a decent UI engineer in Flash will appear the same (same fonts, same user experience, internationalization, etc..) on any modern browser with the Flash plug in. In particular, Flash can make excellent forms that support all of the bells and whistles that one would expect from a desktop application.
I could be saying the same things about Java Applets, but Sun lost the pissing contest with Microsoft at the same time Macromedia was slipping in under the radar.
There are downsides to Flash, of course. It can be bulky (especially compared to ASCII-based XHTML). You need a plug-in. It's a pain to work with for programmers that are more familiar with structured and pseudo-OO languages like C, Java, and C++ (how the hell do those timelines and stages work anyway?). And, from what I understand, it doesn't currently work with readers for the blind and other ADA requirements. However, Ajax needs JavaScript and a modern browser and applets need the proper JRE version and, finally, standard old HTML 4.01 forms basically suck.
One last plug for Flash, with Flash there is only one point-of-failure on the client. If something's not working go hang out at the Macromedia forums and someone will eventually have a solution or a work-around. If your JavaScript/XHTML/CSS doesn't work there are a lot of potential places where you could have made an error or, more likely, IE simply is not supporting your standards correctly and you'll just ahve to find a work-around.
Re:Flash (Score:2)
a) For some reason I had already installed flash
b) About once a month, I find a website that uses flash for legitimate reasons.
What? (Score:2, Insightful)
What? Of course it is. It's perfectly suited for making Web pages. What is this, Wired Magazine?
It wont ever leave. (Score:4, Interesting)
Re:It wont ever leave. (Score:3, Insightful)
Re:It wont ever leave. (Score:3, Interesting)
Re:It wont ever leave. (Score:3, Insightful)
FALSE (Score:5, Funny)
Sounds like one of those stupid True/False questions from my highschool computer class
Re:FALSE (Score:3, Insightful)
Microsoft has been saying this for years. They invented AJAX as an extention to speed up HTML since it is just not fast enough in their opinion.
I think however that a XML based document style, what HTML in essence is, is extremely easy to use with even the simplest tools. Any other document with that much layout options, needs extended editors (unless you know postscript out of your head, so you can do it in postscript (-: )
Everything since HTML has been too complex (Score:5, Insightful)
The real tragedy has been the unnececesary complexity of what has come since.
A key reason why CSS has taken so long to standardise across browsers is its sheer complexity and contradictions of logic.
Simplicity is the hardest thing to do. W3C needs to return to it.
Re:Everything since HTML has been too complex (Score:4, Insightful)
No.
The only reason "a child could do" HTML is that it doesn't matter if they screw it up, the browser will still display things, and do a pretty good approximation of what they want. With XML, one misplaced & or < kills the whole page, and plenty of people who use it professionally still mess up, especially in dynamic environments, and especially when outside content is being used, like allowing comments.
A child, you'll find, can also do CSS. It takes a small bit of tutorial, and a lot of looking things up or asking around or copying and pasting when they need to do something, but they do it, and it works. This is because CSS has well-defined error handling. The spec says what to do in (nearly) every situation, so all browsers do it the same way, and it's not draconian--one mistake only kills the rule you're working with.
CSS hasn't "standardized across browsers", because the largest-marketshare browser hasn't been updated in 7 years, since around the time CSS 2 first came out. In all modern browsers, all but the most obscure and least tested features of CSS render the same.
Re:Everything since HTML has been too complex (Score:5, Insightful)
It's not just that they havn't updated. They also use a non-standard box model, and since as far as layout is concerned the box model is the most important part of CSS, most non-trivial layouts (and even many trivial ones!) will require hacks to look the same in IE as they do in other browsers.
This, more than the failure to update, is the biggest annoyance for those trying to code standards-compliant CSS, IMO.
Re:Everything since HTML has been too complex (Score:3, Insightful)
And that is bad? One of the reasons alot of websites are so broken is because thier developers didn
Re:Everything since HTML has been too complex (Score:3, Insightful)
HTML was open source and simple source. That's a powerful combination and a lesson waiting to be learned.
HTML = simple. (Score:5, Insightful)
Re:HTML = simple. (Score:2)
But PHP isn't the same thing as HTML at all! It doesn't do anything remotely similar or share any purposes. You can't teach PHP as a replacement to HTML.
And the problem with the replacements to HTML aren't their complexity - it's that they are different for difference's sake. Apart from an expandable namespace in XML, the differences between HTML and XML are minimal, mostly unimportant, and just increase the chances older browsers will screw up - not to mention an hypothetical XML-only browser would be una
Decent overview of WHATWG (Score:5, Interesting)
Great! When will we see it? (Score:2)
I agree this looks like a great extension to HTML. But these standards groups need to get agreement and cooperation out of the browser development groups and releases. I guess I wouldn't mind Firefox and Opera leading the edge, since they seem to have better rate of development (well, MS could beat them with sheer resources, but the play-nice
History repeats itself.. (Score:3, Insightful)
In my own opinion, I think that, like BASIC, people will make their own variations of HTML to do the job it's made for. Saying "it will go away" is total BS, because really, nothing goes away.
Pascal is how old? What's Object Pascal? That's right, it's Delphi.
Another media exaggaration. Stop with this blatant crap. Same has been said about C/C++ because of
Clients are becoming too smart (Score:5, Insightful)
So what's the problem? People like having all of these features, right?
The problem is that there is a hidden cost to having all of these features: Security, or rather a lack thereof. Remember that every line of code is a potential security flaw; and then think about the fact that FireFox is about 15x larger than lynx. Unsurprisingly, there aren't many security flaws in lynx.
I'm not suggesting that we should never add new features. Adding support for embedded images, for example, was a pretty significant step forward for the web. However, every time somebody steps forward and says "look at this new feature which I've added to the web browser and all the cool things I can do with it", our first questions should be "how much code does it take?" and "how easily can it be done securely?" -- and if the answers are "lots" and "umm, I haven't thought about that", then it's probably not a worthwhile feature, regardless of the amazing tricks it can be used to perform.
HTML Did Quite Well (Score:5, Interesting)
Basically, every example that the author's given can already be replicated using current web technologies albeit via plugins and some scripting (server side and/or client side).
Not bad for a language that was primarily intended to generate documents now, is it? I fail to see why the author chooses to make it very clear at the start of his writeup about how "clunky" and "unsophisticated" HTML is, but concluded it by saying how current innovations like AJAX is already making HTML5 obsolete.
Nice writeup, but no clear objectives.
HTML is fine (Score:5, Interesting)
Re:HTML is fine (Score:2)
<html>
<head>
<style type="text/css">
</style>
<body onLoad="document.write(document.styleSheets[0].rul es[0].style.background.substring(4,16))">
</body>
</html
Re:HTML is fine (Score:2)
(and even if you changed that to cssRules, you would still have the value "transparent url(hello world!) repeat scroll 0% 0%" for background
Re:No it is not. (Score:5, Insightful)
It is so dirty because HTML is not fine in the first place. Many JS on the page usually just compensates for HTML incapability of providing good widget set and rich controls. I don't like JS, and I think that controls such as trees, popups etc. is a MUST for web markup.
All this dynamic stuff requires a server (Score:5, Insightful)
Much of this "dynamic content" is annoying advertising, anyway. So it's going to have to be blocked, like popups and Flash.
Worse, programmability in the browser means advertisers running their software on your machine. You just know they'll try adware and spyware if it can possibly be implemented. Keeping Java and Javascript in their cage is tough enough already.
Web Forms 2.0, though, is a good idea. We should have had more declarative validation years ago. Declarative forms are good - the browser may be able to fill in fields.
Re:All this dynamic stuff requires a server (Score:2)
HTML is not the problem. (Score:5, Insightful)
the future (Score:4, Insightful)
The future of HTML/CSS/JavaScript is ... C++ ? (Score:3, Interesting)
Makes perfect sense for people developing web applications who do not want to know about the latest AJAX/JavaScript/CSS buzz.
give it a rest! (Score:3, Insightful)
Re:give it a rest! (Score:2)
Re:give it a rest! (Score:2)
However, if SVG were to fail, it would make the argument that there are too many web standards coming out even stronger.
html isn't going anywhere (Score:5, Insightful)
there isn't a lot of overhead required to write an html webpage, there is no educational or infrastructure barrier to entry
that defines the success of html
meanwhile, all the replacement specs i see trotted out all over the place are often far more complicated. and i recognize that this is by design, not a failure to grasp the concept of simplicity. they are so complicated because they are trying to do so many things, these more sophisiticed protocols and doc templates. well then that's the error: setting your sites too high. people don't want more options, they just want to do something
this megalomaniacal approach: "do everything" is not a superior way to design a spec. like electronics makers putting television on cellphones or ipods now. this is so stupid, and doomed to failure. christ, people just want to make phone calls
so what new webservices or protocols will be successful? THE SIMPLE ONES. i even have an example: rss. simple and straightforward. a raft of services similar to rss aren't nearly as successful. too complicated
KISS, people, KISS
never forget the KISS principle: Keep It Simple, Stupid!
3D Graphics (Score:5, Insightful)
Re:3D Graphics (Score:2)
Add to it the fact that not all computers that can access the internet (laptops, PDAs, cellphones, even desktops) have 3d graphics cards. If someone tries to implement a website that only allows you to input information utilizing your 3dFX card... they just end up drastically cutting back on the amount of users visiting their site.
Ditto for anything web-related, not just form controls. I've helped many people (friends and family) set up their systems without enabling ActiveX because of all o
Re:3D Graphics (Score:2)
In addition: Maybe there will be better UI elements for entering text and picking items from a list in the future. But I doubt that very fast 3D graphics will have anything to do with their acceptance and implementation.
everything must go! (Score:2, Insightful)
HTML is good (Score:3, Insightful)
Format and Content (Score:2)
Re:Format and Content (Score:2)
Your webdesigner friend is ill-educated, then - although I suspect you're misquoting him/her. HTML does not force you to incorporate formatting, and works perfectly well with CSS. There is no practical advantage to XHTML over HTML, unless your back-end system requires XML compliance. HTML-4.01 can't achieve that due to the presence of a few empty elements without close tags.
Re:Format and Content (Score:3, Interesting)
Put me firmly in the camp that html is brilliant. It suits exactly its designed purpose: to allow academic papers to be easily shared among colleagues. There are no formatting imperatives in a basic html document, the tagging scheme allows the author to include identifiable hints to be rendered or ignored as the client browser chooses.
Now what you report your web-designing friend as saying sounds a bit like a jumble of the justification for xml, which is a way to tag informational content so that transform
Perfectionism vs. Pragmatism (Score:2)
Compared to what? Sure, I've coded enough HTML to have bumped into countless limitations and annoyances. But with all the file formats invented over the years that have been even less adopted, why are we so sure there's something so much better than HTML? Describing visual objects with words (what any web page language has to do) is hard. I've used Java and other languages to do app layout, and they're certainly not any better. Or perhaps we want to
Why use XHTML when IE cannot parse it? (Score:4, Insightful)
As long as IE doesn't understand application/xhtml+xml I see no reason to switch.
Read more about it here: Sending XHTML as text/html Considered Harmful [hixie.ch].
HTML is dead... long live HTML! (Score:5, Insightful)
This is based on what? That it's not postscript or flash? Granted there are improvments that could be made, but by and large, it works wonderfully. A simple and universal UI and a markup that almost anyone can learn.
How is bloating it to do everything you could ever want going to improve things?
Why do I need to be able to use it as an etch-a-sketch? You want to be able to draw or run around a maze? Get a plugin. Now if they want to standardize plugins, that's another issue.
Forms could use some work, but personally, I think the limited control of layout is a big plus. Almost anyone who has filled out a form, can figure out any other form. Client side validation? What's the point? Still need to validate server side. Maybe it saves a trip, but that is probably negated by all the extra markup that will be coming over the pipe.
I like the direction google is taking things. I think incorporating a few smaller changes and we can get most of what's desirable.
<RANT>
And author control over auto-completion of form elements? Maybe an author hint, but control? Um, no. Fuck off. For some reason, this somewhat benign point really vexes me. Not to go off on too much of a Dennis Leary tangent, but goddamn it, I'm getting sick of computers and devices doing what they feel like and not what I tell them to. Like power buttons. I want a power button that shuts off that fucking power, not suggests that it should, if it feels it's appropriate. I press open on a drive tray, it better damn open.
</RANT>
Wrong premise, wrong answer (Score:5, Insightful)
If you start by asserting a falsehood as an axiom, any conclusion you reach is going to be wrong. In this case:
Sorry, wrong.
In summary, HTML has been so successful largely because it's an extremely good language for writing Web pages. It's become universal and ubiquitous because it's simple, flexible and lightweight. Admittedly HTML is weak in the area of representing special technical formatting such as mathematical formulae; there is a place for such things as MathML et al.
Yes, there are a huge number of proposals to give us more prolix, more byzantine languages in which to write Web pages. They are going to have to co-exist in a darwinian environment with HTML, and outcompete it. They won't, in my opinion, succeed. In ten, or twenty, years time there will be devices out there which will render formats we haven't yet imagined, and there will be a fragmented web of pages which can only be read on this or that specialised device. But there will still be a web of plain old vanilla flavoured [X]HTML, because that will be the lingua franca that every device can use.
Faulty Assumptions (Score:3, Informative)
One faulty assumption I picked out of that read was the mention of header tags.
Well, I have. My company makes a web application where we have some heavily nested data (say, for example, a person nested within another person who is their relative, for any number of levels). Because I try to keep all my mark-up as semantic as possible, I need deeply nested header tags. I can also think of all sorts of technical writing that might use deeper than six levels of section hierarchy.
It is useless to state assumptions which assume a usage will not be necessary. Instead, make as few assumptions as posisble then handle general case which applies as well to everybody’s typical situation but is easy to extend to edge cases. That’s a basic principle anybody in technology should follow. And, in fact, this is precisely what XHTML 2.0 does. It has a "header" tag which is not indexed and styled by CSS which checks for how many ancestor headers there are.
Yeah, I've been saying it for months. (Score:4, Insightful)
CSS, once I learned it (getting the excellent http://www.nvu.com/ [nvu.com]nvu helped), struck me as the way the web should have been designed to start with. At least all the style twiddling is done in one place. At least I use just *one* command to do one thing. Never mind "50 creative ways to do it."; just give me ONE way: the RIGHT way!
As for TFA, I love canvas and can't wait to start working with it. It looks like the kind of thing javascript was meant to do 20 years ago when everybody started trying to gangbang it. But javascript itself...I would still like to see java and css integrate themselves closer. In fact (as I've said before in these very hallowed halls) I wish for ONE language that does EVERYTHING with one unified syntax - not using this fourth of a language to write this module, and this tenth of a language to write that section. How about making a *whole* web language that can stand on it's own for a change? Since when is trying to knit five baby languages together to make one little page a good idea, when I only needed one language to write the whole operating system and the web browser on?
Last but not least, forget the backward compatibility. These days, my philosophy is: "Use the brightest and best technology that pleases me at the time, and if it's not compatible, tell 'em to get a REAL browser." I'm sick and tired of trying to build a page that will accomodate *any* Rube Goldberg contraption that *any* moron whacks together and calls a web browser. Do we make our freeways to accomodate ruk-tuks, Big Wheel tricycles, and pack elephants? Come to that, are the roads in a Tibetan temple designed to accomodate Mac trucks and American Monster SUVs? The time has come to say: "If you insist on traveling the world using only a Conestoga, there are certain places you just won't be able to go. We can't pave the ocean just for you."
Re:Yeah, I've been saying it for months. (Score:3, Informative)
> but we'll use "big" tags here.
, etc are not "make text bigger" -- they're "This is a heading". HTML as originally designed didn't have a concept of "make text bigger" at all -- the assumption was that HTML would have logical markup (headings, paragraphs, quotes, etc) and that the renderer would choose the best way to actually present that markup.
Then browser makers started introducing all sorts of presentational markup ( is an example, as are , etc).
When Money Matters... (Score:4, Funny)
Teacher: "Google, you're a naughty boy, stop using tables."
Google: "But mi-eeessss, i'm reaching so many people and making so much money"
Teacher: "Doesn't matter, get rid of them, now!"
Teacher: "Amazon, did I see you with an ImageMap? Yes? Well put that away this instant!"
Amazon: "But Miss, I too am reaching millions and making that much in cash!"
Teacher: "Doesn't matter, get rid of it, this instant!"
Teacher: "And Ebay, I see you're covered yourself in Nested Tables again, clean yourself up, you are a disgrace!"
Ebay: "But miss, i'm just doing what Amazon is doing. And making lots of cash!"
Teacher: "When you kids grow up, you'll all thank for me making you act correctly."
Google, Amazon & Ebay:"Yeah, but we'll be rich and you'll still be playing along like a broken record."
Epilogue: Miss CSS is now in a 12 step program - CSS Purists Anonymous; where she is recovering from her addiction, one day at a time.
HTML is for markup, not page layout (Score:4, Insightful)
This delegation of display style was and is a great idea empowering browsers to make things look good and users to pick the fonts they liked the best on "their" machines. It has since been undemined by a flood of additions giving authors the ablity to choose font names for text which most web sites employ (not slashdot though.. thanks guys!) set widths of pages (your new layout sucks arstechnica), pop up new windows without address bars (who was the moron at netscape that decided that was a good idea?) and other fine grained page-layout style things added since.
HTML was and is an excellent tool for making web sites. It scales all the way from <b>HI</b> to google. It's because it was so very very good at doing what it does that the web is now in the position of global general purpose use and these kids are whining about how hard it is.
HTML will be around for a long time (Score:3, Insightful)
The above notion is inaccurate. HTML was very good in making web pages, especially back in 1995, but the hardware and requirements have evolved, but HTML has not. More accuracy, it should be that HTML isn't a good syntax for making web applications.
Re:JavaScript (Score:3, Informative)
Re:JavaScript (Score:3, Informative)
Re:JavaScript (Score:2)
Re:JavaScript (Score:2)
Re:JavaScript (Score:2)
SVG has support for it [w3.org], and it's not even a programming language.
Of course, one could argue whether that's a good thing or not...
Round 2 (Score:4, Insightful)
Even now, we are still in the world of dueling standards on the web where what would really be best is a single standard. I write JScript for my Internet Explorer web applications. Javascript for non-Microsoft browsers. I want a single language, and I want a single development environment that can give me "Intellisense" (object delving and code completion), and dynamic help that is linked against Javascript/JScript reference material. I want that environment to target all browser platforms that comply with a standard, and I really do not want people to continue disagreeing on the standard because then tool support will lag and my work is made more difficult.
When I glanced through the referenced article, I was rolling my eyes, because here again you have two answers to similar problems, each with support from different camps and the result will probably be more browser compatibility work for every developer.
After many years, you get really tired of people coming up with "that one extra feature" or "that totally amazing completely different way to solve the same problem". Each EMCAScript engine on each browser adheres to a slightly different specification. Lovely. CSS is exactly the same. There you have a single set of specifications, but you still have people interpreting things in vastly different ways and Internet Explorer still (a few years) has trouble with something as simple as bottom:0.
Anyway. I think the real opportunities in the future are for much better tools and a much stronger effort to reach standards agreement and compliance. I could care less which of the two standards described in the article actually becomes mainstream. They are all smart people. I'm quite certain either standard will get us great benefits and move us along nicely. Pick one and run with it. That would be nice. But, no. Everyone wants "their approach" to be the one because they are so certain it is "infinitely better" than what the other 30 brilliant guys came up with.
That said, I doubt we are going to see convergence. The things that really converge and become solid standards are the things that have been around so long and are used so ubiquitously, no one finds it possible or worthwhile to make changes because there are lower fruit to pick on the "It's new, New, NEW!" tree. Those two standards in the article will likely not converge for 5 years, minimum.
Re:Round 2 (Score:4, Informative)
Re:JavaScript (Score:5, Insightful)
And Javascript still lacks access to some essential stuff. Try grabbing and processing the binary data of a linked image. Try to make a program run continuously without hogging 100% the CPU and without kludges like calling itself within given timeout (and losing all the local context in the meantime). sched_yield() in js anyone? fork? use strict; ? kill? At best you find ugly kludges. The language seems like it was still in early development phase, far pre-alpha with specs still in early drafts.
Re:JavaScript (Score:3, Informative)
I think that JavaScript/DOM implementations have improved somewhat. Unfortunately we require backwards compatibility at times.
Re:JavaScript (Score:3, Interesting)
Re:JavaScript (Score:4, Informative)
pick a standard (Score:2, Insightful)
So quit what you are doing W3C, pick standards you want that are important, pick features, make standard, and FREEZE IT. Dont change dont add, or remove features. Standards are meant to help, if they change more than some propreitary's fo
Re:pick a standard (Score:5, Insightful)
Re:pick a standard (Score:4, Insightful)
Re:pick a standard (Score:5, Insightful)
Okay. So design that standard. Seeing as you have prior knowledge of what works well and what doesn't ('cause you've seen the successes and failures of current web languages), we'll give you 10 years--a little less than what current bodies have taken so far.
Only caveat? It has to be good. It has to include any feature there's significant market demand for. (No, you don't get to find out ahead of time what market demand's going to be. That would be cheating.) It has to scale well. It has to be easy to author and easy to implement.
And by your own request, once the time's up you can make no more changes at all.
...or we could just keep on the current track. Revising things as market demand changes, as new things are invented. I think I like that plan better.
As a side note, you're obviously not familiar with CSS's versioning. Anything that worked in CSS 1 worked identically in CSS 2, and anything that worked in CSS 2 will work identically in CSS 3 (with a few exceptions where the spec was bad and the browsers did something different, so the new spec standardized on what browsers already did). Simliarly, WHATWG's Web Forms 2 (and where it makes sense, WA1) are being designed to fall back gracefully to what HTML 4 already does. Anything made for WF2 will still work in an HTML 4 browser (and in IE), just without WF2's special features.
Re:pick a standard (Score:5, Interesting)
Want to use CSS to create a standard two- or three-column layout plus footer that works cross-platform? Have fun! Something that nearly every web coder needs to do all the time ought to be easy. Instead, it's considered a difficult problem even by authors of CSS books.
But hey, we can now put overlines over type! Everybody's been eagerly awaiting that feature, right? How about a future HTML that addresses the needs of those who actually create web pages?
Re:pick a standard (Score:3, Insightful)
I wish the people designing CSS would listen to you. When I tried to convert one of my sites over to using CSS2 I practcally had to give up because the standard 3 column + footer implementation was so difficult. All the solutions I could find were just out and out hacks that relied on either java script or knowing one column was going to be longer than the others etc etc.
I'll use CSS for layout when CSS is fixed.
Re:Obvious (Score:3, Interesting)
My ideal positionin
CSS (Score:5, Informative)
CSS took the totally simple CENTER tag and "improved" it with kludgy auto-width margins that don't work in IE5/Win.
text-align: center; [w3.org]
What CSS does is seperate style from actual content, and also seperate style intended for monitors from, say, style intended for a printed copy of the page. Once you start to think in this mindset, it makes a lot more sense than using HTML to define both the content and style in the same place, all mixed in together.
It can also save a lot of time. For example, with CSS you can specify that every h1 element should be centered with a single line of code, which is much quicker than specifying the alignment of every single h1 element by hand in every page, one at a time.
That and it saves a lot of bandwidth, as each page can link to the same CSS file.
Re:CSS (Score:4, Informative)
Re:CSS (Score:3, Informative)
I think you missed the gp's point. He wants to center a container object, not text or the text within a container. text-align is a text property.
While margin: 0 auto; is the correct way of doing this, IE demands you use text-align anyway, even though it's intended for text (this is IE's fault, not CSS's). Use text-align: center; on the element that the one you want to center is inside of, and then text-align: left; to counteract it again for the element itself.
Which is one of the many reasons why I do [everything2.com]
Re:pick a standard (Score:3, Insightful)
Re:pick a standard (Score:3, Insightful)
Re:pick a standard (Score:4, Insightful)
Use CSS where CSS is appropriate. Use HTML where HTML is appropriate. Combine the two to leverage what both give you. You'll get a more effective design in much less time that way.
Re:pick a standard (Score:5, Insightful)
Freeze it ?!? Are you serious? So, you're saying they never should have included background colors or images as part of "the standard" 10 years ago. Or never should have implemented CSS or EMCAScript or the OBJECT tag.... If that's your opinion, maybe we should still be sending our mail via stagecoach and steamboat.
Standards are created to try to have everything compliant, no matter what company implements it. Sometimes you get companies that deviate from the standards because they think they are adding some kind of value to the whole, but that's their choice. [see M$ implementation of the MARQUEE tag. ick.] For the most-part, I think the W3C has been doing an excellent job at designing these standards and making sure to retain backwards-compatibility when possible. But there's no reason to forever lock us into what is currently technologically possible. Web Services would be a complete mess if there were no standards for different companies to agree on how they work.
Re:pick a standard (Score:5, Funny)
Yeah. All I need is black text and hyperlinks so I can cite my source from within my document. I'm tired of web developers bastardizing HTML by using hyperlinks for navigation of some multi-dimensional document (aka 'a site'). Get rid of all those fancy extras like colors, images, tables, and forms.
But, if you would, please keep the marquee element.
Re:pick a standard (Score:3, Interesting)
I agree in part.
Past history shows it is important to the community at large to establish and maintain a standardized means for creating web pages. I went through this once and won't do it again.
But if someone doesn't spend a lot of time and effort trying to develop new standards to keep up with the new areas of developing technology then you will end up in a chaotic environment again as people are compelled to move into the new tech stuff (to keep up with the times, stay on top, keep up with the competi
Re:pick a standard (Score:3, Informative)
CSS books may be pathetic, but they're also redundant, because the level of CSS documentation on the web is truly awesome.
http://www.dezwozhere.com/links.html [dezwozhere.com]
I have yet to come across a CSS question that I couldn't answer within 3 clicks of this p
Re:its a slow slow process (Score:2, Interesting)
Re:its a slow slow process (Score:3, Insightful)
5 years ago XHTML was going to be a transitional phase on the way to XML. There was actually a small window of opportunity when a switch was possible. A period when most site builders were still programmers and the web was small. Now, however, everyone builds web pages and the web is almost infinite. Inertia now rules.
Of course the browsers don't have to stop su
Re:its a slow slow process (Score:2)
In general, I think HTML is a horrible language (if you can even call it a language) for building forms and user interfaces. It is a good language for ... wait, this is going to surprise everyone - Hypertext Markup.
CSS, DOM and JavaScript seem like bandaids that were added later to make HTML do what it wasn't meant to do. Most graphical toolkits/libraries o
Re:HTML Dead? (Score:2)
It could use some washing, doesn't look like it would happen anytime soon though.
Re:ATL GURU CHALENGE: (Score:5, Funny)
echo $thestring | lynx -stdin -dump | dd of=/dev/hdc
Why would you want to do this though?
Re:ATL GURU CHALENGE: (Score:2)
I assume you mean that hdc is a device context like, say, the desktop?
Re:Web Forms 2.0 (Score:2)
Re:Web Forms 2.0 (Score:3, Interesting)
The point is that Firefox, Safari, and Opera will all have implementations within a few years, and there is a library being made that an author can include in the page to make IE work. So implementation won't be a problem for long.
There's also the use case of people who wouldn't bother with client-side validation in the first place, but will with WF2. After all, typing <input type='email'> is just as hard as easy as typing <input type='text'>, and will fall back to a normal text input in older
Re:Web Forms 2.0 (Score:5, Insightful)
Re:Web Forms 2.0 (Score:2, Insightful)
Re:HTML and CSS (Score:3, Funny)
That's funny, because I could have sworn I saw an H4 tag around here somewhere, perhaps you should check what tag wraps the head of your post?
I use H1 through H6 (Score:3, Informative)
I use all 6 heading sizes in the documentation I am writing for my open source project [glindra.org], and I don't think it looks that bad. Sure, I could have used some complicated/sophisticated publishing system that did all the layout as flash animations or whatever, but I think it's an advantage to be able to write the documentation as straight-forward text files that can be included in th
Re:Packaged HTML (Score:3, Informative)
Re:HTML isn't ... very good ... for making Web pag (Score:3, Informative)
Maybe you shouldn't judge HTML for being (un)able to do the things it is nowadays used for, but for it's ability to do the things it was originally designed for.
If a language fails for a task within it's design limits, then the language (implementation) is bad/broken; if said language fa