ie8 fix

Linux and Open Source

Steven J. Vaughan-Nichols & Paula Rooney
Home / News & Blogs / Linux and Open Source

How will HTML 5 change the Web?

By | January 23, 2008, 7:51am PST

Summary: The process, which began back in October 2005, has now reached the point of a public working draft which reveals major changes to how the syntax, the language, and how APIs connect.

HTML illustration from ThinkquestIf 2007 was the year of GPLv3, then 2008 will be the year of HTML 5. (Picture from ThinkQuest.)

Just as we spent much of last year debating the revision of our most popular open source license, we’re invited to spend this year having similar discussions around HTML.

The W3C is now seeking public comment on a major update to HTML, the HyperText Markup Language which translates what I’ve typed into what you see through your browser.

The process, which began back in October 2005, has now reached the point of a public working draft which reveals major changes to the syntax, the language, and how APIs connect.

The aim is to standardize how improvements to Web pages work, which should cut software development costs. The result should be backward-compatible to older versions. Your future browser should read older Web pages fine.

Reaction among those who have worked on the draft is relief. “It took several years and will take some more, but we’re making progress,” writes Anne Van Kesteren, who works on Opera as well as Web standards.

In my humble opinion, the current draft is excellent work. New features like the dialog tag, the creation of new area elements, and the XML compatible syntax are all good news.

The other important point about standardization is it will bring browsers together in some ways. Pages will display similarly regardless of which brand of software you use. As someone who creates content I find this a very good thing indeed.

But take a look and let me know what I’ve missed.

Kick off your day with ZDNet's daily e-mail newsletter. It's the freshest tech news and opinion, served hot. Get it.

More from “Linux and Open Source”

Topics

Web, HTML, W3C, Web Browser, Dana Blankenhorn

Dana Blankenhorn has been a business journalist for 30 years, a tech freelancer since 1983.

Disclosure

Dana Blankenhorn

Dana Blankenhorn has been a journalist, writer and part-time futurist for over 30 years.

At the present moment I run only a personal blog in addition to my ZDNet open source blog.

DanaBlankenhorn.Com has the subtitle The War Against Oil. In the past I have used it to write about political history, e-commerce, personal matters, some ideas related to open source, and The World of Always On, which is the idea of using sensors, motes and RFID to turn WiFi links into platforms for applications which live in the air.

My IRA account at Schwab holds a few tech shares, most notably some Intel and Applied Materials, but there are no open source companies in it. I don’t even own any CBS stock.

Biography

Dana Blankenhorn

Dana Blankenhorn has been a business journalist for nearly 25 years and has covered the online world professionally since 1985. He founded the Interactive Age Daily for CMP Media, and has written for the Chicago Tribune, Advertising Age's "NetMarketing" supplement, and dozens of other publications over the years.

Related Discussions on TechRepublic

Did you know you can take part in these discussions with your ZDNet membership?
Ask a Question Start a Discussion
31
Comments
Add Your Opinion

Join the conversation!

Just In

Just embaressing yourself
jackbond 5th Feb 2008
Let me just preface this by saying this: I could take a monkey, smash it's ******* brains in, and it would still be more intelligent than you. That said, let's go.

Here's the standard, http://www.w3.org/html/wg/html5/

You say:

"Oh? if I read the spec well, it's a DOM extension. It appears NOWHERE in the HTML 5 syntax - it is, absolutely, nothing more than an extension to the HTMLDocument!"

You continue to treat HTML and the DOM as if they are two entirely separate things, they are not, here's the first line of section 2,

"The Document Object Model (DOM) is a representation ? a model ? of a document and its content. [DOM3CORE] The DOM is not just an API; the conformance criteria of HTML implementations are defined, in this specification, in terms of operations on the DOM."

There they said it right there in the hope that clueless morons such as yourself could understand. In order to conform to HTML 5, an implementer MUST support the activeElement call properly. You don't implement activeElement properly, you're not HTML 5.

You state,

"So, the addition makes sense. Now please, where does it show up in HTML?"

You continue to show your complete ignorance of what the HTML standard is. HTML the standard does not end with what comes between the and tags, it includes defining the DOM. Have you read the standard? Look at how much time they spend talking about the DOM. Why do they do that? Because it's the heart of HTML 5.

You say,

"How can you implement this, as there is currently no 100% sure way to use TCP/IP and obtain a sustained, ordered communication mode?"

