HDML and WML are special-purpose markup languages that were invented for pre-smartphone era mobile phones with their limited display, processor and data transmission capabilities. They are inspired by HTML, but rely heavily on “cards” – which you can think of as interactive slides with single actions. XHTML Mobile Profile was much closer to Web standards. WAP and i-mode were the streamlined and controlled alternatives to the real, open Web back in the day (10 to 20 years ago).
Anyhow, there is one feature that mobile browsers also supported with XHTML-MP that was really just specified for HDML/WML: local image resources. There are various approaches (and a good overview from 2012 at Mobiforge).
WML and XHTML over WAP
This WML code is actually also valid (X)HTML, because it doesn’t use any custom element types or attributes, but relies on the standard nested fallback model of the
object element which WML imported from HTML. The predefined set of graphics usable with
pict: is found in WAP-213 Pictogram Specification (section 7) from 2001. It is almost completely covered by existing Unicode emojis, although some mappings are not quite obvious.
This URL scheme could be added to the set of Web specs and a registry for additional values (e.g. more recent emojis) be set up.
localsrc attribute has been added to WML’s
img element and many WAP browsers also support(ed) it within XHTML. The local image was the preferred one, the remote resource in
src or, ultimately, the string in
alt is the fallback!
<img icon="68" src="/img/emoji/U263a.svg" alt=":-)" />
<img icon="smileyface" src="/img/emoji/263A.png" alt=":smile:" />
Similar to WML, its alternative and predecessor HDML had a custom attribute for local image resource, called
icon here. The supported values dependended on the vendor, but numbers below 1000 were used the most. I’m believe
icon was preferred over
NTT i-mode, Unicode Emoji: Character references
Prior to Unicode 6, each Japanese telco used different Shift-JIS codes for related sets of emojis. The original i-mode set was supported by all(?) of them and there were extensive m:n mapping tables for the codes of the extended sets, which formed the base of standardization. The glyphs – especially Softbank’s ones by Apple – were also assigned to Unicode PUA codes in the BMP (U+Exyz). Nowadays, standard Unicode emojis are found throughout BMP (e.g. in U+26xy) and SMP (with many at U+1Fxyz). They can be referenced by numeric character references, in either decimal
Ӓ or hexadecimal
Today, symbol fonts like Font Awesome are also using Unicode PUA code points (e.g. U+Fxyz) – often despite appropriate normal code points being available – and frequently, in HTML, an abomination of empty class-laden
i element instances for attaching CSS generated content – allegedly following conventions set by Twitter Bootstrap. If the font resource doesn’t load, this technique may fall back badly to other fonts using the same private-use code points for utterly different glyphs, e.g. unrelated emojis.
<link rel="stylesheet" href="path/to/font-awesome/css/font-awesome.min.css">
<a class="btn btn-default" href="path/to/settings" aria-label="Settings">
<i class="fa fa-cog" aria-hidden="true"></i>
Emoji shortcodes or shortnames
For many facial emojis there are traditional Western sideways ASCII art emoticons
:-) or Eastern kaomoji
(^_^), although no universally accepted convention exists for their equivalences. Likewise, many (server-side) frameworks that replace emoji characters by image files are supporting English code names enclosed in colons
:smile:, much like HTML named entity references
ä. It’s allegedly easier or safer to work with these in some programming languages (e.g. PHP) or database systems than directly with supplementary plane Unicode characters.
Resource Identifiers at WHATWG Wiki proposes a
res attribute that works in the opposite direction:
I’m not sure which would be the best way to reference local, preinstalled or cached resources. I don’t have much experience with the
source element and its
srcset attribute either, by the way.
This could be one approach to edit Embedded Content etc. in the HTML specs:
Add the legacy
localsrc attribute to all HTML element types that support a
data atribute and to
link, but not other element types that support an
Do not add an
Do not standardize the
pict: URL scheme (and do not reuse