I think the main point here is that while this would certainly be very useful for some, many others might make no use of it, at worst cluttering the UI for them - the criteria for adding it should be that it's broadly applicable to most users.
That's somewhat of a subjective measurement, but hopefully it provides some clarity. On Wed, Oct 14, 2015 at 4:10 PM, <[email protected]> wrote: > Perhaps that's one difference in how we look at this. If the content > editors have any technical inclination at all, like you'll find at a small > startup (and let's be honest, CSS isn't rocket science, you can learn the > basics before lunch on Codecademy) then they can edit the CSS themselves. > > With the 'draft' mode for pages this means they can do all the changes of > "Hmm, maybe that text there should be a little bigger" or "Can the section > headers be dark grey?" without requiring a developer or designer to sit > there and use two peoples time to tweak minor things. And if anything more > technical comes up ("Can the bullet points be smiley faces?") then instead > of requiring a new push to the server to tweak a template, it takes 30 > seconds to say "Sure" and change the CSS for the page. > > At the end of the day it really doesn't matter to me if it's in mainline > Mezzanine, it's easy enough to hack in with the EXTRA_MODEL_FIELDS setting. > I was just pointing out a feature that I've found to be a force-multiplier > for faster development and more efficient use of everyone's time (which is > what we all want at the end of the day, unless you're a consultant getting > paid by the hour) that I thought would be a useful feature out of the box > for those designers who aren't inclined to dig into the code. > > - David > > > On Tuesday, October 13, 2015 at 9:30:51 PM UTC-7, Eduardo Rivas wrote: >> >> I tend to follow a different approach with my client projects. With >> frameworks like Bootstrap you get a UI kit you can customize and provide >> that to your users. For example, when the content editors want to modify >> the style of a button, they can add a modifier class to it. The same goes >> for pretty much any other element. This has the added benefit of being a >> composable approach, allowing to stack multiple modifier clases that are >> available through out the site, not only specific pages. >> >> It also feels weird to store style information in the database. At least >> in my experience, it is not the content author's responsibility to tweak >> styling. It is the designer and the developer who have to provide the tools >> necessary to give the content writers enough flexibility but staying within >> the design spec. Hence the approach I explained above (using modifier >> classes). >> >> Now, that's just an opinion, not really an objective argument. If a >> custom CSS field gains traction, I would ask it to be disabled/enabled via >> a setting, just like the blog post featured image. Definitely not a level >> of control I want to give to the users. >> > -- > You received this message because you are subscribed to the Google Groups > "Mezzanine Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- Stephen McDonald http://jupo.org -- You received this message because you are subscribed to the Google Groups "Mezzanine Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
