HTML5

Why does it exist? What void is trying to be filled with it? I heard it is supposed to be an opensource replacement for flash, but I did some research and found that it is not capable of doing anything that flash can except play video.

[Web moderator]

More here:
http://www.w3schools.com/html5/default.asp
http://www.w3.org/TR/html5-diff/

Quite a few changes actually. Besides the video, you can now "draw" shapes on a virtual canvas - which could be quite handy if you ask me. It also allows for "storage" on the visitor's client browser for storing more than simple cookie data.

Unfortunately, until more people update their IE, in particular, and other browsers there won't ever be full compatability.

Yes, seems good, but flash is already capable of doing much more. I just don't see the need of something other than flash. It seems to me like they are reinventing the wheel.

Quite a few changes actually. Besides the video, you can now "draw" shapes on a virtual canvas - which could be quite handy if you ask me.

Both the video and "drawing" sounds incredibly inefficient.  Why don't they develop a GNU alternative to Flash rather than this dumb HTML5 Collective rubbish!

Also, isn't that drawing SVG?  Oh wait.. I remember... "HTML 5" = "HTML 5, and a lot of stuff that very obviously isn't HTML".

It also allows for "storage" on the visitor's client browser for storing more than simple cookie data.

How is that a good thing?  Just go ahead and read it out loud... doesn't make any sense, does it?

HTML 5 is a mark-up language that is going to provide slower browser experiences, more internet ignorance, and act as a platform for other slow standards such as using SVG, CSS3 and dumb video **** to replace far faster browser tools, like Flash.  The idea of using as much scripting, XML and plain-text as possible just seems dumb as *censored* from all points of call and yet this is still regarded as an upgrade.  If people really have an issue with Flash then by all means, make a W3C blessed binary standard for rich media, don't try and replace it with more scripting which shouldn't be given as a utility due to its potential for lazy use and inefficiency!


This is a family friendly forum. Please mind your language.

It seems to me like they are reinventing the wheel.

Agreed.

[Web moderator]

Why don't they develop a GNU alternative to Flash rather than this dumb HTML5 Collective rubbish!

MS tried to create an alternative, although not free, it barely skimmed the top off Adobe's market share.

Also, isn't that drawing SVG?

Use Google if you're not sure.

HTML 5 is a mark-up language that is going to provide slower browser experiences, more internet ignorance, and act as a platform for other slow standards such as using SVG, CSS3 and dumb video **** to replace far faster browser tools, like Flash.  The idea of using as much scripting, XML and plain-text as possible just seems dumb as *censored* from all points of call and yet this is still regarded as an upgrade.  If people really have an issue with Flash then by all means, make a W3C blessed binary standard for rich media, don't try and replace it with more scripting which shouldn't be given as a utility due to its potential for lazy use and inefficiency!

You seem to have a problem with something or other, so I'd suggest you go bang your head off a wall or something. If we can't have a civilised debate over the good and bad points of HTML5 then go elsewhere.

It also allows for "storage" on the visitor's client browser for storing more than simple cookie data.

Sounds like it could be a security risk. Anyway, Veltas, I think you're right.

The idea of using as much scripting, XML and plain-text as possible just seems dumb as *censored* from all points of call and yet this is still regarded as an upgrade.

Exactly, a scripting language language can never have as much power and speed as flash because flash is compiled (to byte code I think). All this will do is add another layer and more complexity to something that doesn't need it in the first place.

[Web moderator]

Exactly, a scripting language language can never have as much power and speed as flash because flash is compiled (to byte code I think). All this will do is add another layer and more complexity to something that doesn't need it in the first place.

Well, IMO, the fact that an external plugin doesn't have to be loaded in the first place would speed things up.

Anyway, whichever is better - a WWW-wide standard should be used and left at that. I don't think there were many changes between HTML 4 and HTML 3 either, but it was a while since an upgrade - so they upgraded it. This update, I do feel, isn't as necessary as the last one. The web has come a long way since HTML 3, and with CSS3 on the footpath, HTML 5 doesn't bring much to the table.

You seem to have a problem with something or other, so I'd suggest you go bang your head off a wall or something. If we can't have a civilised debate over the good and bad points of HTML5 then go elsewhere.

