Now you see it, kind of (apology accepted)?

Viewport grid link construction (notes)

top · problem · construction · restrictions · solutions

Usage: page refresh returns browser to the opening page show. However, as long as the browser window page tab remains open, link or scroll position in each input-label virtual page is retained. So that link and/or scroll origin position displays on return to grid menu virtual page, using the top left nav buttons.

Issue: cannot link grid menu A1-A9 to virtual pages using traditional inline link tags and bookmarks, while retaining 'link memory' to re-open links at last visited location on a virtual page.
CSS-Play demonstration presents the same issue. How can we link from one grid ‘virtual page’ to another grid ‘virtual page’?

Solution: each grid ‘page’ is a scrolling div id container, so deploy targetting grid input/label tag relationship to target id in the link structure.
      <a href="#grid4">
        <input type="radio" name="panel" id="x4">
        <label for="y1">
        A4 LINK TEXT
      </a>
Return from the linked virtual page to the previously active source virtual page by simply clicking that source page's button in the top left nav (in the example below, click inline link to Grid4 and return here to Grid 3 using nav button A-3).

Example 1

Code:
Working link:
<a href="#grid3">
  <input type="radio" name="panel" id="x3">
  <label for="x3">
  A3 LINK TEXT
</a>
A3 LINK TEXT

Example 2

Working link:
<a href="#grid4">
  <input type="radio" name="panel" id="x4">
  <label for="y1">
  A4 LINK TEXT
</a>
A4 LINK TEXTcheck_circle

Code: construct a grid menu using input tags
<input type="radio" name="panel" id="x1">
<input type="radio" name="panel" id="x2">
<input type="radio" name="panel" id="x3">
<input type="radio" name="panel" id="y1">
<input type="radio" name="panel" id="y2">
<input type="radio" name="panel" id="y3">
<input type="radio" name="panel" id="z1">
<input type="radio" name="panel" id="z2">
<input type="radio" name="panel" id="z3">
and now build lables for each input tag
<div class="labels">
<nav>
<label for="x1">a1</label>
<label for="x2">a2</label>
<label for="x3">a3</label>
<label for="y1">a4</label>
<label for="y2">a5</label>
<label for="y3">a6</label>
<label for="z1">a7</label>
<label for="z2">a8</label>
<label for="z3">a9</label>
</nav>
</div>
and now build each id container, input-label tags will link to container id targets
<div id="wrapper">
  <div id="a1">
    <div class="inner">
      <h1>Pablo Picasso... etc.
      note that inside target containers, any input-label link can be deployed using the grid menu link content
      <a href="#grid3">
        <input type="radio" name="panel" id="x3">
        <label for="x3">
        A3 LINK TEXT
      </a>
      <a href="#grid4">
        <input type="radio" name="panel" id="x4">
        <label for="y1">
        A4 LINK TEXT
      </a>
    </div>
  </div>
</div>
CSS now to style grid menu and virtual page content noting that a visible transition from one virtual page area to another virtual page area features the input-label grid menu
a, a label { color: dodgerblue; cursor: pointer; text-decoration: none; }
#wrapper { height: auto; left: 0vw; position: fixed; top: 0vh; transition: left 1s, top 1s 1s; width: auto }
#wrapper > div { background: transparent; height: 100vh; overflow: auto; overflow: x-hidden; position: absolute; width: 100vw; -webkit-overflow-scrolling: touch }
.inner { background: white; border: aliceblue solid medium; border-radius: 1rem; margin: 2vh 15vw; object-fit: contain; padding: 5vh 1vw; text-align: center; width: 70vw; }

* the following input data is required
div[id*="a"] { top: 0; }
div[id*="b"] { top: 100vh; }
div[id*="c"] { top: 200vh; }
div[id*="1"] { left: 0; }
div[id*="2"] { left: 100vw; }
div[id*="3"] { left: 200vw; }
input { display: none; }
input:target { display: table; position: absolute; }
input[id*="x"]:checked ~ #wrapper { top: 0vh; }
input[id*="y"]:checked ~ #wrapper { top: -100vh; }
input[id*="z"]:checked ~ #wrapper { top: -200vh; }
input[id*="1"]:checked ~ #wrapper { left: 0vw; }
input[id*="2"]:checked ~ #wrapper { left: -100vw; }
input[id*="3"]:checked ~ #wrapper { left: -200vw; }
input#x1:checked ~ .labels label:nth-of-type(1),
input#x2:checked ~ .labels label:nth-of-type(2),
input#x3:checked ~ .labels label:nth-of-type(3),
input#y1:checked ~ .labels label:nth-of-type(4),
input#y2:checked ~ .labels label:nth-of-type(5),
input#y3:checked ~ .labels label:nth-of-type(6),
input#z1:checked ~ .labels label:nth-of-type(7),
input#z2:checked ~ .labels label:nth-of-type(8),
input#z3:checked ~ .labels label:nth-of-type(9) { background: rgba(140, 140, 140, 0.8); }

Construction notes... (context)

Viewport declarations are required to construct a virtual 'grid' page. The head tag must contain viewport data:
<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">
<meta id="viewport" name="viewport" content="width=device-width, minimum-scale=1.0, maximum-scale=1.0">

Tags <input> and <label> help browsers to display a scrolling space for each page's div-id. An unlimited number of id-defined ‘grid pages’ can be inserted into any viewport grid HTML page. For our Gallery, we group 9 pages (div id="a") in a 3x3 grid (input id="z")

