specificity wars

[CristinaSolana]

We should consider using less id selectors and possibly, only including normalization when it comes to the box model in screen.css, it causes specificity wars when working with custom themes.

For example:

#column-group-beta p {padding: 10px 0 0 0;}
makes it so that I have to do something like:
#column-group-beta .some-class-here p {padding: 0;}

We should just have a base style for p {} that can then be overriden in custom themes like so: p {} or if more specificity needed something like: .foobar p {} should suffice

[betweenbrain]

I'm all for using less ID selectors. Much of that, when it comes to
specifics like your example, is a throw back to original (circa January
2009) version of Costruct. We probably won't need any ID selectors in
screen.css other than for the layout and menu CSS (flyout). I'm open to any
suggestions or changes that you want to make.

Can you clarify what you mean by only including normalization when it comes
to the box model in screen.css? What changes would you make to it?

Best,

Matt Thomas
Founder betweenbrain http://betweenbrain.com/™
Lead Developer Construct Template Development
Frameworkhttp://construct-framework.com/
Phone: 203.632.9322
Twitter: @betweenbrain
Github: https://github.com/betweenbrain

On Mon, Oct 10, 2011 at 10:40 AM, Cristina Solana <
[email protected]>wrote:

We should consider using less id selectors and possibly, only including
normalization when it comes to the box model in screen.css, it causes
specificity wars when working with custom themes.

For example:

#column-group-beta p {padding: 10px 0 0 0;}
makes it so that I have to do something like:
#column-group-beta .some-class-here p {padding: 0;}

We should just have a base style for p {} that can then be overriden in
custom themes like so: p {} or if more specificity needed something
like: .foobar p {} should suffice

Reply to this email directly or view it on GitHub:
https://github.com/betweenbrain/construct5-pro/issues/2

[CristinaSolana]

By normalization, I mean basic resets for p, ul, etc, but never anything specific like: #id p {} or even .class p {}, anything that is different in a specific place other than general should be left to the custom markup.
Cheers,

Cristina Solana
Nightshift Creative

Matt Thomas [email protected] wrote:

I'm all for using less ID selectors. Much of that, when it comes to
specifics like your example, is a throw back to original (circa January
2009) version of Costruct. We probably won't need any ID selectors in
screen.css other than for the layout and menu CSS (flyout). I'm open to any
suggestions or changes that you want to make.

Can you clarify what you mean by only including normalization when it comes
to the box model in screen.css? What changes would you make to it?

Best,

Matt Thomas
Founder betweenbrain http://betweenbrain.com/;™
Lead Developer Construct Template Development
Frameworkhttp://construct-framework.com/;
Phone: 203.632.9322
Twitter: @betweenbrain
Github: https://github.com/betweenbrain

On Mon, Oct 10, 2011 at 10:40 AM, Cristina Solana <
[email protected]>wrote:

We should consider using less id selectors and possibly, only including
normalization when it comes to the box model in screen.css, it causes
specificity wars when working with custom themes.

For example:

#column-group-beta p {padding: 10px 0 0 0;}
makes it so that I have to do something like:
#column-group-beta .some-class-here p {padding: 0;}

We should just have a base style for p {} that can then be overriden in
custom themes like so: p {} or if more specificity needed something
like: .foobar p {} should suffice

Reply to this email directly or view it on GitHub:
https://github.com/betweenbrain/construct5-pro/issues/2

Reply to this email directly or view it on GitHub:
https://github.com/betweenbrain/construct5-pro/issues/2#issuecomment-2348032

[betweenbrain]

There shouldn't be any normalization targeting any IDs. Geez, I hope I
didn't add any. If I did, you can kick me next time that you see me.

The normalization is in the top portion of screen.css. Below it is the base
styles. Are you possibly looking at those?

That said, there is some basic style applied to some ID's, like in
your example. Those can probably go away as you have suggested. Do you want
to take a pass at what you'd change?

Best,

Matt Thomas
Founder betweenbrain http://betweenbrain.com/™
Lead Developer Construct Template Development
Frameworkhttp://construct-framework.com/
Phone: 203.632.9322
Twitter: @betweenbrain
Github: https://github.com/betweenbrain

On Mon, Oct 10, 2011 at 11:07 AM, Cristina Solana <
[email protected]>wrote:

By normalization, I mean basic resets for p, ul, etc, but never anything
specific like: #id p {} or even .class p {}, anything that is different in a
specific place other than general should be left to the custom markup.
Cheers,

Cristina Solana
Nightshift Creative

Matt Thomas [email protected] wrote:

