A
admin
Guest
By Scott M. Fulton, III, Net1News
With the HTML 5 crowd increasing in volume - both in terms of numbers and noise - Mozilla is looking to regain sole possession as standard-bearer for Web standards. Last Tuesday, with the release of Beta 5 of its upcoming Firefox 4, the organization opened up public comment on its own experiment with a possible browser-based API for audio, which may later open up doors for a video API as well. If it gains traction, it could enable Web developers to develop on-screen tools for visualizing and accessing the data contained within an audio stream.
This could become one of the key distinguishing factors between HTML 5-based multimedia and add-on codec-based multimedia, should the idea catch on. Essentially, it enables the Web page to access the browser's multimedia data, opening up a treasure trove of possible new Web apps. Imagine an Audacity-like audio editor, but entirely in HTML, CSS, and JavaScript. Or imagine Pandora without Flash.
Last month, David Humphrey, a Seneca College professor and head of the Mozilla Foundation's educational effort found his experiment incorporated in Firefox 4. Last week, it became part of the public beta.
"When we started these experiments, we did so without needing permission," Humphrey wrote on his personal blog, "I didn't have to sign an NDA, go talk to and convince the right people, or get approvals. I just grabbed the source code and started messing around. And I did make a mess, at first. I learned as I went, and we iterated on the API a lot. . . We weren't judged for doing it wrong, or for the pace or directions we took. Instead, we heard of lot of, 'This is very cool!' and, 'Have you thought about this?' We were able to take one of the world's premier applications (Firefox) and rework it."
One test of Humphrey's experimental API involves producing a graph (using HTML 5's Canvas element, of course) in sync with the time track on Firefox's built-in audio player, showing the relative volume levels of the entire track at certain points in time.
Humphrey's contribution now stands a chance of becoming a part of the way the Web works, when the HTML 5 standard is finally formalized. But by W3C's own estimates, that could literally be the year 2020. And in the meantime, it may have to withstand some pressure from competitors who will probably point out that Mozilla's experiment, for the time being, bears Mozilla's exclusive trademark.
Everybody wants in on the act
Last winter, browser makers held out hope that HTML 5, the next iteration of the Web's lingua franca, would be the driving force for a new wave of change that could compel users to conceivably switch brands. But what turned out the following summer to be an agreement not to agree on one of HTML 5's key elements - built-in video and audio using open codecs - made HTML 5 a kind of "jump ball" for browser makers. Now, each one - including Microsoft and Apple - is staking its own claim as to how built-in audio should be deployed, and it's every browser for itself.
What consensus there has been thus far has centered around the formation of the and tags used in Web pages. Engineers don't want to make Web authors employ hacks, or tricks such as Internet Explorer's famous "conditional comments," to make one browser brand interpret one block of code and another brand a separate block. Apple's Safari developer's page reveals the iPhone and Mac maker's approach to implementation, including listing different formats of streams within the element tags, sorted in order of which ones the browser is most likely to execute on its own (assuming the developer is able to guess).
Just last February, Adobe pronounced that waiting for browser makers to iron out their HTML 5 differences would result in a situation where "users and content creators would be thrown back to the dark ages of video on the Web with incompatibility issues." Conservative estimates peg Adobe Flash with at least three-fourths of the Web's video, along with a sizable chunk of the Web's rich functionality. That functionality is provided through a browser add-on, the very existence of which HTML 5 was originally supposed to eschew. But now, Adobe finds itself employing its own "embrace and extend" strategy, which included releasing an HTML 5 pack for Adobe Illustrator that enables Web drawings in SVG using the Canvas element, as an alternative to Flash.
Making sure it keeps one toe in every ocean, Google - whose Chrome browser continues to gain share against Firefox - is now actively promoting HTML 5, while at the same time building Flash directly into every Chrome build. . . while at the same time developing its own WebM codec that is neither of the above.
Add to all of this the fact that this Wednesday, Microsoft will attempt to seize leadership of the HTML 5 message, with its first public beta of Internet Explorer 9. It's already planning a blended message of "beauty" and "HTML 5 compliance" that some members of the press are already eating up like free donuts.
This article originally appeared in Net1News.
©Copyright 2010 Ingenus, LLC.
©Copyright 2010 BetaNews, Inc.
Defending the 'Moz-method'
It's amid this chaos that Mozilla finds itself clamoring to reassert itself. With a much stronger PR campaign for Firefox 4 than for version 3.5 or any earlier edition, Mozilla hopes to forestall Microsoft's message of speed, "beauty," and standards-compliance.
But in so doing, it will probably have to answer for this: The new Firefox 4 experimental audio API will use the browser-specific prefix Moz-, as in MozAudioAvailable. This is a method that some Web developers have argued against, equating it with the kind of "hacks" that make IE6 support such a pain for those still forced to implement it by their superiors.
So Mozilla has an answer for the naysayers: Firefox always has been an incubator for standards, and incubators by definition are kept tight and warm until their chicks are ready to be released.
"As part of the W3C's experimental audio incubator, we are working with other browser makers and Web developers to define a standard for all browsers to implement," responds Firefox principal engineer Vladimir Vukicevic, to our question on the prominent prefix. "During the experimental phase we use a 'vendor prefix,' as the W3C encourages. Developers who do experimental work with the Moz- prefixed APIs will provide us with valuable data about use cases that we can incorporated into a final standard. Once a final standard is agreed upon, the Moz- prefixes will be dropped. "Indeed, long-time Mozilla contributors are familiar with this method of incubation. It's currently in use in conjunction with ideas such as events for responding to sideways tips of the screen, as with devices like the iPhone. And the history of CSS is replete with instances where -moz- was tacked onto trial attributes that were left unprocessed by IE.
But in today's more politically charged, if historically apathetic, Web atmosphere, the taint of specificity can be confused with outright exclusivity. Some commenters already greeted Mozilla's announcements last week as "gimmicks." Over on Slashdot, Firefox is being trashed by commenters who argue that Mozilla is becoming a kind of clique, listening only to its most cherished and preferred contributors while leaving suggestions on Bugzilla to rust.
Firing up the incubator
Another case in point: Mozilla's increased promotion for Direct3D hardware accelerated graphics in Firefox 4 for Windows. Direct3D is a Microsoft platform which, of course, is unavailable in Linux or Mac OS. For those OS platforms, Firefox 4 will support OpenGL. This actually isn't news, and hasn't been for several months; still, last Tuesday's Direct3D and Direct2D demonstrations were met with skepticism on Slashdot. Commenter [B]Darkness404[/B] wrote, "What good is having GPU acceleration that only works on one platform? The entire point of the trend of doing things in-browser is to make cross-platform compatibility a reality. If I wanted a game to work just on Windows, why wouldn't I just make an application that did that?"
Thus Vukicevic's public stance, which is to show Firefox as the leader of a cross-platform effort that merely has yet to cross platforms.
"Mozilla's goal is to deliver high-quality and performant rendering of HTML content, including technologies like and WebGL," he tells us. "Under the hood, we leverage the best possible technology on a given platform to deliver that experience. For Windows, Direct2D fit our needs and is comparable to Quartz on Mac and X Render on Linux, which we already have been using in previous versions of Firefox.
"For new functionality that requires 3D acceleration, we turned to OpenGL and Direct3D," he continues. "Direct3D is the default method on Windows, as it currently provides the best experience for the majority of our Windows users. On all other platforms, we'll use OpenGL to provide an identical level of acceleration. Our goal is ultimately to make sure that developers don't have to think about the platform their application is running on, and know that they can take advantage of the latest HTML features to deliver a visually rich experience in their Web applications."
Vukicevic pointed us to the blog of Web applications developer Douglas Alan Schepers, whose current experiment with Mozilla's trial audio API is an SVG-based virtual synthesizer keyboard. Last May, Schepers saw the conference session where Humphrey and others first demonstrated their experimental alteration to Firefox, exposing audio data through API calls and events. "I immediately knew I wanted to see this as a part of the native functionality of the Web platform, across browsers," Schepers wrote. "In some ways, it's the last major missing piece from the open Web: the ability to view source and hack sound, the last commonly digitizable sensorium. I also knew that I wanted the use cases and requirements to come from the larger community, the musicians and UI designers and developers who will ultimately be the ones using this functionality to sound out the depths of what's possible on the Web."
Mozilla's Vukicevic contends that, had that demo not happened and had Firefox not enabled it to happen, we wouldn't even be talking about opening the audio API to developers at all. "The current work to standardize audio in the browser at the W3C," he tells us, "is the direct result of Mozilla's willingness to incorporate the experimental API."
This article originally appeared in Net1News.
©Copyright 2010 Ingenus, LLC.
©Copyright 2010 BetaNews, Inc.
Copyright Betanews, Inc. 2010
[IMG]http://images.pheedo.com/images/mm/digg_64x16.png[/IMG] [IMG]http://images.pheedo.com/images/mm/google.png[/IMG] [IMG]http://images.pheedo.com/images/mm/slashdot.png[/IMG] [IMG]http://images.pheedo.com/images/mm/twitter.png[/IMG] [IMG]http://images.pheedo.com/images/mm/delicious.gif[/IMG] [IMG]http://images.pheedo.com/images/mm/facebook.gif[/IMG] [IMG]http://images.pheedo.com/images/mm/technorati.png[/IMG]
[IMG]http://ads.pheedo.com/img.phdo?p=1[/IMG]
[IMG]http://feeds.feedburner.com/~ff/bn?d=yIl2AUoC8zA[/IMG] [IMG]http://feeds.feedburner.com/~ff/bn?i=LtEOjpBPGrs:RUrJHacDvmA:V_sGLiPBpWU[/IMG] [IMG]http://feeds.feedburner.com/~ff/bn?d=qj6IDK7rITs[/IMG]
With the HTML 5 crowd increasing in volume - both in terms of numbers and noise - Mozilla is looking to regain sole possession as standard-bearer for Web standards. Last Tuesday, with the release of Beta 5 of its upcoming Firefox 4, the organization opened up public comment on its own experiment with a possible browser-based API for audio, which may later open up doors for a video API as well. If it gains traction, it could enable Web developers to develop on-screen tools for visualizing and accessing the data contained within an audio stream.
This could become one of the key distinguishing factors between HTML 5-based multimedia and add-on codec-based multimedia, should the idea catch on. Essentially, it enables the Web page to access the browser's multimedia data, opening up a treasure trove of possible new Web apps. Imagine an Audacity-like audio editor, but entirely in HTML, CSS, and JavaScript. Or imagine Pandora without Flash.
Last month, David Humphrey, a Seneca College professor and head of the Mozilla Foundation's educational effort found his experiment incorporated in Firefox 4. Last week, it became part of the public beta.
"When we started these experiments, we did so without needing permission," Humphrey wrote on his personal blog, "I didn't have to sign an NDA, go talk to and convince the right people, or get approvals. I just grabbed the source code and started messing around. And I did make a mess, at first. I learned as I went, and we iterated on the API a lot. . . We weren't judged for doing it wrong, or for the pace or directions we took. Instead, we heard of lot of, 'This is very cool!' and, 'Have you thought about this?' We were able to take one of the world's premier applications (Firefox) and rework it."
One test of Humphrey's experimental API involves producing a graph (using HTML 5's Canvas element, of course) in sync with the time track on Firefox's built-in audio player, showing the relative volume levels of the entire track at certain points in time.
Humphrey's contribution now stands a chance of becoming a part of the way the Web works, when the HTML 5 standard is finally formalized. But by W3C's own estimates, that could literally be the year 2020. And in the meantime, it may have to withstand some pressure from competitors who will probably point out that Mozilla's experiment, for the time being, bears Mozilla's exclusive trademark.
Everybody wants in on the act
Last winter, browser makers held out hope that HTML 5, the next iteration of the Web's lingua franca, would be the driving force for a new wave of change that could compel users to conceivably switch brands. But what turned out the following summer to be an agreement not to agree on one of HTML 5's key elements - built-in video and audio using open codecs - made HTML 5 a kind of "jump ball" for browser makers. Now, each one - including Microsoft and Apple - is staking its own claim as to how built-in audio should be deployed, and it's every browser for itself.
What consensus there has been thus far has centered around the formation of the and tags used in Web pages. Engineers don't want to make Web authors employ hacks, or tricks such as Internet Explorer's famous "conditional comments," to make one browser brand interpret one block of code and another brand a separate block. Apple's Safari developer's page reveals the iPhone and Mac maker's approach to implementation, including listing different formats of streams within the element tags, sorted in order of which ones the browser is most likely to execute on its own (assuming the developer is able to guess).
Just last February, Adobe pronounced that waiting for browser makers to iron out their HTML 5 differences would result in a situation where "users and content creators would be thrown back to the dark ages of video on the Web with incompatibility issues." Conservative estimates peg Adobe Flash with at least three-fourths of the Web's video, along with a sizable chunk of the Web's rich functionality. That functionality is provided through a browser add-on, the very existence of which HTML 5 was originally supposed to eschew. But now, Adobe finds itself employing its own "embrace and extend" strategy, which included releasing an HTML 5 pack for Adobe Illustrator that enables Web drawings in SVG using the Canvas element, as an alternative to Flash.
Making sure it keeps one toe in every ocean, Google - whose Chrome browser continues to gain share against Firefox - is now actively promoting HTML 5, while at the same time building Flash directly into every Chrome build. . . while at the same time developing its own WebM codec that is neither of the above.
Add to all of this the fact that this Wednesday, Microsoft will attempt to seize leadership of the HTML 5 message, with its first public beta of Internet Explorer 9. It's already planning a blended message of "beauty" and "HTML 5 compliance" that some members of the press are already eating up like free donuts.
This article originally appeared in Net1News.
©Copyright 2010 Ingenus, LLC.
©Copyright 2010 BetaNews, Inc.
Defending the 'Moz-method'
It's amid this chaos that Mozilla finds itself clamoring to reassert itself. With a much stronger PR campaign for Firefox 4 than for version 3.5 or any earlier edition, Mozilla hopes to forestall Microsoft's message of speed, "beauty," and standards-compliance.
But in so doing, it will probably have to answer for this: The new Firefox 4 experimental audio API will use the browser-specific prefix Moz-, as in MozAudioAvailable. This is a method that some Web developers have argued against, equating it with the kind of "hacks" that make IE6 support such a pain for those still forced to implement it by their superiors.
So Mozilla has an answer for the naysayers: Firefox always has been an incubator for standards, and incubators by definition are kept tight and warm until their chicks are ready to be released.
"As part of the W3C's experimental audio incubator, we are working with other browser makers and Web developers to define a standard for all browsers to implement," responds Firefox principal engineer Vladimir Vukicevic, to our question on the prominent prefix. "During the experimental phase we use a 'vendor prefix,' as the W3C encourages. Developers who do experimental work with the Moz- prefixed APIs will provide us with valuable data about use cases that we can incorporated into a final standard. Once a final standard is agreed upon, the Moz- prefixes will be dropped. "Indeed, long-time Mozilla contributors are familiar with this method of incubation. It's currently in use in conjunction with ideas such as events for responding to sideways tips of the screen, as with devices like the iPhone. And the history of CSS is replete with instances where -moz- was tacked onto trial attributes that were left unprocessed by IE.
But in today's more politically charged, if historically apathetic, Web atmosphere, the taint of specificity can be confused with outright exclusivity. Some commenters already greeted Mozilla's announcements last week as "gimmicks." Over on Slashdot, Firefox is being trashed by commenters who argue that Mozilla is becoming a kind of clique, listening only to its most cherished and preferred contributors while leaving suggestions on Bugzilla to rust.
Firing up the incubator
Another case in point: Mozilla's increased promotion for Direct3D hardware accelerated graphics in Firefox 4 for Windows. Direct3D is a Microsoft platform which, of course, is unavailable in Linux or Mac OS. For those OS platforms, Firefox 4 will support OpenGL. This actually isn't news, and hasn't been for several months; still, last Tuesday's Direct3D and Direct2D demonstrations were met with skepticism on Slashdot. Commenter [B]Darkness404[/B] wrote, "What good is having GPU acceleration that only works on one platform? The entire point of the trend of doing things in-browser is to make cross-platform compatibility a reality. If I wanted a game to work just on Windows, why wouldn't I just make an application that did that?"
Thus Vukicevic's public stance, which is to show Firefox as the leader of a cross-platform effort that merely has yet to cross platforms.
"Mozilla's goal is to deliver high-quality and performant rendering of HTML content, including technologies like and WebGL," he tells us. "Under the hood, we leverage the best possible technology on a given platform to deliver that experience. For Windows, Direct2D fit our needs and is comparable to Quartz on Mac and X Render on Linux, which we already have been using in previous versions of Firefox.
"For new functionality that requires 3D acceleration, we turned to OpenGL and Direct3D," he continues. "Direct3D is the default method on Windows, as it currently provides the best experience for the majority of our Windows users. On all other platforms, we'll use OpenGL to provide an identical level of acceleration. Our goal is ultimately to make sure that developers don't have to think about the platform their application is running on, and know that they can take advantage of the latest HTML features to deliver a visually rich experience in their Web applications."
Vukicevic pointed us to the blog of Web applications developer Douglas Alan Schepers, whose current experiment with Mozilla's trial audio API is an SVG-based virtual synthesizer keyboard. Last May, Schepers saw the conference session where Humphrey and others first demonstrated their experimental alteration to Firefox, exposing audio data through API calls and events. "I immediately knew I wanted to see this as a part of the native functionality of the Web platform, across browsers," Schepers wrote. "In some ways, it's the last major missing piece from the open Web: the ability to view source and hack sound, the last commonly digitizable sensorium. I also knew that I wanted the use cases and requirements to come from the larger community, the musicians and UI designers and developers who will ultimately be the ones using this functionality to sound out the depths of what's possible on the Web."
Mozilla's Vukicevic contends that, had that demo not happened and had Firefox not enabled it to happen, we wouldn't even be talking about opening the audio API to developers at all. "The current work to standardize audio in the browser at the W3C," he tells us, "is the direct result of Mozilla's willingness to incorporate the experimental API."
This article originally appeared in Net1News.
©Copyright 2010 Ingenus, LLC.
©Copyright 2010 BetaNews, Inc.
Copyright Betanews, Inc. 2010
[IMG]http://images.pheedo.com/images/mm/digg_64x16.png[/IMG] [IMG]http://images.pheedo.com/images/mm/google.png[/IMG] [IMG]http://images.pheedo.com/images/mm/slashdot.png[/IMG] [IMG]http://images.pheedo.com/images/mm/twitter.png[/IMG] [IMG]http://images.pheedo.com/images/mm/delicious.gif[/IMG] [IMG]http://images.pheedo.com/images/mm/facebook.gif[/IMG] [IMG]http://images.pheedo.com/images/mm/technorati.png[/IMG]
[IMG]http://ads.pheedo.com/img.phdo?p=1[/IMG]