So now you demonstrate that you have NO clue about how AJAX and web services work? Have you ever used either you clueless ****? If I could get a file's bytes, I could make a series of service calls, and upload X number of bytes at a time. You don't need a friggin sustained operation at all. Further, how do you think the existing file uploads are implemented? Here's a clue, via a POST operation. No need to redefine TCP/IP.

One more point on this:

"How can you implement this, as there is currently no 100% sure way to use TCP/IP and obtain a sustained, ordered communication mode?"

Oh really, what do you think sockets are? Now you've demonstrated that you have no clue how the internet works. I have a nice VOIP phone right next to me. Sure the traffic is broken into individual packets, but TCP specifically provides sustained communication(even has error correction), although for the purpose of file uploads, this is both unneccessary and irrelevant. But there's no reason not to repeatedly point out how much of a ******* moron you are.

You say:

"But then, we do hit the real problem: it's not an HTML element you need, it's a transfer protocol that implements transfer rate control! Thing is, currently HTML browsers deal with http://, and add file://, http:// (and in some cases, torrent://) support but none of these protocols natively implement anything looking like transfer control method. And anyway, as soon as it's out of http://'s hands, it's irrelevant to HTML."

So you are telling me that I need a new transfer protocal to upload a file? Well I didn't think it was possible, but you've demonstrated the depths of your stupidity even further. What do you think HTTP is, it IS a transfer protocal. How do you think existing file uploads work??? Here's a deal, I'll make you a bet. If I can upload a file, via HTTP, and not using will you throw yourself off a bridge? Now this is clearly outside the scope of HTML 5, but you seem to be indicating that HTTP can only transfer HTML data? Is that what you are saying? Do you accept my bet? If I lose, I'll throw myself off a bridge, you can pick which one.

Do yourself a favor, re-read this again and again until you actually understand what the HTML 5 spec really is. Here it is again for ya:

"The Document Object Model (DOM) is a representation ? a model ? of a document and its content. [DOM3CORE] The DOM is not just an API; the conformance criteria of HTML implementations are defined, in this specification, in terms of operations on the DOM."

Do you get it yet moron? Here it is again:

"The Document Object Model (DOM) is a representation ? a model ? of a document and its content. [DOM3CORE] The DOM is not just an API; the conformance criteria of HTML implementations are defined, in this specification, in terms of operations on the DOM."

The HTML 5 spec defines the markup language(which is where you think HTML ends) AND the HTML DOM. I want them to add something to the DOM, something that would be trivially easy to do. The fact that there are over 500 people on that ******* committee just goes to show what a joke it is. Put 500 engineers in a room and see the progress they make.

BTW, did you see this:

"The Document Object Model (DOM) is a representation ? a model ? of a document and its content. [DOM3CORE] The DOM is not just an API; the conformance criteria of HTML implementations are defined, in this specification, in terms of operations on the DOM."

Do you get it yet, that's straight from the spec? If you want to be compliant with HTML 5, you need to fully support the DOM outlined in that doc. So, you clueless ******* brain dead monkey, is it sinking in yet? Through your series of responses, you've demostrated that you have NO clue regarding the following:

HTML - markup AND DOM
Javascript
TCP/IP
AJAX
Web Services
HTTP
View in thread
0 Votes
+ -
Not quite so
AbbydonKrafts 23rd Jan 2008
Pages will display similarly regardless of which brand of software you use.

That's only true if the makers implement 100% of the specification. The problem has always been incomplete implementation, which resulted in hacks and work-arounds. Obviously Microsoft is guilty of this the most. It took them until IE7 to get with the program. That was so late that most websites already use broken IE workarounds that cause compliant browsers, such as Opera 9 (which I use), to render the pages incorrectly. I frequently get messages telling me to upgrade my browser.

