TBH. I think we __don't__ want page specific styles, look at most of code, i.e. js, we __force__ to be __generic__ not page specific, and still this code __is not__ page specific, as it's not re-used anywhere anyway, so adding call in view to get one additional class and any benefit, where using other class (`.sylius-products-table`) __which is *kinda* page specific__ (check it's name), sounds strange and adds only WTFs IMO.

If you add css that is page specific (which IMO you are __not__ adding in this PR, as 90% can be re-used in any table at backend, and probably will be re-used), I don't see any point of this in backend, as this have to be simple code, that will be an (_nice_) __skeleton__ for other developers to easily replace it (if they want), or add new code basing at __generic__ parts, without looking for hacks like this one, and throwing WTF's because something bases on something they i.e. accidentially deleted (it's really often when you redesign something, trust me).

Additionally article you linked is dated: XII 2007, [browser market at that month](http://en.wikipedia.org/wiki/Usage_share_of_web_browsers#W3Counter_.28May_2007_to_present.29): IE 62.8%, FF 28%, Chrome 0% (not existed yet), ~2% Opera. So I can agree that those days, where most of users were using IE 6-7 such hacks were useful, now it's useless IMO.