|
The future of HTML
Does anyone foresee HTML becoming more object-oriented (so you could define an event handler once for all of the radio buttons in a group as opposed to setting it up for each one), or am I on crack?
Anonymous Developer
Tuesday, February 3, 2004
Check out the news at W3.
http://www.w3.org/MarkUp/
I can't say for certain, but it looks like the Modularization of XHTML project aims to move HTML toward a more OO design. Anyone happen to be on the XHMTL Modularization working group?
Elephant
Tuesday, February 3, 2004
Is XHTML even relevant anymore? With the advent of XML content authoring and subsequent XSLT transformation to HTML 4.01, it seems that the purpose for XHTML has evaporated and the standard is stillborn. HTML 4.01 is widely supported, XHTML is not. And nobody needs XHTML anymore since the HTML pages are composed from XML documents anyway. Right?
Chris Nahr
Tuesday, February 3, 2004
"Is XHTML even relevant anymore?"
No, but it has nothing to do with XML. It has to do with the fact that browsers are stable, and HTML 4.01 is the end of the line. There's no purpose to push HTML any further.
We might see another round of CSS adoption, but I'm not even sure that's going to happen.
I'd say the state of the browsers today is where they will be for the forseeable future, unless Microsoft puts IE back onto their "important projects" list.
Brad Wilson (dotnetguy.techieswithcats.com)
Tuesday, February 3, 2004
Dammit,
I want my XHTML 2 navigation lists! They look genuinely useful.
Walter Rumsby
Tuesday, February 3, 2004
Sometimes, when I lay in my bed at night, just before I go to sleep, I pray for the end of HTML.
It should be replaced from start to finish. HTTP should be banned and port 80 should be blocked by default in all routers. Preferably in the hardware so that enabling it requires a soldering iron, a blank eprom and extensive asm skills.
Eric DeBois
Tuesday, February 3, 2004
Eric - Miss the days of Gopher? :)
m
Tuesday, February 3, 2004
==>Sometimes, when I lay in my bed at night, just before I go to sleep, I pray for the end of HTML.
SNARF! You just made it into my quote file!
If it does actually end (and I pray that it does) then I'll be satisfied in knowing that I managed to make it through the DotCom boom, bust, fallout, and rebuild -- all without ever truly knowing what the HTML thing was all about. Never written a single line of production HTML, XML or any other ML you want to mention -- and damned proud of it!
That's my story and I'm stickin' to it.
Sgt. Sausage
Tuesday, February 3, 2004
"Sometimes, when I lay in my bed at night, just before I go to sleep, I pray for the end of HTML."
god yes..let it die. let the xplat browser issues die, let the strange syntax die, let the entire steaming morass of crap slowly rot back into the primal ooze from which it sprang.
FullNameRequired
Tuesday, February 3, 2004
and what o' enlightened one is going to replace it?
Christopher Hester
Tuesday, February 3, 2004
"and what o' enlightened one is going to replace it"
<g> Im trying to imagine how it could be anything worse...
The point is that html was originally intended only to describe relative layout of text.
Its now used in shopping carts.
Between those two has been years of bending it out of shape to make things work.
HTML is the _wrong_ solution to the current requirements of the modern day internet.
When it was first used people didn't really expect it to be used in the way that it has.....any new setup will be designed with the current uses in mind and will be rather better designed.
actually I suspect that the 'correct' solution is already out there using css and xml....but I haven't really used either in enough cases to be sure.
But whatever replaces it will have to be pretty shocking to be _worse_ than html.
FullNameRequired
Tuesday, February 3, 2004
[...] no future [...]
(sex pistols: god save the queen)
(tim berners-lee: god save the net)
Tuesday, February 3, 2004
CSS is good.
The problem is that HTML is so tremedously poorly suited for client-server interaction.
What if everything in HTML was a proper object.
First you make a style sheet(client side)
myCSS{position-left:342px;}
Then you make the layout (client side)
MyTable = new table('MyCSS');
And then you have a serverside script:
MyTable.setContent(array);
Order of execution would obviously be reversed from how I wrote it.
Ah well, its way past my bed time.. Im probably dreaming already
Eric DeBois
Tuesday, February 3, 2004
That is my point I think, I am not arguing it's merit, only stating that like it's bastard cousin SMTP we are stuck with it, and in both cases, there isn't a viable alternative on the horizon.
Christopher Hester
Tuesday, February 3, 2004
CSS is much better than vanilla HTML, but it still sucks. The problem is they both define page layout and not UI. That's great for publishers but god awful for programmers trying to build web apps.
It would be nice if something like XUL was widely supported.
so there
Tuesday, February 3, 2004
"That is my point I think, I am not arguing it's merit, only stating that like it's bastard cousin SMTP we are stuck with it, and in both cases, there isn't a viable alternative on the horizon."
hence my "my god, let the sdding thing die" rant. <g> Id hardly feel so strongly about it if there was no need for me to use it anymore.
FullNameRequired
Tuesday, February 3, 2004
I must be the only developer here who actually likes HTML. It's easy to learn in an afternoon, an open standard, lightweight, plain text readable, easy to parse, and contains just enough form controls to cover 90% of what most applications do.
Matthew Lock
Tuesday, February 3, 2004
I also the the irony of you guys complaining about HTML on a forum built on HTML and the web.
Matthew Lock
Tuesday, February 3, 2004
"easy to parse"
Spoken like a person who's never had to parse arbitrary HTML.
Brad Wilson (dotnetguy.techieswithcats.com)
Tuesday, February 3, 2004
Nowadays, most mainstream browsers support some kind of XML embedding into HTML, with javascript controls for layout of the content. The bad side of it is that this is a solution available only to developers, not casual bloggers and two-people retail stores that want a web page.
In my mind, there aren't many changes or improvements to the current version / syntax / flavor of HTML. I would hate to see it "evolving" into some complex, hard to read format that only tools, not editors, would be able to create.
But I absolutely believe there should be an easier and more intelligent way to handle forms...
Dario Vasconcelos
Tuesday, February 3, 2004
"I must be the only developer here who actually likes HTML"
LOL..from this I deduce that you dont have a huge amount of experience in using it to do anything at all complex.
Its _fine_ if all you want to do is display nicely formatted text in a random browse. Thats what it was designed to do, and its perfectly fine for doing that.
But you just try and do anything more advanced...or take that html and parse it into anything useful....its a hideous abortion of a 'language' which needs to die as soon as possible.
FullNameRequired
Tuesday, February 3, 2004
+1 one vote for HTML. I've been using it for five years, and I find it more than satisfactory for its purposes. The problem most of you seem to have is the failure to understand that it's NOT a programming language. It's a language that describes structure of data.
For doing "anything more advanced" with HTML documents, get a clue what DOM is, and use language of your choice with it.
Egor
Tuesday, February 3, 2004
> LOL..from this I deduce that you dont have a huge amount
> of experience in using it to do anything at all complex.
How patronising, I have worked with HTML for 7 years. What do you find do difficult about it? As for parsing any decent language will have a module which will turn a html document into a tree structure, making it simple to parse.
Can you tell me something that you found was so complex HTML wouldn't fit the bill for?
Matthew Lock
Wednesday, February 4, 2004
LOL! HTML evil... LOL!
It is pretty bad if you can't even deal with html, guys. May I suggest changing jobs? You are upper management material. Two-digit IQs and a whiny attitude is all there is required.
Nicky
Wednesday, February 4, 2004
Hey!
I never said I cant deal with it. I just dont like doing it. Because it sucks. Dont try to spin it....
Eric DeBois
Wednesday, February 4, 2004
The original question:
"Does anyone foresee HTML becoming more object-oriented (so you could define an event handler once for all of the radio buttons in a group as opposed to setting it up for each one), or am I on crack?"
Yes, you are on crack, but for a different reason. This technology already exists, and has for atleast four years. Behold:
<script language="javascript">
function sigh() {
alert(":: sigh ::");
}
</script>
<div onclick="sigh()">
<input type="radio" name="barney">
<input type="radio" name="barney">
</div>
"Does anyone foresee HTML becoming more object-oriented (so you could define an event handler once for all of the radio buttons in a group as opposed to setting it up for each one), or am I on crack?"
Totally agree. I love HTML for what it does (great for blogging!). But it simply wasn't designed for UIs. If you follow the CSS groups, you'll see that CSS wasn't either. For instance, the CSS float declaration wasn't meant to provide column support, but that is how it's widely used. It's just another hack.
XUL would have been an incredibly rad technology for web applications if it had caught on beyond Mozilla. You can almost pull it off today with the ActiveX Mozilla plugin, but this means users have to have ActiveX enabled and have or download mozilla.
I know some DHTML groups were trying to emulate XUL in IE, but there is just so much in it that I think they ran out of steam. Instead of complaining, why not put that energy to use and jump in and help?
Aaron Boodman
Wednesday, February 4, 2004
Ah damn. I guess I missed the ctrl+c on that second quote. I was trying to quote the HTML+CSS not so good, but XUL rox0rs the hizou comment.
Aaron Boodman
Wednesday, February 4, 2004
"Yes, you are on crack, but for a different reason. This technology already exists, and has for atleast four years. Behold:
<script language="javascript">
function sigh() {
alert(":: sigh ::");
}
</script>
<div onclick="sigh()">
<input type="radio" name="barney">
<input type="radio" name="barney">
</div>"
QUESTION:
But what if I need to pass the form element itself to the JavaScript function as an input parameter, so I can do something with the form element, like uncheck it?
Anonymous Developer
Wednesday, February 4, 2004
As for the HTML / shopping cart remark...
So would you like to have to download a new .exe for each retailer you want to purchase something from? And if there is no HTML/HTTP, do you want them to email you the .exe? How about they email you a text file with their product catalog, you edit it and put 'XXX' next to the products you want, print it out and the mail it in?
Seesh...
GuyIncognito
Wednesday, February 4, 2004
See, you're looking at HTML the wrong way.
Y'all are saying, "HTML is bad for webapps because it doesn't let me do what I want to do. XUL rocks because I can completely change the UI."
You know what? The users have spoken. They like HTML. Live with it. They like that developers are constrained in their UI choices (ugly JS hacks notwithstanding). Users don't like having to figure out what a new button does.
HTML isn't good for writing a Word processor or anything that *actually* requires a complex UI. It is great for things like shopping carts. The proof is in the pudding. It's not perfect, but it has plenty of room to evolve without being replaced. You guys read JoS, you should know this.
Richard P
Wednesday, February 4, 2004
"QUESTION:
But what if I need to pass the form element itself to the JavaScript function as an input parameter, so I can do something with the form element, like uncheck it? "
<div onclick="sigh(e)">
...
function sigh(e) {
var srcEl = e.target ? e.target : window.event.srcElement;
...
}
There are a lot of different ways to do this. This is the answer which seems closest to your original question.
Aaron Boodman
Wednesday, February 4, 2004
"How patronising, I have worked with HTML for 7 years. "
7 years? and you still _like_ using it? wow...
"What do you find do difficult about it?"
<g> making complex things work in different browsers isn't always easy, but overall I dont find much difficult about it at all...html itself is a very simple layout language, prolly one of the _most_ simple minded on the block.
Things get more complex once you begin using css and js in combination with html of course, but theres nothing ingerently difficult about that either (aside from the whole xplat testing/debugging/fixing PITA for different browsers, and thats not so much hard as it is excruciatingly dull)
Things can get even more complex once you start using cgi to create custom css/js/html pages depending on input, but still its not actually _hard_ so much as it is frustrating (because html is such a limited language) and boring.
so, generally speaking, I dont find anything difficult about it, I just find it limiting, tedious and therefore frustrating.
<g> oh, another part I specially enjoy is taking code generated by graphic or web designers in various html designer programmers (flash, dreamweaver, frontpage etc etc); where they've used the program the same way they would use photoshop or freehand; and taking out all the superfluous tables, divs, font tags, etc etc etc
theres a good way to describe that process as well <g> boring, tedious, frustrating and annoying...
"As for parsing any decent language will have a module which will turn a html document into a tree structure, making it simple to parse."
assuming that the html document follows all standards, which is astonishingly rare...very often the process of making html work in the selected browsers forces the careful ignoring of selected standards..
"Can you tell me something that you found was so complex HTML wouldn't fit the bill for? "
LOL. HTML doesn't fit the bill for _anything_ complex....you can _use it_ for complex things, but its not a 'good' solution its a 'fucking awful' solution.
Right off the bat it breaks because you cannot track session use reliably or simply with html, every single 'webapp' that does so is using a delicate, unreliable solution...thats the only kind of solution that html provides to complex problems.
and lets not even go into the problems that crop up with site maintenance...thats been much improved by css of course but its still a fair way from being ideal.
Im not arguing that you _cant_ create complex solutions in html, Ive done so repeatedly. Im arguing its a _bad_ tool for doing so...it also happens to (currently) be the _best_ tool for doing so, but that doesn't make it a _good_ tool, its not. its a terrible tool for creating complex web apps.
I had vaguely assumed that everyone knew this...certainly every developer I talk with in 'real life' is entirely aware of the huge issues and drawbacks of html.....amazing what you find on web forums I think :)
oh! I bet your not a programmer per se...I bet you are a web designer and so have never used anything except html and possible a little bit of css and javascript....that can give you a rather skewed view of the virtues of html.
if thats the case, take my word for it...html is terrible tool to use for anything more complex than basic text layout :)
(it is also the best tool to use for web apps at the moment, but as I said earlier that doesn't unfortunately make it a good tool in its own right)
FullNameRequired
Monday, February 9, 2004
 Recent Topics
Fog Creek Home
| 
