Disqus - Friends of dlsspy

Re: http://chriseppstein.github.com/blog/2009/10/19/css-unsupported-directive

crispy — Mon, 19 Oct 2009 16:53:27 -0000

i'm not sure what Dynamic CSS is. Do you mean using a precompiler to generate CSS? If so, I agree. Browser makers have to do their part to make it easier to use their new features.

Re: http://chriseppstein.github.com/blog/2009/10/19/css-unsupported-directive

crispy — Mon, 19 Oct 2009 13:14:13 -0000

Then you'll fall back on old technique and approaches. Or we'll just complain.

Re: http://chriseppstein.github.com/blog/2009/10/19/css-unsupported-directive

crispy — Mon, 19 Oct 2009 10:41:52 -0000

Feature inspection is a much more robust approach than user-agent testing. User-Agents will be rolling out new feature support, and I shouldn't have to keep track of the support matrix, I should only have to know what features exist and how to deal with them if they don't.

Re: http://chriseppstein.github.com/blog/2009/10/19/css-unsupported-directive

crispy — Mon, 19 Oct 2009 10:28:11 -0000

I thought about including a selector syntax in the queries, but it's not clear to me how it would help. The document has to change to accommodate the lowest common denominator with respect to selector support, having knowledge in the stylesheet that you can't target some element, seems a little late to adjust to that information.

You're correct that different engines will probably have quirks to them, but I think this feature would help us adopt new features of CSS3 and still provide a decent experience for CSS2 browsers.

Re: http://chriseppstein.github.com/blog/2009/09/20/why-stylesheet-abstraction-matters

crispy — Sun, 18 Oct 2009 11:16:34 -0000

I'm very familiar with that post. Not surprisingly, I completely disagree. I think abstractions can make CSS more suitable for its intended audience by turning simple style primitives into simple style concepts that just work in all browsers.

Re: http://chriseppstein.github.com/blog/2009/09/20/why-stylesheet-abstraction-matters

crispy — Sun, 18 Oct 2009 11:12:58 -0000

I understand that having a css compiler written in the application's native language is convenient, but it should be noted that Sass, Compass, and Less all have command line tools that can be used with any kind of application, independent of the language or framework.

Re: http://chriseppstein.github.com/blog/2009/10/12/css-class-inheritance

crispy — Wed, 14 Oct 2009 14:50:03 -0000

Well my red/green example (realizing now that it was a bad choice for those who are color blind. eek!) is just one of the simplest cases I could construct to demonstrate the issue, it's not a real world example. In a real world example, you'd probably have the class defined at the parent AND then again with some other selector that is augmenting it by not a descendant selector in the stylesheet context -- that augmentation would not be picked up by the inheriting classes.

as for a better example for the first quote, a HAS-A mixin looks like this:

=has-an-avatar
  .avatar
    border: 1px solid black

.user
  +has-an-avatar

But that forces you to always name an avatar ".avatar", not always what you want. so a pure mixin approach looks like this:

=avatar
  border: 1px solid black

.user .avatar
  +avatar

In this case the avatar mixin is more like an IS-A relationship except it only affects this one selector(instance), not all .avatar selectors.

Re: http://chriseppstein.github.com/blog/2009/10/12/css-class-inheritance

crispy — Wed, 14 Oct 2009 14:34:17 -0000

I didn't notice that syntax change, it must have been in the last couple weeks.

Re: http://chriseppstein.github.com/blog/2009/10/12/css-class-inheritance

crispy — Wed, 14 Oct 2009 11:47:14 -0000

Thanks for your thoughtful comment. A couple of replies:

I don't think this is an either or situation. CSS should support inheritance AND mixins as they are slightly different.

I agree it's not an either or thing. I think interesting things can happen when mixins apply @extends to the selector.

The part that has me torn is that mixins can work completely intuitively within the context of a css compiler but inheritance cannot. The question in my mind is whether inheritance can work well enough in practice without causing undue headaches when the limits are poorly understood.

Inheritance is if something IS A Class and Mixins are used if something HAS A Class

