I have just created a dropdown for my site. It works fine in all other browsers except new version of opera that is 12.02.
Webiste Url : http://www.sktechnologyworld.com/demo/anything/
Here when you mouse over on "Categories", it displays dropdown of that categories then when you hover on categories then it displays subcategories of that category. At this time there is background line remains at top of that perticular category and this same thing in all the subcategories. However when i open dragon fly in opera by pressing ctrl+shift+I then it works fine but if dragon fly is not open then it makes it weird.
Its very strange and have not face this kind of problem before. Any help?
Thanks
This is indeed a bug in Opera. As it's merely a cosmetic issue with no big impact on functionality I suggest you just report a bug to Opera Software and forget about it until it's fixed :-)
The root cause is that Opera fails to draw the background colour of the padding-top of the A elements correctly. It's mainly triggered by the padding-top:9px instruction on #CategoriesBar .nav. However, trying to work around it means adding hacks to your CSS and that makes it harder to understand and maintain - even more likely to break in future browsers. Hence reporting a bug and not trying to work around it is your best way ahead.
Here is a simplified demo you can refer to when reporting the bug:
http://jsfiddle.net/sNHbB/
Please let me know the bug reference number and I'll give it a kick for you.
Related
For some reason i am not able to enter any text in inputtext in dhtml environment. The same is working fine in swf10 environment.
When i hover over the input text i observed that the cursor is not changing to selector. It looks as if the onmouseover event of inputtext is not getting fired.
Has anyone come across this kind of issue in openlaszlo dhtml envrironment?
I am using OpenLaszlo 4.9, Windows 7 and the browser is Firefox 15.0
I found a bug report in jira http://jira.openlaszlo.org/jira/browse/LPP-9934.
Please suggest any ideas to overcome this issue/
The problem you are seeing is probably connected to the way OpenLaszlo replicates the behavior of clicking through Sprites or visual elements in the Flash runtime for the DHTML/JavaScript runtime. Until recently browsers didn't support that kind of functionality directly. Therefore the OpenLaszlo team had to use a workaround, which is described in detail in this comment on LPP-5447.
Clickdivs exist to have independent control over clickable sprites,
without interference from regular divs. They are placed in a separate
copy of the regular lzdiv sprite hierarchy so we have more control.
This also provides a place to put focused inputtext divs so they are
in the foreground and clicking/dragging to edit works properly.
The clickdiv functionality seems to be broken from time to time with browser updates or due to regressions. In 2012 some improvements to the DHTML runtime click-through functionality were done, using newer browser features in Firefox (which now allows to click through div elements using the CSS style pointer-events). Since the clickdiv functionality is part of the LFC, fixing that functionality in your application is not advised.
You can test if the inputtext works by tabbing through the components until your inputtext element has the focus and start typing. If the text can be entered as expected, but you cannot click the component with your mouse to select it, it's definitely a clickdiv problem.
Update: Tested with OpenLaszlo 4.9.0 and various browsers
I've tested with OpenLaszlo 4.9.0, DHTML runtime and IE9, Firefox as well as Chrome, using the test case attached to LPP-9934: All browsers show that specific bug behavior. If the bug has not been filed, please file a JIRA bug.
as I found out a few days ago when you click an extension button and popup shows up, its height is much higher than it needs to be if you need the height to be less than 350px. When something happens in the popup (animation e.g.) the height is adjusted properly according to the content. Setting height to html, body and general wrapper element didn't help. It might be some bug in the latest update of Chrome, I cannot test it in earlier builds, because of autoupdate.
I'll be thankful for any thoughts and advices.
Libor
UPDATE: I started to examine what can possibly cause this behaviour and found out this happens because of Twitter and Google Plus share buttons. They both modify DOM structure adding script tag which adds iframe. When commented, popup bubble appeared in correct size. The weird thing is facebook like button script does more or less the same, but it doesn't mess up the layout at all.
Like it was said here, the good solution to solve this problem is changing <html> to <!doctype html>
Same thing here with my extension and Chrome 19 on Windows 7. I must note that there were no problems with the previous version of Chrome. As you stated the issue shows up only on the first appearance of the popup - it shrinks correctly afterwards).
I'm using jQuery in my extension and I think I've partially solved it by adding
$("body").fadeOut(10).fadeIn(50);
though it doesn't always work (it probably will if you increment the fadeIn delay but!). Hope someone can provide a better solution to this.
EDIT. This should be guaranteed to always work (using your hint) although the user might see the resizing happening for a fraction of second:
$(window).load(function() {
$("body").fadeOut(10, function() { $(this).show(); });
});
I'm using the 960.gs grid system to style a website. It appears fine in all the major browsers, except in IE6, I see other sites using the 960.gs perfectly well and it displaying fine in IE6 and wanted to know what I need to tweak to appear correctly.
Here's more info on the 960.gs system: http://960.gs
I've used the class="grid_6 omega" to try and force my last div to float to the right. Which it does in all browsers except IE6. Does anyone know what I need to do to make it work in IE6, do I need to clear something?
Any advice greatly appreciated!
I figured out the problem this morning for anyone wanting to know. I'm using 960.gs and Thematic because I think they're both brilliant in their own ways.
The solution that worked for me was to add the following CSS styling to the containing div before the div that floats to the right, in my case this DIV happens to be called leftloopcontainer, but obviously adjust it to whatever you need it to be:
#leftloopcontainer {overflow: hidden; zoom: 1;}
After I did this IE6 behaved (well, as much as that troublesome browser can!) and displayed my content just fine!
Anyone here know the fix for this?
Others have stated that this is a feature and not a bug for safari on iPad - two finger scroll within the frame might do the trick for you? However, would be nice to have some type of visual tip on scroll potential within the frame.
http://discussions.apple.com/thread.jspa?messageID=11612916
chad.
Since long time i been having a real problem with the different ways that each browser display text.
Sure you have noticed that even when you create a stylesheet specifying everything about the font properties, still every browser display the same text with some differences, the usual problem is the font weight, that even if you specify it different browsers display it different ways.
I would like to know if some as come with a solution. Not turning the text into a image.
Thanks.
EDIT:
This is a example of the problem. On the left Firefox and right IE. However i have defined in the CSS font family, weight, size and still they render the fonts different.
Snapshot
Do you mean that on one browser its bold and another one its normal? A reset should fix that, but if it doesn't, it might be something overriding that.
If you're talking about fonts looking different, it is possible - for example, since Google Chrome / Chromium sandboxes the renderer process, the font rendering won't be affected by other parts of the system, and I believe that it uses some sort of special font rendering. To be honest, on my Linux install, I do get bolder fonts on Chromium, but Firefox displays them fine.
There's SIFR (as pointed above), but it needs Flash and it is a bit heavy. There's also Cufon http://cufon.shoqolate.com/ that uses Javascript. Could you show a screencast so we know what's the problem? Thanks.
SIFR is a good solution, as long as you're only trying to control the appearance of small chunks of text (headings, design elements, etc.)
Beyond that, browsers are perfectly allowed to render text any way they want, and getting it pixel-perfect between browsers and operating systems is usually not even desirable for larger chunks of text. Users will have different accessibility settings and anti-aliasing settings which are tuned to the way they want to read text, and in general websites should try to respect that.
You can use SIFR.
Although this problem is already about a week old, here is a solution that I found, that might be related:
http://blog.wolffmyren.com/2009/05/28/jquery-fadeinfadeout-ie-cleartype-glitch/
If you're not using jQuery, try removing the filter attribute from the elements that are displaying non-Cleartype'd text and it should work, according to that blog post.