4 ms·

All the arguments against h264 apply equally to proprietary fonts only more so (since they're not even free as in beer for the next few years). If font-family

All the arguments against h264 apply equally to proprietary fonts only more so (since they're not even free as in beer for the next few years). If font-family can designate a non-free/open font then video can designate a non-free/open codec.

cookiecaper 16y ago
<video> in fact can specify a non-free codec. This isn't about the types of codecs that should be allowed to be included in <video>, it's about the types of codecs a browser vendor will support out of the box. Fonts are much smaller than video decoders so they can be sent over the wire, making the whole licensing and distribution thing the problem of the person using the font on his site. Fonts are all decoded by the same free code, whether that font is free or not. There is no facility to transmit a decoder for the use of <video> tags on your page, and no one would do that anyone because it would be a huge nightmare to make sure you're sending one that can run on the user's platform, the browser would be forced to allow execution of an arbitrary binary block that could very well just be posing as a video decoder, and then all sites would have to pay for the rights to distribute the license. It just doesn't work. The browser has to include the decoder locally, so the browser vendor has to decide if he's going to pay for the license for a H.264 decoder or not.
- crab 16y ago
  This isn't about the types of codecs that should be allowed to be included in <video>, it's about the types of codecs a browser vendor will support out of the box. This is extremely misleading, as three out of the five major desktop browsers refuse to allow you to play anything except what they support out of the box, meaning that what is "allowed" and what is "supported out of the box" are the same thing. In those browsers you can specify a non-free codec, but you're not free to actually play it. The browser has to include the decoder Also misleading, as this is not a requirement of the specification, but an implementation choice made by certain browser vendors.

cookiecaper 16y ago

<video> in fact can specify a non-free codec. This isn't about the types of codecs that should be allowed to be included in <video>, it's about the types of codecs a browser vendor will support out of the box. Fonts are much smaller than video decoders so they can be sent over the wire, making the whole licensing and distribution thing the problem of the person using the font on his site. Fonts are all decoded by the same free code, whether that font is free or not. There is no facility to transmit a decoder for the use of <video> tags on your page, and no one would do that anyone because it would be a huge nightmare to make sure you're sending one that can run on the user's platform, the browser would be forced to allow execution of an arbitrary binary block that could very well just be posing as a video decoder, and then all sites would have to pay for the rights to distribute the license. It just doesn't work. The browser has to include the decoder locally, so the browser vendor has to decide if he's going to pay for the license for a H.264 decoder or not.

crab 16y ago
This isn't about the types of codecs that should be allowed to be included in <video>, it's about the types of codecs a browser vendor will support out of the box. This is extremely misleading, as three out of the five major desktop browsers refuse to allow you to play anything except what they support out of the box, meaning that what is "allowed" and what is "supported out of the box" are the same thing. In those browsers you can specify a non-free codec, but you're not free to actually play it. The browser has to include the decoder Also misleading, as this is not a requirement of the specification, but an implementation choice made by certain browser vendors.