I think the language of OOP is hard to apply correctly to CSS. But I do think that CSS can be applied to the language of OOP if that helps you. For instance, you can make a mixin that is a HAS-A mixin by always nesting the selectors inside the mixin and not placing any styles on the mixin's parent except where necessary to make the associated element render correctly. But a mixin can do more than just a HAS-A relationship. In object oriented terms, it's very much like the ruby singleton class -- an IS-A relationship that only affects one instance.

I would propose notation such as a new property for inheritance called inherits and using the + syntax from sass for mixins.

I don't think the CSS requires any new syntax to support, just some new keywords and semantics.

I don't see how inherit:box is any different from extends:box, both are not style properties. Inheritance is an aspect of selector behavior, not appearance. This is why I use an @extends directive. I guess it could be @inherit if people like that word better.

Maybe the W3C will add support for mixins but if they do it will also be with a @mixin directive. I can't imagine them changing the grammar syntax for that. I also think the only reason they would do this is because stylesheets with a mixin directive would be more efficient to send over the wire, parse, and render against -- the fact that they can be implemented by a precompiler, means they will drag their feet on this for some time to come.

I think that the notation of putting classes within classes is more like mixins rather than inheritance as you suggest.

Actually less has another syntax for mixins that take arguments, it uses the @ symbol. again. and quite incorrectly. But I agree that the less syntax behaves like a mixin. But it doesn't give you the impression of a mixin -- it gives the impression of inheritance and that makes it broken in my mind.

Re: http://chriseppstein.github.com/blog/2009/09/20/why-stylesheet-abstraction-matters

crispy — Mon, 05 Oct 2009 11:29:14 -0000

If the industry decides to go to a new approach, then whine all they want, the industry is there so whatever. But that's not where we are. I would be surprised if even 1% of web developers know what Sass is yet. So this is what we call the "adoption" phase where people kick the tires, debate the merits, shake their heads in confusion, etc.

If Sass is a good idea, it will be adopted. Nathan and I both agree that the white-space active aspect of Sass poses a significant barrier to adoption, so the Sass syntax as it stands now is quite unlikely to achieve mainstream adoption. Nathan is working on making the Sass parser deal with a more css-like syntax, so that the abstractions I speak of here can be used by people without confusing them about indentation.

I think you're more prescient than others. you see the web as it ought to be and not how it really is and that can be frustrating. Trust me, I understand ;-)

Re: http://chriseppstein.github.com/blog/2009/09/20/why-stylesheet-abstraction-matters

crispy — Mon, 05 Oct 2009 02:11:45 -0000

That's tough when Sass is such an early technology -- early adopters generally accept this risk for the productivity gains. However, this fear assumes that Sass poses a significant learning curve. I think Sass should be (and is) quite easy for anyone who understands CSS to pick up in an hour or two.

Re: http://chriseppstein.github.com/blog/2009/09/20/why-stylesheet-abstraction-matters

crispy — Mon, 05 Oct 2009 02:05:29 -0000

Let's keep a civil tone, shall we? Here's the thing, there's all kinds of people in the web development field. Many of them are just cranking out websites for the pet store around the corner. Not all of them aspire to be awesome or "professionals" so I think it's correct to ask the question about what the right level of complexity should be in stylesheets and markup. I think there's a great argument to be made that mixins and abstraction make design more accessible.

Re: http://chriseppstein.github.com/blog/2009/09/20/why-stylesheet-abstraction-matters

crispy — Wed, 30 Sep 2009 19:58:11 -0000

I know ERB. Blueprint uses it to build their css. You can compare it to this.

If the goal was to simply generate a single CSS file, then Sass would be overkill and ERB would be fine. But that's not the goal. The goal is to give you the tools to build your own css files. That means we have to create abstractions that can be shared and so ERB fails -- it's just a templating system. That sass file is a codification of how blueprint works. You can use it to build your own css files and your own selectors based on blueprint's underlying theory -- not based on it's output.

