Disqus - Friends of dlsspy

Re: Highlight link based on current page in rails

Chris Eppstein — Sun, 28 Sep 2008 02:25:37 -0000

It is a common problem, but I don't think this is a good way to solve it. It fails if your code is in a partial (like say for your header) and shared among different controllers. Also it's not very DRY, you're repeating the link information in the call to is_active? and you're not leveraging the current request information. You shouldn't have to do more than this:

highlight_current_link do
link_to 'Home', root_path
link_to 'About', about_path
link_to 'Contact', contact_path
end

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

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

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

Re: Highlight link based on current page in rails

Chris Eppstein — 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: Caching and Expring Stylesheets and Javascripts in Sinatra

Chris Eppstein — Sat, 28 Feb 2009 19:24:21 -0000

This is a good caching strategy, but I think writing static assets to disk and serving them directly is a better one. This is how sass for rails and merb works. The invalidation mechanism will still work and you won't need to regenerate your stylesheets for every person who visits your site. Your webserver will have an option for configuring the expires header on these static assets.

Re: Using Compass with Jekyll

Chris Eppstein — Sun, 12 Jul 2009 21:31:44 -0000

As of compass 0.8, the compass configuration file can be kept in .compass/config.rb, I imagine that jekyll will skip over hidden directories, so that might work better.

Re: http://chriseppstein.github.com/blog/2009/09/07/building-a-jekyll-watcher-with-fssm

Chris Eppstein — Sun, 20 Sep 2009 22:28:45 -0000

@supaspoida A couple of things:

1) FSSM has support for mac osx fsevents which means that watching is much easier on cpu and laptop battery life.
2) Jekyll's --auto command doesn't let me do an arbitrary build. For most people that's not a problem, because they use jekyll out-of-the-box, but I'm using a fork that supports haml and I use compass to build my stylesheets. In addition, I generate html files for all my sass file so that they're browsable and I build an xml sitemap, etc. Jekyll is good at what it does, but I really see it as just part of my build process.

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

Chris Eppstein — Tue, 22 Sep 2009 00:23:58 -0000

@Jussi

Thanks for stopping by to offer your opinion. But I'm afraid that since you didn't bother to read the article, it doesn't carry much weight. I understand your knee-jerk reaction to my quote, but I stand by it. Sass is what programmers call a "Domain Specific Language". So, yes, it is a programming language. But it is not a general purpose one. You can only use it to emit CSS.

It's worth noting that Sass in its simplest form is a nicer-to-use version of CSS. You don't have to know any programming at all to use it. Since Sass allows us to share our abstractions with each other, the folks who are programmer-designers like myself can build the underlying complexity and keep it fully encapsulated from the non-programmer types. They can then use the mixins for fun and profit. As they mature, they can start to use variables and write their own simple mixins with some conditional statements here and there.

Lastly, please don't insult designers by saying that they cannot learn some basic programming skills if they want to. Can you really expect them to learn the complexities of CSS itself and not think they can pick up variables and expressions? They took algebra in high school too. I prefer to put people in an environment where they can grow as their understanding grows, and not feel constrained instead.

Alas, I don't have any illusion that Sass will ever replace CSS as the predominate stylesheet syntax that folks use, nor can Sass "replace" CSS because Sass emits CSS. But if we can get just 5% of all front-end engineers/designers to use Sass, we will have a very vibrant community that is running circles around those who don't :-P The question that I have for you is which of those groups will you be in?

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

Chris Eppstein — 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: http://chriseppstein.github.com/blog/2009/09/20/why-stylesheet-abstraction-matters

Chris Eppstein — 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

Chris Eppstein — 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

Chris Eppstein — 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

Chris Eppstein — 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

Chris Eppstein — 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

Chris Eppstein — 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

Chris Eppstein — 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/10/12/css-class-inheritance

Chris Eppstein — 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/10/12/css-class-inheritance

Chris Eppstein — 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

Chris Eppstein — 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/09/20/why-stylesheet-abstraction-matters

Chris Eppstein — 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/09/20/why-stylesheet-abstraction-matters

Chris Eppstein — 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/10/19/css-unsupported-directive

Chris Eppstein — 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/10/19/css-unsupported-directive

Chris Eppstein — 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

Chris Eppstein — 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

Chris Eppstein — 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: Astrails Let my controller go or useful impurity in software design.

Chris Eppstein — Tue, 27 Oct 2009 16:00:33 -0000

Generating a view from your model (to_xml) is the problem here and is the reason why you're needing access to controller methods from your model.

I get around this by having models implement a method called canonical_url that returns an object like so:

{:use_route => "article", :id => self.id}

This hash can then be passed to url_for to generate a route. I think this is a good convention for apps like yours that are doing some CMS-y things and necessarily blurring the line between data and views.