As long as the browser developers keep up with the specs, both HTML and CSS, I'm all for new versions. It gives web developers more to work with. I still remember being thrilled with CSS2 implementation. If only CSS3 would come around with full browser support. Web-based software will never compete with a desktop client until it can provide the same rich experience. The only way to do this is to keep improving the standards and have browsers that implement them 100%.
0 Votes
+ -
Standards or We Hat Microsoft
Richard B 23rd Jan 2008
If this is truly ads value then I all for HTML 5. The problem I have is this standards battle is that standards are nothng more that W3C trying to act important or we hate Microsoft the any so called improvement deserves to fail.
0 Votes
+ -
Well, obviously, MS will do anything they can to prevent good
DonnieBoy 23rd Jan 2008
interoperability. If they can keep a lot sites that only display/work correctly with Windows/IE, they will. But, as the percentage of Safari and FireFox users goes up, they will gradually do a better job of supporting standards. They will be able to slow down the new spec, but not stop it.
0 Votes
+ -
Agreed, and it is up to us to spped things up.
emilp 23rd Jan 2008
I.e. to make sure that these IE only web sites get to understand that they are loosing customers (which in most cases means money) simply because potential customers can not use their site.
I have sent email to a couple of sites informing them about the problem, in many cases with litle or no response. Why? Because one lost customer is not worth the trouble. If that 1 would instead be 5% or so, I think we would see a lot quicker move to standard compliant browsers which with a litle care even MS IE should be able to use.
0 Votes
+ -
You'd probably
Blogsworth 23rd Jan 2008
You'd probably go into McDonalds and tell them if they don't change the menu, you personally will stop eating there. Good luck with that one too....
Remember the customer isn't always right, some of the time he's just an a**h***
0 Votes
+ -
Not likely.
emilp 23rd Jan 2008
At least not unless they mess up the meny bad enough not to be readable, with no-one to ask about it. That is the case with (realy) badly designed web pages -- a real world example is a computer store whose page failed to present the menu of things to buy.

You're right in that customers isn't always right, but it is still their money to spend where ever they like. If you try to sell something, you most likely would prefer them spent in your shop.
0 Votes
+ -
Standards
bhartman33@... 23rd Jan 2008
You'd probably go into McDonalds and tell them if they don't change the menu, you personally will stop eating there. Good luck with that one too...

This is about a lot more than changing the content of pages. The layout of pages determines whether or not they'll be usable.

I'm in a wheelchair. If some business has a flight of steps on the entrance to their building, it doesn't just offend me. It keeps me out. That's the situation you're faced with with a lot of IE-only pages: Either the layout of those pages makes them unusable, or even worse, they throw up some "You're not using IE. Go away!" kind of message.

There's a difference between not tailoring your site to individual users on aesthetic grounds, and telling a whole swath of users they can go f*** themselves.
0 Votes
+ -
In any regard, these compatibility problems benifit Microsoft and keep
DonnieBoy 23rd Jan 2008
people from switching to alternative browsers that are better.

And, it is not that the people do not like the menu, it is that they are not allowed in because they are not driving a Chevy.
0 Votes
+ -
Evil Empire
Blogsworth 23rd Jan 2008
Still saying that Microsoft is the evil empire? Look around you can't see the wood for the trees. Apple and Google are just as bad in their own ways.
0 Votes
+ -
There is a difference...
McNee 23rd Jan 2008
between pointing out that MS is the least compliant when it comes to W3 standards and going on a witch hunt.

And there is a difference between going to McDonalds and demanding they change the menu "just because" you don't like it, and pointing out that the fact they have a menu that's so difficult to read that you won't be eating there.
0 Votes
+ -
HAHAHAHAHHA
powershaker 23rd Jan 2008
I guess ya'll are still thinking Apple is as bad as Microsoft. Yeah, right. You don't see Apple stealing ideas from other operating systems. It looks Apple is always the one to invent the idea, and then little Gates follows behind. Such as the spotlight in Vista even though it's on the left and not the right? Oh! I loved it when the report interviewing Bill Gates over Vista said: "Frankly, I don't see anything Vista has that Apple hasn't had for awhile now.
0 Votes
+ -
One Word: PARC
jgwinner 24th Jan 2008
>>You don't see Apple stealing ideas from other operating systems.

Yes they do. One Word: PARC
0 Votes
+ -
Thank you!
ryumaou@... 25th Jan 2008
Thank God someone remembers their computer history! Virtually all the good things in Mac started at PARC, just as virtually all the good things in Windows started at Apple. The rest is just marketing.
0 Votes
+ -
Misguided
Fred Fredrickson 25th Jan 2008
Xerox PARC did not invent the graphical user interface (GUI) or the mouse as some
seem to think, although they did some great work on improving their usefulness.

see "History of the graphical user interface", wikipedia
http://en.wikipedia.org/wiki/History_of_the_graphical_user_interface

