Default css layout

[gas...@gmail.com]

Hi,

I follow the doc in smashing magazine
http://www.smashingmagazine.com/2008/06/26/flexible-layouts-challenge-for-the-future/

and found an awesome css layout tool called YAML (not that YAML for
Rails configuration)
http://www.yaml.de/

with online layout builder
http://builder.yaml.de/

It's well doocumented, looks pretty, and looks very easy to use.

Since we've discussed css layout like 'blueprint' some days ago, YAML
could be a new candidate in our sight.

--
Fred

[laureano arcanio]

That framework looks nice, I've planning to  make lymon running with something alike, on top of the Template engine I've made ( Documents ).
I'll look further this kind of packages to choose one that make it easy for the end user.

Thanks for the Links and info !

[Dean Landolt]

Beautiful.

I'd been using Boilerplate but nothing's really happened with it for quite a while (unlike TG, it does look dead)...

YAML looks pretty pretty sweet -- and judging by the examples, incredibly flexible. As configurable as it is, we could even create a paster template to generate templates like controllers.

[Mark Ramm]

> YAML looks pretty pretty sweet -- and judging by the examples, incredibly
> flexible. As configurable as it is, we could even create a paster template
> to generate templates like controllers.

Sounds like something that might fit right into tg.devtools.

[Kless]

YAML looks a great framework as Blueprint.

But there is also another great framework developed by Yahoo, the YUI
Library CSS Tools [1]. It has great features and a great
documentation.

Note that YAML is licensed under the Creative Commons Attribution 2.0
Germany License. And both Blueprint and YUI are licensed under New
BSD.


[1]
http://developer.yahoo.com/yui/reset/
http://developer.yahoo.com/yui/base/
http://developer.yahoo.com/yui/fonts/
http://developer.yahoo.com/yui/grids/

[Dean Landolt]

Good point: a CC attribution license is probably is a non-starter for an MIT licensed project -- but I've looked at both Blueprint and Yahoo and a few others and YAML strikes me as the nicest tradeoff between expressive layout and clean semantics (though it still has a few too many of those c33r and such classes all over, but oh well)

[Daniel Fetchinson]

> Good point: a CC attribution license is probably is a non-starter for an MIT
> licensed project

I'll have to reveal my ignorance on licenses: why is this the case?

> -- but I've looked at both Blueprint and Yahoo and a few
> others and YAML strikes me as the nicest tradeoff between expressive layout

> and clean semantics (though it still has a few too many of those *c33r* and

> such classes all over, but oh well)

So far YAML seems the best to me too. Would be great to see it in tg
as the default css framework.

Cheers,
Daniel

>> YAML looks a great framework as Blueprint.
>>
>> But there is also another great framework developed by Yahoo, the YUI
>> Library CSS Tools [1]. It has great features and a great
>> documentation.
>>
>> Note that YAML is licensed under the Creative Commons Attribution 2.0
>> Germany License. And both Blueprint and YUI are licensed under New
>> BSD.
>>
>>
>> [1]
>> http://developer.yahoo.com/yui/reset/
>> http://developer.yahoo.com/yui/base/
>> http://developer.yahoo.com/yui/fonts/
>> http://developer.yahoo.com/yui/grids/

--
Psss, psss, put it down! - http://www.cafepress.com/putitdown

[Dean Landolt]

The CC attribution license would require the TG quickstart to have attribution information in the manner specified by the author (a link back to the YAML page). No big deal. But I'm pretty sure it would also require that TG users don't rip that attribution link out of their page template -- which would be a burdensome requirement of an otherwise permissively-licensed (MIT -- just leave the copyrights in the source files) project.

[Daniel Fetchinson]

> The CC attribution license would require the TG quickstart to have
> attribution information in the manner specified by the author (a link back
> to the YAML page). No big deal. But I'm pretty sure it would also require
> that TG users don't rip that attribution link out of their page template --
> which would be a burdensome requirement of an otherwise
> permissively-licensed (MIT -- just leave the copyrights in the source files)
> project.

This is indeed quite annoying and maybe will stop tg from using yaml after all.
On the positive side, not every page has to contain a backlink,
quoting from yaml.de:

"For the free use of the YAML framework, a backlink to the YAML
homepage (http://www.yaml.de) in a suitable place (e.g.: footer of the
website or in the imprint) is required."

Which I understand to mean that it is enough to link back to yaml.de
on a single page (e.g. imprint page) for the whole web site.

What is not clear to me from
http://www.yaml.de/en/license/license-conditions.html is what are the
conditions of redistribution for a non-commercial situation. Say a
backlink is provided on turbogears.org can the tg team bundle yaml for
download in the tg distribution? If yes, tg users are required to add
a backlink? Are they required to know that tg contains something which
requires this?

Cheers,
Daniel

[Jorge Godoy]

