woocommerce/plugins/woocommerce-blocks/assets/js/blocks/cart-checkout/payment-methods/style.scss

255 lines
5.6 KiB
SCSS
Raw Normal View History

Implement Stripe CC and Stripe ApplePay payment methods (https://github.com/woocommerce/woocommerce-blocks/pull/1983) * Server side changes for payment method integrations Including adding a stripe class temporarily * update needed npm packages (and add some types) * updates to contexts * remove stepContent from payment config for payment methods * update payment method interface and typedefs Exposing a components property to pass along components that payment methods can use (so we keep styles consistent for them) * add apple pay and stripe cc integration and remove paypal * remove save payment checkbox from checkout block It is handled by payment methods. * Include an id prop for tabs * fix activePaymentMethod pass through on rendered payment method element also adds an id for the rendered tab * add styles for payment method fields If payment methods use these classes for their fields then the styles will get applied. It _could_ allow for consistent styling, we may have to provide design documentation for this? These are styles in cases where payment methods have to use elements provided by the gateway (eg. Stripe elements). In future iterations we could look at providing components to payment methods to use (if they aren’t restricted by the gateway). * fix rebase conflict * do a test payment request for applePay to determine if the current browser supports it * don’t console.error for stripe loading. * Fix placeholder errors in the editor * improve styling and add missing validation for inline card element * update pacakge-lock * rename payment-methods-demo folder to payment-methods-extension * expose checkbox control on payment method interface * export payment-methods-extension to it’s own asset build This allows us to more accurately demonstrate how payment extensions would hook in to the blocks. * don’t enqueue a style that doesn’t exist * add full stop to comments and remove obsolete comment blcok * fix spacing * switch `activeContent` to `content` for payment method registration config
2020-03-30 12:07:49 +00:00
.wc-block-card-elements {
display: flex;
width: 100%;
.wc-block-components-validation-error {
position: static;
}
Implement Stripe CC and Stripe ApplePay payment methods (https://github.com/woocommerce/woocommerce-blocks/pull/1983) * Server side changes for payment method integrations Including adding a stripe class temporarily * update needed npm packages (and add some types) * updates to contexts * remove stepContent from payment config for payment methods * update payment method interface and typedefs Exposing a components property to pass along components that payment methods can use (so we keep styles consistent for them) * add apple pay and stripe cc integration and remove paypal * remove save payment checkbox from checkout block It is handled by payment methods. * Include an id prop for tabs * fix activePaymentMethod pass through on rendered payment method element also adds an id for the rendered tab * add styles for payment method fields If payment methods use these classes for their fields then the styles will get applied. It _could_ allow for consistent styling, we may have to provide design documentation for this? These are styles in cases where payment methods have to use elements provided by the gateway (eg. Stripe elements). In future iterations we could look at providing components to payment methods to use (if they aren’t restricted by the gateway). * fix rebase conflict * do a test payment request for applePay to determine if the current browser supports it * don’t console.error for stripe loading. * Fix placeholder errors in the editor * improve styling and add missing validation for inline card element * update pacakge-lock * rename payment-methods-demo folder to payment-methods-extension * expose checkbox control on payment method interface * export payment-methods-extension to it’s own asset build This allows us to more accurately demonstrate how payment extensions would hook in to the blocks. * don’t enqueue a style that doesn’t exist * add full stop to comments and remove obsolete comment blcok * fix spacing * switch `activeContent` to `content` for payment method registration config
2020-03-30 12:07:49 +00:00
}
.wc-block-gateway-container {
position: relative;
margin-bottom: em($gap-large);
Implement Stripe CC and Stripe ApplePay payment methods (https://github.com/woocommerce/woocommerce-blocks/pull/1983) * Server side changes for payment method integrations Including adding a stripe class temporarily * update needed npm packages (and add some types) * updates to contexts * remove stepContent from payment config for payment methods * update payment method interface and typedefs Exposing a components property to pass along components that payment methods can use (so we keep styles consistent for them) * add apple pay and stripe cc integration and remove paypal * remove save payment checkbox from checkout block It is handled by payment methods. * Include an id prop for tabs * fix activePaymentMethod pass through on rendered payment method element also adds an id for the rendered tab * add styles for payment method fields If payment methods use these classes for their fields then the styles will get applied. It _could_ allow for consistent styling, we may have to provide design documentation for this? These are styles in cases where payment methods have to use elements provided by the gateway (eg. Stripe elements). In future iterations we could look at providing components to payment methods to use (if they aren’t restricted by the gateway). * fix rebase conflict * do a test payment request for applePay to determine if the current browser supports it * don’t console.error for stripe loading. * Fix placeholder errors in the editor * improve styling and add missing validation for inline card element * update pacakge-lock * rename payment-methods-demo folder to payment-methods-extension * expose checkbox control on payment method interface * export payment-methods-extension to it’s own asset build This allows us to more accurately demonstrate how payment extensions would hook in to the blocks. * don’t enqueue a style that doesn’t exist * add full stop to comments and remove obsolete comment blcok * fix spacing * switch `activeContent` to `content` for payment method registration config
2020-03-30 12:07:49 +00:00
white-space: nowrap;
&.wc-card-number-element {
flex-basis: 15em;
flex-grow: 1;
// Currently, min() CSS function calls need to be wrapped with unquote.
min-width: unquote("min(15em, 60%)");
}
&.wc-card-expiry-element {
flex-basis: 7em;
margin-left: $gap-small;
min-width: unquote("min(7em, calc(24% - #{$gap-small}))");
Implement Stripe CC and Stripe ApplePay payment methods (https://github.com/woocommerce/woocommerce-blocks/pull/1983) * Server side changes for payment method integrations Including adding a stripe class temporarily * update needed npm packages (and add some types) * updates to contexts * remove stepContent from payment config for payment methods * update payment method interface and typedefs Exposing a components property to pass along components that payment methods can use (so we keep styles consistent for them) * add apple pay and stripe cc integration and remove paypal * remove save payment checkbox from checkout block It is handled by payment methods. * Include an id prop for tabs * fix activePaymentMethod pass through on rendered payment method element also adds an id for the rendered tab * add styles for payment method fields If payment methods use these classes for their fields then the styles will get applied. It _could_ allow for consistent styling, we may have to provide design documentation for this? These are styles in cases where payment methods have to use elements provided by the gateway (eg. Stripe elements). In future iterations we could look at providing components to payment methods to use (if they aren’t restricted by the gateway). * fix rebase conflict * do a test payment request for applePay to determine if the current browser supports it * don’t console.error for stripe loading. * Fix placeholder errors in the editor * improve styling and add missing validation for inline card element * update pacakge-lock * rename payment-methods-demo folder to payment-methods-extension * expose checkbox control on payment method interface * export payment-methods-extension to it’s own asset build This allows us to more accurately demonstrate how payment extensions would hook in to the blocks. * don’t enqueue a style that doesn’t exist * add full stop to comments and remove obsolete comment blcok * fix spacing * switch `activeContent` to `content` for payment method registration config
2020-03-30 12:07:49 +00:00
}
&.wc-card-cvc-element {
flex-basis: 7em;
Implement Stripe CC and Stripe ApplePay payment methods (https://github.com/woocommerce/woocommerce-blocks/pull/1983) * Server side changes for payment method integrations Including adding a stripe class temporarily * update needed npm packages (and add some types) * updates to contexts * remove stepContent from payment config for payment methods * update payment method interface and typedefs Exposing a components property to pass along components that payment methods can use (so we keep styles consistent for them) * add apple pay and stripe cc integration and remove paypal * remove save payment checkbox from checkout block It is handled by payment methods. * Include an id prop for tabs * fix activePaymentMethod pass through on rendered payment method element also adds an id for the rendered tab * add styles for payment method fields If payment methods use these classes for their fields then the styles will get applied. It _could_ allow for consistent styling, we may have to provide design documentation for this? These are styles in cases where payment methods have to use elements provided by the gateway (eg. Stripe elements). In future iterations we could look at providing components to payment methods to use (if they aren’t restricted by the gateway). * fix rebase conflict * do a test payment request for applePay to determine if the current browser supports it * don’t console.error for stripe loading. * Fix placeholder errors in the editor * improve styling and add missing validation for inline card element * update pacakge-lock * rename payment-methods-demo folder to payment-methods-extension * expose checkbox control on payment method interface * export payment-methods-extension to it’s own asset build This allows us to more accurately demonstrate how payment extensions would hook in to the blocks. * don’t enqueue a style that doesn’t exist * add full stop to comments and remove obsolete comment blcok * fix spacing * switch `activeContent` to `content` for payment method registration config
2020-03-30 12:07:49 +00:00
margin-left: $gap-small;
// Notice the min width ems value is smaller than flex-basis. That's because
// by default we want it to have the same width as `expiry-element`, but
// if available space is scarce, `cvc-element` should get smaller faster.
min-width: unquote("min( 5em, calc(16% - #{$gap-small}))");
Implement Stripe CC and Stripe ApplePay payment methods (https://github.com/woocommerce/woocommerce-blocks/pull/1983) * Server side changes for payment method integrations Including adding a stripe class temporarily * update needed npm packages (and add some types) * updates to contexts * remove stepContent from payment config for payment methods * update payment method interface and typedefs Exposing a components property to pass along components that payment methods can use (so we keep styles consistent for them) * add apple pay and stripe cc integration and remove paypal * remove save payment checkbox from checkout block It is handled by payment methods. * Include an id prop for tabs * fix activePaymentMethod pass through on rendered payment method element also adds an id for the rendered tab * add styles for payment method fields If payment methods use these classes for their fields then the styles will get applied. It _could_ allow for consistent styling, we may have to provide design documentation for this? These are styles in cases where payment methods have to use elements provided by the gateway (eg. Stripe elements). In future iterations we could look at providing components to payment methods to use (if they aren’t restricted by the gateway). * fix rebase conflict * do a test payment request for applePay to determine if the current browser supports it * don’t console.error for stripe loading. * Fix placeholder errors in the editor * improve styling and add missing validation for inline card element * update pacakge-lock * rename payment-methods-demo folder to payment-methods-extension * expose checkbox control on payment method interface * export payment-methods-extension to it’s own asset build This allows us to more accurately demonstrate how payment extensions would hook in to the blocks. * don’t enqueue a style that doesn’t exist * add full stop to comments and remove obsolete comment blcok * fix spacing * switch `activeContent` to `content` for payment method registration config
2020-03-30 12:07:49 +00:00
}
.wc-block-gateway-input {
@include font-size(regular);
line-height: 1.375; // =22px when font-size is 16px.
Implement Stripe CC and Stripe ApplePay payment methods (https://github.com/woocommerce/woocommerce-blocks/pull/1983) * Server side changes for payment method integrations Including adding a stripe class temporarily * update needed npm packages (and add some types) * updates to contexts * remove stepContent from payment config for payment methods * update payment method interface and typedefs Exposing a components property to pass along components that payment methods can use (so we keep styles consistent for them) * add apple pay and stripe cc integration and remove paypal * remove save payment checkbox from checkout block It is handled by payment methods. * Include an id prop for tabs * fix activePaymentMethod pass through on rendered payment method element also adds an id for the rendered tab * add styles for payment method fields If payment methods use these classes for their fields then the styles will get applied. It _could_ allow for consistent styling, we may have to provide design documentation for this? These are styles in cases where payment methods have to use elements provided by the gateway (eg. Stripe elements). In future iterations we could look at providing components to payment methods to use (if they aren’t restricted by the gateway). * fix rebase conflict * do a test payment request for applePay to determine if the current browser supports it * don’t console.error for stripe loading. * Fix placeholder errors in the editor * improve styling and add missing validation for inline card element * update pacakge-lock * rename payment-methods-demo folder to payment-methods-extension * expose checkbox control on payment method interface * export payment-methods-extension to it’s own asset build This allows us to more accurately demonstrate how payment extensions would hook in to the blocks. * don’t enqueue a style that doesn’t exist * add full stop to comments and remove obsolete comment blcok * fix spacing * switch `activeContent` to `content` for payment method registration config
2020-03-30 12:07:49 +00:00
background-color: #fff;
padding: em($gap-small) 0 em($gap-small) $gap;
Implement Stripe CC and Stripe ApplePay payment methods (https://github.com/woocommerce/woocommerce-blocks/pull/1983) * Server side changes for payment method integrations Including adding a stripe class temporarily * update needed npm packages (and add some types) * updates to contexts * remove stepContent from payment config for payment methods * update payment method interface and typedefs Exposing a components property to pass along components that payment methods can use (so we keep styles consistent for them) * add apple pay and stripe cc integration and remove paypal * remove save payment checkbox from checkout block It is handled by payment methods. * Include an id prop for tabs * fix activePaymentMethod pass through on rendered payment method element also adds an id for the rendered tab * add styles for payment method fields If payment methods use these classes for their fields then the styles will get applied. It _could_ allow for consistent styling, we may have to provide design documentation for this? These are styles in cases where payment methods have to use elements provided by the gateway (eg. Stripe elements). In future iterations we could look at providing components to payment methods to use (if they aren’t restricted by the gateway). * fix rebase conflict * do a test payment request for applePay to determine if the current browser supports it * don’t console.error for stripe loading. * Fix placeholder errors in the editor * improve styling and add missing validation for inline card element * update pacakge-lock * rename payment-methods-demo folder to payment-methods-extension * expose checkbox control on payment method interface * export payment-methods-extension to it’s own asset build This allows us to more accurately demonstrate how payment extensions would hook in to the blocks. * don’t enqueue a style that doesn’t exist * add full stop to comments and remove obsolete comment blcok * fix spacing * switch `activeContent` to `content` for payment method registration config
2020-03-30 12:07:49 +00:00
border-radius: 4px;
border: 1px solid $input-border-gray;
width: 100%;
font-family: inherit;
margin: 0;
box-sizing: border-box;
height: 3em;
Implement Stripe CC and Stripe ApplePay payment methods (https://github.com/woocommerce/woocommerce-blocks/pull/1983) * Server side changes for payment method integrations Including adding a stripe class temporarily * update needed npm packages (and add some types) * updates to contexts * remove stepContent from payment config for payment methods * update payment method interface and typedefs Exposing a components property to pass along components that payment methods can use (so we keep styles consistent for them) * add apple pay and stripe cc integration and remove paypal * remove save payment checkbox from checkout block It is handled by payment methods. * Include an id prop for tabs * fix activePaymentMethod pass through on rendered payment method element also adds an id for the rendered tab * add styles for payment method fields If payment methods use these classes for their fields then the styles will get applied. It _could_ allow for consistent styling, we may have to provide design documentation for this? These are styles in cases where payment methods have to use elements provided by the gateway (eg. Stripe elements). In future iterations we could look at providing components to payment methods to use (if they aren’t restricted by the gateway). * fix rebase conflict * do a test payment request for applePay to determine if the current browser supports it * don’t console.error for stripe loading. * Fix placeholder errors in the editor * improve styling and add missing validation for inline card element * update pacakge-lock * rename payment-methods-demo folder to payment-methods-extension * expose checkbox control on payment method interface * export payment-methods-extension to it’s own asset build This allows us to more accurately demonstrate how payment extensions would hook in to the blocks. * don’t enqueue a style that doesn’t exist * add full stop to comments and remove obsolete comment blcok * fix spacing * switch `activeContent` to `content` for payment method registration config
2020-03-30 12:07:49 +00:00
color: $input-text-active;
cursor: text;
Implement Stripe CC and Stripe ApplePay payment methods (https://github.com/woocommerce/woocommerce-blocks/pull/1983) * Server side changes for payment method integrations Including adding a stripe class temporarily * update needed npm packages (and add some types) * updates to contexts * remove stepContent from payment config for payment methods * update payment method interface and typedefs Exposing a components property to pass along components that payment methods can use (so we keep styles consistent for them) * add apple pay and stripe cc integration and remove paypal * remove save payment checkbox from checkout block It is handled by payment methods. * Include an id prop for tabs * fix activePaymentMethod pass through on rendered payment method element also adds an id for the rendered tab * add styles for payment method fields If payment methods use these classes for their fields then the styles will get applied. It _could_ allow for consistent styling, we may have to provide design documentation for this? These are styles in cases where payment methods have to use elements provided by the gateway (eg. Stripe elements). In future iterations we could look at providing components to payment methods to use (if they aren’t restricted by the gateway). * fix rebase conflict * do a test payment request for applePay to determine if the current browser supports it * don’t console.error for stripe loading. * Fix placeholder errors in the editor * improve styling and add missing validation for inline card element * update pacakge-lock * rename payment-methods-demo folder to payment-methods-extension * expose checkbox control on payment method interface * export payment-methods-extension to it’s own asset build This allows us to more accurately demonstrate how payment extensions would hook in to the blocks. * don’t enqueue a style that doesn’t exist * add full stop to comments and remove obsolete comment blcok * fix spacing * switch `activeContent` to `content` for payment method registration config
2020-03-30 12:07:49 +00:00
&:focus {
background-color: #fff;
}
}
&:focus {
background-color: #fff;
}
label {
@include reset-typography();
@include font-size(regular);
line-height: 1.375; // =22px when font-size is 16px.
Implement Stripe CC and Stripe ApplePay payment methods (https://github.com/woocommerce/woocommerce-blocks/pull/1983) * Server side changes for payment method integrations Including adding a stripe class temporarily * update needed npm packages (and add some types) * updates to contexts * remove stepContent from payment config for payment methods * update payment method interface and typedefs Exposing a components property to pass along components that payment methods can use (so we keep styles consistent for them) * add apple pay and stripe cc integration and remove paypal * remove save payment checkbox from checkout block It is handled by payment methods. * Include an id prop for tabs * fix activePaymentMethod pass through on rendered payment method element also adds an id for the rendered tab * add styles for payment method fields If payment methods use these classes for their fields then the styles will get applied. It _could_ allow for consistent styling, we may have to provide design documentation for this? These are styles in cases where payment methods have to use elements provided by the gateway (eg. Stripe elements). In future iterations we could look at providing components to payment methods to use (if they aren’t restricted by the gateway). * fix rebase conflict * do a test payment request for applePay to determine if the current browser supports it * don’t console.error for stripe loading. * Fix placeholder errors in the editor * improve styling and add missing validation for inline card element * update pacakge-lock * rename payment-methods-demo folder to payment-methods-extension * expose checkbox control on payment method interface * export payment-methods-extension to it’s own asset build This allows us to more accurately demonstrate how payment extensions would hook in to the blocks. * don’t enqueue a style that doesn’t exist * add full stop to comments and remove obsolete comment blcok * fix spacing * switch `activeContent` to `content` for payment method registration config
2020-03-30 12:07:49 +00:00
position: absolute;
transform: translateY(0.75em);
Implement Stripe CC and Stripe ApplePay payment methods (https://github.com/woocommerce/woocommerce-blocks/pull/1983) * Server side changes for payment method integrations Including adding a stripe class temporarily * update needed npm packages (and add some types) * updates to contexts * remove stepContent from payment config for payment methods * update payment method interface and typedefs Exposing a components property to pass along components that payment methods can use (so we keep styles consistent for them) * add apple pay and stripe cc integration and remove paypal * remove save payment checkbox from checkout block It is handled by payment methods. * Include an id prop for tabs * fix activePaymentMethod pass through on rendered payment method element also adds an id for the rendered tab * add styles for payment method fields If payment methods use these classes for their fields then the styles will get applied. It _could_ allow for consistent styling, we may have to provide design documentation for this? These are styles in cases where payment methods have to use elements provided by the gateway (eg. Stripe elements). In future iterations we could look at providing components to payment methods to use (if they aren’t restricted by the gateway). * fix rebase conflict * do a test payment request for applePay to determine if the current browser supports it * don’t console.error for stripe loading. * Fix placeholder errors in the editor * improve styling and add missing validation for inline card element * update pacakge-lock * rename payment-methods-demo folder to payment-methods-extension * expose checkbox control on payment method interface * export payment-methods-extension to it’s own asset build This allows us to more accurately demonstrate how payment extensions would hook in to the blocks. * don’t enqueue a style that doesn’t exist * add full stop to comments and remove obsolete comment blcok * fix spacing * switch `activeContent` to `content` for payment method registration config
2020-03-30 12:07:49 +00:00
left: 0;
top: 0;
transform-origin: top left;
color: $gray-700;
Implement Stripe CC and Stripe ApplePay payment methods (https://github.com/woocommerce/woocommerce-blocks/pull/1983) * Server side changes for payment method integrations Including adding a stripe class temporarily * update needed npm packages (and add some types) * updates to contexts * remove stepContent from payment config for payment methods * update payment method interface and typedefs Exposing a components property to pass along components that payment methods can use (so we keep styles consistent for them) * add apple pay and stripe cc integration and remove paypal * remove save payment checkbox from checkout block It is handled by payment methods. * Include an id prop for tabs * fix activePaymentMethod pass through on rendered payment method element also adds an id for the rendered tab * add styles for payment method fields If payment methods use these classes for their fields then the styles will get applied. It _could_ allow for consistent styling, we may have to provide design documentation for this? These are styles in cases where payment methods have to use elements provided by the gateway (eg. Stripe elements). In future iterations we could look at providing components to payment methods to use (if they aren’t restricted by the gateway). * fix rebase conflict * do a test payment request for applePay to determine if the current browser supports it * don’t console.error for stripe loading. * Fix placeholder errors in the editor * improve styling and add missing validation for inline card element * update pacakge-lock * rename payment-methods-demo folder to payment-methods-extension * expose checkbox control on payment method interface * export payment-methods-extension to it’s own asset build This allows us to more accurately demonstrate how payment extensions would hook in to the blocks. * don’t enqueue a style that doesn’t exist * add full stop to comments and remove obsolete comment blcok * fix spacing * switch `activeContent` to `content` for payment method registration config
2020-03-30 12:07:49 +00:00
transition: transform 200ms ease;
margin: 0 0 0 #{$gap + 1px};
Implement Stripe CC and Stripe ApplePay payment methods (https://github.com/woocommerce/woocommerce-blocks/pull/1983) * Server side changes for payment method integrations Including adding a stripe class temporarily * update needed npm packages (and add some types) * updates to contexts * remove stepContent from payment config for payment methods * update payment method interface and typedefs Exposing a components property to pass along components that payment methods can use (so we keep styles consistent for them) * add apple pay and stripe cc integration and remove paypal * remove save payment checkbox from checkout block It is handled by payment methods. * Include an id prop for tabs * fix activePaymentMethod pass through on rendered payment method element also adds an id for the rendered tab * add styles for payment method fields If payment methods use these classes for their fields then the styles will get applied. It _could_ allow for consistent styling, we may have to provide design documentation for this? These are styles in cases where payment methods have to use elements provided by the gateway (eg. Stripe elements). In future iterations we could look at providing components to payment methods to use (if they aren’t restricted by the gateway). * fix rebase conflict * do a test payment request for applePay to determine if the current browser supports it * don’t console.error for stripe loading. * Fix placeholder errors in the editor * improve styling and add missing validation for inline card element * update pacakge-lock * rename payment-methods-demo folder to payment-methods-extension * expose checkbox control on payment method interface * export payment-methods-extension to it’s own asset build This allows us to more accurately demonstrate how payment extensions would hook in to the blocks. * don’t enqueue a style that doesn’t exist * add full stop to comments and remove obsolete comment blcok * fix spacing * switch `activeContent` to `content` for payment method registration config
2020-03-30 12:07:49 +00:00
overflow: hidden;
text-overflow: ellipsis;
max-width: calc(100% - #{$gap + $gap-smaller});
cursor: text;
Implement Stripe CC and Stripe ApplePay payment methods (https://github.com/woocommerce/woocommerce-blocks/pull/1983) * Server side changes for payment method integrations Including adding a stripe class temporarily * update needed npm packages (and add some types) * updates to contexts * remove stepContent from payment config for payment methods * update payment method interface and typedefs Exposing a components property to pass along components that payment methods can use (so we keep styles consistent for them) * add apple pay and stripe cc integration and remove paypal * remove save payment checkbox from checkout block It is handled by payment methods. * Include an id prop for tabs * fix activePaymentMethod pass through on rendered payment method element also adds an id for the rendered tab * add styles for payment method fields If payment methods use these classes for their fields then the styles will get applied. It _could_ allow for consistent styling, we may have to provide design documentation for this? These are styles in cases where payment methods have to use elements provided by the gateway (eg. Stripe elements). In future iterations we could look at providing components to payment methods to use (if they aren’t restricted by the gateway). * fix rebase conflict * do a test payment request for applePay to determine if the current browser supports it * don’t console.error for stripe loading. * Fix placeholder errors in the editor * improve styling and add missing validation for inline card element * update pacakge-lock * rename payment-methods-demo folder to payment-methods-extension * expose checkbox control on payment method interface * export payment-methods-extension to it’s own asset build This allows us to more accurately demonstrate how payment extensions would hook in to the blocks. * don’t enqueue a style that doesn’t exist * add full stop to comments and remove obsolete comment blcok * fix spacing * switch `activeContent` to `content` for payment method registration config
2020-03-30 12:07:49 +00:00
@media screen and (prefers-reduced-motion: reduce) {
transition: none;
}
}
&.wc-inline-card-element {
label {
// $gap is the padding of the input box, 1.5em the width of the card
// icon and $gap-smaller the space between the card
// icon and the label.
margin-left: calc(#{$gap + $gap-smaller} + 1.5em);
Implement Stripe CC and Stripe ApplePay payment methods (https://github.com/woocommerce/woocommerce-blocks/pull/1983) * Server side changes for payment method integrations Including adding a stripe class temporarily * update needed npm packages (and add some types) * updates to contexts * remove stepContent from payment config for payment methods * update payment method interface and typedefs Exposing a components property to pass along components that payment methods can use (so we keep styles consistent for them) * add apple pay and stripe cc integration and remove paypal * remove save payment checkbox from checkout block It is handled by payment methods. * Include an id prop for tabs * fix activePaymentMethod pass through on rendered payment method element also adds an id for the rendered tab * add styles for payment method fields If payment methods use these classes for their fields then the styles will get applied. It _could_ allow for consistent styling, we may have to provide design documentation for this? These are styles in cases where payment methods have to use elements provided by the gateway (eg. Stripe elements). In future iterations we could look at providing components to payment methods to use (if they aren’t restricted by the gateway). * fix rebase conflict * do a test payment request for applePay to determine if the current browser supports it * don’t console.error for stripe loading. * Fix placeholder errors in the editor * improve styling and add missing validation for inline card element * update pacakge-lock * rename payment-methods-demo folder to payment-methods-extension * expose checkbox control on payment method interface * export payment-methods-extension to it’s own asset build This allows us to more accurately demonstrate how payment extensions would hook in to the blocks. * don’t enqueue a style that doesn’t exist * add full stop to comments and remove obsolete comment blcok * fix spacing * switch `activeContent` to `content` for payment method registration config
2020-03-30 12:07:49 +00:00
}
.wc-block-gateway-input.focused.empty,
.wc-block-gateway-input:not(.empty) {
& + label {
margin-left: $gap;
transform: translateY(#{$gap-smallest}) scale(0.75);
}
}
& + .wc-block-components-validation-error {
Implement Stripe CC and Stripe ApplePay payment methods (https://github.com/woocommerce/woocommerce-blocks/pull/1983) * Server side changes for payment method integrations Including adding a stripe class temporarily * update needed npm packages (and add some types) * updates to contexts * remove stepContent from payment config for payment methods * update payment method interface and typedefs Exposing a components property to pass along components that payment methods can use (so we keep styles consistent for them) * add apple pay and stripe cc integration and remove paypal * remove save payment checkbox from checkout block It is handled by payment methods. * Include an id prop for tabs * fix activePaymentMethod pass through on rendered payment method element also adds an id for the rendered tab * add styles for payment method fields If payment methods use these classes for their fields then the styles will get applied. It _could_ allow for consistent styling, we may have to provide design documentation for this? These are styles in cases where payment methods have to use elements provided by the gateway (eg. Stripe elements). In future iterations we could look at providing components to payment methods to use (if they aren’t restricted by the gateway). * fix rebase conflict * do a test payment request for applePay to determine if the current browser supports it * don’t console.error for stripe loading. * Fix placeholder errors in the editor * improve styling and add missing validation for inline card element * update pacakge-lock * rename payment-methods-demo folder to payment-methods-extension * expose checkbox control on payment method interface * export payment-methods-extension to it’s own asset build This allows us to more accurately demonstrate how payment extensions would hook in to the blocks. * don’t enqueue a style that doesn’t exist * add full stop to comments and remove obsolete comment blcok * fix spacing * switch `activeContent` to `content` for payment method registration config
2020-03-30 12:07:49 +00:00
position: static;
margin-top: -$gap-large;
}
}
.wc-block-gateway-input.focused.empty,
.wc-block-gateway-input:not(.empty) {
padding: em($gap-large) 0 em($gap-smallest) $gap;
Implement Stripe CC and Stripe ApplePay payment methods (https://github.com/woocommerce/woocommerce-blocks/pull/1983) * Server side changes for payment method integrations Including adding a stripe class temporarily * update needed npm packages (and add some types) * updates to contexts * remove stepContent from payment config for payment methods * update payment method interface and typedefs Exposing a components property to pass along components that payment methods can use (so we keep styles consistent for them) * add apple pay and stripe cc integration and remove paypal * remove save payment checkbox from checkout block It is handled by payment methods. * Include an id prop for tabs * fix activePaymentMethod pass through on rendered payment method element also adds an id for the rendered tab * add styles for payment method fields If payment methods use these classes for their fields then the styles will get applied. It _could_ allow for consistent styling, we may have to provide design documentation for this? These are styles in cases where payment methods have to use elements provided by the gateway (eg. Stripe elements). In future iterations we could look at providing components to payment methods to use (if they aren’t restricted by the gateway). * fix rebase conflict * do a test payment request for applePay to determine if the current browser supports it * don’t console.error for stripe loading. * Fix placeholder errors in the editor * improve styling and add missing validation for inline card element * update pacakge-lock * rename payment-methods-demo folder to payment-methods-extension * expose checkbox control on payment method interface * export payment-methods-extension to it’s own asset build This allows us to more accurately demonstrate how payment extensions would hook in to the blocks. * don’t enqueue a style that doesn’t exist * add full stop to comments and remove obsolete comment blcok * fix spacing * switch `activeContent` to `content` for payment method registration config
2020-03-30 12:07:49 +00:00
& + label {
transform: translateY(#{$gap-smallest}) scale(0.75);
}
}
.wc-block-gateway-input.has-error {
border-color: $alert-red;
Implement Stripe CC and Stripe ApplePay payment methods (https://github.com/woocommerce/woocommerce-blocks/pull/1983) * Server side changes for payment method integrations Including adding a stripe class temporarily * update needed npm packages (and add some types) * updates to contexts * remove stepContent from payment config for payment methods * update payment method interface and typedefs Exposing a components property to pass along components that payment methods can use (so we keep styles consistent for them) * add apple pay and stripe cc integration and remove paypal * remove save payment checkbox from checkout block It is handled by payment methods. * Include an id prop for tabs * fix activePaymentMethod pass through on rendered payment method element also adds an id for the rendered tab * add styles for payment method fields If payment methods use these classes for their fields then the styles will get applied. It _could_ allow for consistent styling, we may have to provide design documentation for this? These are styles in cases where payment methods have to use elements provided by the gateway (eg. Stripe elements). In future iterations we could look at providing components to payment methods to use (if they aren’t restricted by the gateway). * fix rebase conflict * do a test payment request for applePay to determine if the current browser supports it * don’t console.error for stripe loading. * Fix placeholder errors in the editor * improve styling and add missing validation for inline card element * update pacakge-lock * rename payment-methods-demo folder to payment-methods-extension * expose checkbox control on payment method interface * export payment-methods-extension to it’s own asset build This allows us to more accurately demonstrate how payment extensions would hook in to the blocks. * don’t enqueue a style that doesn’t exist * add full stop to comments and remove obsolete comment blcok * fix spacing * switch `activeContent` to `content` for payment method registration config
2020-03-30 12:07:49 +00:00
&:focus {
outline-color: $alert-red;
Implement Stripe CC and Stripe ApplePay payment methods (https://github.com/woocommerce/woocommerce-blocks/pull/1983) * Server side changes for payment method integrations Including adding a stripe class temporarily * update needed npm packages (and add some types) * updates to contexts * remove stepContent from payment config for payment methods * update payment method interface and typedefs Exposing a components property to pass along components that payment methods can use (so we keep styles consistent for them) * add apple pay and stripe cc integration and remove paypal * remove save payment checkbox from checkout block It is handled by payment methods. * Include an id prop for tabs * fix activePaymentMethod pass through on rendered payment method element also adds an id for the rendered tab * add styles for payment method fields If payment methods use these classes for their fields then the styles will get applied. It _could_ allow for consistent styling, we may have to provide design documentation for this? These are styles in cases where payment methods have to use elements provided by the gateway (eg. Stripe elements). In future iterations we could look at providing components to payment methods to use (if they aren’t restricted by the gateway). * fix rebase conflict * do a test payment request for applePay to determine if the current browser supports it * don’t console.error for stripe loading. * Fix placeholder errors in the editor * improve styling and add missing validation for inline card element * update pacakge-lock * rename payment-methods-demo folder to payment-methods-extension * expose checkbox control on payment method interface * export payment-methods-extension to it’s own asset build This allows us to more accurately demonstrate how payment extensions would hook in to the blocks. * don’t enqueue a style that doesn’t exist * add full stop to comments and remove obsolete comment blcok * fix spacing * switch `activeContent` to `content` for payment method registration config
2020-03-30 12:07:49 +00:00
}
}
.wc-block-gateway-input.has-error + label {
color: $alert-red;
Implement Stripe CC and Stripe ApplePay payment methods (https://github.com/woocommerce/woocommerce-blocks/pull/1983) * Server side changes for payment method integrations Including adding a stripe class temporarily * update needed npm packages (and add some types) * updates to contexts * remove stepContent from payment config for payment methods * update payment method interface and typedefs Exposing a components property to pass along components that payment methods can use (so we keep styles consistent for them) * add apple pay and stripe cc integration and remove paypal * remove save payment checkbox from checkout block It is handled by payment methods. * Include an id prop for tabs * fix activePaymentMethod pass through on rendered payment method element also adds an id for the rendered tab * add styles for payment method fields If payment methods use these classes for their fields then the styles will get applied. It _could_ allow for consistent styling, we may have to provide design documentation for this? These are styles in cases where payment methods have to use elements provided by the gateway (eg. Stripe elements). In future iterations we could look at providing components to payment methods to use (if they aren’t restricted by the gateway). * fix rebase conflict * do a test payment request for applePay to determine if the current browser supports it * don’t console.error for stripe loading. * Fix placeholder errors in the editor * improve styling and add missing validation for inline card element * update pacakge-lock * rename payment-methods-demo folder to payment-methods-extension * expose checkbox control on payment method interface * export payment-methods-extension to it’s own asset build This allows us to more accurately demonstrate how payment extensions would hook in to the blocks. * don’t enqueue a style that doesn’t exist * add full stop to comments and remove obsolete comment blcok * fix spacing * switch `activeContent` to `content` for payment method registration config
2020-03-30 12:07:49 +00:00
}
}
// These elements have available space below, so we can display errors with a
// larger line height.
.is-medium,
.is-large {
.wc-card-expiry-element,
.wc-card-cvc-element {
.wc-block-components-validation-error > p {
line-height: 16px;
padding-top: 4px;
}
}
}
.is-mobile,
.is-small {
.wc-card-expiry-element,
.wc-card-cvc-element {
.wc-block-components-validation-error > p {
min-height: 28px;
}
}
}
.wc-block-components-checkout-payment-methods * {
pointer-events: all; // Overrides parent disabled component in editor context
}
.is-mobile,
.is-small {
.wc-block-card-elements {
flex-wrap: wrap;
}
.wc-block-gateway-container.wc-card-number-element {
flex-basis: 100%;
}
.wc-block-gateway-container.wc-card-expiry-element {
flex-basis: calc(50% - #{$gap-smaller});
margin-left: 0;
margin-right: $gap-smaller;
}
.wc-block-gateway-container.wc-card-cvc-element {
flex-basis: calc(50% - #{$gap-smaller});
margin-left: $gap-smaller;
}
}
Update checkout payment methods design. (https://github.com/woocommerce/woocommerce-blocks/pull/3439) * Add left vertical bar to payments methods step. * Remove horizontal borders around order notes. * Add class to order notes component. We need it to traget that element with CSS. * Update padding on order notes checkbox to match desing. * Remove full stop to match the design. * Add label for not saved payment methods option. * Remove use new payment radio. * Always show new ayment methods selector * Remove editor context for now. * Add accordion component skeleton. * Small component refactor. * Use accordion for new payment options. * Fix jsdoc. * Add styling. * Add input styling. * Hide label if we don't have saved methods. * Cleanup. * Cleanup and styling. * Add target class to aid with alignment. * Update use new payments label styling. * Update Place Order button location. * add full stop to payment method copy * ensure that there is always a (default) selected payment method: - using `activePaymentMethod` from context - this ensures there is a default selected on initial render - and handles any dynamic changes to available payment methods - e.g. COD disappearing when change shipping option - remove unused / redundant selectedMethod prop - context is best * use tab-based payment UI for 2 or fewer payment methods: - move saved payment state to payment context; it's shared state needed by both PaymentMethodOptions and SavedPaymentMethodOptions - show previous tabs UI if: - customer has no saved payment methods (cards) - store has 2 or fewer payment methods available - when initialising SavedPaymentMethodOptions, only select one if the user hasn't selected a real payment method - this ensures radio buttons switch correctly between saved card => `Use another` - remove various props and local state that is no longer required (🤞🏻) * experimental - styling tweaks for single payment tab (remove "tab" UI) * Revert "experimental - styling tweaks for single payment tab (remove "tab" UI)" This reverts commit e09dd4862b97d989d950a9d67672d83e7b8992e4. * Add single payment method UI. * Adjust single method styling. * Add outline and margin to two methods version. * Fix gap for order notes on/off option. * Update Order button spacing CSS. * Reuse computed values. * Remove tabs and single payment option. * We no longer need this test as the UI was changed. * Fix payment methods labels height. * Simplify. * Remove not needed import. * Typecheck an option. * Refactor code. * Rename. * Rename. * Update typdefs. * Remove border for add order notes. * Correct spacing for radio-button and label. * Add simple test. Switch to payment method. * Update style. Co-authored-by: Rua Haszard <rua.haszard@automattic.com> Co-authored-by: Darren Ethier <darren@roughsmootheng.in>
2021-02-02 04:51:47 +00:00
.wc-block-checkout__payment-method {
.wc-block-components-radio-control__option {
padding-left: 56px;
Update checkout payment methods design. (https://github.com/woocommerce/woocommerce-blocks/pull/3439) * Add left vertical bar to payments methods step. * Remove horizontal borders around order notes. * Add class to order notes component. We need it to traget that element with CSS. * Update padding on order notes checkbox to match desing. * Remove full stop to match the design. * Add label for not saved payment methods option. * Remove use new payment radio. * Always show new ayment methods selector * Remove editor context for now. * Add accordion component skeleton. * Small component refactor. * Use accordion for new payment options. * Fix jsdoc. * Add styling. * Add input styling. * Hide label if we don't have saved methods. * Cleanup. * Cleanup and styling. * Add target class to aid with alignment. * Update use new payments label styling. * Update Place Order button location. * add full stop to payment method copy * ensure that there is always a (default) selected payment method: - using `activePaymentMethod` from context - this ensures there is a default selected on initial render - and handles any dynamic changes to available payment methods - e.g. COD disappearing when change shipping option - remove unused / redundant selectedMethod prop - context is best * use tab-based payment UI for 2 or fewer payment methods: - move saved payment state to payment context; it's shared state needed by both PaymentMethodOptions and SavedPaymentMethodOptions - show previous tabs UI if: - customer has no saved payment methods (cards) - store has 2 or fewer payment methods available - when initialising SavedPaymentMethodOptions, only select one if the user hasn't selected a real payment method - this ensures radio buttons switch correctly between saved card => `Use another` - remove various props and local state that is no longer required (🤞🏻) * experimental - styling tweaks for single payment tab (remove "tab" UI) * Revert "experimental - styling tweaks for single payment tab (remove "tab" UI)" This reverts commit e09dd4862b97d989d950a9d67672d83e7b8992e4. * Add single payment method UI. * Adjust single method styling. * Add outline and margin to two methods version. * Fix gap for order notes on/off option. * Update Order button spacing CSS. * Reuse computed values. * Remove tabs and single payment option. * We no longer need this test as the UI was changed. * Fix payment methods labels height. * Simplify. * Remove not needed import. * Typecheck an option. * Refactor code. * Rename. * Rename. * Update typdefs. * Remove border for add order notes. * Correct spacing for radio-button and label. * Add simple test. Switch to payment method. * Update style. Co-authored-by: Rua Haszard <rua.haszard@automattic.com> Co-authored-by: Darren Ethier <darren@roughsmootheng.in>
2021-02-02 04:51:47 +00:00
&::after {
content: none;
}
.wc-block-components-radio-control__input {
left: 16px;
}
}
// We need to add the first-child and last-child pseudoclasses for specificity.
.wc-block-components-radio-control__option,
.wc-block-components-radio-control__option:first-child,
.wc-block-components-radio-control__option:last-child {
margin: 0;
padding-bottom: em($gap);
padding-top: em($gap);
}
.wc-block-components-radio-control__option-checked {
font-weight: bold;
}
Update checkout payment methods design. (https://github.com/woocommerce/woocommerce-blocks/pull/3439) * Add left vertical bar to payments methods step. * Remove horizontal borders around order notes. * Add class to order notes component. We need it to traget that element with CSS. * Update padding on order notes checkbox to match desing. * Remove full stop to match the design. * Add label for not saved payment methods option. * Remove use new payment radio. * Always show new ayment methods selector * Remove editor context for now. * Add accordion component skeleton. * Small component refactor. * Use accordion for new payment options. * Fix jsdoc. * Add styling. * Add input styling. * Hide label if we don't have saved methods. * Cleanup. * Cleanup and styling. * Add target class to aid with alignment. * Update use new payments label styling. * Update Place Order button location. * add full stop to payment method copy * ensure that there is always a (default) selected payment method: - using `activePaymentMethod` from context - this ensures there is a default selected on initial render - and handles any dynamic changes to available payment methods - e.g. COD disappearing when change shipping option - remove unused / redundant selectedMethod prop - context is best * use tab-based payment UI for 2 or fewer payment methods: - move saved payment state to payment context; it's shared state needed by both PaymentMethodOptions and SavedPaymentMethodOptions - show previous tabs UI if: - customer has no saved payment methods (cards) - store has 2 or fewer payment methods available - when initialising SavedPaymentMethodOptions, only select one if the user hasn't selected a real payment method - this ensures radio buttons switch correctly between saved card => `Use another` - remove various props and local state that is no longer required (🤞🏻) * experimental - styling tweaks for single payment tab (remove "tab" UI) * Revert "experimental - styling tweaks for single payment tab (remove "tab" UI)" This reverts commit e09dd4862b97d989d950a9d67672d83e7b8992e4. * Add single payment method UI. * Adjust single method styling. * Add outline and margin to two methods version. * Fix gap for order notes on/off option. * Update Order button spacing CSS. * Reuse computed values. * Remove tabs and single payment option. * We no longer need this test as the UI was changed. * Fix payment methods labels height. * Simplify. * Remove not needed import. * Typecheck an option. * Refactor code. * Rename. * Rename. * Update typdefs. * Remove border for add order notes. * Correct spacing for radio-button and label. * Add simple test. Switch to payment method. * Update style. Co-authored-by: Rua Haszard <rua.haszard@automattic.com> Co-authored-by: Darren Ethier <darren@roughsmootheng.in>
2021-02-02 04:51:47 +00:00
.wc-block-components-radio-control-accordion-option,
.wc-block-components-radio-control__option {
@include with-translucent-border(1px 1px 0 1px);
}
.wc-block-components-radio-control__option:last-child::after,
.wc-block-components-radio-control-accordion-option:last-child::after {
border-width: 1px;
Update checkout payment methods design. (https://github.com/woocommerce/woocommerce-blocks/pull/3439) * Add left vertical bar to payments methods step. * Remove horizontal borders around order notes. * Add class to order notes component. We need it to traget that element with CSS. * Update padding on order notes checkbox to match desing. * Remove full stop to match the design. * Add label for not saved payment methods option. * Remove use new payment radio. * Always show new ayment methods selector * Remove editor context for now. * Add accordion component skeleton. * Small component refactor. * Use accordion for new payment options. * Fix jsdoc. * Add styling. * Add input styling. * Hide label if we don't have saved methods. * Cleanup. * Cleanup and styling. * Add target class to aid with alignment. * Update use new payments label styling. * Update Place Order button location. * add full stop to payment method copy * ensure that there is always a (default) selected payment method: - using `activePaymentMethod` from context - this ensures there is a default selected on initial render - and handles any dynamic changes to available payment methods - e.g. COD disappearing when change shipping option - remove unused / redundant selectedMethod prop - context is best * use tab-based payment UI for 2 or fewer payment methods: - move saved payment state to payment context; it's shared state needed by both PaymentMethodOptions and SavedPaymentMethodOptions - show previous tabs UI if: - customer has no saved payment methods (cards) - store has 2 or fewer payment methods available - when initialising SavedPaymentMethodOptions, only select one if the user hasn't selected a real payment method - this ensures radio buttons switch correctly between saved card => `Use another` - remove various props and local state that is no longer required (🤞🏻) * experimental - styling tweaks for single payment tab (remove "tab" UI) * Revert "experimental - styling tweaks for single payment tab (remove "tab" UI)" This reverts commit e09dd4862b97d989d950a9d67672d83e7b8992e4. * Add single payment method UI. * Adjust single method styling. * Add outline and margin to two methods version. * Fix gap for order notes on/off option. * Update Order button spacing CSS. * Reuse computed values. * Remove tabs and single payment option. * We no longer need this test as the UI was changed. * Fix payment methods labels height. * Simplify. * Remove not needed import. * Typecheck an option. * Refactor code. * Rename. * Rename. * Update typdefs. * Remove border for add order notes. * Correct spacing for radio-button and label. * Add simple test. Switch to payment method. * Update style. Co-authored-by: Rua Haszard <rua.haszard@automattic.com> Co-authored-by: Darren Ethier <darren@roughsmootheng.in>
2021-02-02 04:51:47 +00:00
}
.wc-block-components-radio-control-accordion-option {
.wc-block-components-radio-control__option::after {
Update checkout payment methods design. (https://github.com/woocommerce/woocommerce-blocks/pull/3439) * Add left vertical bar to payments methods step. * Remove horizontal borders around order notes. * Add class to order notes component. We need it to traget that element with CSS. * Update padding on order notes checkbox to match desing. * Remove full stop to match the design. * Add label for not saved payment methods option. * Remove use new payment radio. * Always show new ayment methods selector * Remove editor context for now. * Add accordion component skeleton. * Small component refactor. * Use accordion for new payment options. * Fix jsdoc. * Add styling. * Add input styling. * Hide label if we don't have saved methods. * Cleanup. * Cleanup and styling. * Add target class to aid with alignment. * Update use new payments label styling. * Update Place Order button location. * add full stop to payment method copy * ensure that there is always a (default) selected payment method: - using `activePaymentMethod` from context - this ensures there is a default selected on initial render - and handles any dynamic changes to available payment methods - e.g. COD disappearing when change shipping option - remove unused / redundant selectedMethod prop - context is best * use tab-based payment UI for 2 or fewer payment methods: - move saved payment state to payment context; it's shared state needed by both PaymentMethodOptions and SavedPaymentMethodOptions - show previous tabs UI if: - customer has no saved payment methods (cards) - store has 2 or fewer payment methods available - when initialising SavedPaymentMethodOptions, only select one if the user hasn't selected a real payment method - this ensures radio buttons switch correctly between saved card => `Use another` - remove various props and local state that is no longer required (🤞🏻) * experimental - styling tweaks for single payment tab (remove "tab" UI) * Revert "experimental - styling tweaks for single payment tab (remove "tab" UI)" This reverts commit e09dd4862b97d989d950a9d67672d83e7b8992e4. * Add single payment method UI. * Adjust single method styling. * Add outline and margin to two methods version. * Fix gap for order notes on/off option. * Update Order button spacing CSS. * Reuse computed values. * Remove tabs and single payment option. * We no longer need this test as the UI was changed. * Fix payment methods labels height. * Simplify. * Remove not needed import. * Typecheck an option. * Refactor code. * Rename. * Rename. * Update typdefs. * Remove border for add order notes. * Correct spacing for radio-button and label. * Add simple test. Switch to payment method. * Update style. Co-authored-by: Rua Haszard <rua.haszard@automattic.com> Co-authored-by: Darren Ethier <darren@roughsmootheng.in>
2021-02-02 04:51:47 +00:00
border-width: 0;
}
.wc-block-components-radio-control__label {
display: flex;
align-items: center;
justify-content: flex-start;
}
Update checkout payment methods design. (https://github.com/woocommerce/woocommerce-blocks/pull/3439) * Add left vertical bar to payments methods step. * Remove horizontal borders around order notes. * Add class to order notes component. We need it to traget that element with CSS. * Update padding on order notes checkbox to match desing. * Remove full stop to match the design. * Add label for not saved payment methods option. * Remove use new payment radio. * Always show new ayment methods selector * Remove editor context for now. * Add accordion component skeleton. * Small component refactor. * Use accordion for new payment options. * Fix jsdoc. * Add styling. * Add input styling. * Hide label if we don't have saved methods. * Cleanup. * Cleanup and styling. * Add target class to aid with alignment. * Update use new payments label styling. * Update Place Order button location. * add full stop to payment method copy * ensure that there is always a (default) selected payment method: - using `activePaymentMethod` from context - this ensures there is a default selected on initial render - and handles any dynamic changes to available payment methods - e.g. COD disappearing when change shipping option - remove unused / redundant selectedMethod prop - context is best * use tab-based payment UI for 2 or fewer payment methods: - move saved payment state to payment context; it's shared state needed by both PaymentMethodOptions and SavedPaymentMethodOptions - show previous tabs UI if: - customer has no saved payment methods (cards) - store has 2 or fewer payment methods available - when initialising SavedPaymentMethodOptions, only select one if the user hasn't selected a real payment method - this ensures radio buttons switch correctly between saved card => `Use another` - remove various props and local state that is no longer required (🤞🏻) * experimental - styling tweaks for single payment tab (remove "tab" UI) * Revert "experimental - styling tweaks for single payment tab (remove "tab" UI)" This reverts commit e09dd4862b97d989d950a9d67672d83e7b8992e4. * Add single payment method UI. * Adjust single method styling. * Add outline and margin to two methods version. * Fix gap for order notes on/off option. * Update Order button spacing CSS. * Reuse computed values. * Remove tabs and single payment option. * We no longer need this test as the UI was changed. * Fix payment methods labels height. * Simplify. * Remove not needed import. * Typecheck an option. * Refactor code. * Rename. * Rename. * Update typdefs. * Remove border for add order notes. * Correct spacing for radio-button and label. * Add simple test. Switch to payment method. * Update style. Co-authored-by: Rua Haszard <rua.haszard@automattic.com> Co-authored-by: Darren Ethier <darren@roughsmootheng.in>
2021-02-02 04:51:47 +00:00
.wc-block-components-radio-control__label img {
height: 24px;
max-height: 24px;
object-fit: contain;
object-position: left;
Update checkout payment methods design. (https://github.com/woocommerce/woocommerce-blocks/pull/3439) * Add left vertical bar to payments methods step. * Remove horizontal borders around order notes. * Add class to order notes component. We need it to traget that element with CSS. * Update padding on order notes checkbox to match desing. * Remove full stop to match the design. * Add label for not saved payment methods option. * Remove use new payment radio. * Always show new ayment methods selector * Remove editor context for now. * Add accordion component skeleton. * Small component refactor. * Use accordion for new payment options. * Fix jsdoc. * Add styling. * Add input styling. * Hide label if we don't have saved methods. * Cleanup. * Cleanup and styling. * Add target class to aid with alignment. * Update use new payments label styling. * Update Place Order button location. * add full stop to payment method copy * ensure that there is always a (default) selected payment method: - using `activePaymentMethod` from context - this ensures there is a default selected on initial render - and handles any dynamic changes to available payment methods - e.g. COD disappearing when change shipping option - remove unused / redundant selectedMethod prop - context is best * use tab-based payment UI for 2 or fewer payment methods: - move saved payment state to payment context; it's shared state needed by both PaymentMethodOptions and SavedPaymentMethodOptions - show previous tabs UI if: - customer has no saved payment methods (cards) - store has 2 or fewer payment methods available - when initialising SavedPaymentMethodOptions, only select one if the user hasn't selected a real payment method - this ensures radio buttons switch correctly between saved card => `Use another` - remove various props and local state that is no longer required (🤞🏻) * experimental - styling tweaks for single payment tab (remove "tab" UI) * Revert "experimental - styling tweaks for single payment tab (remove "tab" UI)" This reverts commit e09dd4862b97d989d950a9d67672d83e7b8992e4. * Add single payment method UI. * Adjust single method styling. * Add outline and margin to two methods version. * Fix gap for order notes on/off option. * Update Order button spacing CSS. * Reuse computed values. * Remove tabs and single payment option. * We no longer need this test as the UI was changed. * Fix payment methods labels height. * Simplify. * Remove not needed import. * Typecheck an option. * Refactor code. * Rename. * Rename. * Update typdefs. * Remove border for add order notes. * Correct spacing for radio-button and label. * Add simple test. Switch to payment method. * Update style. Co-authored-by: Rua Haszard <rua.haszard@automattic.com> Co-authored-by: Darren Ethier <darren@roughsmootheng.in>
2021-02-02 04:51:47 +00:00
}
}
.wc-block-components-radio-control.disable-radio-control {
.wc-block-components-radio-control__option {
padding-left: 16px;
}
.wc-block-components-radio-control__input {
display: none;
}
}
.wc-block-components-checkout-step__description-payments-aligned {
padding-top: 14px;
height: 28px;
}
}
.wc-block-components-radio-control-accordion-content {
padding: 0 $gap em($gap) $gap;
&:empty {
display: none;
}
Update checkout payment methods design. (https://github.com/woocommerce/woocommerce-blocks/pull/3439) * Add left vertical bar to payments methods step. * Remove horizontal borders around order notes. * Add class to order notes component. We need it to traget that element with CSS. * Update padding on order notes checkbox to match desing. * Remove full stop to match the design. * Add label for not saved payment methods option. * Remove use new payment radio. * Always show new ayment methods selector * Remove editor context for now. * Add accordion component skeleton. * Small component refactor. * Use accordion for new payment options. * Fix jsdoc. * Add styling. * Add input styling. * Hide label if we don't have saved methods. * Cleanup. * Cleanup and styling. * Add target class to aid with alignment. * Update use new payments label styling. * Update Place Order button location. * add full stop to payment method copy * ensure that there is always a (default) selected payment method: - using `activePaymentMethod` from context - this ensures there is a default selected on initial render - and handles any dynamic changes to available payment methods - e.g. COD disappearing when change shipping option - remove unused / redundant selectedMethod prop - context is best * use tab-based payment UI for 2 or fewer payment methods: - move saved payment state to payment context; it's shared state needed by both PaymentMethodOptions and SavedPaymentMethodOptions - show previous tabs UI if: - customer has no saved payment methods (cards) - store has 2 or fewer payment methods available - when initialising SavedPaymentMethodOptions, only select one if the user hasn't selected a real payment method - this ensures radio buttons switch correctly between saved card => `Use another` - remove various props and local state that is no longer required (🤞🏻) * experimental - styling tweaks for single payment tab (remove "tab" UI) * Revert "experimental - styling tweaks for single payment tab (remove "tab" UI)" This reverts commit e09dd4862b97d989d950a9d67672d83e7b8992e4. * Add single payment method UI. * Adjust single method styling. * Add outline and margin to two methods version. * Fix gap for order notes on/off option. * Update Order button spacing CSS. * Reuse computed values. * Remove tabs and single payment option. * We no longer need this test as the UI was changed. * Fix payment methods labels height. * Simplify. * Remove not needed import. * Typecheck an option. * Refactor code. * Rename. * Rename. * Update typdefs. * Remove border for add order notes. * Correct spacing for radio-button and label. * Add simple test. Switch to payment method. * Update style. Co-authored-by: Rua Haszard <rua.haszard@automattic.com> Co-authored-by: Darren Ethier <darren@roughsmootheng.in>
2021-02-02 04:51:47 +00:00
}
.wc-block-checkout__order-notes {
.wc-block-components-checkout-step__content {
padding-bottom: 0;
}
}