rgchris / scripts Goto Github PK

load-markup "<?xml ?><!DOCTYPE>" = [<!--?xml ?--> " "]

I wish [<?xml ?> <!DOCTYPE>]

Both [<t/>] and [<t></t>] produce same output, [ <t> _ ]. IMO first case should result in [ <t/> _ ]. (But a first attempt gave troubles in to-path)

... so must redefined by hand:

also: func [x [<opt> any-value!] y [<opt> any-value!]] [:x]

Or use new syntax: ALSO-DO or AFTER

It's impossible to make tab-like (borders just on one side) elements.

I begrudgingly started getting Draem's default CSS into semi-tolerable organizational shape (any feedback appreciated, live site).

Next step was to consider the integration of CSSR into Draem. So I started looking into it.

There are a number of questions I have. But one criterion that emerged from the get-go about a CSS abstraction layer was to recognize the reality that CSS is a nuisance, and one often needs to "debug" at the level the browser understands. This is also the level at which most questions will be asked--since it is not realistic to expect people on StackOverflow to know CSSR at this point in time.

Hence I believe the ability to pass-through comments from the CSSR source level such that they show up in the relevant CSS locations is crucial. If I cannot get comments to somehow "pass through" to the output layer (when not generating minified output) then it would be a problem in seeking help or debugging.

There is opportunity here, I think. In a CSS layer capable of computation, the comments should preserve the source expression. So if in CSSR you could somehow express a value as foo - bar and get 10px, then at the evaluation site you could get property: 10px; /* foo - bar */

But I think a nice generalized documentation format that boiled down into CSS documentation (if needed) would be very helpful.