What is the difference between "image/png" and "image/x-png"?
The x- prefix is given to non-standard MIME types (i. e. not registered with IANA). So I assume that image/x-png would have been PNG before the MIME type was standardized.
6.3. New Content-Transfer-Encodings
Implementors may, if necessary, define private Content-Transfer-Encoding values, but must use an x-token, which is a name prefixed by “X-”, to indicate its non-standard status, e. g., “Content-Transfer-Encoding: x-my-new-encoding”. Additional standardized Content-Transfer-Encoding values must be specified by a standards-track RFC.
The requirements such specifications must meet are given in RFC 2048.
As such, all content-transfer-encoding namespace except that
beginning with “X-” is explicitly reserved to the IETF for future
use.
—RFC 2045 — Multipurpose Internet Mail Extensions, Section 6.3
This is also documented in the PNG specification. See FalseVinylShrub's answer.
According to http://www.w3.org/TR/PNG/#A-Media-type
The internet media type "image/png" is the Internet Media Type for PNG [RFC-2045], [RFC-2048]. It is recommended that implementations also recognize the media type "image/x-png".
So, if you're delivering or uploading a PNG image, 'image/png' is the correct one to use. However, if you're accepting uploads or otherwise interpreting the media type, you are recommended to accept either.
By the way, I found a reference from 2008 that Internet Explorer (version unspecified) was uploading PNG images with a type of image/x-png, so this was a real issue for someone as recently as that.
image/x-png was the type before PNG was accepted by the IANA as an official mime type.
http://www.iana.org/assignments/media-types/image/
The official image/png MIME type for PNG, approved on 14 October 1996
http://www.w3.org/Graphics/PNG/
According to Wikipedia's article on Internet Media Types, and the article it cites...
Types or subtypes that begin with x-
are nonstandard
So my guess is "image/x-png" is probably leftover from the days when png was pretty new, and as such, not standardized.
Related
I do understand there are 2 ways to set the encoding:
By using Content-Type header.
By using meta tags in HTML
Since Content-Type header is not mandatory and is required to be set explicitly (the server side can set it if it wants) and meta tag is also optional.
In case both of these are not present, how does the browser determine the encoding used for parsing the content?
They can guess it based on heuristic
I don't know how good are browsers today at encoding detection but MS Word did a very good job at it and recognizes even charsets I've never heard before. You can just open a *.txt file with random encoding and see.
This algorithm usually involves statistical analysis of byte patterns, like frequency distribution of trigraphs of various languages encoded in each code page that will be detected; such statistical analysis can also be used to perform language detection.
https://en.wikipedia.org/wiki/Charset_detection
Firefox uses the Mozilla Charset Detectors. The way it works is explained here and you can also change its heuristic preferences. The Mozilla Charset Detectors were even forked to uchardet which works better and detects more languages
[Update: As commented below, it moved to chardetng since Firefox 73]
Chrome previously used ICU detector but switched to CED almost 2 years ago
None of the detection algorithms are perfect, they can guess it incorrectly like this, because it's just guessing anyway!
This process is not foolproof because it depends on statistical data.
so that's how the famous Bush hid the facts bug occurred. Bad guessing also introduces a vulnerability to the system
For all those skeptics out there, there is a very good reason why the character encoding should be explicitly stated. When the browser isn't told what the character encoding of a text is, it has to guess: and sometimes the guess is wrong. Hackers can manipulate this guess in order to slip XSS past filters and then fool the browser into executing it as active code. A great example of this is the Google UTF-7 exploit.
http://htmlpurifier.org/docs/enduser-utf8.html#fixcharset-none
As a result, the encoding should always be explicitly stated.
I've encountered problem with output encoding of HTML. If you are creating website or webservice with .i.e nodejs or golang... and you're not sure just add Content-Type charset to header:
For example in golang: resp.Header.Set("Content-Type", "text/html; charset=GB18030");
It is set in the <head> like this:
<meta charset="UTF-8">
I think if this is not set in the head the browser will set a default encoding.
I would like to use the UTF-8 character ✖ on my site but I am not sure if this will be supported cross browser.
I am worried that:
a) Users will not have access to a font containing that character
b) IE will not find the character even if the user has a font that could display it. I am worried about this because of this info:
By the specifications, browsers should display a character if there is any font in the system that contains it. If the fonts specified by the author (in CSS font-family settings or, rarely these days, using font markup in HTML) do not contain the character, browsers are supposed to use fallback fonts. The same applies if no fonts are specified by the author; browsers should use primarily their default fonts, using alternate fonts for any character not covered by the primary font.
In practice, things don’t always work that way. Especially IE is notorious for its failures in this respect. It often fails to display a character, even though it could do that if it used all the fonts in the system. If a browser cannot render a character, it may show a small rectangle, possibly containing a question mark, ?, or some similar indicator. Here’s a quick test (character U+0840, which is probably not supported by any font on your computer): ࡀ.
Source.
c) Other issues that I have though of.
There is a resource called Unify, that will show what devices the character is supported on but it currently (Sept 14, 2015) only suport 107 characters.
So to summarize, the question is: How can I determine if it is safe to use a utf-8 special character on my site? Is it safe to use ✖ specifically on my site?
It's always safe - your user's computers won't suddenly burst into flame.
From a technical perspective, your best bet is to use a web font that has support for every Unicode character you want to use. That is not a catch-all (the user might have web fonts disabled or is using a command line browser, etc...), but it should support the vast majority of computers.
From there I would apply common sense. If the displaying of a character is absolutely crucial and lives depend on it, try to not use Unicode. Otherwise I'd say 'go ahead'.
This is as much a UX question as it is a technical one, so I will mention both.
As a comparison, on my IE11 browser, it looks like this: , but on my Firefox 31.8, it looks like this: . A good user experience is generally associated with consistency, and this approach is not very portable. So from a UX perspective, this is not a great solution.
I would say using a tiny *.gif or *.bmp, or even *.png if you need transparency, is a better solution. Even better yet, go with *.svg so scaling will not be an issue. From a technical aspect, the overhead of something that small is generally insignificant.
The only problem you can face is that exotic symbols are not implemented in many fonts, so the user can see a dummy character (e.g. square) instead of this. I personally like to use svg symbols for this purpose.
An alternative solution would be to use a web font with those icons in it (although probably a subset version of, so that it's less and 1 kb and doesn't weight down your pages).
How (or why) does 2854 "obsolete" 1867?
This may simply come down to my not understanding how to read RFCs, but from what I can discern, 1867 describes how file uploading works with HTML forms and 2854 is about a MIME type not used in HTML forms. Two completely different things?
RFC 2584 marks the end of the Internet Engineering Task Force's involvement in the HTML specification. Further work was continued by the World Wide Web Consortium.
RFC 2584 reads:
The IETF HTML working group closed Sep 1996, and work on defining HTML moved to the World Wide Web Consortium (W3C).
RFC 2584 obsoletes RFC 1867 and many other RFCs in the sense that HTML in its entirety was removed from the IETF's purview. This obsolesence of its previous HTML-related RFCs affirms that decision. And if you were to search for "HTML" on the IETF's RFC site, you'd see there's virtually no HTML-related activity since RFC 2584.
Also note that RFC 1867 was an experimental RFC. According to the IETF's "The Tao of IETF":
Experimental RFCs are for specifications that may be interesting, but for which it is unclear if there will be much interest in implementing them, or whether they will work once deployed. That is, a specification might solve a problem, but if it is not clear that many people think that the problem is important, or think that they will bother fixing the problem with the specification, the specification might be labeled an Experimental RFC.
I was reading through a website named w3schools and was taking the HTML5 lesson. There I saw a number of deprecated tags in HTML5 that were before accepted by HTML4. One of its tag were <applet>! So are now applets of no use?
You can see it here: HTML5 New Elements(at the end)
or here:
Applets (as applications written in Java and intended to run inside a browser) are not deprecated in any way in HTML specifications or drafts. There is decreasing interest in them, due to many other alternatives being available, but that’s a different issue.
The applet element was declared deprecated in HTML 4, in favor of the object element. In HTML 4, deprecation means that element is still part of the language, browsers are recommended to support it (though in practice, not all browsers support it, and some browsers could not support it), but there is a recommendation to use something else (in this case, object) instead of it.
In HTML5 CR, the word “deprecated” is not used. It uses the term “obsolete”, which means in principle something quite different but comes very close in practice. In HTML5 CR, the applet element is declared “entirely obsolete and non-conforming”, with the note that it “must not be used by authors”. Yet, HTML5 contains a definition of applet under “Requirements for implementations”. And HTML5 conformance requirements specify that normal browsers must (not just should) support it.
One of the few real differences between the HTML 4 concept “deprecated” and the HTML5 concept “obsolete” is in validation: when validating against an HTML 4 DTD, applet is accepted when the Transitional DTD is used (but flagged as an error when validating against the Strict DTD); in HTML5 validation, applet is reported as an error.
P.S. W3schools should not be used as any kind of authority or reference, see http://w3fools.com
UPDATE 2021 - Applets were officially deprecated by Oracle in Java 9. So while W3Schools were not strictly correct at the time that this article was written, what they said then is correct ... now.
The main reason that Oracle gave for deprecating Applets was that most modern web browsers have stopped supporting them. As of right now, (AFAIK) only Internet Explorer still supports Applets, and IE is due to go EOL in mid 2022.
They are still of use, but use the object tag instead. Example:
<object
width = "800"
height = "510"
data = "http://math.hawaii.edu/~ralph/Classes/Plotting/fplotter.jar"
type = "application/x-java-applet"
>
<param
name = "codebase"
value = "http://math.hawaii.edu/~ralph/Classes/Plotting/"
/>
<param
name = "code"
value = "a_fplotter.class"
/>
<param
name = "width"
value = "800"
/>
<param
name = "height"
value = "510"
/>
<param
name = "archive"
value = "fplotter.jar"
/>
</object>
Applet deprecated in Java 9
Applets are deprecated in Java 9. Oracle will stop distributing and supporting the Java browser plug-in.
Quoting from the java.applet.Applet class:
The Applet API is deprecated. See the java.applet package documentation for further information.
See this blog post from Oracle for more info: Moving to a Plugin-Free Web
Consider Java Web Start technology.
Disregarding whether or not applets are a good idea,
Use the <object> element instead. That's the standards complaint way.
The object element can represent an external resource, which, depending on the type of the resource, will either be treated as an image, as a nested browsing context, or as an external resource to be processed by a plugin.
I'm getting this error in w3C HTML 5 validator
Line 9, Column 101: Bad value
apple-touch-icon-precomposed for
attribute rel on element link: Keyword
apple-touch-icon-precomposed is not
registered. …-icon-precomposed"
sizes="72x72"
href="images/sl/touch/m/apple-touch-icon.png">
Syntax of link type valid for :
A whitespace-separated list of link
types listed as allowed on in
the HTML specification or listed as an
allowed on on the Microformats
wiki
How to fix this error?
Ignore it.
If that's the only error you have, then your document is valid HTML5.
Here's what the official (in development) spec states about the <meta> tag: Extensions to the predefined set of metadata names may be registered. I can't find the area in the spec that talks about the "ref" tag values, but the validator treats them similarly (one for links, one for strings), and points us to the extension Wiki. You 'may' register them, but don't have to. In RFC terminology this is a SHOULD not a MUST.
The spec doesn't seem to mandate a fixed list, or use of the Wiki. Doing so would seem odd, as these fields have often evolved with time. It does state that Conformance checkers must use the information given on the WHATWG Wiki MetaExtensions page to establish if a value is allowed or not: values defined in this specification or marked as "proposed" or "ratified" must be accepted. which is an interesting line as it is a specification for the HTML Validators, not HTML5 itself, and doesn't itself make the markup invalid.
In fact, many of these "extensions" are already in the wiki (including your one), they just haven't been accepted. Same with many meta tags, even very common ones. It seems many won't be accepted either.
I think it's very nice of the W3C to create a standardised list of these. It helps developers know what they should be using now and in the future (and can hopefully clean up some things linke reducing the number of ways you can specify a creation date from 5+ to 1).
Unfortunately we are dealing with third parties here (e.g. Apple) – and unless you want to contact every third party who has created one of these informal specification, and tell them to formalize a spec, and submit it to the W3C's list (which may or may not get accepted) what are you to do? At the end of the day you still need to support it.
Anyway, isn't the very point of having these HTML elements to support extensions so vendors don't break the spec by adding new elements to do what the need?
If you move the touch icons into your web root and follow the Apple documentation for naming conventions, you won't actually need to insert the link tags in your HTML and will avoid those validation errors.
The iOS devices will look for the icons in the web root automatically, using the predefined naming conventions and the correct resolution as also outline here. Good luck.
Delete the element from your source.
You probably don't want to do that though. Remember that validation is a tool, not a competition.
You might want to edit the wiki of supported link types and then wait for the validator to catch up.