Update browser's URL hash id/anchor on scrolling with Skrollr - skrollr

So your page consists of sections, each section has a unique id or anchor and you would like browser's URL update with current section's id/anchor as you scroll.
PS I'm not asking a question but rather sharing a recipe. All relevant code examples and demo are in the answer, so please don't vote against this question.

This is possible with Skrollr! But you'll need to help him.
First, create a menu with links to page sections:
>
<nav><ul>
<li><a href='#home'>Home</a></li>
<li><a href='#about'>About</a></li>
<li><a href='#goods'>Goods</a></li>
<li><a href='#services'>Services</a></li>
</ul></nav>
Tie each <li> to corresponding page section with Skrollr's data-anchor-target (read this for info). Then add some Skrollr transitions:
<li
data-anchor-target="#about"
data--200-center-bottom="opacity: 0.2;"
data--200-center-top="opacity: 1;"
data-200-center-bottom="opacity: 1;"
data-200-center-top="opacity: 0.2;"
>
From now on, Skrollr will apply the skrollable-between classname to those <li> elements, whose corresponding page sections are currently visible on the page. And we're gonna exploit that feature! :D
When initializing Skrollr, you can assign a callback to the render parameter. This callback will fire during scrolling. In that callback, you need to:
Retrieve the list of currently active menu items (those who have the skrollable-between classname).
Decide which of the active menu items to consider current. If there's only one active item, the choice is obvious. If there's more than one, i suggest you pick the second one.
Retrieve the value of the href attribute of the link of the current menu item.
Update browser URL with that value.
Note that Skrollr hijacks vanilla browser behavior of scrolling the page to the current item on page load. So we have to work around that. Even worse, Skrollr executes the render callback multiple times on page load, resetting the browser's URL hash to that of the first page section. To work around this issue:
Before initializing Skrollr, read the hash from browser's URL.
Set a timer for 500-1000 ms that would reset the hash scroll the page to the beginning of the corresponding section. The simpliest way to do this is to use the click method of the skrollr-menu plugin.
The timer approach is kinda ugly. If you have a better idea, please leave a comment here.
Another issue you'll have to work around is the fact that Skrollr executes render callback hundreds of times per second during scrolling. You definitely don't want your callback to run that much: that's completely unnecessary and will slow down the browser.
So you need to throttle your callback. If you happen to use a standard library extension plugin like Lo-Dash in your project, use it's throttle method. If you don't, you can use the tiny jquery.timer-tools plugin.
Here's a demo that embraces all of the above, written in comfy CoffeeScript:
Demo: http://jsbin.com/gozota/7
Source: http://jsbin.com/gozota/7/edit?html,css,js

Related

How to put one button inside another one in Vue?

I’m stuck with putting one button inside of another one: it’s prohibited, but I use bootstrap, that’s why I appoint class “btn …” to span and it looks like the button.
My button should look like this:
Filename.jpg <small delete button<
When you press on filename, file opens, when on small delete button - it sends request to API and deletes file
But now link is not working, but delete button does work. Putting and so one did not solve my problem
Code:
<span v-for=“link in links”
class= “btn btn-success”
v-bind:href=“<domain> + link.file”>
<button type=“button” class=“btn btn-danger” #click=“deleteFile(`$(link.file_id) `)”>-</button>
</span>
href only works on certain elements. Use <a> anchor instead of <span>.
Generally speaking it is not a good idea to wrap clickable elements inside other clickable elements. It's bad for accessibility and tab navigation and it can lead to easy missclicks from your users.
The right thing to do would be to put your two buttons next to each others to indicate that there is in fact two separate actions your users can take related to the file.

Conditional v-once directive

I'm working on an app that uses Vue. It is a kind of document editor that allows editing of content.
There's a filmstrip in a sidebar displaying the entirety of the document, and a viewport in the center displaying the current page/spread.
On large documents with 100+ pages, I'd like to throttle the number of updates allowed through to the filmstrip component as it gets a little laggy on resize and when the JS controlled layouts in pages all have to resize simultaneously when global fields are changed etc.
There's a data structure representing the document's content, which is rendered by Vue components in the viewport and the filmstrip.
I could maintain two data structures and only update the data structure used in the filmstrip 1000ms after the last user interaction.
However, it feels like there could be a better way.
Vue has a directive called v-once, which looks promising, however, I can't find out if that can be set conditionally.
If I could, then I could set a timeout on change, and clear it if a change occurs before the timeout ends, and then momentarily unset v-once, then on next tick, add it back on again so that rendering pauses.
If there's a way of doing this, I'd love to know.
Here Proposal: Allowing v-once to accept a boolean flag is very clear, you can't set v-once dynamically. Also there is an example of one way to combine v-if and v-once to achieve the result you want.
Excerpt from the link
v-once is used for static content. v-once tell the compiler don't add any responsive functionalities to save cpu time. Otherwise, if the content is responsive, no methods could be used to save this kind of cpu time.
Hope it helped

Transition views in javascript of a dojo based application

