2016-12-14 20:35:51 +01:00
|
|
|
/**
|
|
|
|
|
* @provides phui-oi-big-ui-css
|
|
|
|
|
* @requires phui-oi-list-view-css
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
.phui-oi-list-big ul.phui-oi-list-view {
|
|
|
|
|
margin: 0;
|
|
|
|
|
padding: 20px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.phui-oi-list-big .phui-oi-no-bar .phui-oi-frame {
|
|
|
|
|
border: 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.phui-oi-list-big .phui-oi-image-icon {
|
2019-03-01 16:13:16 +01:00
|
|
|
margin: 12px 2px 12px;
|
|
|
|
|
text-align: center;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.phui-oi-list-big .phui-oi-image-icon .phui-icon-view {
|
|
|
|
|
position: relative;
|
2016-12-14 20:35:51 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.phui-oi-list-big a.phui-oi-link {
|
2017-07-17 20:08:17 +02:00
|
|
|
color: {$blacktext};
|
2016-12-14 20:35:51 +01:00
|
|
|
font-size: {$biggestfontsize};
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.phui-oi-list-big .phui-oi-name {
|
|
|
|
|
padding-top: 6px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.phui-oi-list-big .phui-oi-launch-button a.button {
|
|
|
|
|
font-size: {$normalfontsize};
|
|
|
|
|
padding: 3px 12px 4px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.device-desktop .phui-oi-list-big .phui-oi {
|
2019-03-01 16:13:16 +01:00
|
|
|
margin-bottom: 8px;
|
2016-12-14 20:35:51 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.phui-oi-list-big .phui-oi-col0 {
|
|
|
|
|
vertical-align: top;
|
|
|
|
|
padding: 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.phui-oi-list-big .phui-oi-status-icon {
|
|
|
|
|
padding: 5px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.phui-oi-list-big .phui-oi-visited a.phui-oi-link {
|
|
|
|
|
color: {$violet};
|
|
|
|
|
}
|
2017-09-06 00:21:12 +02:00
|
|
|
|
|
|
|
|
.phui-box-white-config .phui-oi-list-big.phui-oi-list-view {
|
|
|
|
|
padding: 8px 8px 4px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.phui-box-white-config .phui-oi-frame {
|
|
|
|
|
padding: 4px 8px 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.device-desktop .phui-box-white-config .phui-oi:hover .phui-oi-frame {
|
|
|
|
|
background-color: {$hoverblue};
|
|
|
|
|
border-radius: 3px;
|
|
|
|
|
}
|
Replace the "Choose Subtype" radio buttons dialog with a simpler "big stuff you click" sort of UI
Summary:
Ref T13222. Fixes T12588. See PHI683. In several cases, we present the user with a choice between multiple major options: Alamnac service types, Drydock blueprint types, Repository VCS types, Herald rule types, etc.
Today, we generally do this with radio buttons and a "Submit" button. This isn't terrible, but often it means users have to click twice (once on the radio; once on submit) when a single click would be sufficient. The radio click target can also be small.
In other cases, we have a container with a link and we'd like to link the entire container: notifications, the `/drydock/` console, etc. We'd like to just link the entire container, but this causes some problems:
- It's not legal to link block eleements like `<a><div> ... </div></a>` and some browsers actually get upset about it.
- We can `<a><span> ... </span></a>` instead, then turn the `<span>` into a block element with CSS -- and this sometimes works, but also has some drawbacks:
- It's not great to do that for screenreaders, since the readable text in the link isn't necessarily very meaningful.
- We can't have any other links inside the element (e.g., details or documentation).
- We can `<form><button> ... </button></form>` instead, but this has its own set of problems:
- You can't right-click to interact with a button in the same way you can with a link.
- Also not great for screenreaders.
Instead, try adding a `linked-container` behavior which just means "when users click this element, pretend they clicked the first link inside it".
This gives us natural HTML (real, legal HTML with actual `<a>` tags) and good screenreader behavior, but allows the effective link target to be visually larger than just the link.
If no issues crop up with this, I'd plan to eventually use this technique in more places (Repositories, Herald, Almanac, Drydock, Notifications menu, etc).
Test Plan:
{F6053035}
- Left-clicked and command-left-clicked the new JS fanciness, got sensible behaviors.
Reviewers: amckinley
Reviewed By: amckinley
Subscribers: PHID-OPKG-gm6ozazyms6q6i22gyam
Maniphest Tasks: T13222, T12588
Differential Revision: https://secure.phabricator.com/D19855
2018-12-07 15:04:07 +01:00
|
|
|
|
2019-03-01 16:13:16 +01:00
|
|
|
.phui-oi-list-big .phui-oi-frame {
|
|
|
|
|
padding: 2px 8px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.phui-oi-list-big .phui-oi-linked-container {
|
|
|
|
|
border: 1px solid {$lightblueborder};
|
|
|
|
|
border-radius: 4px;
|
|
|
|
|
box-shadow: 1px 1px 2px rgba(0, 0, 0, 0.035);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.phui-oi-list-big .phui-oi-disabled {
|
|
|
|
|
border-radius: 4px;
|
|
|
|
|
background: {$lightgreybackground};
|
|
|
|
|
}
|
|
|
|
|
|
Replace the "Choose Subtype" radio buttons dialog with a simpler "big stuff you click" sort of UI
Summary:
Ref T13222. Fixes T12588. See PHI683. In several cases, we present the user with a choice between multiple major options: Alamnac service types, Drydock blueprint types, Repository VCS types, Herald rule types, etc.
Today, we generally do this with radio buttons and a "Submit" button. This isn't terrible, but often it means users have to click twice (once on the radio; once on submit) when a single click would be sufficient. The radio click target can also be small.
In other cases, we have a container with a link and we'd like to link the entire container: notifications, the `/drydock/` console, etc. We'd like to just link the entire container, but this causes some problems:
- It's not legal to link block eleements like `<a><div> ... </div></a>` and some browsers actually get upset about it.
- We can `<a><span> ... </span></a>` instead, then turn the `<span>` into a block element with CSS -- and this sometimes works, but also has some drawbacks:
- It's not great to do that for screenreaders, since the readable text in the link isn't necessarily very meaningful.
- We can't have any other links inside the element (e.g., details or documentation).
- We can `<form><button> ... </button></form>` instead, but this has its own set of problems:
- You can't right-click to interact with a button in the same way you can with a link.
- Also not great for screenreaders.
Instead, try adding a `linked-container` behavior which just means "when users click this element, pretend they clicked the first link inside it".
This gives us natural HTML (real, legal HTML with actual `<a>` tags) and good screenreader behavior, but allows the effective link target to be visually larger than just the link.
If no issues crop up with this, I'd plan to eventually use this technique in more places (Repositories, Herald, Almanac, Drydock, Notifications menu, etc).
Test Plan:
{F6053035}
- Left-clicked and command-left-clicked the new JS fanciness, got sensible behaviors.
Reviewers: amckinley
Reviewed By: amckinley
Subscribers: PHID-OPKG-gm6ozazyms6q6i22gyam
Maniphest Tasks: T13222, T12588
Differential Revision: https://secure.phabricator.com/D19855
2018-12-07 15:04:07 +01:00
|
|
|
.device-desktop .phui-oi-linked-container {
|
|
|
|
|
cursor: pointer;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.device-desktop .phui-oi-linked-container:hover {
|
|
|
|
|
background-color: {$hoverblue};
|
2019-03-01 16:13:16 +01:00
|
|
|
border-color: {$blueborder};
|
Replace the "Choose Subtype" radio buttons dialog with a simpler "big stuff you click" sort of UI
Summary:
Ref T13222. Fixes T12588. See PHI683. In several cases, we present the user with a choice between multiple major options: Alamnac service types, Drydock blueprint types, Repository VCS types, Herald rule types, etc.
Today, we generally do this with radio buttons and a "Submit" button. This isn't terrible, but often it means users have to click twice (once on the radio; once on submit) when a single click would be sufficient. The radio click target can also be small.
In other cases, we have a container with a link and we'd like to link the entire container: notifications, the `/drydock/` console, etc. We'd like to just link the entire container, but this causes some problems:
- It's not legal to link block eleements like `<a><div> ... </div></a>` and some browsers actually get upset about it.
- We can `<a><span> ... </span></a>` instead, then turn the `<span>` into a block element with CSS -- and this sometimes works, but also has some drawbacks:
- It's not great to do that for screenreaders, since the readable text in the link isn't necessarily very meaningful.
- We can't have any other links inside the element (e.g., details or documentation).
- We can `<form><button> ... </button></form>` instead, but this has its own set of problems:
- You can't right-click to interact with a button in the same way you can with a link.
- Also not great for screenreaders.
Instead, try adding a `linked-container` behavior which just means "when users click this element, pretend they clicked the first link inside it".
This gives us natural HTML (real, legal HTML with actual `<a>` tags) and good screenreader behavior, but allows the effective link target to be visually larger than just the link.
If no issues crop up with this, I'd plan to eventually use this technique in more places (Repositories, Herald, Almanac, Drydock, Notifications menu, etc).
Test Plan:
{F6053035}
- Left-clicked and command-left-clicked the new JS fanciness, got sensible behaviors.
Reviewers: amckinley
Reviewed By: amckinley
Subscribers: PHID-OPKG-gm6ozazyms6q6i22gyam
Maniphest Tasks: T13222, T12588
Differential Revision: https://secure.phabricator.com/D19855
2018-12-07 15:04:07 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.device-desktop .phui-oi-linked-container a:hover {
|
|
|
|
|
text-decoration: none;
|
|
|
|
|
}
|
2019-01-23 15:49:55 +01:00
|
|
|
|
|
|
|
|
/* Spacing for InfoView inside an object item list, like MFA setup. */
|
|
|
|
|
.phui-oi .phui-info-view {
|
|
|
|
|
margin: 0 4px 4px;
|
|
|
|
|
}
|
