RiverLeaf design perspectives...

Element a's link family

On this page, we focus on the TOC compendium (Contents and Index). To get there, we discuss how parent element a, containing child elements a, are grouped in a link family. More specifically, we explore the way that HTML weights do prioritize display of link family elements. Designers can manipulate the code's structure with style, including animation (that we leave for all to explore). Our interest here is the link family code structure. Instabiity that we discuss below suggests that W3C will strengthen the link family in years to come. Here is the style behavior that inspired this page (for browser and system information, see below).

Coding - menu and nav, a and li...

Group element a, in this way:
<nav><ul><a href="link"><li>webLink</li><span>docLink</span></a></ul></nav>

2014 a year of change...

Combinative strings of elements define Web data exchange, and for the first time in the history of the web, the HTML exchange base is becoming stable in the global and secure network, World Wide Web.
<ul> <li> <a> [content] </a> </li> </ul>
It is a painfully obvious eyesore, that parallel use of the above universally standard linking technology is excluded from all major operating systems' built-in and complimentary document applications. HTML5 technology and the above traditional element string works fine on all of our modern computing devices! We DO NOT WANT the toxic layers of javascript and other programming, that awkwardly glue together failed attempts at the missing service, core-web integration... Ever so sadly, it will be a long time before we lose the paranoia and greed that promote the glue.

Modern coding looks more like this:
Not again...
Happy family, except W3 Validator 2014 wants <a> inside of <li>. For styling reasons, we need <li> inside of <a>.
<ul> <a> <li> [content] </li> </a> </ul>
We have to ignore the Validator, again.
Oh Gee, who'd a thought...    Great, it works on a web page!

That stable A-LI inversion is a new DOM feature, PROBLEMATIC as it is not culturally appropriate, for PLUG-AND-PLAY coders. Yet, some of us see PROMISE, and ask what can be done with that elemental inversion of coding culture? For many of us, it suggests inherent security and creative potential, in links. Some of us envision system improvement that will enable security and creativity, unheard of in today's world. We must strive to develope and extend our code. On this page, we make a reasonable case for extension that exists. Our interest here, arises from the styled presentation of linking, that we call the LINK FAMILY.

Further, in the global culture of established HTML5-CSS3 code, that new element nav is unfamiliar. Or, is it menu?
Performace of li inside of a, and using menu and nav together, as we all will demonstrate, is due to new machine technology using new Web technology. It has just happened, and we cannot ignore it. ;-()...

menu

Further, note that the menu tag indents more than the nav tag - also, that menu and menuitem elements are intended as classic presentational form tags! Occidentally, nav is a newbie, full of bounce, and unrestrained. Maintaining tradition, should we erstwhile allow menu to parent nav? Some of us think that twist rocks!

Menu-nav diadic response is a critical development, that illustrates wonderfully how Web exactly transcribes countless millenia of human civilization (almost). The question of resilience is best answered when we look at the foundation structure of written culture, that is the Table Of Contents, or TOC.

The compelling navigation feature that demands TOC formality is obviously the MENU element. The only navigation feature with the flexibility to style TOC is NAV. Together, menu and nav are ideally suited to TOC construction. Commanding execution for both Content and Index regions of formal publication.

Sadly, in the year 2014, HTML and CSS are (like their Validator) grossly incompetant. We are perhaps a decade away from the full scientific realisation of our Link Family... Rather, we have a traditional, gentle easing-in of functionality. W3C will respond to its recognized diaspora. Let's jump ahead a few years...

2019 enhancing navigation...

The navigation elements (a, nav, menu, menuitem - in focus here) conform to and improve the li-a cultural inversion. Device compatibility and online document sharing, also deserving of mention, further support that inversion. 2019, we see vastly improved Web document conversion to PDF document format. PDF security may illucidate W3 process success, for the Web and Core Services interchange, perhaps defining in some way the nascent stirrings of HTML6-CSS4 'style' direction. Why mention pending language evolution here? HTML5 and CSS3 perform flawlessly in the PDF environment, making that environment ready for the next generation of DOM. Case for pushing on, concluded. Next step, explore what we have. Connect within inevitable change.

