Closed Bug 649408 (nativehtml5) Opened 14 years ago Closed 14 years ago

Support Native HTML5

Categories

(Core :: General, defect)

Product:
Core
Component:
General
Platform:
x86
Windows 7
Type:
defect
Priority:
Not set
Severity:
blocker

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: beltzner, Unassigned)

References

(
URL
)

Details

(Whiteboard: [parity-ie][telepathy-needed])

Attachments

(1 file)

The HTML5 coprocessor
90.96 KB, image/jpeg
Details
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."
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.
link to track our progress on this bug: http://arewenativeyet.com/
(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.
Are we sure Microsoft didn't fat-finger that blog post and really meant "naïve HTML5" rather than "native HTML5"?
Oh dear, a "like" button is missing. /me like #2
Alias: nativehtml5
(In reply to comment #3) > Wake me up when we have HTML5 coprocessors. Aha! So is *that* what "full hardware acceleration" means? Dave
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! :)
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.)
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.
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?
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.
Who is producing this native hardware? I want a coprocessor dedicated only to accelerating throbbers.
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
Whiteboard: [parity-ie]
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.
I have said that MS is the most non PR 2.0 compliant vendor for a while now.
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.
#winning
I have the feeling this bug is not enough. We should have a companion "Support Native CSS" bug too.
(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.)
(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.
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.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
I have a Pentium, and the Pentium is accelerating Internet. Can't be better : That's what the ad said.
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...
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?
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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.
(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...
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 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!
Just did a screencast of how bad we are at rendering native HTML5: http://www.youtube.com/watch?v=eSfNIjdXHJY
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?
>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.
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!
> Are you native? Do we need http://www.areyounative.com? I thought going native was generally looked down upon?
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!
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.
I'm sure I can do the french slang l10n for Firefox. Will be totally native for parisian teenagers who barely speak correct french.
(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 !
Every time I hear the word "native" I think of the political movement: http://en.wikipedia.org/wiki/Nativism_%28politics%29 Fitting, I think.
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
(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
Let's do an arduino-based HTML5 native coprocessing unit?
but, it will still not pass the reporter's expected result (see comment 25)
Attached image The HTML5 coprocessor —
Just received an anonymous tip on a newly developed HTML5 coprocessor with a leaked product shot!
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?
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.
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.
(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.
(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!
(In reply to comment #46) chock full of win!
(In reply to comment #46) chock full of win!
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.
(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?
(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)
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]!
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
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.
(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/
Needs more aboriginals, inuits, and first nations.
(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?
Severity: normal → blocker
(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
(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!
(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?
(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?
(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
(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!
(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.
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
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!
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!
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.
TCPoT (TCP over Telepathy) should be implemented first. I believe this is still planned with the upcoming 1.0pre release of homo-superior
Whiteboard: [parity-ie] → [parity-ie][telepathy-needed]
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).
(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.
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.
> 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.
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.
(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.
Sure Microsoft also has a native html5 debugger. I wonder what native errors look like.
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.
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
@ #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.)
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.
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.
(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.
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.
(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.
I believe this needs to be more holistic than just parser.
Component: HTML: Parser → General
QA Contact: parser → general
> 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.
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?
(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.
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 :)
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.
Status: REOPENED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → INVALID
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.
(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
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"?
(In reply to comment #98) > Maybe someone should create a Native HTML5 fork of Firefox called "Windmill"? Mike "Quixote" Beltzner is your man.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: