FYI: I've begun working on a branch to deprecate implicit strings which is the first step to address this issue.
http://github.com/chriseppstein/haml/commits/deprecated_implicit_strings On Nov 24, 6:20 pm, Nathan Weizenbaum <[EMAIL PROTECTED]> wrote: > Currently, the non-! variable syntax overlaps with the plain-string > syntax. If we do deprecate that syntax, then once we actually remove it > (post-2.2) we may be able to remove the ! syntax. But that's a > discussion for the future. > > Also, I'd like to make it clear that it wouldn't be the entire = syntax > that would be deprecated. You could still do > > background-image = !my_image_url > > and depending on whether or not we keep in the default function behavior > of working like a string, > > background-image = url(!my_image_name) > > It's only stuff like > > border = 1px solid !border_color > > that would have to change to > > border: 1px solid #{!border_color} > > - Nathan > > Chris Eppstein wrote: > > I had a similar thought. So far I haven't been able to think of a good > > reason to require the ! in that context except consistency. I was > > reading the w3c proposal for css variables today that is already > > implemented in Webkit. They have the following syntax: > > > @variables { > > my_image_name: url("/images/bg.png"); > > } > > > and you can reference a variable using a var() function like so: > > > background-image: var(my_image_name) > > > I think there's certainly an opportunity for us to do better than that! > > > Personally, I've never liked the !var syntax because of the overlap > > with the rule modifier !important and I think that too much > > punctuation scares off newbies. > > > That said, I think this is orthogonal to the issue at hand. > > > chris > > > On Mon, Nov 24, 2008 at 4:35 PM, railsjedi <[EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>> wrote: > > > I thinks fine to require using the #{} for evaluating variables as I > > think its a great Ruby idiom to reuse. > > > What if after Sass uses the ! operator to set variables, it allowed > > the #{} without the ! to evaluate them? > > > For example: > > !my_image_name = "/images/bg.png" > > div > > background-image: url(#{my_image_name}) > > > On Nov 24, 4:19 pm, Chris Eppstein <[EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>> wrote: > > > Nathan and I chatted for a while about this issue. We agree that > > > there's an awkward difference here between evaluated and > > non-evaluated > > > styles but the fix is not necessarily straightforward. > > > > Here's the rub. In theory, there's no way for the Sass parser to be > > > 100% certain whether you're referring to a resource or wanting > > > SassScript evaluation. Consider the following example: > > > > div > > > background-image = url(2-1) > > > > In theory this could be pointing to a resource named "2-1" in > > the same > > > directory as the compiled stylesheet, but then so could "1" -- the > > > result of performing an evaluation. Certainly this is just a corner > > > case. What are the chances that you're referring to a resource > > in the > > > same directory that happens to be named the same as a legal > > SassScript > > > expression? But the fact that it exists is extremely worrisome > > from a > > > language design perspective. > > > > The leading option right now to address this issue is to do away > > with > > > evaluation mode (=) altogether and use interpolation(#{}) to access > > > SassScript in a style value. You can use Sass this way right now, so > > > we'd simply deprecate evaluation mode for the next release. This > > means > > > that if you wanted to point to a resource named "1" using the code > > > above you'd have to express it like so: > > > > div > > > background-image: url(#{2-1}) > > > > But it also means that > > > div > > > background-image= url(!my_image_name) > > > > would have to become: > > > div > > > background-image: url(#{!my_image_name}) > > > > Any feedback or other ideas are welcome. > > > > Chris > > > > On Nov 24, 8:55 am, "Chris Eppstein" <[EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>> wrote: > > > > > Well I made a changeset that makes the url function escaped, > > but now that I > > > > think about it, it's not the right approach because it precludes > > > > url(!my_file_name). I think maybe you're just going to have to > > add quotes > > > > when in evaluation mode (=). > > > > > Nathan, do you think there's a bug here? > > > > > for reference, here's the change I made. I'll be dumping it > > shortly -- > > > > bummer cuz it was pretty clean code. > > > > > >http://github.com/chriseppstein/haml/commit/fa9092798194384df0caaed89... > > > > > On Mon, Nov 24, 2008 at 7:32 AM, Chris Eppstein > > <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>wrote: > > > > > > I'll look into this right away. As a work-around for now you > > can place > > > > > your image name in quotes. > > > > > > chris > > > > > > On Nov 24, 3:43 am, jazen <[EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>> wrote: > > > > > > Hello, > > > > > > > i'm using Edge Rails, Ruby 1.8.6 and (Edge) Haml and ran > > into the > > > > > > following issues: > > > > > > > Sass::SyntaxError: Undefined operation "-960 minus yellow" > > > > > > ... > > > > > > background = !highlight_color url(../images/bg-box-bottom-960- > > > > > > yellow.png) no-repeat 0 bottom > > > > > > > Sass::SyntaxError: Expected expression, was and token > > > > > > ... > > > > > > background = transparent > > url(../images/repl-de-logo-and-slogan.png) no- > > > > > > repeat 11px 0 > > > > > > > and Sass evaluates color aliases into their codes, e.g.: > > > > > > > background-image = url(../images/bg-arrow-red-down.gif) > > > > > > becomes > > > > > > background-image = url(../images/bg-arrow-#ff0000-down.gif) > > > > > > (Firebug revealed this) > > > > > > > /jazen > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Haml" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/haml?hl=en -~----------~----~----~----~------~----~------~--~---
