3 ms·

With projects like Compass (http://compass-style.org http://compass-style.org) for SASS/SCSS, those abstraction layers are there. When we made WebPutty (http://

by tghw 15y ago

With projects like Compass (http://compass-style.org http://compass-style.org) for SASS/SCSS, those abstraction layers are there. When we made WebPutty (http://webputty.net http://webputty.net) with SCSS support, one of the first and most common questions we got was "can I use Compass", so we added it. It's pretty much the standard for abstractions. Less is not quite there yet, but things like Twitter Bootstrap are well on their way to becoming similar standard abstractions.

masklinn 15y ago
> With projects like Compass (http://compass-style.org http://compass-style.org) for SASS/SCSS, those abstraction layers are there. That's nonsense, those "abstraction layers" are inserted statically during deployment, they don't improve as browsers improve. When Google or Apple adds a proprietary -webkit- property which may never get standardized, Compass has no way to make that property available to all browsers in sites built at the time the property was solely proprietary as browsers gradually implement it (and it gets standardized) over the next years.
- jballanc 15y ago
  Code that you compiled on a machine 10 years ago is rather unlikely to still run on whatever machine you're using now. That's the way things go. Still, this is CSS's problem, not Compass's. If CSS had better abstraction abilities built in, then you could point your page to a reference set of abstractions that could be updated as browsers improve.
  - masklinn 15y ago
    > Code that you compiled on a machine 10 years ago is rather unlikely to still run on whatever machine you're using now. 1. That's not even true, you should try out windows once in a while 2. We're not talking about local programs. > That's the way things go. No it's not, that's not even a cop-out that's complete, utter and absolute bullshit. Pages from the very origin of the internet back in 1992 still work perfectly fine today: http://www.w3.org/History/19921103-hypertext/hypertext/WWW/TheProject.html http://www.w3.org/History/19921103-hypertext/hypertext/WWW/T... You making things which break is not "the way things go", it's you being incompetent, don't try to pass the blame to somebody else... > If CSS had better abstraction abilities built in, then you could point your page to a reference set of abstractions that could be updated as browsers improve. as you're doing here. So now to fix your own personal incompetence there needs to be a centralized authority set which will magically fix your crap as time goes on? How about doing things correctly to start with?
    - jballanc 15y ago
      Pages from the very origin of the internet back in 1992 still work perfectly fine today Yeah, but none of my <marquee> tags work. Which is funny, because that was also a non-standard, browser-specific feature. If that element had been standardized, but as <marquis>, then those pages would still break. How about doing things correctly to start with? I thought that's what we were advocating? Using vendor specific prefixes is the same as using a non-standard tag: it will likely break, and will almost definitely not work on multiple platforms. That doesn't seem to me, though, to be an argument against them. If you want to complain that the standardization process is too slow, and thus people are used to continue using vendor-prefixed tags longer than they should, I'll be right beside you yelling about it. But the solution, it seems to me, isn't to "break" or abolish vendor prefixes. If you want to speed up the standardization process, do what the WHATWG did.

by tghw 15y ago

masklinn 15y ago

> With projects like Compass (http://compass-style.org http://compass-style.org) for SASS/SCSS, those abstraction layers are there. That's nonsense, those "abstraction layers" are inserted statically during deployment, they don't improve as browsers improve. When Google or Apple adds a proprietary -webkit- property which may never get standardized, Compass has no way to make that property available to all browsers in sites built at the time the property was solely proprietary as browsers gradually implement it (and it gets standardized) over the next years.

jballanc 15y ago
Code that you compiled on a machine 10 years ago is rather unlikely to still run on whatever machine you're using now. That's the way things go. Still, this is CSS's problem, not Compass's. If CSS had better abstraction abilities built in, then you could point your page to a reference set of abstractions that could be updated as browsers improve.
- masklinn 15y ago
  > Code that you compiled on a machine 10 years ago is rather unlikely to still run on whatever machine you're using now. 1. That's not even true, you should try out windows once in a while 2. We're not talking about local programs. > That's the way things go. No it's not, that's not even a cop-out that's complete, utter and absolute bullshit. Pages from the very origin of the internet back in 1992 still work perfectly fine today: http://www.w3.org/History/19921103-hypertext/hypertext/WWW/TheProject.html http://www.w3.org/History/19921103-hypertext/hypertext/WWW/T... You making things which break is not "the way things go", it's you being incompetent, don't try to pass the blame to somebody else... > If CSS had better abstraction abilities built in, then you could point your page to a reference set of abstractions that could be updated as browsers improve. as you're doing here. So now to fix your own personal incompetence there needs to be a centralized authority set which will magically fix your crap as time goes on? How about doing things correctly to start with?
  - jballanc 15y ago
    Pages from the very origin of the internet back in 1992 still work perfectly fine today Yeah, but none of my <marquee> tags work. Which is funny, because that was also a non-standard, browser-specific feature. If that element had been standardized, but as <marquis>, then those pages would still break. How about doing things correctly to start with? I thought that's what we were advocating? Using vendor specific prefixes is the same as using a non-standard tag: it will likely break, and will almost definitely not work on multiple platforms. That doesn't seem to me, though, to be an argument against them. If you want to complain that the standardization process is too slow, and thus people are used to continue using vendor-prefixed tags longer than they should, I'll be right beside you yelling about it. But the solution, it seems to me, isn't to "break" or abolish vendor prefixes. If you want to speed up the standardization process, do what the WHATWG did.