You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As discovered in ampproject/amp-wp#3712 we need an extensible theming approach to allow other parties to re-skin the editor with different colors, fonts, etc.
We need some kind of theming approach, that will allow this in a way, that doesn't create too much work for us.
The overall idea is:
Use styled-components or emotion (still undecided as of ampproject/amp-wp#3712) to style core components.
Add sensible class names to relevant components, document what these class names represent and how they can be used for theming.
We can go about this in two way:
Create the default theme using our internal styling method (CSS-in-JS) as done in WordPress/gutenberg#17963) and simply document how others can use the classes to alter the default theme. We can then potentially create alternative themes using this method later.
Use no theming in our internal styling method (CSS-in-JS) and create the default theme using the same means, that we would expose to others as the primary way of creating a theme. We can then use this default theme to create alternative themes later.
The former runs the risk of us not remembering to expose all relevant parts of the codebase and not documenting this properly. The latter comes with the extra work required to do double-styling - both in CSS-in-JS for functionality and layout and secondarily in a CSS file for look and feel.
The difference between the two approaches is also the need to define what constitutes "the theme". If we want to split our own CSS in "functionality" and "theme" (approach 2), we'll continually run into the problem of having to choose which CSS properties go where - does the button padding belong to functionality or theme? What about the margin? And so forth. For approach 1, that is not an issue.
Do not alter or remove anything below. The following sections will be managed by moderators only.
Acceptance criteria
AC1: Select and document our theming approach.
AC2: Figure out where and how we document how to create themes.
AC3: If necessary, create the default theme using this approach.
Implementation brief
QA testing instructions
Demo
Changelog entry
The text was updated successfully, but these errors were encountered:
Feature description
As discovered in ampproject/amp-wp#3712 we need an extensible theming approach to allow other parties to re-skin the editor with different colors, fonts, etc.
We need some kind of theming approach, that will allow this in a way, that doesn't create too much work for us.
The overall idea is:
styled-components
oremotion
(still undecided as of ampproject/amp-wp#3712) to style core components.We can go about this in two way:
The former runs the risk of us not remembering to expose all relevant parts of the codebase and not documenting this properly. The latter comes with the extra work required to do double-styling - both in CSS-in-JS for functionality and layout and secondarily in a CSS file for look and feel.
The difference between the two approaches is also the need to define what constitutes "the theme". If we want to split our own CSS in "functionality" and "theme" (approach 2), we'll continually run into the problem of having to choose which CSS properties go where - does the button padding belong to functionality or theme? What about the margin? And so forth. For approach 1, that is not an issue.
Do not alter or remove anything below. The following sections will be managed by moderators only.
Acceptance criteria
Implementation brief
QA testing instructions
Demo
Changelog entry
The text was updated successfully, but these errors were encountered: