I'm not a Drupal module developer by all means, though very familiar with CSS.
I was using Primary Links as a CSS styled dynamic-looking menu where the active page
of menu (as defined by CSS 2.1 compliant ":active" psuedo class) was a similar color. (using Zen theme)
Drupal did not allow me to do this as it generates a class ".active" for the <a> tags
for what it determines as the active link, however it does not
add this class to the link you define as "Home" or "first", therefore not allowing
that link to have an ".active" color. Also directly interferes with ":active" psuedo-class (note the semi-colon):
you can't have a:active as the standard CSS syntax for the link if a.active is what Drupal
determines is the CSS property to use for <a> element.
Throws off the whole point of this CSS menu style/method, which is quite standard.
I had to do an elaborate CSS contextual over-ride using "body.front" tag/property Drupal generates.
This may seem finicky, but Drupal should not dictating what CSS classes you can use!!
and the solution for this is infinitely simple, just change the spelling of one word!
(if the class generated said "activelink" and/or "activetab" instead of "active",
it would not longer interfere with behavior of :active class)
Can this be added to Drupal 6, or will it need to be?
(how frozen is 6 code contribution, and could they have room to change the spelling of one word!!!??)
Comments
...
Please see this page
Look at the Bug report and the Feature request descriptions and decide which it falls under.
Drupal 6 is pretty much frozen at this point.
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
above should read as follows, forgot to code tags...
I'm not a Drupal module developer by all means, though very familiar with CSS.
I was using Primary Links as a CSS styled dynamic-looking menu where the active page
of menu (as defined by CSS 2.1 compliant ":active" psuedo class) was a similar color. (using Zen theme) Drupal did not allow me to do this as it generates a class ".active" for the
<a>tags for what it determines as the active link, however it does not add this class to the link you define as "Home" or "first", therefore not allowing that link to have an ".active" color. Also directly interferes with ":active" psuedo-class (note the semi-colon) - you can't have a:active as the standard CSS syntax for the link if a.active is what Drupaldetermines is the CSS class to use for
<a>xhtml element.Throws off the whole point of this CSS menu style/method, which is quite standard.
I had to do an elaborate CSS contextual over-ride using "body.front" tag/property Drupal generates.
This may seem finicky, but Drupal should not dictating what CSS classes you can use!!
and the solution for this is infinitely simple, just change the spelling of one word!
(if the class generated said "activelink" and/or "activetab" instead of "active",
it would not longer interfere with behavior of :active class)
Can this be added to Drupal 6, or will it need to be?
(how frozen is 6 code contribution, and could they have room to change the spelling of one word!!!??)
bug?
this isn't a bug, something was coded into Drupal 5.0 that directly conflicts with standard CSS usage,
big assumption on part of Drupal coders.
And like I said, this change would literally take 5 minutes so I'm wondering
if it can be snuck in, (Drupal "code-freeze" is a relative term so I've heard)
...
Code freeze is not a relative term. We are well past beta and alpha and into the realywanttogetfinaltestingandreleasethedarnthingsopeoplecanworkondruapl7 phase.
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
so more for Drupal7??
so this would be a change for the Drupal 7 release then I guess.
(despite the fact it could have been changed in the time it took to have this
conversation - its changing the spelling of one word, not really a "coding addition"
now is it? more like a spelling error causing huge problems in the Web standards
department?)
geez am I annoying monday mornings or what!
scope and comparisons
It is not a five minute change. Any change would have to go through the complete testing and review process. It would have to be tested on every core theme in every browser/OS combination testing that occurs especially when we get to this stage of the release cycle.
In the past, a one line change has had subtle consequences that were not found for weeks. The potential inter-relationships between the various modules and themes must be accounted for.
Just because you are irritated doesn't mean you are right, nor does it mean you are wrong. Please follow up on the link I provided. Once submitted, your issue can be tracked and decided on. Posting in the forums will result in nothing happening with it and it getting lost.
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
Can you give a specific
Can you give a specific example of what cannot be done? I do not see how having a specific class on an element, can stop a pseudo-class from working, especially when (as you imply) it works with a different class.
Are you trying to give
a:activeanda.activethe same style? Wouldul li a:activehelp, to over-ride the existing style?I don't get it either.
I don't get it either. Without a counterexample, I would assume that CSS can distinguish between
a,a.active,a:active, and evena.active:active. I can maybe see a slight usability problem if all of those situations are styled the same way, but I think Drupal means something different from the :active pseudo-class when it applies the .active class.-----
Übercart -- One cart to rule them all.
to answer your question - EDITED
(using Drupal 5.2)
I was adding some fancy menu css to my horizontal Primary links
so the active page link would distinct. (not un-common html/CSS trick)
i.e.
Home | About Us | Whats New | Contact
I tried in zen and also by switching my theme to Garland
2 things going on here
1) Drupal dynamically generates the .active class for every menu link that becomes "active",
except not the first menu link in the series, to which it gives a class of .first So my alternate color
I specify for .active class will not work for the first link (i.e. home). I could use "a.first"
but the .first class is always generated for the first menu item, wether active or not,
so that would just change the color that link is at all times - so even using the current
Menu system, you cannot achieve what I was trying to do. Not sure if simple wording change would fix it -
Would fix problem if the class ".active" was generated as an alternative class on top of .first for the "first" link.
2) The .active class that is generated for specific Primary Menu
<a>elements, DEFINES those specific<a>elements as being a.active in the CSS/tag hiearchy, which means it cannot also be a:activePsuedo classes are CLASSES, not properties. A specific element cannot have 2 classes ( ?)
But I dont think a.active:active would be proper syntax. That seems to be how its behaving.
i.e.
ul li a:active {color:#ffffff;}<a>cannot over-ride
ul li a.active {color:#ffffff;}<a>because as soon as you classify
<a>as being a.active, it cannot also be a:active, if you follow.There is a way around it, I used
body.front div#page div#container div#sidebar-left #primary ul.links li.first a.menu-1-1-2
{color:#ffffff; }
using the alternative class given for that specific link, and the body.front tag/class that specifies you
are at the front page (i.e. frontpage would then be the active page)
but the point remains, Drupal in the menu context is interfering with a standard CSS class/property
behaviour
Using the standard Garland theme.
I’m looking at a site using the standard Garland theme.
Drupal generates an .active class for the a tag, and a .first class for the li class in a link (even if they are the same link), so
a.first {won’t work, it should be.first a {: Have you tried.first .active {?You say Are you suggesting that there is something I cannot do, or something you cannot do? Better to say .
Pseudo-classes are not classes, they are pseudo-classes, because they are more dynamic than normal classes. I think that when pseudo-classes were introduced, browsers could only have one class per tag, and pseudo-classes were additional. Later, browsers implemented more than one class per tag. If your browser cannot have more than one class on an element, you should use a new(er) browser. Having the class .active does not stop that tag being :active.
You then say that you used what is that if not a second class?
Considering the number of mistakes in your post, and the incompleteness of your understanding of css, you haven’t got a point. Whoever edited your post, unfortunately left some of it behind.
Walk-around: CSS Specificity
I agree with you that presentation should not be dictated tat strongly by the backend application... only suggested.
A walk-around that should be able to solve our problem is to find out the specificity of the Drupal default definition for the selector including the class .active and that which is making :active look regular and override those settings by writing new selectors in CSS that have a higher specificity (you can test with !important - note that I strongly oppose using !important beyond testing or emergency fixes).
Specificity will allow you to override whatever presentation rules come with Drupal out of the box.
Here is a clear overview of how you can adjust selector specificity to fine-tune your CSS presentation
-----
iDonny Productions: Web CMS Design, Development & Web Standards
CSS Specificity
agreed, that was in fact how I fixed it (yesterday, see above), i lucked out with body.front - not sure if it
would have worked without the frontpage custom themeability (which is actually cool)
but I can tell you a lot of designers would be annoyed at spending time trying to figure out the above
CSS contextual selection when they would rather be playing with photoshop.
I believe there is (was) a move to make Drupal 6 more designer and also themer-friendly, and not just cater to
module developers and PHP enthusiasts
(wow, I gotta post a bit faster around here)
tried a.active:active
not sure if CSS will do that,
i also tried adding it to an class already in my zen.css to make active bread-crumbs bright green
.breadcrumb:active {color:#00FF00;}didn't work
more a discussion saved for the WW3 website that looks after CSS specification
(uhhh... I'm rather busy and don't have time for that site!)
Did you try it?
You’re not sure? Well, did it work or not?
Try
.breadcrumb :active {color:#00FF00;}(note the space) only anatag can be:active.The point of this post was not to find a CSS work-around
I had that before i posted.... More so the fact drupal demands a weird css work-around
to begin with as something that can be improved apon (i.e. not messing with users
ability to use pseudo classes in their normal usage)
if this is not going to be looked at please close, Im out
can't close, not an issue.
This is a forum post. Have you posted an issue per my earlier post? If not, then no one will work on it.
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
This *is* an issue
Some of the OP comments about .active causing problems with :active are not correct, and can be overcome with correct CSS code. However, the problem that is an issue is that Drupal is generating these menus with the multiple selectors sitting directly next to each other (li.first.menu-1-1-2-active) when in order to enable full CSS styling the multiple class selectors should be separated with spaces, not conjoined with periods (i.e. li.first menu-1-1-2-active). Also, the -active at the end needs to be formatted instead as: li.first menu-1-1-2 active which then allows it to be actually used as a selector across multiple menu items whereas at the moment it is useful only by defining a list of multiple selectors in your CSS up to the maximum conceivable number of menu items you have, so that each one is selected regardless of the menu id... very inefficient.
I am under no illusions such a change will occur in 5.x or even 6.x at this point—so do not plan to post this as either a bug report or a feature request. But anyone know how I can hack 5.x to fix this myself?