Icon fonts in FxOS

[Jet Villegas]

Hi All:

We need a path forward on the deployment of Icon fonts in FxOS. The Gaia team understandably wants to squeeze every bit of performance on their apps in v1.4:
https://bugzilla.mozilla.org/show_bug.cgi?id=951593

We are concerned about leaking these fonts into Open Web content, so we want to restrict it to certified Gaia apps:
https://bugzilla.mozilla.org/show_bug.cgi?id=1008458

The approach we take to restrict icon fonts to certified Gaia apps is under some debate, and we've got 4 possibilities:

1. Let people use the icon fonts anywhere. (ie. like "MS WingDings" can be used for this purpose)
2. The patch in bug 1008458 introduces "private" fonts that use the Unicode Private Use Area (PUA) for icon glyphs.
3. Use PUA characters as per bug 1008458 but disable use of PUA characters in local fonts on all platforms except for FirefoxOS certified apps.
4. Use the OpenType discretionary ligatures ("dlig") feature to hide the glyphs ( see https://bugzilla.mozilla.org/show_bug.cgi?id=1008458#c22 )

I'm afraid of the amount of code in the patch for bug 1008458 for the 1.4 release, so I'm inclined to let the Gaia team use the icon font as-is (option 1) with the promise that they won't use it in uncertified non-system apps.

I also propose that we make any required code changes in v2.0 so that non-certified apps can't get unrestricted use of the font. All the options proposed (#2,3, or 4,) have drawbacks, the common one being that they may be overly restrictive.

I'd like some feedback here, first on my proposal that we go with Option 1 for 1.4. Second, I'd like us to solve the font leakage problem for 2.0 with one of the 3 other proposals, if still needed--I'd like to see how far we get to improve SVG performance (bug 999931) to make all this a moot point. I really am not a fan of icon fonts (see https://twitter.com/73inches/status/468368206282113024/photo/1 )

Thanks,

--Jet

[James Burke]

On 6/16/14, 12:34 PM, Jet Villegas wrote:
> I also propose that we make any required code changes in v2.0 so that non-certified apps can't get unrestricted use of the font. All the options proposed (#2,3, or 4,) have drawbacks, the common one being that they may be overly restrictive.
>

The Gaia email app has gone privileged instead of certified just
recently. I expect that most partners will want to deliver the email app
with the same look and feel as the other apps that may be certified. If
that means the use of the icon font, we might have some trouble.

In general, I prefer solutions that do not require certified status, as
I hope more apps for gaia can move to privileged and even be delivered
through the Marketplace and for Android devices that can use Marketplace
apps.

I can appreciate there are other factors involved, just mentioning a
general desire to move more to apps out of the certified embrace. For
email, I will likely look for any alternatives that allow us to stay
privileged instead of reverting to certified.

James

[Patryk Adamczyk]

Comments inline.

> 1. Let people use the icon fonts anywhere. (ie. like "MS WingDings" can be used for this purpose)

We can always host the icon fonts on github to download. Could web developers package the icon fonts in the apps itself? That way they can use the font outside of Gaia if they want, and when perhaps we can write some script that would use the system icon fonts if they are present, otherwise it would fall back to the ones packaged in the app. That way we can get the performance gain.

It would be good if we can even go with 1 app to type this out for the next release, our initial plan was Settings.

> 2. The patch in bug 1008458 introduces "private" fonts that use the Unicode Private Use Area (PUA) for icon glyphs.
> 3. Use PUA characters as per bug 1008458 but disable use of PUA characters in local fonts on all platforms except for FirefoxOS certified apps.
> 4. Use the OpenType discretionary ligatures ("dlig") feature to hide the glyphs ( see https://bugzilla.mozilla.org/show_bug.cgi?id=1008458#c22 )

To me feels like #2 and #4 are the cleanest, #4 being the least code intensive, especially if we’d ideally want to go pure SVG.

> I'd like some feedback here, first on my proposal that we go with Option 1 for 1.4. Second, I'd like us to solve the font leakage problem for 2.0 with one of the 3 other proposals, if still needed--I'd like to see how far we get to improve SVG performance (bug 999931) to make all this a moot point. I really am not a fan of icon fonts (see https://twitter.com/73inches/status/468368206282113024/photo/1 )

We on the visual design team would prefer SVG over Icon Font as well, clearly there are some performance limitations as you cited, so we opted for icon fonts for the system icons since they are single colour. Each release we spend weeks trying to update graphics, so the sooner we can get something in place the better.

---
Patryk Adamczyk, R.G.D.
Design Manager - Visual Design, Firefox OS
Mozilla Corporation

[Jonathan Kew]

OK, that's useful info, thanks! And it significantly changes the
picture, as it means that implementing a platform-level solution
targeting certified apps may be less useful than expected.

JK

[Masatoshi Kimura]

(2014/06/17 4:34), Jet Villegas wrote:
> 1. Let people use the icon fonts anywhere. (ie. like "MS WingDings" can be used for this purpose)

Actually WingDings can NOT be used at least on desktop Firefox because
it does not have a unicode cmap. Does Firefox OS have an option to relax
this restriction?

[Wilson Page]

We are using icon-fonts in some of the new web-component based building-blocks examples. I have created a gaia-icons repo so that our components can explicitly depend on these icons. Inside this repo we have all the source SVGs inside `images/`. A grunt task called grunt-webfont converts all these SVGs into a single icon-font. To add new icons, you simple have to drop new SVGs into the `images/` directory.

Icon fonts are perfect for our themeability requirements as they can easily by styled with CSS. AFAIK SVGs cannot be colored/styled with CSS alone (but I don't know that much about SVG).

We've been using icon-fonts in Camera for a while now and so far it's been great. I plan to move Camera to pull its icon-font from gaia-icons so that we can begin to move to toward a central icons store.

IMO SVG and icon-fonts will always serve slightly difference use cases. But for simple icons, icon-fonts have always got the job done; allowing me to focus on the more important stuff :p

W.

----- Original Message -----

From: "Patryk Adamczyk" <pada...@mozilla.com>
To: "Jet Villegas" <j...@mozilla.com>
Cc: "John Daggett" <jdag...@mozilla.com>, "b2g-internal" <b2g-in...@mozilla.org>, "Cameron McCormack" <hey...@gmail.com>, "Jonathan Watt" <jw...@mozilla.com>, "L. David Baron" <dba...@mozilla.com>, "Jaime Chen" <jac...@mozilla.com>, "Vivien" <vnic...@mozilla.com>, "sicking" <sic...@mozilla.com>, "Robert O'Callahan" <rocal...@mozilla.com>, "Jonathan Kew" <jk...@mozilla.com>, "mozilla.dev.platform group" <dev-pl...@lists.mozilla.org>
Sent: Monday, June 16, 2014 10:14:19 PM
Subject: Re: Icon fonts in FxOS

Comments inline.

1. Let people use the icon fonts anywhere. (ie. like "MS WingDings" can be used for this purpose)

We can always host the icon fonts on github to download. Could web developers package the icon fonts in the apps itself? That way they can use the font outside of Gaia if they want, and when perhaps we can write some script that would use the system icon fonts if they are present, otherwise it would fall back to the ones packaged in the app. That way we can get the performance gain.

It would be good if we can even go with 1 app to type this out for the next release, our initial plan was Settings.

<blockquote>

2. The patch in bug 1008458 introduces "private" fonts that use the Unicode Private Use Area (PUA) for icon glyphs.
3. Use PUA characters as per bug 1008458 but disable use of PUA characters in local fonts on all platforms except for FirefoxOS certified apps.
4. Use the OpenType discretionary ligatures ("dlig") feature to hide the glyphs ( see https://bugzilla.mozilla.org/show_bug.cgi?id=1008458#c22 )

</blockquote>

To me feels like #2 and #4 are the cleanest, #4 being the least code intensive, especially if we’d ideally want to go pure SVG.

<blockquote>

I'd like some feedback here, first on my proposal that we go with Option 1 for 1.4. Second, I'd like us to solve the font leakage problem for 2.0 with one of the 3 other proposals, if still needed--I'd like to see how far we get to improve SVG performance (bug 999931) to make all this a moot point. I really am not a fan of icon fonts (see https://twitter.com/73inches/status/468368206282113024/photo/1 )

</blockquote>

We on the visual design team would prefer SVG over Icon Font as well, clearly there are some performance limitations as you cited, so we opted for icon fonts for the system icons since they are single colour. Each release we spend weeks trying to update graphics, so the sooner we can get something in place the better.

---
Patryk Adamczyk, R.G.D.
Design Manager - Visual Design, Firefox OS
Mozilla Corporation

_______________________________________________
b2g-internal mailing list
b2g-in...@mozilla.org
https://mail.mozilla.org/listinfo/b2g-internal

[Jet Villegas]

Wilson:

How difficult would it be to have your grunt script add a dlig table to your font?
https://www.microsoft.com/typography/otspec/features_ae.htm#dlig
https://bugzilla.mozilla.org/show_bug.cgi?id=1008458#c22

--Jet

[Wilson Page]

The gaia-icons font currently uses ligatures to place icons, see here . The ligature character sequence is derived from the original filename of the SVG source file in `images/`.

Is this what you were referring to?

W.

----- Original Message -----

From: "Jet Villegas" <j...@mozilla.com>
To: "Wilson Page" <wilso...@mozilla.com>
Cc: "Patryk Adamczyk" <pada...@mozilla.com>, "John Daggett" <jdag...@mozilla.com>, "b2g-internal" <b2g-in...@mozilla.org>, "Cameron McCormack" <hey...@gmail.com>, "Jonathan Watt" <jw...@mozilla.com>, "L. David Baron" <dba...@mozilla.com>, "Jaime Chen" <jac...@mozilla.com>, "Vivien" <vnic...@mozilla.com>, "sicking" <sic...@mozilla.com>, "Robert O'Callahan" <rocal...@mozilla.com>, "Jonathan Kew" <jk...@mozilla.com>, "mozilla.dev.platform group" <dev-pl...@lists.mozilla.org>
Sent: Tuesday, June 17, 2014 12:54:57 AM
Subject: Re: Icon fonts in FxOS

[Wilson Page]

I'm inlining to minimise cross-origin issues and to reduce requests. The entire asset is <12k so I'm really not concerned with performance here, especially considering the number of PNG assets this replaces. We've been using a similar approach in Camera for quite some time and all has been well. I think there are better areas we can focus performance efforts.

I'm not exactly sure if glyphs are still assigned to code points within the generated font, is that an issue?

IMO we should just treat icon assets in the same way we do images assets. Baking them into the platform seems like it could cause unnecessary complications further down the line, for negligible perf gains. At the end of the day we're a collection of web-apps, the more we exploit our platform power, the further we distance ourselves from the real web platform.

W.

----- Original Message -----

From: "Jonathan Kew" <jk...@mozilla.com>
To: "Wilson Page" <wilso...@mozilla.com>, "Jet Villegas" <j...@mozilla.com>
Cc: "Patryk Adamczyk" <pada...@mozilla.com>, "John Daggett" <jdag...@mozilla.com>, "b2g-internal" <b2g-in...@mozilla.org>, "Cameron McCormack" <hey...@gmail.com>, "Jonathan Watt" <jw...@mozilla.com>, "L. David Baron" <dba...@mozilla.com>, "Jaime Chen" <jac...@mozilla.com>, "Vivien" <vnic...@mozilla.com>, "sicking" <sic...@mozilla.com>, "Robert O'Callahan" <rocal...@mozilla.com>, "mozilla.dev.platform group" <dev-pl...@lists.mozilla.org>
Sent: Tuesday, June 17, 2014 11:31:18 AM
Subject: Re: Icon fonts in FxOS

On 17/6/14 11:10, Wilson Page wrote:



The gaia-icons font currently uses ligatures to place icons, see here . The ligature character sequence is derived from the original filename of the SVG source file in `images/`.

Is this what you were referring to?

OK, so if you're using ligatures to access the icon glyphs, can you modify the script that generates this font so that it does NOT assign PUA codepoints to the glyphs at all? It should be possible to leave them unencoded (i.e. with no entry in the font's cmap), so that the only way they can be accessed is via the ligature sequence.

I see you're embedding the generated font directly in a CSS file as a data-URL. How's the performance of this approach? It won't be quite as efficient as installing the font in the base OS, because each app that uses it will be instantiating its own separate copy, so there must be a memory and perf cost. But maybe it's good enough?

JK


<blockquote>

----- Original Message -----

From: "Jet Villegas" <j...@mozilla.com>
To: "Wilson Page" <wilso...@mozilla.com>
Cc: "Patryk Adamczyk" <pada...@mozilla.com> , "John Daggett" <jdag...@mozilla.com> , "b2g-internal" <b2g-in...@mozilla.org> , "Cameron McCormack" <hey...@gmail.com> , "Jonathan Watt" <jw...@mozilla.com> , "L. David Baron" <dba...@mozilla.com> , "Jaime Chen" <jac...@mozilla.com> , "Vivien" <vnic...@mozilla.com> , "sicking" <sic...@mozilla.com> , "Robert O'Callahan" <rocal...@mozilla.com> , "Jonathan Kew" <jk...@mozilla.com> , "mozilla.dev.platform group" <dev-pl...@lists.mozilla.org>
Sent: Tuesday, June 17, 2014 12:54:57 AM
Subject: Re: Icon fonts in FxOS

Wilson:

How difficult would it be to have your grunt script add a dlig table to your font?
https://www.microsoft.com/typography/otspec/features_ae.htm#dlig
https://bugzilla.mozilla.org/show_bug.cgi?id=1008458#c22

--Jet

----- Original Message -----
From: "Wilson Page" <wilso...@mozilla.com>

We are using icon-fonts in some of the new web-component based building-blocks examples. I have created a gaia-icons repo so that our components can explicitly depend on these icons. Inside this repo we have all the source SVGs inside `images/`. A grunt task called grunt-webfont converts all these SVGs into a single icon-font. To add new icons, you simple have to drop new SVGs into the `images/` directory.

</blockquote>

[Wilson Page]

Maybe I'm late to the party, but I don't know what the PUA issue is?

I suggest we offer gaia-icons repo that's an easy/ready-to-go package. If app owners wish to refine the icon-font to just the glyphs they need (to trim off a few kb) then they could run their own grunt-webfont script using a sub-set of SVGs from the gaia-icons repo. I'm always in favor of anti-magic/transparent solutions and performance work once issues are proven, not before :)

W.

----- Original Message -----

From: "Jonathan Kew" <jk...@mozilla.com>
To: "Wilson Page" <wilso...@mozilla.com>
Cc: "Jet Villegas" <j...@mozilla.com>, "Patryk Adamczyk" <pada...@mozilla.com>, "John Daggett" <jdag...@mozilla.com>, "b2g-internal" <b2g-in...@mozilla.org>, "Cameron McCormack" <hey...@gmail.com>, "Jonathan Watt" <jw...@mozilla.com>, "L. David Baron" <dba...@mozilla.com>, "Jaime Chen" <jac...@mozilla.com>, "Vivien" <vnic...@mozilla.com>, "sicking" <sic...@mozilla.com>, "Robert O'Callahan" <rocal...@mozilla.com>, "mozilla.dev.platform group" <dev-pl...@lists.mozilla.org>
Sent: Tuesday, June 17, 2014 12:08:52 PM
Subject: Re: Icon fonts in FxOS

On 17/6/14 11:52, Wilson Page wrote:



I'm inlining to minimise cross-origin issues and to reduce requests. The entire asset is <12k so I'm really not concerned with performance here, especially considering the number of PNG assets this replaces. We've been using a similar approach in Camera for quite some time and all has been well. I think there are better areas we can focus performance efforts.

I'm not exactly sure if glyphs are still assigned to code points within the generated font, is that an issue?

I looked at the embedded font in your CSS file, and it has the icons encoded at PUA character codes U+E001..E01D. If we could avoid exposing PUA codes at all, that would be helpful, as it eliminates any risk that authors actually use (non-portable) PUA codes to render the icons.

AFAIK, it should be possible to do this. In fontforge, the glyphs are referenced by name; they shouldn't need codepoints assigned.


<blockquote>

IMO we should just treat icon assets in the same way we do images assets. Baking them into the platform seems like it could cause unnecessary complications further down the line, for negligible perf gains. At the end of the day we're a collection of web-apps, the more we exploit our platform power, the further we distance ourselves from the real web platform.

</blockquote>

If this works acceptably, can we close bug 951593 (and 1008458) as WontFix? That'd be awesome, IMO, as none of the proposed strategies there are really satisfactory. Where are we at w.r.t. the launch regression that was filed as bug 1002904? Has the data-URL version of the embedded font been tried there?

One other optimization you might want to consider - especially as the icon collection grows - is to have your build scripts generate a custom font subset for each app that's using them, instead of having all the apps (separately) load the complete set of icons even if they only need a few. So the original collection of graphics would be a shared "building block" resource, but the actual CSS that embeds the font would be individually generated for each app depending on its needs. (Presumably it'd be simple to scan the app's files and determine exactly which icons it needs.)

JK


<blockquote>

W.

----- Original Message -----

From: "Jonathan Kew" <jk...@mozilla.com>
To: "Wilson Page" <wilso...@mozilla.com> , "Jet Villegas" <j...@mozilla.com>
Cc: "Patryk Adamczyk" <pada...@mozilla.com> , "John Daggett" <jdag...@mozilla.com> , "b2g-internal" <b2g-in...@mozilla.org> , "Cameron McCormack" <hey...@gmail.com> , "Jonathan Watt" <jw...@mozilla.com> , "L. David Baron" <dba...@mozilla.com> , "Jaime Chen" <jac...@mozilla.com> , "Vivien" <vnic...@mozilla.com> , "sicking" <sic...@mozilla.com> , "Robert O'Callahan" <rocal...@mozilla.com> , "mozilla.dev.platform group" <dev-pl...@lists.mozilla.org>
Sent: Tuesday, June 17, 2014 11:31:18 AM
Subject: Re: Icon fonts in FxOS

On 17/6/14 11:10, Wilson Page wrote:

<blockquote>

The gaia-icons font currently uses ligatures to place icons, see here . The ligature character sequence is derived from the original filename of the SVG source file in `images/`.

Is this what you were referring to?

</blockquote>

OK, so if you're using ligatures to access the icon glyphs, can you modify the script that generates this font so that it does NOT assign PUA codepoints to the glyphs at all? It should be possible to leave them unencoded (i.e. with no entry in the font's cmap), so that the only way they can be accessed is via the ligature sequence.

I see you're embedding the generated font directly in a CSS file as a data-URL. How's the performance of this approach? It won't be quite as efficient as installing the font in the base OS, because each app that uses it will be instantiating its own separate copy, so there must be a memory and perf cost. But maybe it's good enough?

JK


<blockquote>

----- Original Message -----

From: "Jet Villegas" <j...@mozilla.com>
To: "Wilson Page" <wilso...@mozilla.com>
Cc: "Patryk Adamczyk" <pada...@mozilla.com> , "John Daggett" <jdag...@mozilla.com> , "b2g-internal" <b2g-in...@mozilla.org> , "Cameron McCormack" <hey...@gmail.com> , "Jonathan Watt" <jw...@mozilla.com> , "L. David Baron" <dba...@mozilla.com> , "Jaime Chen" <jac...@mozilla.com> , "Vivien" <vnic...@mozilla.com> , "sicking" <sic...@mozilla.com> , "Robert O'Callahan" <rocal...@mozilla.com> , "Jonathan Kew" <jk...@mozilla.com> , "mozilla.dev.platform group" <dev-pl...@lists.mozilla.org>
Sent: Tuesday, June 17, 2014 12:54:57 AM
Subject: Re: Icon fonts in FxOS

Wilson:

How difficult would it be to have your grunt script add a dlig table to your font?
https://www.microsoft.com/typography/otspec/features_ae.htm#dlig
https://bugzilla.mozilla.org/show_bug.cgi?id=1008458#c22

--Jet

----- Original Message -----
From: "Wilson Page" <wilso...@mozilla.com>

We are using icon-fonts in some of the new web-component based building-blocks examples. I have created a gaia-icons repo so that our components can explicitly depend on these icons. Inside this repo we have all the source SVGs inside `images/`. A grunt task called grunt-webfont converts all these SVGs into a single icon-font. To add new icons, you simple have to drop new SVGs into the `images/` directory.


</blockquote>

</blockquote>

[Anne van Kesteren]

On Tue, Jun 17, 2014 at 1:19 PM, Wilson Page <wilso...@mozilla.com> wrote:
> Maybe I'm late to the party, but I don't know what the PUA issue is?

Code points carry semantics. If you assign meaning to unassigned code
points through fonts, you have created a portability problem. That is,
the font is required to make sense out of the code points. This was a
problem with Emoji until it was standardized by Unicode. It would be
good to avoid doing that again.


--
http://annevankesteren.nl/

[Wilson Page]

If we are using ligatures in our apps, this isn't a problem. If someone wants to remove PUA glyphs, great! But this has no reason to block.

----- Original Message -----

From: "Anne van Kesteren" <ann...@annevk.nl>
To: "Wilson Page" <wilso...@mozilla.com>
Cc: "Jonathan Kew" <jk...@mozilla.com>, "Patryk Adamczyk" <pada...@mozilla.com>, "John Daggett" <jdag...@mozilla.com>, "b2g-internal" <b2g-in...@mozilla.org>, "L. David Baron" <dba...@mozilla.com>, "Jaime Chen" <jac...@mozilla.com>, "Jonathan Watt" <jw...@mozilla.com>, "Jet Villegas" <j...@mozilla.com>, "Cameron McCormack" <hey...@gmail.com>, "Vivien" <vnic...@mozilla.com>, "sicking" <sic...@mozilla.com>, "Robert O'Callahan" <rocal...@mozilla.com>, "mozilla.dev.platform group" <dev-pl...@lists.mozilla.org>
Sent: Tuesday, June 17, 2014 12:26:19 PM
Subject: Re: Icon fonts in FxOS

[Wilson Page]

grunt-webfont is where the magic lives :)

