Financial-Times / o-grid

Responsive grid system
http://registry.origami.ft.com/components/o-grid
94 stars 17 forks source link

Leaky selectors #7

Closed wheresrhys closed 10 years ago

wheresrhys commented 10 years ago

Ouch. Is there no way of solving this? I can see it catching people out. @triblondon

wheresrhys commented 10 years ago

The only sensible ways I can think of are to break the class from ft-grid-col-d6-s12 to something like ft-grid-col d6 s12 or ft-grid-col-d6 ft-grid-col-s12. I prefer the single class version as it feels more encapsulated. And if we split up the classes into d6 s12 those also run the risk of being matched by other errant stylesheets. The column width selectors are all low specicifity so any leaking in/out of grid-module (at least when it comes to in-house code) should be easy to avoid/rectify. An option would be to make the classes a bit silly in structure and therefore rarer e.g. ft-grid-col-d_6-s_12 would give us the highly unusual selector [class*="-d_6"]

wheresrhys commented 10 years ago

just had a realisation on classnames:

although ft-grid-col.d6.s12 is not valid as a class selector, it can still be used in an attribute selector [class*=".d6"]: http://jsbin.com/ekAhime/2/ . Still very readable, reduces the leakiness to practically zero, and has the advantage of preventing developers/designers from misusing the grid classes as hooks for other styles

wheresrhys commented 10 years ago

Checked on w3 that this new idea is valid html5, and it is; the class attribute has to be a space separated list of tokens http://dev.w3.org/html5/markup/datatypes.html#data-token (surprisingly it's even allowed in html 4, though under different terminology http://www.w3.org/TR/html401/types.html#type-cdata).

We should take some time to think of the perfect syntax before implementing - I'm quite excited by how expressive this approach could be e.g. ft-grid-col3,s12,m6, ft-grid-col3(s12,m6)

triblondon commented 10 years ago

Not sure I see why this is less leaky. Is it because you don't anticipate a period being used in a classname (since it would delimit classes in a regular selector)? I like the other suggestions, especially the bracket syntax. Let's discuss that. But I'd have thought the solution would simply be to chain the existing attribute filter with another one:

[class^="ft-grid"][class*=".d6"] {
  background: red;
}

That seems to work when I tried it on your jsbin.

wheresrhys commented 10 years ago

Yep. that's exactly my reasoning. I'm not a fan of doubling up on attribute selectors as it increases specicifity without completely removing the risks inherent in scopeless css. Invalid css class characters seems like a good way to decrease the risk (which I reckon is pretty small anyway) without increasing specicifity. Going back to separate classes is still an option too, but I really like the conciseness and, IMO, increased clarity of a single class with structure.

triblondon commented 10 years ago

I'm a bit concerned that using periods might make us vulnerable to browser bugs because we're relying on an edge case (albeit a correct one) in the CSS implementation. Can we discuss the disadvantages of using the double selector a bit more? It seems to me to completely remove the risks, and the increase in specificity seems reasonable, but I'm very happy to be persuaded on this.

wheresrhys commented 10 years ago

I've tried out the double selector locally and it works (apart from one or two little things which should be fairly easy to fix). In order to get the media query cascade to work properly though we need to sometimes have [class*="ft-grid"][class*="ft-grid"], which is pretty ugly. And any extension of a no-gutters placeholder, or any other grid-module selector, will end up having double the specicifity the user might expect. e.g.

.my-no-gutter {
    @extend %no-gutter;
}
--->

.my-no-gutter.my-no-gutter {
     // no gutter styles
}

A compromise could be to make turning on the double selector a configurable option at the product level using a sass variable; both types of selector expect exactly the same markup (although products that have it turned on/off may need to bolster the specicifity of some modules' styles)

wheresrhys commented 10 years ago

resolved by email

class structure decided on is e.g. ft-grid-col|3|s12|