I have two scenarios I need help with, and I thought posting them together would prove more
valuable for myself, and other viewers.
Setup:
Worklight 6.1
dojo 1.9
Application:
MainView.html (Contains Body, and a transition Div, and NorthSouthView.js script reference)
View1.html (Contains a single Div that displays and unordered list
View2.html (Contains a single Div that Displays <p> data, and also plays audio)
View3.html (Contains a single Div that Displays instructional information)
application-descriptor <mainFile> MainView.html </mainFile>
All of the views are stored together in the application. There are no external http queries made by the application. All view transitions are local to the application.
Scenario #1:
At application start the MainView.html is invoked by worklight. Anticipated format::
<body>
<div>
<h1 id="SSheader" data-dojo-type="dojox.mobile.Heading" data-dojo-props='fixed:"top"'>Loan Snapshot</h1>
</div>
<div id="TransitionViewDiv">
/* Would like to load content of View1.html, View2.html, or View3.html here */
</div>
<script>SetView.js</script>
</body>
Description + Questions:
When the application starts, SetView.js will be loaded, and the purpose of this script is to look at localStorage and determine which view should be displayed. (View1, View2, or View3). The goal is to keep SSheader fixed at the top of the screen at all times. Only TransitionViewDiv would update.
Questions:
1) What coding approach can be used in SetView.js to load one of the 3 possible views into the TransitionViewDiv?. I did findin dojo 1.9 specs an example using dojox/mobile/ViewController but I was not able to get the sample code to work as documented by dojo.
2) Is the approach of having the TransitionViewDiv necessary, or could View1, 2 or 3 be loaded without TransitionViewDiv? Keep in mind that each view View1, 2, and 3 are defined as individual Div's.
Appreciate any advice to accomplish the above approach, or welcome any suggestion on the best practices to accomplish the transition.
Scenario #2:
As a follow-on to the scenario 1 above. Once View1, 2 or 3 is successfully loaded the views will have buttons defined that will want to cause the transition to another one of the remaining views. So, if inside SetView.js the decision is to slide in View2 to be displayed, View2
will have buttons that will want to load for example View3.html.
Description + Questions:
1) Would the best approach to load View3.html from View2.html be to use the moveTo on the button click, or should the button use the callback to invoke javascript to cause the transition similar to what was used to load the initial view?
Appreciate any advice on the best practices to managing multiple view stored in independent files. In the end the application will have upwards of 15+ ViewXX.html files each containing a Div. Based on this, having all of the views in one html file and forcing the hide, and show is not feasible.
Appreciate your time and help
To load an HTML fragment (View1.html, View2.html or View3.html), you can use the dojox/mobile/ContentPane. This widget allows you to provide a href property that can be used to specify the location of the view.
You can also alter it later on by setting the href property again, for example:
registry.byId("myContentPane").set("href", "View2.html");
You should keep the div#TransitionViewDiv and programmatically add the dojox/mobile/ContentPane to it, or use declarative syntax and add the following attributes:
<div id="TransitionViewDiv" data-dojo-type="dojox/mobile/ContentPane" data-dojo-props="href: 'View1.html'"></div>
Your second scenario is differs from the first one. In the first one, you actually have 1 view with many fragments, while in your second scenario you have many views.
If you only have 1 view, you cannot transition to other views (there are none). So if you want to use transitions you cannot use dojox/mobile/ContentPane.
However, if you have seperate views, then that means you need to move the header to each view (since they're part of it). For these, more complex cases I think you should look at the dojox/app module. This covers a lot of the MVC code for you and the only thing you need to do is configure it.
If you're not interested in the dojox/app module, you can try to inherit views. You might want to look at this answer I once provided. In the comment section of that answer you can also find a more detailed JSFiddle. In this example the header is actually inherited. I also wrote a more detailed article to handle this case .

Seaside calling a component inside javascript

I have a seaside application with a master-detail page. The master page has a table that consists of a list of tr records. When the user clicks a particular tr element, I want to call a detail component, which'll show the individual record's data.
Since I cannot make a tr element with callback or have it contain an anchor with a callback, I want the tr's onClick property to have some JavaScript which'll call: subcomponent . When I tried this, I got an error saying call: can only be used in callbacks and tasks.
Using ajax is a workaround, however it breaks the back button.
Edit:
More generally, I'd like to know how to set callback like behaviour for various JavaScript events.
Well, you cannot render a component in a tr element, but you could add some anchor or other element in one of its td children.
For my project I did roughly the following: I added an anchor to each row with a special css class, e.g. '.dblclick-action'. This anchor has a normal Seaside callback.
Then I bound a dblclick handler to the tr element that does something like document.location=$(this).find('.dblclick.ction').get(0).href;
I am not close to a Smalltalk image now to give you source code, but I hope you get the idea: you don't use Ajax to click the link in that particular row, but instead have the browser navigate to the callback that is associated to the link in that row. You could say you use the tr.'s dblclick handler to click the link and then let the normal Seaside stuff do its work. No magic there. You can find a little bit more info here.
If you don't want the anchor to be visible you may want to experiment with making the anchor invisible (display: none) or the like.
If you are a bit more experiment friendly, you can also try saving a callback on the server and render its url with callback id as an attribute of the tr element and use the dblclick handler to follow the link from that attribute you extract the value of an attribute in query using attr().
I forgot to answer your initial question: you cannot issue a call: from javascript. But you can use the document.location trick to re/misuse an existing link to a callback on the page using the technique I described in my first answer.

What HTML5 Tag Should be Used for a "Call to Action" Div?

I am new to HTML5 and am wondering which HTML5 tag should be used on a Call to Action div that sits in a column next to the main content on the home page.
Option 1:
<aside>
//call to action
</aside>
Option 2:
<article>
<section>
//call to action
</section>
</article>
The reason I ask is because I don't see either option as being a perfect fit. Perhaps I am missing something. Thanks!
My HTML for the Call to Action:
<section class="box">
<hgroup>
<h1 class="side">Call Now</h1>
<h2 class="side">To Schedule a Free Pick-Up!</h2>
<ul class="center">
<li>Cleaning</li>
<li>Repair</li>
<li>Appraisals</li>
</ul>
<h3 class="side no-bottom">(781) 729-2213</h3>
<h4 class="side no-top no-bottom">Ask for Bob!</h4>
</hgroup>
<img class="responsive" src="img/satisfaction-guarantee.png" alt="100% Satisfaction Guarantee">
<p class="side">We guarantee you will be thrilled with our services or your money back!</p>
</section>
This is a box on the right column of a three column layout. The content in the large middle column gives a summary of the company's services. If you wanted to use those services, you would have to schedule a pick-up, hence the call to action.
Does anyone object to this use of HTML5, or have a better way?
My take is that the best practices for the new HTML5 structural elements are still being worked out, and the forgiving nature of the new HTML5 economy means that you can establish the conventions that make the most sense for your application.
In my applications, I have separate considerations for markup that reflects the layout of the view (that is, the template that creates the overall consistency from page to page) versus the content itself (usually any function or query results that receive additional markup before being inserted into the various regions in the layout). The distinction matters because the layout element semantics (like header, footer, and aside) don't really help with differentiation of the content during search since that markup is usually repeated from page to page. I particularly favor using the semantic distinctions in HTML5 to describe the content the user is actually searching on. For example I generally use article to wrap the primary content and nav to wrap any associated list of links. Widget wrappers are usually tied to the page layout, so I'd go with the convention of the template for that guideline.
Whenever I have to decide on semantic vs generic names, my general heuristic is:
If there is a possible precedent already in the page template, follow that precedent;
If the element in question is new part of the page layout (vs a content query that is rendered into a region in the layout) and there is no guiding pattern in the template already, div is fine for associating that page layout behavior to;
If the content is created dynamically (that is, anything that gets instanced into the layout at request time--posts, navigation, most widgets), wrap it in a semantic wrapper that best describes what that item is (vs how you think it should appear)
Whenever authoring or generating content, use semantic HTML5 markup as appropriate within that content (hgroup to bracket hierarchical headings, section to organize chunks within the article, etc.). This is future-proof enrichment for search.
According to all this, div would be fine as a wrapper for your widget unless your page template already establishes a different widget wrapper. Also, your use of heading elements for creating large, bold appearance within the widget is using markup for appearance rather than for semantics. Since your particular usage is appearance-motivated, it would be better to use divs or spans with CSS classes that can let you specify sizes, spacing, and other adornments as needed for that non-specific text rather than having to override the browser defaults for the heading elements. I'd save the heading elements for the page heading, for widget headings, and for headings within the primary content region of the page. There can be SEO ranking issues for misuse of headings that are not part of the main content.
I hope these ideas help in your consideration of HTML5 markup usage.
So far as the semantics of the markup go, Don's advice makes sense. (As you said your CTA was visually beside the main content and secondary to that content, I would favor aside, but there's no single correct answer.)
However, you've tagged your question with "seo," so I take it you're interested in the SEO benefits of using the right markup. At this time, Google doesn't give special weight to having nice, semantic markup---they don't care about the difference between things like aside, section, and div. This may be partly because the meaning of these tags is still being defined (by the practice of Web devs), but they even seem to ignore tags that are clearly relevant search results (like nav, which will almost always be irrelevant to a page's description in the search results).
Instead, they heavily favor using microdata for marking up rich semantics. In the short term, marking your page up using the Schema.org WebPage microdata will likely provide greater benefit. You can mark your CTA as a relatedLink or significantLink, and keep it outside the mainContent of the page. If you're looking to optimize your page for search, this is a great way to do it---in my experience, Google very rarely shows text outside of your mainContent block in the search results description.
Proper markup depends on the actual content, which you have not provided.
That said, wrapping everything in a div is fine (although perhaps unnecessary) no matter what your content is as the <div> tag has no semantic value. Your two examples are probably not correct, unless your "call to action" is literally an entire article (which I doubt is the case).
The call to action might occur within an <aside>, but it's not likely that the call to action is the aside itself. Once again, that depends on the content (what it is) and context (where it is in relation to other content).
Typically "call to action" is a link somewhere, so the obvious answer to me is using an anchor, <a>.
It's just a link to another page. Use a div.