HTML5 and CSS3 evolve in the proprietary browsers, to fix issues and complete transition from HTML4-CSS2. That smudge-along can go on, forever! DOM design platform is thus stable. HTML5 and CSS3 are not satisfactory, but crude, blunt design tools. All designers and developers are waiting for the resposible engineers to give us more. Why is it that progress and security always clash? Regardless, today's environment is ripe for exploration of... well, everything, including navigation. Locally, the improving online security mesh almost completely lacks any foothold.

No popular operating system provides built-in and standardized “local” Web format. For example, Apple's TextEdit offers exceptional archive work with cut-and-paste Web code. However, it is not a web editor: adjust preferences to default html production, and with unfortunate consistency, every html document is corrupt, when production displays in browser. On top of that there is no external style sheet integration, no code hinting, and that list of blocked online features goes on, without end. Microsoft is equally useless. For now, OS text editors are great archivers, but system deployment does not favor an online local editing interface, yet. Until the OS manufacturers pay for the missing security that is their next step.

Build - institution of element a...

To build the TOC application, we must gather the components that institute performance, and construct HTML and style CSS accordingly. We begin with the question, “What is data?”... Clearly, the HTML-CSS cultural context is grossly primitive, because so many critical features are missing. In the very basic TOC deployment, where are the parent HTML language CONTENT and INDEX elements? Without Content and Index tags, without that very basic STRUCTURE in educational materials, there would be no Web! Our engineers would never have graduated! Primitive!

! ! !

It's time to (finally) enhance search for professional HTML publication. To put that in perspective, consider cursory and impact environments.

Evidence: proof, confirmation, verification, substantiation, corroboration, affirmation, attestation...
the available body of facts or information indicating belief or proposition in situ...
be or show evidence of existence.
Search engine: compare WWW, source of unfilterd data collection, requires continuous user optimization
Index: compare TOC, filtered content reference, requires professional publication
Clearly, construction of the TOC compendium involves more than the introduction of two (2) simple HTML tags, though that custodial system concession is essential for academic and professional Web culture to thrive.
DOM
Native isolation of new content element and index element, as special operands for navigation elements
Direction
Content and Index, traditional style envelope, fitting into CSS hiearchy under 'body' element in HTML language
Structure
New layout, placement and texture for element a, complete and comprehensive overhaul to include parent a and child a Link Family relationships

Correction of common (sic., public) cultural and technological illiteracy is in order here. Document search is NOT the same data process as Index. Both methodologies should always compliment each other, but are mutually exclusive in the benefits each provides. Document search is always unfiltered, divorced from any context, except a very short text-string. Great to resource (locate?) that rare knowledge exception. Index is extensively filtered, prior to publication to exactly fit, and link to the flow of information in the document.

Generally speaking, civilization critical publications tend to provide massive Index resources. The linked TOC (Contents and Index) are essential components of all significant online publications. The rag-tag appearance of TOC in our browsers today, is a matter for greater concern... PDF is a popular format for document distribution with unhealthy, crappy support for HTML5-CSS3 TOC, failed efforts in the present absence of HTML support. But then, locate the original HTML documents and they are not so great, either. In fact, Content is a lame menu, and Index is almost universally ignored. Readers are left by scud publishers to google what they need, wherever. Or scroll through undirected page searches with a browser. Bad. Very crappy, semi-literate publishing standards.

Full support for CONTENTS and INDEX, in browser display and in PDF conversion, requires the existence of MISSING HTML ELEMENTS CONTENT INDEX. (Argh!!!) Carry on...

TOC process

