How should MyersDaily be written: Myers Daily, MyersDaily, or Myersdaily? Myers Daily as two words works better in printed material, page titles, etc., and generally is nicer. However, Myers Daily could sound like a newspaper, rather than a general service organization (not excluding newspapers, of course).
MyersDaily fits well in terms of a single, one-word name, and Myersdaily works as a word. For domain and identification purposes, myersdaily is case-insensitive, but published references to MyersDaily should use one of the first two versions, whichever is fits your taste.
Perhaps rather than using only one, a combination of all might be best. You could refer to services of MyersDaily as "A Myers Daily such-and-such," the organization itself simply as MyersDaily, and use Myersdaily as a noun form (e.g. "Go be a Myersdaily!").
In summary, MyersDaily refers to the organization, Myers Daily is used as an adjectival form, and Myersdaily is used as a generic proper noun.
In order to simplify management at the website, a fairly strict inheritance rule is used: A document can only reference materials which are either (a) contained within its directory, or (b) able to reference the document itself.
The only exception to this rule is for general-purpose library files, which must be contained within a directory set aside for such a purpose. An example would be to have a JavaScript code library contained in a folder /js_lib, and then having all the code be available throughout your website despite the fact that referring to /js_lib from /other/foo would violate the inheritance rule.
Each directory should contain a file (normally index.html) with an overview of its content, preferably along with a complete list of available resources within.
Only complete conformance to published standards is acceptable. However, an indication of this on any page is extraneous and not desirable. Please report any errors you find.
Keeping extra code out is important, too. Some aspects of the existing standards seem to impose inefficiencies. Hopefully the requirements will become more conservative.
Abiding by the Keep it Simple principle is crucial in order to maintain order. Except for dynamically generated content, automated source production is avoided. Such automations as source formatting are acceptable, however. A rule of thumb for software use is, "If you don't understand it, don't use it."
Page structures are normally defined by headings (h1-h6), with no following colons. First word only capitalization is used on sub-headings, and standard title capitalization is used for title headings. Block-level text is laid out in paragraphs. List items are followed by periods.
Documentation is an important part of management. It is helpful to form a standard way of supplying and finding documentation. Presently the proposal is to divide the task into two parts: (1) File-wise help, (a) internal, comments (as provided by the file capability) and (b) [filename].man; (2) System-wide help, (a) references within file-wise help to Internet or published documentation and (b) a standard "man" dir with entries keyed to the related files and able to be looked up through a standard "help" mechanism.
It may be convenient to use a widely-applicable suite of tools--like the standard "toolbox," only applied to a Web server--for a host of purposes. It would help if there were a method of distinguishing between these type of functions and the normal forms of canonical addressing. Such a technique could be described as a pragma, and would in practice be similar to type determination.
To execute this task, one might form a "request basis scheme." In the context of Web addresses, such a scheme could be incorported rather simply. All that would be necessary is the definition of type associations--either by directory name or by file-name--and their corresponding map to the server's program space.
For example, one could define an invisible redirection which would direct requests to any "/(*)/-x-(*)" location through a program found in $PATH/$2. A form posted to -x-mail would be processed by /cgi-bin/mail, if "cgi-bin" was in the $PATH and it contained an appropriate "mail" executable. Similarly, an "I" directive ["/(*)/-i-(*).(*)"] could indicate an inclusion from predefined library locations. The third parentheses could help determine which library to search--e.g. a CSS library for -i-STYLE.CSS. This could be tremendously useful, even with things such as style sheets and graphics. Templates would not have to be maintained in several locations if they were able to retain--based on their directory path--a kind of identity, by which appropriate differences would be accomodated through some mechanism of dynamic inclusion.
It is wrong for the same abstract entity to be represented by two indistinguishable names. There should only be one address per resource, whether or not the resource is multi-sourced. It is highly recommendable then to follow the de facto practice of referencing material for a WWW domain at http://www.your.domain/whatever. Hopefully this will prevent the useless replication of data via domain pointing. Never should a domain be used to repeat content that is in fact canonically addressed by another name. Either a site should be mirrored--providing multiple copies of the same material--or it should be multi-homed--more than one server identically responding to the requests at the same address.
The resource of a directory, i.e. /dir/, (as opposed to that of a file) is obligated to accurately return information according to the context of a directory of contained materials, or what ought to be contained.
"Oh, Johnny, you've forgotten your password!"
"Mommy, whatever did I need one for?"
"You didn't, but after all, doesn't every machine have its key?"
"These days," people are paranoic about security. Where passwords matter--and there are places they do--choosing one is your own responsiblity, and the security structure is required to protect you as far as possible within the limitations of that password. In the case that a "password is necessary" but you don't want or don't need one, then you have only to follow certian simple guidelines. Take these merely as conventions, nothing more.
Ideally, you should circumvent a useless password by using the "blank" password. Otherwise, where a certain minimum size is required, for example, you should be able to use the very cute substitute: a mere repetition of your login name. If even this doesn't work (blast those idiotic "good intentions" of security folks!), there are several other usual workarounds.
In the case of anonymous logins, a terse way of saying "take it or leave it" is to type nothing. Unforunately, many FTP servers (for example) make the ridiculous demand that you enter your e-mail address. You can enter user@host or user@host.com (in the worst case, make something up, like say, nobody@noplace.not) in order to get around the nasty beast.
In general it is good to imagine that your content is being viewed in color and on a screen. If a document is printed or read aloud, these beautifications are not so important, and in fact do often impair the usefulness of material, especially text, certainly the most critical element of electronic media. Images are a separate question, and deserve their own issue. For the purposes of CSS, they can be ignored entirely, as the image itself is removed into an entirely separate sphere and if CSS were to affect its display it would still be distinct from that of the main.
For these reasons it ought to be that every style sheet related to display should be specified as rel="screen", thereby preventing any inappropriate application of its rules.
11-29-03 new 9-15-03. Global variables don't use 'var'. It's more illegal to declare a variable twice, which can easily happen if 'var' is used. No variable name should ever be used which clashes with a variable in a higher scope, thus alleviating any ambiguity between "window.alert" and a "var alert," for example. Only truly localized variables [such as: function x() { var r }] should share names between other truly localized variables--i.e., two algorithms may both use "i," "x," etc.
Semi-colons should always be used where joining a previous line to the next will result in invalid code. Saying "for (; true;) { break }" is not wrong, because the brace after the break statement explicitly indicates the end of the expression.
10-12-03. Making it easier. I used to think images should clearly say alt="image: Joseph Myers," for example. I hated brackets. I've changed--the "image" is indicated from the image tag, and I presume that this is explained in the page's context. alt="Joseph Myers" is OK, and I guess it's better. Also, "Sunday, October 12, 2003," should be pronounced, "Sunday, October 12th, 2003" It is not English to say, "October Twelve, 2003." (for an example).
10-30-03. Vulgar words or expressions. It is OK to use a word for what it means. Doing so is better, for example, than using "image" in psychology when "imagine" is the perfectly good word. That a word is "vulgar" is not that it is bad. In fact, the production of vulgar words comes from prissily not using the plain, common word when it is right. It is more arrogant not to use vulgar words. Cursing, however, is off--or using vulgar words for what they do not mean. The word for its own purpose is decent; to hurt someone it is not. If we use vulgar words, they aren't. If we misuse them, they are. I have a good right, a holy right, a pure right, to say a word, etc. In fact, you decide what you will use, and there is nothing wrong. If you do not decide, there is something wrong. The point is that you indivdually do it. All words are holy. Mouths that speak and pens that write are either natural or foul, and produce the good or evil of their own words.
The main thing is not to make a cursing deal out of saying that you will tolerate a vulgar word. How can you fight evil with itself?