Nor did Apple "steal" Xerox's GUI - Apple representatives were invited to PARC, as
were Microsoft's (and probably lots of others). The Mac interface the evolved from
that is very different to the one that was demonstrated, to say it was a straight rip-
of does the hard working developers a great injustice. Note the differences
between early Windows and Mac interfaces - the Mac was terrific for ease of use,
Windows was almost unusable.

Both Apple and Microsoft have contributed far more to the IT industry than GUI
refinement.
0 Votes
+ -
Idiotic post
Fred Fredrickson 25th Jan 2008
Microsoft had 4 representatives on the committee that wrote the HTML 5 specification,
including the chair, so it's a bit rich to characterize it as a an anti-Microsoft
document.

0 Votes
+ -
I'm waiting for CSS 3
CobraA1 23rd Jan 2008
Forget HTML 5, I want better progress on CSS 3. Unfortunately, it's been set back a lot - a lot of stuff that used to be "last call" is now "working draft" and it appears most of the stuff is stuck there indefinitely. Apparently "last call" doesn't really mean last call. It just means they're pretending to make progress.

Seriously, what do these people do all day? Just quibble on details, as far as I can tell. I'd really like to see CSS 3 become a recommendation within my lifetime.
0 Votes
+ -
I'd be happy with wider adoption of CSS2...
bhartman33@... 23rd Jan 2008
CSS3 would be nice, but everyone needs to get on board with at least CSS2 first. Firefox doesn't yet support text-shadow, and from what I've seen, absolute positioning will give you different results in different browsers with the same values.
0 Votes
+ -
It's getting better
CobraA1 23rd Jan 2008
I agree. CSS2 should be better supported.

But we are making progress in that area - IE7 was a great step forward for Microsoft, and IE8 looks like it will be another big step. I'm hoping they can continue the trend.

Text shadows aren't really all that important, but absolute positioning is - and quite frankly it's the worst in IE6, which is creating a lot of headaches as long as a large percentage of people keep using it. I really wish everybody would upgrade to IE7 or Firefox.

Unfortunately, as long as people cling to IE6, wider adoption of CSS2 is not going to happen sad. I think that's holding back a lot of websites from being able to use the full potential CSS2 has.
0 Votes
+ -
CSS2
bhartman33@... 24th Jan 2008
I agree that text-shadow isn't all that important. It's just a cool effect. I use it on my personal page (in the header) and it's a pain in the neck to implement it in a cross-browser kind of way. But yeah, that's just my pet peeve... wink

I think the outlook for IE7 and Firefox is better than you think it is. People are going to have to move off of Win2K eventually. IE6 is basically old as dirt, and it's time for people to move on. XP and Vista (but mostly XP, for now) will make it happen.

It drives me absolutely nuts that I have to have browser detection in my page, and dynamically write code, depending on what browser people are using. It's not like CSS2 is some new-fangled thing. It's been around since at least 2003, from what I've been able to find out online.

(Interestingly, I can't find any reference to text-shadow in CSS3, so maybe it's being phased out.)

CCS3 Font Specs
0 Votes
+ -
Sorry. Link problem!
bhartman33@... 24th Jan 2008
For some reason, it didn't post the link correctly. Here it is:

http://www.w3.org/TR/css3-fonts/
0 Votes
+ -
Will it automatically sweep the net
Boot_Agnostic 23rd Jan 2008
and upgrade all the html 3. sites out there and smack xhtml in the head along the way?
0 Votes
+ -
HTML 5 and XML
CobraA1 23rd Jan 2008
Actually, HTML 5 is a form of XML. In fact, the specifications specify both HTML and XML (XHTML) forms of HTML 5 - with the differences between the two essentially being changes in the first two lines of code on a web page.