Yes... Our TOC compendium lacks massive popular 'scientific' recognition. We know that CSS can illustrate TOC behaviors that speak to enhanced functionality and increased security. We know that HTML has yet to deploy those behaviors as actions in the browsers. For now, nothing to stop us from using <content> and <index> tags, experimentally as we wait for W3C to catch up.

tool administration, coincidental users.

For the greater good...

It is rock-solid, using Safari 12.1.1, that child element 'a' links can be contained inside of the parent element a. That is our link family.

Now, the child element a bridges many things, inside of the container parent element a. That process involves intersection of HTML language elements. In a typical designer construction, intersections do not demonstrate any unique behavior, do not stand out and disrupt link actions. CSS coding locates and exploits intersection leaks. Intentional leaks, called hooks, and unintentional leaks called anomalies, all are fair game for the CSS output known as style.

Traditional CSS styling shapes this page, in order to enhance discussion of those hooks and anomalies. Our opening webLink-docLink demonstration shows how the link family can be styled. Link styling traditionally is used to demonstrate function.

Traditional CSS styling shapes this page, in order to enhance discussion of those hooks and anomalies. Our opening webLink-docLink demonstration shows how the link family could be styled. Link styling traditionally is used to demonstrate function. As we show below, HTML5 element a appears to block styling of its functionality.

Element a's link family codification...

Now, let us design the link family. This design rests in my discovery, Spring 2019 that the parent element a can now contain one other child element a, with specific stable functionalities enabled. In prior renditions of OS and of browser, we could not place child a inside of parent a, so this is a new and welcomed direction for W3C. The code machine is Apple Mojave 10.14.5, and the code bahavior is displayed in Safari 12.1.1 and also in FireFox Tor 8.5.1 based on FIreFox 60.7.0esr. The foundation link family being analysed is constructed as the traditional HTML link family.

  <a> parent <a> child </a> </a>

Due to presently lacking development of parent-child relationships in the HTML5 language around element a, we cannot yet use CSS to easily enable special behaviors to effect all of the parent-child relationship potentials, specfifically for the element a. We can exploit link family behavior in other ways. For example, hovering, opening, closing behaviors are interpreted by the browser, as we show below. Though the expression of those style or display behaviors is blocked by the Web browser only for element a in traditional HTML configurations, we can begin to style the link family.

By example...

We can style other elements inside of the element a link family. Experimentally, we remove the injection of child element a, coding the unordered list elements nav ul, to change color of element span, when we hover a li. This is uniquely styling elements contained by element a, and therefore institutes in the HTML language, the simple construction of the link family.

Below, items webLink and docLink constitute a specific application of the link family insitution in HTML. Both webLink and docLink are grouped inside of the single element a. Inside of element a, element span gives more weight to contained docLink. Hence, with span we isolate, and provide unique behavior to span docLink grouped inside of element a. Thus, hovering docLink highlights only docLink, yet hovering webLink highlights both webLink and docLink!

Group element a, in this way:
<nav><ul><a href="link"><li>webLink</li><span>docLink</span></a></ul></nav>

Element a family loses its visually shared activity, by placing the child element a inside the parent elements li a span... Though the above style share remains active, HTML display blocks style expression when element a is injected into the code string.

Group element a, in this way:
<nav><ul><a href="link"><li><a href="link">webLink</a></li> <li><a href="link">docLink</a></li></a></ul></nav>

Note that both webLink and docLink open the same link target, in both examples above. While the following features are not provided by current DOM.

  • • The ability of link family to easily share style between 2 or more child element a's.
  • • The ability to share styles while opening seperate links in the same link family.

This weak targetting in the DOM demonstrates an enormous insufficiency in our scientific organiztion of link data. That is, HTML5 is clearly missing the boat, for now.

We can clearly see below, that both styled color and text links respond to isolation of child 'a' inside of parent 'a'. CSS limitations appear, as the element a is deficient in its capacity to isolate and distinguish members of the clearly styled link family. Can HTML5-CSS3 activate style for the display-blocked child a members of the link family? Perhaps, there is a CSS technique that we are not discussing here. Solution is \nNot likely, in HTML5. Element a grouping is a huge W3C accomplishment, that likely involves decades of DOM development. So we may have to wait for HTML6-CSS4 to actuate enormous potentials expressed herein. Beyond the simple a+span exploit displayed here.

