Beginners have trouble with it, because it's not what they expect to be a default setting when they start putting images in their paragraphs. I would like to propose changing this to:
And, possibly, moving both "p img.left" and "p img.right" to the fancy type plugin, since for most projects, they are not needed at all. But before I commit these changes, I'd like to hear everyone's thoughts. Agree? Disagree?
I like it though it would obviously not be backwards compatible. If you get enough thumbs up I'd definitely advertise it loudly on the list and site. It definitely something that trips me up as well though once I was aware of it I do the same thing too.
> Beginners have trouble with it, because it's not what they expect to > be a default setting when they start putting images in their > paragraphs. I would like to propose changing this to:
> And, possibly, moving both "p img.left" and "p img.right" to the fancy > type plugin, since for most projects, they are not needed at all. But > before I commit these changes, I'd like to hear everyone's thoughts. > Agree? Disagree?
> -- > -- > Christian Montoya > christianmontoya.net
thatcher.christop...@gmail.com> wrote: > I like it though it would obviously not be backwards compatible. If you > get enough thumbs up I'd definitely advertise it loudly on the list and > site. It definitely something that trips me up as well though once I was > aware of it I do the same thing too.
> +1
> thatcher
> On Thu, Nov 6, 2008 at 8:01 PM, Christian Montoya <siro...@gmail.com>wrote:
>> Hello all,
>> There's one line of Blueprint that I always delete or change. It's >> this, from typography.css:
>> Beginners have trouble with it, because it's not what they expect to >> be a default setting when they start putting images in their >> paragraphs. I would like to propose changing this to:
>> And, possibly, moving both "p img.left" and "p img.right" to the fancy >> type plugin, since for most projects, they are not needed at all. But >> before I commit these changes, I'd like to hear everyone's thoughts. >> Agree? Disagree?
>> -- >> -- >> Christian Montoya >> christianmontoya.net
In my Sass port of blueprint, I have a stylesheet called "scaffolding". It's a collection of styles that make for good defaults, but are recommended that you remove them once you start doing any serious styling. I think it would be great if blueprint adopted this approach of encouraging people to remove a link to a stylesheet instead of removing styles from blueprint stylesheets. The latter approach makes it very hard to upgrade. I would fully endorse moving these styles out of core and especially to a "scaffold" stylesheet. Here's my scaffolding.sass file: http://github.com/chriseppstein/compass/tree/master/frameworks/bluepr...
> Beginners have trouble with it, because it's not what they expect to > be a default setting when they start putting images in their > paragraphs. I would like to propose changing this to:
> And, possibly, moving both "p img.left" and "p img.right" to the fancy > type plugin, since for most projects, they are not needed at all. But > before I commit these changes, I'd like to hear everyone's thoughts. > Agree? Disagree?
> -- > -- > Christian Montoya > christianmontoya.net
that a very interesting idea and I think very useful to future development in blueprint as a true framework. scaffolding in most 'railable' frameworks though doesn't imply something that would be removed later in development, but rather something that saves the effort of hand writing a common pattern. I would encourage thinking along the lines of utilities to provide scaffolding but reserve it for custom style names that translate to simplify blueprint patterns. This end goal should be to never touch the core but override it with additional css files included later.
On Thu, Nov 6, 2008 at 11:27 PM, Chris Eppstein <ch...@eppsteins.net> wrote: > In my Sass port of blueprint, I have a stylesheet called "scaffolding". > It's a collection of styles that make for good defaults, but are recommended > that you remove them once you start doing any serious styling. I think it > would be great if blueprint adopted this approach of encouraging people to > remove a link to a stylesheet instead of removing styles from blueprint > stylesheets. The latter approach makes it very hard to upgrade. I would > fully endorse moving these styles out of core and especially to a "scaffold" > stylesheet. > Here's my scaffolding.sass file:
>> Beginners have trouble with it, because it's not what they expect to >> be a default setting when they start putting images in their >> paragraphs. I would like to propose changing this to:
>> And, possibly, moving both "p img.left" and "p img.right" to the fancy >> type plugin, since for most projects, they are not needed at all. But >> before I commit these changes, I'd like to hear everyone's thoughts. >> Agree? Disagree?
>> -- >> -- >> Christian Montoya >> christianmontoya.net
> There's one line of Blueprint that I always delete or change. It's
> this, from typography.css:
> p img { float: left; margin: 1.5em 1.5em 1.5em 0; padding: 0; }
+1. I prefer having a specific left and right, and keep the default non
floating.
On Fri, Nov 7, 2008 at 2:01 AM, Christian Montoya <siro...@gmail.com> wrote:
> Hello all,
> Beginners have trouble with it, because it's not what they expect to
> be a default setting when they start putting images in their
> paragraphs. I would like to propose changing this to:
> And, possibly, moving both "p img.left" and "p img.right" to the fancy
> type plugin, since for most projects, they are not needed at all. But
> before I commit these changes, I'd like to hear everyone's thoughts.
> Agree? Disagree?
> --
> --
> Christian Montoya
> christianmontoya.net
> +1. I prefer having a specific left and right, and keep the default > non floating.
+1 for me too. "Backwards compatibility" can be obtained by leaving the old stylesheet in place on your site. Why upgrade a stylesheet on a site with a finished design. Obviously redesigns could be an issue but until blueprint reaches the level 100% common sense it needs to keep evolving and not get stuck up on backwards compatability (let the browser makers worry about that).
> Beginners have trouble with it, because it's not what they expect to
> be a default setting when they start putting images in their
> paragraphs. I would like to propose changing this to:
> And, possibly, moving both "p img.left" and "p img.right" to the fancy
> type plugin, since for most projects, they are not needed at all. But
> before I commit these changes, I'd like to hear everyone's thoughts.
> Agree? Disagree?
> --
> --
> Christian Montoya
> christianmontoya.net
Excuse me! This was a default that made sense to me. I always thought
the "float: left" is intended to keep the baseline grid intact.
If I place an an image within a paragraph and don't float it (take it
out of the regular document "flow"), the following lines will be glued
to the images' bottom, right?
Do i get HTML/CSS wrong or are you aiming to destroy this awesome
feature?
In case i got things right, you guys get a major big minus 1 from me.
> Excuse me! This was a default that made sense to me. I always thought > the "float: left" is intended to keep the baseline grid intact.
> If I place an an image within a paragraph and don't float it (take it > out of the regular document "flow"), the following lines will be glued > to the images' bottom, right? > Do i get HTML/CSS wrong or are you aiming to destroy this awesome > feature? > In case i got things right, you guys get a major big minus 1 from me.
iroybot, I think I can give you a reason why some images would belong in the normal document flow. One example of such would be sparklines, and another would be emoticons.
The only reason you want to "pull" an image out of the normal flow is if it does not belong in the flow to begin with. If you put an IMG inside a P, then it makes more sense semantically for that IMG to be an inline bit of content (like a sparkline or an emoticon) than a picture of a dog (as in the example page). Blueprint started out with a focus on making webpages pretty by default, but in order to make it into a framework that is widely used and flexible, it needs to be developed with a "big picture view" of how many pages on the web would be coded semantically.
I hope you'll understand this decision, as it has already been committed into version 0.8.
|
