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
structure.
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:
<http://emberapp.com/>http://emberapp.com/
<http://www.thecssawards.com/>http://www.thecssawards.com/
<http://cssmania.com/galleries/>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
<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
<http://www.mail-archive.com/[email protected]/msg00013.html>rendering
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
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
<<mailto:[email protected]>[email protected]> 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
<mailto:[email protected]>[email protected]
<http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel>http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel
_______________________________________________
lively-kernel mailing list
[email protected]
http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel
