w3future.com

Site Search
Site Colors
Site E-mail Me

Syn Atom 1.0
Syn RSS 0.91
Syn Subscribe

CC Licensed
Geo URL
With Radio

Accidental web-archeology

While searching for something completely different, I found this message from August 1993. What if Marc Andreessen had written “OK, we'll add an error indicator”.

Re: A note on the design of markup languages

Matthew Thomas pointed to me some days ago. I have to respond (though a bit late) because I'm a big fan of Matthew's ideas about UI design. They are a lot more refreshing and inspiring than the usual 'look at the Mac' UI suggestions. At Q42 we try to avoid a save button in our web applications since Matthew wrote When good interfaces go crufty.

About Matthew's note: I don't really agree. The main reason is that it's a bit late. RSS always has had links in the contents of elements. For the sake of consistency it's better to leave it that way, even for new elements. Matthew's main argument is that an attribute would work better for styling with CSS. But making a arbitrary XML document readable with CSS should be considered nothing more than a trick, XSL should be used instead. The fact that CSS makes better use of attributes than element content, is a design issue of CSS. If that doesn't fit well with the RSS format, then CSS shouldn't be used with RSS.

I do agree with Matthew's argument that because the URIs are intended more for machine consumption than human consumption, it should be an attribute, rather than the contents of an element. When I design XML formats I always put URIs in attributes, even if they are the only attributes in the whole format. In this case I would have preferred the rdf:resource attribute, because that's the suggested use of the element, and it's also used with the admin elements.

The friendlier Loell

Since the last Loell update, the language has become a lot more user friendly. Precedence and unary operators are implemented, so arithmetic formulas now work as expected. The ; expression separator is now optional at the end of a line. Extra indentation on new lines prevents the insertion of a separator. Lists are now built-in. The list syntax uses the ; expression separator too, which is also optional at the end of a line. Lists have support for Ruby-like collect, in the form of two methods: all and some. The difference is in the handling of failures:

[1; 'a'; 3] all {that*2} // --> failure
[1; 'a'; 3] some {that*2} // --> [2; 6]

Another new feature is an 'else' for closures, which together with the (runtime) assertions gives a clean syntax, similar to Haskell's guards.

Number.sign = {this gt 0;  1}
            | {this lt 0; -1}
            | 0

ContentEditable in Mozilla 1.3

My colleague Lon Boonen has built a much improved version of contentEditable for Mozilla. It uses the new designMode feature in Mozilla 1.3, which makes cursor and selection handling much better. And, because at Q42 we can't resist to sometimes just give things away for free, you can download it from the Xopus site.

Assertions in Loell

I've found 2 good uses of the new goal directed execution of Loell. One is that failure together with else works the same as throw and catch in Javascript. The other one (maybe rather obvious) is assertions. To the shapes example I added this precondition to the moveTo method:

pos {.x isA Number gt 0;.y isA Number gt 0};

Which means that pos has to be an object with 2 properties, x and y, which both have to be of type Number, and greater than 0. You see that you don't have to write .x isA Number;.x gt 0. This is because the methods that previously returned a boolean value, now return this (the left-hand expression) instead of true. In Icon tests return the right-hand expression with success, but I figured the left-hand side makes more sense in an OO language.

Goal directed programming with Loell

Inspired by an article on Ltu today, I implemented a goal directed programming feature into Loell. No more booleans, instead there are now success and failure. When an expression returns failure, the whole closure immediately returns failure. This was only a small change in the code, and the examples hardly changed. I only had to add else success to the while code to indicate that failing the while test is not a failure. I haven't found a really cool example for this yet, but you can try the following in the shapes example:

scribble each {that isA Shape}

This will test if the scribble list only contains shapes. (Remember that that is the default method argument)