Navigation builds links to grid ‘pages’ with 2 groups of html tags: <input> and <label> tags. At the beginning of <body> tag, 9 <input> tags are used to list 9 <input> items. One <input> item can be made to appear <checked> by default. The default loading page is indicated thus:
<input type="radio" name="panel" id="x1" checked="checked">

However, browser interaction with input and label tags works better without the 'leaky' checked=checked detail. Which may cause unintended nav highlighting of 2 or more pages. And which destabilizes inline grid links.

Linking grid ‘page’ content must be placed after the opening <input> code lines, and after the opening <label> code lines, but within the <a> element that ponits to grids 1-9.
<a href="#grid3">
  <input type="radio" name="panel" id="x3">
  <label for="x3">
  A3 LINK TEXT
</a>
A3 LINK TEXT

Just before the closing </body> tag, each <input> item is provided with the corresponding <label> tags:
<label for="x1">a1</label>, etc. Within the <Data Input> schema, at the bottom of the page.

Viewport grid link restrictions

top · problem · construction · restrictions · solutions

1. “Grid page”, or ‘grid’ navigation uses 2 blocks of HTML code to construct grid links: grid links open scrolling HTML content containers called “grids” on the viewport page. Because each grid is contained by a label tag, and because viewport styling sets that label to fill the device display, each scrolling grid is locked in the browser display, and it is impossible to scroll out of the label's grid. This creates the illusion that each grid is a separate page. In fact, each grid is simply a div that uses a grid label ID. Grid labels restrict browser visibility to only the content of one grid at a time.
Grid content (e.g., a collection of scrollable grids) targetted by viewport grid navigation must be placed between that navigation's HTML <input> elements and HTML <label> elements; that is, between the two blocks of code. Aditionally, all content within each grid must be placed between the <input> and <label> elements: that is, HTML code for each grid and for each grid's unique content, must be placed between the Viewport page's input-label code blocks. On the viewport grid page, each input-label link and each grid can only occur once, and browsers cannot read and process any other link or view any other grid on the viewport grid page. Input-label navigation should be fixed and always available.
2. We cannot wrap HTML input-label tags around HTML <href="#anything> code linking one grid to another grid's content, because inside of all grids, the opening-closing <input> and <label> code blocks take priority over any further use of <input> and <label> linking. Each grid in the Viewport Grid can only have one input-label link that opens it.
3. Relatively minor issue, refreshing the viewport page ignores the active grid's browser display grid-location on the viewport grid page and refreshes to the viewport page's first grid.
4. Browsers give greater priority to input-label links, than they give to href links, so all of our attempts here tend to fail href while fortunately preserving input-label. Browser engineering solution seems to be a simple inclusion of traditional structure in the new input-label schema. For now, input and label links are exclusive as they depend on singular ID associations that cannot be repeated on the same viewport grid page. This priority thankfully helps to secure scrollable HTML grid containers, but disables local-internal access to those grid container ID's using normal href inter-grid links to each grid's ID. Perhaps this involves a browser engineering solution.

Possible viewport grid link solutions?

top · problem · construction · restrictions · solutions

The problem with Viewport Grid page linking is that even newer browsers cannot find <div id="link-target"> where the <input>/>label> navigation is active (readable). This would appear to be a Net4 limitation, for as we begin leaking Net5 capacities in early 2018, now the >href> linking on the <input>/<label> Viewport Grid pages is improving.

1. Any link to an external page resource works well. So a link with <href="index.html#a5" target="_self"> could work. Click on here to test. Nothing happens, because browsers cannot read <input> and <label> HTML tags to extract link information.
2. We could construct a separate but parallel navigation lattice. We tried to superimpose that lattice by inserting ID's into existing input/label structure: e.g., try to extend <label for="x1"> as <label for="x1" id="something">. But that was ignored (naturally we had to investigate).
   We could try link-target div id's containing the existing label-target link id's.
3. This works only for the label's div-id inside of the same grid.
   the link:
   <div class="grid-item img1"><a href="#grid1"><img src="_files/a1.png"></a></div>
   the target:
   <div id="a1"><div id="grid1"></div>
   the style:
   div.grid-container img { width: initial; }>
   .img1 { background-color: transparent; background-image: url('_files/a1.png'); height: 13vw; width: 13vw; }
4. To link to <div id="grid2"> (etc.) we can now include the parent viewport grid page's address in the local page link, but this strips the grid's <input>/<label> styling... and also strips the <div="label-ID"> scrolling-grid isolation in the viewport grid.
   
   Apple FEEDBACK !!
   
   <div class="grid-item img1"><a href="index.html/#grid2"><img src="_files/a2.png"></a></div>
   This is a vast improvement over dead links a year ago, but clearly early 2018 browsers are still struggling to facilitate more than one navigation technology on the same page... not my auto-pilot drone (or automobile)!

Note that the <background-image> property is used to avoid conflict with the <label> cacscade that includes many <img> tags in the Gallery style hierarchy. We tried the <content> property (housing the image url), but that conflicted and was ignored. Cascade isolation provided by <content> property is ‘preferred’ by W3Schools.com in the Net4 schema. However, the upcoming Net5 schema would likely return to more robust direct embedded element calls, as this leaves room to isolate multi-interface cascades around the style-object media-hub, in emerging dedicated languages' syntax. In other words, HTML5 Viewport Grid page technology presents hub-input as <input-label> calls, and hub-output as styled <img> object, leaving lots of room for interpretation by complimentary code languages.

top · problem · construction · restrictions · solutions