I'm sorry, I'm acting like HTML 5 killed my mother... I'll tone down the drama.

MS tried to create an alternative, although not free, it barely skimmed the top off Adobe's market share.

Yeah, but Silverlight wasn't really ever seen as a GNU alternative, as it wasn't GNU and didn't really take off anyway.

[Web moderator]

You are

HTML5 is a step forward, and more or less a natural extension of what we have. So far we'd had to rely on hacks and workarounds to get things working; in IE3, MS worked around the dismal support for layout by having a Layout ActiveX control; netscape had something similar. Of course you had to code two different web pages pretty much. then they added CSS to the standards and suddenly the control and NS plugin were obsolete. The interesting thing is people were saying exactly what is being said now. "I don't know why they added CSS! It will be slower than the layout control!" etc. All of which turned out to be hot-air.

MS tried to create an alternative, although not free, it barely skimmed the top off Adobe's market share.

Sharepoint and SilverLight are actually rather commonly used in enterprises over flash now. WPF itself is actually pretty bloody good for UI designing; better than HTML&CSS for sure. It particularly shines with data binding and data templates. I imagine a lot of the problem is that it requires the rather expensive IIS server.

Exactly, a scripting language language can never have as much power and speed as flash because flash is compiled (to byte code I think). All this will do is add another layer and more complexity to something that doesn't need it in the first place.

Flash's ActionScript compiles to bytecode. But as far as performance is concerned it hardly makes a difference, since Javascript is compiled to machine code on-the-fly for the local machine with most browser's interpreters; much akin to java. Flash's use of a Binary Blob for data has been a source of too many problems to count. Most of the security issues we have to constantly keep updating Flash Player for are caused by malformed SWF files that break assumptions made in the plugin.

Thing is, Flash/Shockwave has only become so widely accepted because machines have gotten fast enough to run it. In it's earliest incarnations it required what would be considered a rather weighty machine to use adequately.

HTML 5 is a mark-up language that is going to provide slower browser experiences,

How will it be slower? Currently, with flash, the speed at which Shockwave files play depends entirely on the implementation in
 the plugin. With HTML5, the speed of canvas element animation will depend on the browser implementation. the fact is it's not moving anything. Rather than having the animation coded in a native-code library attached to the browser, it will be run in the browser itself. The fact that the elements and other properties of the animations is held in plain-text has no bearing on speed since it will be read once, placed into data structures by the browser, and run. The same thing has to happen with flash anyway, being effectively binary doesn't make a huge difference.

more internet ignorance

Um, how would this happen?

and act as a platform for other slow standards such as using SVG, CSS3 and dumb video **** to replace far faster browser tools, like Flash.

SVG and CSS3 are better than flash, simply by virtue of A: not requiring a security addled plugin, and B: not relying on a uninspectible, proprietary binary file for it's information. That binary file doesn't make Flash faster. Flash isn't faster, it's language is ActionScript and doesn't run any faster than javascript does in a browser thanks to jit.

The idea of using as much scripting, XML and plain-text as possible just seems dumb as *censored* from all points of call and yet this is still regarded as an upgrade.

Consider that almost every single exploit in either browsers or flash has to do with malformed binary data, I think it makes perfect sense to change formats from an ill-documented binary format whose loading is controlled by a third-party plugin that cannot be properly security audited to a format that can be.

If people really have an issue with Flash then by all means, make a W3C blessed binary standard for rich media, don't try and replace it with more scripting which shouldn't be given as a utility due to its potential for lazy use and inefficiency!

The fact that flash is Binary at all is the problem, and is typically the cause of almost all browser security issues across the board. This applies both to it's swf files, which use a proprietary format that cannot be verified as meeting any specification by an external observer, as well as the plugin, which is generally a native code plugin or extension for the browser that is the only thing that understands that format. Of course since the plugin runs in the browser and thus has full control over it, you have the problem where the plugin being exploited by malformed binary data can either take control of the browser or crash it entirely (which is why almost all browsers have sandboxed plugin processes- all because of flash).


Also, what does GNU have to do with HTML5 and the W3C, anyway?

