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
>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.
>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
>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...
More information about the lively-kernel