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

URL scheme

<object   data="pict:///time/season/winter">
  <object data="pict:///weather/snow">
    <img   src="http://www.pict.com/xx/snowman.wbmp"
           alt="snowman" />
  </object>
</object>

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.

Extra localsrc attribute

<img localsrc="pict:///core/arrow/right"
          src="http://www.pict.com/xx/rightArrow.wbmp"
          alt="→" />

The 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!

HDML icon attribute

<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 src.

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 ꯍ notation.

☺️ 😀    

Symbol fonts

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>
</a>

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.

Related

Resource Identifiers at WHATWG Wiki proposes a res attribute that works in the opposite direction:

<img src="local/copy/of/something.png"
     res="org.gov.mil.something.png" />

Lazy Loading

• Resource Hints
• Resource Priorities
• A standard way to lazy-load images (WICG#1153)

Draft Proposal

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 src or data atribute and to link, but not other element types that support an href attribute. Do not add an icon attribute. Do not standardize the pict: URL scheme (and do not reuse local: or about: either).

When I wrote the above a while ago, I apparently made a mistake regarding HDML: the attribute wasn’t called icon but name according to the specification I linked to.

https://www.w3.org/TR/hdml20-6.html#HEADING6-177

The example would then become:

<img name="68" src="/img/emoji/U263a.svg" alt=":-)">
<img name="smileyface" src="/img/emoji/263A.png" alt=":smile:">

I was not able to get the jest of this proposal. If it goes towards multiple fallbacks, there are several ways to achieve it in HTML5, the object wrapping is just one of those.

The template proposal has given the local fallback option to any content including the image. Its custom-element implementation would provide the fine grained control over fallback chains.

But just a fallback does not look like an essence of this proposal.

@Crissov , can you express the proposal in sentence or two, please?

I think I’m nowadays leaning more towards reviving the pict: URL scheme with an actively maintained registry and use it within <picture><source media="(prefers-reduced-data: reduce)" srcset="pict:…">.

PS: I actually went there already: Using emojis as images