I can't seem to get the paper-dialog to show up correctly all of the time. It will show correctly once then it will show up compressed the next time when I click on it to the point that it looks like a line. Unfortunately, I am unable to add a picture of it since this is my first question.
I have removed my styling sheets from this element but could the other styling sheets of my other element be causing this problem? Any direction of what I should look at would be really helpful.
I setup this paper dialog with the following:
<paper-dialog id='addressDialog'
opened="{{addressDialogOpened}}"
no-cancel-on-outside-click
no-cancel-on-esc-key
entry-animation="slide-from-right-animation"
exit-animation="scale-down-animation">
<div>
<template is="dom-if" if="{{newAddressDialog}}">
<h2>Add an Address</h2>
</template>
<template is="dom-if" if="{{editAddressDialog}}">
<h2>Edit Address Information</h2>
</template>
<hr>
</div>
It has a series of template repeats in it as well. I was reading about the paper dialog and it says that it has space for a header, content area, and buttons. Do I always have to set it up this way in order for it to work?
Additional solution is to add position: fixed; into your paper-dialog style like:
:host paper-dialog { position: fixed; }
So the only way that I saw to fix this terrible problem was to use a style of "min-height" and some percentage of the page. After I included this in my paper-dialog elements the popups were showing perfectly.
Related
We upgraded from JSSOR 26.5.2 to 27.5.0, and found that we are no longer able to use "link slides" as described in the JSSOR documentation here:
https://www.jssor.com/development/define-slides-html-code.html
The issue seems to be a DOM change in JSSOR 27. Now there is a new DIV element, the one with data-events=auto and data-display=block, that acts as a kind of "glass" in front of the actual image (the one with u=image). As a result, any ... that surrounds the actual IMG can never be clicked, because the z-index of this "glass" prevents the click on the .
In our case, we've always been using a construct like this:
<a u="image" href="..." style="display: block;">
<img src="..." alt="..."/>
</a>
It's always worked until now. Is this a bug in JSSOR?
Your code is correct.
Anyway, here is an example, hope this helps.
https://www.jssor.com/jssordev/problems/image-slider.slider
https://www.jssor.com/jssordev/problems/image-slider.slider/=edit
The output code is as below,
<a href="#">
<img data-u="image" src="//jssorcdn7.azureedge.net/demos/img/gallery/980x380/004.jpg" />
<div data-t="0" style="position:absolute;top:30px;left:30px;width:500px;height:40px;font-family:Oswald,sans-serif;font-size:32px;font-weight:200;line-height:1.2;text-align:center;background-color:rgba(255,188,5,0.8);">responsive, scale smoothly</div>
</a>
Edit
I got the problem, the new version improved to use <a> element as whole slide.In this manner, you can add anything inside without hiding the link area.
That's to say, as <a> is a slide, you can remove the parent <div> element.
The likebox I created for nbglive.com is not resizable, no matter what method I use, and as such, it is causing great trouble as to how I can integrate it with our site without having it overlap the radio player.
Is it possible to get the like box to resize when the page is resized? I'm using twitter-bootstrap.
I am putting FB widgets (likebox and comments) into the Bootstrap's grid like this:
<div class="span4">
<div style="text-align: center;">
<div class="fb-like-box" data-href="{url}" data-width="234" data-show-faces="true" data-stream="false" data-border-color="#007Db7" data-header="false"></div>
</div>
</div>
where url is the variable containing web URL of the FB page.
with CSS:
div.fb-like-box,
div.fb-like-box > span,
div.fb-like-box > span > iframe[style],
div.fb-comments,
div.fb-comments > span,
div.fb-comments > span > iframe[style] {
width: 100% !important;
}
Facebook loads its component asynchronously with styles set according to the width data attribute. I set it to some safe value: looks bad but does not overflow to other elements for different view-ports. My CSS overrides all the FB's width settings that are necessary to resize the widgets (I set 100%, so it adjusts to the containing div). It is not documented and possibly it will stop to work when FB changes their designs, so choose your default width (234px for me) wisely ;)
Example with LikeBox of at the bottom of the right-hand side panel and in the sidebar. Note the responsive behavior when you change the size of the browsers window.
Here is an easy way:
$(".fb-like-box").attr("data-width", $(document).width());
Do your cording according to your CSS as below
<div class="comment-box">
<div class="fb-comments" data-href="site_url" data-width="100%" data-numposts="5" data-colorscheme="light" data-mobile="auto-detected"></div>
</div><!--comment-box-->
cut and copy java-script as fb gives in headder
I'm using the following code for my like button
<fb:like id="facebook-like" href="http://mysite.com/index.php" layout="button_count" width="450" show_faces="false" font=""></fb:like>
Some users have experienced the like button not showing up. Noted in 3.6.17 but observed in other versions. I'm somewhat familier with the firefox iframe bug, but I was currious if anyone has any work arounds for the facebook like button.
Like buttons that are rendered with javascript (<div class="fb-like"/> and <fb:like/>) get height=0 if they are initially hidden (display:none).
To work around this, create the element with javascript after the container is displayed, and then run:
FB.XFBML.parse();
Example:
result.show();
var like_box = $(".fb-like-inactive", result);
like_box.removeClass("fb-like-inactive");
like_box.addClass("fb-like");
FB.XFBML.parse();
This CSS solved it for me
.fb-like span, .fb-like iframe { height:25px!important; width:150px!important}
This is still an issue, as can be seen here (also contains fix):
http://codepen.io/wiledal/pen/cGnyq
Firefox does not draw the Facebook-like if the div is hidden at the time of parsing. In the example above I delay the showing of a div after different times. You can see that a like-button shown after 500ms does not get rendered in Firefox.
I managed a work around which does not cut off the comment dialog after liking, simply by using min-height and min-width instead of set values that was previously proposed.
.fb-like span, .fb-like iframe {
min-width: 100px !important;
min-height: 20px !important;
}
I had the same problem on Firefox only (v.29.0.1) and it turned out to be AdBlock plus (v.2.6) blocking the Like and Share buttons from rendering.
Can you try calling the like button like so:
<div id="fb-root"></div><script src="http://connect.facebook.net/en_US/all.js#appId=195243810534550&xfbml=1"></script><fb:like href="http://mysite.com/index.php" send="false" width="450" show_faces="true" font=""></fb:like>
And let me know if you're still seeing issues.
Leaving an answer because I can't leave comments yet...
Oli's nice CSS hack looked like it worked initially:
.fb-like span, .fb-like iframe { height:25px!important; width:150px!important}
but it clipped the comment box that tried to pop up when we actually clicked the like button.
Per's delayed parse solution seems to do the job; here's a bit more detail. In our case we had the like button in a drop down menu, which looked like:
<ul>
<li class="control_menu">
<span>menu name</span>
<ul style="display: none;">
<li><div class="fb-like-inactive" data-href=...></li>
...
</ul>
</li>
...
</ul>
with code that shows the drop down ul when the user hovers over the control_menu element. We used this code to handle the delayed parsing:
$(document).ready(function() {
$('.fb-like-inactive').closest('.control_menu').hover(function() {
var inactive = $(this).find('.fb-like-inactive');
if (inactive.length && (typeof FB != 'undefined')) {
inactive.removeClass('fb-like-inactive').addClass('fb-like');
FB.XFBML.parse(this);
}
});
});
It finds the fb-like-inactive buttons, then looks up the tree to find the containing control_menu elements, then attaches an event to the control_menu elements to detect when the user hovers over them. When it detects a hover for a particular menu element, it looks for inactive like buttons within that element, marks them as normal fb-like, and then parses just the content of that element.
I hope this saves someone some time.
I just spent an hour on this and on a much more basic level, you need to know that the Facebook buttons will not render when testing your page locally.
It may seems obvious but it will only work when rendering from a webserver.
Per's solution is based on the XFBML version of the fb button and I wasn't sure how to do this with the "html5 version" or if it is really possible but I found a CSS/JS solution that doesn't clip content instead so here it is:
html
<button class="like-button">I like this stuff</button>
<!-- This is a hidden like-box -->
<div class="social-share aural">...stuff...</div>
CSS:
html body .aural {
position: absolute;
font-size: 0;
left: -9999px;
}
jQuery:
$('body').on("click", '.like-button', function(e) {
var $socialShare = $('.social-share');
$socialShare.css({'font-size':'1em'});
var sw = $socialShare.width();
$socialShare.animate({left: sw-80}, 400);
});
You may have to use !important rule (in both css and js) or nest the .aural class depending on the rest of your css. If it doesn't work I'd suggest trying to change the default layout so it doesn't override .aural or nest .aural and as a last resort use !important..
I had the same problem but the culprit was setting tracking protection in about:config to true.
This tip turned me on to the idea initially:
Lifehacker: Turn on Tracking Protection in Firefox to Make Pages Load 44% Faster
My solution is completely different to any of the above.
I have a character animation in my page, and one of the elements has the id="body" (which is perfectly reasonable) however this seemed to kill the FB script.
As soon as I renamed my id, the share started working again; I can only presume there was some kind of conflict, as id'ed elements can be referenced as global variables.
I found this out through the usual process of removing elements until things worked, so I'm fairly sure it was this.
I've been playing with html5 and I've noticed that sometimes the page displays my html differently in the dom (viewed through firebug) than it actually appears in my html files. The result is an element being replicated several times in different ways. I only notice this on nested elements.
For example:
<a href="#" class="block top-middle">
<h5 class="title-top">TITLE</h5>
<img src=""path/to/img.png" alt="TITLE" />
</a><!-- .top-middle -->
Is occasionally displaying as:
<a class="block top-middle" href="#"> </a>
<h5 class="title top">
<a class="block top-middle" _moz-rs-heading="" href="#">TITLE/a>
</h5>
<a class="block top-middle" href="#">
<img alt="TITLE" src="path/to/img.png">
</a>
I'm not really sure what the solution is but I wanted to know if anyone else has experienced glitches like this. I've sifted through every bit of my code and I can't find anything broken and the pages it happens on validate without any problems. It's especially frustrating because it only happens once in a while.
thanks!
**edit also, I know using anchor tags like this is not valid but as far as I have been able to tell with what I've read about html5 it is valid wrap content inside an anchor*
The browser/rendering engine was made before HTML 5 existed, so it is obeying the rule that anchors which are inline elements cannot contain h5s, which are block level.
This makes perfect sense. I don't think you can really do anything other than wait and see if the rendering engine adopts the HTML 5 rule that allows anchors to nest block levels such as h5s.
EDIT: I assume you are using the HTML 5 Doctype, although it probably won't have much bearing.
EDIT #2: This has been filed as a bug, even though I personally think it shouldn't be. A way around this seems to be wrapping the h5 in a div.
My current project involves working with a document editor that, for better or worse, is implemented using mshtml and setting contentEditable to true. We're certainly considering replacing this setup with something else, but for the moment assume it is not an option.
In case it matters, we're doing this using VS 2008 (.Net 3.5) & C#:
document = (HtmlDocument)this.editorWebBrowser.Document;
body = (HtmlBody)document.body;
body.contentEditable = true;
We'd like to hide most of the structural editing behind our UI, but let the user edit the text any way they like. The problem arises when we add a div with any of several styles:
(Adding a body tag to simulate what we're doing programmatically, so you can test in IE, but remember we're working in C#/.Net/VS.)
<BODY contentEditable="true">
<DIV class="intro" style="border: 1px solid blue; width=100%;">
<P>My Intro</P>
</DIV>
<P>Other Text</P>
</BODY>
There are two things wrong with this:
The first click by the user selects the div. We'd like the click to go straight to the text, and never let the user see the resize handles.
If the user places the cursor in Other Text then tries to move to the div text using the keyboard, they're prevented. The div is treated as one character when you are outside of it moving around.
So, effectively, is there any way to make the div behave like just a background decoration, but have everything around it still be editable? This html is completely internal, so we can do anything with it we like. So the div itself doesn't matter. What matters is that we:
Contain several P or other tags
Show the user visually that all the contained P or other tags are part of one group, as styling like border & background color on the current div accomplish now.
This SO question makes me worried that what I want isn't possible with our current setup, but I ask to help anyone else who stumbles on a similar problem. I'll be adding a couple imperfect solutions we've come up with in a moment.
Possible or not, thanks for any thoughts you might have.
Partial solution: Set a containing div to contentEditable=false, then true again on an inner element, like so:
<BODY contentEditable="true">
<DIV class="intro" contentEditable="false" style="border: 1px solid blue; width=100%;">
<P contentEditable="true">My Intro</P>
</DIV>
<P>Other Text</P>
</BODY>
This possibly solves problem 1 (user selecting the div) but does nothing about problem 2.
Since the HTML is internal and doesn't need to play nice with anything else, just represent the area with a table, rather than a div:
<table class="intro">
<tbody>
<tr>
<td>
Intro
</td>
</tr>
</tbody>
</table>
This solves both problems, but significantly complicates the code for editing or parsing. We'd prefer a cleaner solution.