Sorry if this makes no sense as am only just getting to grips with WordPress and editing CSS.
I have a calendar plugin which for the most part is pretty standard.
However, I wish to make a minimum height for the elements so if there isn't much text, the format still looks better.
Following tutorials, I am able to inspect the source, make the change, and have the desired effect. My issue is, that if I find the element, it seems the custom CSS makes changes to multiple elements on the screen, I can work round most of this but it effectively breaks a clickable link (Makes it not cover the whole button).
The element part I edit is quite large but here is a chunk of it:
.tribe-common abbr, .tribe-common acronym, .tribe-common address, .tribe-common applet, .tribe-common article,
There's about 50, so I'm guessing my edit is covering too much or that I'm editing an attribute that more than one element inherits?
The only attribute I am setting is min-height, so unsure why this seems to make the clickable button area smaller? The button itself stays the same, but I can only click it right at the top.
The plugin I am using is a free one called events calendar. And for the most part I am able to edit the way I've described, I am just struggling to get this one to work and thought it might be the giant list that's causing it. Or should I say my lack of knowledge
Thanks
I am not sure if i get the issue you are describing correctly, but if your changes in css apply to some elements that you don't want them to apply, then you are not precise enough with your selector.
For example, the element you mentioned in your text contains many commas (","), which select all elements separated with comma. This makes your selection wider, not narrowing it down.
If you are not familiar with syntax of CSS selectors, i recommend checking out this resource:
https://www.w3schools.com/cssref/css_selectors.asp
Related
We are instituting a new responsive web template design on our website, this design has worked perfectly in all but one place (We are on the Convio CMS if that helps). Here is what it is supposed to look like (menu and contact info in right column):
http://www.ucc.org/feed-your-spirit/practices/prayer-flags.html
On this page however:
http://www.ucc.org/find/find-a-ucc-church.html
that info appears below here. However after you use the find feature, the information then DOES appear on the right side as it should. This really has me stumped.
The find a church service is a component that can be placed on any page.
Secondary issue - the map is not visible on the results page in Firefox, though on the current page - www.ucc.org/find - it is visible.
Any solutions, ideas, etc. are welcome!
Two problems, both CSS. The left div, ef-inner3 does not have float:left nor width specified. This causes it to be too wide, pushing the topics area down.
You need to add those CSS values in. How you do that with your particular CMS system I am not sure.
The reason behind it moving down is thus: When you float two elements, their combined widths cannot be greater than the width of their parent. If they are greater then there is not enough room and the second floated item moves below the first.
Tricky one! But I'm thinking this might not be CSS.
My first reaction was that maybe a DIV isn't properly closed somewhere.
Based on the Find function fixing it, maybe you have a </div> that's set to display with the Find results, so it's not showing up before the Find function brings it up?
Hope that makes sense! If possible, try searching for any closing tags that are inside any kind of if/else statement.
EDIT - just noticed - A lot of the content in your Find a Church page seems to be after the 'three fourth' DIV, and after a 'clear' DIV. If you can edit the source, try placing all of that back inside the 'three fourth' DIV and see what happens.
I am building a site using Drupal 7 and have run into a CSS issue. I am trying to wrap everything on this registration page in the center and at the same time reduce the width of the drop down buttons. I believe I've narrowed the problem to my logintobaggan (drupal module) css sheet. But the button "widths" seem to be from the foundation.min.css (according to chrome elements). How would you guys approach this CSS problem? I am relatively new, so please don't be too harsh ;). Thanks!
http://medicaldoctorapps.com/user/register
I would get Firebug or similar in-browser development tool, select the element you are interested in seeing the CSS properties for, and then see exactly which rules are being applied or overridden. You can even modify the CSS right there in the tool until you get want you want.
From such a tool, I can see that the button widths are not explicitly defined, but are basically derived from the amount of padding (5px) around the text string inside the button.
The rules are defined starting on line 41 of this file:
http://medicaldoctorapps.com/sites/all/modules/logintoboggan/logintoboggan.css?mgqhxk
...Screenshot of my abomination
jsFiddle: http://jsfiddle.net/ELZD8/
It was looking fine, until I needed to change the fieldset size: and since I was using position:relative for literally every element on the page, changing the fieldset screwed everything up, bad. Forgive me but I'm pretty new to CSS and I know I'm using wayyy too much code.
So, as you can see in the imgur, it looks like hell now. What's the quickest way to fix this? I know it probably has to do with floats and margin:left and margin: right, but could someone provide some insight before I go bananas?
Any input is appreciated, cheers.
Easy fix:
You need to use proper div sectioning, that is, make each section a div and then place elements inside each div, otherwise it becomes a clusterfuck. You also need to list your elements in your css file by order of appearance in the html, otherwise it's painful to look for things...
Don't use massive amounts of <br>, use padding and margin css rules instead
Yes, you may use position:relative, but since you asked for advice, I am strongly against it, it takes longer to build, longer to update, longer to fix, etc. Use sections, floats and keep it simple, Simple is your friend.
I also suggest strongly against using fieldset, use <form> instead, its a major html/css breaker imo.
Here's a chopped up example after cleaning/tweaking the code considerably. There's still a thousand ways left to clean and refine it but at least now it looks more like what I suppose you wanted:
http://sotkra.com/stackoverflow/positionrelative/index.html
I stumbled upon this article
http://www.thefloatingfrog.co.uk/css/my-hatred-of-br-clearall/
When would one need to use that ?
Why is it evil ?
I don't understand the substitute syntax can you explain ?
Setting clear to both with not allow other elements to float on either the left or right side of the element. The class below is an easy way to add this anywhere.
.clear {
clear:both;
}
So when you want to clear something (that is, if you were to float the next element to the left, it would be below the current element and to the left, instead of left of it) you'd simply add the .clear class.
The problem with the following code is that if later on you decide that you don't want to clear everything after the 'something' class, then you have to go through your HTML and remove the br clear="all" wherever you have that 'something' class.
<div class="something">Cool content.</div>
<br clear="all">
<div class="other">Cool content again.</div>
Instead you could do something like this:
.something {
float: left;
}
.other {
clear :both;
float: left;
}
<div class="something">Hi!</div>
<div class="other">Hi again from below!</div>
That way if later on you decide to float all blocks with the 'other' class then you can just remove the 'clear:both;' from the CSS once.
I was about to post something snarky about you not reading the article, but when I saw that it was just a page of vitriolic rage with no explanation, I figured I'd answer.
It's because there are better ways of doing what you want to do -- namely, by using CSS in the way he does in the article, he has separated the semantics of the elements he's displaying from how he's displaying them. Why is this a big deal? Well, for one, he can more easily transform how his page looks when it's shown on different platforms (mobile, desktop) and media (screen, print, a screen reader for the blind), simply by editing CSS and not having to touch the document itself. This feature of CSS is pure gold.
On the other hand, if you use a construct such as this, you put in a hard constraint about your document's presentation that sticks around no matter what media or platform you're dealing with. What makes him so mad? Because once a developer has come in before him and used <br clear="all">, he has to take it out in order to get the benefits I just mentioned. That's why it's so frustrating. One bad developer can disable a whole host of development scenarios for every other developer who comes after.
As far as CSS goes, I have to say that it's a very difficult subject to just pick up without reading all about how it works. It's hard to explain how the clear attribute works if you don't understand floats. I had quite a hard time myself until I bought a great book on the subject.
When you have floated elements, the parent element can't calculate it's dimensions effectively and sizes incorrectly. Other items that follow floated items may also sit out of position. By clearing an element at the end of your floats, you correct alter this behaviour.
EDIT
Actually correct is probably the wrong word to use as this is what is supposed to happen and using the word correct suggests it is broken.
The author is just going off on a crazy rant about how the same thing can be accomplished using CSS on the DIV elements themselves. He's saying that br class="clear" is unnecessary.
It's also not a good practice because it mixes content with presentation. If a web designer wanted to re-theme the web application, he or she would need to modify the HTML to pull out all of the br clear elements, whereas if this was done as the author suggested, then the CSS files could be swapped out independently of the HTML, making their jobs easier and giving them one less thing to rant and rave about.
The rant is of course justified, as these simple, silly lines of code can actually cause a lot of headaches.
The idea is that your markup describes the information, and the CSS formats that information.
A dummy tag to clear floats isnt semantic, as it's only purpose is for layout reasons. There are other semantic ways of clearing floats that keep this separation. As commented below but here for clarity this is a good resource for semantically clearing floats http://css-tricks.com/the-how-and-why-of-clearing-floats/
I have a problem where i am doing an ajax fetch of some table rows which i use to replace a table's body.
The problem is that sometimes IE(6/7) decides to forget about all page styles after such an append. (that is to say, it reverts to using styles in css includes at the top of the page, but not styles defined on the page itself)
I have been able to find other people describing the same problem, but no solution. has anyone encountered this before, and was able to solve it?
bonus points if the solution did not involve externalizing all css on the page.
Well, if you mean that you have style tags in the body, they shouldn't really be there, so it's not surprising that some browsers may react badly to that.
If you are replacing all rows in a table, try to replace the entire table instead. The structure of a table isn't really meant to be changed that drastically, so replacing the entire table may very well cause a less aggressive reflow of the page. That may keep it from removing the questionable style tags in the code.
Verify that the code that you are putting in the page is valid. If you introduce invalid HTML code, that may force the browser to change rendering mode. That in turn would require a complete reexamination of the code, which could be a possible explanation why it's throwing away inline style tags.
Instead of a table you could try using div tags that you arrange to form the layout that you want. Replacing some div elements may cause less confusion to the browser than replacing a table or part of a table, which may make the page more stable.
If all that fails, I don't really see any other solution than making the page more robust by not putting style tags in the body. That's something that you should consider in the long run anyway.