----- Original Message -----

From: "Jonathan Kew" <jk...@mozilla.com>

To: "Wilson Page" <wilso...@mozilla.com>, "Anne van Kesteren" <ann...@annevk.nl>
Cc: "Patryk Adamczyk" <pada...@mozilla.com>, "John Daggett" <jdag...@mozilla.com>, "b2g-internal" <b2g-in...@mozilla.org>, "L. David Baron" <dba...@mozilla.com>, "Jaime Chen" <jac...@mozilla.com>, "Jonathan Watt" <jw...@mozilla.com>, "Jet Villegas" <j...@mozilla.com>, "Cameron McCormack" <hey...@gmail.com>, "Vivien" <vnic...@mozilla.com>, "sicking" <sic...@mozilla.com>, "Robert O'Callahan" <rocal...@mozilla.com>, "mozilla.dev.platform group" <dev-pl...@lists.mozilla.org>
Sent: Tuesday, June 17, 2014 2:22:03 PM
Subject: Re: Icon fonts in FxOS

On 17/6/14 13:17, Wilson Page wrote:



If we are using ligatures in our apps, this isn't a problem. If someone wants to remove PUA glyphs, great! But this has no reason to block.

Right, if we're embedding the font in our apps rather than installing it in the OS, then the PUA codepoints it includes aren't likely to be exposed to the world in general. Still, it'd be cleaner to eliminate them - especially if we expect this may be adopted by other authors as well.

