●Stories
●Firehose
●All
●Popular
●Polls
●Software
●Thought Leadership
Submit
●
Login
●or
●
Sign up
●Topics:
●Devices
●Build
●Entertainment
●Technology
●Open Source
●Science
●YRO
●Follow us:
●RSS
●Facebook
●LinkedIn
●Twitter
●
Youtube
●
Mastodon
●Bluesky
Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!
Forgot your password?
Close
This discussion has been archived.
No new comments can be posted.
Load 500 More Comments
Full
Abbreviated
Hidden
/Sea
Score:
5
4
3
2
1
0
-1
More
Login
Forgot your password?
Close
Close
Log In/Create an Account
●
All
●
Insightful
●
Informative
●
Interesting
●
Funny
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
bysuso ( 153703 ) * writes:
See, this is something that open source accomplishes that stupid fucking arrogant businesses will never get. When something is obsolete or no longer needed, it gets ditched or replaced by something better. Don't keep it around because someone thinks that they have the right to continue being in business even though their shit is a decade out of date. Its a hard and cold life for the developer whose project gets ditched (And sometimes I feel bad for them), but in the end, the user wins big and things evolve
byionix5891 ( 1228718 ) writes:
Since when is Java a company... Oracle (previously Sun) are behind java
and why no mention of Apple? they are the ones refusing to support ogg
bysamkass ( 174571 ) writes:
To be fair, Google is also refusing to switch YouTube to Ogg because of its lower quality per bitrate than h.264.
As was argued by the original author, you're left in a situation where if Ogg were specified in the standard, you'd have folks who followed the standard at a disadvantage in quality and/or bitrate.
Besides, W3C doesn't say which image file formats are allowable, why should it specify a codec?
byNoCowardsHere ( 1278858 ) writes:
Besides, W3C doesn't say which image file formats are allowable, why should it specify a codec?
I think this is a really good point. I mean, I have no idea if it's true or not... maybe they do specify image file formats, I have no f*****g idea. But it certainly makes sense. The standard should define how web developers specify images, and how browsers should handle them, but the actual file formats are left up to the market to work out. Same thing with video... makes sense, right?
There are really only two
byCereal Box ( 4286 ) writes:
The problem with standards is that if you leave too much open to "interpretation" you get a mess of incompatibilities. I'm a firm believer that standards organizations need to make the truly important parts of the spec completely mandatory, i.e., if you don't support <video> and all the listed codecs, you can't claim HTML5 compatibility.
Parent
twitter
facebook
byPenguSven ( 988769 ) writes:
It hasn't worked in the past, it won't work now. Even the W3C accepts that browser vendors won't support what they don't want to, regardless of what the spec says.
byCereal Box ( 4286 ) writes:
Precisely. That's why you say "if you don't do X, Y, and Z, you can't say you're compliant with the spec." Sun does this all the time to Java EE appserver vendors and what do you know? They all implement the specs fully (with the inevitable bugs of course).
byPenguSven ( 988769 ) writes:
I think you missed my point. Browser vendors aren't going to implement things they don't want to, regardless of what the spec says. That' the whole reason CSS2.1 exists. The vendors didn't implement a number of things in CSS2.0 and thus a revised spec was released to more closely match what was actually implemented.
This is the same. The W3C aren't going to release a spec that no one can/will implement fully. Ian Hickson has made that quite clear.
byDavidTC ( 10147 ) writes:
I think that it's entirely reasonable to have a <video> tag with a few specified codecs, but also to allow new codecs to be added.
The problem here is that including a video codec in an HTML spec is rather silly, and was a silly idea to start with.
You'll notice that no image specs are included in HTML, and you can use, for example, the TIFFs image format in a <img> if you feel like it. Of course, no browsers actually support TIFFs, so that won't display, but there's nothing stopping browsers fr
There may be more comments in this discussion. Without JavaScript enabled, you might want to turn on Classic Discussion System in your preferences instead.
Slashdot
●
●
Submit Story
It is much harder to find a job than to keep one.
●FAQ
●Story Archive
●Hall of Fame
●Advertising
●Terms
●Privacy Statement
●About
●Feedback
●Mobile View
●Blog
Do Not Sell or Share My Personal Information
Copyright © 2026 Slashdot Media. All Rights Reserved.
×
Close
Working...