Boxed operating systems have yet to fully exploit today's link family, with common user browser facilitations appearing globally. Perhaps special browsing tools like Kali are not hindered in facilitation, like popular browsers. To sum up our current Mojave-Safari facilitations, here now are basic link family behaviors, using the traditional navigation hierarchy parent elements menu and nav.

menu (color is indigo)
css article styles span inside childless parent a
    <a href="http://web.org"><li>parent</li> <span><span>child</span> <span>child</span></span> some text</a>
  • parent
  • child child
      (menu family, css style behavior)
css with element a injected into styled span
    <a href="http://web.org"><li>web.org</li> <span><span><a href="https://w3.org">w3.org</a></span> <span><a href="https://web.dev">web.dev</a></span></span> some text</a>
  • web.org
  • w3.org web.dev   (menu family, html link behavior)
    <a href="http://web.org">All?   <li><a href="https://web.org">web.org</a></li> <li><a href="https://w3.org">w3.org</a></li> <li><a href="https://web.dev">web.dev</a></li> some text</a>
    All?  
  • web.org
  • w3.org
  • web.dev
  •   (menu family, no span, no link here?)
indented

This is where the menu tag comes to its natural (and oddly indented) end - CSS reset can handle indent.

This is where the nav tag comes to its natural end. Hopefully, this will not be your last appreciation of element a link families. Here we go with menu parent and nav children.

menu <br>
menuitem - almost pure, clssic menuitem form data style, but contains nav menuitem - meet family-type element a

Web design and development need and expect more from CSS. Attribute appearance, content management and character substitution for a (selector a a:hover {?}) is not helpful, ignored - completely absent.

Element a can only display CSS behaviors that were provided before W3C enabled link family coding. Link family does not appear to have any new style, dedicated CSS capacity, to match here the extension of its HTML capacity.

Deploy - link family applications...

Presently, opening the child links WEB.ORG, W3.ORG and WEB.DEV, should maintain existing default, to open only the asssociated link in the link family. In keeping with CSS3-HTML5 style isolation, what should happen with the link families created above?

The first enhancement that comes to mind, is an ability to press a key and select multiple links to open or share from the public browser window. A context menu related to multiple selections is essential. But sky is the limit.

Styling of selector a a should make link family grouping easy. Attribute value selectors are another obvious immediate intervention. Those selectors can style the parent "href=" target parent link, and so on. For now, expect the HTML and CSS to work together as demonstrated above. Link family is a fragile structure, due to the poor support provided by the element a. For example, on this page I want to build CSS so that element h5 floats left, and the first 3 lines of paragraph text float right, wrapping paragraph around element h5: but as soon as I apply this:
h5 { float: left; } and h5>p { float: right; }
then the behavior of elements a-containing-span on this page change, such that the webLink-docLink behaviors demonstrated here, no longer work. Link family construction is fragile, and tentative, in so far as system and device compatibility are concerned.

However, W3C is moving ahead with the link family. So product expansion will shape that move. Perhaps in situ, the popular standard browser context menu option. Also, the ability to select and open multiple links at once could be standardized. Further, for security purposes, the parent-child link relationships could be adapted to engineered networks and devices. Javascript, PHP, Python and other machine assembly systems will be all over DOM link families. W3C will watch how link family is deployed, and HTML-CSS versions will adapt accordingly. More great stuff to come.

(Comments to currents@riverleaf.net)

Resources...

Disclaimer...

This page is constructed using Sublime Text 3, Safari 12.1.1, FireFox Tor 8.5.1, Mojave 10.14.5. Other systems and system components will likely experience the newly emerging link family in a unique way.

end