Page MenuHomePhabricator

Allow custom CSS overrides on a per-app basis
Closed, WontfixPublic

Description

Without going all the way to implementing themes as in T4213, I think it would go a long way to make basic UI tweaks available to users by adding a setting to the most common apps like Maniphest and Projects to specify custom CSS to be injected into the <style> section of HTML page at rendering time.

Concrete example: to fix the labels not wrapping in the tiles of the workboards (https://github.com/facebook/phabricator/issues/600), one would simply set the CSS override to white-space: normal;.

Obviously such setting might have a disclaimer saying there's not guarantee the overrides will continue to work across releases etc... but it's much much cleaner than having to fork the repo.

Event Timeline

swisspol raised the priority of this task from to Needs Triage.
swisspol updated the task description. (Show Details)
swisspol added a subscriber: swisspol.

You can include your own CSS/JS overrides with Celerity, see https://secure.phabricator.com/book/phabcontrib/article/adding_new_css_and_js/. If we're getting large amounts of complaints on design/layout defaults, then we'll simply fix/resolve the defaults to the best of our ability. Dashboards also improve users customizability.

Re: workboards, we're going to default to long titles.

epriestley claimed this task.

We tend to bear a lot of costs (in terms of users being frustrated and upset) when we ship junky things, no matter how many caveats we put on them.

For example, we accepted a "immediately deprecated" API call in the past covered with "this is unstable and will be removed" warnings, but the guy who wrote it and was totally onboard with that solution had switched teams by the time we broke it, and the new guy didn't have the context and wasn't happy about things.

I think it's better for everyone involved to explicitly force installs to bear the costs in an obvious way (forking + merging) than to implicitly force them to bear the costs in an ignorable/forgettable way (one-time warning, eventual breakage without a smoking gun of local changes).

As @chad mentions, you can technically do this today, but it's almost certainly more work than forking + merging.

In this specific case, D9148 adjusted the wrapping behavior.

Thanks for the feedback. I was aware of the Celerity but thought it was a bit overkilled. I'm glad D9148 improved things though.