Where is the script that generates this font maintained?

JK


<blockquote>

----- Original Message -----

From: "Anne van Kesteren" <ann...@annevk.nl>
To: "Wilson Page" <wilso...@mozilla.com>
Cc: "Jonathan Kew" <jk...@mozilla.com> , "Patryk Adamczyk" <pada...@mozilla.com> , "John Daggett" <jdag...@mozilla.com> , "b2g-internal" <b2g-in...@mozilla.org> , "L. David Baron" <dba...@mozilla.com> , "Jaime Chen" <jac...@mozilla.com> , "Jonathan Watt" <jw...@mozilla.com> , "Jet Villegas" <j...@mozilla.com> , "Cameron McCormack" <hey...@gmail.com> , "Vivien" <vnic...@mozilla.com> , "sicking" <sic...@mozilla.com> , "Robert O'Callahan" <rocal...@mozilla.com> , "mozilla.dev.platform group" <dev-pl...@lists.mozilla.org>
Sent: Tuesday, June 17, 2014 12:26:19 PM
Subject: Re: Icon fonts in FxOS

On Tue, Jun 17, 2014 at 1:19 PM, Wilson Page <wilso...@mozilla.com> wrote:
> Maybe I'm late to the party, but I don't know what the PUA issue is?

Code points carry semantics. If you assign meaning to unassigned code
points through fonts, you have created a portability problem. That is,
the font is required to make sense out of the code points. This was a
problem with Emoji until it was standardized by Unicode. It would be
good to avoid doing that again.


--
http://annevankesteren.nl/

</blockquote>

[Jonathan Kew]

On 17/6/14 13:17, Wilson Page wrote:
> If we are using ligatures in our apps, this isn't a problem. If
> someone wants to remove PUA glyphs, great! But this has no reason to
> block.

Right, if we're embedding the font in our apps rather than installing it
in the OS, then the PUA codepoints it includes aren't likely to be
exposed to the world in general. Still, it'd be cleaner to eliminate
them - especially if we expect this may be adopted by other authors as well.

Where is the script that generates this font maintained?

JK

>

> ------------------------------------------------------------------------
> *From: *"Anne van Kesteren" <ann...@annevk.nl>
> *To: *"Wilson Page" <wilso...@mozilla.com>
> *Cc: *"Jonathan Kew" <jk...@mozilla.com>, "Patryk Adamczyk"

> <pada...@mozilla.com>, "John Daggett" <jdag...@mozilla.com>,
> "b2g-internal" <b2g-in...@mozilla.org>, "L. David Baron"
> <dba...@mozilla.com>, "Jaime Chen" <jac...@mozilla.com>, "Jonathan
> Watt" <jw...@mozilla.com>, "Jet Villegas" <j...@mozilla.com>, "Cameron
> McCormack" <hey...@gmail.com>, "Vivien" <vnic...@mozilla.com>,
> "sicking" <sic...@mozilla.com>, "Robert O'Callahan"
> <rocal...@mozilla.com>, "mozilla.dev.platform group"
> <dev-pl...@lists.mozilla.org>

> *Sent: *Tuesday, June 17, 2014 12:26:19 PM
> *Subject: *Re: Icon fonts in FxOS

[Jonathan Kew]

On 17/6/14 11:10, Wilson Page wrote:
> The gaia-icons font currently uses ligatures to place icons, see here

> <https://github.com/gaia-components/gaia-icons/blob/master/style.css#L32>.

> The ligature character sequence is derived from the original filename
> of the SVG source file in `images/`.
>
> Is this what you were referring to?

OK, so if you're using ligatures to access the icon glyphs, can you
modify the script that generates this font so that it does NOT assign
PUA codepoints to the glyphs at all? It should be possible to leave them
unencoded (i.e. with no entry in the font's cmap), so that the only way
they can be accessed is via the ligature sequence.

I see you're embedding the generated font directly in a CSS file as a
data-URL. How's the performance of this approach? It won't be quite as
efficient as installing the font in the base OS, because each app that
uses it will be instantiating its own separate copy, so there must be a
memory and perf cost. But maybe it's good enough?

JK

> ------------------------------------------------------------------------
> *From: *"Jet Villegas" <j...@mozilla.com>

> *To: *"Wilson Page" <wilso...@mozilla.com>

> *Cc: *"Patryk Adamczyk" <pada...@mozilla.com>, "John Daggett"

> <jdag...@mozilla.com>, "b2g-internal" <b2g-in...@mozilla.org>,

> "Cameron McCormack" <hey...@gmail.com>, "Jonathan Watt"
> <jw...@mozilla.com>, "L. David Baron" <dba...@mozilla.com>, "Jaime
> Chen" <jac...@mozilla.com>, "Vivien" <vnic...@mozilla.com>, "sicking"

> <sic...@mozilla.com>, "Robert O'Callahan" <rocal...@mozilla.com>,

> "Jonathan Kew" <jk...@mozilla.com>, "mozilla.dev.platform group"
> <dev-pl...@lists.mozilla.org>
> *Sent: *Tuesday, June 17, 2014 12:54:57 AM

> *Subject: *Re: Icon fonts in FxOS
>

> Wilson:
>
> How difficult would it be to have your grunt script add a dlig table
> to your font?
> https://www.microsoft.com/typography/otspec/features_ae.htm#dlig
> https://bugzilla.mozilla.org/show_bug.cgi?id=1008458#c22
>
> --Jet
>

[Jonathan Kew]

On 17/6/14 11:52, Wilson Page wrote:
> I'm inlining to minimise cross-origin issues and to reduce requests.
> The entire asset is <12k so I'm really not concerned with performance
> here, especially considering the number of PNG assets this replaces.
> We've been using a similar approach in Camera for quite some time and
> all has been well. I think there are better areas we can focus
> performance efforts.
>
> I'm not exactly sure if glyphs are still assigned to code points
> within the generated font, is that an issue?
I looked at the embedded font in your CSS file, and it has the icons
encoded at PUA character codes U+E001..E01D. If we could avoid exposing
PUA codes at all, that would be helpful, as it eliminates any risk that
authors actually use (non-portable) PUA codes to render the icons.

AFAIK, it should be possible to do this. In fontforge, the glyphs are
referenced by name; they shouldn't need codepoints assigned.

>

> IMO we should just treat icon assets in the same way we do images
> assets. Baking them into the platform seems like it could cause
> unnecessary complications further down the line, for negligible perf
> gains. At the end of the day we're a collection of web-apps, the more
> we exploit our platform power, the further we distance ourselves from
> the real web platform.

If this works acceptably, can we close bug 951593 (and 1008458) as
WontFix? That'd be awesome, IMO, as none of the proposed strategies
there are really satisfactory. Where are we at w.r.t. the launch
regression that was filed as bug 1002904? Has the data-URL version of
the embedded font been tried there?

One other optimization you might want to consider - especially as the
icon collection grows - is to have your build scripts generate a custom
font subset for each app that's using them, instead of having all the
apps (separately) load the complete set of icons even if they only need
a few. So the original collection of graphics would be a shared
"building block" resource, but the actual CSS that embeds the font would
be individually generated for each app depending on its needs.
(Presumably it'd be simple to scan the app's files and determine exactly
which icons it needs.)

JK

>

> W.
>
> ------------------------------------------------------------------------
> *From: *"Jonathan Kew" <jk...@mozilla.com>
> *To: *"Wilson Page" <wilso...@mozilla.com>, "Jet Villegas"
> <j...@mozilla.com>

> *Cc: *"Patryk Adamczyk" <pada...@mozilla.com>, "John Daggett"
> <jdag...@mozilla.com>, "b2g-internal" <b2g-in...@mozilla.org>,
> "Cameron McCormack" <hey...@gmail.com>, "Jonathan Watt"
> <jw...@mozilla.com>, "L. David Baron" <dba...@mozilla.com>, "Jaime
> Chen" <jac...@mozilla.com>, "Vivien" <vnic...@mozilla.com>, "sicking"
> <sic...@mozilla.com>, "Robert O'Callahan" <rocal...@mozilla.com>,

> "mozilla.dev.platform group" <dev-pl...@lists.mozilla.org>
> *Sent: *Tuesday, June 17, 2014 11:31:18 AM

[Wilson Page]

Following the grunt-webfont readme everything seemed to 'just work' for me (OSX).

----- Original Message -----

From: "Jonathan Kew" <jk...@mozilla.com>
To: "Wilson Page" <wilso...@mozilla.com>

Cc: "Anne van Kesteren" <ann...@annevk.nl>, "Patryk Adamczyk" <pada...@mozilla.com>, "John Daggett" <jdag...@mozilla.com>, "b2g-internal" <b2g-in...@mozilla.org>, "L. David Baron" <dba...@mozilla.com>, "Jaime Chen" <jac...@mozilla.com>, "Jonathan Watt" <jw...@mozilla.com>, "Jet Villegas" <j...@mozilla.com>, "Cameron McCormack" <hey...@gmail.com>, "Vivien" <vnic...@mozilla.com>, "sicking" <sic...@mozilla.com>, "Robert O'Callahan" <rocal...@mozilla.com>, "mozilla.dev.platform group" <dev-pl...@lists.mozilla.org>
Sent: Tuesday, June 17, 2014 4:23:26 PM
Subject: Re: Icon fonts in FxOS

On 17/6/14 14:31, Wilson Page wrote:



grunt-webfont is where the magic lives :)