On Wednesday 02 July 2008 01:55:09 Daniel Fetchinson wrote:
> > The CC attribution license would require the TG quickstart to have
> > attribution information in the manner specified by the author (a link
> > back to the YAML page). No big deal. But I'm pretty sure it would also
> > require that TG users don't rip that attribution link out of their page
> > template -- which would be a burdensome requirement of an otherwise
> > permissively-licensed (MIT -- just leave the copyrights in the source
> > files) project.
>
> This is indeed quite annoying and maybe will stop tg from using yaml after
> all. On the positive side, not every page has to contain a backlink,
> quoting from yaml.de:
>
> "For the free use of the YAML framework, a backlink to the YAML
> homepage (http://www.yaml.de) in a suitable place (e.g.: footer of the
> website or in the imprint) is required."
>
> Which I understand to mean that it is enough to link back to yaml.de
> on a single page (e.g. imprint page) for the whole web site.
>
> What is not clear to me from
> http://www.yaml.de/en/license/license-conditions.html is what are the
> conditions of redistribution for a non-commercial situation. Say a
> backlink is provided on turbogears.org can the tg team bundle yaml for
> download in the tg distribution? If yes, tg users are required to add
> a backlink? Are they required to know that tg contains something which
> requires this?

So far we are 100% free to write opensource and commercial code.

So far we are not required to recognize that we are using a specific framework
(and believe me, it is easier to add a new thing to some environments when
absolutely nothing changes visually from what was there before, specially to
big corporations).

I see this addition as a drawback to using TG and my vote is -1 to anything
that makes this a concern.

If we are having problems figuring it out and would have to "hire a lawyer" to
check, then what would take this requirement from our users? Our word? I
don't believe that we are here to support anyone's business decision,
specially if one day we might be questioned about the endorsement.

So, -1 from me to add this.

Make it an external project, make it a module... But never a dependency or
requirement for any application where the author himself / herself didn't ask
for it.

--
Jorge Godoy <jgo...@gmail.com>

[Florent Aide]

On Wed, Jul 2, 2008 at 1:13 PM, Jorge Godoy <jgo...@gmail.com> wrote:
>
> So far we are 100% free to write opensource and commercial code.
>
> So far we are not required to recognize that we are using a specific framework
> (and believe me, it is easier to add a new thing to some environments when
> absolutely nothing changes visually from what was there before, specially to
> big corporations).
>
> I see this addition as a drawback to using TG and my vote is -1 to anything
> that makes this a concern.

-1 on this. Default tg quickstart and tools should be 100% BSD/MIT
whatever that does not require the final product to do anything
special.
If we include some thing in the default template or tools people may
use it without understanding the real requirement. And then problems
will pop-up with lawers and we'll have people complaining around that
we did not warn them (even if we did).

Please avoid such things at all costs. If you want to use this tools,
then create a plugin and make sure you can easy_install it. Then
default TG2 installs will be safe.

I (like Jorge) work in an environment were getting authorization to
use some tool is put under scrutiny by an army of lawers and non-tech
people who will pick any excuse to refuse your techno and impose some
"standard choice" (ASP .NET)

I want to be 100% on the safe side and make sure those people won't
have an easy excuse like this one to refuse tg2.

Florent.

[Daniel Fetchinson]

Makes sense, I'm with you guys on this one.

Cheers,
Daniel

[Kevin Horn]

On Wed, Jul 2, 2008 at 6:13 AM, Jorge Godoy <jgo...@gmail.com> wrote:

So, -1 from me to add this.

Make it an external project, make it a module...  But never a dependency or
requirement for any application where the author himself / herself didn't ask
for it.

Better yet, just write a tutorial/recipe on how to use YAML + TG, and clearly state the requirement in the tutorial.

Kevin Horn

[Dean Landolt]

Good point.

But I would still argue TG could use a sensible-default css framework. The benefit of a good style reset alone is pretty big, plus the default TG styles don't strike me as the greatest base.

I just looked at some of the more popular frameworks and it looks like cc attribution is quite popular. Blueprint, one of the most popular it seems, is MIT, so that works. There were a few LGPLs as well, which is a lot more permissive than CC Attribution (though I bet there'd still be some objections)...

I did come across a little pythonic something called CleverCSS which is just an easy_install away. I haven't played with it yet, but it looks promising. I don't know if it has the kind of sensible default layout(s) I'm looking for, but I'd be willing to try to hack it together.

[Kevin Horn]

On Wed, Jul 2, 2008 at 12:52 PM, Dean Landolt <de...@deanlandolt.com> wrote:

Good point.

But I would still argue TG could use a sensible-default css framework. The benefit of a good style reset alone is pretty big, plus the default TG styles don't strike me as the greatest base.

I just looked at some of the more popular frameworks and it looks like cc attribution is quite popular. Blueprint, one of the most popular it seems, is MIT, so that works. There were a few LGPLs as well, which is a lot more permissive than CC Attribution (though I bet there'd still be some objections)...

I did come across a little pythonic something called CleverCSS which is just an easy_install away. I haven't played with it yet, but it looks promising. I don't know if it has the kind of sensible default layout(s) I'm looking for, but I'd be willing to try to hack it together.

CleverCSS looks more like a "dynamic CSS tool" than a layout framework.  It could probably be used to build a layout framework though. Even if you didn't use it for that, it could probably be used in a number of other ways for TG development.  This is a very intriguing little tool.  I'm already wondering about how to integrate/use it with Widgets.  I can think of lots of situations in which a dynamically created CSSSource widget could be useful, for example.  Thanks for the link.

Kevin Horn