Mailspring/static/components/contenteditable.less

166 lines
4.2 KiB
Plaintext
Raw Normal View History

@import "ui-variables";
.contenteditable-container {
flex: 1;
display: flex;
line-height: 1.4;
position: relative;
color: @text-color;
font-size: @font-size;
refactor(signatures): Removed old signature imgs and made static empty signatures page Summary: Refactored signature preferences page to allow more signatures than the previous 1-1 mapping for signatures and accounts. Created a multi select dropdown of the accounts for which a certain signature is set as default for. Added a button into the draft header From field to toggle between saved signatures. refactor(signatures): Add basic add/remove capabilities to static refactor(signatures): Hooked up signature actions and signature store for basic functionality fix(signatures): Cleaned up signature store and started on multiselectdropdown fix(signatures): Add multi signature toggle select to multiselect dropdown build(signatures): Built framework for multiselect dropdown build(signatures): Toggle button functionality for dropdown build(signatures): Build multi select from components and add debounce refactor(signatures): Move signature actions and signature store into flux fix(signatures): Styled composer signatures button/dropdown and fixed preferences checkmarks build(signatures): Finish main functionality, about to refactor composer signature button into injected component fix(signatures): Changed position styles fix(signatures): Fixed background color for dropdown button when blurred build(signatures): Began to write tests for signatures store, preferences and dropdown Test Plan: Wrote tests for preferences signatures, signature store, signature composer dropdown and refactored tests for signature composer extension. For signature composer extension I removed applyTransformsToDraft and unapplyTransformsToDraft and tested by sending emails with signatures to different providers to make sure the <signature> tag caused problems. Reviewers: bengotow, juan Reviewed By: juan Differential Revision: https://phab.nylas.com/D3073
2016-07-12 03:28:37 +08:00
padding-bottom: 15px;
div[contenteditable], .contenteditable {
flex: 1;
refactor(toolbar): allow toolbar extensions in contenteditable Summary: This is a refactor of the toolbar in the contenteditable. Goals of this are: 1. Allow developers to add new buttons to the toolbar 2. Allow developers to add other component types to the floating toolbar (like the LinkEditor) 3. Make the toolbar declaratively defined instead of imperatively set 4. Separate out logical units of the toolbar into individual sections 5. Clean up `innerState` of the Contenteditable The Floating Toolbar used to be an imperative mess. Doing simple functionality additions required re-understanding a very complex set of logic to hide and show the toolbar and delecately manage focus states. There also was no real capacity for any developer to extend the toolbar. It also used to be completely outside of our `atomicEdit` system and was a legacy of having raw access to contenteditable controls (since it all used to be directly inside of the contenteditable) Finally it was difficult to declaratively define things because the `innerState` of the Contenteditable was inconsistently used and its lifecycle not properly thought through. This fixed several lifecycle bugs with that. Along the way several of the DOMUtils methods were also subtly not functional and fixed. The Toolbar is now broken apart into separate logical units. There are now `ContentedtiableExtension`s that declare what should be displayed in the toolbar at any given moment. They define a method called `toolbarComponentData`. This is a pure function of the state of the `Contenteditable`. If selection and content conditions look correct, then that method will return a component to render. This is how we declaratively define whether a toolbar should be visible or not instead of manually setting `hide` & `show` bits. There is also a `toolbarButtons` method that declaratively defines buttons that can go in the new `<ToolbarButtons>` component. The `ToolbarButtonManager` takes care of extracting these and binding the correct editorAPI context. Now the `<LinkEditor>` is a separate component from the `<ToolbarButtons>` instead of being smashed together. The `LinkManager` takes care of declaring when the `LinkEditor` should be displayed and has properly bound methods to update the `contenteditable` through the standard `atomicEdit` interface. If users have additional contenteditable popup plugins (like displaying extra info on a name or some content in the composer), they can now implement the `toolbarComponentData` api and declaratively define that information based on the state of the contenteditable. Test Plan: TODO Reviewers: bengotow, juan Reviewed By: bengotow Differential Revision: https://phab.nylas.com/D2442
2016-01-21 06:35:20 +08:00
// Subtle: overflow is required to make the composer wrap
// instead of scroll when you type a very long "word" / url.
overflow-x: hidden;
refactor(toolbar): allow toolbar extensions in contenteditable Summary: This is a refactor of the toolbar in the contenteditable. Goals of this are: 1. Allow developers to add new buttons to the toolbar 2. Allow developers to add other component types to the floating toolbar (like the LinkEditor) 3. Make the toolbar declaratively defined instead of imperatively set 4. Separate out logical units of the toolbar into individual sections 5. Clean up `innerState` of the Contenteditable The Floating Toolbar used to be an imperative mess. Doing simple functionality additions required re-understanding a very complex set of logic to hide and show the toolbar and delecately manage focus states. There also was no real capacity for any developer to extend the toolbar. It also used to be completely outside of our `atomicEdit` system and was a legacy of having raw access to contenteditable controls (since it all used to be directly inside of the contenteditable) Finally it was difficult to declaratively define things because the `innerState` of the Contenteditable was inconsistently used and its lifecycle not properly thought through. This fixed several lifecycle bugs with that. Along the way several of the DOMUtils methods were also subtly not functional and fixed. The Toolbar is now broken apart into separate logical units. There are now `ContentedtiableExtension`s that declare what should be displayed in the toolbar at any given moment. They define a method called `toolbarComponentData`. This is a pure function of the state of the `Contenteditable`. If selection and content conditions look correct, then that method will return a component to render. This is how we declaratively define whether a toolbar should be visible or not instead of manually setting `hide` & `show` bits. There is also a `toolbarButtons` method that declaratively defines buttons that can go in the new `<ToolbarButtons>` component. The `ToolbarButtonManager` takes care of extracting these and binding the correct editorAPI context. Now the `<LinkEditor>` is a separate component from the `<ToolbarButtons>` instead of being smashed together. The `LinkManager` takes care of declaring when the `LinkEditor` should be displayed and has properly bound methods to update the `contenteditable` through the standard `atomicEdit` interface. If users have additional contenteditable popup plugins (like displaying extra info on a name or some content in the composer), they can now implement the `toolbarComponentData` api and declaratively define that information based on the state of the contenteditable. Test Plan: TODO Reviewers: bengotow, juan Reviewed By: bengotow Differential Revision: https://phab.nylas.com/D2442
2016-01-21 06:35:20 +08:00
a:hover {
cursor: text;
}
}
img.emoji {
-webkit-user-drag: none;
}
spelling.misspelled {
background: linear-gradient(45deg, transparent, transparent 49%, red 49%, transparent 51%);
background-size: 2px 2px;
background-position: bottom;
background-repeat-y: no-repeat;
}
.floating-toolbar {
z-index: 10;
position: absolute;
background: #fff;
box-shadow: 0 10px 20px rgba(0,0,0,0.19), inset 0 0 1px rgba(0,0,0,0.5);
border-radius: @border-radius-large;
color: @text-color;
transition-duration: .15s;
transition-property: opacity, margin;
refactor(toolbar): allow toolbar extensions in contenteditable Summary: This is a refactor of the toolbar in the contenteditable. Goals of this are: 1. Allow developers to add new buttons to the toolbar 2. Allow developers to add other component types to the floating toolbar (like the LinkEditor) 3. Make the toolbar declaratively defined instead of imperatively set 4. Separate out logical units of the toolbar into individual sections 5. Clean up `innerState` of the Contenteditable The Floating Toolbar used to be an imperative mess. Doing simple functionality additions required re-understanding a very complex set of logic to hide and show the toolbar and delecately manage focus states. There also was no real capacity for any developer to extend the toolbar. It also used to be completely outside of our `atomicEdit` system and was a legacy of having raw access to contenteditable controls (since it all used to be directly inside of the contenteditable) Finally it was difficult to declaratively define things because the `innerState` of the Contenteditable was inconsistently used and its lifecycle not properly thought through. This fixed several lifecycle bugs with that. Along the way several of the DOMUtils methods were also subtly not functional and fixed. The Toolbar is now broken apart into separate logical units. There are now `ContentedtiableExtension`s that declare what should be displayed in the toolbar at any given moment. They define a method called `toolbarComponentData`. This is a pure function of the state of the `Contenteditable`. If selection and content conditions look correct, then that method will return a component to render. This is how we declaratively define whether a toolbar should be visible or not instead of manually setting `hide` & `show` bits. There is also a `toolbarButtons` method that declaratively defines buttons that can go in the new `<ToolbarButtons>` component. The `ToolbarButtonManager` takes care of extracting these and binding the correct editorAPI context. Now the `<LinkEditor>` is a separate component from the `<ToolbarButtons>` instead of being smashed together. The `LinkManager` takes care of declaring when the `LinkEditor` should be displayed and has properly bound methods to update the `contenteditable` through the standard `atomicEdit` interface. If users have additional contenteditable popup plugins (like displaying extra info on a name or some content in the composer), they can now implement the `toolbarComponentData` api and declaratively define that information based on the state of the contenteditable. Test Plan: TODO Reviewers: bengotow, juan Reviewed By: bengotow Differential Revision: https://phab.nylas.com/D2442
2016-01-21 06:35:20 +08:00
margin-top: 0;
&.toolbar-visible {
opacity: 1;
visibility: visible;
margin-top: 0;
}
.toolbar-pointer-container {
position: absolute;
width: 23px;
height: 10px;
div {
-webkit-mask-image: url('images/tooltip/tooltip-bg-pointer@2x.png');
background-color: #fff;
position: absolute;
zoom: 0.5;
width: 45px;
height: 20px;
&.shadow {
-webkit-mask-image: url('images/tooltip/tooltip-bg-pointer-shadow@2x.png');
background-color: fade(@black, 22%);
transform: translateY(0.5px);
}
}
}
&.above {
.toolbar-pointer-container {
transform: translateX(-11px) rotate(0deg);
bottom: -9px;
}
}
&.below {
.toolbar-pointer-container {
transform: translateX(-11px) rotate(180deg);
top: -9px;
}
}
.floating-toolbar-input {
border: 0;
display: inline;
color: @text-color;
&:focus {
border: 0;
box-shadow: 0 0 0;
}
}
@padding: 0.5em;
.btn {
background: transparent;
font-size: 16px;
height: auto;
border-radius: 0;
padding: @padding*0.25 @padding;
margin: 0;
color: @text-color;
box-shadow: none;
&:first-child {
padding-left: 1.5*@padding;
}
&:last-child {
padding-right: 1.5*@padding;
}
&:hover, &:active {
color: lighten(@text-color-link, 10%);
background: transparent;
}
}
.preview-btn-icon {
position: relative;
top: 1px;
padding: 0 @padding*0.25 0 @padding*1.5;
}
button.btn.toolbar-btn {
@padding-top: 4px;
@padding-left: 8px;
width: 12.5px + 2*@padding-left;
height: 12.5px + 2*@padding-top;
margin: 7.5px 0;
box-shadow: none;
border: 0;
border-right: 1px solid @border-color-divider;
&:last-child { border-right: 0 }
background: no-repeat;
background-size: 12.5px 12.5px;
background-position: @padding-left @padding-top;
&.btn-bold { background-image: url("images/composer/tooltip-bold-black@2x.png") }
&.btn-italic { background-image: url("images/composer/tooltip-italic-black@2x.png") }
&.btn-underline { background-image: url("images/composer/tooltip-underline-black@2x.png") }
&.btn-link { background-image: url("images/composer/tooltip-link-black@2x.png") }
&:hover {
cursor: pointer;
background: no-repeat;
background-size: 12.5px 12.5px;
background-position: @padding-left @padding-top;
&.btn-bold { background-image: url("images/composer/tooltip-bold-blue@2x.png") }
&.btn-italic { background-image: url("images/composer/tooltip-italic-blue@2x.png") }
&.btn-underline { background-image: url("images/composer/tooltip-underline-blue@2x.png") }
&.btn-link { background-image: url("images/composer/tooltip-link-blue@2x.png") }
}
}
}
}
body.platform-win32 {
.contenteditable-container {
.floating-toolbar {
border-radius: 0;
input, input:focus {
box-shadow: none;
}
}
}
}