Hmm. Magic indeed. Omitting the unwanted PUA codepoints would probably be a pretty minor tweak to the fontforge script there. But a brief attempt to get this up and running didn't go well for me, on either OS X (the fontforge python script fails, and homebrew can't seem to give me a new FF installation) or on Linux (npm fails to install grunt, grunt-webfont, etc). :(



<blockquote>

----- Original Message -----

From: "Jonathan Kew" <jk...@mozilla.com>
To: "Wilson Page" <wilso...@mozilla.com> , "Anne van Kesteren" <ann...@annevk.nl>
Cc: "Patryk Adamczyk" <pada...@mozilla.com> , "John Daggett" <jdag...@mozilla.com> , "b2g-internal" <b2g-in...@mozilla.org> , "L. David Baron" <dba...@mozilla.com> , "Jaime Chen" <jac...@mozilla.com> , "Jonathan Watt" <jw...@mozilla.com> , "Jet Villegas" <j...@mozilla.com> , "Cameron McCormack" <hey...@gmail.com> , "Vivien" <vnic...@mozilla.com> , "sicking" <sic...@mozilla.com> , "Robert O'Callahan" <rocal...@mozilla.com> , "mozilla.dev.platform group" <dev-pl...@lists.mozilla.org>
Sent: Tuesday, June 17, 2014 2:22:03 PM

Subject: Re: Icon fonts in FxOS

On 17/6/14 13:17, Wilson Page wrote:

<blockquote>

If we are using ligatures in our apps, this isn't a problem. If someone wants to remove PUA glyphs, great! But this has no reason to block.

</blockquote>

Right, if we're embedding the font in our apps rather than installing it in the OS, then the PUA codepoints it includes aren't likely to be exposed to the world in general. Still, it'd be cleaner to eliminate them - especially if we expect this may be adopted by other authors as well.

Where is the script that generates this font maintained?

JK


<blockquote>

----- Original Message -----

From: "Anne van Kesteren" <ann...@annevk.nl>
To: "Wilson Page" <wilso...@mozilla.com>

Cc: "Jonathan Kew" <jk...@mozilla.com> , "Patryk Adamczyk" <pada...@mozilla.com> , "John Daggett" <jdag...@mozilla.com> , "b2g-internal" <b2g-in...@mozilla.org> , "L. David Baron" <dba...@mozilla.com> , "Jaime Chen" <jac...@mozilla.com> , "Jonathan Watt" <jw...@mozilla.com> , "Jet Villegas" <j...@mozilla.com> , "Cameron McCormack" <hey...@gmail.com> , "Vivien" <vnic...@mozilla.com> , "sicking" <sic...@mozilla.com> , "Robert O'Callahan" <rocal...@mozilla.com> , "mozilla.dev.platform group" <dev-pl...@lists.mozilla.org>
Sent: Tuesday, June 17, 2014 12:26:19 PM
Subject: Re: Icon fonts in FxOS

On Tue, Jun 17, 2014 at 1:19 PM, Wilson Page <wilso...@mozilla.com> wrote:
> Maybe I'm late to the party, but I don't know what the PUA issue is?

Code points carry semantics. If you assign meaning to unassigned code
points through fonts, you have created a portability problem. That is,
the font is required to make sense out of the code points. This was a
problem with Emoji until it was standardized by Unicode. It would be
good to avoid doing that again.


--
http://annevankesteren.nl/

</blockquote>



</blockquote>

[Anthony Ricaud]

On 16/06/14 21:34, Jet Villegas wrote:
> 1. Let people use the icon fonts anywhere. (ie. like "MS WingDings" can be used for this purpose)
> 2. The patch in bug 1008458 introduces "private" fonts that use the Unicode Private Use Area (PUA) for icon glyphs.
> 3. Use PUA characters as per bug 1008458 but disable use of PUA characters in local fonts on all platforms except for FirefoxOS certified apps.
> 4. Use the OpenType discretionary ligatures ("dlig") feature to hide the glyphs ( see https://bugzilla.mozilla.org/show_bug.cgi?id=1008458#c22 )

For 1.4, a 5th option is that we don't use icon fonts. Which apps are
currently using them in 1.4?

[Vivien Nicolas]

Just want to make sure that there is no misunderstanding here: based on
the data from https://bugzilla.mozilla.org/show_bug.cgi?id=948856#c37,
some experience with loading icon fonts versus images versus svg that
has been described on dev-gaia, *preloading the font is needed*.

On 06/17/2014 12:52 PM, Wilson Page wrote:
> I'm inlining to minimise cross-origin issues and to reduce requests.
> The entire asset is <12k so I'm really not concerned with performance
> here, especially considering the number of PNG assets this replaces.
> We've been using a similar approach in Camera for quite some time and
> all has been well. I think there are better areas we can focus
> performance efforts.

Performance is not always related to the size of the asset. For example
last time I found that we consume 2.4mb of memory all the time in the
System app because we were loading 4 times an image asset of 3k. Every
time this asset was rendered it was consuming 600k of memory. This asset
was a gradient and it was expensive to render it.

When you consider the size of the asset in this case, you should also
consider at which time it is read, if is it going to trigger some
invalidations because the image will arrive after the app is rendered,
how long will it take for the font subsystem to render those glyphs, can
we save some memory by using some system features, instead of having a
local copy in all apps, etc...

> I'm not exactly sure if glyphs are still assigned to code points
> within the generated font, is that an issue?
>

> IMO we should just treat icon assets in the same way we do images assets.

Image assets may be slow. We run into this issue multiple times in the
Settings app. Replacing our current image assets icons with an icon font
baked into the platform shave ~300ms of load time.

> Baking them into the platform seems like it could cause unnecessary
> complications further down the line, for negligible perf gains.

Obviously 300ms is not negligible :)

Also in terms of memory there is an impact too, and since we're
targeting very low end devices, I expect this to be useful too.
The current mechanism used by Gecko to discard images help us to reduce
the memory overhead here for background apps, but it has the side effect
that the image needs to be re-decoded when the app goes to foreground
and it takes time (you see images flashes when the images are re-decoded
/ repainted).

So icon font would make some apps to load faster, consume less memory,
and avoid some glitches when the app goes from background to foreground.
Definitively not negligible.

> At the end of the day we're a collection of web-apps, the more we
> exploit our platform power, the further we distance ourselves from the
> real web platform.
>

What you say here is true. And we would all like to use only simple web
features, and that's definitively the goal.
But while we are heading up to this goal, we sometimes needs to do some
trade-offs, and using icon fonts is one of them. It does not mean there
is more distance from the real web platform, as I believe that while
Gaia use icon fonts, a lot of efforts will be done on the svg side in
order to replace the icon font with SVG when it will be time to do so.

So you should see that as: it makes us more competitive in this
extremely competitive area, and offers us a bit more time to fix the
real issue, which is that SVG does not fit yet, and beside that, to fix
the web platform to make it becomes reals on mobile.

Vivien.

> W.
>
> ------------------------------------------------------------------------
> *From: *"Jonathan Kew" <jk...@mozilla.com>
> *To: *"Wilson Page" <wilso...@mozilla.com>, "Jet Villegas"
> <j...@mozilla.com>

> *Cc: *"Patryk Adamczyk" <pada...@mozilla.com>, "John Daggett"

> <jdag...@mozilla.com>, "b2g-internal" <b2g-in...@mozilla.org>,

> "Cameron McCormack" <hey...@gmail.com>, "Jonathan Watt"
> <jw...@mozilla.com>, "L. David Baron" <dba...@mozilla.com>, "Jaime
> Chen" <jac...@mozilla.com>, "Vivien" <vnic...@mozilla.com>, "sicking"

> <sic...@mozilla.com>, "Robert O'Callahan" <rocal...@mozilla.com>,
> "mozilla.dev.platform group" <dev-pl...@lists.mozilla.org>

> *Sent: *Tuesday, June 17, 2014 11:31:18 AM
> *Subject: *Re: Icon fonts in FxOS
>
> On 17/6/14 11:10, Wilson Page wrote:
>
> The gaia-icons font currently uses ligatures to place icons, see
> here
> <https://github.com/gaia-components/gaia-icons/blob/master/style.css#L32>.
> The ligature character sequence is derived from the original
> filename of the SVG source file in `images/`.
>
> Is this what you were referring to?
>
>
> OK, so if you're using ligatures to access the icon glyphs, can you
> modify the script that generates this font so that it does NOT assign
> PUA codepoints to the glyphs at all? It should be possible to leave
> them unencoded (i.e. with no entry in the font's cmap), so that the
> only way they can be accessed is via the ligature sequence.
>
> I see you're embedding the generated font directly in a CSS file as a
> data-URL. How's the performance of this approach? It won't be quite as
> efficient as installing the font in the base OS, because each app that
> uses it will be instantiating its own separate copy, so there must be
> a memory and perf cost. But maybe it's good enough?
>
> JK
>
> ------------------------------------------------------------------------
> *From: *"Jet Villegas" <j...@mozilla.com>
> *To: *"Wilson Page" <wilso...@mozilla.com>

> *Cc: *"Patryk Adamczyk" <pada...@mozilla.com>, "John Daggett"

> <jdag...@mozilla.com>, "b2g-internal" <b2g-in...@mozilla.org>,

> "Cameron McCormack" <hey...@gmail.com>, "Jonathan Watt"
> <jw...@mozilla.com>, "L. David Baron" <dba...@mozilla.com>, "Jaime
> Chen" <jac...@mozilla.com>, "Vivien" <vnic...@mozilla.com>,

> "sicking" <sic...@mozilla.com>, "Robert O'Callahan"

> <rocal...@mozilla.com>, "Jonathan Kew" <jk...@mozilla.com>,
> "mozilla.dev.platform group" <dev-pl...@lists.mozilla.org>
> *Sent: *Tuesday, June 17, 2014 12:54:57 AM
> *Subject: *Re: Icon fonts in FxOS
>
> Wilson:
>
> How difficult would it be to have your grunt script add a dlig
> table to your font?
> https://www.microsoft.com/typography/otspec/features_ae.htm#dlig
> https://bugzilla.mozilla.org/show_bug.cgi?id=1008458#c22
>
> --Jet
>

[Vivien Nicolas]

On 06/16/2014 09:34 PM, Jet Villegas wrote:
> Hi All:
>
> We need a path forward on the deployment of Icon fonts in FxOS. The Gaia team understandably wants to squeeze every bit of performance on their apps in v1.4:
> https://bugzilla.mozilla.org/show_bug.cgi?id=951593
>
> We are concerned about leaking these fonts into Open Web content, so we want to restrict it to certified Gaia apps:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1008458
>
> The approach we take to restrict icon fonts to certified Gaia apps is under some debate, and we've got 4 possibilities:
>

> 1. Let people use the icon fonts anywhere. (ie. like "MS WingDings" can be used for this purpose)
> 2. The patch in bug 1008458 introduces "private" fonts that use the Unicode Private Use Area (PUA) for icon glyphs.
> 3. Use PUA characters as per bug 1008458 but disable use of PUA characters in local fonts on all platforms except for FirefoxOS certified apps.
> 4. Use the OpenType discretionary ligatures ("dlig") feature to hide the glyphs ( see https://bugzilla.mozilla.org/show_bug.cgi?id=1008458#c22 )
>

> I'm afraid of the amount of code in the patch for bug 1008458 for the 1.4 release, so I'm inclined to let the Gaia team use the icon font as-is (option 1) with the promise that they won't use it in uncertified non-system apps.
>

> I also propose that we make any required code changes in v2.0 so that non-certified apps can't get unrestricted use of the font. All the options proposed (#2,3, or 4,) have drawbacks, the common one being that they may be overly restrictive.
>

> I'd like some feedback here, first on my proposal that we go with Option 1 for 1.4. Second, I'd like us to solve the font leakage problem for 2.0 with one of the 3 other proposals, if still needed--I'd like to see how far we get to improve SVG performance (bug 999931) to make all this a moot point. I really am not a fan of icon fonts (see https://twitter.com/73inches/status/468368206282113024/photo/1 )

Ideally we would like to use SVG instead of Icon Fonts in Gaia for many
use cases. But I believe the SVG performance won't be as good an Icon
Font baked into the platform in the 2.1 timeframe.

3 seems agressive. PUA has always worked on the web AFAIK and it's
unclear to me why we want to changed this.
4 seems like an obfuscation mechanism, which is smart, but won't prevent
what 2 and 3 try to prevent, which is leaking our glyphs on the web.

I'm not saying I like 2 - it always sad when we have to do a
certified-only hack - but it seems the cleaner approach as it draw a
clear line between regular and this "private" font without regressing
things that already works, or trying to hide the feature even if it works.

Then once SVG would be good enough, yes I believe we will use it.

Vivien.

>
> Thanks,
>
> --Jet

[Wilson Page]

Just to clarify: I am in favor of icon-fonts, but less baking them into the system. Do we have perf figures comparing normal @font-face loading (external or inlined) compared to the baked in solution?

----- Original Message -----

From: "Vivien Nicolas" <vnic...@mozilla.com>
To: "Wilson Page" <wilso...@mozilla.com>, "Jonathan Kew" <jk...@mozilla.com>
Cc: "Jet Villegas" <j...@mozilla.com>, "Patryk Adamczyk" <pada...@mozilla.com>, "John Daggett" <jdag...@mozilla.com>, "b2g-internal" <b2g-in...@mozilla.org>, "Cameron McCormack" <hey...@gmail.com>, "Jonathan Watt" <jw...@mozilla.com>, "L. David Baron" <dba...@mozilla.com>, "Jaime Chen" <jac...@mozilla.com>, "sicking" <sic...@mozilla.com>, "Robert O'Callahan" <rocal...@mozilla.com>, "mozilla.dev.platform group" <dev-pl...@lists.mozilla.org>
Sent: Tuesday, June 17, 2014 4:48:19 PM
Subject: Re: Icon fonts in FxOS

Just want to make sure that there is no misunderstanding here: based on the data from https://bugzilla.mozilla.org/show_bug.cgi?id=948856#c37 , some experience with loading icon fonts versus images versus svg that has been described on dev-gaia, *preloading the font is needed*.

On 06/17/2014 12:52 PM, Wilson Page wrote:



I'm inlining to minimise cross-origin issues and to reduce requests. The entire asset is <12k so I'm really not concerned with performance here, especially considering the number of PNG assets this replaces. We've been using a similar approach in Camera for quite some time and all has been well. I think there are better areas we can focus performance efforts.



Performance is not always related to the size of the asset. For example last time I found that we consume 2.4mb of memory all the time in the System app because we were loading 4 times an image asset of 3k. Every time this asset was rendered it was consuming 600k of memory. This asset was a gradient and it was expensive to render it.

When you consider the size of the asset in this case, you should also consider at which time it is read, if is it going to trigger some invalidations because the image will arrive after the app is rendered, how long will it take for the font subsystem to render those glyphs, can we save some memory by using some system features, instead of having a local copy in all apps, etc...

<blockquote>

I'm not exactly sure if glyphs are still assigned to code points within the generated font, is that an issue?

IMO we should just treat icon assets in the same way we do images assets.

</blockquote>

Image assets may be slow. We run into this issue multiple times in the Settings app. Replacing our current image assets icons with an icon font baked into the platform shave ~300ms of load time.

<blockquote>

Baking them into the platform seems like it could cause unnecessary complications further down the line, for negligible perf gains.

</blockquote>

Obviously 300ms is not negligible :)

Also in terms of memory there is an impact too, and since we're targeting very low end devices, I expect this to be useful too.
The current mechanism used by Gecko to discard images help us to reduce the memory overhead here for background apps, but it has the side effect that the image needs to be re-decoded when the app goes to foreground and it takes time (you see images flashes when the images are re-decoded / repainted).

So icon font would make some apps to load faster, consume less memory, and avoid some glitches when the app goes from background to foreground. Definitively not negligible.

<blockquote>

At the end of the day we're a collection of web-apps, the more we exploit our platform power, the further we distance ourselves from the real web platform.

</blockquote>

What you say here is true. And we would all like to use only simple web features, and that's definitively the goal.
But while we are heading up to this goal, we sometimes needs to do some trade-offs, and using icon fonts is one of them. It does not mean there is more distance from the real web platform, as I believe that while Gaia use icon fonts, a lot of efforts will be done on the svg side in order to replace the icon font with SVG when it will be time to do so.

So you should see that as: it makes us more competitive in this extremely competitive area, and offers us a bit more time to fix the real issue, which is that SVG does not fit yet, and beside that, to fix the web platform to make it becomes reals on mobile.

Vivien.

<blockquote>

W.

----- Original Message -----

From: "Jonathan Kew" <jk...@mozilla.com>
To: "Wilson Page" <wilso...@mozilla.com> , "Jet Villegas" <j...@mozilla.com>
Cc: "Patryk Adamczyk" <pada...@mozilla.com> , "John Daggett" <jdag...@mozilla.com> , "b2g-internal" <b2g-in...@mozilla.org> , "Cameron McCormack" <hey...@gmail.com> , "Jonathan Watt" <jw...@mozilla.com> , "L. David Baron" <dba...@mozilla.com> , "Jaime Chen" <jac...@mozilla.com> , "Vivien" <vnic...@mozilla.com> , "sicking" <sic...@mozilla.com> , "Robert O'Callahan" <rocal...@mozilla.com> , "mozilla.dev.platform group" <dev-pl...@lists.mozilla.org>
Sent: Tuesday, June 17, 2014 11:31:18 AM
Subject: Re: Icon fonts in FxOS

On 17/6/14 11:10, Wilson Page wrote:

<blockquote>

The gaia-icons font currently uses ligatures to place icons, see here . The ligature character sequence is derived from the original filename of the SVG source file in `images/`.

Is this what you were referring to?

</blockquote>

OK, so if you're using ligatures to access the icon glyphs, can you modify the script that generates this font so that it does NOT assign PUA codepoints to the glyphs at all? It should be possible to leave them unencoded (i.e. with no entry in the font's cmap), so that the only way they can be accessed is via the ligature sequence.

I see you're embedding the generated font directly in a CSS file as a data-URL. How's the performance of this approach? It won't be quite as efficient as installing the font in the base OS, because each app that uses it will be instantiating its own separate copy, so there must be a memory and perf cost. But maybe it's good enough?

JK

<blockquote>

----- Original Message -----

From: "Jet Villegas" <j...@mozilla.com>
To: "Wilson Page" <wilso...@mozilla.com>

Cc: "Patryk Adamczyk" <pada...@mozilla.com> , "John Daggett" <jdag...@mozilla.com> , "b2g-internal" <b2g-in...@mozilla.org> , "Cameron McCormack" <hey...@gmail.com> , "Jonathan Watt" <jw...@mozilla.com> , "L. David Baron" <dba...@mozilla.com> , "Jaime Chen" <jac...@mozilla.com> , "Vivien" <vnic...@mozilla.com> , "sicking" <sic...@mozilla.com> , "Robert O'Callahan" <rocal...@mozilla.com> , "Jonathan Kew" <jk...@mozilla.com> , "mozilla.dev.platform group" <dev-pl...@lists.mozilla.org>
Sent: Tuesday, June 17, 2014 12:54:57 AM
Subject: Re: Icon fonts in FxOS

Wilson:

How difficult would it be to have your grunt script add a dlig table to your font?
https://www.microsoft.com/typography/otspec/features_ae.htm#dlig
https://bugzilla.mozilla.org/show_bug.cgi?id=1008458#c22

--Jet

----- Original Message -----
From: "Wilson Page" <wilso...@mozilla.com>

We are using icon-fonts in some of the new web-component based building-blocks examples. I have created a gaia-icons repo so that our components can explicitly depend on these icons. Inside this repo we have all the source SVGs inside `images/`. A grunt task called grunt-webfont converts all these SVGs into a single icon-font. To add new icons, you simple have to drop new SVGs into the `images/` directory.

</blockquote>



</blockquote>

[Vivien Nicolas]

On 06/17/2014 06:01 PM, Wilson Page wrote:
> Just to clarify: I am in favor of icon-fonts, but less baking them
> into the system. Do we have perf figures comparing normal @font-face
> loading (external or inlined) compared to the baked in solution?

Yeah, looked at comment 37 of bug 948856. Between not baking it, and
baking it, there is a 500ms diff :/

>
> ------------------------------------------------------------------------
> *From: *"Vivien Nicolas" <vnic...@mozilla.com>
> *To: *"Wilson Page" <wilso...@mozilla.com>, "Jonathan Kew"
> <jk...@mozilla.com>
> *Cc: *"Jet Villegas" <j...@mozilla.com>, "Patryk Adamczyk"

> <pada...@mozilla.com>, "John Daggett" <jdag...@mozilla.com>,
> "b2g-internal" <b2g-in...@mozilla.org>, "Cameron McCormack"
> <hey...@gmail.com>, "Jonathan Watt" <jw...@mozilla.com>, "L. David
> Baron" <dba...@mozilla.com>, "Jaime Chen" <jac...@mozilla.com>,
> "sicking" <sic...@mozilla.com>, "Robert O'Callahan"
> <rocal...@mozilla.com>, "mozilla.dev.platform group"
> <dev-pl...@lists.mozilla.org>

> *Sent: *Tuesday, June 17, 2014 4:48:19 PM
> *Subject: *Re: Icon fonts in FxOS

>
> Just want to make sure that there is no misunderstanding here: based
> on the data from

> https://bugzilla.mozilla.org/show_bug.cgi?id=948856#c37, some

> experience with loading icon fonts versus images versus svg that has
> been described on dev-gaia, *preloading the font is needed*.
>
> On 06/17/2014 12:52 PM, Wilson Page wrote:
>
> I'm inlining to minimise cross-origin issues and to reduce
> requests. The entire asset is <12k so I'm really not concerned
> with performance here, especially considering the number of PNG
> assets this replaces. We've been using a similar approach in
> Camera for quite some time and all has been well. I think there
> are better areas we can focus performance efforts.
>
>
> Performance is not always related to the size of the asset. For
> example last time I found that we consume 2.4mb of memory all the time
> in the System app because we were loading 4 times an image asset of
> 3k. Every time this asset was rendered it was consuming 600k of
> memory. This asset was a gradient and it was expensive to render it.
>
> When you consider the size of the asset in this case, you should also
> consider at which time it is read, if is it going to trigger some
> invalidations because the image will arrive after the app is rendered,
> how long will it take for the font subsystem to render those glyphs,
> can we save some memory by using some system features, instead of
> having a local copy in all apps, etc...
>

> I'm not exactly sure if glyphs are still assigned to code points
> within the generated font, is that an issue?
>
> IMO we should just treat icon assets in the same way we do images
> assets.
>
>

> Image assets may be slow. We run into this issue multiple times in the
> Settings app. Replacing our current image assets icons with an icon
> font baked into the platform shave ~300ms of load time.
>

> Baking them into the platform seems like it could cause
> unnecessary complications further down the line, for negligible
> perf gains.
>
>

> Obviously 300ms is not negligible :)
>
> Also in terms of memory there is an impact too, and since we're
> targeting very low end devices, I expect this to be useful too.
> The current mechanism used by Gecko to discard images help us to
> reduce the memory overhead here for background apps, but it has the
> side effect that the image needs to be re-decoded when the app goes to
> foreground and it takes time (you see images flashes when the images
> are re-decoded / repainted).
>
> So icon font would make some apps to load faster, consume less memory,
> and avoid some glitches when the app goes from background to
> foreground. Definitively not negligible.
>

