I would like to fire a function when a user is scrolling and reaches a certain element, so that I can mark that element "read" (think of how posts were marked read after viewing them in the now defunct Google Reader). So, for example, imagine a page like the following:
<div id="1">Node 1</div>
<div id="2">Node 2</div>
<div id="3">Node 3</div>
<div id="4">Node 4</div>
Assuming only the first two <divs> fit within the viewport, I would like to use Dojo's event listener and fire an event when div 3 came into view and again when div 4 came into view. (In addition to my goal of recording when an element has been read, this would also allow me to easily implement infinite scrolling.)
The jQuery Waypoints tool seems to do exactly what I want, but since most of my code uses Dojo, I really don't want to use jQuery just for this one task. I'd like to find a prewritten tool or simple method for doing this that isn't dependent on a library/toolkit other than Dojo (I'm fine with it using Dojo or no library at all).
UPDATE: It appears Skrollr also does what I am looking for, but only for animation -- that is, it can animate an element based on its relationship to the viewport. This doesn't exactly help, though, since my goal isn't animation but to activate a function (that will make an AJAX call via Dojo) when an element comes within the viewpoint.
Thanks to a few pointers from a friend, I was able to put together a functional solution to this question. Assuming all the divs are within another div with the id articles, when the user scrolls the bottom of the element at least 50px into the viewport, I then apply a "read" class to the element.
posts = dojo.query("#articles > div");
dojo.connect(window, 'onscroll', function(){
var vs = win.getBox();
var output;
var readCount;
for (var i = 0; i < posts.length; i++) {
var includeScroll = false;
var locInfo = domGeom.position(posts[i], includeScroll)
var fullyOnScreen = locInfo.y + locInfo.h + 50;
if ((fullyOnScreen > 0) && (fullyOnScreen < vs.h)) {
//Apply "read" class to div if it has been scrolled to.
domClass.add(posts[i], "read");
}
if (locInfo.y > vs.h) {
break;
}
}
});
Remaining question: While this solves my goal, I'm not sure it is the most efficient to poll the location of every div in or above the viewport every time the user scrolls -- even multiple times per scroll event. Are there ways to make this more efficient? It seems to run OK on my Core 2 Duo system, but I don't want to be sloppy just because it doesn't seem laggy.
I thought about calculating the position of all of the divs from the absolute top just once on start up and then doing some comparisons between the viewport and the top each time I scroll. This would probably be more efficient, but I'm not sure if the efficiency gains justify the added complexity of the code.
Related
I have a button to pull some data from backend. But the length of the data is uncertain and the time to load is also uncertain.
This will generate high CLS penalty. Is there anyway to avoid this?
var stHandler = 0;
$('#render').click(function(){
clearTimeout(stHandler);
$('#result').html('loading...');
// [Simulate the server response time]
// CLS will not be penalized if the everything happens in 100ms,
// but most of the case, the server will return the data longer than that
stHandler = setTimeout(function(){
$('#result').html(fakeResultBuilder);
}, 500 + Math.random()*1000);
})
// [Simulate the real-world condition]
// Every time you load this content, the height will be different.
function fakeResultBuilder(){
var html = '';
for (var i=0; i<Math.random()*100; i++) {
html += '<div class="block"></div>';
}
return html;
}
button {cursor:pointer}
.block {height:10px; background:#f00; width:20px; margin:5px}
#result {border:1px solid #999}
footer {margin-top:1em}
<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.3.1/jquery.min.js"></script>
<div>
<button id="render">Render</button>
</div>
<h2>Result:</h2>
<div id="result"></div>
<footer>Page Footer - will have huge CLS sometimes</footer>
The key is to adjust as much as possible within the 500ms grace period (note not 100ms as given in your code comment). The 500ms grace period is set because clicking on things (like your Render button) is an expected shift. However, if it happens considerably later (and 500ms is set as the limit) then it's back to being an unexpected shift. The user may be in the middle of reading some of the footer while they wait.
While the full response may not be able to be returned within that 500ms, you can still reserve some space (perhaps using min-height?) to, at the very least, reduce the CLS. The default height of an empty div is 0px so ANYTHING you do here will be better than than that as surely it will be larger than 0ms?
Additionally if it's enough to always knock the footer off-screen then adding a minimum height to push that footer off screen will mean any further moves for it are not considered CLS.
This may leave a large white space, which may not be ideal, so you may wish to consider some kind of "Loading..." message or a loading spinner. This will give an indication that something is happening to the user rather than them being unsure and perhaps rage-clicking the render button again and again.
I need to implement a plotly.js chart on a page with a very restricted width. As a result, a tooltip is partially cut. Is it possible to cause tooltip not to be limited by plotly.js container size?
My code example at codepen: https://codepen.io/anatoly314/pen/gOavXzZ?editors=1111
//my single trace defined as following but it's better to see example at codepen
const yValue1 = [1000];
const trace1 = {
x: [1],
y: yValue1,
name: `Model 1`,
text: yValue1.map(value => Math.abs(value)),
type: 'bar',
textposition: 'outside'
};
It is, by design, not possible for any part of the chart to overflow its container.
I would say it is wrong to say that by design this is not possible! It is a bit hacky, but when you add the following lines, it shows the label outside of svg:
svg.main-svg,svg.main-svg *
{
overflow:visible !important;
}
The answer given by rokdd works. However the css selector should be more specific, otherwise it's natural that you will introduce subtle bugs (particularly if you need to scroll the content where the plotly chart is contained).
If we look at the DOM tree constructed by Plotly, we find that the tooltips are created inside the <g class="hoverlayer"></g> element (which is a direct child of one of the three <svg class="main-svg"></svg>). So that parent (that svg.main-svg element) is only one that needs to affected.
The ideal css selector in this case would be the :has selector. However it's still not supported (as of 2022): https://css-tricks.com/the-css-has-selector/
So the next simplest thing is to use a little bit of javascript right after we call Plotly.newPlot:
// get the correct svg element
var mainSvgEl = document.querySelector('#positive g.hoverlayer').parentElement;
mainSvgEl.style['overflow'] = 'visible';
Or in a more generic way (works for any chart):
Array.from(document.querySelectorAll('g.hoverlayer')).forEach(hoverEl => {
let mainSvgEl = hoverEl.parentElement;
mainSvgEl.style['overflow'] = 'visible';
});
I'm using Waypoints and their Sticky shortcut to 'stick' an element with the id stick-this to the top of the viewport once it gets scrolled past. I am having some difficulty positioning the element past another fixed element on the screen, however.
There is a <div> with a class .header which always remains fixed. I am trying to position the top of the new element to the height() of the .header element so they are 'stacked' on top of one another and both visible. This is the code I am using to accomplish this:
var sticky = new Waypoint.Sticky({
element: $('#stick-this')[0],
handler: function() {
$(".stuck").css({ "top" : $(".header").height() });
}
})
So, essentially, once the #stick-this is scrolled past, it becomes sticky with a position:fixed class and the top is dynamically determined by the height() of .header.
This works great until I scroll back up, and the top style is still applied to this element, in spite of the stuck class not being applied anymore.
So when I scroll past, the element ends up like this
<div id="stick-this" class="stuck" style="top:70px /*or whatever the height() ends up being */">
and when I scroll back up the element ends up like this with the top property still in place
<div id="stick-this" class="" style="top:70px /*I need this back to 0px */">
Is it possible to have a function called when the "sticky" is removed, so that the inline style property can be set to top:0px or something like that?
For anyone else struggling with this, I ended up dynamically writing the CSS when the sticky element's class is initiated and inserting it into the head:
var sticky = new Waypoint.Sticky({
element: $('#stick-this')[0],
offset: $('.header').outerHeight(true),
handler: function(direction) {
$("<style>")
.prop("type", "text/css")
.html("\
.stuck {\
position: fixed;\
top:" + $(".header").height() + "px;\
}")
.appendTo("head");
}
})
so, the class will be added with the correct top positioning, and once the class is removed, the top property is inherently returned back to 0px.
It's important to have the \ after each line break in the .html() portion of this code in order for it to work.
This question builds on the (correct) answer provided to this. I simply haven't been able to get any further..
With the help of an interpolator function, d3.js's tween allows smooth graphical transition between existing and new (ie to be set) DOM element values. At the simplest level, for a given animation we have a target element, an start state, an end state, a transition, a tween function and an interpolator.
Now, say I want every so often to programmatically update the contents of an input (text field) element. The value to be entered is non-interpolable (either the text is submitted, or it is not. There is no in-between state). In providing a closure (allowing for text retrieval at the scheduled transition time), tween would seem to be a good vehicle for the updates. Either I replace the interpolator with a fixed value, ensure the start and end values are identical, or find some other way of forcing it to fire at t=1. That's the theory..
To this end, in my case each property (not value) is modified in it's own update call, into which are passed transition, element index and parent element selection.
First cut:
an outer, 'governing' transition with delay values staggered using a multiple of the current element's index
playback_transition = d3.transition()
.delay(function(d, i, j) {
return (time_interval * i);
})
.duration(function() {
return 1; // the minimum
});
within a call to playback_transition.each() pass the transition as a parameter to a dependent animation by means of an update() interface
within this dependent animation, apply the transition and tween to the current element(s):
input // a UI dialog element
.transition()
.tween(i.toString(), setChordname( waveplot.chordname ));
Where:
function setChordname(newValue) {
return function() {
var i = newValue; // a string
return function(t) {
this.value = i;
inputChanged.call(this);
};
};
};
and
function inputChanged() {
if (!this.value) return;
try {
var chord = chordify.chordObjFromChordName(this.value);
purge(); // rid display of superceded elements
plotChord(chord, options); // calculate & draw chord using new input property
} catch (e) {
console.log(e.toString());
}
}
PROBLEM
While setChordname always fires (each chord is in turn correctly found and it's value stored), of the scheduled returned functions, only the first fires and results in display of the associated waveform. For all subsequent return function occurrences, it is as if they had never been scheduled.
From the display:
direct user update to the input field still works fine
only the first of setChordname's return functions fire, but, for this initial chord, carries right through, correctly displaying the cluster of associated chord and note waves.
From this, we can say that the problem has nothing to do with the integrity of the waveplotting functions.
From the console
transitions are accumulating correctly.
chord supply is all good
associated (ie initial) tween fires at t=1. (specifically, tween appears to accept omission of an interpolator function).
looking at the output of transition.toSource(), though the associated outer index increases by single figure leaps, tween itself is always paired with an empty pair of curly brackets.
transition = [[{__transition__:{8:{tween:{}, time:1407355314749, eas..
For the moment, apart from this and the initial execution, the tween factory return function behaviour is a mystery.
From Experiment
Neither of the following have any impact:
Extending the period before the initial transition takes effect
Extending (by a multiple) each staggered transition delay
Furthermore
the same transition configuration used in a different scenario works fine.
These seem to eliminate timing issues as a possible cause, leaving the focus more on the integrity of the tween setup, or conditions surrounding waveplot append/remove.
Afraid it might be interfering with input property text submission via the tween, I also tried disabling a parallel event listener (listening for 'change' events, triggering a call to inputChanged()). Apart from no longer being able to enter own chordnames by hand, no impact.
In addition to 'change', I tried out a variety of event.types ('submit', 'input', 'click' etc). No improvement.
The single most important clue is (to my mind) that only the first setChordname() return function is executed. This suggests that some fundamental rule of tween usage is being breached. The most likely candidate seems to be that the return value of tween **must* be an interpolator.
3 related questions, glad of answers to any:
Anything blatently wrong in this approach?
For a shared transition scenario such as this, do you see a better approach to transitioning a non-interpolable (and normally user-supplied) input property than using tween ?
Provided they are staggered in time, multiple transitions may be scheduled on the same element - but what about multiple tweens? Here, as the staggered transition/tween combos are operating on only one element, they seem likely to be passed identical data (d) and index(i) in every call. Impact?
I'm now able to answer my own question. Don't be put off by the initial couple of paragraphs: there are a couple of valuable lessons further down..
Ok, there were one or two trivial DOM-to-d3 reworking issues in my adoption of the original code. Moreover, an extra returned function construct managed to find it's way into this:
Was:
function setChordname(newValue) {
return function() { <--- Nasty..
var i = newValue;
return function(t) {
this.value = i;
inputChanged.call(this);
};
};
};
Should have been:
function setChordname(newValue) {
var i = newValue;
return function(t) {
this.value = i;
inputChanged.call(this);
};
};
The fundamental problem, however, was that the transition -passed in as a parameter to an update() function- seems in this case to have been blocked or ignored.
Originally (as documented in the question) defined as:
input // a UI dialog element
.transition()
.tween(i.toString(), setChordname( waveplot.chordname ));
..but should have been defined as:
transition
.select("#chordinput") // id attribute of the input element
.tween(i.toString(), setChordname( waveplot.chordname ));
My guess is that the first version tries to create a new transition (with no delay or duration defined), whereas the second uses the transition passed in through the update() interface.
Strange is that:
what worked for another dependent animation did not for this.
the staggered delays and their associated durations were nevertheless accepted by the original version, allowing me to be misled by console logs..
Just to round this topic off, I can point out the the following (event-based) approach seems to work just as well as the tween variant with non-interpolable values documented above. I can switch freely between the two with no apparent difference in the resulting animations:
transition
.select("#chordinput") // id attribute of the input element
.each("start", setChordname( waveplot.chordname ));
Thug
What is the best way to programmatically insert HTML (that represents a CKEditor widget) before an existing element in CKEditor?
The content editable is not in focus and is not currently being edited.
For example, suppose the contents of the editor are:
<h1>Here's a title</h1>
<h2>Here's a subtitle</h2>
<p>Here's a paragraph</p>
<p>Here's a paragraph</p>
<p>Here's a paragraph</p>
Now, say I have a reference to the second <p> element. What is the best way to insert html before this tag? (Keeping in mind that the HTML that I want to insert will become a Ckeditor widget after inserting.)
Thank you very much for any help,
Michael
With the current API it is not possible to insert HTML string at the specific position without involving selection (EDIT: since CKEditor 4.5.0 it is possible – read below), because the editor.insertHtml method inserts in the selection position. However, if you have a simple situation that your HTML string contains just one element (with some ancestors), then you can easily use editor.insertElement on a lower level, when you can specify range at which you want to insert element:
var range = editor.createRange(),
element = CKEDITOR.dom.element.createFromHtml( elementHtml );
// Place range before the <p> element.
range.setStartAt( elementP, CKEDITOR.POSITION_BEFORE_START );
// Make sure it's collapsed.
range.collapse( true );
// Insert element at the range position.
editor.editable().insertElement( element, range );
As you can see this code uses editable.insertElement, which is used by editor.insertElement.
PS. Remember that insertElement will not upcast and initialize your widget. You can find more about this here - CKEditor, initialize widget added with insertElement.
Since 4.5.0
CKEditor 4.5.0 introduced editor.editable().insertHtmlIntoRange() as well as a range parameter for editor.insertHtml(). The latter method is a more high-level one, so it will take care of undo manager and setting selection in place of insertion. The former one is more a low-level method and it only inserts the data.
If you want to insert an element between or outside of the paragraphs
, the CKEDITOR.POSITION_BEFORE_START flag won't work because the element will still be placed inside the <p></p> node.
However, the CKEDITOR.dom.node.insertBeforeMe() method will place the new element before any editor node without wrapping it or confining it to a text node.
var startRange = editor.getSelection(); //Cursor position
var parent = startRange.getStartElement(); //The parent <p> or <span> of the cursor
var e1 = CKEDITOR.dom.element.createFromHtml("<h3>Subtitle before paragraphs</h3>");
parent.insertBeforeMe(e1); //Places new node before the specified node
Hope this helps!
its smoothly simple as this
$(document).ready(function(){
$("#add1").click(function(){
CKEDITOR.instances.editor2.insertHtml( '<ul><li>Computers & Electronics</li></ul>' );
});
});