Maybe we can steal the method from T128301: Audit unused CSS rules and redundant vendor prefixes to look for any CSS that isn't used?
Description
Description
Related Objects
Related Objects
- Mentioned In
- T158494: Figure out which parts of OOjs UI documentation should be improved, and where they should live
- Mentioned Here
- T162425: Evaluate usage of `-webkit-linear-gradient` for icon backgrounds
T127281: Link to jsduck docs somewhere in OOUI demos
T128301: Audit unused CSS rules and redundant vendor prefixes
Event Timeline
Comment Actions
Not completely sure what a 'fully demoing OOUI' would mean.
We are currently using the demo not only to show all available widgets, but also contrived cases to test certain functionality. We should decide what the purpose of the demo should be, and split to different demos if required. A demo could have…
- …all the widgets with a few config changes to highlight functionality, in a particular order
- …whatever widgets, in whatever order we need to make sure the library is functioning properly
- …few and very specific widgets (with T127281: Link to jsduck docs somewhere in OOUI demos) to get users acquainted and started with the library.
Comment Actions
@Jdforrester-WMF I'm also confused by the title. When there's new functionality implemented, it's also resembled in the demos, at least for the last couple of versions (more than a year) that I've been closely following the development. Should this be a Tracking-Neverending bug?
Comment Actions
I've done this on the different demo sections with UnCSS locally, the results are very modest.
Over the last months I've repeatedly removed unnecessary/obsolete rules (in MediaWiki), I can say for sure that there's not much left that would justify the effort of an automated test with all states and different dependencies. Majority of our CSS size (all of the following before gzipping) is due to our naming conventions, our modular approach to CSS (code repetition), which results in not sharing same properties across rules, huge selectors (ex: .oo-ui-buttonElement-framed.oo-ui-widget-enabled.oo-ui-flaggedElement-progressive.oo-ui-buttonElement-pressed > .oo-ui-buttonElement-button, and not (fully) using the power of cascade.
Interesting for a few KBs in the future will be removing vendor prefixes, f.e. -webkit-linear-gradient, still necessary for Android up to 4.3, Safari 6 and Chrome 25. That could be on our list for the next 12-18 months and squeezes a serious bit. We've got PNG fallbacks, so we are not completely loosing the interface abilities.
Comment Actions
@Volker_E, I am either unable to understand what you're saying, or you've commented on and closed the wrong task. Could you please clarify?
Comment Actions
@Prtksxna The task description is referring to T128301, which is about using CSS rules audit (there: Chrome Dev Tools' Web Page Performance Audit) on finding unused CSS. I've already accomplished a similar way by using UnCSS locally (see https://gerrit.wikimedia.org/r/#/c/328541/) and also deep diving into most of our elements and widgets and removing unnecessary, obsolete selectors and properties.
From my conviction after a year of cleaning up and streamlining OOjs UI CSS is that we're fine on this specific issue.
Comment Actions
@Volker_E I now understand and agree with you. I am very confused about the relation between the title and the description of the task though. @Jdforrester-WMF, could you clarify?