Style
Locked
 
|
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
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.
|
|
|
Hi Casey -
I'm answering your query publicly because this may be confusing
to several people.
Yes, Lively bypasses the need for HTML and CSS and does
everything itself.
However, many possible clients use CSS as a vehicle for factoring
out style metrics (window title bar color, etc) in their web content
and, moreover, they expect to be able to approach things this
way.
It would be pretty easy, and probably a good thing, for Lively to
support this level of factored style. Thus, just as you may set
a number of preferences in localconfig.js, you might want to put your
window color scheme in a CSS file. It's not a big deal, but I
think it may be worth meeting the rest of the planet half-way on
this.
Much more important, though, is how would you like Lively to
look?
Thank you for requesting clarification
-------------------------------------
Dan, I'm a bit confused. There may be a piece of the puzzle I don't understand well, as I'm new to lively. As I understand it, lively largely bypasses HTML by rendering directly to the SVG canvas, correct? If this is the case, how would CSS help? |
|
|
In reply to this post by Dan Ingalls-4
Here are some pages of some design inspiration for any of you:
http://www.thecssawards.com/
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 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 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 <[hidden email]> wrote:
|
|
|
In reply to this post by Dan Ingalls-4
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
-------------------------------------
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 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 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 <[hidden email]> wrote: |
|
|
In reply to this post by Dan Ingalls-4
An important but often overlooked aspect of styling is typography. Does anyone have thoughts on how to use web fonts [2] with the Canvas implementation of Lively? Long term I have continued interest in the canvas implementation of Lively for its flexibility and purity. However, the canvas implementation of Lively does not use CSS because the canvas does not support CSS. And web fonts seem to require CSS3.
I recently mentioned that I'd prefer that styling in Lively ought to remain based on JavaScript and OLN. If CSS3 is necessary under the hood to provide rich web fonts in Lively SVG and Lively HTML5 that's fine - but it would be nice to be able to have custom web fonts in Lively Canvas as well.
It's not necessary to discuss this topic in order dress up Lively today - but rich typography is an aspect of styling which is often overlooked.
On Fri, Sep 10, 2010 at 8:36 AM, Dan Ingalls <[hidden email]> wrote:
|
«
Return to Lively Kernel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |