Statically checked DSL for CSS selectors

[Maxim Shafirov]

CSS builder stuff is amazing to say the least. It covers LESS and SASS with a breathe.

In "statically check everything" mantra though, we also need to address untyped string parameter of the s() function.

I'm prototyping something like

s(div(header, footer)) {
  background = grey
}

right now. For this to be statically checked you'll need to have your style classes like header and footer defined somewhere to reference from both HTML and CSS builders.

Does that make sense?

[Andrey Cheptsov]

Sounds very promising! How about inheritance and polymorphism for CSS classes definition?

[Andy Selvig]

I've always felt a bit dirty about strewing a bunch of strings in with the CSS builder code.

I think that it's a good idea as long as we can make the class (and ID) definitions as simple as possible. I guess it could be something as simple as:

class header() : CssClass()

Even better would be if we could have the class declaration take an optional stylesheet builder. 

So the question is, how elegant can we make the selector syntax? It's one thing to support simple class selectors, but about something more complicated like:

ul#myList li.active

[Maxim Shafirov]

We'll generate to plain CSS by the end of the day, that's the only limitation we have. So can we please elaborate a bit more details of what you'd like to get implemented?

[Maxim Shafirov]

> u#myList li.active

Current proto-syntax for this is like following

s(u(id("myList"))) {
   s(li(active)) {
   }
}

Alternatively, it may look like this:

s(u[id("myList")]) {
   s(li[active]) {
   }
}

And classes are just listed in some enum like following:

enum class MyClasses : StyleClass {
  header footer active
}

A bit more sophisticated sample:

s(div att "class" startsWith "foo") {
}

same with full parenthesis:

s(div.att("class").startsWith("foo")) {
}

[Maxim Shafirov]

Another idea is to have apply function on selectors instead of s() taking selector as parameter. This way we'll write:

u[id("myList")] apply {
   li[active] apply {
   }
}

[Hadi Hariri]

I'm not too keen on the first samples, too Lisp looking. Doesn't read too well IMHO (nor with [). 

I'd prefer something in this direction:

[Andrey Cheptsov]

Please take a look: https://docs.google.com/document/d/1r_NNpcXo-c1OXbBvj5l1MtPMreKSV31lnuZC2KA5oPs/edit

Comments are welcome.

[Maxim Shafirov]

How does "body {...}" work on top level?

[Andrey Cheptsov]

Have fixed all compiler errors.

[Andrey Cheptsov]

If I can write:

id("element-id)" {

}

I would like also to be able write (in addition to the current style):

c("class-name") { // Without any(...) and without enum definition.

}

"c" is short and nice.

For colors we might use color("#ffaaaa").

[Andy Selvig]

Hey Andrey-

I've been travelling and just got a chance to look at this. In general, I think the syntax is looking really good. I agree that using c() for class selectors is a good idea. It's then consistent with the HTML builder, and we can just use color() for the color parser. 

From an implementation standpoint, it seems like it would make more sense to define the tag selectors (a, body, img, etc) as functions instead of instance variables on the Element class. The way it is right now, you're generating a bunch of garbage every time you make a new element. Is there an advantage to this approach that I'm missing?

[Maxim Shafirov]

> The way it is right now, you're generating a bunch of garbage every time you make a new element. 

Good point. Will try to switch to functions and see if DSL is being hurt.

--
You received this message because you are subscribed to the Google Groups "Kara Framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to karaframewor...@googlegroups.com.
To post to this group, send email to karafr...@googlegroups.com.
Visit this group at http://groups.google.com/group/karaframework?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Maxim Shafirov]

Fixed. All those vals don't have backing fields anymore

[Maxim Shafirov]

Please note style classes can now be defined as enum constants (see KaraDemo's StyleClasses) and styles can be applied to classes just like to tags:

styleClass {

  width = 85.percent

}

So, this c(String) : StyleClass function is probably not needed

On Feb 1, 2013, at 5:50 PM, Andy Selvig <ajse...@gmail.com> wrote:

[Andy Selvig]

Okay, great. I love that syntax.