> At the end of the day we're a collection of web-apps, the more we
> exploit our platform power, the further we distance ourselves from
> the real web platform.
>
>

> What you say here is true. And we would all like to use only simple
> web features, and that's definitively the goal.
> But while we are heading up to this goal, we sometimes needs to do
> some trade-offs, and using icon fonts is one of them. It does not mean
> there is more distance from the real web platform, as I believe that
> while Gaia use icon fonts, a lot of efforts will be done on the svg
> side in order to replace the icon font with SVG when it will be time
> to do so.
>
> So you should see that as: it makes us more competitive in this
> extremely competitive area, and offers us a bit more time to fix the
> real issue, which is that SVG does not fit yet, and beside that, to
> fix the web platform to make it becomes reals on mobile.
>
> Vivien.
>

> W.
>
> ------------------------------------------------------------------------
> *From: *"Jonathan Kew" <jk...@mozilla.com>

> *To: *"Wilson Page" <wilso...@mozilla.com>, "Jet Villegas"
> <j...@mozilla.com>
> *Cc: *"Patryk Adamczyk" <pada...@mozilla.com>, "John Daggett"

> <jdag...@mozilla.com>, "b2g-internal" <b2g-in...@mozilla.org>,
> "Cameron McCormack" <hey...@gmail.com>, "Jonathan Watt"
> <jw...@mozilla.com>, "L. David Baron" <dba...@mozilla.com>, "Jaime
> Chen" <jac...@mozilla.com>, "Vivien" <vnic...@mozilla.com>,
> "sicking" <sic...@mozilla.com>, "Robert O'Callahan"
> <rocal...@mozilla.com>, "mozilla.dev.platform group"
> <dev-pl...@lists.mozilla.org>

