Talk:Data URI scheme

From Wikipedia, the free encyclopedia

Perhaps someone could add a brief introduction and a link to the "data: URL" page on the main "URL" page?

Contents

[edit] They are really URIs

I think this article should be renamed to data: URI, and replace all references to URL with URI, retaining the historical aspect of them being called URLs. data: URL should be redirected there. Hrvoje Šimić 12:42, 17 November 2005 (UTC)

According to RFC 2397, it is considered a URL, despite the fact that data: is not a locator. For that matter, it isn't really an identifier either; it's more like a container. - Brianiac 19:30, 18 November 2005 (UTC)

It's a tricky issue. Let me try to explain why I think data: scheme URIs should not be considered URLs, despite they being called that in the relevant specification. They are URIs, even if you consider them URLs, since all URLs are URIs. The RFC 2397 calls them URLs, but I haven't found any formal or informal references implying that they should be considered URLs. It's as if the authors didn't know what URIs mean, so they called them URLs. RFC 3986 (see section 1.1.3) and documents from the Technical Architecture Group specify that URIs should not be considered URLs if they are not explicitly used as locators. In particular, URI schemes are not to be classified as specific URL or URN schemes. Hrvoje Šimić 09:38, 21 November 2005 (UTC)
Well, I'm going around clearing up all the articles we have on the topic, and I think we need a standard and uncontroversial naming scheme. Since all URLs are also URIs, I figure that all "URL schemes" are also "URI schemes", so at worst it is "not specific enough" to use the latter. For consistency, therefore, I'm going to rename all the articles about schemes which deserve an article "<scheme>: URI scheme". I'm also going to put in place lots of redirects, because I actually missed this page when searching once, and almost created a new one. I hope no one is "offended" by this, it just seems sensible to be consistent. - IMSoP 22:49, 8 December 2005 (UTC)
Sounds reasonable. -- Brianiac 22:16, 22 March 2006 (UTC)

[edit] Data: URIs in CSS

Just a note on data uri's in CSS. Non-alphabetic characters must be escaped by backslashes. Refer to this bugzilla entry:https://bugzilla.mozilla.org/show_bug.cgi?id=319779

[edit] Disadvantages

Am I correct in thinking that data: does not support specifying http headers such as content-disposition, so suggested names for saving cannot be given, nor transparent gzip compression specified. If that's correct, it should be listed in the disadvantages. Also the lack of content negotiation.

True, Content-Disposition is not available. Compression and content negotiation are not available, either. Good points, anonymous stranger. ;) -- Brianiac 22:23, 22 March 2006 (UTC)
Actually, now that I think about it, the multipart/alternative MIME type can be used for content negotiation, and similar containers (multipart/parallel, message/rfc822, etc.) might be used to support compression and Content-Disposition. It all depends on your processing environment. A simple image included as part of a web page may not support these workarounds, though.

[edit] What Copyvio?

For some reason, this article has copyvio flags. There is no copyright violation, as RFC 2397's copryight statement allows (if not encourages) copying. As the pertient section of the "Full Copyright Statement" states:

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

-- NeoAmsterdam 04:57, 12 April 2006 (UTC)

I've highlighted what seems to me to be the problematic part.

-- Uldoon 14:12, 14 April 2006 (UTC)

Every RFC seems to have the copyright part inserted, so if Data: URI's would be infringing, somebody should check out the pages for E-Mails, HTTP, IRC, Jabber, etc. because they are all RFC's

-- The Decryptor 16:18, 20 April 2006 (UTC)

I do not think copying from RFCs, especially for informative purposes, constitute a copyright violation. --soUmyaSch 10:02, 1 May 2006 (UTC)
The RFC says:
Copyright (C) The Internet Society (1998).  All Rights Reserved.
When you contribute anything to Wikipedia, you agree to this:
You agree to license your contributions under the GFDL.
Only the copyright holder has the right to relicense their work. (Boborok 16:05, 10 May 2006 (UTC))


Just in response to "if Data: URI's would be infringing, somebody should check out the pages for E-Mails, HTTP, IRC, Jabber, etc. because they are all RFC's" - none of our articles should be verbatim copies of RFCs, since RFC content is not, per se, encyclopedic; Wikipedia is not a primary source. However, many articles will discuss and even quote from copyrighted standards, but neither of those would constitute copyright infringement, so there's very unlikely to be a problem. - IMSoP 13:06, 21 September 2006 (UTC)

[edit] data: URI examples

Also, I would like to add data: URI examples but how do I link to them? I tried [data:,] and <a href="data:,"> formats but neither are turned into links... How do I do this? (Boborok 16:05, 10 May 2006 (UTC))

Its better to avoid them, bcoz it wont be accessible by 85% (whatever the market share of ie is) of the web browsing public. --soUmyaSch 19:30, 10 May 2006 (UTC)
These stats [1] show 72% but I think it would be significantly less among users reading the data: URI article. Anyway it looks like there is no way to add them :) (Boborok 21:34, 10 May 2006 (UTC))

[edit] Looks like IE8 should support this

According to this: http://blogs.msdn.com/ie/archive/2007/12/19/internet-explorer-8-and-acid2-a-milestone.aspx#6810063 —Preceding unsigned comment added by 70.183.120.25 (talk) 08:44, 20 December 2007 (UTC)

[edit] IE about: urls

I removed:

Early versions of Internet Explorer treated unrecognised about: URIs as HTML source, so something like about:<b>bold</b> in these versions was broadly equivalent to data:text/html,<b>bold</b> in browsers that support data: URIs[citation needed]

because

  • No references
  • Doesn't specify which versions
  • Not even quite true: Whereas data: URIs are most useful in including an image, like data:image/gif;base64,aoeu023ithaoeu, not displaying bold text or a web page. About: would not seem to be very equivalent.
  • Not a very useful fact, since it does not provide an alternative to data: as the latest versions of IE do not support it, and as it would not allow the inclusion of images (AFAIK) as notod above.
  • For something so irrelevant, it was one of the first things in the article. Perhaps it should be moved to something like a "see also" section.

If you disagree, please discuss it. --Temporitron (talk) 19:45, 10 January 2008 (UTC)

[edit] server-side / PHP

Disadvantages include greater server CPU and disk use unless a server-side cache is used.

I'm going to quibble with this. Disk use is not necessarily increased... if the script is generating a CSS page, the server only has to access the image files exactly as many times as it would have if they were referenced in the standard way: either the server loads the file to create the base64 encoding, or the client makes the server serve the file when the client is rendering the page. I removed the bold section and feel it should stay gone. --Temporitron (talk) 19:57, 10 January 2008 (UTC)

this entry quality is horrible. Need lots of enhancements. --Tei

[edit] Safari 3

The commentary about Safari needs some clarity. I've read the paragraph several times and can't tell if it means yes, Safari does render data: URIs, or no it doesn't. (In fact, Safari 3 does.) Using "although" starts an inversion, a negating clause. Can that paragraph be rewritten so any average reader would know what the final answer is? I can't because I'm not sure what point it was making exactly. John Sinclair (talk) 08:34, 25 May 2008 (UTC)