Declarative constraints using ccss

[kof]

Any thoughts on how ccss could be used with slalom to allow declarative syntax?

http://constraints.cs.washington.edu/web/ccss-uwtr.pdf

[iamralpht]

Grid StyleSheets are the natural outgrowth of that work: http://gridstylesheets.org/

One area I'm thinking about a lot right now is representing and editing constraints visually. I'm torn between doing a parser and just using JSON and making an editor. I'm leaning towards doing an editor though. It'd be mind blowing (to me, at least) to have a touch-driven tool for building touch-driven UIs...

If an editor works well then the syntax just needs to be lightweight enough for the editor to digest. I think state handling is also critical (CSS has pseudoselectors which allow for basic state-based interactions, video games often use HFSMs for character control and have editor UIs for building the state machines...).

So that's where my head's at right now. I want to do one more example with Slalom where one gesture drives two Manipulators (which is now possible since gesture recognition got moved out of the Manipulator). Then I'll try to do something that'll build a UI from JSON or text.

One thing I haven't thought about at all is how to make Slalom so that it can be introduced incrementally to an existing web app. I think that would be critical for driving adoption (but I also think it's too early for that yet). It's perhaps easier on native where you're already using AutoLayout or it's more natural to introduce a custom layout manager...

[kof]

I like the idea to have a JSON DSL for constraints. Its actually mostly very readable (e.g. mongodb) and doesn't require expensive parsing!

I think making layout constraints optional on top of normal css is the way to go to make it progressive enhancement like. For sure things need to be absolutely positioned etc.

Editor is not an easy task. Maybe we should look for something existing and then transform the output. I know 1 company working on such editor.

[kof]

All in all slalom is on a very good way to be a competitor to famo.us and I strongly believe this ideas will lead to a way better layout engine.

[kof]

Even if building an editor it needs to produce some JSON dsl. Which can be parsed then. Also imperative API can still be required for more complex cases.

[iamralpht]

Yes, totally agree. You always need good escape hatches to imperative code. I think the editor will be the most fun to work on and think about actually, so I'm enjoying the challenge. Even if it's only good for fairly simple things, it'll still be useful for building quick prototypes.

[kof]

It would be cool to define some sort of plan/roadmap. Define crieria for physics engine and layout engine to fulfill most popular tasks.

It should be someting like this

1. Define all use cases for physics
2. Define all use cases for constraints layout
3. Make all physics cases work imperatively
4. Make all layout cases work imperatively
5. Write tests for everything
6. Stabilize the API
7. Create a JSON dsl for declarative constraints
8. Build an editor on top of all this things

[kof]

This is a very big vision mate :)

[iamralpht]

I'm starting on the JSON and constraint parser (adapting the peg grammar from cassowary.js) so we should have something more to talk about soon.

I actually don't want to handle all cases of physics or layout--I know that there are a bunch of things I can't build with Slalom, and that's OK for now. If it just solves the classes of problems it tackles elegantly then it'll be a very useful tool :).

[kof]

What about actually more mongodb like JSON syntax:

instead of

"xyz.left == 0"

{'xyz.left': {$eq: 0}}

"width == scaleBox.right - scaleBox.left"

{width: {$eq: {
  $subtruct: ['scaleBox.right', 'scaleBox.left']
}}}

Its more verbose, but its easier to parse and more a dsl than just strings.

[kof]

Its like sql queries vs. mongodb queries. For me mongodb queries won.

[kof]

Just looked at what pegjs has generated: 1900LOC 58KB ... with JSON DSL you will get it way way smaller and faster.

[iamralpht]

Interesting -- why did the JSON syntax win out for MongoDB? Where is it more expressive than SQL?

I agree the generated code is way too large for real use on the web. I do kinda like the syntax though, especially as the linear constraints are very limited. Currently cassowary.js also includes one of these generated parsers (that's where I got the grammar.pegjs that I started with) which is unused, so there's a lot of clean up work to do.

I want to add array references (so you can do x[first] and x[i] and x[i-1] for expressing constraints between elements in a list) then I think the syntax is done.

One possibility is that Slalom could have a build tool that webpack runs to parse and crunch the syntax down to raw JS (like JSXTransformer for react); then we'd get the nice syntax and avoid the runtime and code size overhead...

[kof]

I think in mongo the win is because you a building the query using objects instead of strings, it makes it cleaner and less issues with escaping. But you might find different pros on this approach on the web. I am not sure how much of them do actually apply to slalom use case, just kinda liking it :)

[kof]

and yes transformation approach from string format to json dsl would be possible however not sure how to mark those things. JSX is clearly easier to define as what you have right now is basically js. In this case you would want to have some sort of xml block or something identifying the part.

[kof]

Transformation could be a next step but JSON DSL first ...

[iamralpht]

I was thinking that the whole description would live in a JSON file and then that whole file would get transformed. I want that eventually because I want to do a visual editor for a Slalom system...

[kof]

Then its very strict forward:

• slalom works with JSON only
• separate project for JSON DSL spec
• separate project which can transform string format to the JSON

[iamralpht]

Could always transform directly to code. Don't know if that's objectionable...

[kof]

Maybe yes ... still kinda liking more JSON syntax. Its basically writing constraints using javascript vs. some custom query language.

[kof]

Could be for sure 2 separate approaches and we will see which one wins. Both JSON DSL and string based can convert to code. Both can be implemented independent.

[iamralpht]

Yeah.. for now I think it's OK to have huge parsers, etc, and just get all the functionality in there. So long as the layering is good we can always do the big/slow bits as a compilation step.

The other stuff I want to get done right away is 2D gestures (pan, for 2d scrolling and the FB paper scaling example) and pinch-pan (which I'm not sure I can express as linear constraints on the fingers, we'll see).