> *Sent: *Tuesday, June 17, 2014 11:31:18 AM
> *Subject: *Re: Icon fonts in FxOS

>
> On 17/6/14 11:10, Wilson Page wrote:
>
> The gaia-icons font currently uses ligatures to place icons,
> see here

> <https://github.com/gaia-components/gaia-icons/blob/master/style.css#L32>.

> The ligature character sequence is derived from the original
> filename of the SVG source file in `images/`.
>
> Is this what you were referring to?
>
>

> OK, so if you're using ligatures to access the icon glyphs, can
> you modify the script that generates this font so that it does NOT
> assign PUA codepoints to the glyphs at all? It should be possible
> to leave them unencoded (i.e. with no entry in the font's cmap),
> so that the only way they can be accessed is via the ligature
> sequence.
>
> I see you're embedding the generated font directly in a CSS file
> as a data-URL. How's the performance of this approach? It won't be
> quite as efficient as installing the font in the base OS, because
> each app that uses it will be instantiating its own separate copy,
> so there must be a memory and perf cost. But maybe it's good enough?
>
> JK
>

> ------------------------------------------------------------------------
> *From: *"Jet Villegas" <j...@mozilla.com>
> *To: *"Wilson Page" <wilso...@mozilla.com>

> *Cc: *"Patryk Adamczyk" <pada...@mozilla.com>, "John

> Daggett" <jdag...@mozilla.com>, "b2g-internal"
> <b2g-in...@mozilla.org>, "Cameron McCormack"
> <hey...@gmail.com>, "Jonathan Watt" <jw...@mozilla.com>, "L.
> David Baron" <dba...@mozilla.com>, "Jaime Chen"
> <jac...@mozilla.com>, "Vivien" <vnic...@mozilla.com>,
> "sicking" <sic...@mozilla.com>, "Robert O'Callahan"
> <rocal...@mozilla.com>, "Jonathan Kew" <jk...@mozilla.com>,
> "mozilla.dev.platform group" <dev-pl...@lists.mozilla.org>

> *Sent: *Tuesday, June 17, 2014 12:54:57 AM
> *Subject: *Re: Icon fonts in FxOS

[Jonathan Kew]

On 17/6/14 14:31, Wilson Page wrote:

> grunt-webfont <https://github.com/sapegin/grunt-webfont> is where the

> magic lives :)
>

