Slashdot Mirror
Google Funds Ogg Theora For Mobile
An anonymous reader writes "Google has decided to fund the development of Theora optimized for ARM processors. The article on the Open Source at Google blog notes the importance of having a universal baseline video codec for the Web: 'What is clear though, is that we need a baseline to work from — one standard format that (if all else fails) everything can fall back to. This doesn't need to be the most complex format, or the most advertised format, or even the format with the most companies involved in its creation. All it needs to do is to be available, everywhere. The codec in the frame for this is Ogg Theora, a spin off of the VP3 codec released into the wild by On2 a couple of years ago.'"
This is awesome! Not to detract from it, but why is there so much more love for Theora than for Dirac?
Chris DiBona of the Google open source group claimed that "If [youtube] were to switch to theora and maintain even a semblance of the current youtube quality it would take up most available bandwidth across the Internet."
This was shown to be false.
Mr DiBona then mysteriously vanished without trace.
Could he please manifest and either (a) support his claims or (b) concede his error?
Thanks ever so much.
http://rocknerd.co.uk
The technically inferior is set to become the ubiquitously available option because the better option is entangled in non-technical problems.
why optimize for the low end, when the high end also needs a boost? ;)
After all, Theora is not covered by most graphics card's built in video deocders.
Christian
still, hats off to those who have remained focused/selfless. nobody ever sees their efforts, as anything worthwhile becomes assimilated with little/no fanfare/recognition/compensation to the people who actually accomplish the task at hand.
XML serialization of HTML is still there. XForms... I never heard it worked in any browser sans some 3rd party plugins.
So, please, describe what's rubbish in HTML. Those new elements are _needeed_ anyway. It's better to have them than to implement anew every time you need them.
I don't understand what's you problem with audio and video either. They are here anyway with flash. You can disable flash. You can disable audio/video if you really want to. Your problem is?
Quick way to get 30% Funny 70% Troll: defend Opera browser on
Meh, getting 503s trying to log in. Sorry for the A/C Post.
XHTML was interesting and lovely, and no one gave a shit. Ideology loses to practicality in almost every case until ideology is reformed to conform to reality.
I think you'll find that if you look at HTML5, there's not a lot of presentational bits in it. Most of that is still reserved for CSS.
You'll also find that the cases where things are defined at least gives the web a unified a way to handle real web pages that exist *today*. Right now, a new browser would have to reverse engineer what Chrome, FF, IE and friends did in order to know how to render the web. HTML5 at least identifies the reality that exists.
You note that JS is being used to do things it shouldn't. On what grounds? Who are you to tell what should and shouldn't be done with a language and in a given environment? The practical fact is that folks *are* doing amazing things with JS. If you don't like the language, that's your problem. If you don't want it on your computer, don't use those websites. JS *does* lots of things today, and there's no reason to limit it artificially. You want something better out there? Come up with a solution and push it.
Your final comment notes that web developers aren't interested in quality and technical superiority. You're right. Why should they? What they care about is getting a product out. You're asking them to solve problems that they don't have.
Tks,
Jeff Bailey
(an employee of Google, not speaking for Google at all)
They picked this shitty format, so be happy and shut up.
If Google really cared they would fix Android Chrome to reflow text, instead of discriminating
Many of its new elements have gone out of their way to bring back the combination of presentation and content that we've tried to get rid of for over 15 years now.
Absolutely not true. The new tags are for things like articles, sections, and so on. They provide more semantic information, not less. The HTML 2 approach removed all of these as redundant because you can implement them with class attributes. The problem with this is that one site will use <div class="article">, another will use <div class="post">, a third will use <div class="blog">, and this makes it very difficult for the browser to render them in a consistent way and for other user agents to know that they represent articles. In contrast, HTML5 pages will use the <article> tag.
Others, like canvas, encourage JavaScript to be used more than it ever should be. Furthermore, the audio and video playback will end up as the next-generation marquee or blink element; annoying, misused and hated by all.
They don't allow you to do anything that you can't do in Flash already. Flash is often abused, but in some cases it's used very effectively. I'd rather have an open standard than a proprietary system. Things like Web Socket are also very useful, allowing you to keep a connection to the server open and incrementally fetch data without polling. Something like Slashdot could use this to insert posts into an open page whenever someone posts them, rather than fetching them in a blob when you hit 'more,' for example.
What's worst of all, though, is that XHTML, XForms and other sensible standards are being discarded for something so much worse.
XHTML is not being discarded. XHTML 2 is. I like XHTML 2 a lot, and if I were creating the web now as a new system, I'd want something like XHTML 2. Unfortunately, this is not the current situation. XHTML 2 is a great standard for designing document formats, but it doesn't in any way reflect how people are building web sites today, let alone tomorrow. If every browser supported XHTML 2 tomorrow, I doubt you'd see more than a handful of sites using it in a year's time. In contrast, people are already using bits of [X]HTML 5, because they're actually useful.
XHTML 2 made the same mistake the W3C did with HTML 4 and XHTML 1. The spec was written before the implementation. With HTML 5, every feature has to have a well-defined use case and must have two independent implementations before it goes into the final spec.
I've written in more detail about HTML 5 in two articles. I don't agree with everything in the spec, but it's a lot better than HTML 4 + Flash.
I am TheRaven on Soylent News
Canvas is not needed. You can create dynamic, animated graphics using the existing SVG standard.
And yes, html5 brings back the integration of style and content.
It is defined to maintain backwards compatibility by keeping some elements that are counter to the philosophy of html and yet fails to preserve the definition and presence of those elements. It is even halfassed at meeting its stated goals.
Html5 spec does not specify a single DOM structure, unlike html2, this means that IE is going to continue to require hackish work around for cross platform js.
Html5 may not be total crap compared to html4, but compared to the competing and now defunct standard xhtml2? It is utter irredeemable crap.
If Google was serious, they would release VP8 as open source, and open source the patents. They did just buy On2. Why support a codec that was state of the art in 2000?
Hi, Jeff.
XHTML was ignored because it is sensible. It is easy to parse, and hence easy to generate, easy to manipulate, and easy to validate. In most other computing fields, these would be seen as benefits. I think it's due to a collective stupidity and ignorance that web developers haven't bothered to make better use of a technology that would vastly improve their lives.
There is no need for elements like "header" and "footer" in HTML5. The exact same functionality is better represented as traditional divs or spans with a class specified. End of story. Anyone who supports the "header" and "footer" elements, among several others, supports content mixed with presentation. It's a regression.
JavaScript is a scripting language, Jeff. I shouldn't have to explain this to you. It is okay to use it for writing a single-line onclick handler. It does not, however, offer the language constructs to develop anything beyond that. We have far too many ignorant web developers who think that JavaScript is a good language, but that's only because they're totally ignorant of everything else. Use C, C++, Python, Ruby, Perl, C#, OCaml, Haskell, Scheme or Common Lisp for even a week, and you'll immediately see how fucked up JavaScript is, and how pathetic of a language it is for development of code that exceeds two or three lines in length.
What are some of these "amazing things" that have been done with JavaScript? Tell me, Jeff. Tell me. It sure as fuck isn't GMail. Thunderbird, mutt and even goddamn Outlook are still more pleasant to use than GMail's web interface. It isn't Facebook, because that site is as slow as molasses, yet still doesn't do anything interesting with JavaScript. Is it those JavaScript re-implementations of video games from the 1970s, the ones that run slower than the originals did? Sorry, Jeff, nobody has done anything unique with JavaScript. That's why most web "apps" are pure shit compared to their desktop equivalents from the early 1990s.
Your final comment notes that web developers aren't interested in quality and technical superiority. You're right. Why should they? What they care about is getting a product out.
This, Jeff, is why web "apps" are so shitty, and will continue to be shitty. You guys, even at "respected" companies like Google, are all about "getting product out". Great, you've "shipped your product". That doesn't change the fact that it's shit, and basically unusable. But what the fuck, you've "shipped". That's all that matters, right? Actually, no. You guys are basically the same as Indian offshore developers, who shovel out one piece of shit after another. You guys are a disgrace to software development.
This is beyond awesome, it's a game-changer. Google is one of those rare companies that singularly has the power to move markets, and it is revolutionary to see it do so in favor of consumers as it has. I understand the reasons why it has preferred H.264 over Theora, but it is really nice to see that it also understands the reasons why we should be preferring an open format instead. It's especially nice in an age of companies wanting to lock everything down and be the gatekeeper to everything, the major player in technology is pushing yet again to open things up.
Sometimes I think that Google is about the only company that "gets it." They understand that more people using the Internet translates to more money in their pocket. Even if those people are not using Google's services directly, they are increasing the market such that collectively, it has more opportunity, which in turn translates into more $$$. They seem to not really care if other people are making more money as well, which really separates them in my mind from other companies, who are of the "it is not enough that I succeed, but everyone else must fail" mentality.
Anyway, back to the topic at hand, one reason I've seen people regurgitate in why H.264 is the right way to go is because it is supported on hardware. Congratulations to Google on working to negate that argument.
I'm not going to mention canvas here as I'm not interested in it ATM.
Like B and I? I don't see any major problem with that. And they have been somewhat redefined. XHTML2 could not care less about backward compatibility and now it's dead.
I don't quite understand what you mean here. Could you please be more specific?
Please name a few areas where XHTML2 was the best-thing-since-you-know-what that make HTML5 "utter irredeemable crap". XHTML2 had some nice things in it, but nothing really good to sacrifice everything. I see more problems in a fact that CSS is still not up to the task in some areas.
Quick way to get 30% Funny 70% Troll: defend Opera browser on
I've always used the MPEG4 codec, both for audio (AAC+SBR) and video (AVC/H.264), since it can provide quality equal to MP3 or MPEG2, but at half the speed.
How does OGG compare to MPEG4?
"I disapprove of what you say, but I will defend to the death your right to say it." - historian Evelyn Beatrice Hall
What does this have to do with Chris DiBona?
>>> http://people.xiph.org/~greg/video/ytcompare/comparison.html
I don't see any difference between the MPEG4 codecs ((H.264+AAC) and the OGG codecs (Theora+Vorbis). The two images look identical. It's too bad the author did not provide larger images.
"I disapprove of what you say, but I will defend to the death your right to say it." - historian Evelyn Beatrice Hall
XHTML is easy to generate, manipulate, and validate? Have you ever written software that tried to handle XHTML? It's as complex as writing an XML handler which is not trivial to do properly. Things like tag attributes add a whole extra layer of complexity to getting a machine to actually understand the document. Your contention that HTML5 is regressing with respect mixing presentation and content is ignorant and borderline stupid. It makes me wonder if you've even read the spec. HTML5 eliminates presentation tags like center, tt, and the font tag. It does add tags that make it easier for user agents to determine the context of different parts of a document.
For instance the header, footer, and article tags let the UA figure out in a search which parts of the document they ought to pay more attention to. Search engines can focus on text inside article tags and ignore text matches in the footer or nav tags for instance. Screen readers don't need to try to parse pages based on tag attributes like they have to with HTML4/XHTML. A screen reader can know that it doesn't need to bother reading the contents of the footer or it can more easily provide a verbal menu based on the sections of the document.
I'm a loner Dottie, a Rebel.
David, aside from two blogs using the same shitty WordPress themes, when have you ever seen two sites that look exactly like? It's very, very rare. And besides, if the <article> tag is being used to control rendering, that makes it a presentational element no different than <b>, <i> tables, and other crap like that we've tried to get rid of.
In reality, do you know what's going to happen with the <article> element? In order to make it render properly, people will have to specify a class or style, and fix the rendering using CSS. There's really no beneficial difference between <article class="..."> and <div class="...">. Most sensible people will just use divs, since they're supported by just about every browser still in use today.
Web Sockets and crap like that are nothing more than pathetic hacks to work around the web platform being a steaming pile of shit 95% of the time. Like with previous hacks, such as JavaScript, we've seen that they introduce huge security flaws, all for comparatively little gain. As for your Slashdot example, they could obtain the same effect by just using JavaScript's setTimeout function to make an AJAX request and grab any comments since the last check. There's no need for persistent connections or any stupidity like that.
Also, HTML5 is not a specification. A specification is defined before the implementation, not after it. It's difficult to even call it a "standard", with vendors still arguing over video codecs and shit like that. I personally prefer to call it a "failure".
Ok, I'm not a web developer, but I follow the news and try things out on my browser, like the acid3 tests. I don't know the difference between the various markup languages. What I do know is that I want a consistent experience across the web. To help this along, I try to use a browser that supports open standards so that web developers get the feedback from my browser.
When I read a well reasoned debate, even on Slashdot (and it does happen), it's encouraging. I would much prefer that to the drama of a flame war. This comment is not just directed to TheRaven64, but to everyone who can participate in the discussion with reasoning, facts and references.
Since I can't know everything about web design, I try to use discussions like this as a chance to become better informed.
Thank you.
The diversity and expression of human opinion is essential to human survival.
Video encoder comparison
Ogg Theora vs. H.264: head to head comparisons
someone piss in your corn flakes this morning?
By the sounds of it, the only thing that'll solve your problem is canceling your internet.
Are you serious? Are you seriously saying that you find parsing XML difficult? Perhaps you should find another field to work in, if that's the case. Handling XML (and, by extension, XHTML) is a trivial task.
Yes, I have worked on systems that store millions of complex documents in XML and XHTML. I've worked on content management systems where we had end-users editing those documents. Do you know what we did? We forced the documents to validate before we persisted them, and that made them easy to parse. For the average user, it took about 10 minutes for them to figure out how to write well-formed and valid document.
Theora lost because it wasn't as good as H.264 and it's still not as good as H.264 bit for bit. The only reason why the opensource world support it isn't because it's better, but because it's the only "open source friendly" option. Sorry, but that just because it fits an idelogoy doesn't mean much to the part of the world that uses the product. It's like suggesting that a professional 3D/video shop use Blender instead of Maya or Cinelerra instead of Final Cut Pro or Avid. The professionals are going to take a look at it for a while and go, "Nice toy, now I've got to get back to work."
If the opensource world wants Theroa to succeed, you're going to have to produce something that's better than H.264 end of story. Until then the people are working in Video are going to continue using H.264 because it's everywhere and is currently the best mainstream codec available.
I worked in Video production in the late 90's through about 2005. H.264 was a godsend when we finally had a single Codec that was adopted by pretty much all recording hardware and editing software. Before it was a Codec Hell. Nobody I talk to in the industry, and I still have a lot of friends who work everywhere from their basement to large production shops, have any interest in embracing Theora or anything else. They only want to support 1 Codec that works everywhere, and that's H.264. Even if it costs them a little bit of money. Because whatever it costs them is likely cheaper than the headaches of having to support multiple formats.
Now, if Theora or some other patent free format gets to the point where it can offer at least the same (really it has to be BETTER than H.264 in features and quality) only then will the production houses be interested in switching. And by better, offer at least the same quality as H.264 at a lower bit rate than H.264.
"The problem with socialism is eventually you run out of other people's money" - Thatcher.
Tags like header and footer denote semantics which are part of the content (content denotes what is displayed, not how it is displayed). They don't say "the footer should be in a 10pt font" -- that is up to the CSS. They (and the other layout elements) denote the semantics of what is currently being done in an ad-hoc way. They allow things like search engines to identify relevant information (e.g. ignore the footer sections).
HTML5 is looking to be a great standard. Not perfect by any means, but it is a good step forward (giant leap?) in the right direction. Having a defined way of processing HTML5 and having an XML variant (XHTML) unified to the same DOM makes it easier to choose how you want to write/generate your HTML content.
There were some nice ideas in XHTML2, but it didn't pan out. That does not mean that some of those ideas cannot be integrated into HTML in the future like section has been.
It is also good to see Google seeking to improve video support.
Gradually, HTML5 support will improve, as will support for CSS3 as these standards get finalised. Also, audio and video support will stabilise as well. These, with all the advances in support for MathML, SVG, SMIL and other standards as well as performance improvements for JavaScript and hardware-accelerated page rendering mean that the web is only growing in strength.
As for JavaScript, it is just a scripting language -- you can do anything with it and hook it to anything. You do know that the "fetch more comments" feature of slashdot uses javascript? You do know that thunderbird and firefox make use of javascript for binding their UI together?
That TI's mated to their ARM cpus? TI DaVinci
The article, section, header, footer and aside tags don't have any presentation information (except that section/section/h1 is similar to using h2). A HTML5 browser should only have the following presentation logic done via CSS:
article, section, header, footer, aside { display: block; }
Anything more fancy is done by CSS. Which means that you can have a single CSS theme file (WordPress, ZenGarden, whatever) that is used by *any* website that uses HTML5 markup.
Sometimes I think that Google just didn't "get it" in the first place when choosing H.264 for youtube.
YouTube started out on Sorenson H.263 because Flash Player supported that out of the box. When iPhone and new versions of Flash Player started to support H.264, YouTube reencoded uploaded videos in the new format. It was a happy accident that Chrome and Safari supported the same codec for the HTML5 <video> element. Now that platforms stuck on Flash 7 (namely Wii) have upgraded to a version with H.264, YouTube appears not to do H.263 anymore. Theora is somewhere between H.263 and H.264 in quality, roughly on par with MPEG-4 part 2 codecs such as DivX and Xvid, but H.264 still uses half the bitrate of Theora for the same perceived quality.
Canvas is not needed. You can create dynamic, animated graphics using the existing SVG standard.
But can you let the user do this creating? How would one write a photo editor or pixel art editor with SVG and no <canvas>? And how well does SVG handle sprite graphics in the style of 8-bit or 16-bit consoles?
And yes, html5 brings back the integration of style and content.
It was still there in transitional XHTML 1.
Html5 spec does not specify a single DOM structure
What exactly do you mean by this? If the HTML5 standard cites the DOM Events spec, then it supports addEventListener and the like. Microsoft made a specific choice not to support DOM Events, a W3C Recommendation published in 2000, and therefore not support HTML5.
but compared to the competing and now defunct standard xhtml2?
Which web browser ever supported XHTML 2 without using XSLT to turn it into XHTML 1? Heck, IE was even late to support XHTML 1.
There is no need for elements like "header" and "footer" in HTML5. The exact same functionality is better represented as traditional divs or spans with a class specified. End of story.
So how are you going to get thousands of web sites to use the same class= for a header or footer so that the user can apply a user stylesheet to every site's header and footer?
Use C, C++, Python, Ruby, Perl, C#, OCaml, Haskell, Scheme or Common Lisp for even a week, and you'll immediately see how fucked up JavaScript is, and how pathetic of a language it is for development of code that exceeds two or three lines in length.
It's interesting that you mention Scheme and Common Lisp. The common opinion on the web is that JavaScript has Lisp semantics with C syntax. In fact, I'd wager that if M-expressions had ever been properly implemented in Lisp, they would look a lot like JavaScript. Another advantage of JavaScript is that end users might not have privileges to install an application written in "C, C++, Python, Ruby, Perl, C#, OCaml, Haskell, Scheme or Common Lisp".
Is it those JavaScript re-implementations of video games from the 1970s, the ones that run slower than the originals did?
The originals don't run at all if you don't have permission to install them on a given PC. JavaScript has the advantage that it's (at least supposed to be) sandboxed, so computer owners are more likely to let guests use applications written in it.
Bitter much?
I would say you are way off the mark. What's been unique with Javascript? Let's start with AJAX. C, C++, Python, Ruby, Perl, C#, OCaml, Haskell, Scheme, nor Lisp has advanced the state of the web like AJAX has. I can't access/run thunderbird/mutt/outlook on my iPhone, or use them from my work desktop, but gmail's web interface works EVERYWHERE.
Maybe those things aren't important to YOU, but they are to me. Javascript may not be the best programming language in the world, but it has some very unique advantages that most others don't. It's no one else fault that you simply can't see the advantages and disadvantages to differing technologies, and apparently have a blinding hate towards specific ones.
We forced the documents to validate before we persisted them
Which is still possible with HTML5. It has two surface forms, XML and a pseudo-SGML, which parse to the same DOM. The user can enter XHTML5, and you can still validate that. But the advantage of HTML5 is that its pseudo-SGML parser is more clearly specified, so that even tag soup translates to a well-defined DOM. If the user enters pseudo-SGML, in which case you can parse that into a DOM and then serialize it back to XHTML5.
XHTML was ignored because it is sensible. It is easy to parse, and hence easy to generate, easy to manipulate, and easy to validate.
Sorry, but this is just bullshit. As someone who used XHTML extensively and liked the flexibility it offered me, XHTML was killed by one thing and one thing only, and that is IE's complete and utter refusal to support it and the extremely high market share of IE during the period where adoption was a practical option. If XHTML could have even failed back to something useful in IE, it might have had a chance, but that did not really work in practice either. As a result, the Web developer community moved on to technologies where they could provide more useful Web apps, but where they could provide support for IE using the same page and a bunch of hacks.
What are some of these "amazing things" that have been done with JavaScript? Tell me, Jeff. Tell me. It sure as fuck isn't GMail. Thunderbird, mutt and even goddamn Outlook are still more pleasant to use than GMail's web interface.
Sigh. Except you're missing the critical element that Gmail will work on your Windows PC, Mac, iPhone, Android, Wii, or whatever else you throw at it using whatever browser a particular user happens to have, even including the abysmally retro IE. All the other e-mail programs you mention require a separate version to support each and every platform. The Web application is the work around for the complete failure of cross-platform computing technologies, largely killed by Microsoft.
1: XForms are a huge improvement over traditional html forms with contol over view, validation and data.
2: The standardization on xml events and DOM. This is a huge issue.
If you have ever done any serious work in AJAX web apps,
you will know that there are IE uses a different DOM structure than everything else.
This means they you have to:
A: know all the idiosyncratic differences and how to identify and code around them.
B: test everything with rediculous thoroughness and apply hackish patches to get things working.
C: use a bloated standardization library (prototype, jquery, dojo, etc).
3: xhtml2 is a host language allowing you to embed other xml language elements within.
You can include MathML, SVG, etc with the appropriate namespaces.
4: seperation of symantics from styling.
Html5 has predefined css styles and tags used to define symantic meaning in a haphazard fashion.
Xhtml2 uses the role attribute to define symantic meaning in a single, clear and consistant way without interfering in document structure markup or styling.
5: real errors. Invalid documents are invalid and produce an error instead of allowing the browser to randomly attempt to guess the correct fix for bad code. This will make developing consistant and valid documents easier as the author will be able to catch invalid documents during development.
Anyone who supports the "header" and "footer" elements, among several others, supports content mixed with presentation. It's a regression.
Very wrong. Header and footer elements denote document structure, nothing else. Of course they will have default styles, but that can be overridden like everything else. Actually header and footer elements are much more sensible than using divs with classes or ids. A header is specified to be used for certain parts of a document, and can be correctly interpreted by software such as screen readers and braille displays. How do you do that with divs? The id/class is an arbitrary string, not something that such software can rely on.
It is okay to use it for writing a single-line onclick handler. It does not, however, offer the language constructs to develop anything beyond that.
Who are you to assert what we can and cannot do with it?
We have far too many ignorant web developers who think that JavaScript is a good language
I can agree that much Javascript code is pretty hackish, but you can develop structured code with it. Sure, I'd prefer a conventional object oriented language instead of the prototype-based language Javascript is, but it's really just because I'm more familiar with the former. The more you use it however, the better you'll become in thinking about prototypes instead of superclasses.
Use C, C++, Python, Ruby, Perl, C#, OCaml, Haskell, Scheme or Common Lisp for even a week, and you'll immediately see how fucked up JavaScript is, and how pathetic of a language it is for development of code that exceeds two or three lines in length.
I don't agree. Like every language, it has its strengths and its weaknesses, but it's not like other languages does not have strengths and weaknesses of their own. Javascript surely has its share of quirks, but so has every other language out there. Care to explain what is so immensely shitty, pathetic and fucked up about Javascript?
In reality, do you know what's going to happen with the element? In order to make it render properly, people will have to specify a class or style, and fix the rendering using CSS.
article, nav, section, header, footer and friends are about markup, not about rendering. In terms of normal rendering it makes no difference if you use <article> or <div class="article>, in terms of marked it however makes a huge different. One of the core problem for me with the Web today is that there is simply no to tell the browser what is the actual content and what is just a navigation bar. This in turn makes some webpages on some devices pretty much unusable (Wikipedia on a PSP for example). If the navigation and article content would feature proper markup you could have a button in your browser to simply hide the navigation, without the markup the browser has no way to tell where the navigation ends and the content starts.
Now of course in practice things might turn out different, pages might not use proper markup as it would make it to easy to skip advertisements and such, but on the other side you have pages like Wikipedia where it could really be a useful addition.
That said, I am not holding by breath, <link rel="next"> and friends have been in HTML for well over a decade and can be extremely useful in some use cases (having a book in HTML for example), yet proper support in most browsers for them is still missing or at least well enough hidden that a normal end user would never find them.
Are you seriously saying that you find parsing XML difficult? ... Handling XML (and, by extension, XHTML) is a trivial task.
Depends on your point of view. Using an already existing XML parser in an application can be pretty easy. Writing a fully compliant XML parser is far from simple. If it would be so simple, why are most XML libraries fairly large and complicated pieces of software?
It is pretty simple to write a non-validating parser for a limited subset of XML, but if you include things such as namespace support, XPATH support, not to mention validation by DTD, Relax-NG and/or XML Schema, the parser suddenly becomes very complex.
Did you notice that the author of the blog entry is a developer of theorarm. His point of vue is not necessary the same as google...
Ogg/Theora+Vorbis provided a clearer image at a smaller compression. It's more noticeable in the upper right hand corner. At higher compression it's hard to tell a difference if one even exists at all.
Where space and power matters most (pocketable devices), I'm just not entranced by support for more codecs that aren't efficient.
Some day it'll be reasonable for the device in your pocket to play video in any format you find it in. But for now, I think I'd rather the effort were concentrated on maxing out the efficiency (bits and power) of the codecs that are already in wide use.
http://lkml.org/lkml/2005/8/20/95
Yes, the iPhone and iPod Touch mattered. But if Google had chosen Theora and not H.264 (not sure why it's an either/or, but you presupposed this) then YouTube would be a bit player in the mobile market right now because no mobile device could play it efficiently, because there is no Theora support in mobile chips right now.
YouTube's competitors were already supporting H.264 and thus they could work on mobile devices, and Google could have lost the mobile market space to them if they didn't move to cover this weakness.
To me it's strange to think mobile players will move to adding Theora hardware support just as a "backup plan". Transistors aren't free. There's a lot of codecs they already don't support that would bring a lot more perceived value to the customer before they'd add Theora.
http://lkml.org/lkml/2005/8/20/95
Inefficient transmission of a noisy, poorly-lit video of some kid complaining about his life is unimportant if it only gets downloaded nine times.
Nine? It's over nine thousand.
In reality, do you know what's going to happen with the <article> element? In order to make it render properly, people will have to specify a class or style, and fix the rendering using CSS. There's really no beneficial difference between <article class="..."> and <div class="...">. Most sensible people will just use divs, since they're supported by just about every browser still in use today.
That's precisely the point. They will be presented in different ways (like I said, they're not presentation tags), but the browser will know that they are articles, not something else. If it's on an eInk device, for example, it may decide to split a big page on article breaks. It may display a list of articles in a side view. Anything parsing the HTML for some purpose other than immediate display will know that these are articles, and not just some arbitrary level of detail in a hierarchy.
You seem to be arguing both against presentation markup and against semantic markup. There is a big difference between using an article tag and using a div with a class. As I said in my original post, the former is uniform across sites, while the latter is not. It's the same as the heading tags that have been in HTML from the start. You could replace these with div tags and heading1 (for example) classes, but it's useful for things parsing the HTML to know that something is a heading, not just that it's a generic bit of text.
And you're completely ignoring the benefit of user CSS. This is a feature that has been in browsers for a long time and allows you to specify CSS that overrides the site's own styling. With a richer set of semantic elements, you can define CSS attributes that are applied to every article, every caption, every section, and so on. You don't have to maintain a massive list of class names for every site that you might visit.
Since you like XHTML 2 so much, perhaps you should refresh your memory as to what the XHTML 2 solution is to this problem. If you honestly think that maintaining a huge network of ontology maps is better than defining a few new tags, then I hope I never use a system that you've designed.
I am TheRaven on Soylent News
1. XForms are a huge improvement which currently does not work. Good or bad bad it is.
2. What? There already is a standard. Microsoft decided it does not need to do it the way it's written. Why would you think they'll implement something else?
3. XHTML5 (XML serialization of HTML5) can include MathML and SVG too. Your point is? HTML serialization will be able to do that or so I heard.
4. Predefined styles are backward compatibility. I don't like them either (aside from, maybe, b/i/etc) but I doubt browser vendors will do something about that. Otherwise users complain it's broken. And no, you cannot educate them on the issue. They do not care.
5. This is something I don't like myself (sometimes). However, you can't really make something about that either (same reason). Well, you can somewhat - use XML serialization of HTML. However it'll only check validity of XML. Good thing anyway, you don't want a browser to analyze if it's allowed to have one element in the other - you may need to introduce new elements someday.
Quick way to get 30% Funny 70% Troll: defend Opera browser on
So basically you're saying that you can only ever have what you have now? How do you want to make progress? Sorry, I don't buy it.
And as for JS, it is pure crap. If you use it to write a website, it's practically impossible to do it well unless you limit your use of JS to something really simple. I can't remember how many times website JS programs made me curse at them for doing stupid or unexpected things. On the other hand, plain, non-JS websites are perfectly usable and make you feel in control. I don't call this progress at all.
Is it for Android, Windows Mobile, Linux, or all of them?
You do know that the "fetch more comments" feature of slashdot uses javascript?
I for one have been made painfully aware that it uses javascript when I followed a link and pressed the 'back' button, only to find all the comments gone. Hello javascript, goodbye plain-old-HTML usability.
Actually header and footer are pretty arbitrary. While they are common structures on paper, what do they have to do with websites? What's the difference between a header and a footer, because they look like something pretty much the same to me, only you call them differently based on whether they are at the beginning or end. If their only purpose is to distinguish content from meta-content, there should be another tag, or better css attribute to do say it.
Technical Objections To the Ogg Container Format:
http://news.slashdot.org/story/10/03/03/1913246/Technical-Objections-To-the-Ogg-Container-Format
[I really don't know]
Is this a branch not discussed in the above article?
~hylas
Quality is not the reason why Theora lost to H.264, just like quality wasn't the reason why Vorbis lost to mp3.
Then tell me why Theora lost. Don't stand on the quick, weightless, mod-up to +4 "Insightful."
"It's interesting that you mention Scheme and Common Lisp. The common opinion on the web is that JavaScript has Lisp semantics with C syntax. In fact, I'd wager that if M-expressions had ever been properly implemented in Lisp, they would look a lot like JavaScript."
You, like all web developers are so full of shit.
M-expressions for Lisp, been there done that it's called DYLAN and it has nothing to do with Brendan Eich's toy language. Syntax macros, everything is an object, CLOS-inspired powerful object system with multimethods, optional static typing, modules (namespaces), keyword arguments.. and an incredibly nice environment, incremental compilation and interactive IDEs.
You are so full of shit. Javascript doesn't even begin to compare with an actual m-expression Lisp, much less the actual Lisp and its powerful ability to define its core in term of itself and interactive environments. Do you think a language like Javascript would be suitable to recreate the concepts behind the Lisp Machine ? I don't think so.
We already have an unpatented, royalty-free, unencumbered, lowest-common-denominator video codec for use on the internet: H.261.
H.323 specifies it as the lowest common denominator for video-over-IP, so all video phones already support it, including hardware implementations. It was published in 1990 - twenty years ago - so it is as patent-free as you can get. And it's published by the ITU, so the specification is freely available.
Why do you need validation by DTD/Relax-NG/etc.? Current HTML works without that. XHTML don't need to do that either. In fact you can make things worse by doing so.
Quick way to get 30% Funny 70% Troll: defend Opera browser on
The common opinion on the web is that JavaScript has Lisp semantics with C syntax.
The only people who think that JavaScript is Lisp with a C-like syntax are people who have never actually used Lisp.
If they'd actually used Lisp, they'd be comparing JavaScript to dogshit instead.
Javascript does not magically do AJAX possible. It works because browser does it and give access to needed objects to javascript. This can happen with any language integrated with a browser.
Quick way to get 30% Funny 70% Troll: defend Opera browser on
You must not have paid much attention to the abomination that was the XHTML2 work.
This is not really a property of XHTML2, but of XML. The original XHTML could have those too.
As for the feature itself, it just leads to bloat with tons of namespaces. Embedding through files is the way to go.
This is really vague. Examples?
So does HTML5 in some cases. And are you implying that the elements themselves should lose semantic meaning and only be used for style hooks? We already have this phenomenon with div elements and classes, and it's called divitis. It's not pretty.
HTML5 will define how parsing errors are to be handled, so no worries there.
SVG is a bloated, unwieldy spec that has been mostly dropped. Because of this, no web browser implements it fully or well. Meanwhile the canvas element is simple, well-defined, and supported.
I've recently read the short description of the MPEG-LA license terms for broadcasters. (Not the full licenses, though)
If I understand it correctly, by purchasing a license, you're allowed to use h.264 for YOUR distribution, but the terms does not mention re-licensing to third party. To my best guess, that would mean re-licensing is not allowed.
But, and here's the catch, when YouTube-videos are embedded into other sites (Facebook, or Joe Shmoe:s blog) isn't that a form of re-sale to third party?
Can someone with more insight comment on this?
examples? the copyright, error, example, issue, note, search, and warning style class is defined to have specific semantic meaning in html5. The time, meter and output tags act similarly with a few differences. Completely over ridding developer control. With xhtml2 the role attribute has more flexibility without breaking separation of concerns.
This is the best thing that I've heard all day
I was worried Google was gonna go with H.246, but they seem to understand that youtube has become an essential part the web, and the web should stay open!
Didn't Google buy On2? Why aren't we seeing open VP7 and VP8?
...The opinions in Google are starting to fragment a bit too much. So now Google has a department that prefers h.264 for web content, and a different department that'd gladly fund development Theora?
Reading the post, it seems a bit clearer they're just going for the "right tool for the right job", apparently.
I am not devoid of humor.
Check out http://dev.w3.org/html5/spec/Overview.html#the-article-element.
I am not devoid of humor.
Clicked "post" before I was done, oops. My point is, the spec doesn't define any sort of representational attributes to the tag. It is purely intended for clearer contextual information, which can be used positively in user agents. (Screen readers won't read the navigation section of the site, mobile phones can take just the article and view that in the best possible way, etcetera).
I am not devoid of humor.
Completely over ridding developer control.
Yes, that's the point. It is a good thing. I, as a browser of the web, do not want you as the developer to have complete control over my experience.
Over-the-top Response Guy! Giving "Over-the-Top Responses" since 1970.
I don't think you understand what I am saying. With these semantic style classes, meaning is applied to the meaningless. Style classes are for style, not meaning. It also applies markup tags, tags are defining the structure of a document, not its meaning.
what does the style "copyright error" mean? In HTML5 it means that section is the copyright notice section for your page, it is also an error display area, even though it may be intended to style an article on inadvertent copyright infringement.
Noone seems to have mentioned that Google now owns On2 so presumably could do the same thing w/ VP6 which is a much more advanced codec?
Why do you need validation by DTD/Relax-NG/etc.? Current HTML works without that. XHTML don't need to do that either.
Since the GP was discussing XML, so was I, and XML validation is an important part of XML. HTML isn't XML, so it is outside the scope of the discussion.
In fact you can make things worse by doing so.
Are you saying that XML validation is a bad thing, and that it should be avoided? Or are you specifically referring to HTML/XHTML validation? Anyway, why would validation "make things worse"?
It is not in any way required.
I'm talking about HTML/XHTML validation, yes.
Quick way to get 30% Funny 70% Troll: defend Opera browser on
Because Theora is based off of the other On2 (now Google) open-sourced VP3?