Additionally, I didn’t demonstrate the full power of mixins in this post, but you simply cannot achieve the same results using this kind of templating approach as you can with mixins, because mixins know the selector context they are being mixed into, this allows you to embed nested selectors into the calling context. Sass also has the "&" operator that is a reference to the parent selector which allows you to build some very useful mixins as you can refer to the parent selector in the abstract (e.g. the "* html" hack)

Re: http://chriseppstein.github.com/blog/2009/09/20/why-stylesheet-abstraction-matters

crispy — Tue, 29 Sep 2009 10:18:37 -0000

it was spread out and the bulk of it was making the syntax highlighter for Sass. Also that includes building the whole browsable stylesheets feature of this blog which was non-trivial.

Re: http://chriseppstein.github.com/blog/2009/09/20/why-stylesheet-abstraction-matters

crispy — Mon, 28 Sep 2009 23:39:57 -0000

Absolutely. Comments should describe "why" not "how".

Re: http://chriseppstein.github.com/blog/2009/09/20/why-stylesheet-abstraction-matters

crispy — Mon, 28 Sep 2009 15:14:42 -0000

The syntax highlighting was a non-trivial task, the blog is built on top of a fork of jekyll which has a syntax highlighter integration built in using pygments. I built a sass syntax highlighter on top of pygments. Then I hand coded the syntax stylesheet in sass to make it look like my TextMate theme. There's at least 30 hours of my own work to get it all working ;-)

All the code for my blog is online here.

Re: http://chriseppstein.github.com/blog/2009/09/20/why-stylesheet-abstraction-matters

crispy — Tue, 22 Sep 2009 02:48:20 -0000

My point still is that introducing higher level programming concepts to style sheet languages like CSS raises the bar to entry for newcomers

It does and it doesn't. If you've one a bunch of calculations on a piece of paper and then typed that into your CSS, I'm left to wonder why that number is what it is. If you have the some hex color strewn about your code, I don't know why you've been using that color. If you're bad at Sass, you can certainly make a mess of things and be potentially worse off than just plain CSS, but if you're good, I'm positive that I'll have an easier time figuring out how to modify the site, even taking into account that I have to learn sass. Anyways, the Sass learning curve is not pertinent to the discussion of the value that abstraction brings to design.

Another point is that Sass is not a lock-in technology. If you ever decide that it's not for you, keep your generated css, throw your sass away and move along.

With all due respect, I don't think it's about picking sides

You're right, It's not about picking sides, it's about whether you yourself are going to take the challenge to try things a different way. Once you have, we'll see if you really ever go back ;-)

power and simplicity are to an extent mutually exclusive

No. They are not. Ruby has metaprogramming and singleton classes and open classes and all these other really powerful concepts that I never understood when I first started programming in ruby. The presence of those features did not affect my ability to write code in the least. But it did give others (like the folks who wrote ruby on rails) the ability to make it really easy for me to build a website. And when I was ready to up my game, I had plenty of power at my fingertips and tons of examples to follow. The same goes with sass. I don't have to understand the powerful features of sass to benefit from them. I can read well named mixins and understand what they do (coupled with a little documentation) and since sass emits css I can inspect the results and understand them even if I don't comprehend the code that generated it. And when I'm ready to up my game, I have a wealth of complex sass code (from compass) that I can study to understand Sass better.

languages like XSL have failed to gain wider adoption primarily due to the fact that they're just too bloody hard to learn

XSL is a huge piece of shit. It was hard to learn because it sucks. I'm pretty damn smart and XSL made my head hurt. Add to that, that XSL was really about transforming documents, not styling them. Sass is basically CSS and it layers on top of that a simple imperative scripting language -- if you already know basic javascript, you can certainly handle SassScript.

Re: Highlight link based on current page in rails

crispy — Tue, 30 Sep 2008 16:58:24 -0000

Because if you're doing say 10 or 20 links instead of 2 or 3, link_to_with_highlight is less dry than a block approach. But if the number of links is small, then this is a fine approach.

Re: Absolutely bullshit Ruby HTTP client situation | apocryph.org

crispy — Sun, 28 Sep 2008 02:44:25 -0000

There doesn't have to be anything wrong with python for ruby to be better.