I'm all for using less ID selectors. Much of that, when it comes to
specifics like your example, is a throw back to original (circa January
2009) version of Costruct. We probably won't need any ID selectors in
screen.css other than for the layout and menu CSS (flyout). I'm open to any
suggestions or changes that you want to make.

Can you clarify what you mean by only including normalization when it comes
to the box model in screen.css? What changes would you make to it?

Best,

Matt Thomas
Founder betweenbrain http://betweenbrain.com/;™
Lead Developer Construct Template Development
Frameworkhttp://construct-framework.com/;
Phone: 203.632.9322
Twitter: @betweenbrain
Github: https://github.com/betweenbrain

On Mon, Oct 10, 2011 at 10:40 AM, Cristina Solana <
[email protected]>wrote:

We should consider using less id selectors and possibly, only including
normalization when it comes to the box model in screen.css, it causes
specificity wars when working with custom themes.

For example:

#column-group-beta p {padding: 10px 0 0 0;}
makes it so that I have to do something like:
#column-group-beta .some-class-here p {padding: 0;}

We should just have a base style for p {} that can then be overriden in
custom themes like so: p {} or if more specificity needed something
like: .foobar p {} should suffice

Reply to this email directly or view it on GitHub:
https://github.com/betweenbrain/construct5-pro/issues/2

Reply to this email directly or view it on GitHub:

https://github.com/betweenbrain/construct5-pro/issues/2#issuecomment-2348032

Reply to this email directly or view it on GitHub:

https://github.com/betweenbrain/construct5-pro/issues/2#issuecomment-2348229

[CristinaSolana]

Here are some examples:

#column-group-alpha h3 {
padding: 0;
}

#column-group-alpha li {
margin: 0;
padding: 0;
}

#column-group-alpha p {
padding: 10px 0 0 0;
}

#column-group-beta h3 {
padding: 0;
}

#column-group-beta ul {
list-style-type: none;
}

#column-group-beta li {
margin: 0;
padding: 0;
}

#column-group-beta p {
padding: 10px 0 0 0;
}

I think we should be just doing this at the element level and not at a class or id level because of the weight it adds to specificity.

Cheers,

C

On Monday, October 10, 2011 at 11:13 AM, Matt Thomas wrote:

There shouldn't be any normalization targeting any IDs. Geez, I hope I
didn't add any. If I did, you can kick me next time that you see me.

The normalization is in the top portion of screen.css. Below it is the base
styles. Are you possibly looking at those?

That said, there is some basic style applied to some ID's, like in
your example. Those can probably go away as you have suggested. Do you want
to take a pass at what you'd change?

Best,

Matt Thomas
Founder betweenbrain http://betweenbrain.com/™
Lead Developer Construct Template Development
Frameworkhttp://construct-framework.com/
Phone: 203.632.9322
Twitter: @betweenbrain
Github: https://github.com/betweenbrain

On Mon, Oct 10, 2011 at 11:07 AM, Cristina Solana <
[email protected] (mailto:[email protected])>wrote:

By normalization, I mean basic resets for p, ul, etc, but never anything
specific like: #id p {} or even .class p {}, anything that is different in a
specific place other than general should be left to the custom markup.
Cheers,

Cristina Solana
Nightshift Creative

Matt Thomas <[email protected] (mailto:[email protected])> wrote:

I'm all for using less ID selectors. Much of that, when it comes to
specifics like your example, is a throw back to original (circa January
2009) version of Costruct. We probably won't need any ID selectors in
screen.css other than for the layout and menu CSS (flyout). I'm open to any
suggestions or changes that you want to make.

Can you clarify what you mean by only including normalization when it comes
to the box model in screen.css? What changes would you make to it?

Best,

Matt Thomas
Founder betweenbrain http://betweenbrain.com/;™
Lead Developer Construct Template Development
Frameworkhttp://construct-framework.com/;
Phone: 203.632.9322
Twitter: @betweenbrain
Github: https://github.com/betweenbrain

On Mon, Oct 10, 2011 at 10:40 AM, Cristina Solana <
[email protected] (mailto:[email protected])>wrote:

We should consider using less id selectors and possibly, only including
normalization when it comes to the box model in screen.css, it causes
specificity wars when working with custom themes.

For example:

#column-group-beta p {padding: 10px 0 0 0;}
makes it so that I have to do something like:
#column-group-beta .some-class-here p {padding: 0;}

We should just have a base style for p {} that can then be overriden in
custom themes like so: p {} or if more specificity needed something
like: .foobar p {} should suffice

Reply to this email directly or view it on GitHub:
https://github.com/betweenbrain/construct5-pro/issues/2

