The blog post mentions submitting a specification to the relevant standards organization. Are they planning on creating a new mp4 ftyp and registering a mimetype with IANA?
The blog post mentions submitting a specification to the relevant standards organization. Are they planning on creating a new mp4 ftyp and registering a mimetype with IANA?
Can I start serving .html files as .awesome files? And .js as .kicka$$ files? and .mp3 as .boomin'?
GET "index.awesome"
<script src='jquery.kicka$$'>
<audio src="foil.boomin'">
at this rate, why not re-write all of html so it's cooler? <body> => <b0d> <title> => <1nduk+10n>
<link rel="openid.server" href=""> => <cyb3r-jack rel=!!openid.matrix_data_cent3r" ultra_max_hyper_ref="">
Sure, go ahead. Extensions in a URL have little to do with the actual type of content, and .html has long been abandoned by dynamic systems, who originally went to extensions being an implementation detail, and on many current systems being a lie (e.g. the .aspx extension that actually runs a PHP page that returns an HTML5 file).
They're using a URL extension to signal to their system what to do with the file, which in the case of GIFV is to wrap an MP4 video in a simple HTML5 container. Eh.
It's what's intended, but it's not what's true. Usually this bites on video, but it even bites on, say, SVG:
http://stackoverflow.com/questions/10261460/internet-explore...
Ostensibly, this is to protect users. Quoting TechNet:
When files are served to the client, Internet Explorer uses the following pieces of information to decide how to handle the file:
1. File name extension, the corresponding ProgID and CLSID for the registered handler of that file name extension.
2. Content-Type from the HTTP header (MIME type), the corresponding ProgID, and CLSID for the registered handler of that Content or MIME type.
3. Content-Disposition from the HTTP header.
4. Results of the MIME sniff.
-- http://technet.microsoft.com/en-us/library/cc787872(v=ws.10)...
Yes, I'm aware that this is probably a workaround for broken web servers, or brain-dead server admins. This workaround should never have been deployed, as it breaks interactions with non-broken web servers.
You can't call either browser broken here. One is doing what the spec says is correct. The other is doing what the user says is correct.
You upload JSON, and give you a URL that points to the same thing, except formatted as XML.
xjson!
People could not care less if it's a actually a new format or hijacks an existing one.
the imgurl community is always asking for more servers and bandwidth, and the imgurl team is only delivering crappy feature on top of crappy feature that only makes things worse.
their goal is not pleased users, its a big fat huge "exit". thats why new feature and buzzwords abound. it impresses investors, which is their goal.
well, not like i would ever typed to reach it on purpose anyway. it is just reddit's image anyway.
They serve 2 billion images per day, and they never delete pictures that are still actively accessible from the internet. At no cost to the user.
In any case, cache is golden, and a 5 MB gifs off of their front page could be a 500kb MP4. That difference adds up superfast it's off of their front page and has 30M views.
the post i just answered to asked what is so special about gifv if all they are doing is a video tag.
also, similar arguments where done when adding lazy loading etc... with the idea that "loading images progressively is better" etc... it all backfires in the end when done by those guys. now the user actually PERCEIVES the slow loading. before, images would take a long time, but if you waited you could see the whole album. now, thanks to lazy loading done bad, they will load AS YOU SCROLL... you get to witness all the wait! it is hell.