Three Artists'



Three lives that span an era.

Paul Cézanne
Vincent Willem van Gogh
Pablo Picaso



Design by Riverleaf™ ©2019

Gallery filter Guide

Paul Cézanne ❦ 1839–1906

Self Portrait in a Bowler Hat, 1874 ❧ The Bathers, 1874 ❧ The Fishermen ~ Fantastic Scene ❧ Madame Cézanne, La Boule in a Red Dress, 1877 ❧ Leda and the Swan, 1880-82 ❧ Harlequin, 1839 ❧ Pine and Red Earth, 1895 ❧ La Maison Maria, 1895 ❧ Still Life with Carafe, Bottle, and Fruit, 1906

Vincent Willem van Gogh ❦ 1853-1890

Self Portrait with Bandaged Ear, 1874 ❧ Sunflowers Still Life, 1887 & Sunflowers, 1888-1889 ❧ Van Gogh's Chair, 1888 ❧ Irises, 1889 ❧ A Wheatfield with Cypresses, 1889 ❧ Farms Near Auvers, 1890 & Houses among Auvers Farms, 1890 ❧ Long Grass with Butterflies, 1890 ❧ View of Vessenots near Auvers, 1890 ❧ Landscape with a Carriage and a Train, 1890

Pablo Picasso ❦ 1881-1973

Self Portraits, 1896-1972 ❧ The Old Guitarist, 1904 ❧ Les Demoiselles d'Avignon, 1907 ❧ Three Women, 1908 ❧ Portrait of a Lady, 1921 ❧ Bull State VII, 1945 ❧ Mediterranean Landscape, 1952 ❧ Homme a la Pipe, 1969 ❧ Tete d'Hom, 1972

Gallery Design Credits

CSS-PlayW3 SchoolsRebecca W3CWikipedia

Viewport grid internal links

The problem

In a technical nutshell, viewport grid input-label links observe emerging HTML technology.


Viewport Grid: a page containing more than one viewport grid, also called “grid page”, or just “grid”.
Grid Scrolling: construction implements secure browser object handling behaviours. However, that security entails restricted control of page objects (content). Secure content restrictions lock out usual hypertext linking protocols. Generating the context of this discussion. How can we link the grid icons to the grid pages, in their exising layout, that is as viewport objects, on the HTML grid, where each grid provides display boundaries of the HTML grid-page?

Viewport grid link construction

Issue: cannot link to grids A1-A9 inline.
CSS-Play demonstration presents the same issue. How can we link from one grid ‘page’ to another grid ‘page’?

Each grid ‘page’ is a scrolling div id container. Tags input and label help browsers to display a scrolling space for each page's div-id. An unlimited number of ‘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. Input checked is styled to display the active grid page:
<input type="radio" name="panel" id="x1" checked="checked">

Grid ‘page’ content must be placed after the opening input code lines, and before the closing label code lines, or the grid links will not work.

Just before the closing /body tag, each input item is provided with the corresponding label tags:
<label for="x1">a1</label>, etc.

Viewport grid link restrictions

  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.
  2. 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.
  3. 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.
  4. 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.
  5. 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?

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 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.

CSS Play

Did anyone ever tell you how this site was inspired in the first place by CSS Play? Well it was, you know. And now you know for sure!

CSS Play ( has been curated by STU, and an entity known as Nichols, for decades.

Now, in forums a-plenty and everywhere else we look, the Nichols entity only exists as a collect-on-and-on forever type dude in Dageurotype-like photos, and nobody knows who he is.

One day, beleive-me-or-not a mountain of personal online research narrowed down this STU entity to a United Kingdom Technical University. We leave you, the reader, to ponder whetever the "S"may stand for... long string of thoughts here.

Which would explain how the entity whom has (or more correctly 'which did') respond in factually ever-so-many always unique emails over the years and decades, did retire from campus to die several times! Oh dear. Once with a nasty bout of leukemia. Another time (or maybe twice) failed kidneys. Perhaps the best loved British professors get tossed into a giant STU'ing pot, souped, so-to-speak. Tastey prosperity. Truly!

For solid proof-positive, kindly visit .

Doing It With Style

Eh! Whose it this time?

You see it now?

Its always a fascinating circus of odd-balls painting pictures of your actual hunger organ. To make you want to eat more. Check it out. Check the address bars when you RESEARCH those pages.
Because if you see... OF COURSE YOU KNOW
You hit it again... Another "404"
Well, that's it, honey. IT means:

Because we found the proof, of course... ONLINE!

((( where else )))


Understanding A-B-C Racism Today

Cougar Lizzy's hot-tub Bucky amerigo ship-rat back home in Europe. Game plan, help Lizzy pay 127 trillion Euro debt that jumps from 4% to 8% interest when Lizzy brexits to loot governmment banks in colony amerigos, terrra del fuego, hop to baffin island, ausimandius, kiwi-and-everwherelse...

My Mother always did say,
We live in a wacky world.