2011-01-25 20:31:40 +01:00
|
|
|
/**
|
2013-08-26 20:53:11 +02:00
|
|
|
* @provides phui-form-view-css
|
2011-01-25 20:31:40 +01:00
|
|
|
*/
|
|
|
|
|
|
2013-08-26 20:53:11 +02:00
|
|
|
.phui-form-view {
|
|
|
|
|
padding: 16px;
|
2011-06-10 00:28:29 +02:00
|
|
|
}
|
|
|
|
|
|
[Redesign] Mobile/Phone design pass
Summary: Ref T8099, Quick descent pass at making header, object lists, tables, filter view, mobile friendly.
Test Plan:
Test home, differential diff, maniphest task, new task, search, and a few other views.
{F414034}
Reviewers: btrahan, epriestley
Reviewed By: epriestley
Subscribers: Korvin, epriestley
Maniphest Tasks: T8099
Differential Revision: https://secure.phabricator.com/D12984
2015-05-23 02:52:51 +02:00
|
|
|
.device-phone .phui-object-box .phui-form-view {
|
|
|
|
|
padding: 0;
|
|
|
|
|
}
|
|
|
|
|
|
2013-08-26 20:53:11 +02:00
|
|
|
.phui-form-view.phui-form-full-width {
|
|
|
|
|
padding: 0;
|
2013-06-18 07:02:16 +02:00
|
|
|
}
|
|
|
|
|
|
2013-08-26 20:53:11 +02:00
|
|
|
.phui-form-view label.aphront-form-label {
|
2011-01-25 22:26:09 +01:00
|
|
|
width: 19%;
|
2016-11-10 01:31:30 +01:00
|
|
|
height: 28px;
|
|
|
|
|
line-height: 28px;
|
2011-01-25 20:31:40 +01:00
|
|
|
float: left;
|
|
|
|
|
text-align: right;
|
|
|
|
|
font-weight: bold;
|
2015-06-26 18:33:03 +02:00
|
|
|
font-size: {$normalfontsize};
|
2013-09-07 18:13:55 +02:00
|
|
|
color: {$bluetext};
|
2013-08-26 20:53:11 +02:00
|
|
|
-webkit-font-smoothing: antialiased;
|
2011-01-25 20:31:40 +01:00
|
|
|
}
|
|
|
|
|
|
2013-08-26 20:53:11 +02:00
|
|
|
.device-phone .phui-form-view label.aphront-form-label,
|
|
|
|
|
.phui-form-full-width.phui-form-view label.aphront-form-label {
|
2013-07-04 05:24:28 +02:00
|
|
|
display: block;
|
|
|
|
|
float: none;
|
2013-01-19 23:30:26 +01:00
|
|
|
text-align: left;
|
2013-07-04 05:24:28 +02:00
|
|
|
width: 100%;
|
2013-03-13 07:30:03 +01:00
|
|
|
margin-bottom: 3px;
|
2013-01-19 23:30:26 +01:00
|
|
|
}
|
|
|
|
|
|
2011-01-25 20:31:40 +01:00
|
|
|
.aphront-form-input {
|
2011-01-25 22:26:09 +01:00
|
|
|
margin-left: 20%;
|
Update form styles, implement in many places
Summary:
This creates a common form look and feel across the site. I spent a bit of time working out a number of kinks in our various renderings. Some things:
- Font Styles are correctly applied for form elements now.
- Everything lines up!
- Selects are larger, easier to read, interact.
- Inputs have been squared.
- Consistant CSS applied glow (try it!)
- Improved Mobile Responsiveness
- CSS applied to all form elements, not just Aphront
- Many other minor tweaks.
I tried to hit as many high profile forms as possible in an effort to increase consistency. Stopped for now and will follow up after this lands. I know Evan is not a super fan of the glow, but after working with it for a week, it's way cleaner and responsive than the OS controls. Give it a try.
Test Plan: Tested many applications, forms, mobile and tablet.
Reviewers: epriestley, btrahan
Reviewed By: epriestley
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D5860
2013-05-07 23:07:06 +02:00
|
|
|
margin-right: 20%;
|
|
|
|
|
width: 60%;
|
2011-01-25 20:31:40 +01:00
|
|
|
}
|
|
|
|
|
|
2013-05-14 21:21:00 +02:00
|
|
|
.device-phone .aphront-form-input,
|
2015-04-06 19:10:18 +02:00
|
|
|
.device .aphront-form-input select,
|
|
|
|
|
.device .aphront-form-input pre,
|
2013-08-26 20:53:11 +02:00
|
|
|
.phui-form-full-width .aphront-form-input {
|
2013-01-19 23:30:26 +01:00
|
|
|
margin-left: 0%;
|
|
|
|
|
margin-right: 0%;
|
|
|
|
|
width: 100%;
|
|
|
|
|
}
|
|
|
|
|
|
2014-05-22 18:12:54 +02:00
|
|
|
.aphront-form-input *::-webkit-input-placeholder {
|
|
|
|
|
color:{$greytext} !important;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.aphront-form-input *::-moz-placeholder {
|
|
|
|
|
color:{$greytext} !important;
|
|
|
|
|
opacity: 1; /* Firefox nudges the opacity to 0.4 */
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.aphront-form-input *:-ms-input-placeholder {
|
|
|
|
|
color:{$greytext} !important;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2011-01-25 20:31:40 +01:00
|
|
|
.aphront-form-error {
|
Update form styles, implement in many places
Summary:
This creates a common form look and feel across the site. I spent a bit of time working out a number of kinks in our various renderings. Some things:
- Font Styles are correctly applied for form elements now.
- Everything lines up!
- Selects are larger, easier to read, interact.
- Inputs have been squared.
- Consistant CSS applied glow (try it!)
- Improved Mobile Responsiveness
- CSS applied to all form elements, not just Aphront
- Many other minor tweaks.
I tried to hit as many high profile forms as possible in an effort to increase consistency. Stopped for now and will follow up after this lands. I know Evan is not a super fan of the glow, but after working with it for a week, it's way cleaner and responsive than the OS controls. Give it a try.
Test Plan: Tested many applications, forms, mobile and tablet.
Reviewers: epriestley, btrahan
Reviewed By: epriestley
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D5860
2013-05-07 23:07:06 +02:00
|
|
|
width: 18%;
|
2011-01-25 20:31:40 +01:00
|
|
|
float: right;
|
2013-06-21 02:11:57 +02:00
|
|
|
color: {$red};
|
2011-01-25 20:31:40 +01:00
|
|
|
font-weight: bold;
|
2013-06-21 02:11:57 +02:00
|
|
|
padding-top: 5px;
|
2011-01-25 20:31:40 +01:00
|
|
|
}
|
|
|
|
|
|
2015-02-03 16:08:59 +01:00
|
|
|
.aphront-form-label .aphront-form-error {
|
|
|
|
|
display: none;
|
|
|
|
|
}
|
|
|
|
|
|
2013-08-26 20:53:11 +02:00
|
|
|
.aphront-dialog-body .phui-form-view {
|
|
|
|
|
padding: 0;
|
|
|
|
|
}
|
|
|
|
|
|
2013-05-14 21:21:00 +02:00
|
|
|
.device-phone .aphront-form-error,
|
2013-08-26 20:53:11 +02:00
|
|
|
.phui-form-full-width .aphront-form-error {
|
2015-02-03 16:08:59 +01:00
|
|
|
display: none;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.device-phone .aphront-form-label .aphront-form-error,
|
|
|
|
|
.phui-form-full-width .aphront-form-label .aphront-form-error {
|
|
|
|
|
display: block;
|
|
|
|
|
float: right;
|
|
|
|
|
padding: 0;
|
|
|
|
|
width: auto;
|
2013-01-19 23:30:26 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.device-phone .aphront-form-drag-and-drop-upload {
|
|
|
|
|
display: none;
|
|
|
|
|
}
|
|
|
|
|
|
2012-08-15 23:15:12 +02:00
|
|
|
.aphront-form-required {
|
|
|
|
|
font-weight: normal;
|
2013-09-02 17:10:47 +02:00
|
|
|
color: {$lightgreytext};
|
2015-06-26 18:33:03 +02:00
|
|
|
font-size: {$smallestfontsize};
|
2013-08-26 20:53:11 +02:00
|
|
|
-webkit-font-smoothing: antialiased;
|
2012-08-15 23:15:12 +02:00
|
|
|
}
|
|
|
|
|
|
2016-08-17 23:57:21 +02:00
|
|
|
.aphront-form-input input[type="text"],
|
|
|
|
|
.aphront-form-input input[type="password"] {
|
2011-01-25 20:31:40 +01:00
|
|
|
width: 100%;
|
|
|
|
|
}
|
|
|
|
|
|
2015-03-02 22:01:08 +01:00
|
|
|
.aphront-form-cvc-input input {
|
|
|
|
|
width: 64px;
|
|
|
|
|
}
|
|
|
|
|
|
2011-01-25 20:31:40 +01:00
|
|
|
.aphront-form-input textarea {
|
Update form styles, implement in many places
Summary:
This creates a common form look and feel across the site. I spent a bit of time working out a number of kinks in our various renderings. Some things:
- Font Styles are correctly applied for form elements now.
- Everything lines up!
- Selects are larger, easier to read, interact.
- Inputs have been squared.
- Consistant CSS applied glow (try it!)
- Improved Mobile Responsiveness
- CSS applied to all form elements, not just Aphront
- Many other minor tweaks.
I tried to hit as many high profile forms as possible in an effort to increase consistency. Stopped for now and will follow up after this lands. I know Evan is not a super fan of the glow, but after working with it for a week, it's way cleaner and responsive than the OS controls. Give it a try.
Test Plan: Tested many applications, forms, mobile and tablet.
Reviewers: epriestley, btrahan
Reviewed By: epriestley
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D5860
2013-05-07 23:07:06 +02:00
|
|
|
display: block;
|
|
|
|
|
width: 100%;
|
|
|
|
|
box-sizing: border-box;
|
2011-01-25 20:31:40 +01:00
|
|
|
height: 12em;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.aphront-form-control {
|
|
|
|
|
padding: 4px;
|
|
|
|
|
}
|
|
|
|
|
|
2016-07-26 21:17:45 +02:00
|
|
|
.device-phone .aphront-form-control {
|
|
|
|
|
padding: 4px 8px 8px;
|
|
|
|
|
}
|
|
|
|
|
|
2013-08-26 20:53:11 +02:00
|
|
|
.phui-form-full-width .aphront-form-control {
|
2013-05-22 00:28:43 +02:00
|
|
|
padding: 4px 0;
|
|
|
|
|
}
|
|
|
|
|
|
2011-01-25 20:31:40 +01:00
|
|
|
.aphront-form-control-submit button,
|
|
|
|
|
.aphront-form-control-submit a.button {
|
|
|
|
|
float: right;
|
2013-08-26 20:53:11 +02:00
|
|
|
margin: 4px 0 0 8px;
|
2011-01-26 00:19:06 +01:00
|
|
|
}
|
|
|
|
|
|
2013-10-25 22:59:02 +02:00
|
|
|
.phui-form-control-multi-submit input,
|
2014-03-25 22:20:25 +01:00
|
|
|
.phui-form-control-multi-submit button,
|
2013-10-25 22:59:02 +02:00
|
|
|
.phui-form-control-multi-submit a {
|
Add a basic multipage form
Summary:
Ref T2232. Very busy day on IRC so I feel like I've made 20 minutes of progress in 1-minute spurts here, but this adds the basics for a form that can have multiple pages and automatically handle pagination and reading to/from the request, objects and responses.
The UIExample is reasonably instructive. Basically, you make a form, add pages to the form, and add controls to the pages. The core flow control looks like this:
if ($request->isFormPost()) {
$form->readFromRequest($request); // (1)
if ($form->isComplete()) { // (2)
$response = $form->writeToResponse($response); // (3)
// Process result here. // (4)
}
} else {
$form->readFromObject($object); // (5)
}
The key parts are:
# This reads the form state from the request, including reading all the inactive pages.
# This tests if all pages are valid and the user just clicked "Done" on the last page.
# This produces a "response", which might be writing to an object (for simpler forms) or creating a transaction record (for more complex forms).
# Here, we would save the object or apply the transactions.
# When the user views the form for the first time, we preload all the values from some object (which might just be empty).
Ultimate goal here is to fix repository creation to not be a terrible pit of awfulness.
There are probably a lot of rough edges and missing features still, but this seems to not be totally crazy.
I'm using two submit buttons with different names which doesn't work on IE7 or something, but we can JS our way out of that if we need to.
Test Plan: Paged forward and backward through the form.
Reviewers: btrahan, chad
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T2232
Differential Revision: https://secure.phabricator.com/D6003
2013-05-23 23:39:01 +02:00
|
|
|
float: right;
|
2014-03-25 22:20:25 +01:00
|
|
|
margin: 4px 0 0 8px;
|
Add a basic multipage form
Summary:
Ref T2232. Very busy day on IRC so I feel like I've made 20 minutes of progress in 1-minute spurts here, but this adds the basics for a form that can have multiple pages and automatically handle pagination and reading to/from the request, objects and responses.
The UIExample is reasonably instructive. Basically, you make a form, add pages to the form, and add controls to the pages. The core flow control looks like this:
if ($request->isFormPost()) {
$form->readFromRequest($request); // (1)
if ($form->isComplete()) { // (2)
$response = $form->writeToResponse($response); // (3)
// Process result here. // (4)
}
} else {
$form->readFromObject($object); // (5)
}
The key parts are:
# This reads the form state from the request, including reading all the inactive pages.
# This tests if all pages are valid and the user just clicked "Done" on the last page.
# This produces a "response", which might be writing to an object (for simpler forms) or creating a transaction record (for more complex forms).
# Here, we would save the object or apply the transactions.
# When the user views the form for the first time, we preload all the values from some object (which might just be empty).
Ultimate goal here is to fix repository creation to not be a terrible pit of awfulness.
There are probably a lot of rough edges and missing features still, but this seems to not be totally crazy.
I'm using two submit buttons with different names which doesn't work on IE7 or something, but we can JS our way out of that if we need to.
Test Plan: Paged forward and backward through the form.
Reviewers: btrahan, chad
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T2232
Differential Revision: https://secure.phabricator.com/D6003
2013-05-23 23:39:01 +02:00
|
|
|
width: auto;
|
|
|
|
|
}
|
|
|
|
|
|
2011-01-26 02:17:19 +01:00
|
|
|
.aphront-form-control-textarea textarea.aphront-textarea-very-short {
|
Update form styles, implement in many places
Summary:
This creates a common form look and feel across the site. I spent a bit of time working out a number of kinks in our various renderings. Some things:
- Font Styles are correctly applied for form elements now.
- Everything lines up!
- Selects are larger, easier to read, interact.
- Inputs have been squared.
- Consistant CSS applied glow (try it!)
- Improved Mobile Responsiveness
- CSS applied to all form elements, not just Aphront
- Many other minor tweaks.
I tried to hit as many high profile forms as possible in an effort to increase consistency. Stopped for now and will follow up after this lands. I know Evan is not a super fan of the glow, but after working with it for a week, it's way cleaner and responsive than the OS controls. Give it a try.
Test Plan: Tested many applications, forms, mobile and tablet.
Reviewers: epriestley, btrahan
Reviewed By: epriestley
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D5860
2013-05-07 23:07:06 +02:00
|
|
|
height: 44px;
|
2011-01-26 02:17:19 +01:00
|
|
|
}
|
|
|
|
|
|
2011-02-05 21:20:18 +01:00
|
|
|
.aphront-form-control-textarea textarea.aphront-textarea-very-tall {
|
|
|
|
|
height: 24em;
|
|
|
|
|
}
|
|
|
|
|
|
2013-08-26 20:53:11 +02:00
|
|
|
.phui-form-view .aphront-form-caption {
|
2015-06-26 18:33:03 +02:00
|
|
|
font-size: {$smallerfontsize};
|
2013-09-07 18:13:55 +02:00
|
|
|
color: {$bluetext};
|
2014-11-21 20:16:13 +01:00
|
|
|
padding: 8px 0;
|
Update form styles, implement in many places
Summary:
This creates a common form look and feel across the site. I spent a bit of time working out a number of kinks in our various renderings. Some things:
- Font Styles are correctly applied for form elements now.
- Everything lines up!
- Selects are larger, easier to read, interact.
- Inputs have been squared.
- Consistant CSS applied glow (try it!)
- Improved Mobile Responsiveness
- CSS applied to all form elements, not just Aphront
- Many other minor tweaks.
I tried to hit as many high profile forms as possible in an effort to increase consistency. Stopped for now and will follow up after this lands. I know Evan is not a super fan of the glow, but after working with it for a week, it's way cleaner and responsive than the OS controls. Give it a try.
Test Plan: Tested many applications, forms, mobile and tablet.
Reviewers: epriestley, btrahan
Reviewed By: epriestley
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D5860
2013-05-07 23:07:06 +02:00
|
|
|
margin-right: 20%;
|
2011-01-26 02:40:21 +01:00
|
|
|
margin-left: 20%;
|
2013-08-26 20:53:11 +02:00
|
|
|
-webkit-font-smoothing: antialiased;
|
2015-06-26 18:33:03 +02:00
|
|
|
line-height: 16px;
|
2011-01-25 20:31:40 +01:00
|
|
|
}
|
|
|
|
|
|
2013-08-26 20:53:11 +02:00
|
|
|
.device-phone .phui-form-view .aphront-form-caption,
|
|
|
|
|
.phui-form-full-width .phui-form-view .aphront-form-caption {
|
2014-11-21 20:16:13 +01:00
|
|
|
margin: 0;
|
2013-01-19 23:30:26 +01:00
|
|
|
}
|
|
|
|
|
|
2011-01-25 20:31:40 +01:00
|
|
|
.aphront-form-instructions {
|
Update form styles, implement in many places
Summary:
This creates a common form look and feel across the site. I spent a bit of time working out a number of kinks in our various renderings. Some things:
- Font Styles are correctly applied for form elements now.
- Everything lines up!
- Selects are larger, easier to read, interact.
- Inputs have been squared.
- Consistant CSS applied glow (try it!)
- Improved Mobile Responsiveness
- CSS applied to all form elements, not just Aphront
- Many other minor tweaks.
I tried to hit as many high profile forms as possible in an effort to increase consistency. Stopped for now and will follow up after this lands. I know Evan is not a super fan of the glow, but after working with it for a week, it's way cleaner and responsive than the OS controls. Give it a try.
Test Plan: Tested many applications, forms, mobile and tablet.
Reviewers: epriestley, btrahan
Reviewed By: epriestley
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D5860
2013-05-07 23:07:06 +02:00
|
|
|
width: 60%;
|
|
|
|
|
margin-left: 20%;
|
2016-07-26 21:32:56 +02:00
|
|
|
padding: 12px 4px;
|
|
|
|
|
color: {$darkbluetext};
|
Update form styles, implement in many places
Summary:
This creates a common form look and feel across the site. I spent a bit of time working out a number of kinks in our various renderings. Some things:
- Font Styles are correctly applied for form elements now.
- Everything lines up!
- Selects are larger, easier to read, interact.
- Inputs have been squared.
- Consistant CSS applied glow (try it!)
- Improved Mobile Responsiveness
- CSS applied to all form elements, not just Aphront
- Many other minor tweaks.
I tried to hit as many high profile forms as possible in an effort to increase consistency. Stopped for now and will follow up after this lands. I know Evan is not a super fan of the glow, but after working with it for a week, it's way cleaner and responsive than the OS controls. Give it a try.
Test Plan: Tested many applications, forms, mobile and tablet.
Reviewers: epriestley, btrahan
Reviewed By: epriestley
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D5860
2013-05-07 23:07:06 +02:00
|
|
|
}
|
|
|
|
|
|
2013-05-14 21:21:00 +02:00
|
|
|
.device .aphront-form-instructions,
|
2013-08-26 20:53:11 +02:00
|
|
|
.phui-form-full-width .aphront-form-instructions {
|
2016-07-26 21:32:56 +02:00
|
|
|
width: auto;
|
Update form styles, implement in many places
Summary:
This creates a common form look and feel across the site. I spent a bit of time working out a number of kinks in our various renderings. Some things:
- Font Styles are correctly applied for form elements now.
- Everything lines up!
- Selects are larger, easier to read, interact.
- Inputs have been squared.
- Consistant CSS applied glow (try it!)
- Improved Mobile Responsiveness
- CSS applied to all form elements, not just Aphront
- Many other minor tweaks.
I tried to hit as many high profile forms as possible in an effort to increase consistency. Stopped for now and will follow up after this lands. I know Evan is not a super fan of the glow, but after working with it for a week, it's way cleaner and responsive than the OS controls. Give it a try.
Test Plan: Tested many applications, forms, mobile and tablet.
Reviewers: epriestley, btrahan
Reviewed By: epriestley
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D5860
2013-05-07 23:07:06 +02:00
|
|
|
margin: 0;
|
2016-07-26 21:32:56 +02:00
|
|
|
padding: 12px 8px 8px;
|
2011-01-25 20:31:40 +01:00
|
|
|
}
|
|
|
|
|
|
2011-09-06 18:37:35 +02:00
|
|
|
.aphront-form-important {
|
|
|
|
|
margin: .5em 0;
|
|
|
|
|
background: #ffffdd;
|
|
|
|
|
padding: .5em 1em;
|
|
|
|
|
}
|
|
|
|
|
.aphront-form-important code {
|
|
|
|
|
display: block;
|
|
|
|
|
padding: .25em;
|
|
|
|
|
margin: .5em 2em;
|
|
|
|
|
}
|
|
|
|
|
|
2012-02-22 19:21:39 +01:00
|
|
|
.aphront-form-control-markup .aphront-form-input {
|
2015-06-26 18:33:03 +02:00
|
|
|
font-size: {$normalfontsize};
|
2011-01-25 20:31:40 +01:00
|
|
|
}
|
2011-01-26 02:40:21 +01:00
|
|
|
|
2016-12-07 06:22:01 +01:00
|
|
|
.aphront-form-control-static .aphront-form-input {
|
|
|
|
|
line-height: 28px;
|
|
|
|
|
}
|
|
|
|
|
|
2011-04-04 00:50:06 +02:00
|
|
|
.aphront-form-control-togglebuttons .aphront-form-input {
|
2013-03-13 07:30:03 +01:00
|
|
|
padding: 2px 0 0 0;
|
2011-04-04 00:50:06 +02:00
|
|
|
}
|
|
|
|
|
|
Improve Herald personal/global UI/UX
Summary:
- Default "personal" vs "global" choice to "personal".
- Don't show global rules under "My Rules".
- After editing or creating a global rule, redirect back to global rule list.
- Use radio buttons for "personal" vs "global" and add captions explaining the
difference.
- For "global" rules, don't show the owner/author in the rule detail view --
they effectively have no owner (see also D1387).
- For "global" rules, don't show the owner/author in the rule list view, as
above.
- For admin views, show rule type (global vs personal).
Test Plan:
- Created and edited new global and personal rules.
- Viewed "my", "global" and "admin" views.
Reviewers: btrahan, jungejason, nh, xela
Reviewed By: btrahan
CC: aran, epriestley
Differential Revision: https://secure.phabricator.com/D1518
2012-01-31 21:09:29 +01:00
|
|
|
table.aphront-form-control-radio-layout,
|
2011-01-26 02:40:21 +01:00
|
|
|
table.aphront-form-control-checkbox-layout {
|
2017-03-14 22:21:43 +01:00
|
|
|
margin-top: 4px !important;
|
2015-06-26 18:33:03 +02:00
|
|
|
font-size: {$normalfontsize};
|
2011-01-26 02:40:21 +01:00
|
|
|
}
|
|
|
|
|
|
2013-06-17 19:52:38 +02:00
|
|
|
table.aphront-form-control-radio-layout th {
|
2013-06-17 19:51:35 +02:00
|
|
|
padding-left: 8px;
|
2017-03-14 22:21:43 +01:00
|
|
|
padding-bottom: 8px;
|
2013-06-17 19:51:35 +02:00
|
|
|
font-weight: bold;
|
2013-09-02 22:57:48 +02:00
|
|
|
color: {$darkgreytext};
|
2011-01-26 02:40:21 +01:00
|
|
|
}
|
|
|
|
|
|
2013-06-20 23:13:53 +02:00
|
|
|
|
2013-06-17 19:52:38 +02:00
|
|
|
table.aphront-form-control-checkbox-layout th {
|
|
|
|
|
padding-top: 2px;
|
|
|
|
|
padding-left: 8px;
|
2013-08-27 18:08:01 +02:00
|
|
|
padding-bottom: 4px;
|
2013-09-02 22:57:48 +02:00
|
|
|
color: {$darkgreytext};
|
2013-06-17 19:52:38 +02:00
|
|
|
}
|
|
|
|
|
|
Improve Herald personal/global UI/UX
Summary:
- Default "personal" vs "global" choice to "personal".
- Don't show global rules under "My Rules".
- After editing or creating a global rule, redirect back to global rule list.
- Use radio buttons for "personal" vs "global" and add captions explaining the
difference.
- For "global" rules, don't show the owner/author in the rule detail view --
they effectively have no owner (see also D1387).
- For "global" rules, don't show the owner/author in the rule list view, as
above.
- For admin views, show rule type (global vs personal).
Test Plan:
- Created and edited new global and personal rules.
- Viewed "my", "global" and "admin" views.
Reviewers: btrahan, jungejason, nh, xela
Reviewed By: btrahan
CC: aran, epriestley
Differential Revision: https://secure.phabricator.com/D1518
2012-01-31 21:09:29 +01:00
|
|
|
.aphront-form-control-radio-layout td input,
|
2011-01-26 02:40:21 +01:00
|
|
|
.aphront-form-control-checkbox-layout td input {
|
2011-12-23 03:08:05 +01:00
|
|
|
margin-top: 4px;
|
2011-01-26 02:40:21 +01:00
|
|
|
width: auto;
|
|
|
|
|
}
|
2011-02-06 08:56:06 +01:00
|
|
|
|
2013-06-20 23:13:53 +02:00
|
|
|
.aphront-form-control-radio-layout label.disabled,
|
|
|
|
|
.aphront-form-control-checkbox-layout label.disabled {
|
2013-09-02 17:10:47 +02:00
|
|
|
color: {$greytext};
|
2013-06-20 23:13:53 +02:00
|
|
|
}
|
|
|
|
|
|
Improve Herald personal/global UI/UX
Summary:
- Default "personal" vs "global" choice to "personal".
- Don't show global rules under "My Rules".
- After editing or creating a global rule, redirect back to global rule list.
- Use radio buttons for "personal" vs "global" and add captions explaining the
difference.
- For "global" rules, don't show the owner/author in the rule detail view --
they effectively have no owner (see also D1387).
- For "global" rules, don't show the owner/author in the rule list view, as
above.
- For admin views, show rule type (global vs personal).
Test Plan:
- Created and edited new global and personal rules.
- Viewed "my", "global" and "admin" views.
Reviewers: btrahan, jungejason, nh, xela
Reviewed By: btrahan
CC: aran, epriestley
Differential Revision: https://secure.phabricator.com/D1518
2012-01-31 21:09:29 +01:00
|
|
|
.aphront-form-radio-caption {
|
2013-06-17 19:51:35 +02:00
|
|
|
margin-top: 4px;
|
2015-06-26 18:33:03 +02:00
|
|
|
font-size: {$smallerfontsize};
|
2013-06-17 19:51:35 +02:00
|
|
|
font-weight: normal;
|
2015-06-26 18:33:03 +02:00
|
|
|
color: {$bluetext};
|
Improve Herald personal/global UI/UX
Summary:
- Default "personal" vs "global" choice to "personal".
- Don't show global rules under "My Rules".
- After editing or creating a global rule, redirect back to global rule list.
- Use radio buttons for "personal" vs "global" and add captions explaining the
difference.
- For "global" rules, don't show the owner/author in the rule detail view --
they effectively have no owner (see also D1387).
- For "global" rules, don't show the owner/author in the rule list view, as
above.
- For admin views, show rule type (global vs personal).
Test Plan:
- Created and edited new global and personal rules.
- Viewed "my", "global" and "admin" views.
Reviewers: btrahan, jungejason, nh, xela
Reviewed By: btrahan
CC: aran, epriestley
Differential Revision: https://secure.phabricator.com/D1518
2012-01-31 21:09:29 +01:00
|
|
|
}
|
|
|
|
|
|
2012-06-26 17:14:15 +02:00
|
|
|
.aphront-form-control-image span {
|
2013-08-27 18:08:01 +02:00
|
|
|
margin: 0 4px 0 2px;
|
2012-06-26 17:14:15 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.aphront-form-control-image .default-image {
|
2013-01-25 02:23:05 +01:00
|
|
|
display: inline;
|
2012-06-26 17:14:15 +02:00
|
|
|
width: 12px;
|
|
|
|
|
}
|
|
|
|
|
|
2011-02-06 08:56:06 +01:00
|
|
|
.aphront-form-input hr {
|
|
|
|
|
border: none;
|
|
|
|
|
background: #bbbbbb;
|
|
|
|
|
height: 1px;
|
|
|
|
|
position: relative;
|
2011-03-24 19:07:36 +01:00
|
|
|
}
|
|
|
|
|
|
2014-11-07 23:16:30 +01:00
|
|
|
.phui-form-inset {
|
2016-04-01 16:14:25 +02:00
|
|
|
margin: 12px 0;
|
2013-08-26 20:53:11 +02:00
|
|
|
padding: 8px;
|
2014-11-17 23:06:05 +01:00
|
|
|
background: #f7f9fd;
|
|
|
|
|
border: 1px solid {$lightblueborder};
|
|
|
|
|
border-radius: 3px;
|
Update form styles, implement in many places
Summary:
This creates a common form look and feel across the site. I spent a bit of time working out a number of kinks in our various renderings. Some things:
- Font Styles are correctly applied for form elements now.
- Everything lines up!
- Selects are larger, easier to read, interact.
- Inputs have been squared.
- Consistant CSS applied glow (try it!)
- Improved Mobile Responsiveness
- CSS applied to all form elements, not just Aphront
- Many other minor tweaks.
I tried to hit as many high profile forms as possible in an effort to increase consistency. Stopped for now and will follow up after this lands. I know Evan is not a super fan of the glow, but after working with it for a week, it's way cleaner and responsive than the OS controls. Give it a try.
Test Plan: Tested many applications, forms, mobile and tablet.
Reviewers: epriestley, btrahan
Reviewed By: epriestley
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D5860
2013-05-07 23:07:06 +02:00
|
|
|
}
|
|
|
|
|
|
2014-11-07 23:16:30 +01:00
|
|
|
.phui-form-inset h1 {
|
2014-11-17 23:06:05 +01:00
|
|
|
color: {$bluetext};
|
2013-08-26 20:53:11 +02:00
|
|
|
padding-bottom: 8px;
|
2014-11-17 23:06:05 +01:00
|
|
|
margin-bottom: 8px;
|
2015-06-26 18:33:03 +02:00
|
|
|
font-size: {$biggerfontsize};
|
2014-11-17 23:06:05 +01:00
|
|
|
border-bottom: 1px solid {$thinblueborder};
|
2011-03-24 19:07:36 +01:00
|
|
|
}
|
Improve drag-and-drop uploader
Summary:
Make it discoverable, show uploading progress, show file thumbnails, allow you
to remove files, make it a generic form component.
Test Plan:
Uploaded ducks
Reviewed By: tomo
Reviewers: aran, tomo, jungejason, tuomaspelkonen
CC: anjali, aran, epriestley, tomo
Differential Revision: 334
2011-05-23 01:11:41 +02:00
|
|
|
|
|
|
|
|
.aphront-form-drag-and-drop-file-list {
|
|
|
|
|
width: 400px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.drag-and-drop-instructions {
|
2013-09-02 22:57:48 +02:00
|
|
|
color: {$darkgreytext};
|
2015-06-26 18:33:03 +02:00
|
|
|
font-size: {$smallestfontsize};
|
Improve drag-and-drop uploader
Summary:
Make it discoverable, show uploading progress, show file thumbnails, allow you
to remove files, make it a generic form component.
Test Plan:
Uploaded ducks
Reviewed By: tomo
Reviewers: aran, tomo, jungejason, tuomaspelkonen
CC: anjali, aran, epriestley, tomo
Differential Revision: 334
2011-05-23 01:11:41 +02:00
|
|
|
padding: 6px 8px;
|
|
|
|
|
}
|
2011-07-15 23:17:55 +02:00
|
|
|
|
2012-10-08 22:26:41 +02:00
|
|
|
.drag-and-drop-file-target {
|
|
|
|
|
border: 1px dashed #bfbfbf;
|
2013-08-26 20:53:11 +02:00
|
|
|
padding-top: 12px;
|
|
|
|
|
padding-bottom: 12px;
|
2012-10-08 22:26:41 +02:00
|
|
|
}
|
|
|
|
|
|
2016-11-17 01:28:41 +01:00
|
|
|
body .phui-form-view .remarkup-assist-textarea.aphront-textarea-drag-and-drop {
|
|
|
|
|
background: {$sh-greenbackground};
|
|
|
|
|
border: 1px solid {$sh-greenborder};
|
2011-07-15 23:17:55 +02:00
|
|
|
}
|
2012-04-04 21:14:10 +02:00
|
|
|
|
2013-02-06 23:03:52 +01:00
|
|
|
.aphront-form-crop .crop-box {
|
|
|
|
|
cursor: move;
|
|
|
|
|
overflow: hidden;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.aphront-form-crop .crop-box .crop-image {
|
|
|
|
|
position: relative;
|
|
|
|
|
top: 0px;
|
|
|
|
|
left: 0px;
|
|
|
|
|
}
|
|
|
|
|
|
2012-04-04 21:14:10 +02:00
|
|
|
.calendar-button {
|
Make date control include times
Summary:
See discussion in T404. Basically, the problem with date-only controls is that they may behave unpredictably in the presence of timezones. When you say "This needs to be done by Oct 23", you probably mean "Oct 23 5PM PST" or something like that, but someone in China may see the "Oct 24" and hit the deadline in good faith but be 10 hours too late. T404 has more discussion and examples. There are ways to fake this, but they get more complicated if the guy in China needs to move the date forward 24 hours.
I think the best solution to this is to not have date-only controls, and always display the time. This makes it absolutley unambiguous what something means, because the guy in the US will set "Oct 23 5PM" and the guy in China will see that accurately in local time.
The downside is that it's slightly more visual clutter and work for the user to specify things precisely, but I added some hints (start/end of day, start/end of business) that will hopefully let us pick the right default in most cases.
Test Plan:
Set some dates.
{F21956}
This has a couple of edge case issues on resize and some not-so-edge-case issues on mobile, but should be good to build T407 on without API changes.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T404, T407
Differential Revision: https://secure.phabricator.com/D3793
2012-10-23 21:00:20 +02:00
|
|
|
display: inline;
|
2014-08-16 23:55:22 +02:00
|
|
|
padding: 8px 4px;
|
Make date control include times
Summary:
See discussion in T404. Basically, the problem with date-only controls is that they may behave unpredictably in the presence of timezones. When you say "This needs to be done by Oct 23", you probably mean "Oct 23 5PM PST" or something like that, but someone in China may see the "Oct 24" and hit the deadline in good faith but be 10 hours too late. T404 has more discussion and examples. There are ways to fake this, but they get more complicated if the guy in China needs to move the date forward 24 hours.
I think the best solution to this is to not have date-only controls, and always display the time. This makes it absolutley unambiguous what something means, because the guy in the US will set "Oct 23 5PM" and the guy in China will see that accurately in local time.
The downside is that it's slightly more visual clutter and work for the user to specify things precisely, but I added some hints (start/end of day, start/end of business) that will hopefully let us pick the right default in most cases.
Test Plan:
Set some dates.
{F21956}
This has a couple of edge case issues on resize and some not-so-edge-case issues on mobile, but should be good to build T407 on without API changes.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T404, T407
Differential Revision: https://secure.phabricator.com/D3793
2012-10-23 21:00:20 +02:00
|
|
|
margin: 2px 8px 2px 2px;
|
|
|
|
|
position: relative;
|
2012-04-04 21:14:10 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.aphront-form-date-container {
|
|
|
|
|
position: relative;
|
|
|
|
|
display: inline;
|
|
|
|
|
}
|
|
|
|
|
|
Make date control include times
Summary:
See discussion in T404. Basically, the problem with date-only controls is that they may behave unpredictably in the presence of timezones. When you say "This needs to be done by Oct 23", you probably mean "Oct 23 5PM PST" or something like that, but someone in China may see the "Oct 24" and hit the deadline in good faith but be 10 hours too late. T404 has more discussion and examples. There are ways to fake this, but they get more complicated if the guy in China needs to move the date forward 24 hours.
I think the best solution to this is to not have date-only controls, and always display the time. This makes it absolutley unambiguous what something means, because the guy in the US will set "Oct 23 5PM" and the guy in China will see that accurately in local time.
The downside is that it's slightly more visual clutter and work for the user to specify things precisely, but I added some hints (start/end of day, start/end of business) that will hopefully let us pick the right default in most cases.
Test Plan:
Set some dates.
{F21956}
This has a couple of edge case issues on resize and some not-so-edge-case issues on mobile, but should be good to build T407 on without API changes.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T404, T407
Differential Revision: https://secure.phabricator.com/D3793
2012-10-23 21:00:20 +02:00
|
|
|
.aphront-form-date-container select {
|
2012-04-04 21:14:10 +02:00
|
|
|
margin: 2px;
|
Make date control include times
Summary:
See discussion in T404. Basically, the problem with date-only controls is that they may behave unpredictably in the presence of timezones. When you say "This needs to be done by Oct 23", you probably mean "Oct 23 5PM PST" or something like that, but someone in China may see the "Oct 24" and hit the deadline in good faith but be 10 hours too late. T404 has more discussion and examples. There are ways to fake this, but they get more complicated if the guy in China needs to move the date forward 24 hours.
I think the best solution to this is to not have date-only controls, and always display the time. This makes it absolutley unambiguous what something means, because the guy in the US will set "Oct 23 5PM" and the guy in China will see that accurately in local time.
The downside is that it's slightly more visual clutter and work for the user to specify things precisely, but I added some hints (start/end of day, start/end of business) that will hopefully let us pick the right default in most cases.
Test Plan:
Set some dates.
{F21956}
This has a couple of edge case issues on resize and some not-so-edge-case issues on mobile, but should be good to build T407 on without API changes.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T404, T407
Differential Revision: https://secure.phabricator.com/D3793
2012-10-23 21:00:20 +02:00
|
|
|
display: inline;
|
|
|
|
|
}
|
2013-05-31 01:19:43 +02:00
|
|
|
.aphront-form-date-container input.aphront-form-date-enabled-input {
|
|
|
|
|
width: auto;
|
|
|
|
|
display: inline;
|
|
|
|
|
margin-right: 8px;
|
|
|
|
|
font-size: 16px;
|
|
|
|
|
}
|
Make date control include times
Summary:
See discussion in T404. Basically, the problem with date-only controls is that they may behave unpredictably in the presence of timezones. When you say "This needs to be done by Oct 23", you probably mean "Oct 23 5PM PST" or something like that, but someone in China may see the "Oct 24" and hit the deadline in good faith but be 10 hours too late. T404 has more discussion and examples. There are ways to fake this, but they get more complicated if the guy in China needs to move the date forward 24 hours.
I think the best solution to this is to not have date-only controls, and always display the time. This makes it absolutley unambiguous what something means, because the guy in the US will set "Oct 23 5PM" and the guy in China will see that accurately in local time.
The downside is that it's slightly more visual clutter and work for the user to specify things precisely, but I added some hints (start/end of day, start/end of business) that will hopefully let us pick the right default in most cases.
Test Plan:
Set some dates.
{F21956}
This has a couple of edge case issues on resize and some not-so-edge-case issues on mobile, but should be good to build T407 on without API changes.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T404, T407
Differential Revision: https://secure.phabricator.com/D3793
2012-10-23 21:00:20 +02:00
|
|
|
|
2015-05-26 20:27:51 +02:00
|
|
|
.aphront-form-date-container .aphront-form-time-input-container,
|
|
|
|
|
.aphront-form-date-container .aphront-form-date-input-container {
|
Time control typeaheads.
Summary: Ref T8031, Time control typeaheads
Test Plan: Edit an event, type '3', typeahead should suggest, '3:00 AM', '3:30 AM', '3:00 PM', '3:30 PM'.
Reviewers: chad, epriestley, #blessed_reviewers
Reviewed By: epriestley, #blessed_reviewers
Subscribers: Korvin, epriestley
Maniphest Tasks: T8031
Differential Revision: https://secure.phabricator.com/D12953
2015-05-20 18:51:26 +02:00
|
|
|
position: relative;
|
|
|
|
|
display: inline-block;
|
|
|
|
|
width: 7em;
|
|
|
|
|
}
|
|
|
|
|
|
2015-05-26 20:27:51 +02:00
|
|
|
.aphront-form-date-container input.aphront-form-time-input,
|
|
|
|
|
.aphront-form-date-container input.aphront-form-date-input {
|
Make date control include times
Summary:
See discussion in T404. Basically, the problem with date-only controls is that they may behave unpredictably in the presence of timezones. When you say "This needs to be done by Oct 23", you probably mean "Oct 23 5PM PST" or something like that, but someone in China may see the "Oct 24" and hit the deadline in good faith but be 10 hours too late. T404 has more discussion and examples. There are ways to fake this, but they get more complicated if the guy in China needs to move the date forward 24 hours.
I think the best solution to this is to not have date-only controls, and always display the time. This makes it absolutley unambiguous what something means, because the guy in the US will set "Oct 23 5PM" and the guy in China will see that accurately in local time.
The downside is that it's slightly more visual clutter and work for the user to specify things precisely, but I added some hints (start/end of day, start/end of business) that will hopefully let us pick the right default in most cases.
Test Plan:
Set some dates.
{F21956}
This has a couple of edge case issues on resize and some not-so-edge-case issues on mobile, but should be good to build T407 on without API changes.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T404, T407
Differential Revision: https://secure.phabricator.com/D3793
2012-10-23 21:00:20 +02:00
|
|
|
width: 7em;
|
Time control typeaheads.
Summary: Ref T8031, Time control typeaheads
Test Plan: Edit an event, type '3', typeahead should suggest, '3:00 AM', '3:30 AM', '3:00 PM', '3:30 PM'.
Reviewers: chad, epriestley, #blessed_reviewers
Reviewed By: epriestley, #blessed_reviewers
Subscribers: Korvin, epriestley
Maniphest Tasks: T8031
Differential Revision: https://secure.phabricator.com/D12953
2015-05-20 18:51:26 +02:00
|
|
|
}
|
|
|
|
|
|
2015-05-26 20:27:51 +02:00
|
|
|
.aphront-form-time-input-container div.jx-typeahead-results a.jx-result {
|
Time control typeaheads.
Summary: Ref T8031, Time control typeaheads
Test Plan: Edit an event, type '3', typeahead should suggest, '3:00 AM', '3:30 AM', '3:00 PM', '3:30 PM'.
Reviewers: chad, epriestley, #blessed_reviewers
Reviewed By: epriestley, #blessed_reviewers
Subscribers: Korvin, epriestley
Maniphest Tasks: T8031
Differential Revision: https://secure.phabricator.com/D12953
2015-05-20 18:51:26 +02:00
|
|
|
border: none;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.phui-time-typeahead-value {
|
|
|
|
|
padding: 4px;
|
2012-04-04 21:14:10 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.fancy-datepicker {
|
|
|
|
|
position: absolute;
|
|
|
|
|
width: 240px;
|
|
|
|
|
}
|
|
|
|
|
|
2016-11-15 19:09:52 +01:00
|
|
|
.device .fancy-datepicker {
|
|
|
|
|
width: 100%;
|
|
|
|
|
}
|
|
|
|
|
|
2012-04-04 21:14:10 +02:00
|
|
|
.fancy-datepicker-core {
|
2016-11-15 19:09:52 +01:00
|
|
|
width: 240px;
|
|
|
|
|
margin: 0 auto;
|
2012-04-04 21:14:10 +02:00
|
|
|
padding: 1px;
|
2015-06-26 18:33:03 +02:00
|
|
|
font-size: {$smallerfontsize};
|
2012-04-04 21:14:10 +02:00
|
|
|
text-align: center;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.fancy-datepicker-core .month-table,
|
|
|
|
|
.fancy-datepicker-core .day-table {
|
|
|
|
|
margin: 0 auto;
|
|
|
|
|
border-collapse: separate;
|
|
|
|
|
border-spacing: 1px;
|
|
|
|
|
width: 100%;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.fancy-datepicker-core .month-table {
|
|
|
|
|
margin-bottom: 6px;
|
2015-06-26 18:33:03 +02:00
|
|
|
font-size: {$normalfontsize};
|
2014-08-16 23:55:22 +02:00
|
|
|
background-color: {$hoverblue};
|
|
|
|
|
border-radius: 2px;
|
2012-04-04 21:14:10 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.fancy-datepicker-core .month-table td.lrbutton {
|
2014-08-16 23:55:22 +02:00
|
|
|
width: 18%;
|
|
|
|
|
color: {$lightbluetext};
|
2012-04-04 21:14:10 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.fancy-datepicker-core .month-table td {
|
|
|
|
|
padding: 4px;
|
|
|
|
|
font-weight: bold;
|
2014-08-16 23:55:22 +02:00
|
|
|
color: {$bluetext};
|
2012-04-04 21:14:10 +02:00
|
|
|
}
|
|
|
|
|
|
2014-08-16 23:55:22 +02:00
|
|
|
.fancy-datepicker-core .month-table td.lrbutton:hover {
|
|
|
|
|
border-radius: 2px;
|
|
|
|
|
background: {$hoverselectedblue};
|
|
|
|
|
color: {$darkbluetext};
|
2012-04-04 21:14:10 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.fancy-datepicker-core .day-table td {
|
|
|
|
|
overflow: hidden;
|
|
|
|
|
vertical-align: center;
|
|
|
|
|
text-align: center;
|
2014-08-16 23:55:22 +02:00
|
|
|
border: 1px solid {$thinblueborder};
|
2012-04-04 21:14:10 +02:00
|
|
|
padding: 4px 0;
|
|
|
|
|
}
|
|
|
|
|
|
2014-08-16 23:55:22 +02:00
|
|
|
.fancy-datepicker .fancy-datepicker-core .day-table td.day:hover {
|
|
|
|
|
background-color: {$hoverblue};
|
|
|
|
|
border-color: {$lightblueborder};
|
|
|
|
|
}
|
|
|
|
|
|
2012-04-04 21:14:10 +02:00
|
|
|
.fancy-datepicker-core .day-table td.day-placeholder {
|
|
|
|
|
border-color: transparent;
|
|
|
|
|
background: transparent;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.fancy-datepicker-core .day-table td.weekend {
|
2014-08-16 23:55:22 +02:00
|
|
|
color: {$lightgreytext};
|
|
|
|
|
border-color: {$lightgreyborder};
|
|
|
|
|
background: {$lightgreybackground};
|
2012-04-04 21:14:10 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.fancy-datepicker-core .day-table td.day-name {
|
|
|
|
|
background: transparent;
|
|
|
|
|
border: 1px transparent;
|
|
|
|
|
vertical-align: bottom;
|
2013-09-02 17:12:18 +02:00
|
|
|
color: {$lightgreytext};
|
2012-04-04 21:14:10 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.fancy-datepicker-core .day-table td.today {
|
2014-08-16 23:55:22 +02:00
|
|
|
background: {$greybackground};
|
|
|
|
|
border-color: {$greyborder};
|
|
|
|
|
color: {$darkgreytext};
|
|
|
|
|
font-weight: bold;
|
2012-04-04 21:14:10 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.fancy-datepicker-core .day-table td.datepicker-selected {
|
2014-08-16 23:55:22 +02:00
|
|
|
background: {$lightgreen};
|
|
|
|
|
border-color: {$green};
|
|
|
|
|
color: {$green};
|
2012-04-04 21:14:10 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.fancy-datepicker-core td {
|
|
|
|
|
cursor: pointer;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.fancy-datepicker-core td.novalue {
|
|
|
|
|
cursor: inherit;
|
|
|
|
|
}
|
|
|
|
|
|
2014-08-16 23:55:22 +02:00
|
|
|
.picker-open .calendar-button .phui-icon-view {
|
|
|
|
|
color: {$sky};
|
2012-04-04 21:14:10 +02:00
|
|
|
}
|
|
|
|
|
|
2014-08-16 23:55:22 +02:00
|
|
|
.fancy-datepicker-core {
|
|
|
|
|
background-color: white;
|
2017-01-17 21:04:28 +01:00
|
|
|
border: 1px solid {$lightgreyborder};
|
2015-04-14 18:48:59 +02:00
|
|
|
box-shadow: {$dropshadow};
|
2014-08-16 23:55:22 +02:00
|
|
|
border-radius: 3px;
|
2012-04-04 21:14:10 +02:00
|
|
|
}
|
2013-03-07 22:02:36 +01:00
|
|
|
|
2015-05-04 19:08:49 +02:00
|
|
|
/* When the activation checkbox for the control is toggled off, visually
|
|
|
|
|
disable the individual controls. We don't actually use the "disabled" property
|
|
|
|
|
because we still want the values to submit. This is just a visual hint that
|
|
|
|
|
the controls won't be used. The controls themselves are still live, work
|
|
|
|
|
properly, and submit values. */
|
|
|
|
|
.datepicker-disabled select,
|
|
|
|
|
.datepicker-disabled .calendar-button,
|
|
|
|
|
.datepicker-disabled input[type="text"] {
|
|
|
|
|
opacity: 0.5;
|
|
|
|
|
}
|
|
|
|
|
|
2015-05-26 20:27:51 +02:00
|
|
|
.aphront-form-date-container.no-time .aphront-form-time-input{
|
2015-05-08 19:01:13 +02:00
|
|
|
display: none;
|
|
|
|
|
}
|
|
|
|
|
|
2013-03-07 22:02:36 +01:00
|
|
|
.login-to-comment {
|
2013-11-22 01:09:04 +01:00
|
|
|
margin: 12px;
|
2013-03-07 22:02:36 +01:00
|
|
|
}
|
2013-03-13 19:01:15 +01:00
|
|
|
|
2013-05-24 21:38:27 +02:00
|
|
|
.phui-form-divider hr {
|
|
|
|
|
height: 1px;
|
|
|
|
|
border: 0;
|
2015-04-14 18:48:59 +02:00
|
|
|
background: {$thinblueborder};
|
2013-05-24 21:38:27 +02:00
|
|
|
width: 85%;
|
|
|
|
|
margin: 15px auto;
|
|
|
|
|
}
|
Add password authentication and registration to new registration
Summary:
Ref T1536. Ref T1930. Code is not reachable.
This provides password authentication and registration on the new provider/adapter framework.
I sort of cheated a little bit and don't really route any password logic through the adapter (instead, this provider uses an empty adapter and just sets the type/domain on it). I think the right way to do this //conceptually// is to treat username/passwords as an external black box which the adapter communicates with. However, this creates a lot of practical implementation and UX problems:
- There would basically be two steps -- in the first one, you interact with the "password black box", which behaves like an OAuth provider. This produces some ExternalAccount associated with the username/password pair, then we go into normal registration.
- In normal registration, we'd proceed normally.
This means:
- The registration flow would be split into two parts, one where you select a username/password (interacting with the black box) and one where you actually register (interacting with the generic flow). This is unusual and probably confusing for users.
- We would need to do a lot of re-hashing of passwords, since passwords currently depend on the username and user PHID, which won't exist yet during registration or the "black box" phase. This is a big mess I don't want to deal with.
- We hit a weird condition where two users complete step 1 with the same username but don't complete step 2 yet. The box knows about two different copies of the username, with two different passwords. When we arrive at step 2 the second time we have a lot of bad choices about how to reoslve it, most of which create security problems. The most stragihtforward and "pure" way to resolve the issues is to put password-auth usernames in a separate space, but this would be incredibly confusuing to users (your login name might not be the same as your username, which is bizarre).
- If we change this, we need to update all the other password-related code, which I don't want to bother with (at least for now).
Instead, let registration know about a "default" registration controller (which is always password, if enabled), and let it require a password. This gives us a much simpler (albeit slightly less pure) implementation:
- All the fields are on one form.
- Password adapter is just a shell.
- Password provider does the heavy lifting.
We might make this more pure at some point, but I'm generally pretty satisfied with this.
This doesn't implement the brute-force CAPTCHA protection, that will be coming soon.
Test Plan: Registered with password only and logged in with a password. Hit various error conditions.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran, chad
Maniphest Tasks: T1536, T1930
Differential Revision: https://secure.phabricator.com/D6164
2013-06-16 19:15:49 +02:00
|
|
|
|
|
|
|
|
.recaptcha_only_if_privacy {
|
|
|
|
|
display: none;
|
|
|
|
|
}
|
2013-08-26 20:53:11 +02:00
|
|
|
|
2013-09-17 23:22:04 +02:00
|
|
|
.phabricator-standard-custom-field-header {
|
|
|
|
|
font-size: 16px;
|
|
|
|
|
color: {$bluetext};
|
|
|
|
|
border-bottom: 1px solid {$lightbluetext};
|
|
|
|
|
padding: 16px 0 4px;
|
|
|
|
|
margin-bottom: 4px;
|
|
|
|
|
}
|
2014-02-01 20:48:28 +01:00
|
|
|
|
|
|
|
|
.device-desktop .text-with-submit-control-outer-bounds {
|
|
|
|
|
position: relative;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.device-desktop .text-with-submit-control-text-bounds {
|
|
|
|
|
position: absolute;
|
|
|
|
|
left: 0;
|
|
|
|
|
right: 184px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.device-desktop .text-with-submit-control-submit-bounds {
|
|
|
|
|
text-align: right;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.device-desktop .text-with-submit-control-submit {
|
|
|
|
|
width: 180px;
|
|
|
|
|
}
|
2014-06-26 18:41:07 +02:00
|
|
|
|
2015-12-16 16:53:13 +01:00
|
|
|
.phui-form-iconset-table td {
|
2014-06-26 18:41:07 +02:00
|
|
|
vertical-align: middle;
|
|
|
|
|
padding: 4px 0;
|
|
|
|
|
}
|
|
|
|
|
|
2015-12-16 16:53:13 +01:00
|
|
|
.phui-form-iconset-table .phui-form-iconset-button-cell {
|
2014-06-26 18:41:07 +02:00
|
|
|
padding: 4px 8px;
|
|
|
|
|
}
|
2015-11-18 19:50:09 +01:00
|
|
|
|
|
|
|
|
.aphront-form-preview-hidden {
|
|
|
|
|
opacity: 0.5;
|
|
|
|
|
}
|
2015-12-23 03:07:57 +01:00
|
|
|
|
|
|
|
|
.aphront-form-error .phui-icon-view {
|
2016-11-09 19:33:05 +01:00
|
|
|
float: right;
|
2015-12-23 03:07:57 +01:00
|
|
|
color: {$lightgreyborder};
|
2016-11-09 19:33:05 +01:00
|
|
|
font-size: 20px;
|
2015-12-23 03:07:57 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.device-desktop .aphront-form-error .phui-icon-view:hover {
|
2016-11-09 19:33:05 +01:00
|
|
|
color: {$red};
|
2015-12-23 03:07:57 +01:00
|
|
|
}
|
2016-12-28 19:21:54 +01:00
|
|
|
|
|
|
|
|
.phui-form-static-action {
|
|
|
|
|
padding: 4px;
|
|
|
|
|
color: {$bluetext};
|
|
|
|
|
}
|
When accepting revisions, allow users to accept on behalf of a subset of reviewers
Summary:
Ref T12271. Currenty, when you "Accept" a revision, you always accept it for all reviewers you have authority over.
There are some situations where communication can be more clear if users can accept as only themselves, or for only some packages, etc. T12271 discusses some of these use cases in more depth.
Instead of making "Accept" a blanket action, default it to doing what it does now but let the user uncheck reviewers.
In cases where project/package reviewers aren't in use, this doesn't change anything.
For now, "reject" still acts the old way (reject everything). We could make that use checkboxes too, but I'm not sure there's as much of a use case for it, and I generally want users who are blocking stuff to have more direct accountability in a product sense.
Test Plan:
- Accepted normally.
- Accepted a subset.
- Tried to accept none.
- Tried to accept bogus reviewers.
- Accepted with myself not a reviewer
- Accepted with only one reviewer (just got normal "this will be accepted" text).
{F4251255}
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T12271
Differential Revision: https://secure.phabricator.com/D17533
2017-03-22 17:28:36 +01:00
|
|
|
|
|
|
|
|
.phuix-form-checkbox-action {
|
|
|
|
|
padding: 4px;
|
|
|
|
|
color: {$bluetext};
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.phuix-form-checkbox-action input[type=checkbox] {
|
|
|
|
|
margin: 4px 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.phuix-form-checkbox-label {
|
|
|
|
|
margin-left: 4px;
|
|
|
|
|
}
|
