> 1. XHTML instead of HTML 4.01. This was a surprising change in > behavior, wasn't XHTML the old default? Now this is just something else > I have to go and change in app.cfg for every single project I create.
All the templates have to be valid XHTML, but the output is HTML 4. Right now not all browsers handle XHTML as well as we would like, so it is much easier to write cross browser pages when the output is HTML 4. If this gets fixed (we can always dream, can't we?) it is just a simple option to switch. But for now people are going to have a much better experience with HTML output, so I think the default should not change here. > 2. A default style.css. Creating a new file has slightly more overhead > than modifying an existing style. Does anyone NOT create > /static/css/style.css first thing after a new project? I would be > surprised. Plus with all the new tools being added, there is bound to > be some default style included anyway; see the #pageLogin style now > included in master.kid by default. This makes sense to me, but I can't really think what ought to be in this style.css file. We could probably throw something in that that makes the default page look good... > 3. As you may have read, I think attaching Identity to an app should > look a lot simpler if it's going to be in the default project. Right > now it adds an immediate learning curve because "hey, what's that > stuff?" There was a proposal about this yesterday, and I think Jeff Watkins was looking into it. If it happens it will reduce the identity related code in a quickstarted application to two lines. > 4. mochikit_all. This config option just stands out to me. I can > configure the output format and encoding of my Kid templates, but this > option flat out inserts some markup. Besides the format and encoding > options, I feel like my template structures are entirely under my > control, only stuff I put in there will be in there. Maybe I'm just > really picky, but I feel like a new tag coming from a config option > undermines that control. Anyway, I could just leave this disabled and > add MochiKit manually if it ruffles my feathers so much... There are applications where you pretty much know you are going to want mochikit everywhere. Isn't mochikit_all turned off by default? If you are worried about stuff showing up in your templates that you did not "put there yourself" mochikit_all is the least of your worries, as widgets can bring in whatever javascript and CSS they need. If it is easy to use, and easy to understand, and it saves me work, then I think automatically importing javascript and CSS is totally reasonable. And in my mind mochikit_all meets all three of those requirements. So, my vote would definitely be to keep it. The alternatives all pretty much suck ;) -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears Trunk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk -~----------~----~----~----~------~----~------~--~---