Hmm. Magic indeed. Omitting the unwanted PUA codepoints would probably
be a pretty minor tweak to the fontforge script there. But a brief
attempt to get this up and running didn't go well for me, on either OS X
(the fontforge python script fails, and homebrew can't seem to give me a
new FF installation) or on Linux (npm fails to install grunt,
grunt-webfont, etc). :(

> ------------------------------------------------------------------------
> *From: *"Jonathan Kew" <jk...@mozilla.com>

> *To: *"Wilson Page" <wilso...@mozilla.com>, "Anne van Kesteren"
> <ann...@annevk.nl>

> *Cc: *"Patryk Adamczyk" <pada...@mozilla.com>, "John Daggett"

> <jdag...@mozilla.com>, "b2g-internal" <b2g-in...@mozilla.org>, "L.

> David Baron" <dba...@mozilla.com>, "Jaime Chen" <jac...@mozilla.com>,

> "Jonathan Watt" <jw...@mozilla.com>, "Jet Villegas" <j...@mozilla.com>,
> "Cameron McCormack" <hey...@gmail.com>, "Vivien"

> <vnic...@mozilla.com>, "sicking" <sic...@mozilla.com>, "Robert
> O'Callahan" <rocal...@mozilla.com>, "mozilla.dev.platform group"
> <dev-pl...@lists.mozilla.org>

> *Sent: *Tuesday, June 17, 2014 2:22:03 PM

> *Subject: *Re: Icon fonts in FxOS
>

> On 17/6/14 13:17, Wilson Page wrote:
>
> If we are using ligatures in our apps, this isn't a problem. If
> someone wants to remove PUA glyphs, great! But this has no reason
> to block.
>
>

> Right, if we're embedding the font in our apps rather than installing
> it in the OS, then the PUA codepoints it includes aren't likely to be
> exposed to the world in general. Still, it'd be cleaner to eliminate
> them - especially if we expect this may be adopted by other authors as
> well.
>

> Where is the script that generates this font maintained?
>
> JK
>
>
> ------------------------------------------------------------------------
> *From: *"Anne van Kesteren" <ann...@annevk.nl>

> *To: *"Wilson Page" <wilso...@mozilla.com>

> *Cc: *"Jonathan Kew" <jk...@mozilla.com>, "Patryk Adamczyk"

> <pada...@mozilla.com>, "John Daggett" <jdag...@mozilla.com>,

> "b2g-internal" <b2g-in...@mozilla.org>, "L. David Baron"
> <dba...@mozilla.com>, "Jaime Chen" <jac...@mozilla.com>, "Jonathan

> Watt" <jw...@mozilla.com>, "Jet Villegas" <j...@mozilla.com>,
> "Cameron McCormack" <hey...@gmail.com>, "Vivien"

> <vnic...@mozilla.com>, "sicking" <sic...@mozilla.com>, "Robert
> O'Callahan" <rocal...@mozilla.com>, "mozilla.dev.platform group"
> <dev-pl...@lists.mozilla.org>

> *Sent: *Tuesday, June 17, 2014 12:26:19 PM

> *Subject: *Re: Icon fonts in FxOS
>

[Jonathan Kew]

On 17/6/14 17:02, Vivien Nicolas wrote:
>
> On 06/17/2014 06:01 PM, Wilson Page wrote:
>> Just to clarify: I am in favor of icon-fonts, but less baking them
>> into the system. Do we have perf figures comparing normal @font-face
>> loading (external or inlined) compared to the baked in solution?
>
> Yeah, looked at comment 37 of bug 948856. Between not baking it, and
> baking it, there is a 500ms diff :/

If I'm reading bug 948856 correctly, the difference may have been
somewhat less (150ms? comment 17) when the font was inlined in the CSS
using a data URI, rather than loaded from a separate file.

If we can't afford that, then we still need some other solution here.

But jburke said that we're generally "downgrading" apps from certified
to privileged as much as possible. If the system-installed icon font
were available only to certified apps, would this adequately address the
issue? Any Gaia apps that go from certified to privileged would need to
adopt a separate (lower-perf) approach at that point.

This could be solved by roc's suggestion of providing the font through
@font-face with a public mozilla URL, which the platform then recognizes
and special-cases to use a locally preinstalled copy instead, but I'm
not really comfortable with making all this dependent on a public URL
(which we're then obligated to maintain forever, so as not to break
other people's apps that may start to depend on it). I'd prefer a
solution that is purely an internal optimization in the FxOS device, and
not exposed to the Web at all.

For certified apps, we could do that; but if it needs to be available to
non-certified Gaia apps as well, it's less clear how we can handle this.
We could extend use of the "private" font to privileged as well as
certified apps, but does that make it too "public" to be healthy? It
still wouldn't be leaking to the general Web, but we might find that a
lot of 3rd-party apps start to depend on it, and thus risk breaking any
time we want to revise it for Gaia (or switch Gaia to some completely
different solution such as SVG images).

JK

>
>>
>> ------------------------------------------------------------------------
>> *From: *"Vivien Nicolas" <vnic...@mozilla.com>
>> *To: *"Wilson Page" <wilso...@mozilla.com>, "Jonathan Kew"
>> <jk...@mozilla.com>

>> *Cc: *"Jet Villegas" <j...@mozilla.com>, "Patryk Adamczyk"

>> <pada...@mozilla.com>, "John Daggett" <jdag...@mozilla.com>,

>> "b2g-internal" <b2g-in...@mozilla.org>, "Cameron McCormack"
>> <hey...@gmail.com>, "Jonathan Watt" <jw...@mozilla.com>, "L. David

>> Baron" <dba...@mozilla.com>, "Jaime Chen" <jac...@mozilla.com>,

>> "sicking" <sic...@mozilla.com>, "Robert O'Callahan"
>> <rocal...@mozilla.com>, "mozilla.dev.platform group"
>> <dev-pl...@lists.mozilla.org>

>> *Sent: *Tuesday, June 17, 2014 4:48:19 PM

>> *Subject: *Re: Icon fonts in FxOS
>>

>> ------------------------------------------------------------------------
>> *From: *"Jonathan Kew" <jk...@mozilla.com>

>> *To: *"Wilson Page" <wilso...@mozilla.com>, "Jet Villegas"
>> <j...@mozilla.com>

>> *Cc: *"Patryk Adamczyk" <pada...@mozilla.com>, "John Daggett"
>> <jdag...@mozilla.com>, "b2g-internal"

>> <b2g-in...@mozilla.org>, "Cameron McCormack"
>> <hey...@gmail.com>, "Jonathan Watt" <jw...@mozilla.com>, "L.

>> David Baron" <dba...@mozilla.com>, "Jaime Chen"

>> <jac...@mozilla.com>, "Vivien" <vnic...@mozilla.com>, "sicking"

>> <sic...@mozilla.com>, "Robert O'Callahan"
>> <rocal...@mozilla.com>, "mozilla.dev.platform group"
>> <dev-pl...@lists.mozilla.org>

>> *Sent: *Tuesday, June 17, 2014 11:31:18 AM

>> *Subject: *Re: Icon fonts in FxOS
>>

>> On 17/6/14 11:10, Wilson Page wrote:
>>
>> The gaia-icons font currently uses ligatures to place icons,
>> see here
>> <https://github.com/gaia-components/gaia-icons/blob/master/style.css#L32>.
>> The ligature character sequence is derived from the original
>> filename of the SVG source file in `images/`.
>>
>> Is this what you were referring to?
>>
>>
>> OK, so if you're using ligatures to access the icon glyphs, can
>> you modify the script that generates this font so that it does
>> NOT assign PUA codepoints to the glyphs at all? It should be
>> possible to leave them unencoded (i.e. with no entry in the
>> font's cmap), so that the only way they can be accessed is via
>> the ligature sequence.
>>
>> I see you're embedding the generated font directly in a CSS file
>> as a data-URL. How's the performance of this approach? It won't
>> be quite as efficient as installing the font in the base OS,
>> because each app that uses it will be instantiating its own
>> separate copy, so there must be a memory and perf cost. But maybe
>> it's good enough?
>>
>> JK
>>
>> ------------------------------------------------------------------------
>> *From: *"Jet Villegas" <j...@mozilla.com>

>> *To: *"Wilson Page" <wilso...@mozilla.com>

>> *Cc: *"Patryk Adamczyk" <pada...@mozilla.com>, "John
>> Daggett" <jdag...@mozilla.com>, "b2g-internal"

>> <b2g-in...@mozilla.org>, "Cameron McCormack"
>> <hey...@gmail.com>, "Jonathan Watt" <jw...@mozilla.com>, "L.

>> David Baron" <dba...@mozilla.com>, "Jaime Chen"

>> <jac...@mozilla.com>, "Vivien" <vnic...@mozilla.com>,

>> "sicking" <sic...@mozilla.com>, "Robert O'Callahan"

>> <rocal...@mozilla.com>, "Jonathan Kew" <jk...@mozilla.com>,
>> "mozilla.dev.platform group" <dev-pl...@lists.mozilla.org>
>> *Sent: *Tuesday, June 17, 2014 12:54:57 AM

>> *Subject: *Re: Icon fonts in FxOS
>>

[Vivien Nicolas]

On 06/17/2014 06:51 PM, Jonathan Kew wrote:
> On 17/6/14 17:02, Vivien Nicolas wrote:
>>
>> On 06/17/2014 06:01 PM, Wilson Page wrote:
>>> Just to clarify: I am in favor of icon-fonts, but less baking them
>>> into the system. Do we have perf figures comparing normal @font-face
>>> loading (external or inlined) compared to the baked in solution?
>>
>> Yeah, looked at comment 37 of bug 948856. Between not baking it, and
>> baking it, there is a 500ms diff :/
>
> If I'm reading bug 948856 correctly, the difference may have been
> somewhat less (150ms? comment 17) when the font was inlined in the CSS
> using a data URI, rather than loaded from a separate file.

The 150ms is going from gif -> icon font if I read correctly too. And
moving it into moztt was 10 ms better.

It seems somewhat different than what is state in comment 37, which says:

3- Replacing gif with icon font with the font in shared/style (median: 1595)
4- Replacing gif with icon font with the font in system/fonts (median: 1010)


It worth double checking the time here.

>
> If we can't afford that, then we still need some other solution here.
>
> But jburke said that we're generally "downgrading" apps from certified
> to privileged as much as possible. If the system-installed icon font
> were available only to certified apps, would this adequately address
> the issue? Any Gaia apps that go from certified to privileged would
> need to adopt a separate (lower-perf) approach at that point.
>

That's true. Actually there are many other hacks that depends on the
fact that application are certified. So even if I would like to have
more apps as privileged apps just for the principle, it's not that
simple. And we may need to reconsider the |privileged| status of the
email app based on some of the use case on some low end devices for now.

So one of the only reason the email app has been made |privileged| is
for some CSP compliance things, and because it does not needs APIs that
are certified-only. But we may need to keep it certified for perf
reasons if needed. It will depends on the impact of icon font there.

> This could be solved by roc's suggestion of providing the font through
> @font-face with a public mozilla URL, which the platform then
> recognizes and special-cases to use a locally preinstalled copy
> instead, but I'm not really comfortable with making all this dependent
> on a public URL (which we're then obligated to maintain forever, so as
> not to break other people's apps that may start to depend on it). I'd
> prefer a solution that is purely an internal optimization in the FxOS
> device, and not exposed to the Web at all.
>
> For certified apps, we could do that; but if it needs to be available
> to non-certified Gaia apps as well, it's less clear how we can handle
> this. We could extend use of the "private" font to privileged as well
> as certified apps, but does that make it too "public" to be healthy?
> It still wouldn't be leaking to the general Web, but we might find
> that a lot of 3rd-party apps start to depend on it, and thus risk
> breaking any time we want to revise it for Gaia (or switch Gaia to
> some completely different solution such as SVG images).
>

For the moment, I think we should just consider |certified| app.

[James Burke]

On 6/17/14, 10:08 AM, Vivien Nicolas wrote:
> That's true. Actually there are many other hacks that depends on the
> fact that application are certified. So even if I would like to have
> more apps as privileged apps just for the principle, it's not that
> simple. And we may need to reconsider the |privileged| status of the
> email app based on some of the use case on some low end devices for now.
>
> So one of the only reason the email app has been made |privileged| is
> for some CSP compliance things, and because it does not needs APIs
> that are certified-only. But we may need to keep it certified for perf
> reasons if needed. It will depends on the impact of icon font there.

I appreciate there are always tradeoffs, but I also want to caution
against just proceeding because there is an escape value via certified.
We have a train model, and if it takes another train to avoid
certified-only, all apps benefit. It is already disconcerting that just
switching the type value in the manifest from certified to privileged,
we see a 20ms slowdown[1].

The greater concern is these certified escapes build up, and then taking
the time to undo them later eats into the next certified escape that is
wanted, so the gap will continue to grow. A good way to start fighting
the issue is to stop adding to the pile.

On icon fonts, it would be good to make sure there implemented with
accessibility in mind. This document[1] talks about that, and mentions a
Firefox bug[2] about aria-hidden that may need some attention if icon
fonts are used in buttons.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1024005
[2] http://filamentgroup.com/lab/bulletproof_icon_fonts.html
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=948540

James

[Robert O'Callahan]

On Wed, Jun 18, 2014 at 4:51 AM, Jonathan Kew <jk...@mozilla.com> wrote:

> If I'm reading bug 948856 correctly, the difference may have been somewhat
> less (150ms? comment 17) when the font was inlined in the CSS using a data
> URI, rather than loaded from a separate file
>

> If we can't afford that, then we still need some other solution here.
>

Maybe we should investigate that 150ms performance difference further, and
try to reduce it?

Seems to me it wouldn't be hard to build a toy page that uses some fonts
with embedded data: URIs, measure its load performance, and identify chunks
of the profile related to font loading/rendering. AFAIK no-one's really
tried to optimize this case and there's probably some low-hanging fruit.

Jonathan, B2G doesn't share user font instances across apps (assuming 1 app
per process) in any way, right? And it doesn't share rasterized glyphs
across processes either? I'm wondering what extra costs there are of using
a user data: URL font are vs referencing a system font. I guess usually the
system font gets mmaped so it's already in memory without having to do any
loading, conversion or decompression.

Rob
--
Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa
stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr,
'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp
waanndt wyeonut thoo mken.o w

[Vivien Nicolas]

On 06/17/2014 09:18 PM, James Burke wrote:
> On 6/17/14, 10:08 AM, Vivien Nicolas wrote:
>> That's true. Actually there are many other hacks that depends on the
>> fact that application are certified. So even if I would like to have
>> more apps as privileged apps just for the principle, it's not that
>> simple. And we may need to reconsider the |privileged| status of the
>> email app based on some of the use case on some low end devices for now.
>>
>> So one of the only reason the email app has been made |privileged| is
>> for some CSP compliance things, and because it does not needs APIs
>> that are certified-only. But we may need to keep it certified for
>> perf reasons if needed. It will depends on the impact of icon font there.
>
> I appreciate there are always tradeoffs, but I also want to caution
> against just proceeding because there is an escape value via
> certified. We have a train model, and if it takes another train to
> avoid certified-only, all apps benefit. It is already disconcerting
> that just switching the type value in the manifest from certified to
> privileged, we see a 20ms slowdown[1].

TBH I'm not surpised. We (re)discovered last september/october that the
CSP in JS was consuming a lot of startup time. Not because the JS code
was slow, but because of 1 xpconnect call per file, and apps loads a lot
of files.

So for certified app, we landed a fast path. It would be good to
investigate if this is purely related to the CSP or not, by simply
disabling it (security.csp.enable = false), and if yes, investigate if
reducing the number of files by aggregating them helps.

>
> The greater concern is these certified escapes build up, and then
> taking the time to undo them later eats into the next certified escape
> that is wanted, so the gap will continue to grow. A good way to start
> fighting the issue is to stop adding to the pile.
>

It's true that this is a big concern. The greater concern is that the
web platform is not competitive / successful. So in order to mitigate
some of the issues, that are always solvable but takes time, we adding
to the pile. We know that at some point we have to pay the cost, and we
always try to not take this path - sadly sometimes there is no other
choice for a given release, and then we need to add to the pile.

[Andreas Gal]

On Jun 18, 2014, at 2:03 AM, Vivien Nicolas <vnic...@mozilla.com> wrote:

>
> On 06/17/2014 09:18 PM, James Burke wrote:
>> On 6/17/14, 10:08 AM, Vivien Nicolas wrote:
>>> That's true. Actually there are many other hacks that depends on the fact that application are certified. So even if I would like to have more apps as privileged apps just for the principle, it's not that simple. And we may need to reconsider the |privileged| status of the email app based on some of the use case on some low end devices for now.
>>>
>>> So one of the only reason the email app has been made |privileged| is for some CSP compliance things, and because it does not needs APIs that are certified-only. But we may need to keep it certified for perf reasons if needed. It will depends on the impact of icon font there.
>>
>> I appreciate there are always tradeoffs, but I also want to caution against just proceeding because there is an escape value via certified. We have a train model, and if it takes another train to avoid certified-only, all apps benefit. It is already disconcerting that just switching the type value in the manifest from certified to privileged, we see a 20ms slowdown[1].
>
> TBH I'm not surpised. We (re)discovered last september/october that the CSP in JS was consuming a lot of startup time. Not because the JS code was slow, but because of 1 xpconnect call per file, and apps loads a lot of files.
>
> So for certified app, we landed a fast path. It would be good to investigate if this is purely related to the CSP or not, by simply disabling it (security.csp.enable = false), and if yes, investigate if reducing the number of files by aggregating them helps.

Please profile this. I am sure this can be optimized. We likely don’t need to involve xpconnect here for starters.

Thanks,

Andreas

>
>>
>> The greater concern is these certified escapes build up, and then taking the time to undo them later eats into the next certified escape that is wanted, so the gap will continue to grow. A good way to start fighting the issue is to stop adding to the pile.
>>
>
> It's true that this is a big concern. The greater concern is that the web platform is not competitive / successful. So in order to mitigate some of the issues, that are always solvable but takes time, we adding to the pile. We know that at some point we have to pay the cost, and we always try to not take this path - sadly sometimes there is no other choice for a given release, and then we need to add to the pile.
>
>
>> On icon fonts, it would be good to make sure there implemented with accessibility in mind. This document[1] talks about that, and mentions a Firefox bug[2] about aria-hidden that may need some attention if icon fonts are used in buttons.
>>
>> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1024005
>> [2] http://filamentgroup.com/lab/bulletproof_icon_fonts.html
>> [3] https://bugzilla.mozilla.org/show_bug.cgi?id=948540
>>
>> James
>>
>

[Kyle Huey]

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

This is being worked on in bug 925004.

- Kyle

[Fabrice Desré]

On 06/18/2014 04:51 AM, Andreas Gal wrote:

>> So for certified app, we landed a fast path. It would be good to
>> investigate if this is purely related to the CSP or not, by simply
>> disabling it (security.csp.enable = false), and if yes, investigate if
>> reducing the number of files by aggregating them helps.
>

> Please profile this. I am sure this can be optimized. We likely don�t

> need to involve xpconnect here for starters.

The xpconnect overhead should have disappeared with the new c++ csp
implementation that Sid's team landed. The hardcoded implementation of
the certified apps csp is still there though, and will be hard to beat
perf wise. I'm not sure how many resources the app is loading at
startup, but the csp cost is mostly linear with the resource number and
that adds up.

Fabrice
--
Fabrice Desr�
b2g team
Mozilla Corporation

[Jonas Sicking]

On Tue, Jun 17, 2014 at 5:09 AM, James Burke <jbu...@mozilla.com> wrote:
> On 6/16/14, 12:34 PM, Jet Villegas wrote:
>>
>> I also propose that we make any required code changes in v2.0 so that
>> non-certified apps can't get unrestricted use of the font. All the options
>> proposed (#2,3, or 4,) have drawbacks, the common one being that they may be
>> overly restrictive.
>>

> The Gaia email app has gone privileged instead of certified just recently. I
> expect that most partners will want to deliver the email app with the same
> look and feel as the other apps that may be certified. If that means the use
> of the icon font, we might have some trouble.

I agree that it's great when we can move to a privileged app. Though
if it comes at the cost of a 500ms or 150ms slowdown then that might
not be worth it.

Another thing that will likely force us to use certified apps for now
is Web Components. We are only enabling those for certified apps for
now since we want to have freedom to make changes to the spec and the
implementation without worrying about breaking other apps or webpages.

Can the email app work without Web Components?

Either way, I definitely agree that, we should certainly look at
reducing those 150ms. But do people really feel comfortable with
making that the only plan? Can we make that happen for Gecko 34
(September 1st)? At what point do we start working on a backup plan
such as the ones discussed in this thread?

/ Jonas

[James Burke]

On 6/18/14 8:25 AM, Jonas Sicking wrote:
> Another thing that will likely force us to use certified apps for now
> is Web Components. We are only enabling those for certified apps for
> now since we want to have freedom to make changes to the spec and the
> implementation without worrying about breaking other apps or webpages.
>
> Can the email app work without Web Components?
>
> Either way, I definitely agree that, we should certainly look at
> reducing those 150ms. But do people really feel comfortable with
> making that the only plan? Can we make that happen for Gecko 34
> (September 1st)? At what point do we start working on a backup plan
> such as the ones discussed in this thread?

So this is the heart of the matter (at least for email/gaia apps and the
idea of "privileged"):

"certified" is being used as an implementation pref switch. There will
always be new things we will want to try, and it helps if Gecko has a
well-constrained set of web apps to try it out, to work out any issues
in the Gecko implementation, maybe help give early feedback on specs. We
need a controlled space that also gets some real world use, but where we
can hopefully update as the Gecko implementation changes.

I am particularly interested in service workers because I am hopeful it
will eliminate the need for email's cookie cache that is used for fast
startup. I expect that will also only be enabled for "certified" apps in
the beginning.

This comes at a cost: Gaia apps will not be able to do installs/updates
via the Marketplace, which also makes it hard to use them on Android via
the web runtime, but the hope is that by having this early testing we
have better APIs and implementations for the web platform in the long run.

So, I think we just need to set the expectation for at least another
year or two, that the gaia set of apps will not be able to be
"privileged", because we need them as early beta testers for features
and capabilities we are building out for the mobile web platform.

In the short term this creates a bit of an issue for email. The
"privileged" setting helped with the new CSP policy desires (bug
1012652) but since email is part of gaia, and email uses some of the
shared resources, I filed bug 1027185 to switch email back to
"certified", and we'll have to use another approach for bug 1012652. I
will confirm the cause of the slowdown for bug 1024005 before switching
email back to certified.

That should end the "privileged" diversion for this thread.

James

[Ben Francis]

On Wed, Jun 18, 2014 at 6:59 PM, James Burke <jbu...@mozilla.com> wrote:

> So, I think we just need to set the expectation for at least another year
> or two, that the gaia set of apps will not be able to be "privileged",
> because we need them as early beta testers for features and capabilities we
> are building out for the mobile web platform.
>

We said that a year or two ago. There will always be new features to test,
and with a current total of 34 apps in the gaia/apps directory we have no
shortage of certified apps to test them out with. The risk of inadvertently
building another proprietary app platform that isn't the web and of
crippling the pace of Firefox OS updates because we're forcing 34 apps
through an arduous certification process they don't need (a mistake Android
already made for us) seems greater than the risk of taking the brave step
of making some Gaia apps a step closer to being web apps.

The longer that each Gaia app is not a web app, the less credible our
mantra of "the web is the platform" becomes. If we can't figure out how to
build our own apps using the web, how can we can expect third party app
developers to do so?

Maybe we haven't yet figured out all the details of how to put the Email
app in the Firefox Marketplace, let alone how to make it run
cross-platform, but if we resign ourselves to the idea that all Gaia apps
are going to have to be certified for the foreseeable future then we're not
doing our mission justice IMHO.

[James Burke]

It is a matter of degree: at least with Gaia apps we get the use of web
tech in the construction, just not the network delivery and
addressability, and by proving out the web APIs in Gaia first, we ensure
a better dev experience with those APIs later for all.

That is how I would frame the larger picture, in the effort of
cooperation and moving forward.

For me personally, I would absolutely not put a performance fix that is
only available for certified apps. See the use of the cookie cache in
email: it is ugly, but it is standard. Sometimes we need to do the
uglier things or have less ideal dev experience in the interests of
working on the common platform, file bugs for the platform, then switch
to something better when it is properly sorted out, available to all
apps. For email's cookie cache, I'm hopeful the proper answer will be
Service Workers.

But, I am not working on that platform code affected by the icon font
request, so it is easier for me to be harder philosophically in that
case. I would endorse that harder line though for performance changes
tied to "certified".

New features only in certified apps is a harder one to sort out. I
personally want to avoid features that are only available to certified
apps in email. However, since email depends on /shared, some of that
choice is out of email's control.

Maybe instead of using "certified" as the marker, we use app signing
instead, with a list of signatures that are allowed getting pushed as
part of device flashing, and a dev experience that overrides that, so
that we do not have to sign for our local dev-debug-deploy cycles.

James

[Jonas Sicking]

On Thu, Jun 19, 2014 at 3:20 AM, Ben Francis <bfra...@mozilla.com> wrote:

> On Wed, Jun 18, 2014 at 6:59 PM, James Burke <jbu...@mozilla.com> wrote:
>>
>> So, I think we just need to set the expectation for at least another year
>> or two, that the gaia set of apps will not be able to be "privileged",
>> because we need them as early beta testers for features and capabilities we
>> are building out for the mobile web platform.
>

> Maybe we haven't yet figured out all the details of how to put the Email app
> in the Firefox Marketplace, let alone how to make it run cross-platform, but
> if we resign ourselves to the idea that all Gaia apps are going to have to
> be certified for the foreseeable future then we're not doing our mission
> justice IMHO.

I'm all for making Gaia apps be privileged apps. It both enables us to
put it in the marketplace and puts more pressure on us to move the
"privileged apps" platform forward. The work to make Loop and the
homescreen only use privileged APIs has brought many advantages to the
privileged apps ecosystem.

Even better is to make Gaia apps be non-privileged normal hosted apps
as that does the same thing to the web. Calculator, if we shipped it,
could likely fall into this category already today.

But we have to realize that it comes at a cost. Right now it would
mean not using Web Components and (until we speed up Gecko) a 150ms
startup cost. 6 months from now the costs would likely not be zero, as
you point out, but they would hopefully be different.

So the question is when do we make this transition? I.e. when are the
above costs acceptable? I'm happy to leave that decision up to the
teams working on the individual apps.

But just because the answer is "not now", doesn't mean that the answer
is "never".

In the meantime, trying to stick to privileged permissions, or to
"normal" permissions, gives some of the benefit while making it
possible to avoid some of the costs.

/ Jonas