[lively-kernel] Style

Dan Ingalls danhhingalls at gmail.com
Fri Sep 10 15:36:27 CEST 2010

Many thanks, Phil -

I agree.   It's especially nice to hear others feeling that the 
Lively approach is a good one.  I agree with your last "In summary" 
paragraph.  So that would narrow the topic to choosing a few looks 
and figuring out how to design some nice declarative descriptions of 
style (there are a few pieces of this already in Lively) and object 

We'll get that prototype page out where we can all play with it

All:  Keep those comments coming

	- Dan
>Here are some pages of some design inspiration for any of you:
>Dan said: If you happen to know CSS, please send along 
>suggestions about how you would most like to see it supported.
>I don't consider myself a W3C CSS guru nor would I really like to 
>be. I'm not convinced that Lively ought to try implement W3C CSS in 
>its entirely without object literal notation. The absence of W3C CSS 
>based layout hassles in Lively is one of the reasons I began using 
>Lively. Anyway, overall I'm more a fan of resizing constraints and 
>corner pinning that layout managers when working with Morphic. A 
>tiny additional factor is that I do not believe that the W3C CSS 
>spec allows for compound borders. To me that's an oversight however 
>it is very small.
>Here are three additional reasons why I think it's not necessary to 
>exactly implement W3C external W3C CSS stylesheets in Lively: 1. 
>Continue to use the object literal notation of JavaScript. 2. The 
>recent appearance of programmatic CSS frameworks such as 
><http://sass-lang.com/>SASS and perhaps others suggest that 
>programmatic styling is nice to have. 3. One of the original goals 
>of Lively was to minimize the number of technologies in play. Casey 
>recently mentioned this. I would actually embrace the 
>of some object-based hypertext markup for for passages of text 
>inside of Lively before having interest in incorporating the W3C CSS 
>specification in external CSS documents and without OLN. But I'd 
>welcome to the full spirit of CSS using OLN.
>Furthermore, I don't like that W3C CSS embedded inline within an 
>HTML document overrides any CSS in an external stylesheet or in the 
>HTML header. I'm not recalling how Lively style classes work exactly 
>but I prefer that any linked external styling would override or have 
>priority over local styling within the class of an object. This is 
>one of the problems I have with CSS - because it's much more natural 
>to provide default styling for a component or morph while working 
>with the morph's class that having to jump over to separate style 
>sheets during development. Some may argue that it's wrong to style 
>locally within an object's class - but external styling ought to be 
>at least able to override local styling properties which had been 
>embedded within within some handler of an object's class. Not the 
>other way around.
>Stellar web design involves much more that CSS. Today, web designers 
>create most of their artwork in tools such as Illustrator, 
>Photoshop, and Fireworks. In the links I listed above, try to forget 
>that a couple of those links have the letters css in them. Lively 
>has a tremendous opportunity to disrupt the graphic design for the 
>web and even the industry itself. We ought to not forget this. It 
>may not be a priority. Educational goals and such might be more 
>important. Object-oriented web development might be more important. 
>But we shouldn't ignore this tremendous opportunity. Lively could 
>allow declarative and nested construction of shapes and paths and 
>styling (inline or class-based) using nested structures of object 
>literal notation. SVG allows this, canvas does not of course: but 
>Lively ought to. Make a declarative OLN API for Lively with similar 
>intent to Logo perhaps to be able to draw complicated paths more 
>easily based on directions/directives. And later overall Lively and 
>Morphic do deserve more focus on capabilities for vector 
>In summary, I propose that using OLN for drawing directives might be 
>more important than implementing W3C CSS in external stylesheets. A 
>significant extent of what we consider style typically occurs in 
>graphics editors - and Lively SVG or Lively Canvas has an 
>opportunity to shake things up. If Lively were to try to implement 
>the full capabilities of W3C CSS in spirit using JavaScript OLN 
>inside linked stylesheets, I think that is probably fantastic - but 
>I'd suggest that it might also support specifying layout but using 
>layout managers in addition to or instead of the technicalities of 
>float, clear, etc.
>Anyone feel free to correct any of this or argue. Sorry it's verbose 
>and I hope these opinions are clear. :-) Maybe I'll try to send some 
>styles I like later, but for now there are the three links above.
>On Thu, Sep 9, 2010 at 6:45 PM, Dan Ingalls 
><<mailto:DanHHIngalls at gmail.com>DanHHIngalls at gmail.com> wrote:
>Good People,  it's time to decorate!
>It has become clear to me that Lively will only be a toy to many 
>people as long as it continues to look like geekware.  There are two 
>things required to improve our look:   artistic sense, and a knack 
>for CSS or similar controls.  I have neither.
>But I have friends...
>All you lurkers out there:  It's time to give Lively a few minutes 
>of your time
>         Choose one or two web pages that you love, share the links with us,
>         and say what you like about them that's relevant to Lively
>         If you happen to know CSS, please send along suggestions
>         about how you would most like to see it supported.
>In the next day or two, we'll put a prototype page out in the wiki 
>that you can redecorate with your favorite style.  That will give us 
>a sense of what's needed to get a decent range of style and how to 
>keep it lively.
>It may seem stupid to spend time on appearance, but it could be the 
>most significant thing we do for support in the next couple of 
>         - Dan
>lively-kernel mailing list
><mailto:lively-kernel at hpi.uni-potsdam.de>lively-kernel at hpi.uni-potsdam.de
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.hpi.uni-potsdam.de/archive/lively-kernel/attachments/20100910/e2fd12b1/attachment.htm 

More information about the lively-kernel mailing list