Page MenuHomePhabricator

Make Tokens modular / real application
Open, Needs TriagePublic

Assigned To
None
Authored By
epriestley
Jun 25 2016, 2:13 PM
Referenced Files
F1700509: sprite-tokens.png
Jun 25 2016, 2:13 PM
Tokens
"Manufacturing Defect?" token, awarded by logangorence."Manufacturing Defect?" token, awarded by stevex."Like" token, awarded by tomekj2ee."Like" token, awarded by yelirekim."Like" token, awarded by Luke081515.2."Like" token, awarded by joshuaspence.

Description

It would be nice to let installs define custom tokens for "Award Token". Two general approaches to this are:

  • extend them with extensions, so you can add tokens by installing extensions.
  • create a database "token" object, so you can add tokens via the web UI.

The major technical issue with both approaches is that tokens currently generate a sprite map, and this is a manual, offline process:

sprite-tokens.png (68×68 px, 7 KB)

Ideally, we would just generate this map (and the associated CSS) on demand through Celerity, so it could have as much stuff in it as we wanted without any performance penalty or need to run scripts.

We can't dynamically generate sprite maps through Celerity right now. This is probably not particularly difficult to build, although we will potentially lose optipng from the pipeline. We could still ship the default map as a cached resource on disk and accept a small reduction in compression effectiveness when installs extend the defaults, although this increases complexity.

We also don't really need to sprite these resources, and could stop doing them as a sprite map and accept the performance hit. Or we could sprite the defaults and accept that extensions eat a performance hit.

When I built tokens, I think we used a lot of sprite maps and it seemed inevitable that we'd need to modularize them eventually (e.g., for application icons). However, FontAwesome has replaced most uses and we use very few today, and it no longer seems inevitable that we must provide modular sprite composition. This reduces the attractiveness of sinking work into on-demand sprite composition infrastructure.

Event Timeline

Probably go with data driven. I don't think these need to be sprited, but should probably inline CSS (base64) with celerity? I don't think these will be large enough to need to be in an image sheet.

So I think I can lay the groundwork here. My plan is to:

  • Implement PhabricatorTokensToken
  • Allow creation, editing, viewing of Tokens.
  • Do nothing with UI/Display
  • Allow you to figure out migration to new backend/display

One question though, does EditEngine support file uploads?

Probably go with data driven. I don't think these need to be sprited, but should probably inline CSS (base64) with celerity? I don't think these will be large enough to need to be in an image sheet.

Although I think this is a reasonable approach, data-driven-CSS is probably slightly more complicated than data-driven-sprite-sheets because it interacts with packaging. D16178 has more discussion.

One question though, does EditEngine support file uploads?

Not yet. I think this isn't too tricky to build. It should be based on the newer/fancier PHUIFormFileControl (which is what the "Upload File" button in Remarkup uses now) control, since that supports huge files / chunked uploads / resuming, not the older AphrontFormFileControl.php. This control is unique in that it needs to run code when the containing form is submitted (other Javascript controls like tokenizers only run code when they are interacted with directly) so getting it to work as part of run-of-the-mill forms may be a little tricky.

eadler added a project: Restricted Project.Sep 15 2016, 6:08 PM

This one is a little scattered, so let me know where I can fill in any gaps. Most of the details are in D16178.

Currently, Tokens are hard-coded: all installs have exactly the same tokens we ship with, and they can't be disabled or extended.

We'd like to make this system more flexible so that installs can add their own tokens, and third-party applications could conceivably add new types of tokens.

D16178#189120 roughly outlines how to get started on this -- that's more of a general shape of things, but I think you've run into most of this stuff at least a little bit already.

At some point we need to add a new type of dynamic CSS sheet to Celerity, but I think that's not hugely involved and I can probably just bang it out faster than write it up.

Don't know if D16178 is worth comandeering? But feel free.

fwiw, I want to convert all bitmaps to SVG if possible, so we can skip building 1x and 2x images.

I think we can just do 2x in all cases for these, if that's reasonable?

Are SVG'd bitmaps smaller than just 2x? I'd assume they'd be larger unless we actually redraw them with vectors.

I'm generally hesitant to start using SVG for anything because SVG has like thirty five million security issues (T6445). In this case the SVG would be trusted, but Celerity would have to be able to serve it, which puts us closer to making a mistake and getting an XSS hole.

(That will give us slightly bad scale-downs on 1X screens, but I bet they're not worse than scaling down an SVG would be.)

I'd like to generate 1 image and have them work 1x, 2x, 3x, etc or any size I need. I can't think of any other long term solution.

For example:

iPhone 7 plus = 2.46
iPhone 7 = 2
Galaxy 6s = 4
Galaxy 5 mini = 3.396
Macbook = 2
Macbook Air = 1

Alright -- we can have bin/celerity map rasterize SVG into arbitrary sizes if I'm not comfortable serving SVG directly from Celerity.

I'm also not sure if we can use SVG as a data: URL in CSS. It probably should work, but if it doesn't we'll have to rasterize (and, I guess, serve 5+ different sizes to every user).

This isn't like something I'm looking for immediately, btw. Just like, next time I have to make 50 images.

I did order an iPhone 7 plus, so I'll have a better understanding if 2x is actually noticeably bad.

T12000 isn't really a duplicate. It's more of an enhancement for today's tokens. Of course, it'd be useful for this eventually, too, but that's tangential.

chad renamed this task from Make tokens modular or data-driven to Make Tokens modular / real application.Dec 13 2016, 12:11 AM
epriestley added a subscriber: jcox.