Last Comment Bug 649408 - (nativehtml5) Support Native HTML5
(nativehtml5)
: Support Native HTML5
Status: RESOLVED INVALID
[parity-ie][telepathy-needed]
:
Product: Core
Classification: Components
Component: General (show other bugs)
: unspecified
: x86 Windows 7
: -- blocker with 14 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
:
Mentors:
http://blogs.msdn.com/b/ie/archive/20...
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-04-12 10:47 PDT by Mike Beltzner [:beltzner, not reading bugmail]
Modified: 2013-12-27 14:36 PST (History)
77 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
The HTML5 coprocessor (90.96 KB, image/jpeg)
2011-04-13 09:49 PDT, Daniel Buchner [:dbuc]
no flags Details

Description Mike Beltzner [:beltzner, not reading bugmail] 2011-04-12 10:47:08 PDT
The Internet Explorer 10 Platform Preview has "Native HTML5" support, see:

http://blogs.msdn.com/b/ie/archive/2011/04/12/native-html5-first-ie10-platform-preview-available-for-download.aspx

Mozilla should consider adding support for native HTML5 as well. I'm sure that a specification will be produced, but for now the definition seems to be:

"Web sites and HTML5 run best when they run natively, on a browser optimized for the operating system on your device ... The only native experience of the Web and HTML5 today is on Windows 7 with IE9."
Comment 1 Boris Zbarsky [:bz] (still a bit busy) 2011-04-12 12:16:09 PDT
I believe the definition Jeff suggested was that "Native HTML5" would be a browser optimized for your hardware, without compatibility layers like Windows getting in the way.

