-
Notifications
You must be signed in to change notification settings - Fork 67
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Prefixed 'uls-' to all classes and IDs #105
base: master
Are you sure you want to change the base?
Conversation
@@ -1,254 +1,254 @@ | |||
/* Generated using Foundation http://foundation.zurb.com/docs/grid.php */ | |||
/* Global Reset & Standards ---------------------- */ | |||
.grid * { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since this is thirdparty grid system from foundation. we should avoid customizing class names like this. There are multiple reasons
- We cannot upgrade this css with latest releases from foundation.zurb.com
- Breaks the idea of semantic class names like "six columns". now it is "uls-six uls-columns". less readable too
- This grid was reused in some mw extensions that depends jquery.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:
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/ |
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:
|
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. |
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-'.