Essentially Hitch looks to add behavior to CSS where Sass/LESS looks to make writing CSS easier. We love Sass/LESS and don't believe it's a competition with the libraries.
So I'm curious if you say it 'hitches/intercepts' the css of the browser, why not implement the proposed spec as is, instead of a custom function ie: '-hitch-has' that way at least if the spec does get approved then sites using hitch benefit from already following the spec.
Obviously the spec might change and there's no way round that but seems better to hope for the best than to have a custom / branded pseudo-selector. - just a thought.
That's a very good thought. We struggled with that during the development of -hitch-has() and a few others. Ultimately we landed on the position of getting an implementation out there that was functionally equivalent.
CSS Selectors 4 (http://www.w3.org/TR/2011/WD-selectors4-20110929/#subject) points out a syntax that is currently using "$". But that has also been suggested as "!" in the past. It's a tough thing to get nailed down, but we decided we'd rather not wait to have the functionality.
Since it has changed so many times and there still isn't agreement it wouldn't be prudent to even pretend that this is shimming something that is planned for CSS.
Indeed, this is merely one new selector that Hitch provides - there are lots more, and a plugin model which allows an unlimited number in the future. They all follow CSS' forward compatible parsing rules and so, by their nature, they sort of have to follow prefixed pseudo form as a rule.
Hitch is quite a bit different than Sass/LESS. I wrote about this here: http://clint-hill.com/2012/05/06/changing-how-css-works-hitc...
Essentially Hitch looks to add behavior to CSS where Sass/LESS looks to make writing CSS easier. We love Sass/LESS and don't believe it's a competition with the libraries.