I'm not sure whom to cc to get that messaging to happen.
Comment 2 Andreas Gal :gal 2011-04-12 13:54:47 PDT
link to track our progress on this bug: http://arewenativeyet.com/
Comment 3 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2011-04-12 15:57:06 PDT
(In reply to comment #1)
> I believe the definition Jeff suggested was that "Native HTML5" would be a
> browser optimized for your hardware, without compatibility layers like Windows
> getting in the way.

I don't think general-purpose hardware actually supports Native HTML5.  Wake me up when we have HTML5 coprocessors.
Comment 4 Philipp von Weitershausen [:philikon] 2011-04-12 16:25:09 PDT
Are we sure Microsoft didn't fat-finger that blog post and really meant "naïve HTML5" rather than "native HTML5"?
Comment 5 Anthony Catel [:paraboul] 2011-04-12 16:30:49 PDT
Oh dear, a "like" button is missing. /me like #2
Comment 6 Dave Herman [:dherman] 2011-04-12 16:33:41 PDT
(In reply to comment #3)
> Wake me up when we have HTML5 coprocessors.

Aha! So is *that* what "full hardware acceleration" means?

Dave
Comment 7 Daniel Buchner [:dbuc] 2011-04-12 16:37:42 PDT
Just Googled that quote Mike, here's what happened:

  Search - "Websites & HTML5 run best when they run natively"

  Results - Did you mean: "Website & HTML5 buzzwords sound best when used naïvely"

Zing! :)
Comment 8 JR Conlin [:jrconlin,:jconlin] 2011-04-12 16:48:37 PDT
Actually, I'd make an argument that the assertion is incorrect. 

Websites run best when using native code and transmitted via an optimized binary protocol. The protocol should be designed to work on a wide number of simple clients with minimal graphic interfaces. 

Microsoft is merely announcing that all future development will be in X-Windows.

(By the way, i'm planning on seeing how much VC i can gather for my new startup: Selling developers spork proof goggles for when they figure out Microsoft's goal.)
Comment 9 Robert Sayre 2011-04-12 18:56:55 PDT
I don't see how IE10 can claim to be Native HTML5 when they don't support the Web Audio API: http://chromium.googlecode.com/svn/trunk/samples/audio/specification/specification.html

That is totally native stuff. You can write exact clones of desktop applications, without doing any messy networking.
Comment 10 Jonathan Allen 2011-04-12 19:16:04 PDT
You guys have it all wrong. 

A "native HTML" app is one that feels like a native WINDOWS app. That isn't just performance or standards support. That means supporting stuff like task bar jump lists and notifications.

http://www.infoq.com/news/2011/03/Pinned-Sites

Do you really want that in Firefox? Are you willing to do this for every OS that Firefox supports?
Comment 11 Asa Dotzler [:asa] 2011-04-12 19:18:06 PDT
I'm pretty sure Firefox 5 has "complete native html5" support. We should resolve this as fixed and be sure to let the world know we beat Microsoft to shipping *complete* native html5.
Comment 12 Marco Bonardo [::mak] 2011-04-12 19:35:04 PDT
Who is producing this native hardware? I want a coprocessor dedicated only to accelerating throbbers.
Comment 13 Brendan Eich [:brendan] 2011-04-12 19:40:41 PDT
Jonathan: you're missing out on some key facts:

1. This is a joke bug.

2. Microsoft is *not* using "native HTML5" to describe jump-list integration. They are talking about performance, or rather the lack of it due to the lack of hardware accelerated graphics on windows XP.

3. We have jump-list, aero, etc. integration thanks to jmathies. More to come, since that is hard work dealing with under- and undocumented Win32 APIs and who wants to play that losing game on Microsoft's treadmill. But we perservere.

Meanwhile, back in reality, the "native HTML5" nonsense-phrase is a source of endless fun. Like this bug. So back to the joke.

/be
Comment 14 JR Conlin [:jrconlin,:jconlin] 2011-04-12 21:02:47 PDT
Is this replacing ActiveX support? If not, we should file a bug with Microsoft. Because I can't imagine a scenario where providing remote access to my machine's hardware via visting a webpage would be bad and I loved the kind of amazing system level things I could do with ActiveX.
Comment 15 Yuhong Bao 2011-04-12 21:10:55 PDT
I have said that MS is the most non PR 2.0 compliant vendor for a while now.
Comment 16 Alex Faaborg [:faaborg] (Firefox UX) 2011-04-12 23:34:45 PDT
I was browsing the Web earlier today, and I suddenly realized that it didn't have nearly as many fish as it was supposed to.
Comment 17 Eric Shepherd [:sheppy] 2011-04-12 23:40:02 PDT
#winning
Comment 18 Daniel Glazman (:glazou) 2011-04-12 23:54:28 PDT
I have the feeling this bug is not enough. We should have a companion "Support
Native CSS" bug too.
Comment 19 Asa Dotzler [:asa] 2011-04-12 23:57:28 PDT
(In reply to comment #18)
> I have the feeling this bug is not enough. We should have a companion "Support
> Native CSS" bug too.

Daniel, only native *CSS3* though since this one isn't about native HTML but rather native HTML5! (though that does raise the question of whether or not we all ought to make HTML 4.0.1 native as well.)
Comment 20 Daniel Glazman (:glazou) 2011-04-13 00:01:01 PDT
(In reply to comment #19)

> Daniel, only native *CSS3* though since this one isn't about native HTML but
> rather native HTML5! (though that does raise the question of whether or not we
> all ought to make HTML 4.0.1 native as well.)

The current secret project of the CSS WG is a CSS coprocessor. Oops, I said it.
Bah.
Comment 21 Zibi Braniecki [:gandalf][:zibi] 2011-04-13 00:36:01 PDT
Fixed per comment 11. Can someone verify please? 

I believe it's an amazing news that the world does not have to wait until Windows 8 release somewhere late into 2012 to experience "Native HTML5"... Hey! Not even Windows 7 is required!

Oh, and we're ready for the next buzzword as well.
Comment 22 Xavier Mouton-Dubosc 2011-04-13 00:43:37 PDT
I have a Pentium, and the Pentium is accelerating Internet.

Can't be better : That's what the ad said.
Comment 23 Shawn Wilsher :sdwilsh 2011-04-13 00:53:06 PDT
Mike said he'd still be a part of our community when he left, and I sure am glad he still is!  Mike, thank you for filling this very important bug.  If we want to remain competitive in the marketplace, we absolutely need to make sure we are native as soon as possible.  Mike, do you have suggestions on how we can verify Asa's assertion in comment 11 that we are native?  I think Alex has a great point in comment 16; I too felt like the Web did not have enough fish while browsing today.  Perhaps we aren't native enough yet?  Can we maybe write some arbitrary test to declare our compliance?  This seems to have worked well for some of our competitors...
Comment 24 Andreas Gal :gal 2011-04-13 01:06:07 PDT
Jeff showed me his webgl version of the IE fish tank today. It can render around 50,000 fish whereas IE manages a meager 1000 or so with the canvas version. With that logic we should be 50x more native than IE, no?
Comment 25 Mike Beltzner [:beltzner, not reading bugmail] 2011-04-13 01:08:59 PDT
I can't verify that comment 11 is true. According to the rough spec (see comment 0) we don't meet the requirements until we manage to ship Firefox 4 on Internet Explorer on Windows 7.
Comment 26 Laxminarayan G Kamath A 2011-04-13 01:11:17 PDT
See, they were initially planning to implement html5 as a plugin .. like flash .. then they made a bold decision to implement right in the browser. So, creds to them on that.
Comment 27 Mathias Bynens 2011-04-13 01:12:51 PDT
(In reply to comment #26)
> See, they were initially planning to implement html5 as a plugin .. like flash

Microsoft Gears™. I can see it now...
Comment 28 Daniel Glazman (:glazou) 2011-04-13 01:28:10 PDT
I wonder if the human user behind the native browser should be native too.
Are you native? Do we need http://www.areyounative.com?
Comment 29 Zibi Braniecki [:gandalf][:zibi] 2011-04-13 01:46:49 PDT
Comment 25 made me rethink our strategy and as linostar pointed out on IRC - maybe we should embrace our native self. Maybe we should give up on the localization and go bold - Native American only!
Comment 30 Paul Rouget [:paul] 2011-04-13 03:10:26 PDT
Just did a screencast of how bad we are at rendering native HTML5: http://www.youtube.com/watch?v=eSfNIjdXHJY
Comment 31 Timo Kinnunen 2011-04-13 03:30:36 PDT
As I understand it, HTML5 is the source code for the DOM, which contains graphics, videos, text, executable instructions and other things. 

Is the point of this bug that Firefox will not composite the DOM natively on a GPU, will not decode videos natively on a GPU, will not render text using APIs that run natively on a GPU, will not run the instructions natively on the CPU, but that some of this will be emulated?
Comment 32 Alex Faaborg [:faaborg] (Firefox UX) 2011-04-13 04:27:33 PDT
>Just did a screencast of how bad we are at rendering native HTML5:
>http://www.youtube.com/watch?v=eSfNIjdXHJY

On careful inspection, I'm pretty sure that the only demo in that reel that was actually native was the one with the fish.
Comment 33 Demis Bellot 2011-04-13 05:33:06 PDT
Breaking! Mozilla just got some *real competition* there's a new Big Fish in town providing the best native functionality the world has ever seen!

http://www.youtube.com/watch?v=2zql2t8uC4M

This is going to be tough to beat - I wish you the best and hope you guys are up to the task!
Comment 34 Boris Zbarsky [:bz] (still a bit busy) 2011-04-13 06:04:30 PDT
> Are you native? Do we need http://www.areyounative.com?

I thought going native was generally looked down upon?
Comment 35 Guillermo López :willyaranda (probably SLOW response) 2011-04-13 06:23:26 PDT
Are you saying that my awesome page made in HTML5

http://willy.pijusmagnificus.com/mozilla/truehtml5video.html

is not native in Firefox? What are you thinking guys!! I'm going to tell every single user of Firefox to switch to IE10 with Native HTML5 Support to really enjoy my page!
Comment 36 Majken Connor [:Kensie] 2011-04-13 07:47:04 PDT
So I'm not quite native, does Metis count?

To be serious for just a moment - it would be pretty awesome to have a range of "native" l10ns for Firefox.  I know there are some european translations that could count. But it would be really cool to have others, like Ojibway and Navajo.
Comment 37 Daniel Glazman (:glazou) 2011-04-13 07:55:38 PDT
I'm sure I can do the french slang l10n for Firefox. Will be totally native
for parisian teenagers who barely speak correct french.
Comment 38 Markus Amalthea Magnuson 2011-04-13 07:56:31 PDT
http://www.flickr.com/photos/jamesstephens/3521178837/
Comment 39 David Bruant 2011-04-13 08:04:36 PDT
(In reply to comment #37)
> I'm sure I can do the french slang l10n for Firefox. Will be totally native
> for parisian teenagers who barely speak correct french.
I'm confident in being able to create a native l10n for Bordeaux (or French South-West):
"Firefox a crashé, ça daille gavé ! Tu veux restaurer ta session ?"
"Panorama: mettez vos onglets dans des poches !" We could have a skin for that :-p So native !
Comment 40 Christopher Blizzard (:blizzard) 2011-04-13 08:10:55 PDT
Every time I hear the word "native" I think of the political movement: http://en.wikipedia.org/wiki/Nativism_%28politics%29

Fitting, I think.
Comment 41 Daniel Buchner [:dbuc] 2011-04-13 08:34:21 PDT
Perhaps we should try to have HTML5 included in NaCl? I mean what would be better than having the next version of the mark-up language we all know and love available in any browser, NATIVELY!...err... #solvedproblem
Comment 42 [Baboo] 2011-04-13 08:45:42 PDT
(In reply to comment #3)
> I don't think general-purpose hardware actually supports Native HTML5.  Wake me
> up when we have HTML5 coprocessors.

HTML is not very complicated therefore building HTML5 co-processors shouldn't be a challenge either.
Maybe Mozilla could distribute DIY kits consisting of some NORs and a pinboard patch panel. This would also make updating to newer HTML revisions easier (and there will many more come since HTML is now forever alpha[*]).

[*] http://blog.whatwg.org/html-is-the-new-html5
Comment 43 Daniel Glazman (:glazou) 2011-04-13 08:48:05 PDT
Let's do an arduino-based HTML5 native coprocessing unit?
Comment 44 Zibi Braniecki [:gandalf][:zibi] 2011-04-13 09:00:24 PDT
but, it will still not pass the reporter's expected result (see comment 25)
Comment 45 Daniel Buchner [:dbuc] 2011-04-13 09:49:53 PDT
Created attachment 525702 [details]
The HTML5 coprocessor

Just received an anonymous tip on a newly developed HTML5 coprocessor with a leaked product shot!
Comment 46 Allison Naaktgeboren :ally 2011-04-13 09:54:50 PDT
Will HTML5 in the state of Arizona be required to provide proof of nativeness stopped by a police browser? Are we in violation of Arizona law for interacting with non-native HTML5?
Comment 47 JR Conlin [:jrconlin,:jconlin] 2011-04-13 09:58:22 PDT
To address the astute observations of Comment 16, 23, 24, and 33, I have taken a rough first approach to adding the IE9 level of HTML5 awesome we need. 

http://evilonastick.com/awesome/

It obviously needs some refinement, including the ability to optionally look for the soon-to-be introduced <fish> tag.
Comment 48 JR Conlin [:jrconlin,:jconlin] 2011-04-13 10:03:35 PDT
I've been informed that the page is much easier to read (albeit less awesome) if you view source on the page. 

I've also been commended on the self-documenting nature of the javascript.
Comment 49 Jeff Walden [:Waldo] (remove +bmo to email) 2011-04-13 10:22:21 PDT
(In reply to comment #29)
If you need an Acme Genuwine 100% Real Native American for marketing, I offer myself as 1/16th Native American from a great-great-grandmother.  (Yes, that 1/16th is 100% Real, 4srs.)  I guarantee you won't find anyone else who looks the part more than me (whatever that means) if you don't look very hard.
Comment 50 Agostino 2011-04-13 10:48:23 PDT
(In reply to comment #16)
> I was browsing the Web earlier today, and I suddenly realized that it didn't
> have nearly as many fish as it was supposed to.

I agree. I tried plentyofffish.com today with IE10, and there's like twice the fish!
Comment 51 Keegan Watkins 2011-04-13 10:49:48 PDT
(In reply to comment #46)

chock full of win!
Comment 52 Keegan Watkins 2011-04-13 10:49:59 PDT
(In reply to comment #46)

chock full of win!
Comment 53 docileshark 2011-04-13 11:28:34 PDT
Here's an example of the layers that are between FF and running natively: https://wiki.mozilla.org/Gecko:Layers

Feel free to laugh at the phrase... the rest of us will laugh at FF performance.
Comment 54 Marco Bonardo [::mak] 2011-04-13 11:46:32 PDT
(In reply to comment #53)
> Here's an example of the layers that are between FF and running natively:
> https://wiki.mozilla.org/Gecko:Layers

Crazy abstraction! I suggest to gift a new video card to each user every 6 months, so all of them will have the same GPU and we can go with direct Assembler to the chip.  Who sends a mail to nVidia and ATI to get the best offer?
Comment 55 gabe 2011-04-13 12:15:40 PDT
(In reply to comment #54)
> (In reply to comment #53)
> > Here's an example of the layers that are between FF and running natively:
> > https://wiki.mozilla.org/Gecko:Layers
> 
> Crazy abstraction! I suggest to gift a new video card to each user every 6
> months, so all of them will have the same GPU and we can go with direct
> Assembler to the chip.  Who sends a mail to nVidia and ATI to get the best
> offer?
 youed need new pc every 6 months things change so rapidly old motherboards dont support new gpu 

also writing a browser in Assembly langauge would be impossable though i bet such a browser would also be insanly fast (would probably take the resources of every web browser maker working on single browser over 100 years to make that)
Comment 56 Reece H. Dunn 2011-04-13 13:34:01 PDT
I always knew the IE team was behind the curve. Don't they know they need to support Native Living HTML [http://www.whatwg.org/specs/web-apps/current-work/multipage/index.html]!
Comment 57 Daniel Abromeit 2011-04-13 16:47:26 PDT
oh c'mon - the whole thing is a ridiculous question for philosphy-nerds. 

don't you remember the bulls**tbingo in all the microsoft-blogs when ie8 came out? lots and lots of improper statements about uh-uh webstandards and performance. (hey marketing is not about lying to the people)

please set this to 'wontfix' or whatever. 


regards
~ d.abromeit
http://www.w3.org/wiki/User:Dabromei
Comment 58 patrickjdempsey 2011-04-13 17:54:03 PDT
Is this a regression?  Can we get this tracked?  I'm pretty sure I remember watching fish swim around in Native HTML5 in Firefox back in 2009. 

Or maybe the problem is that Firefox lacks 3 different Confirmation popups before rendering  any HTML5 content?  That would certainly make it feel more native for me.
Comment 59 Daniel Buchner [:dbuc] 2011-04-13 18:10:23 PDT
(In reply to comment #58)
> Is this a regression?  Can we get this tracked?  I'm pretty sure I remember
> watching fish swim around in Native HTML5 in Firefox back in 2009. 
> 
> Or maybe the problem is that Firefox lacks 3 different Confirmation popups
> before rendering  any HTML5 content?  That would certainly make it feel more
> native for me.

Well when you're interacting with something native within a page within an app within an OS, you need those 3 different levels of popups to kick you back up each level or you may lose your grip on reality and be trapped indefinitely...http://inception.davepedu.com/
Comment 60 Dac Chartrand 2011-04-13 18:59:54 PDT
Needs more aboriginals, inuits, and first nations.
Comment 61 Jeff Hammel 2011-04-13 20:09:45 PDT
(In reply to comment #3)
> (In reply to comment #1)
> > I believe the definition Jeff suggested was that "Native HTML5" would be a
> > browser optimized for your hardware, without compatibility layers like Windows
> > getting in the way.
> 
> I don't think general-purpose hardware actually supports Native HTML5.  Wake me
> up when we have HTML5 coprocessors.

So it's settled: Mozilla's Q2 goal will be developing the HTML5 coprocessor.  I'm not sure who here has expertise in fab technologies or chip design.  Maybe philikon and myself and handle the plasma etching.  Anyone know a whole helluva lot about lithography?  Or preferably have good contacts at motorola/intel/samsung/foxcon etc?  We're going to have to get these things on motherboards this year if we want to make an impact, preferably with a dedicated link to the CPU/GPU.  Should I put this as a Firefox 5/6 blocker?
Comment 62 Dave Herman [:dherman] 2011-04-13 20:14:25 PDT
(In reply to comment #61)
> So it's settled: Mozilla's Q2 goal will be developing the HTML5 coprocessor. 
> I'm not sure who here has expertise in fab technologies or chip design.  Maybe
> philikon and myself and handle the plasma etching.  Anyone know a whole helluva
> lot about lithography?  Or preferably have good contacts at
> motorola/intel/samsung/foxcon etc?  We're going to have to get these things on
> motherboards this year if we want to make an impact, preferably with a
> dedicated link to the CPU/GPU.  Should I put this as a Firefox 5/6 blocker?

I think we have some local expertise with plasma etching:

http://twitter.com/#!/djwitte/status/57259417133002752

Dave
Comment 63 Shawn Wilsher :sdwilsh 2011-04-13 20:29:51 PDT
(In reply to comment #61)
> So it's settled: Mozilla's Q2 goal will be developing the HTML5 coprocessor. 
> I'm not sure who here has expertise in fab technologies or chip design.  Maybe
> philikon and myself and handle the plasma etching.  Anyone know a whole helluva
> lot about lithography?  Or preferably have good contacts at
> motorola/intel/samsung/foxcon etc?  We're going to have to get these things on
> motherboards this year if we want to make an impact, preferably with a
> dedicated link to the CPU/GPU.  Should I put this as a Firefox 5/6 blocker?
The Firefox 5 train has already left; sorry!
Comment 64 dwitte@gmail.com 2011-04-13 20:41:36 PDT
(In reply to comment #62)
> I think we have some local expertise with plasma etching:

Fortuitously, lithography as well. I heartily approve of the fact that Mozilla is willing to pour a few million dollars into getting its very own piece of silicon. For that amount of effort and expense, though, we shouldn't stop at HTML5. Who'd like to volunteer to rewrite Places in Verilog?
Comment 65 Philipp von Weitershausen [:philikon] 2011-04-13 20:41:36 PDT
(In reply to comment #62)
> I think we have some local expertise with plasma etching:
> 
> http://twitter.com/#!/djwitte/status/57259417133002752

Yes. Bug 645260 is related, suggesting a different approach to improving perf. Turns out [ecto1-parity] just isn't as important as [ie-parity].

FWIW, I'm not sure that hardware is the answer. beltzner clearly points out in comment 25, that the only way to get better scores on the native HTML5 benchmark is to run on top of IE on top of Windows. Maybe it's time reconsider Gecko as our platform?

We've been teaching the world that the web is the operating system we make, I think it's time that we'd embrace this ourselves! I mean, it's not like we don't have the technology:

* Jägermonkey could easily be replaced with Narcissus
* gal's js-dom will give us a great head start for excellent HTML5 DOM compliance
* azakai's emscripten will help us port any legacy C++ code to the web platform

Am I missing anything?
Comment 66 Dave Herman [:dherman] 2011-04-13 21:07:25 PDT
(In reply to comment #65)
> * Jägermonkey could easily be replaced with Narcissus
> * gal's js-dom will give us a great head start for excellent HTML5 DOM
> compliance
> * azakai's emscripten will help us port any legacy C++ code to the web platform
> 
> Am I missing anything?

I think we can do better. We should capitalize on bleeding-edge research and build on the recent result that HTML5 + CSS3 is Turing Complete:

http://lambda-the-ultimate.org/node/4222

So HTML5 + CSS3 can be reduced to a Turing Machine, which can implement a 2PDA. From there we can build a lambda calculus interpreter (no problem), which is just a stone's throw, of course, from JavaScript. That's where azakai comes in. Naturally, thanks to IE this will all be running, um, natively.

Dave
Comment 67 Philipp von Weitershausen [:philikon] 2011-04-13 21:49:17 PDT
(In reply to comment #66)
> I think we can do better. We should capitalize on bleeding-edge research and
> build on the recent result that HTML5 + CSS3 is Turing Complete:
> 
> http://lambda-the-ultimate.org/node/4222

I'd hate to rain fish on your parade, but sadly the underlying platform code (https://github.com/elitheeli/oddities) only runs well in WebKit browsers. I'm afraid there's still lots of platform work (extremely hairy CSS, I presume) to be done to get us running natively on IE.

> So HTML5 + CSS3 can be reduced to a Turing Machine, which can implement a 2PDA.
> From there we can build a lambda calculus interpreter (no problem), which is
> just a stone's throw, of course, from JavaScript. That's where azakai comes in.
> Naturally, thanks to IE this will all be running, um, natively.

I can see how this will make us run faster and more natively. If we overcome the underlying platform issues, it sounds too good to be true!
Comment 68 Marco Bonardo [::mak] 2011-04-14 04:49:30 PDT
(In reply to comment #64)
> Who'd like to volunteer to rewrite Places in Verilog?

Looks like you just offered to do that, rs=me.
Comment 69 gabe 2011-04-14 07:00:25 PDT
speaking relesticly on 64 bit windows microsoft has the only native shiping 64 bit browser to best of my knowlodge maybe thats what they meant
Comment 70 Boris Zbarsky [:bz] (still a bit busy) 2011-04-14 07:54:27 PDT
That's true.  We should do just like them and ship a "native" 64-bit browser that does all its JS implementation natively instead of using the CPU.

But if we actually jit instead (unlike 64-bit IE), then we're more completely hardware accelerated, right?

Tough call!
Comment 71 Reece H. Dunn 2011-04-14 08:05:13 PDT
Easy -- run user/application JavaScript on narcissus that is running on the jitted 64-bit JavaScript engine, then you have JavaScript running on native JavaScript running on hardware accelerated JavaScript: problem solved!
Comment 72 Dmitriy 2011-04-14 13:47:52 PDT
I believe all the above solutions do not address the main problem. We are not running natively on the USER. Thats right, we must implement Firefox to run natively on the user's brain. This way there is no performance barrier. 

note: ensure no bugs are present or we risk turning our users into vegetables, which is not on the firefox's diet. However this is worth the risk of beating MS at their own game at a truly native client.
Comment 73 Jeff Hammel 2011-04-14 13:56:27 PDT
TCPoT (TCP over Telepathy) should be implemented first.  I believe this is still planned with the upcoming 1.0pre release of homo-superior
Comment 74 Reece H. Dunn 2011-04-14 14:09:05 PDT
I also propose creating a DIP addressing scheme (DNA Internet Protocol) to ensure that the intended recipient of the Telepathic Packet is correctly identified and that there are sufficient addresses to identify each user (although we will need to solve the problem of identical twins (same DNA address) and other issues).
Comment 75 JR Conlin [:jrconlin,:jconlin] 2011-04-14 14:46:43 PDT
(In reply to comment #74)
> I also propose creating a DIP addressing scheme (DNA Internet Protocol) to
> ensure that the intended recipient of the Telepathic Packet is correctly
> identified and that there are sufficient addresses to identify each user
> (although we will need to solve the problem of identical twins (same DNA
> address) and other issues).

There is a flaw in this. DIP would require a relay period of approximately 13-18 years (depending on statutory laws). I'd recommend IPV (IP over Virus), only I don't want to be manning the crash cart.
Comment 76 Calc-Yolatuh 2011-04-14 16:16:07 PDT
This is news? Scholastic had a piece about Native HTML long ago: http://goo.gl/H8R66

I propose that we acquire one of these tomes, and implement Native HTML5 that is compatible with prior implementations.
Comment 77 Kahawe Dawnstrider 2011-04-15 03:57:57 PDT
> Websites run best when using native code and transmitted via an optimized binary protocol.

While we are at it, I have to firmly disagree with the whole "native" idea and binary protocols.

You will just never achieve the same kind of warmth, transparency and open, three dimensional presentation and the unbelievable musicality, err I mean, readability of analog tube computers, browsers and protocols. I for one will stick with my UNIVAC II mono blocks, thankyouverymuch.
Comment 78 Dmitriy 2011-04-15 07:03:16 PDT
I sure (In reply to comment #77)
> > Websites run best when using native code and transmitted via an optimized binary protocol.
> 

I sure hope that nobody starts using that binary code using hex, that would not be optimized or native. On that note, the only true way to display HTML natively is using optimized binary format. Screw css, we need just ones and zeroes. We need to start implementing the BML (Binary Markup Language) and represent it properly and quickly on the screen. We can optimize the experience to not needing the mouse since clicking will be pointless. We'll just give users a terminal. After that we can start doing optimizations like not displaying all the help all the time and converting them to man pages.

The only problem is that we'll need to start teaching kids in pre-school to read and understand binary. Which is fine, its optimized, it should be faster and more native.
Comment 79 gadjo 2011-04-15 07:21:36 PDT
(In reply to comment #78)
> The only problem is that we'll need to start teaching kids in pre-school to
> read and understand binary. Which is fine, its optimized, it should be faster
> and more native.

For this binary format a separate standardization group should be created, otherwise some browsers will support zeros and ones and some other browser will support zeros and threes - this may lead to big incompatibilities between browsers.

Anyway I don't think it's a good place for discussions, if you have any constructive comment or patch for this bug then ok, if not just let guys to do their work as we'll never be native.
Comment 80 Daniel Glazman (:glazou) 2011-04-15 07:50:41 PDT
Sure Microsoft also has a native html5 debugger. I wonder what native errors
look like.
Comment 81 JR Conlin [:jrconlin,:jconlin] 2011-04-15 08:02:08 PDT
While trying the direct binary interface on a few, err, we'll call them "test subjects of uncertain willingness" there have been a few reports of "notable client crashes" similar to the following:
http://www.youtube.com/watch?v=IANjVcohKO4

(Separate bug will be filled from international waters)

I would recommend against the direct visual binary interface in lieu of a more calm, synthesized voice speaking the one or zero. Possibly with soothing "new age" style music being played in the background. This may detrimentally effect page delivery speeds, however ad impression counts should rise favorably after individuals reawaken and attempt to reload the page without falling asleep again.
Comment 82 Dave Herman [:dherman] 2011-04-15 09:37:02 PDT
A binary interface is such an important idea I stayed up all night designing it. Here's my draft proposal:

    RFC 24601: Binary Markup Language (BML) -- DRAFT
    
    1. Abstract
    BML is a lightweight, binary data interchange format. It is designed to be extensible and compatible with most mainstream, modern computer architectures. It's native, so that's good.
    
    2. Grammar
    The following grammar is given in the extended BNF (Backus-Naur Form) of RFC 822.
    
    <bigit> ::= "0" | "1"
    <page> ::= <bigit>*
    
    3. Extensions
    For the good of programmers, the web should never change, so no extensions to the BML grammar will be considered valid BML. See also: RFC 4627.
    
    4. Semantics
    None. See also: RFC 4627.
    
    5. Prior art: none that I'm aware of (TODO: should we patent?)

I'm still working on the companion documents:

    RFC 24602: Representation of BML in XML
    Table of contents
    1. Abstract
    2. The binarymarkuplanguage DTD
    3. The binarymarkuplanguage namespace
    4. The <binarymarkuplanguage:page> tag
    5. The <binarymarkuplanguage:bigit> tag
    6. Comparison to OOXML

    RFC 24603: Representation of HTML5 in BML
    Table of contents
    1. Abstract
    2. Unicode
    ...
    4. Profit

Dave
Comment 83 Valentijn Sessink 2011-04-15 13:23:56 PDT
@ #69, #70: I think the first step for native HTML5 is to get out HTML5-64 - with Javascript64 and CSS3-64. (I suppose the regular HTML5 is actually HTML-32-bit, right? All this machine language and chip etching talk made me think it might be 16 bit, but then I've seen some pretty long URL's lately, like "micros~1.com" so it *can* do long file names so I'm sure it's 32 bit after all.)
Comment 84 Calc-Yolatuh 2011-04-15 13:52:11 PDT
I would submit that we cannot rule out Native Hex support. Beyond the natural symmetry of hex coding, other native methods like {voodoo}() take it as a prerequisite. You can't call voodoo methods without a hex API.
Comment 85 Jo Hermans 2011-04-15 14:48:37 PDT
With all this talk about Native HTML5, haven't we forgotten about Alien HTML5 ? For proof, see <about:robots>.

I, for one, would welcome support for our black monolith overlords.
Comment 86 Graham 2011-04-15 17:31:30 PDT
(In reply to comment #78)
> The only problem is that we'll need to start teaching kids in pre-school to
> read and understand binary. Which is fine, its optimized, it should be faster
> and more native.

I think you're on to something here. Kids would only actually learn 10 things, so those with all thumbs would be better prepared for life.
Comment 87 tz 2011-04-16 07:47:28 PDT
This is the Nightmare before Christmas memo.
They used to be called "Halloween Memos", but apparently they want the feast of the Nativity too.

And you are forgetting the most critical part.  You need to implement HTML5 Genuine Advantage so that if something detects that the hardware changes or that the video isn't going through a properly encrypted path you half-disable everything and pop-up nasty messages until someone phones Mozilla on a 900 number or with a credit card.
Comment 88 Dmitriy 2011-04-16 09:21:05 PDT
(In reply to comment #87)
> This is the Nightmare before Christmas memo.
> They used to be called "Halloween Memos", but apparently they want the feast of
> the Nativity too.
> 
> And you are forgetting the most critical part.  You need to implement HTML5
> Genuine Advantage so that if something detects that the hardware changes or
> that the video isn't going through a properly encrypted path you half-disable
> everything and pop-up nasty messages until someone phones Mozilla on a 900
> number or with a credit card.

Oh man, I completely forgot. We don't want those filthy software pirates stealing our HTML5 native execution engine. Filthy bastards. Our software will be free, but by god we will only allow three simultaneous installations and will require a brain-implanted chip to validate your identity.
Comment 89 Henri Sivonen (:hsivonen) 2011-04-16 09:55:17 PDT
I believe this needs to be more holistic than just parser.
Comment 90 Jonadab the Unsightly One (Nathan Eady) 2011-04-20 14:54:35 PDT
> HTML5 + CSS3 can be reduced to a Turing Machine, 
> which can implement a 2PDA.  From there we can build 
> a lambda calculus interpreter (no problem), which is
> just a stone's throw, of course, from JavaScript...

If you can make it run native in Emacs, you'll make an old geek very happy.
Comment 92 turgut@kalfaoglu.com 2011-07-08 02:31:50 PDT
I'm a native of Turkey (well, I was born in The UK), can I still enjoy native HTML 5 under Fedora/Firefox, or do I need to run out and purchase windows?
Comment 93 Tony Mechelynck [:tonymec] 2011-07-08 02:46:53 PDT
(In reply to comment #92)
> I'm a native of Turkey (well, I was born in The UK), can I still enjoy
> native HTML 5 under Fedora/Firefox, or do I need to run out and purchase
> windows?

The keyword here is "native". By the criterion in comment #1, you can enjoy native HTML5 on any browser which runs on the bare metal, *without* a compatibility layer like Fedora or Windows (or XPCOM, for that matter) in between. Now you tell me where I can get one.
Comment 94 turgut@kalfaoglu.com 2011-07-08 03:04:39 PDT
but but that nice man at Microsoft told me that I *had* to get windows to enjoy native HTML5, even though I was born elsewhere.. ok ok, enough of this :)  what a bunch of BS :)
Comment 95 Mike Beltzner [:beltzner, not reading bugmail] 2011-07-08 06:03:54 PDT
http://www.theregister.co.uk/2011/07/07/microsoft_abandons_native_html_pitch/

Looks like the spec won't ever be published or pursued, so this bug is now INVALID.
Comment 96 docileshark 2011-07-08 07:03:25 PDT
I'll laugh along when FF is faster... what's ironic here is that Joe Drew has actually been working on this already; see "Introducing the Azure Project" (http://blog.mozilla.com/joe/2011/04/26/introducing-the-azure-project/), via Comparing Performance: Azure vs Cairo (http://www.basschouten.com/blog1.php/comparing-performance-azure-vs-cairo)

Specifically, after enumerating all the problems with the graphics layers in FF he writes: 

What can we do about it?
We would very much like to remove these unnecessary conversions and state tracking. <..> Mozilla needs a stateless graphics API that’s closer both to platform APIs and hardware. <...>

The Azure project
To accomplish this, the Mozilla graphics team is creating a new 2D graphics API. It’s going to be stateless, and significantly closer to Direct2D.
Comment 97 Sam "SammyTheSnake" Penny 2011-07-08 07:10:17 PDT
(In reply to comment #93)
> ... you can enjoy
> native HTML5 on any browser which runs on the bare metal, *without* a
> compatibility layer like Fedora or Windows (or XPCOM, for that matter) in
> between. Now you tell me where I can get one.

http://www.armory.com/~spectre/cwi/hl/

Presumably support for HTML5 will be forthcoming.

HTH
Cheers & God bless
    Sam "SammyTheSnake" Penny
Comment 98 patrickjdempsey 2011-07-08 14:07:01 PDT
This is disappointing... I'm really tired of Mozilla following the herd.  C'mon guys, be innovative!  The fact that Microsoft has pulled IE out of the Native HTML5 race means that Firefox could easily be the world leader in a technology that everyone capable of rational thought seems to think is impossible!  Maybe someone should create a Native HTML5 fork of Firefox called "Windmill"?
Comment 99 Nicholas Nethercote [:njn] 2011-07-08 14:09:28 PDT
(In reply to comment #98)
> Maybe someone should create a Native HTML5 fork of Firefox called "Windmill"?

Mike "Quixote" Beltzner is your man.

Note You need to log in before you can comment on or make changes to this bug.