Beez 1.6

[Angie Radtke]

Hi ,

I'm working on my concept for Beez 1.6.
At the moment I'm still using 1.511 as basis.
After finishing this , I want to migrate the template to 1.6.

My aim is to demonstrate the template overrides, add some accessible JS, add
template -parameter and make the design nicer.

For the template- Prameter I decided to offer the possibility choose
between navigation before and after content.
I think this way is good , because a lot of people have different opions
about this issue.
At my demo- site the navigations is after the content. After configuering
we got a normal 3 column layout.
I want to offer two color schemes. Blue and black / white and Aria -
Elements for the forms.

http:// test1.run-digital.com

It's only the beginning , I got a lot of work , especially CSS for IE,
left.

Bye Angie

ausdrucks | STARK
Büro für Kommunikation Angie Radtke
www.der-auftritt.de
Witterschlicker Allee 52 53125 Bonn
0228/6420467 Mail:a.ra...@derauftritt.de
-----------------------------------------------------------------------
Barrierefreies Webdesign
von Angie Radtke und Dr. Michael Charlier
ISBN: 3-8273-2379-7

[KenMcD]

There is a space in the link which breaks the link,
http://test1.run-digital.com/

It looks very nice!

On 27 June, 03:07, "Angie Radtke" <a.rad...@derauftritt.de> wrote:
> Hi ,
>
> I'm working on my concept for Beez 1.6.
> At the moment I'm still using 1.511 as basis.
> After finishing this , I want to migrate the template to 1.6.
>
> My aim is to demonstrate the template overrides, add some accessible JS, add
> template -parameter and make the design nicer.
>
> For the template- Prameter I decided to offer  the possibility choose
> between navigation before and after content.
> I think this way is good , because  a lot of people have different opions
> about this issue.
> At my demo- site the navigations is after the content.  After configuering
> we got a normal 3 column layout.
> I want to offer two color schemes. Blue and black / white  and Aria -
> Elements for the forms.
>
> http:// test1.run-digital.com
>
> It's only the beginning , I got a lot of work , especially  CSS for IE,
> left.
>
> Bye Angie
>
> ausdrucks | STARK
> Büro für Kommunikation Angie Radtkewww.der-auftritt.de
> Witterschlicker Allee 52    53125 Bonn

> 0228/6420467   Mail:a.rad...@derauftritt.de

[Christophe Demko]

It sounds great!!!

There is a problem with the width of the login form (in firefox 3.0.11/
Linux)


On 29 juin, 06:41, KenMcD <kenmcd2...@gmail.com> wrote:
> There is a space in the link which breaks the link,http://test1.run-digital.com/

[Angie Radtke]

Hi,

> There is a problem with the width of the login form (in firefox 3.0.11/
Linux)

what kind of prob we got?

Bye Angie

[Antoine Bernier]

Hi Angie,

While you are refactoring beez for J1.6 let me focus your attention on something that caused me problem while writing CSS for Hot Property component with beez template selected.

Components developers have to write CSS to style their specific elements related to their components. In order the component works with any template, component's CSS rules have to be always more specific than template's ones (1) to take precedence over them.

Let's take an example... Say our component (wrapped in a div) is listing products, in the mainframe we'll have:

<div class="our_component">

  <ul class="products">

    <li><!--product1--></li>

    <li><!--product2--></li>

    ...

    <li><!--productn--></li>

  <ul>

</div>

and as CSS we want:

.our_component ul.products {  /* specificity = 0,0,2,1 */

  padding-left:0;

  list-style:none;

}

but this CSS rule is competing with beez one:

#main ul,#main2 ul {  /* specificity = 0,1,0,1 */

  list-style-position:outside;

  list-style-type:square;

  padding:0 0 0 10px;

  margin:0 0 0 20px;

}

=> beez's rule wins because its CSS specificity is higher component's one and as a result, it causes a visual conflict: our products list will have bullets whereas we didn't want it.

You'd certainly say "but you can make your selector more specific, by adding an id to your component!". Sure that's what we did, but for the only reason to be more specific to template's rules. We would had prefered keeping .our_component class which was more generic.

To summup, let's minimize our CSS specificity to avoid systematic higher bid strategy.

References:

• http://www.w3.org/TR/CSS2/cascade.html
• http://www.slideshare.net/manugoel2003/css-specificity

[Angie Radtke]

Hi Antonie,

 

this is a difficult problem.

If  I  don't use context selectors, I only can style something with  a  element  arround.

Sometimes we got moduleoutput without a div around.

For example the output can be only a list.

In this case I have to style with context selectors, otherwise I got the same output like inside the content.

That's a pitty .

 

At the moment I got no really good  idea.

On the other side I think that  template is the controller of the design.

 

This is an issue we should discuss with others. Maybe we can find a good solution.

 

 

Bye Angie

 

 

 

 

ausdrucks | STARK
Büro für Kommunikation Angie Radtke
www.der-auftritt.de
Witterschlicker Allee 52    53125 Bonn

0228/6420467   Mail:a.ra...@derauftritt.de

-----------------------------------------------------------------------
Barrierefreies Webdesign
von Angie Radtke und Dr. Michael Charlier
ISBN: 3-8273-2379-7

[Andrea Tarr at Tarr Consulting]

There was a discussion of this issue (who should have final design control) and the general consensus was that it should be the designer, not the component or module developer. So maybe using the suggestion of having an id on your component to add specificity is your best solution. That way you will trump the template naturally, but the designer can always grab it back if they want.

 

