HTML Input Element Types Randomized History Tutorial

HTML Input Element Types Randomized History Tutorial

HTML Input Element Types Randomized History Tutorial

Hashtag navigation such as …

  • window.location=’#place'; // Hashtagging, as being in web page and (you will really quickly go to) HTML element id=place position on the webpage

… is all fine and good in principle, but even this fast navigation can have its fallbacks. If there is a lot of it going on, it can fill your web browser history with lots of entries pretty much, for all intents and purposes, the same as others, and make it hard for the web browser’s Back and Forward (through web browser history (of web pages)) to be of much practical use anymore.

So we need to do two things with our “HTML input Element Types Randomized” (mini) web application project, last talked about at HTML Input Element Types Randomized Iframe Tutorial, which suffers from this frustration.

  • stop navigating in that window.location=’#place'; way and either …
    1. don’t leave the webpage you are on, even to hashtag (which causes a web browser history record to happen) … or, and we don’t do this option today …
    2. use Ajax to navigate (to yourself)
  • take control of what, after the first history entry on starting an execution session is “let through to the keeper”, is written to the browser history (as possible ever since HTML5 came along)

… and in that way, make available to the user three modes of browser history writing (starting with the default) …

  • minimal history (just that first of session history written in a natural web browser functionality fashion) … plus …
  • only unique webpage URL history recordings this execution session (that had #place hashtagging in the old days) … through to …
  • maximum webpage URL history recorded (even repeated #place hashtagging)

… and to do this we, instead of window.location=’#place';ing we now introduce an HTML a link we click and control the click event logic as per …


var cats = { hash: '', ih: '' };
function clickHandler(event) {
cats.hash = event.target.getAttribute('title').split('/').pop();
updateContent(cats); // which just hangs around to let //setTimeout(randomize,3000); be the next action point

// Add an item to the history log
document.getElementById('imyhistory').innerHTML=document.getElementById('myhistory').value;
bihi=document.getElementById('imyhistory').innerHTML;
if (1 == eval(document.getElementById('imyhistory').innerHTML)) { // maximum history
if (sofar.indexOf(';' + document.URL.split('#')[0] + '#' + diarray[choice].id + ';') == -1) {
sofar+=document.URL.split('#')[0] + '#' + diarray[choice].id + ';';
}
history.pushState(cats, document.URL.split('#')[0] + '#' + diarray[choice].id, document.URL.split('#')[0] + '#' + diarray[choice].id); //event.target.href);
} else if (3 == eval(document.getElementById('imyhistory').innerHTML)) { // unique history this session
if (sofar.indexOf(';' + document.URL.split('#')[0] + '#' + diarray[choice].id + ';') == -1) {
sofar+=document.URL.split('#')[0] + '#' + diarray[choice].id + ';';
history.pushState(cats, document.URL.split('#')[0] + '#' + diarray[choice].id, document.URL.split('#')[0] + '#' + diarray[choice].id); //event.target.href);
}
}

return event.preventDefault();
}

Why the variable name cats? In honour of a very useful link, thanks.

The HTML and CSS and Javascript becomes hashtag_idea.html and changed this way regarding web browser history improvements.


Previous relevant HTML Input Element Types Randomized Iframe Tutorial is shown below.

HTML Input Element Types Randomized Iframe Tutorial

HTML Input Element Types Randomized Iframe Tutorial

There are lots of things to be “cross” about trying to code for all eventualities to do with web applications … we’ll just limit it to that

  • computer device … cross platform
  • web browser … cross browser … and add to that, on occasions …
  • supervision “mode”

… and by supervision “mode” we mean that surprising “assumptions” may be thrown out the “window” (tee hee), we’ve found out usually relating to using mobile devices, when your web application is hosted in an HTML iframe things do not function anything like it does as “top.document” (ie. the first “call” of the web browser address bar) even when everything else is the same. Okay, in our experience, this is rare, but think we remember when on other occasions this issue has reared up in front of us, it was, as with today, to do with issues revolving around …

  • horizontal hashtagging … and associated …
  • horizontal scrolling … when your …
  • content extends to the right beyond the physical width of the (we’ve always found it to be, mobile) device

And so, we’re revisiting yesterday’s HTML Input Element Types Randomized Primer Tutorial because we found that when we hosted its associated “HTML input Element Types Randomized” (mini) web application in an HTML iframe element, as we did at the blog posting, here, we hadn’t tested this on an iPad, for instance, and found to our horror the next morning that it worked okay as “top.document” (via a “click picture”) execution, but showed very little content when hosted by the iframe and when using any of the web browsers (we tested Safari and Chrome) on an iPad (mobile) tablet.

We spent several fruitless hours persisting with our stubborn “horizontal scrolling” approach, and we’ve left that struggle in the code, for others to take up, if they feel adventurous, but the solution required a little bit of simplistic thinking.

We live in a three dimensional world. To be “stuck on” the idea of “horizontal scrolling” is to ignore the Y and Z dimensional “view”, in favour of “X” thinking. What about “Y” thinking? Well, after the “X” struggle, we thought about it, and thought maybe this was feasible with less talk on Google about “vertical scrolling mobile issues” than the heaps about “horizontal scrolling mobile issues”, but then the “vertical” “Y” thinking has its own problems. The “height” of a device is a bit of a vague concept too, and it has the complication that if you want to specify a height that equals the device height, we’ve found success using units in “vh” rather than “%”, and we started thinking this aspect alone will lead to as much complication with “Y” thinking as “X” thinking.

So, what about “Z” thinking? Well, there is the joy with CSS’s wonderful (and we normally talk about with “overlay” thoughts) …

… as the web application equivalent of our geographical talk regarding “elevation”. Let’s “cherry pick” our way out of the issues! The problem can be solved really simply with the MVC (C represents Javascript) “wresting of control” from the default MVC (V represents CSS) percentage definition of HTML div element’s …

  • left property … and for our problem cases, which we bit the bullet and classified as “all mobile devices” we “wrested control of left to 0″ (via Javascript DOM, once, at the first call) and started, instead, to make the dynamic property, be …
  • z-index which we, on a first call case, set to an “order indexed value” (Javascript DOM wise), and increase for a particular “focussed” “HTML input Element Type” (and then later defaulted back to its “order indexed value”) as execution of the web application proceeds

… as a much simpler solution, where for these problematic cases, think (a web design involving) “a wad of A4 sheets” (like vertical stacking) versus the default “film strip” (in X) (ie. horizontal scrolling) approach and the coalescing “concepts” of …

  • overlay … and/or …
  • reveal

There’s that issue, and then there’s the other “forward move” with our web application. Did you end up reading HTML Textarea and Div Talents Primer Tutorial as you were invited to yesterday? There, you would have seen a table as below explaining …

But their strengths and weaknesses go like this, at least to us, in the limited HTML text view of things …

Text Functionality Issue HTML Element Type Strength Weakness (where a “Yes” is like … “Oh No!”)
Display Monocolour Text Textarea Yes
Div Yes
Display Editable Text Textarea Yes
Div Yes
Display Multicolour Text Textarea Yes
Div Yes

As you would have viewed yesterday’s incarnation of the web application, your eye may have not known where to rest, with respect to the middle bit or the report bit, because both change, but the “middle” is immediately relevant whereas the bottom HTML textarea element report can sometimes be of diverting interest. Well, that is the scenario, where something of “diverting interest” but with quite a lot of content to take in, can benefit the user greatly with a “focussing” technique, such as just highlighting the tiny bit of its content that changed just recently. You can’t achieve this “highlighting” with the HTML textarea element, but you can with an HTML div element, which we … you guessed it … separated from the HTML textarea by establishing different, and Javascript DOM dynamically controlled …

… the “star” of today’s work.

The “top.document” live run link hopefully has an execution look the same as the HTML iframe HTML iframe hosted live run (below), especially on a mobile device. The HTML and CSS and Javascript is now downloadable as hashtag_idea.html and changed this way.


Previous relevant HTML Input Element Types Randomized Primer Tutorial is shown below.

HTML Input Element Types Randomized Primer Tutorial

HTML Input Element Types Randomized Primer Tutorial

We are quite pleased here, with a web application design (mini) project, when all three of …

  • HTML
  • Javascript
  • CSS

… get a relatively even workload, and also that you can think of their roles as being quite separate in code presentation. Sort of like that separatism I remember leaving the best bits (ie. the “Javascript” of the “food” world) of the meal to last as a kid. And so it came to pass here, as the order of attending to the code was …

  1. HTML
  2. CSS
  3. Javascript

… and it occurs to us, if you like compartmentalization yourself as a creed you are going to see some MVC‘ism (Model-View-Controller … we venture HTML-CSS-Javascript (DOM)) in all this. We find the use of HTML with inner CSS and inner Javascript irresistible generally, but it is satisfying taking a rest from this.

What’s the go with today’s “HTML input Element Types Randomized” (mini) web application project today? It was inspired by yesterday’s “horizontal hashtag” talk when we presented Zipfiles in PHP Image Gallery Navigation Tutorial and coalesced into those web design “staples” …

  • overlay … or …
  • reveal

… we use around here to pare down the web design process into our most popular two constructs, today’s falling into that reveal “staple”. We’re doing a “horizontal” “reveal” off the user’s screen today via CSS concepts of …

  • position:absolute property … teamed, primarily, with the control of …
  • left property … using percentage values off the screen, such as 500% being for the sixth “reveal” “webpage” of interest (and so things don’t “jigger” too much we make the HTML div width be almost 100% (ie. 98%)) … and making use of …
  • window.location=’#place'; // Horizontal hashtagging, as being in web page and (you will really quickly go to) HTML element id=place position on the webpage … facilitated by our, so often used, “randomosity” Javascript construct …
  • choice = Math.floor(Math.random() * diarray.length); // where diarray array is a collection of what is today's "content" idea, that being ...
  • HTML input element type properties “presentation” within HTML div elements showing the look, a type and the HTML outerHTML property (where we use the CSS pseudo-element #dbutton::after { content:'\A\A Button\A\A <input type=button value=Button></input>'; } type of syntax to effectively add “captions”) in the middle of the web page … with a top heading (h1 and h3), as well as …
  • HTML textarea element (and it occurs to us a read of HTML Textarea and Div Talents Primer Tutorial would be good, again, here) containing a report of the “randomosity” and being pulled along “horizontally (as with the h1 and h3) via …
  • document.getElementById('myta').style.left=window.getComputedStyle(diarray[choice], null).getPropertyValue('left').replace('px','') + 'px'; // powered by a self calling and self timing ...
  • setTimeout(randomize,3000); // call of the one Javascript function of our (mini) web application project ... as you can see happening with ...

… to end up with a “horizontal hashtagging” “reveal” “HTML input Element Types Randomized” web application you can try at this live run link and with this HTML/CSS/Javascript hashtag_idea.html source code (all together, but really suited to redesigning with external CSS and external Javascript).

If this was interesting you may be interested in this too.


If this was interesting you may be interested in this too.


If this was interesting you may be interested in this too.

This entry was posted in eLearning, Event-Driven Programming, Tutorials and tagged , , , , , , , , , , , , , , , , , , , , , , , , , , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>