Base Web Files |
Welcome. This is meant to describe some of the base files that this site is probably likely to reference on pages from multiple distinct sections of the web page.
Below a description of the various components, some sample HTML for these base technologies is available.
Sections of the JavaScript tree can be expanded (by clicking on plus signs) and collapsed (by clicking on minus signs). The following controls are JavaScript links to help web browsers collapse and/or expand the definition list tree to specific specified amounts:
The LinkNav (with LinkNav Fix) JavaScript may cause a widget to appear in the upper-right corner.
If the DT Tag JavaScript is being used, the “definitions” in lists may be collapsed, allowing easier navigation from one part of a tree outline to a different, unrelated section. The page has “partial expansion” controls that can be used, and which are used by default if the browser is not expecting to visit an anchor when the page loads. With this default partial expansion, specific pre-selected page sections of likely interest open up for quicker access, while other sections remain collapsed for quicker navigation to other sections. For example, the “instructions” section is short (when it is not further expanded) and so it is expanded one level by default, so its contents can easily be viewed. However, the DT Tag: Status section, which is more verbose, is collapsed so that it doesn't take up a lot of viewing area for people who are more interested in skipping over that section and reading about other JavaScript files on this page.
Expanding an ancestor element doesn't result in the browser losing track of which descendents were previously visible before any earlier collapse of the ancestor.
The example sub-lists have been commented out of this page. Later sections of this page, such as the example code, service as a real-life example of deeply nested definition lists and so they can be used for testing. (The example code was, in fact, needlessly broken up into multiple sections for the clear purpose of being more deeply nested so it could serve as an example of a deeply nested definition list.)
If an anchor tag's “NAME” attribute is specified in the web browser's address bar (e.g. file://filename.htm#shortcut), it would be ideal if the definition list containing that tag, and all parents, were automatically expanded so the referenced anchor starts out being visible. To have the definition list containing that named anchor be the only definition list that gets special treatment (being expanded when it is normally collapsed) would involve the code needing to figure out what definition list the specified named anchor is in. To implement something more sensible more quickly, code was added to make it so that any named anchor causes all definition lists to be expanded. Specifying an anchor (such as #start) will lead to web browsers putting to focus at the top of the page if the specified named anchor does not exist or if it is at the top of the page, and will cause the lists to be expanded. (Specifying just a # may cause the browser to put the focus on the page but to not have the referenced anchor be noticable via the Javascript check, and not cause the lists to be expanded.)
This was made to be intentionally easy. Basically, the requirements on the webmaster are the fewest possible that perform the technical necessities:
The following loads DTTag and LinkNav. (Please respect licensing information, and customize the page references such as properly identifying the Copyright page.)
|
</BODY></HTML>
Using window.onload will cause the code to be loaded only after the entire body is loaded. If the web browser continues to load the page indefinitely, which may happen if there is a missing file (with a file:// reference), the window.onload may not run. This can likely to worked around by creating a more standard function and then placing an additional JavaScript tag when all the other content is loaded, so just before the </BODY> and </HTML> tags.
Having web pages run the initialization script can be a bit distracting if content, which the user is trying to view, collapses out of view (even if only temporarily before it is re-expanded) or is scrolled out of view due to other content that is collapsing.
Different web browsers may process the definition lists at different speeds. Therefore, testing the experience in one web browser (like Firefox 2) may make things seem much better than how the content ends up getting displayed in another web browser (such as MS IE 7). Having large definition lists (with dozens and dozens of items) may take well over ten and perhaps even thirty seconds even if the HTML file is loaded quickly. Any use of the hideem() function can therefore be quite distracting.
It is possible that some of this may be improved with different code, such as if initem() becomes enhanced to try to be more graceful with a BODY that isn't yet done loading. However, this does describe some potential experience with the current state of things.
The changeem() function (and any other function that simply calls changeem() and exits without checking changeem()) might not be complete when the function exits. This is intentionally done to improve browser responsiveness (by breaking changeem() up into pieces) and because JavaScript's while command should not wait on the results of a setTimeout (or else the thread with the while command may hog up the CPU time allocated to the JavaScript processing, and not allow the other code which setTimeout runs to ever be able to run and complete.)
After calling changeem(), do not expect that the function is compete until isChangeEmDone() indicates that it is complete. For example, calling changeem() multiple times could cause an earlier, more elaborate changeem() process (perhaps one affecting more list elements) to complete after a later, simpler call. The end result of what is showing and what is not showing may be something other than desired.
For now, all parents must be expanded in order for a child to be visibly expanded when the page begins. The code could be modified to automatically expand any ancenstors whenever a child is expanded. However, unless that was made into an option, that would limit possibilities. For example, on this page, expanding the “Example code” will cause some sections, like the Overview, to be expanded while the larger section of code remains collapsed. This may or may not have really good uses, but as this page shows, the capability for such hidden sub-expansions does exist.
A wrapper function expnamed() has been made. See example of partexp() in this HTML file for an example of how to use expnamed().
Although manually naming DT elements is not necessary just to implement basic expandability, manually naming DT elements is highly recommended as an easy to way reference what gets expanded and what doesn't. If the tags are not manually named, they can be expanded partially if they are properly referenced, but referencing the tags may be more difficult if they aren't given manually-assigned names.
Thoughts/plans:
Brian Lalonde's LinkNav file uses both JavaScript and CSS.
LinkNav causes the upper-right corner to show a widget with hyperlinks allowing easy access to web pages that are specified by some standard HTML code that some popular browsers do not support. However, the <LINK> tag is considered standard HTML and other web browsers do support the tag. This allows for an easy way for a web master to provide benefit for supporting browsers while making the efforts usable by those using other browsers that support JavaScript but provide very low (and quite possibly no) support for this tag.
Redistribution is permitted according to the license specified in the files.
[#lnknavfx]: The lnknavfx.js adds support for browsers that don't support :hover (such as MS IE 5.5) and shows how one can remove a reference to the linknav download site (which is done not to resist giving credit to the site, but rather just to make the widget smaller). No changes are needed to be made to the linknav.js or linknav.css file: just include this file as well. This LnkNavFx (LinkNav Fix) code is licensed for distribution with the same permissions granted by the LinkNav's license. (This is a simple script, and ideally the license would be this simple three word license: “No rights reserved.” However, LinkNav's license's “Share Alike” clause is more restrictive.)
Possible additions/changes that may be made: Add/document support for creating a custom footer, supporting title elements of LINK tags (as used by FGA: Providing "split horizon" DNS service as an example).
Coming... I wouldn't say coming soon, because these might take some time before it is launched.
Controls over embedded files, notably multimedia files such as music and movies, is something that TOOGAM is very likely to include on this site at some point in time.
Such supporting code does exist: some code had been developed to support multiple plug-ins (such as QuickTime and Windows Media Player) and browsers (including Microsoft Internet Explorer and Netscape Navigator), although the code was developed before Firefox. Making sure the code works okay with newer browsers is likely to be done before public release. Also, testing with mozplugger and Timidity is likely to be done as well.
The code used cookies to save preferences, so users could save whether they preferred one codec over another. (There may be various reasons for this: speed issues, cosmetics, or even how the output is played, which can be dramatically different quality with MIDI files.) There were plans (although this might not have been implemented yet) to allow the user to pick a task, such as picking a background music, and having it play uninterrupted as the user went from one web page to another. (This was done with an additional window, such as a legitimate and useful and non-intrusive use of a pop-under that would politely close when the main web page was left. This might not commonly work as well now that browsers have become more aggresive against less user-favorable usage of pop-up technologies.)
Another cool feature that was working was SAPI: having web pages speak to users. This began to work less well as unsigned ActiveX controls became less runnable, but there may be some potential in having this be released yet.
See LinkNav in the JavaScript section.
This is not included here for the intentions of recommending that others use it (in its current state). Instead, the reason this file is being mentioned is simply so that another file, that is used by this web page, is being publicly documented and made available.
This may be updated quite a bit before being recommended for widespread use. Counting on its contents is currently not a recommended practice.
This was initially named the “CSS for Operating System Installer Guide”. This was named after a guide that TOOGAM started working on. However, that guide has since evolved into a website called Cyber Pillar.
Start with something like this:
|
Be sure to also have a matching
</BODY></HTML>
Customize as desired:
<DL>
tags are on a single
page. Otherwise, the act of creating bars on the left (which is called
"tabularizing", a term made by the creator of the code that does that) might be
rather slow. By the end of the year 2016, that was still typically true.
(Presumably that will eventually be sped up with newer hardware and/or
software.)
This can be seen on many pages on the Cyberpillar.com website. To rectify this,
Cyberpillar.com would not "tabularize" a page that has more than a certain
number of tags (or certain tags). However, Cyberpillar.com would show a
“Tabularize” hyperlink in the right frame, so users could choose
to Tabularize on their own.