No long-winded apologies, element a has got us huffing and puffing. 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. That is, informally, the raw DOM (data object model) HTML and CSS. 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).

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. ;-()...

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

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

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.

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. What functionality can the outdated HTML5 provide to the link family, without javascript or PHP container interventions? Link styling traditionally is used to demonstrate function. Assuming the links below were <content> or <index> components, clicking on parent web.org should open parent link web.org, and both of the child links, w3.org and web.dev.

<a href="http://web.org">web.org... <a href="https://w3.org">w3.org</a> <a href="https://web.dev">web.dev</a> </a>

web.org...   w3.org, the ordinal web.dev, by google (link family is here, test links in your browser)

Optimally, the browser should open the link family in the following manner.

• → Opening family Parent replaces existing page (or other instantiation, per user preference). Child links are placed in sleaves or columns or icons, in a window page bottom area - similar to developer page-bottom code view. Mobile devices can use columns or icons. Click or tap of link family child item, swaps child with parent. Thus child becomes a parent, in main window, with Address bar and all other active address functionality.
• → Opening family Child behaves as any non-family link.

Traditional CSS styling shapes this page, in order to enhance discussion of existing, but not utilized 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 is primitive, blocks styling and functionality of link family. Yet all links are fully functional. Grossly under-developed by the W3C browser manufacturing community.

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.

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.

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.

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.

An investment in knowledge pays the best interest. -- Benjamin Franklin

(Comments to currents@riverleaf.net)

Link family page: issues

1. Page: fa-rd-cd (current deploy)
2. 1. fa-nr
3. 2. fa-rc
4. 3. fa-rd
5. 4. fa-rd-cd (current deploy)
6. 5. fa-rm-id (issue discovered)
7. 6. fa-rm-nc
8. 7. nf-nr
9. 8. nf-rm

New technology has its perks, and quirks. Link family <code> and <a> tags are not behaving as expected. Apple insists the code is good, the server is at fault. Server staff, not understanding code, blames code. Together, they are rapidly making the code work. Little else, can we mere mortals comment. Kindly refer to links sbove (alphabetic)... Service FontAwesome fa is CDN. Service MiniReset's rc is CDN and rm is local CSS: both rc and rm are subject to ongoing unstable development. Service HTML5 Doctor Reset rd is subject to stable development... Further, the fa-rm-id (issue discovered) page is where the issue was moved to troubleshooting teams, 2019-Jun-27. The fa-rm-nc (no code) page is where the code tag remains inline, however, code style is removed from reset min local.

Two resets are implemented in the link family test, MiniReset and HTML5 Doctor Reset. Stable performance is provided by the "no reset" page, and by the "HTML Doctor Reset", or rd. Further code discussion appears below. It is a reasonable assumption that developers and designers would benefit from inclusion of HTML5 Doctor Reset in exploration and deployment of link family code... We leave ongoing exhaustive browser testing to manufacturers, servers, and back-end developers. Our coincidental personal discovery of the link family, constitutes designer interest. Importantly, MDN Firefox that initially had no problem with fa-rm-id, now appears to have adopted the display problem provided by Apple Safari. This establishes code that is not standards appropriate, for now.

This page, and all pages linked above (containing link family code), consistently display link family code without any corruption in Desktop browsers Safari and FireFox. However, online pages tend to often demonstrate corruption. Apple compared our desktop and online displays, and over a week this interactive Link Family demonstration appeared. On Apple's advise, a2Hosting moves to more rigorous server back end investigation of link family. We assume that Apple is providing back end support, as over several days issues resolve, and sometimes fall back into disarray. Essentially, we are provided the opportunity to isolate the code method that is appropriate to the online link family. Assume that [previous] unanimous Desktop support for any method will eventually resolve to the emerging online standards support: network device and display considerations are also in play, where a far more conservative, possibly guiding (?)s role would be usual.

Initially, 2019-Jun-23, Apple provides the following advice for server staff. Where the HTML code tag string (<code> </code>) is used to display code, the server is incorrectly truncating the closing HTML code (</code>) tag... On a page that is effected by this truncation problem, each code element text display appears in Safari and FireFox as styled font-family, but unexpected normal system font-size: the styled font-size is ignored. Further, each code element suffers an unexpected line break, moving each code tag string (<code> </code>) to display in Safari browser on its own line of text. The cause of this truncation is not understood. Finally, link code generally does not perform as expected, with a quality of malfunction that strongly suggests incorrect coding for the link family application.

The problem is investigated server-side. Apple maintains some interest in local Safari behavior, around this demonstration of the link family... In several days, some code tag issues resolve, some issues do not resolve, other issues resolve and fall back into disarray. Clearly indicating ongoing back end development with generall improvement of link family application. Naturally, FireFox being more robust, suffers significantly less corruption than Safari. However, the fa-rm (issue discovered) page that intitally worked so well in FireFox, now suffers corruption that is identical to the Safari display (read my lips, "not standard").

Note that the page contains a background image that is unpaid (free for public), a FontAwesome icon - some demonstration pages (linked above) remove display of this background. Also note that any links over fontawesome.com background do not work, nor can other content on top of fontawesome.com content be selected for copy, perhaps due to service asset protection and security features. Also note that when inline page images are positioned to cover the fa-leaf background, the cover images adopt page transparency, with background visible 'under' image (safari full transparency, FireFox partial transparency). To facilitate examination of link family display relationships in noted browsers, fa-leaf will only animate when direct hover of the visible object-box occurs. In other applications, the full-size background provides content protection for entire page, where background opacity is styled as 0.01 (emial, web documents, etc.). This background is a significant modulator of link family behavior, so exhaustive testing may befit frm inclusion of FontAwesome, or a similar CDN network service security system.

2019-Jun-26 an additional problem is identified with unexpected line-wrap around hyphens inside of the link element's tags. Incidental, page has additional problem, displaying content text flow around hyphen glyph, in Safari local. Here are the initial desktop and online link family general observations. Initial observations have changed significantly, as Apple (and perhaps MDN) consider standards.

Code looks good.

Firefox looks good.

Safari has a minor issue, as white-space:nowrap is not required for the link-family demonstration, but is clearly required to avoid link line-breaks.

Now we can proceeed to review more carefully, what a link family is, and how we choose to deploy link family technologies.

A quick selection from W3 Schools.com...

Sidenav buttons, similar to this page
Navigation bars
Topnav, for small jobs
Subnav, expanding horizons
Mega menu, full width
Full window with screen opacity
More sidenav
Data warehousing

Tutorial samples from How To page (menu on left)
Give it a try
Sticky navbar
Full window example

If you are a little bit clever, go ahead and adapt the above resources, any way you like!