But yes, you do have a point out there about the pages still using older HTML. Unfortunately, there's not much anybody can ever do about a web page that stops being maintained. In fact, if you're still visiting unmaintained web pages, I suggest you download them and archive them, as pages that aren't maintained anymore tend to disappear off the Internet.
0 Votes
+ -
HTML 5 = TOTAL JOKE
jackbond 23rd Jan 2008
I read the HTML differences page. It took them 3 years to put that together. Who are they? A bunch of people who started with an IQ of 85, and then had a hammer slammed into their foreheads? How about something that would allow AJAX uploads? Oh but wait, they did some spiffy work on that "dialog" tag? Who the hell needs that? Why not use the dialog keyword for something useful, like actual dialogs? Enough with the moronic semitransparent divs. How about a real rich text box? Great work guys. Design by commitee = worthless ****.
0 Votes
+ -
jackbond = total ignorance
Mitch 74 25th Jan 2008
AJAX has little, if anything at all, to see with HTML (any version). AJAX is Asynchronous Javascript And XML - read that more closely: it's Javascript and XML.
As a matter of fact, due to the syntax used in HTML 5 being compatible with XML syntax (I get it's closer to XHTML 1.0 Strict than HTML 4.01 Strict), it makes using AJAX easier due to a more 'XML-like' Document Object Model.
I guess you're looking for tags like MARQUEE, that create actions through HTML. Guess what? it was found out that such tags are HARMFUL to HTML: HTML, as its name implies, is a MARKUP language - it's used to give signification to elements it contains, not program their actions. That, is the function of Javascript - ACT on those objects. The DOM is built from the HTML, modified through Javascript, and styled with CSS.

HTML 5, building upon HTML 4.01 Strict and XHTML 1.0 Strict, is intended at allowing better DOM manipulations - right now, there are disparities from one browser to the other. In order for a browser to be HTML 5.0 compatible, it will have to implement a precise DOM model (on par with current DOM level 2 pecifications, and some of DOM 3).
Guess what? The latter allows integrity checking and dynamic debugging! You won't have to build safeguards all over the place to prevent the browser from hanging due to heavy Javascript!

If you think HTML 5 is worthless for AJAX programming, then you obviously don't program 'low-level' AJAX.

Go back to your DHTML and VBscript editor.
0 Votes
+ -
Mitch 74 = Dumb Piece of Moronic Filth
jackbond 26th Jan 2008
Ok Moron, the following is HTML right?



Yes. Well that friggin bit of the HTML is useless for letting me control the upload process via javascript. I can't get a handle to a stream to read, manipuloate, upload, whatever. Consequently, I can't do an upload in an AJAX fashion. What they could have done was given us this:



Hell, they didn't even need to add file2, they could have just added some decent methods to input type file. But NO, what did they add Gee thanks guys, useful, but tons of work arounds for that already.

And another thing you brain dead monkey, I didn't say HTML 5 was worthless for AJAX programming, I said, after 3 years, they could have come up with some significantly more useful stuff, like a useful file input type OR a rich text box.

It's what I love about you Mozilla/Firefox/I love Web Committee/Open Source loving scum bags. You sit around doing work for 5 years, that's worthless, doesn't help anybody, and you pat yourselves on your backs like you've cured cancer. What's really comical is that a bunch of stuff that's "New" in HTML5 already exists in IE6, yah IE SIX, but the open source filth scoffed at because it wasn't a standard.

Try again moron, then again, don't bother. You've already demonstrated your pathetic brain can't parse the English language.
0 Votes
+ -
your personal itch, and you don't even get it!
Mitch 74 28th Jan 2008
As I said, HTML 5 is a MARKUP LANGUAGE. The 'input' tag allows one to DEFINE the location of a file to transfert - not HOW it will be transferred, and not the file itself.

If you want to control the file's transfert method, then you must create a DOM object that represents the file itself (and NOT its location, see the nuance?), an then specify its transfert method.

Right now, we're outside of HTML; the file you want to transfert is not part of the document, since by definition the HTML document ends at the end of the HTML document file.

You want to implement a control rate property to the 'file' or 'stream' objects in Javascript? Port it to the ECMAScript 4 working group - if it doesn't exist already.

The DHTML idea that the document includes whatever external object it references, and should define its properties directly in the HTML tag, has been abandoned for a long time - even at Microsoft - because the W3C's idea, to split the Web into separate markup, presentation and action languages were recognized by many to be more flexible than 'stuff it all in a single file, and let bugs sort them out'.
0 Votes
+ -
Mitch = Dumber and Dumber and Dumber
jackbond 28th Jan 2008
My god are you just plain ******* stupid. Have you read the doc? (probably above your reading level) Here's a link, http://www.w3.org/TR/2008/WD-html5-diff-20080122/#htmldocument-extensions Look there in section 4, what do you see? Hello, it's new APIs. Wow, check it out, HTMLDocument has picked up activeElement (only been in IE for I dunno how long) But wait, that isn't HTML, that's a new DOM element. But you said, "HTML 5 is a markup language", and "Right now, we're outside of HTML" So that leaves us with 2 options, the HTML5 doc includes things that aren't necessarily HTML, or you're a ******* moron. So please explain to me, if they can add activeElement to HTMLDocument, why couldn't they have added:

bool fileSelected
byte [] getFileBytes(int count)

to the input type file object? And 1 more thing there moron, yes, HTML is a markup language, but it is also DOM initialization language. HTML is a set of instructions for browsers on how to build the DOM, so to treat them as 2 entirely unrelated things is ridiculous. So you're "Port it to the ECMAScript 4 working group" statement is just naive. Their response would be, "what can we do, it isn't in the HTML DOM." I'd talk to them if I wanted enhancements to the scripting language, NOT the objects manipulated by the language.
0 Votes
+ -
Perfect....
kingmph@... 29th Jan 2008
10/10 on this one.

This is the first time in a very long time I've seen obvious flame-bait backed up by an actual well-thought-out, organized, and logical response.
0 Votes
+ -
OK, I'm citing you - and mark my words!
Mitch 74 5th Feb 2008
"Wow, check it out, HTMLDocument has picked up activeElement (only been in IE for I dunno how long)"

Oh? if I read the spec well, it's a DOM extension. It appears NOWHERE in the HTML 5 syntax - it is, absolutely, nothing more than an extension to the HTMLDocument! You want to support it in HTML 4 with valid markup? prototype document.activeElement() = function (){/* pseudocode returning element that currently has focus, varies from browser to browser */}

That's it - it can be used in an HTML 4 document without any problem, the document will remain Valid HTML 4.

So, the addition makes sense. Now please, where does it show up in HTML? What does it have in common with, say, MARQUEE? can you use it as ? No?

Then it hasn't been added to HTML 5 syntax (it doesn't show up in the HTML document, only in Javascript imports or CDATA sections) like you want to add a controlRate attribute to the INPUT tag. It has been added to the DOM HTMLDocument prototype object - we're well into the scope of a programming language, and out of pure markup.