Also, what does GNU have to do with HTML5 and the W3C, anyway?

Dunno, lol.

HTML5 is a step forward, and more or less a natural extension of what we have.

Certainly, not considering current plugins HTML 5 is a natural extension.

Sharepoint and SilverLight are actually rather commonly used in enterprises over flash now. WPF itself is actually pretty bloody good for UI designing; better than HTML&CSS for sure. It particularly shines with data binding and data templates. I imagine a lot of the problem is that it requires the rather expensive IIS server.

You learn something new every day... but as far as web design in general is concerned this is really a niche rather than a general swoop... but not small enough not to be considered.

But as far as performance is concerned it hardly makes a difference, since Javascript is compiled to machine code on-the-fly for the local machine with most browser's interpreters; much akin to java.

This is only a recent development (or in Google Chrome's case something since inception, half the reason Chrome caught developer's eyes so early on was its amazing out-of-this-world JavaScript performance), and still requires a faster machine than flash does.



Something else worth considering... most web developers know barely anything about coding web-pages, much less how to script using all the features plugged into HTML 5.  This means they're going to grab the first good HTML 5 development kit that hits the market and horrendous unreadable and ultra-inefficient code is going to become the standard on all but the best funded websites.  Even if well-formed HTML 5 is almost as fast as Flash, most people won't be able to provide this and HTML 5 will take a very long time to become adopted.  This is good news for web coders, bad news for small businesses and a pain for large companies that want to look groovy and use HTML 5.

[Web moderator]

most web developers know barely anything about coding web-pages, much less how to script using all the features plugged into HTML 5.

