●Stories
●Firehose
●All
●Popular
●Polls
●Software
●Thought Leadership
Submit
●
Login
●or
●
Sign up
●Topics:
●Devices
●Build
●Entertainment
●Technology
●Open Source
●Science
●YRO
●Follow us:
●RSS
●Facebook
●LinkedIn
●Twitter
●
Youtube
●
Mastodon
●Bluesky
Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!
Forgot your password?
Close
This discussion has been archived.
No new comments can be posted.
Load 500 More Comments
Full
Abbreviated
Hidden
/Sea
Score:
5
4
3
2
1
0
-1
More
Login
Forgot your password?
Close
Close
Log In/Create an Account
●
All
●
Insightful
●
Informative
●
Interesting
●
Funny
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
byAnimats ( 122034 ) writes:
What we really need in HTML standarization:
●
Valid XML, all the time. Require that the tags balance, as in XHTML. This will make the document tree well-defined, which, at the moment, it is not. So all software that works on the DOM will behave consistently.
●
Errors put the browser in "dumb rendering" mode. Rather than a "best effort" approach, browsers should, upon detecting a serious error in the input, drop to "dumb mode" - default font, default colors, etc., after displaying an error message. Much of
byPhroggy ( 441 ) writes:
Valid XML, all the time. Require that the tags balance, as in XHTML. This will make the document tree well-defined, which, at the moment, it is not. So all software that works on the DOM will behave consistently.
You're wrong. The document tree is well-defined in HTML 5. You don't need XML, you just need to follow the HTML spec. Of course, we can't force people to follow the spec, and the Web is currently full of non-conforming pages that include half-assed attempts at using bits and pieces of XHTML mixed with HTML. XHTML doesn't make anything better.
Errors put the browser in "dumb rendering" mode. Rather than a "best effort" approach, browsers should, upon detecting a serious error in the input, drop to "dumb mode" - default font, default colors, etc., after displaying an error message. Much of the incompatibility between browsers comes from inconsistent handling of bad HTML. So there should be a penalty, but not a fatal one, for bad code.
You're wrong. If your browser does this, users will use some other browser (regardless of whether it conforms to the HTML5 spec or not, because users don't care about that). You're right that broken code is a problem, but HTML5 addresses this by more clearly defining how broken code should be handled, so that all browsers can try to render even bad code in a consistent and compatible way.
No more upper code pages. The only valid character sets should be Unicode, or ASCII with HTML escapes. Chars above 127 in ASCII mode are to be rendered as a black dot or square. No more "Latin-1", or the pre-Unicode encodings of Han or Korean. So all pages will render in all browsers, provided only that they have some full Unicode font.
You're wrong. If you make a browser that doesn't support these other character sets, users will choose something else (see above). Of course everybody should be using UTF-8 these days, but we can't force them to.
Downloadable fonts. Netscape used to have downloadable fonts. The font makers bitched. Bring that feature back, despite the whining. No more having to express fonts as images.
It's back [alistapart.com], but in CSS, not HTML.
WebForms. Get the WebForms proposal back on track. Any needed processing for input should be do-able without Javascript.
HTML5 includes Web Forms 2.
2D layout The "div"/"clear" model of layout was a flop. Horrors of Javascript are needed just to make columns balance. Absolute positioning is overused as a workaround for the limits of "div"/"clear". (Text on top of text happens all too often.) Tables were actually a better layout tool, because they're a 2D system. HTML needs a 2D layout model that can't accidentally result in overlaps. There are plenty of those around; most window managers have one. There's been a quiet move back to tables for layout, but people are embarrassed to admit it.
CSS layout has some problems. Balanced columns is certainly one of them (although tables certainly doesn't fix that). They're working on it, but this can be addressed by improving CSS, outside of HTML.
Better parallelism. Pages must do their initial render without "document.write()". Forcing sequentiality during initial page load should be considered an error. This will make pages load faster. Some ad code will have to be rewritten.
I'm not sure what you're talking about exactly, but this sounds like a JavaScript implementation issue and not an HTML issue at all.
Parent
twitter
facebook
bySimetrical ( 1047518 ) writes:
Mod parent up. I have no idea how the grandparent got to +5; his suggestions are all either implemented, unreasonable, or flat-out unimplementable. (No browser vendor can massively break reverse compatibility. Period.)
byindiechild ( 541156 ) writes:
Agreed. The ignorance of some of the +5 modded webdev posts on Slashdot is absolutely astounding. That such incompetent people could be doing web development is horrifying.
And a move back to using tables for layout? I call bullshit. I've seen no such thing. The only people still using tables for layouts (aside from HTML emails) are ignorant and incompetent dolts.
byPhroggy ( 441 ) writes:
Even if the javascript "promised" not to use document.write() somehow, the DOM manipulations may still require redrawing the entire page, in which case the browser may still say "well, we'll wait until the javascript is done, then show the page". There's no solution to this at all, other than to tell people not to use JS to create the whole page.
You can dynamically manipulate the DOM from JavaScript without using document.write at all; for example this page I made [webwizardry.net] generates the entire Search section dynamically. Notice the performance doesn't suck. If you're doing something more complicated than that with your JavaScript, then you're right, there's no solution - the browser can't guess what the results of your JS code is eventually going to be, so it will have to redraw.
All the major browsers are working on improving JS performance. Perhaps that
byblurryrunner ( 524305 ) writes:
While I can understand all your counter points to the GP, it sounds like you are closer to the browser implementation side than the web development side. I'm on the web developer side and I deal mostly with writing web apps. On this side, development is a beast. There have been many improvements and I am grateful for the work that has gone into things, but it's 2009 and we are still writing web apps in a language targeted at documents! It's also sad that I don't see any easy way to make web development easi
byPhroggy ( 441 ) writes:
You're right, of course. HTML5 is an improvement over what we have today, both for documents and for applications. It's not a final solution, but it's a feasible evolution. It's not good, but it's better, and it's possible.
Yes, it will be five years before we can safely count on all of HTML5's features. However, if HTML5 wasn't in development now, then five years from now, we'd still be stuck on HTML 4.01. If we scrap HTML5 now and start designing something better, then in five years, we won't even hav
byblurryrunner ( 524305 ) writes:
I guess my real beef is that I see so much potential in the web platform and the reason that it doesn't advance is because two of the major players have their own competing platforms. Neither Microsoft or Apple have an incentive to make the web platform powerful. Their only motivations are to make sure that the web platform works well enough. If it becomes too powerful, their OS's become irrelevant.
I understand the reasons, but I just cringe at having to keep backward compatibility. It's just really sad
byPhroggy ( 441 ) writes:
I guess my real beef is that I see so much potential in the web platform and the reason that it doesn't advance is because two of the major players have their own competing platforms. Neither Microsoft or Apple have an incentive to make the web platform powerful. Their only motivations are to make sure that the web platform works well enough. If it becomes too powerful, their OS's become irrelevant.
Actually, Apple is sort of in a position where they want the OS to become irrelevant... because the dominant OS isn't theirs. Of course there are limits to this, but they do support cross-platform interoperability to an extent.
I understand the reasons, but I just cringe at having to keep backward compatibility. It's just really sad and depressing that over several years we can only come to a standard that is incrementally better.
Actually what happened was, the W3C was trying to push a standard that nobody wanted to follow. All the browser developers mostly ignored it, until WHATWG was formed, and HTML5 was created outside of the W3C. Finally the W3C realized WHATWG's HTML5 really was the right way to go,
byblurryrunner ( 524305 ) writes:
Thanks I appreciate the insight you shared!
br/
byZearin ( 1315583 ) writes:
I wish Animats' original comment were viable. Truly, I wish we could enforce stricter standards on the web without X browser losing users.
But you're right. :(
I really wish they'd bring back XForms. I haven't read the WebForms spec yet--I'm about to go check it out--but XForms was such beautiful, beautiful stuff. Weird at first, sure, but new technologies often are. Once the weird phase was over, XForms was absolute heaven. Shame it never caught on. Shame XHTML never caught on (or at least, never reach
●ent threshold.
There may be more comments in this discussion. Without JavaScript enabled, you might want to turn on Classic Discussion System in your preferences instead.
Slashdot
●
●
Submit Story
It is much harder to find a job than to keep one.
●FAQ
●Story Archive
●Hall of Fame
●Advertising
●Terms
●Privacy Statement
●About
●Feedback
●Mobile View
●Blog
Do Not Sell or Share My Personal Information
Copyright © 2026 Slashdot Media. All Rights Reserved.
×
Close
Working...
Working...