As far as I use sifr.setup(); every h2, h1, and so on becomes invisible. But I don't want that.
I just want the "selectors" to provide a replacement and become invisible and replaced.
How can I prevent that?
I also have another problem where every font is blue and it never gets that color from anywhere.
Sounds like you've kept the original CSS, which hides those elements. Have a look at the CSS file and remove the original .sIFR-hasFlash h1 selectors.
Can you post an example for the color problem?
Related
I'm using vaadin-combo-box and I have a problem. I have no clue how to customize look and feel of scrollbars for the dropdown. I read about styling parts and I know how to do it but this seems to be impossible. Cant figure out the way to select #scroller element because it has been design not to be a "part" to style. However that is the only way I can think of to apply custom style to dropdown scrollbars. How can that be accomplished?
Thanks in advance for help.
#Update
Turns out that as of today there is no way of having customized styling on scrollbars for vaadin-combo-box component. Element responsible for scrolling resides inside contents shadow DOM and is inaccessible from outside nor its going to inherit style implemented on the parent part [part="content"]
The dropdown part is called vaadin-combo-box-overlay, see: https://vaadin.com/components/vaadin-combo-box/html-api/elements/Vaadin.ComboBoxOverlayElement And it is available for styling.
This allows to style the dropdown to some extent, but there is additional shadow root, that prevents to apply e.g. ::-webkit-scrollbar styles on #scroller element.
So the last option would be to make a copy of the vaadin-combo-box html file in right place in frontend directory. It happens so that that file will be used instead of the one coming from webjar. Then you can edit that html file directly. Of course this means that if there are changes in future versions of vaadin-combo-box, you need to copy again, re-apply changes
Not sure where to look for an answer, but here's my quest:
http://www.mobiliteitsvisie.nl/
On this site I've made a one page parallax, but when scrolling the main text moves underneath the menubar, but the headers (h3 & h4) seem to move over it...
But where would I need to adjust this? In the .css or in the .js file?
Thanks in advance!
Ruud
Since you're problem is with the style you need to make a change to the CSS.
In your case you want to get the menu on top of all other objects. Just give the menu container a large z-index.
Add this to your css file:
header {
z-index: 100;
}
The z-index property specifies the stack order of an element.
An element with greater stack order is always in front of an element with a lower stack order.
Note: z-index only works on positioned elements (position:absolute, position:relative, or position:fixed).
Additional question about the same site. When scrolling through the site, the menu-item should change with every slide it passes. At this moment the last clicked menu-item is highlighted, even when scrolling through to the several slides. Is there an easy way to make that work in CSS? Or would that be possible by just adding a jQuery.nav.js to the index.html?
I'm having an odd problem with jQuery draggable this morning, I wonder if anyone else has come across this.
I have many small divs inside a large div. They are absolutely positioned: "position:absolute" in CSS for their class, with the actual position itself calculated and set in JS on demand.
Now I'm adding functionality to allow these divs to be draggable.
But, as soon as I make one draggable, it is given "position:relative" directly on the element, which as you might imagine, seriously messes up the on screen position.
Does anyone know why it changes the "position" like this or how to tell it not to?
EDIT:
Just realised there is a rather obvious answer staring me in the face - !important on my position:absolute! This seems to fix it. BUT I'm still interested if anyone knows why it sets "position: relative" like this (and doesn't either make it configurable or check first if it needs position)...I'm wondering what problems I've just stored up for myself ;-)
"I came across the same problem today. The reason was I was applying draggable() on a dynamically created element. I was 'later' appending it to dom. The element should be in dom when you apply draggable() (if style is being applied by a class). In short, when it finds no position attached with the element , it adds relative." - Jashwant
Firs do: .append(jElement) Then: jElement.draggable()
For some reason Jashwant put his answer in the comment to the question. So I thought it will be convenient to other to repost it here.
It also happened to me, but only on Chrome. Reason?
It was like this:
$("#div-popup").draggable({ handle: ".top", containment: 'document'});
Then I removed the containment parameter, like this:
$("#div-popup").draggable({ handle: ".top"});
So it's about the Browser (Chrome in this case), which sets position to Relative when you specify which containment the element will be draggable.
in my case it seems to be a race condition between the stylesheets and javascript loading...
i realized i'd made the mistake of including the stylesheets AFTER the javascript in the document head. they should be included BEFORE the javascript because $(document).ready() does not account for the CSS being loaded by the browser: https://stackoverflow.com/a/1324720/3633109
I am working on an existing site which uses sifr. It was set up to substitute all h1, h2, etc with sifr. I need to prevent this from happening on just a couple headlines.
Unfortunately because of the timeline I do not have the time to change the sifr-config to be more locked down and then change all of the html pages too.
Is there some way I can add a class to an H1 to prevent sifr?
You can add the sIFR-ignore class to elements you do not want to be replaced.
Please note that any sIFR-related CSS applied to the elements in question (such as .sIFR-active h1 rules) may still apply.
Looking forward to any help/comments on any aspect of this, but the main question is about sIFR text wrapping, and how to disallow it. This was supposed to be a simple html-izing job (ha ha ha)
Check out here
So I've housed the nav and the content clip boxes in tables, which I know you purists might disdain, but it seemed the easiest/most consistent way... please forgive.
The problem is the sIFR - I can't get one of the nav items ("Exchange Technologies") to behave; it keeps wrapping. Meanwhile, the sIFR headlines in the little content boxes have become unruly and are trying to escape.
I've clogged up the CSS trying to fix it in various elements -- I would be so eternally grateful if a sIFR expert would check it out and see if there are any suggestions on making the sIFR heads work.
Note that I do not need any padding on the bottom of the sIFR elements because the headlines are rendered in all caps.
If it would help I could send along the image of what the designer was looking for.
The forceSingleLine parameter for sIFR.replace() is the easiest way to resolve this. The problem usually arises when the Flash text is wider than the HTML text, and the elements being replaced are exactly the width of the HTML text. In this case the sIFR text won't fit in the allowed space without wrapping.
Another solution is to use letter-spacing through .sIFR-active .myNavItemToBeReplaced CSS rules, to make the HTML text wider so the Flash text does fit without wrapping.