Edit: I had been using a custom font "Gotham" (downloaded folder of fonts in my project) in the #font-face which appears to be the source all of the bugs. Not really sure how to fix it though. Is there a way to fix these issues while keeping my custom font?
Edit #2: the issue has been fixed with ascent-override: 80%; in the font-face. But this doesn't work on Safari browsers. Is there any solution?
When I resize my browser's window height while testing my website, there is a horizontal invisible line cutting off my h1/h2 text. From my research, it seems to be something due to line-height, but im not sure.
Thoughts I had:
When I don't set a line-height for the h1/h2, their height renders to 0px and are just invisible. The p tag in the middle seems to be fine with/without line height, I don't understand why?
see below, all line height removed
When it does have a line height, the text of the h1/h2 seems to be offset of the container. When I highlight the h1 in devtools, the text is higher than the box, outside of the margins.
When I resize my window, the 'invisible line' cutting into my text seems to be in the same spot, while my text moves up and down with the page resizing. So when the invisible line is between lines of the h2/h1, the page looks normal.
I have a script animating numbers that sets the innerHTML to the next number. Maybe the use of .innerHTML is screwing something up? When the animation happens, the invisible line cuts into the numbers like so. But for some reason it fixes itself when I resize the window.
Maybe it's the font I'm using? I'm using a custom font 'Gotham' and have it set up in the #font-face in the css.
Sorry for the bad description, but I did my best. Let me know if I could clarify anything. Could someone point me in the right direction?
I can't add a comment so adding an answer, can you not use box-sizing to resolve this?
https://developer.mozilla.org/en-US/docs/Web/CSS/box-sizing
This should then force the h1/h2 to remain within the box rather than cutting part of it.
Related
When I have enough rows in my ui-grid to do scrolling, it seems to have a lot of whitespace at the bottom of the list for some reason.
I've nailed it down to this piece of code (i think?):
styles['margin-top'] = hiddenRowWidth + 'px';
line 3038 of ui-grid.js
Not sure why it's adding so much white space at the bottom though. Any ideas? I was thinking it's because my container is 100% height, but it seems to do this even with a specific pixel height as well.
edit: Well, now I'm not certain that it was that code that's the culprit. The ui-grid-canvas element has a HUGE height, still not sure why.
Closing this out, as it seems to be something CSS related that's only a problem for my custom CSS.
I figured out the culprit.
I had added padding: 0 to .ui-grid-canvas, because the 1px space between the header border and the start of the rows was really bugging me. However, for whatever reason this breaks the calculations when it's trying to handle virtualization for scrolling.
Upon removing my custom padding, everything seems to work normally.
my friend has designed my webpage for me, but has now gone on holiday and i only know the very basics. I want to reduce the width of my buttons on one of my pages.
I think this is the part of the coding (where it says (".betbutton) i need to change but just don't know how - hope somebody can help me - thanks
$(".betbutton").click(function(){
$("#numberofbets").html(this.attributes["nob"].value);
bet = this.attributes["bet"].value;
This is the problem with how it actually looks on my site and need the size to reduce so the buttons all shift to the left.
http://freebetoffersonline.com/bet-calc.php
Instead of giving you a fish I will teach you to fish.
First use Firefox and then install the Firebug extension. Restart Firefox.
Once you have restarted there should be a Firebug menu, open it.
Once Firebug is open click on the blue arrow icon and that will let you choose the element inspector.
Then use the element inspector to inspect the "button" elements.
Firebug has a "style" tab on the right, it will show you the styles, including the width from various CSS classes. It will also show you where the CSS style sheet is located.
Even nicer, you can CHANGE the styles including the width to test and see if the changes you think may work will actually do what you think they will.
When you look at the buttons with Chrome's Web Inspector you see that they have a dynamic width. The container, which has class name .bidlist has a fixed width of 880px. Change it to ~560px and you should be fine :-)
I'm not really sure which buttons you want to change the size of, so this answer will be rather generic.
You need to use CSS. Inside the HTML for your button put style="width:100px;" or whatever width you want. If there is already a style attribute in the button's HTML, just add the width:100px; to the style.
In style.css, line 797, there is the .bidlist width property. Reduce that to something like 580px and see them shrink :)
Your friend made the buttons 25% of the width of the bidlist container, so there would be 4 fitting in each row. If you reduce the parent container's width, they shrink, too. In the style.css file, the design of all the elements are implemented, including the container width. So that is the part you change, not somewhere in the HTML (markup).
I've created a small javascript Rich Text Editor, but when I open it in an iframe, the padding of certain objects are not correct. Here's an image of what it looks like from the source:
But, when I put it in the iframe and use this source, it looks like this:
I tried changing the DOCTYPE and changing the margin: and padding: to 0px, but nothing changed. I can't seem to fix this. Any help would be greatly appreciated. Thank you!
As far as I can see, what's happening is that the iframe's width is not enough. From the source the colorpicker box can fill all the space it needs, but in the iframe it's cramped, shrinking everything inside it and making the color bands at the end and the gray 16, 32, 64 fall to another row. Also, the offset for the colorpicker seems to be off; are you using percentage-widths and offsets, maybe? You can do many things to solve this: just increase the width of the iframe (you can't make the box only spill out of the iframe), move the colorpicker box to the left, make the picker's size fixed (you'll need to resize the iframe or make it scrolling for this, etc. It's probably not a DOCTYPE problem, though. More details would be appreciated, but I hope this helps!
Ok. I figured out what I needed to do. I had the colorpicker div set to be at a specific .offset() with jQuery, but it didn't fully function in the iframe. The reason was because the div's width was variant on the color bit function. Because of this, jQuery had trouble determining the left positioning of the colorpicker div since the offset function I wrote uses the width of the div. So, all I needed to do was set the width of the colorpicker. ;) Thanks for the help!
I'm trying to create a editable textbox with HTML/CSS/Javascript that looks and functions like a printed textbox with lines appearing every row.
It must look like this because the form may be printed on paper for people to write in.
I see three approaches to this method:
Table row with 'border-bottom' on each row and using javascript to determine when the text-overflows and move the cursor to the input box on the next row when it does.
This method is probably not very accurate.
Drawing absolute-positioned lines beneath the div/textarea that contains the text.
Using CSS3 repeating gradients to draw the lines behind the div/textarea. Like so: http://net.tutsplus.com/tutorials/html-css-techniques/lets-create-paper-with-css/
. This method is only compatible with modern browsers though.
Which method is the best and why?
Here’s one option. You need a div to draw each line, that could be done beforehand or with JavaScript.
In short, set an explicit line height on your textarea, then absolutely position a container element behind it. Inside that container put a set of elements with a height equal to the line height of the textarea, a one-pixel bottom border, and a negative-one-pixel bottom margin.
It’s most similar to your #2 but a little simpler.
The CSS3 method is best I think. As a fallback for browser that don't support it, you could put a background image of a line there, repeat it both horizontally and vertically, and use CSS to set the font size and line height so the typing aligns with the background image lines.
Well, the CSS3 method would at least let you use relative sizing like ems so people who've resized their fonts will still be ok. If it's not available in older browsers, I don't think that's hugely important, as it's an enhancement to make things easier if people print, rather than something that is essential to people interacting with the textarea.
Absolutely positioned lines might get un-aligned if the user resizes their browser/fonts/etc, although I haven't tested this to confirm. The Javascript seems like overkill for what is just a decorative effect unless the page is printed. And I'm not sure if you can even put tables inside a text-area, although again I haven't tested that.
I think this might be impossible, but is there some way using JQuery to prevent lines of text not fully visible from showing up on the screen when a user scrolls until the entire line is visible? That is, we want to prevent something like this from showing up:
Thanks!
I agree with #rahmanisback, don´t mess with the user's browsing experience.
However, what would perhaps be a nice "inbetween" solution, is using a transparency gradient so that the bottom pixels fade out. But that would apply also to "whole" lines, so perhaps that´s not a good solution for your problem.
I don't know if there is something out there to do that. But I think it will cause confusion more that it would make any visual enhancement ever. A user will not be happy when scrolling down and finds lines just "popup" suddenly, in opposite to normally easing out as a result of scrolling action.
After all, when we speak about a scrollable HTML element with scrollbars visible, a user is aware text might be partially shown and that is normal and needs to be scrolled down to read the remaining. I really would not recommend that.
But for a technical answer, I think you would need to fix the CSS line-height property of that scrolling element, say make it 8px or whatever fits your layout. Then, capture the scroll event and devide the jQuery scrollTop() by that CSS line-height, then check the results: if it have a fraction then that means there is a "partially visible" line. Don't forget aout margin and padding that can cause mistakes when calculating.
I believe I have had this problem also, in that you have a div with a specific height and overflow hidden.
Thinking about it i would resize the div based on the line-height of the text in the div.
Change the height of div so that it equals a multiple of the line height of the containing text....
ie 3 lines of text with line-height = 16 change the div height from 50 to 48px.
( i posted this at the same time as rahmanisback' answer )
Hypothetically you could measure the height of text area, measure the height of the line, find scroll position do some math and then have some way of hiding text that is not fully exposed yet (eg Using a white div of x height depending on your math). However, it seems like a lot of trouble to go to for something that is usually a non-issue. You might also be able to do something with the overflow property, but you might have some issues with that I'm not sure.
I thought of an alternate method that would be easier to implement. Capture scroll events and then change it to the closest multiple of line height.