jquery.uls
jquery.uls copied to clipboard
Prefixed 'uls-' to all classes and IDs
jQuery.uls code consists of very generic class-names and IDs such as 'search', 'row' etc. I am working to port jquery.ime and jquery.uls to browser extensions. Since the extensions would inject CSS in the webpage and would also modify the webpage's DOM, having such generic class-names and IDs might produce some unexpected results. So I have prefixed all classes and IDs with 'uls-'.
we need to live the grid system untouched
In that case I'll revert all the changes made to grid css. But it might result in some unexpected layout when the parent webpage is also having similar classes.
There's no reason to use ID's at all, they're evil.
Also why does the grid css need to be untouched? Any un-namespaced CSS is a bad idea.
The grid system we use is foundation grid. http://foundation.zurb.com/grid.html. It is an upstream css. We define it as an RL module and use in Translate, MW ULS. That is the reason for not modifying grid css.
Just because it's upstream code doesn't mean we should use it unmodified. Classes as generic as "row" and "grid" need to be prefixed, maybe with 'zurb-' or 'foundation-' if not 'uls-'.
Also looking at that library it seems to have a fairly concerning rule containing a '*' selector:
.grid * {
-webkit-box-sizing: border-box;
-moz-box-sizing: border-box;
box-sizing: border-box;
}
If you placed anything inside a grid layout that assumed the default content-box sizing model this rule would break it.
Interesting. Border box based box-sizing is the core of percentage based responsive grid systems. Infact, foundation grid restrict it to .grid class. Look at how Bootstrap defines it
* {
-webkit-box-sizing: border-box;
-moz-box-sizing: border-box;
box-sizing: border-box;
}
*:before,
*:after {
-webkit-box-sizing: border-box;
-moz-box-sizing: border-box;
box-sizing: border-box;
}
(You may also read read: http://www.paulirish.com/2012/box-sizing-border-box-ftw/)
I cannot think of a case where somebody place anything inside the grid without knowing it is grid... So I am not getting your concern here.
There's a big difference between starting a site from scratch with box-sizing:border-box on *, and loading into an existing site. The problem comes when someone decides to use .grid for laying out larger amounts content (e.g. in a skin) that they don't necessarily have control over.
What you really expect from a grid layout system in that it creates areas in which you can put any contents/widgets/plugins, and it should be possible to do that by just using a more specific selector than '*'.
Also the universal selector ('*') is incredibly slow: http://www.stevesouders.com/blog/2009/06/18/simplifying-css-selectors/
Also the universal selector ('*') is incredibly slow: http://www.stevesouders.com/blog/2009/06/18/simplifying-css-selectors/
Things moved a lot after 2009. See Performance section about http://www.paulirish.com/2012/box-sizing-border-box-ftw/ again for details.
Btw, we are moving a bit away from this specific issue report. Discussions around thirdparty grid systems it bit tangential here. Some of learning about using Grids in many language engineering team projects caused this RFC https://www.mediawiki.org/wiki/Requests_for_comment/Grid_system for MW and we use Agora grid system in one of our new project(by @pauginer )
So to keep things on track, I still think we should:
- prefix ULS classes with uls-
- remove all IDs (or at least prefix)
- prefix grid classes with something
And on our "offtopic" grid discussion, I'm sure * selectors are quicker than they were in '09 but they are still causing us performance issues: https://bugzilla.wikimedia.org/show_bug.cgi?id=64719
Other extensions (at least Translate) depend on the ULS grid. It will be annoying to migrate while keeping backwards compatibility.
I would rather wait until we have a grid system in core, and migrate to that, to avoid needing to migrate twice.