{"action":"opened","issue":{"url":"https://api.github.com/repos/google/material-design-lite/issues/4456","repository_url":"https://api.github.com/repos/google/material-design-lite","labels_url":"https://api.github.com/repos/google/material-design-lite/issues/4456/labels{/name}","comments_url":"https://api.github.com/repos/google/material-design-lite/issues/4456/comments","events_url":"https://api.github.com/repos/google/material-design-lite/issues/4456/events","html_url":"https://github.com/google/material-design-lite/issues/4456","id":162482256,"number":4456,"title":"MDL v2 Theming Strategy","user":{"login":"traviskaufman","id":1185269,"avatar_url":"https://avatars.githubusercontent.com/u/1185269?v=3","gravatar_id":"","url":"https://api.github.com/users/traviskaufman","html_url":"https://github.com/traviskaufman","followers_url":"https://api.github.com/users/traviskaufman/followers","following_url":"https://api.github.com/users/traviskaufman/following{/other_user}","gists_url":"https://api.github.com/users/traviskaufman/gists{/gist_id}","starred_url":"https://api.github.com/users/traviskaufman/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/traviskaufman/subscriptions","organizations_url":"https://api.github.com/users/traviskaufman/orgs","repos_url":"https://api.github.com/users/traviskaufman/repos","events_url":"https://api.github.com/users/traviskaufman/events{/privacy}","received_events_url":"https://api.github.com/users/traviskaufman/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/google/material-design-lite/labels/2.0%20Big%20Themes","name":"2.0 Big Themes","color":"0052cc"},{"url":"https://api.github.com/repos/google/material-design-lite/labels/research","name":"research","color":"eb6420"}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2016-06-27T15:37:09Z","updated_at":"2016-06-27T15:37:09Z","closed_at":null,"body":"> Continued discussion from #4447 \r\n\r\n> For MDL v2 we have to figure out a strategy for theming that's maintainable, easy to use by developers, and future-forward such that frameworks using newer technologies such as CSS Variables can support it.\r\n\r\n> Original issue comment from @sgomes\r\n\r\n#### Maintainability\r\n\r\nOne aspect is maintainability. How do we determine which properties should live in the base file or the theme file? Should we e.g. move all colour properties to the theme file? How about size properties? Also, is this something we do manually, or through some tool?\r\n\r\n#### Customising the primary and the accent\r\n\r\nI suspect that the simplest level of customisation that users will want to do is simply to change the primary and accent colours for their site. This actually translates into a few more colours, but we can select those automatically:\r\n- A contrast colour for text on top of the primary colour. This is either 66% black or 100% white, and can be calculated with a colour contrast formula.\r\n- A contrast colour for text on top of the accent colour. This is either 66% black or 100% white, and can be calculated with a colour contrast formula.\r\n- A \"dark primary\" colour, used in certain places. This is a darker version of the primary colour, and can also be calculated by e.g. using the 700 colour of the primary palette (assuming a Material colour), or simply by blending a certain amount of black into the primary.\r\n- A contrast colour for text on top of the \"dark primary\" colour. Same as the other contrast colours.\r\n\r\nOur current [customizer](https://getmdl.io/customize/index.html) allows for downloading a custom CSS file with the entire set of MDL styles, using a particular set of colours. The theme file approach would allow us to instead provide add-on theme files, which would override the default colours.\r\n\r\nHowever, how would this play with the modularisation effort? Would we have:\r\n- A single theme file that overrides the colours for every component, regardless of which components you're actually using? May cause some size concerns.\r\n- A theme file per component? Would require extra effort from developers simply to override the defaults, and the number of individual files we need to keep on our CDN (and potentially the number of npm packages we maintain) would massively increase.\r\n\r\n#### Deep integration with frameworks and end-user code\r\n\r\nThe final aspect we need to consider is how we can have deep theming integration both with npm and with the frameworks we expect to use our code as a base:\r\n- How could we make it easy to choose a theme through npm, if the user is using the plain compiled CSS?\r\n- How could we make it easy to choose a theme through npm, if the user is running our sources through the preprocessor (SASS or PostCSS, depending on what we end up choosing)? This one seems easier to me, as it should simply be a case of overriding a few variables.\r\n- How could we allow a framework that uses CSS variables to easily style component instances individually (with e.g. `--primary-color`, `--accent-color`, etc.)?\r\n\r\nNone of these questions need to be answered on this PR, but they're interesting topics to have on the back of our minds; it may help to have some sense of the direction we're going to take early on, since it could translate into constraints on tool and architecture decisions."}}
{"actor":{"display_login":"traviskaufman"}}