Change Details

==== Background information The apps currently have complex checks for [[ https://github.com/wikimedia/wikimedia-page-library/blob/master/src/transform/ThemeTransform.js#L39-L102 | very specific parts of templates ]] that need to be excluded from theming. This is not a tenable long term solution. These templates will likely change and new templates with the same problem will be added in the future. The existing check that was upstreamed into mobile-html was the most expensive part of generating the page and would have only gotten more expensive as more exclusions were added. This expensive check was removed as it was one of the main causes of T229286. ==== What - Have a CSS class that can be used by editors to exclude certain items from theming. I’m proposing `notheme` as it matches the existing `nomobile`. - Provide a way for editors to provide theme-specific CSS to their templates through TemplateStyles - Have the mobile-html endpoint add `notheme` to elements and their children that have an inline `backrground` style ==== How - [DONE] [[ https://github.com/wikimedia/wikimedia-page-library/pull/255 | Update the page library ]] - [DONE] [[ https://gerrit.wikimedia.org/r/c/mediawiki/services/mobileapps/+/544854 | Remove the expensive check from the mobileapps service ]] - [DONE] Create a [[ https://apps.wmflabs.org/en.wikipedia.org/v1/page/mobile-html/Pantone?t=d | working prototype ]] of mobile-html that adds `notheme` to elements with an inline background style. Site, title, and theme (t=d,t=s,t=d) can be changed to evaluate the results. This leaves more elements unthemed but fixes the examples that were excluded by the expensive check. - Comment on the talk page of the templates we were manually excluding encouraging them to adopt template styles or add the `notheme` class to the appropriate elements. Provide a link to this ticket, a screenshot of the issue, and a link to a copy of the template in userspace with the changes made already. ==== Open questions Are there any better alternative solutions? Open to other suggestions While the prototype does solve the named examples in a performant manner: {F30878638} {F30878639} {F30878640} It leaves additional items unthemed: {F30878648} {F30878650} Are we OK with this tradeoff while we work with template editors to make the necessary changes to fit in with themeing? The alternative is to over-theme and break the appearance of templates until they're updated to be excluded from theme-ing. That would look like this until templates are fixed: {F30878683} {F30878707} {F30878689} {F30878695} {F30878697}

==== Background information The apps currently have complex checks for [[ https://github.com/wikimedia/wikimedia-page-library/blob/master/src/transform/ThemeTransform.js#L39-L102 | very specific parts of templates ]] that need to be excluded from theming. This is not a tenable long term solution. These templates will likely change and new templates with the same problem will be added in the future. The existing check that was upstreamed into mobile-html was the most expensive part of generating the page and would have only gotten more expensive as more exclusions were added. This expensive check was removed as it was one of the main causes of T229286. ==== What - Have a CSS class that can be used by editors to exclude certain items from theming. I’m proposing `notheme` as it matches the existing `nomobile`. - Provide a way for editors to provide theme-specific CSS to their templates through TemplateStyles - Have the mobile-html endpoint add `notheme` to elements and their children that have an inline `backrground` style ==== How - [DONE] [[ https://github.com/wikimedia/wikimedia-page-library/pull/255 | Update the page library ]] - [DONE] [[ https://gerrit.wikimedia.org/r/c/mediawiki/services/mobileapps/+/544854 | Remove the expensive check from the mobileapps service ]] - [DONE] Create a [[ https://apps.wmflabs.org/en.wikipedia.org/v1/page/mobile-html/Pantone?t=d | working prototype ]] of mobile-html that adds `notheme` to elements with an inline background style. Site, title, and theme (t=d,t=s,t=d) can be changed to evaluate the results. This leaves more elements unthemed but fixes the examples that were excluded by the expensive check. - Comment on the talk page of the templates we were manually excluding encouraging them to adopt template styles or add the `notheme` class to the appropriate elements. Provide a link to this ticket, a screenshot of the issue, and a link to a copy of the template in userspace with the changes made already. ==== Open questions Are there any better alternative solutions? Open to other suggestions While the prototype does solve the named examples in a performant manner: {F30878638} {F30878639} {F30878640} It leaves additional items unthemed: {F30878648} {F30878650} Are we OK with this tradeoff while we work with template editors to make the necessary changes to fit in with themeing? The alternative is to over-theme and break the appearance of templates until they're updated to be excluded from theme-ing. That would look like this until templates are fixed: {F30878683} {F30878707} {F30878689} {F30878695} {F30878697} No matter the tradeoff we pick, some templates will still be broken until they are updated. This is obviously a very limited set of test cases. It might be helpful to generate a list of popular articles or templates across multiple languages and examine the output of different options.

==== Background information The apps currently have complex checks for [[ https://github.com/wikimedia/wikimedia-page-library/blob/master/src/transform/ThemeTransform.js#L39-L102 | very specific parts of templates ]] that need to be excluded from theming. This is not a tenable long term solution. These templates will likely change and new templates with the same problem will be added in the future. The existing check that was upstreamed into mobile-html was the most expensive part of generating the page and would have only gotten more expensive as more exclusions were added. This expensive check was removed as it was one of the main causes of T229286. ==== What - Have a CSS class that can be used by editors to exclude certain items from theming. I’m proposing `notheme` as it matches the existing `nomobile`. - Provide a way for editors to provide theme-specific CSS to their templates through TemplateStyles - Have the mobile-html endpoint add `notheme` to elements and their children that have an inline `backrground` style ==== How - [DONE] [[ https://github.com/wikimedia/wikimedia-page-library/pull/255 | Update the page library ]] - [DONE] [[ https://gerrit.wikimedia.org/r/c/mediawiki/services/mobileapps/+/544854 | Remove the expensive check from the mobileapps service ]] - [DONE] Create a [[ https://apps.wmflabs.org/en.wikipedia.org/v1/page/mobile-html/Pantone?t=d | working prototype ]] of mobile-html that adds `notheme` to elements with an inline background style. Site, title, and theme (t=d,t=s,t=d) can be changed to evaluate the results. This leaves more elements unthemed but fixes the examples that were excluded by the expensive check. - Comment on the talk page of the templates we were manually excluding encouraging them to adopt template styles or add the `notheme` class to the appropriate elements. Provide a link to this ticket, a screenshot of the issue, and a link to a copy of the template in userspace with the changes made already. ==== Open questions Are there any better alternative solutions? Open to other suggestions While the prototype does solve the named examples in a performant manner: {F30878638} {F30878639} {F30878640} It leaves additional items unthemed: {F30878648} {F30878650} Are we OK with this tradeoff while we work with template editors to make the necessary changes to fit in with themeing? The alternative is to over-theme and break the appearance of templates until they're updated to be excluded from theme-ing. That would look like this until templates are fixed: {F30878683} {F30878707} {F30878689} {F30878695} {F30878697} No matter the tradeoff we pick, some templates will still be broken until they are updated. This is obviously a very limited set of test cases. It might be helpful to generate a list of popular articles or templates across multiple languages and examine the output of different options.