If you meant 'adding a controlRate attribute to the DOM "input" prototype object, in case it is of the "file" type', then all right - it could be spec'ed.

Now please, considering the way a web page can be accessed, how will you document the property? How can you implement this, as there is currently no 100% sure way to use TCP/IP and obtain a sustained, ordered communication mode? Should the HTML WG redefine TCP/IP? And before you implement rate control, you may want to specify a protocol - I'm not sure either GET or POST (as an input must be in a form) do the trick.

But then, we do hit the real problem: it's not an HTML element you need, it's a transfer protocol that implements transfer rate control! Thing is, currently HTML browsers deal with http://, and add file://, http:// (and in some cases, torrent://) support but none of these protocols natively implement anything looking like transfer control method. And anyway, as soon as it's out of http://'s hands, it's irrelevant to HTML.

The feature you asked for inclusion is, as such, really mistargeted. And you can insult me as much as you want, it doesn't change the fact that you moan about it and yet I haven't seen you on the W3C mailing lists.

Neither am I (not recently), but I don't ask for features - I only report bugs or ask for explanations.
0 Votes
+ -
Just embaressing yourself
jackbond 5th Feb 2008
Let me just preface this by saying this: I could take a monkey, smash it's ******* brains in, and it would still be more intelligent than you. That said, let's go.

Here's the standard, http://www.w3.org/html/wg/html5/

You say:

"Oh? if I read the spec well, it's a DOM extension. It appears NOWHERE in the HTML 5 syntax - it is, absolutely, nothing more than an extension to the HTMLDocument!"

You continue to treat HTML and the DOM as if they are two entirely separate things, they are not, here's the first line of section 2,

"The Document Object Model (DOM) is a representation ? a model ? of a document and its content. [DOM3CORE] The DOM is not just an API; the conformance criteria of HTML implementations are defined, in this specification, in terms of operations on the DOM."

There they said it right there in the hope that clueless morons such as yourself could understand. In order to conform to HTML 5, an implementer MUST support the activeElement call properly. You don't implement activeElement properly, you're not HTML 5.

You state,

"So, the addition makes sense. Now please, where does it show up in HTML?"

You continue to show your complete ignorance of what the HTML standard is. HTML the standard does not end with what comes between the and tags, it includes defining the DOM. Have you read the standard? Look at how much time they spend talking about the DOM. Why do they do that? Because it's the heart of HTML 5.

You say,