You are seeing it from the point of view (naturally) of the component developer, but think also of the site designer who wants all the extensions in the site to have the same look and feel.

 

This is the earlier thread:

http://groups.google.com/group/joomla-dev-cms/browse_thread/thread/24d7eba022b1c830/dd7b055feb11f025

 

Andy

 

 

Andrea Tarr

www.tarrconsulting.com

 

---

<BR

[G. D. Speer]

I agree that this comment "component's CSS rules have to be always more specific than template's ones" is problematic.

The support for it uses an example of inadvertant styling effect.

I believe the proper sceme of inportance is:

1)  Core default styling to apply in the absence of a template

2)  Template styling generic to all content in all positions.

3)  Component/Module specific default styling to apply in the absence of more specific template styling

4)  Template styling specific to the module/component.

 

The example cited in Antoine's is a case where a component-level CSS rule in category 3 is not overriding a general rule for UL/LI elements in category 2.  I think we all agree in concept that this shouldn't happen and that context selectors combined with a component/module-specific ID should have percedence over the generic template styles.

 

I think the layout team will agree with you that 3 should trump 2.

But we should also agree that 4 should trump 3.  Otherwise template designers can't deliver templates claiming that they extend their styling theme to cover virtuemart or jomsocial or a myriad of modules they may have styled with greater precision.

 

The concept of CSS specificity allows us to build the scheme above; it's a matter of making sure the CSS specificity is truly following the same container hierarchy produced by the core and the standardized generic template markup we are aiming toward.

 

 

 

---

No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.339 / Virus Database: 270.13.0/2209 - Release Date: 06/29/09 14:43:00

[Andrea Tarr at Tarr Consulting]

Yes, you explained it much more clearly than I did. Some of this is achieved with specificity and some of it with proximity. #3 is achieved with specificity and #4 can use that specificity and trump it with proximity.

 

Andy

 

Andrea Tarr

www.tarrconsulting.com

 

---

[Antoine Bernier]

http://idisk.me.com/abernier/Public/Pictures/Screenshots/peanut-20090630-202106.jpg

To simplify, let's assume a website is a m&m's, we can distinguish 3 layers ordered as follow:

1. The Joomla! core
2. The component
3. The template

We now clearly see the CSS specificity should be centripetal, eg: the template's selectors specificity should be as little as possible.

So if in templates we use selectors with ID(s) CSS specificity will be > 0,1,0,0 and it will be very difficult for the component to take precedence over.

Also using IDs in template seems "dangerous"... How making sure a component won't use an already use ID like #main (which is suppose to be unique)? It could occur since components' developers don't know by advance the template the final user will have chosen.

Why don't using classes in templates in lieu of IDs?

Best regards.

[G. D. Speer]

Antoine -

I understand the point you are trying to make...  That a scheme should be adopted that allows

templates designers and component designers to play nicely with each other and achieve predictable outcomes. 

With respect, some statements you are making as generic platitudes are not helping us reach a playing field where the design intentions are being honored.  I wish we could get to the simplicity of the M&M, but you are pointing out that you want component CSS to outweigh template CSS, exactly contrary to the M&M image you posted.

 

Also using IDs in template seems "dangerous"... How making sure a component won't use an already use ID like #main (which is suppose to be unique)?

 

IDs are a valid styling tool and have their place making the scheme work.  In your M&M example, the template is the outermost layer.  Why should a template designer be inhibited from using an ID selector plus being last to load to win a specificity battle if the intentention is to precisely control the final styling of an intentionally targeted component element.  Conceptually, component styling should be 'suggested' styling - it overrides less specific default styling, but still gives the template designer the last word to knowingly/intentionally override those suggestions.

 

Your example of #main actually cuts the other direction.  Component designers should be using non-generic naming of component elements simply because there could be a conflict with generalized template naming by template designers and end users.  On the html generation side, where the template's PHP is defining elements, containership, and respective IDs and classes, except for page weight and ID uniqueness, there is nothing wrong with giving a lot of styling hooks by including IDs and classes wherever they may be of value.  The CSS does not have to reference them. 

 

The objection I thing you are raising is when the CSS of a template is using an ID selector to accomplish generic styling that has the effect of overriding component designer styling due to the specificity weight of an ID selector.  The point you may be wanting to make is to suggest that template designers should be using attribute selectors [ID=main] (not available in IE6) when making generic styling rules so that these more generic rules tend to lose the specificity battle with component styles that all descend from a component ID, and reserve use of one or more ID selectors in template CSS to instances of intentional restyling of those component-level default styles.

 

As a rule, using IDs in selectors is intended for surgical precision.  The template PHP code is the place to uniquely name and class regions of the layout to allow generic styling rules by region.  Component designers can play nicely by giving unique IDs to the wrapping DIV of their component and providing default CSS that has that ID in every selector set where the component designer believes the template CSS must be overridden to achieve functionality.  This leaves the template designers the option to consciously and intentionally override that override by similarly referencing that ID plus the template region ID.

 

I will agree that escalation of CSS wars is not desireable and that classes or attribute selectors should be used whenever practical in the template CSS.  But I will absolutely disagree with the idea that template designers should never assign IDs to the layout divs.  Semantic element naming and classing is the essential cornerstone of making a complex multi-source CSS scheme work with predictability that avoids template v. component/module design conflicts and support issues.  Proximity also gives greater control to component designers with respect to default rules.