[lively-kernel] Style

Philip Weaver philmaker at gmail.com
Fri Sep 10 08:45:41 CEST 2010


Here are some pages of some design inspiration for any of you:

http://emberapp.com/
http://www.thecssawards.com/
http://cssmania.com/galleries/

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 SASS <http://sass-lang.com/> 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 rendering of
some object-based hypertext
markup<http://www.mail-archive.com/general@livelykernel.sunlabs.com/msg00013.html>
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 illustration.

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.

Sincerely,
Philip

On Thu, Sep 9, 2010 at 6:45 PM, Dan Ingalls <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 months.
>
>         - Dan
>
> _______________________________________________
> lively-kernel mailing list
> lively-kernel at hpi.uni-potsdam.de
> http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.hpi.uni-potsdam.de/archive/lively-kernel/attachments/20100910/1cb36599/attachment-0001.htm 


More information about the lively-kernel mailing list