I don't know who you're referring to or how true it is, but any and all websites I do are created first in Photoshop, then Dreamweaver (for it's very-handy compatability checking) and finally to Notepad++ where I do the coding. Also, with most websites using some form of server-side technology, web developers have no choice but know how to code.

Even if well-formed HTML 5 is almost as fast as Flash, most people won't be able to provide this and HTML 5 will take a very long time to become adopted.

Very true.

I think the problem for HTML5 is javascript libraries like jQuery, Prototype, Mootools etc. They make designing interactive and animated websites very easy.

and a pain for large companies that want to look groovy and use HTML 5.

As I said above, there will be no need for large companies to upgrade to HTML 5 because of things like jQuery.

I think the problem for HTML5 is javascript libraries like jQuery, Prototype, Mootools etc. They make designing interactive and animated websites very easy.

Now I'm confused... I thought JavaScript was supposed to be used with HTML 5.

[Web moderator]

No, not necessarily. Just the storage thing, I think, uses Javascript.

Also, with most websites using some form of server-side technology, web developers have no choice but know how to code.

There must be other facilities that don't require this... like PHPBB or whatever it is that people use for forums.

No, not necessarily. Just the storage thing, I think, uses Javascript.

I noticed a lot of scripting in CSS 3 too, is that not JavaScript or EcmaScript?

[Web moderator]

I think some terminology needs to be cleared up.

Server-side is PHP, ASP, ASP.NET, JSP, ColdFusion etc. This forum (SimpleMachines Forum) uses server-side technology - PHP - the same as phpBB or InvisionBoard or vBulletin. Anywhere a website communicates with the server - to send or retrieve data from a database for example is server-side. HTML or Javascript can't connect to a database alone.

I noticed a lot of scripting in CSS 3 too, is that not JavaScript or EcmaScript?

CSS 3 Javascript? Nope! CSS 3 is the same as CSS 2 with added effects.

CSS 3 Javascript? Nope! CSS 3 is the same as CSS 2 with added effects.

Yeah thanks I know, but what about the scripts in between the CSS?

[Web moderator]

I'm not sure what about scripts between the CSS...

This is only a recent development

That's irrelevant. It's here now.

(half the reason Chrome caught developer's eyes so early on was its amazing out-of-this-world JavaScript performance)

If you ask me, Chrome's javascript interpreter, or at least it's implementation of certain behaviours, is broken.

Let's say I want to pop off an analytics pixel at unload time. We need a little delay to ensure the image request gets sent, so we shove in this little gem:

Code: [Select]

var s = e = new Date();

while (e.getTime() - s.getTime() < 500)
{
   e = new Date();
}


There! Works in every browser! Except Chrome- "Error: Too much time spent in unload handler"

OK, no problem. We'll just change it to this.

Code: [Select]

var s = e = new Date();

while (e.getTime() - s.getTime() < 1)
{
   e = new Date();
}

whew, glad that's out of th "Error: Too much time spent in unload handler."

So... one millisecond is too long? Is that what the error means? Why is chrome the only one that has this limitation? Guess though! Turns out that this error is a lie- it had nothing to do with the amount of time spent in the handler. It should really read, "Chrome detected you're trying to delay unload to ensure a pixel request goes through. Even though the only way to accomplish this is by delaying unload, we're going to be total dicks about it and pre-empt your attempt".

I mean, I can understand preventing too long of a delay, but basically providing a handler and refusing to do anything useful in it? What is that supposed to do?

You might think "well it's for security rite" Which I might agree with. The purpose if this code, by the way, is to try to keep track of what link was clicked to leave a page. I ended up working around it by creating my own Mini URL shortener service and having those links in the DB, so the page that redirects to it can record the link hit. Then I removed it because it was a pain in the *censored*, so now my DB has empty fields where the counts should be.  One might argue that "anything that tracks the user is inherently bad even if the purpose is to increase site usability"... Of course that sort of falls apart, since you can get the proper behaviour by just using this:

Code: [Select]

var s = e = new Date();

for( var i = 0; e.getTime() - s.getTime() < 500; i++)
{
   e = new Date();
}

So, why doesn't the original code work? It's some weird bit of hueristic done by chrome to prevent... well, I'm not sure.  It's quite targeted. you can use a while() loop, it doesn't trigger the error. Nor does calling getTime() on it's own. But if you call getTime in the condition or body of a while loop, poof- "too much time spent in unload handler".

it's really quite targeted. A while() loop alone doesn't trigger the behavior, nor does calling getTime() alone. But if you call getTime() in the condition or body of a while() loop, bam. I don't remember reading about this error being thrown in those specific conditions in the ECMA specification. The best I can tell is it was designed to prevent infinite loops in the BeforeUnload handler. I can totally understand preventing infinite loops in BeforeUnload handlers, because- duh. Thing is if the above behaviour is designed to do that, they missed a bunch of other ways to lock up their own browser:

Code: [Select]

var img = document.createElement('IMG');
img.src = 'http://url_i_want_to_load.png';
img.loaded = false;
img.onload = new Function('e', 'this.loaded = true');

while( !img.loaded )
{
  CodeToTrickChromeIntoThinkingThisCodeDoesSomethingUseful();
}
In that segment (mostly psuedocode) the while condition is never going to occur, because the image's onload handler cannot be trigger while in the middle of another handler. So, one might expect the browser to do toe usual "chug along for 30 or so seconds, complain about "this page stopped responding" and prompt to close it,right?

Nope. the tab's process pegs the CPU at 100% (or rather high, regardless) until the user forces the tab closed. It's an interesting day at the office when you accidentally learn how to write malicious javascript. Too bad it only works (or worked, they may have fixed this since I discovered it) in Chrome. Also too bad we have to write workaround code- only for chrome, mind you- to "fix" their special "prevent infinite loops" behaviour nonsense which doesn't even work.

Anyway- so when I first discovered this- as noted, the problem only cropped up in Chrome. IE? worked fine. IE6? Worked fine. Firefox? worked fine. Opera? don't know. didn't try it. etc. Only Chrome was a problem.

And people give IE a bad rap for making people write workaround code...

One of the major problems is that how browser makers and the W3C hold their hands up to their ears and yell "NAH NAH NAH NAH!!!" whenever the need for web analytics comes up. There really should be support for something this simple in the spec. Analytics aren't inherently evil, and if it's in the spec, one can control exactly what kind of information is kept track of, and what can be done (like not showing alerts and so forth). It's not like a server side page can't already track all sorts of stuff like refering URLs and IP addresses and whatnot. Seeing how people are leaving the page is hardly a bad thing.


Than again, all the browsers have their issues. I rather like this bug from 2001..

I'm not sure what about scripts between the CSS...

I have to echo your confusion...

That's irrelevant. It's here now.

Doesn't matter, that wasn't my point.  My point in that line was that JavaScript requires more attention from the computer than Flash.

If you ask me, Chrome's javascript interpreter, or at least it's implementation of certain behaviours, is broken.

Maybe, but when they were first developing Chrome it ran JavaScript the fastest by far.

Doesn't matter, that wasn't my point.  My point in that line was that JavaScript requires more attention from the computer than Flash.

"More attention" is hardly something you can really quantify. If you mean it takes more processing power to run JavaScript over Flash; well, that's not accurate either, since, As I said, there are now JIT Compilers for Javascript; and, more importantly, ActionScript is still only compiled to bytecode (again, a more or less undocumented bytecode run by a single VM implementation that is entirely proprietary). As I said before, the primary reason for most browser "security issues" can usually be blamed on Flash.

I'd take a more security auditable and less black-box implementation using HTML5 over Flash any day.

Maybe, but when they were first developing Chrome it ran JavaScript the fastest by far.

It doesn't matter how fast your code runs if it doesn't work.

I'd take a more security auditable and less black-box implementation using HTML5 over Flash any day.

If there was a W3C binary alternative it wouldn't technically be black-box, would it?

It doesn't matter how fast your code runs if it doesn't work.

Well obviously it worked enough... it may not even have been as bad as IE was at the time with JavaScript.

If there was a W3C binary alternative it wouldn't technically be black-box, would it?

um... why do you think that binary formats are better? They aren't. The speed gains from a Binary format is all in the parsing, and the fact is that in order to combat things like buffer overflow issues and malformed input, the reading code would need all sorts of sanity checks to make sure somebody isn't trying to screw with them. The burden of processing is on translating the Script or "binary" code into the internal data structures for execution, not in the actual load-time.

Well obviously it worked enough...

It was broken. see above broken implementation of an attempted "security feature" that required workaround code to deal with.

it may not even have been as bad as IE was at the time with JavaScript.

I've never had issues with Microsoft's Javascript implementation. I have with Chromes.

I've never had issues with Microsoft's Javascript implementation. I have with Chromes.

Maybe I'm remembering wrongly.

I wouldn't want to suffer from chromes.

compiled to machine code on-the-fly

The difference in speed would result from this. Even if javascript is compiled, it's compiled on-the-fly where as flash is already precompiled to byte code resulting in faster execution.

Anyway, the main point of the post was comparing HTML5 to flash and even if HTML5 has its pluses, it will never compare to flash performance-wise.

The difference in speed would result from this. Even if javascript is compiled, it's compiled on-the-fly where as flash is already precompiled to byte code resulting in faster execution.

No. the main branches of javascript on a page will be compiled quicker than the flash plugin can even load.

Anyway, the main point of the post was comparing HTML5 to flash and even if HTML5 has its pluses, it will never compare to flash performance-wise.

What do you base this on?

These tests indicate quite a different picture.

Surely a lot of animation is done without much ActionScript use?  I don't think anyone's trying to say ActionScript runs faster than JavaScript.

Surely a lot of animation is done without much ActionScript use?  I don't think anyone's trying to say ActionScript runs faster than JavaScript.

[Web moderator]

*facepalm*

Try learning ActionScript. It's like writing a GUI-based calculator in DOS.

I'm not sure why we're so worried about speeds anyway - we're only talking milliseconds in the difference.

I'm not sure why we're so worried about speeds anyway - we're only talking milliseconds in the difference.

Exactly... and that would be the cumulative time. And if we are talking about just a few bloody tweens, I hardly see how somebody could prefer flash. (which wouldn't be faster anyway*)

There are several key points to summarize.

-Javascript is a plain-text language that has to be interpreted by the browser.

-Veltas, at least, thinks that there should be some sort of "Binary code" that is "W3C approved" (whatever that means) for use on the web at large.

-But the reason we don't do that, is that Binary Blobs are inherently unsafe. What is it, anyway? Some sort of byte code? machine code? Just saying "Binary standard" was a dreadfully vague thing to say. Bitmap files are a "Binary standard"  but I don't see them as being very useful for animation.

-Currently, the security issues are constrained by the browser's javascript interpreter. This would simply move that to a "new" interpreter for this Binary blob (or remove security and platform independence altogether if it was just a blob of machine code that could be arbitrarily run by a browser, Web-based ActiveX All over again... but W3C approved!) And of course the browser would still need a javascript interpreter anyway, so all this would do is multiply the attack surface- for no real gain whatsoever.


*Allow me to explain why Flash will always universally be slower than javascript,CSS/HTML:

First, it's always a plugin. That means it always has to be loaded, for any Flash-based content to be viewed. various implementations of the plugin could easily change behaviour. Also, most browser plugin architectures on most windowed desktops have to create a Child window for it. This has several ramifications- first, it means that scrolling the page will require more work by the browser to properly clip the flash video being shown (otherwise it would appear atop other controls). You can already see this as a frequent symptom with Flash video- "native" HTML content, without ridiculous and sometimes browser-specific hacks, appears on top of everything else, simply by virtue of it using a window handle (on windows, or equivalent on other systems) and being a full-fledged OS managed Window, whereas the rest of the content is rendered as part of a larger frame. HTML5 would put those rendered elements as part of the rendered frame, making their actions, responses, and general interactions scriptable using javascript. And, by eliminating a Machine-Language binary from the browser, you've eliminated the biggest attack surface present in browsers for over a decade. Is it slower? well, maybe. But you know what? There is no point being minutely faster if it's inherently insecure. And I repeat, Adobe Flash is the primary reason that browsers now sandbox plugins.

Firstly, BC, I think you need to get over yourself.

Secondly, even if you use ActionScript all over an animation or for a site, it's still not taking up most of the processing time.

Firstly, BC, I think you need to get over yourself.

What?

You said that "not all flash has actionscript"

Except it does. The fact is that Shockwave/Director/Flash itself, when creating tweens and other content in the editor, are basically going to compile that into actionscript. Just because a swf doesn't have user-created actionscript doesn't mean that it magically doesn't have any at all; any and all actions- animation or otherwise- in a flash video are done via ActionScript, or rather, actionscript bytecode.
It's sort of like saying that not all Windows applications have a WinMain() function. It's only right if you don't look beneath the surface; all Windows applications have a WinMain function, just most languages and libraries hide it beneath their runtimes. Similar with ActionScript; just because you didn't add it yourself doesn't mean it isn't there.

Secondly, even if you use ActionScript all over an animation or for a site, it's still not taking up most of the processing time.

This discussion would be a lot easier if you had used any of the involved technologies at some point.

[Web moderator]

It's sort of like saying that not all Windows applications have a WinMain() function. It's only right if you don't look beneath the surface; all Windows applications have a WinMain function, just most languages and libraries hide it beneath their runtimes. Similar with ActionScript; just because you didn't add it yourself doesn't mean it isn't there.

An internet comparison to that would be the class contructor function in PHP (or Java) - you can create one if you like but one will be added automatically if you don't.

must
you can create one if you like but one will be added automatically if you don't.

not to tarnish your point, but there is a glaring exception with java-
you must define a constructor in any class which derives from another class that doesn't have a parameterless constructor. For example:

Code: [Select]

//a.java
public class a{
    public a(int parameter){

    }

}

//b.java
public class b extends a

}

as that is, b.java will not compile, since it cannot automatically generate a parameterless constructor on account of such a automatically generated constructor simply consisting of a call to the parameterless superclass constructor, which in this case doesn't exist. Now you can of course create your own parameterless constructor which calls a superclass constructor with parameters, but in this case it can't be automatic.

of course if you were really referring to javascript, than I have no idea of the semantics involved, though I'd be rather disappointed that you would confuse them

Totally off-topic, but am I the only one that thinks interfaces should totally allow for a guarantee that certain constructors be present? I mean, I can throw an exception if reflection doesn't find the appropriate constructor, but it would be nice to have some compile-time checking, since that is sort of the point of using interfaces to begin with...

[Web moderator]

Yes, I was talking about Java.
I'm learning it at the moment in college, so not quite up on all the points yet - including the one you mentioned.