"How can you implement this, as there is currently no 100% sure way to use TCP/IP and obtain a sustained, ordered communication mode?"

So now you demonstrate that you have NO clue about how AJAX and web services work? Have you ever used either you clueless ****? If I could get a file's bytes, I could make a series of service calls, and upload X number of bytes at a time. You don't need a friggin sustained operation at all. Further, how do you think the existing file uploads are implemented? Here's a clue, via a POST operation. No need to redefine TCP/IP.

One more point on this:

"How can you implement this, as there is currently no 100% sure way to use TCP/IP and obtain a sustained, ordered communication mode?"

Oh really, what do you think sockets are? Now you've demonstrated that you have no clue how the internet works. I have a nice VOIP phone right next to me. Sure the traffic is broken into individual packets, but TCP specifically provides sustained communication(even has error correction), although for the purpose of file uploads, this is both unneccessary and irrelevant. But there's no reason not to repeatedly point out how much of a ******* moron you are.

You say:

"But then, we do hit the real problem: it's not an HTML element you need, it's a transfer protocol that implements transfer rate control! Thing is, currently HTML browsers deal with http://, and add file://, http:// (and in some cases, torrent://) support but none of these protocols natively implement anything looking like transfer control method. And anyway, as soon as it's out of http://'s hands, it's irrelevant to HTML."

So you are telling me that I need a new transfer protocal to upload a file? Well I didn't think it was possible, but you've demonstrated the depths of your stupidity even further. What do you think HTTP is, it IS a transfer protocal. How do you think existing file uploads work??? Here's a deal, I'll make you a bet. If I can upload a file, via HTTP, and not using will you throw yourself off a bridge? Now this is clearly outside the scope of HTML 5, but you seem to be indicating that HTTP can only transfer HTML data? Is that what you are saying? Do you accept my bet? If I lose, I'll throw myself off a bridge, you can pick which one.

Do yourself a favor, re-read this again and again until you actually understand what the HTML 5 spec really is. Here it is again for ya:

"The Document Object Model (DOM) is a representation ? a model ? of a document and its content. [DOM3CORE] The DOM is not just an API; the conformance criteria of HTML implementations are defined, in this specification, in terms of operations on the DOM."

Do you get it yet moron? Here it is again:

"The Document Object Model (DOM) is a representation ? a model ? of a document and its content. [DOM3CORE] The DOM is not just an API; the conformance criteria of HTML implementations are defined, in this specification, in terms of operations on the DOM."

The HTML 5 spec defines the markup language(which is where you think HTML ends) AND the HTML DOM. I want them to add something to the DOM, something that would be trivially easy to do. The fact that there are over 500 people on that ******* committee just goes to show what a joke it is. Put 500 engineers in a room and see the progress they make.

BTW, did you see this:

"The Document Object Model (DOM) is a representation ? a model ? of a document and its content. [DOM3CORE] The DOM is not just an API; the conformance criteria of HTML implementations are defined, in this specification, in terms of operations on the DOM."

Do you get it yet, that's straight from the spec? If you want to be compliant with HTML 5, you need to fully support the DOM outlined in that doc. So, you clueless ******* brain dead monkey, is it sinking in yet? Through your series of responses, you've demostrated that you have NO clue regarding the following:

HTML - markup AND DOM
Javascript
TCP/IP
AJAX
Web Services
HTTP
0 Votes
+ -
ZDNet UFC Champ, jackbond
PJfromOttawa 28th Jan 2008
You laid some smack on him good. You're very tough and intimidating.

Have you wiped the spittle off your keyboard?

"Brain dead monkey"??? Haha. Thanks for the wonderful lessons in the composition of colorful prose. All of us here luv ya to (BlueScreenOf)death.

Join the conversation!

Formatting +
BB Codes - Note: HTML is not supported in forums
  • [b] Bold [/b]
  • [i] Italic [/i]
  • [u] Underline [/u]
  • [s] Strikethrough [/s]
  • [q] "Quote" [/q]
  • [ol][*] 1. Ordered List [/ol]
  • [ul][*] · Unordered List [/ul]
  • [pre] Preformat [/pre]
  • [quote] "Blockquote" [/quote]
ie8 fix

The best of ZDNet, delivered

ZDNet Newsletters

Get the best of ZDNet delivered straight to your inbox

Facebook Activity

Blog Roll

Blog Archive

White Papers, Webcasts, & Resources
ie8 fix