I'm not sure I agree, Chris... haml-dev is more about Haml implementors discussing language issues.
I'll try to cover the internals of Sass from top to bottom. Interaction with the user is done either through Haml::Exec (which handles the command-line utilities), Sass::Plugin (which handles integration with Ruby frameworks and file watching), Sass::Repl (which handles sass -i), and Sass::Engine (which is the main entrance point of the Ruby API). When given an input string, first that string is parsed. Sass::Engine handles parsing the indented syntax, Sass::SCSS::Parser handles parsing SCSS, and Sass::SCSS::CssParser (a subclass of Sass::SCSS::Parser) handles parsing plain CSS for sass-convert. When being parsed, the string is transformed into an AST. AST nodes are subclasses of Sass::Tree::Node, except for property values, which are subclasses of Sass::Script::Node. In general any SassScript and property evaluation is handled in the Sass::Script namespace, whereas other sorts of evaluation are handled in Sass::Tree. There are several steps done when compiling the AST to CSS. First it is "performed", which means that all dynamic features including any SassScript and control directives are run and resolved. Then is it "cssized", which means that any remaining Sass-specific structure is removed -- nested rules are resolved, that sort of thing. Finally, it's recursively converted to a CSS string. Hope this is helpful, - Nathan On Wed, Apr 14, 2010 at 11:12 AM, Chris Eppstein <[email protected]> wrote: > This thread is more appropriate for the haml-dev list. > > On Wed, Apr 14, 2010 at 11:08 AM, Suno Ano <[email protected]> wrote: >> >> How would one describe the architecture of Sass? >> >> ,----[ From an earlier post made by Chris ] >> | In Sass 3, Nathan has made the core of what Sass is a lot more >> | technically robust. This has allowed us to get rid of a number of >> | syntactic annoyances like the need to use = or #{} in the most common >> | cases to use SassScript. >> | >> | On top of this core, there are three parsers, one for the indentation >> | based syntax, another for the css superset syntax called scss, and one >> | for parsing css3. The way these parsers work is by translating your >> | document into a syntax agnostic representation called an AST, which can >> | then be converted to css, sass, or scss. This is also what enables the >> | two syntaxes to completely interoperate across imports. >> `---- >> >> So the architecture is like this, bottom to top: >> >> - Sass core at the bottom (what exactly is this?); judging from the >> source, a bunch of logic busy with doing conversion and >> imports/exports >> - sitting atop this core are three parsers, one for each syntax, >> translating into AST >> - what else? >> >> How do those components work together? Workflow? >> >> >> >> >> >> >> >> >> -- >> 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. >> > > -- > 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. > -- 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.
