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.
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.
We have a sharing toolbox that defaults to 32x32 px but we also use the same toolbox code to display at 20x20 px in other parts of our site. The code below (including Drupal tokens) worked fine for a few months but last month it started showing the icons at 32x32 even though it has the class addthis_20x20_style. It also changed the behavior on another system outside Drupal that uses the same toolbox code.
<div addthis:title="[node:title]" addthis:url="[node:url]"
class="addthis_sharing_toolbox addthis_default_style addthis_20x20_style">
</div>
I tried changing addthis_sharing_toolbox to addthis_toolbox per the support page at http://www.addthis.com/academy/customizing-the-addthis-toolbox/, but then the buttons do not display at all. The AddThis support pages are incredibly disorganized and outdated and they seem to have abandoned their user forum. I don't even know where else to ask.
Here's a reply I received from AddThis support. Hopefully this will be of use to others:
JAN 07, 2016 | 03:26PM EST
Hi,
We recently made a change to our code that affected some of our older
buttons.
You will need to use our advanced configuration code in the locations
that you would like our buttons to appear in 20x20.
Replace the current code in these locations with the following:
<div class="addthis_toolbox addthis_default_style addthis_20x20_style">
<a class="addthis_button_preferred_1"></a>
<a class="addthis_button_preferred_2"></a>
<a class="addthis_button_preferred_3"></a>
<a class="addthis_button_preferred_4"></a>
<a class="addthis_button_compact"></a>
</div>
Additional advanced configuration code information can be found here:
http://www.addthis.com/academy/customizing-the-addthis-toolbox/
Please let me know if you need any additional help
Thanks,
Mike
I am having the same problem. It looks like they have removed support for 20x20 sized buttons, as it is no longer listed on the academy support page you provided. It is a shame because it is the only size that has a constant height for facebook, facebook_like, tweet, etc buttons.
The below css styles, while feeling a little hacky, go some distance in repairing the broken functionality:
.addthis_20x20_style .at-icon-wrapper,
.addthis_20x20_style .at-icon {
height:20px !important;
width:20px !important;
}
That didn't fix the size of the google_plusone button. I happen to be using drupal as well - the addthis module - and the below 'customize services' settings worked pretty well.
That's:
Service code: google_plusone
HTML classes: addthis_button_google_plusone
HTML attributes: g:plusone:size="medium"
(Re the addthis service, the phrase "you had one job!" comes to mind...)
I am using an iPhone 3GS for development and my app consists of 5 pages (data-role="page") 2 of them are dialogues (data-rel="dialogue") and the rest are links on my footer's navbar.
What I am experiencing is very slow transitions when a link is tapped.
Javascript itself is running smoothly, performing it's operations as it should without delay (alerts are instant when bound on "touchsrart" event). The actual links though are incredibly slow.
Anyone experiencing similar problems and/or has found a way to tackle them?
Thanks in advance :)
EDIT: forgot to mention -> sometimes a link gets 'stuck' before getting resolved which results in 2 'active' links (which UI-wise is aweful) and you actually need to re-tap it to make it work.
EDIT 2: posting footer bar whos links are particularly slow:
<div class = "footer-wrapper">
<div data-role="footer" class="footer" data-position="fixed">
<div data-role="navbar">
<ul>
<li><span>Option 1</span></li>
<li><span>Option 2</span></li>
<li><span>Information</span></li>
</ul>
</div>
</div>
</div>
Second option's button is the active one as I grabbed the code from page #2.
I am having a problem using fancybox with expression engine.
Basically I have different galleries set-up using matrix plugin. Each gallery has around 10 images. Basically I want the thumbnail to open up fancybox and fancybox to be able to scroll through the images in that matrix entry/gallery.
Sounds simple but I can’t seem to get fancybox to scroll through the images, it just stays on the first image.
This is my code for the thumbnails:
<ul id="image_gallery">
{exp:channel:entries channel="gallery_images"}
<li>
<a class="grouped_elements" href="{title_permalink='gallery/view'}" rel="{title}">
{gallery_image limit="1"}
{exp:imgsizer:size src="{image}" width="200px" height="180px"}
<img src="{sized}" width="{width}" height="{height}" alt="" />
{/exp:imgsizer:size}
{/gallery_image}
</a>
<h1>{title}</h1>
</li>
{/exp:channel:entries}
</ul>
This is my code for the fancybox template:
{exp:channel:entries channel="gallery_images"}
<ul id="img_gallery">
{gallery_image}
<li>
{exp:imgsizer:size src="{image}" width="650px" height="500px"}
<img src="{sized}" width="{width}" height="{height}" alt=""/>
{/exp:imgsizer:size}
</li>
{/gallery_image}
</ul>{/exp:channel:entries}
Everything works fine except for the image scrolling.
I’d appreciate any help!
Without seeing the output of your ExpressionEngine tags, it's difficult to understand where the problem is. However, your problem may be as simple as making sure all of the images in a gallery share the same HTML relationship attribute.
Fancybox Galleries are created from elements who share the same rel="" attribute:
<a class="gallery" rel="set_1" href="#"><img src="1.jpg" alt=""/></a>
<a class="gallery" rel="set_1" href="#"><img src="2.jpg" alt=""/></a>
<a class="gallery" rel="set_1" href="#"><img src="3.jpg" alt=""/></a>
<script>
$('a.gallery').fancybox();
</script>
In looking over your code, you're using the ExpressionEngine {title} tag as the rel="" attribute.
Since the title of your channel entry likely contains spaces and other special characters, a better choice would be to use the URL Title field, {title_permalink}.
The {title_permalink} tag converts the channel entry title to be URL-safe using either hyphens or underscores as character separators (using the Word Separator for URL Titles setting in the Global Channel Preferences).
Your updated thumbnail code would then be:
<a class="grouped_elements" href="{title_permalink='gallery/view'}" rel="{title_permalink}">
<img src="{sized}" width="{width}" height="{height}" alt="" />
</a>
If this doesn't work, perhaps you can provide a more complete code sample such as a jsFiddle or Pastie to help us understand where the problem may be.
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.