Reply to this email directly or view it on GitHub:

https://github.com/betweenbrain/construct5-pro/issues/2#issuecomment-2348032

Reply to this email directly or view it on GitHub:

https://github.com/betweenbrain/construct5-pro/issues/2#issuecomment-2348229

Reply to this email directly or view it on GitHub:
https://github.com/betweenbrain/construct5-pro/issues/2#issuecomment-2348309

[betweenbrain]

Yep, I agree with dropping those declarations and going global :) Feel free
to go for it, or I can do it as well.

That's all old stuff from the early days. Good catch!

Best,

Matt Thomas
Founder betweenbrain http://betweenbrain.com/™
Lead Developer Construct Template Development
Frameworkhttp://construct-framework.com/
Phone: 203.632.9322
Twitter: @betweenbrain
Github: https://github.com/betweenbrain

On Mon, Oct 10, 2011 at 7:47 PM, Cristina Solana <
[email protected]>wrote:

Here are some examples:

#column-group-alpha h3 {
padding: 0;
}

#column-group-alpha li {
margin: 0;
padding: 0;
}

#column-group-alpha p {
padding: 10px 0 0 0;
}

#column-group-beta h3 {
padding: 0;
}

#column-group-beta ul {
list-style-type: none;
}

#column-group-beta li {
margin: 0;
padding: 0;
}

#column-group-beta p {
padding: 10px 0 0 0;
}

I think we should be just doing this at the element level and not at a
class or id level because of the weight it adds to specificity.

Cheers,

C

On Monday, October 10, 2011 at 11:13 AM, Matt Thomas wrote:

There shouldn't be any normalization targeting any IDs. Geez, I hope I
didn't add any. If I did, you can kick me next time that you see me.

The normalization is in the top portion of screen.css. Below it is the
base
styles. Are you possibly looking at those?

That said, there is some basic style applied to some ID's, like in
your example. Those can probably go away as you have suggested. Do you
want
to take a pass at what you'd change?

Best,

Matt Thomas
Founder betweenbrain http://betweenbrain.com/™
Lead Developer Construct Template Development
Frameworkhttp://construct-framework.com/
Phone: 203.632.9322
Twitter: @betweenbrain
Github: https://github.com/betweenbrain

On Mon, Oct 10, 2011 at 11:07 AM, Cristina Solana <
[email protected] (mailto:[email protected])>wrote:

By normalization, I mean basic resets for p, ul, etc, but never
anything
specific like: #id p {} or even .class p {}, anything that is different
in a
specific place other than general should be left to the custom markup.
Cheers,

Cristina Solana
Nightshift Creative

Matt Thomas <[email protected] (mailto:[email protected])>
wrote:

I'm all for using less ID selectors. Much of that, when it comes to
specifics like your example, is a throw back to original (circa January
2009) version of Costruct. We probably won't need any ID selectors in
screen.css other than for the layout and menu CSS (flyout). I'm open to
any
suggestions or changes that you want to make.

Can you clarify what you mean by only including normalization when it
comes
to the box model in screen.css? What changes would you make to it?

Best,

Matt Thomas
Founder betweenbrain http://betweenbrain.com/;™
Lead Developer Construct Template Development
Frameworkhttp://construct-framework.com/;
Phone: 203.632.9322
Twitter: @betweenbrain
Github: https://github.com/betweenbrain

On Mon, Oct 10, 2011 at 10:40 AM, Cristina Solana <
[email protected] (mailto:[email protected])>wrote:

We should consider using less id selectors and possibly, only
including
normalization when it comes to the box model in screen.css, it causes
specificity wars when working with custom themes.

For example:

#column-group-beta p {padding: 10px 0 0 0;}
makes it so that I have to do something like:
#column-group-beta .some-class-here p {padding: 0;}

We should just have a base style for p {} that can then be overriden
in
custom themes like so: p {} or if more specificity needed
something
like: .foobar p {} should suffice

Reply to this email directly or view it on GitHub:
https://github.com/betweenbrain/construct5-pro/issues/2

Reply to this email directly or view it on GitHub:

https://github.com/betweenbrain/construct5-pro/issues/2#issuecomment-2348032

Reply to this email directly or view it on GitHub:

https://github.com/betweenbrain/construct5-pro/issues/2#issuecomment-2348229

Reply to this email directly or view it on GitHub:

https://github.com/betweenbrain/construct5-pro/issues/2#issuecomment-2348309

Reply to this email directly or view it on GitHub:

https://github.com/betweenbrain/construct5-pro/issues/2#issuecomment-2353852