Skip to content
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

Open
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

pravee-n
Copy link

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-'.

@@ -1,254 +1,254 @@
/* Generated using Foundation http://foundation.zurb.com/docs/grid.php */
/* Global Reset & Standards ---------------------- */
.grid * {
Copy link
Member

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

  1. We cannot upgrade this css with latest releases from foundation.zurb.com
  2. Breaks the idea of semantic class names like "six columns". now it is "uls-six uls-columns". less readable too
  3. This grid was reused in some mw extensions that depends jquery.uls.

@santhoshtr
Copy link
Member

we need to live the grid system untouched

@pravee-n
Copy link
Author

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.

@edg2s
Copy link
Member

edg2s commented Apr 22, 2014

There's no reason to use ID's at all, they're evil.

@edg2s
Copy link
Member

edg2s commented Apr 26, 2014

Also why does the grid css need to be untouched? Any un-namespaced CSS is a bad idea.

@santhoshtr
Copy link
Member

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.

@edg2s
Copy link
Member

edg2s commented Apr 27, 2014

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-'.

@edg2s
Copy link
Member

edg2s commented Apr 27, 2014

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.

@santhoshtr
Copy link
Member

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.

@edg2s
Copy link
Member

edg2s commented Apr 28, 2014

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 '*'.

@edg2s
Copy link
Member

edg2s commented Apr 28, 2014

Also the universal selector ('*') is incredibly slow: http://www.stevesouders.com/blog/2009/06/18/simplifying-css-selectors/

@santhoshtr
Copy link
Member

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 )

@edg2s
Copy link
Member

edg2s commented May 1, 2014

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

@edg2s
Copy link
Member

edg2s commented May 2, 2014

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

@Nikerabbit
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

4 participants