What is the style rule on HTML and inline CSS?

Question

Here's a proposed style rule: HTML and inline CSS is not recommended unless it's specifically recommended.

The page explaining it: http://www.wikitree.com/wiki/HTML_and_Inline_CSS

The way the rule is phrased here is almost tautological. But maybe there are points that need to be considered before the rule is finalized.

Before commenting, please be sure you read HTML and Inline CSS. Is something about it unclear?

Comments

This new page is very well written.  The tautology is appreciated in the name of clarity.

Minor change thoughts:

• In the Wiki Mark-Up vs. HTML section, maybe the last sentence could say "For a list of the items that are considered to be Wiki Mark-Up, please see Editing Tips." 
• In the HTML Tags and Inline CSS are Non-Standard section, add "is" to this sentence, " It is not officially recommended."

 

---

I agree with wiki markups, but anyone here ever done a major profile?. I recommend you do before you make rules that effect others

---

I'm hoping for a more clearly documented and easily accessible list of the existing accepted / supported / recommended formatting tools first. I think that is what this topic is about. The official list of recommended items are strewn amongst many pages, which serve their own purpose. Before we can make requests about future rules, we need to know what is currently supported, yes?

---

Spot on

---

This is now "official": http://www.wikitree.com/wiki/HTML_and_Inline_CSS

I'm still working on http://www.wikitree.com/wiki/Recommended_Tags and related pages.

---

A thought just came to me... while we have explicitly said that more creative expression (in terms of using HTML/CSS) is allowed on free-space profiles and Private profiles we have not specifically mentioned category, template, and help pages.

I will leave it up to others to suggest what is correct for category and help pages but I suggest that to make things crystal clear (even though editing pages in the template namespace is restricted to leaders anyway) we add a specific exemption for {{Template:}} pages; since they are largely used for presentation rather than content, and are somewhat 'centrally managed' anyways, etc.

HTML and CSS are required for some parts of the 'display' templates - notably borders and backgrounds, other layout elements, and using wikitables rather than html tables inside templates (alongside all the other braces and pipes/vertical bars) can make creation and maintenance an absolute nightmare.

Answer 1

I support fully Wiki Markups, after 1 week of trial and using them, there is practicaly no difference and its not going to break, Being creative is a challenge but not impossible but the thing is everything must have standards.. Plus there easier to use ~ Eric

Answer 2

I know a little bit about HTML, but mostly use an HTML text editor. I know nothing about CSS or Wiki Mark-up. I tried creating a Wiki Mark-up table, did something wrong and had dismal results so went back to HTML because of familiarity. For those of us coming from this degree of inexperience, how are we to know which is which? I use the <ref></ref> tags a lot, but I don't know what that language is. It looks like HTML to me. Most of my HTML use is making tables for census records. I know where some of those tables are, but I don't know where all of them are. Is there a simple way to find them system wide so they can be changed?

Also, if others are like me and see something they're not familiar with so delete it, what if it is Wiki Mark-up so they've deleted something they weren't supposed to?

Comments

I think everybody knows me, I have used HTML extensively, If i was to chose between HTML and Wiki Markups, i would choose Wiki Markups it is much easier to use and much more fairer on those who edit after me

---

I'm sure it will be fine. I just have to learn how to use it effectively. :)

Answer 3

Since the tags for adding footnotes and listing source information in the Sources section are no longer recommended, what is the new recommended way of handling this?

Comments

Tags for sources are recomended and should be used, they come under styles and standards. think we are talking <ref></ref> tags

---

Exactly, Eric.

<ref> and <references /> look like HTML. They're actually wiki mark-up. I realize that's confusing. But you don't need to know the difference.

You just need to know that <ref> and <references /> are specifically recommended on various help pages.

---

Well, I guess I have been using some wiki mark-up without realizing it. Now if I can just learn how to do tables so they work. Practice, practice.

---

Those tags are not mentioned on the "wiki markup" page linked from the new rule.  I actually clicked that link to see exactly what is encompassed within wiki markup.

Now y'all are saying that even though the <ref> tag is not on the page that the rule says is the complete set of "recommended" styles, it is still "recommended", I have to wonder if there is anything else that is not on the linked page that is also "recommended".

Chris, I know that you are busier than a one-armed paper hanger, but hope you can provide a CLEAR and COMPLETE set of EVERYTHING that is included in the "recommended" set of enhancement tweaks.  Lacking that, I (and I expect everyone else) have no way of knowing what I can and cannot do.

---

Gaile, please read the opening text of Editing Tips.  About the third line down is the following:

Here are tips on doing the wikitext formatting by hand. Also see the separate pages on adding links, sources, and footnotes.

 

---

Editing Tils???

---

She meant Editing Tips. There's a link there to Footnotes.

---

Thank you Jillaine, but I STILL have a problem with all these things being in so many different places making it impossible to know EXACTLY what included in the "recommended" things we can do.

I really need to see a single page that includes the COMPLETE list of ALL "recommended" things we can do, instead of a scavenger hunt going to one page, then to one or more pages linked from it, and maybe more linked from each of those and trying to guess which things on each page are included in the "recommended" list.

---

I concur that would be good; especially now.

---

Please see Heilberg-81.  I had an html table to display source data and just experimented using wiki markup to create the same table below it for comparison.  It is painfully obvious that the wiki markup does NOT produce anything close to the html table!  In adition to not having a visually defined space (a box with outline and gray background), the spacing is badly fouled.  There are blank lines that do not belong there!

If anyone knows ways to format the wiki markup table better, please let me know.

THANX

---

Gaile. Thank you! You helped me create a successful table using wiki mark-up. I copied yours, removed the content and added the columns I needed, filled in my information and this time it worked. :) I don't know why I had such a difficult time before.

While I was doing that, I noticed a couple of inconsistencies in your formatting which probably accounted for the extra spacing. I removed them for my own chart and it came out looking fine. http://www.wikitree.com/wiki/Space:Cox_Families_of_Pendleton_District%2C_South_Carolina

True, there aren't defined lines or a different background color, but if there's no way to do that, the important thing is, the content is there and is understandable to others reviewing the material. Thanks again. I'm all smiles.

---

We could try to make sure that Editing Tips clearly links to all the recommended formatting options. And/or have a category for all help pages related to formatting.

I don't think we have pages with instructions on creating tables. We could probably just link to one on Wikipedia. Maybe if their instructions aren't clear someone could draft a rewrite?

I know we need to add a page about inline images. Part of the hold-up is that I'm not totally confident that won't be changing soon, e.g. with a few new classes in the main stylesheet.

---

My mistake! http://www.wikitree.com/wiki/Editing_Tips#Tables

---

I attempted to draft an all-in-one editing tips page. Still needs some work:

http://www.wikitree.com/wiki/Editing_Tips2

---

Are the links following (from the "editing tips" page) considered to be usable wiki markup here at wiki tree. I know eventually I'm going to want to center some text or something similar. That's on one of the pages listed, but not on the WikiTree page. Or maybe I could ask: is the Wikipedia markup the same as the WikiTree Markup.?

• Wikipedia Wiki Markup
• MediaWiki
• Confluence

---

Debby, I don't have a clue what I did that helped you, but I'm glad you were able to use it!

I'm not sure what inconsistencies you found - I have stared so hard at that code that I think my eyes have become fixated.  The only thing I see that I think you might be referring to is that on a couple of rows I deliberately put an extra return character at the start.  That was for places where I wanted to skip a line.  There are a couple of other places where I did not want to skip a line and did not start with a return character but a line got skipped.  My goal was to exactly re-create my original table.

If you saw something there other than the 2 places I used the extra return character (those finally did the job - I had first tried to have a blank row, but that didn't do anything) please let me know so that I can fix it.

THANX,
Gaile

---

Anne, I think the thing I found most frustrating when doing that experimental table conversion was the inability to control justification.  I saw the link to Wikipedia Wiki Markup after I had done the table, but I also have a vague recollection of having seen something somewhere in the labyrinth of WikiTree help pages that said we don't support all wiki markup - only what's documented on our page.

I could not more fully agree that we desperately need a single place where everything that is officially recommended is listed AND explained.

I saw something in this thread last night (fleetingly) about "average" users.  I don't know if I'm average, above, or below ... nor do I care.  People who write profiles ALL need to have access to whatever enhancement tools are available to us.  We need to not just throw an example of code on the left and an illustration of the result on the right to show people how to do it.  We alsoneed an explanation of the role of the syntax elements so that it does not look like a bunch of hocus pocus to a non-geek who would like to understand what they're doing.  If someone wants, I'll put my money where my mouth is and write a sample.

---

Bless you Jillaine for starting the Editing Tips2 page!!  That's exactly the kind of quick reference sheet I've been looking for.  I have created a notepad version for myself so I can copy/paste code snippets, but having an official page of "approved" usage is invaluable!

---

It's incomplete and has some formatting issues. I'd reorganize it a bit. I'm not sure it gets at Gaile's request for an explanation of the syntax items. I will always argue for less than more.

---

I agree.  I think there are probably a few ways to make it visually cleaner and maybe structuraly a little more organized.  Grouping the types of syntax items would be good.  

When you say "less than more" do you mean simplicity in explanation? Or fewer items?

I'm thinking something that works like this:
http://en.wikipedia.org/wiki/Help:Cheatsheet

---

Wow - I missed the last few of these while I was writing a way too long answer to the "is it clear" part of Chris' original question.

Lundie and Jillaine, you are both saying - and in so much simpler, shorter (and therefore much better) words - most of what I was trying to say in that absurdly long discourse.  My husband thinks I write like Charles Dickens and often asks if I get paid by the word.

Lundie, I want to see the kind of more user friendly and structured presentation you're suggesting.  My comment suggested a "packet" for each "recommended" element.

Jillaine, I offered to prepare a draft of the "packets" if someone gives me the list of elements that are "recommended", but others will definitely need to go behind me to impose your "less is more" (which I am 100% with you on) on what I produce, as well as to make sure that my draft is technically correct and complete..

---

These are most of the "standard elements" I could think of from the top of my head divided by symbols. (I have used 5 underscores _____ where there is variable text)

Angle Brackets
<nowiki>_____</nowiki>
<includeonly>_____</includeonly>
<onlyinclude>_____</onlyinclude>
<noinclude>_____</noinclude>
<ref>_____</ref>
<references /> used once per page after all uses of <ref>_____</ref>
<br />

Apostrophes
''_____'' - italic uses 2
'''_____''' - bold uses 3
'''''_____''''' - bold and italic uses 5

Asterix
* bulleted list level 1
** bulleted list level 2
*** bulleted list level 3

...etc

Bang/Exclamation Mark
! used in a wikitable to indicate column or row headings

Braces/Curly Brackets
{{#_____:|_____}} call parser functions
{{_____|_____}} call template or magic word
{{Space:_____|_____}} call template code in freespace page
{{Category:_____|_____}} call template code in a category page
{{{_____|_____}}} template parameters

Brackets/Square Brackets
[[_____|_____]] links to Wikitree profiles
[[Space:_____|_____]] links to Wikitree freespace pages

[[Image:_____|_____]] displays an image

[[Project:_____|_____]] links to Wikitree project pages
[[Category:_____|_____]] categorize a page
[[:Category:_____|_____]] link to Wikitree category
[[Wikipedia:_____|_____]] link to Wikipedia article
[_____  _____] - Links to anything else

Colons
:_____ indent (must be first character on line)
::_____ double indent
:::_____ triple indent
...etc

Equal Signs
=_____= level 1 heading
==_____== level 2 heading
===_____=== level 3 heading
...etc

Hash/Number/Pound Sign
#_____ numbered list level 1
##_____ numbered list level 2
###_____ numbered list level 3

Hyphen/Minus Sign
---- horizontal line

Pipe/horizontal Bar
| Used in wikitables to mark new cells.
Also used as a divider between separate elements enclosed in brackets and/or braces.
May appear multiple times within 'an element'. example: [[Image:picture-1.jpg|50px|First Picture]]
Will sometimes be used together two or more times in any of the uses named above.

Tildes
~~~ user id
~~~~ user id, time, date
~~~~~ time, date

Mixed symbols
Asterisks, Hash signs, and Colons together in various orders to make "mixed lists"
{| start of table
|+ table caption
|- new table row
|} end of table

Miscellaneous
&#61; sometimes used to replace equals signs in hyperlinks
&lt; sometimes used to replace left angle bracket to prevent <____> from being processed as a tag

Other special characters will usually use a format similar to the above, namely &#_____;

---

WOW!!! Foirmidable list - I did not realize we have that much available in wiki markup.  THANX OODLES, Rob!!!!!!!

Just to be absolutely sure on this ... is ALL that included in the "recommended" things?

I am so - most pleasantly, for a change - shocked at the extent of this.  My reaction alone further convinces me that we really need to have all this in 1 place, so everybody will be able to see everything that is in their tool box when they go to work on profiles.

Rob has already listed it all in nicely organized groups - now all that is needed is to set up the "packet" format for each one and fill in all the info and we will have a fabulous resource for EVERYONE - it will serve the needs of people who are mystified and want to do no harm when editing, it will give people who are used to using code to enhance profiles the knowledge of exactly what they can use, and it will also give sufficient explanation in a user friendly way for people who would like to learn how to use code when they work on profiles.

Now I'm really getting excited about this, but first I'm going to see if there is any more I can do to improve the wiki table I made as an illustration of what will be lost by using only "recommended" tags.

---

Yes - this is great!  The section that Rob is calling "Angle Brackets" is the area that blurs the lines for me between HTML and Wiki Markup.  We want to make sure that whatever is on this page is labeled "officially recommended".

Jillaine and Gaile - I also offer my assistance wherever needed to help craft this reference page.   

---

I'm going to do 2 things right now this very minute!

1. Design a template for the info packet on a markup item.  This will be an html page that I will host on my server ... I suppose I could make a free space page here with it, but don't want to get involved with wiki markup for the display - those to whom it is natural can deal with that - all I want to do is show a sample of how I'm suggesting the page should look and it's much easier for me to do that in my "native" language of html!

2. Go back to Heilberg-81, where I put a sample table using only the wiki markup that was specifically mentioned on the page that started this thread and see if there's anything I can do to improve it with stuff in this complete set of tags.

By the way, I just had to put about a half hour into putting that table back to what I originally had there because some well intentioned member decided to improve my sample wiki tag table by putting all kinds of very nice styles in it to make it look EXACTLY like my original html table above it.  It certainly was an improvement, but that's not what I really wanted there at this point.  I sent her a private message to thank her for her efforts and explain why I was going to undo them all.  I also beefed up the note on the page about the wiki table asking people not to edit it!

Lundie - that's the best offer I've had in years ... except that I'm not part of any committee that i know of, but you made me think it would be great if Rob, Jillaine, you, and I can become one to make this happen!!!!!

---

I just put the start of my idea on my web server so y'all can see what I tried to describe.  It is at:   http://www.gcube.us/gedcom/wikimarkup.html

Of course, it would start with a table of contents.  Each section would have separate subsections for each element.  Each element's subsection would be formatted identically.  The last section, labeled "when to use it" for the tags, would be labeled "how it works" or "explanation" or something like that for other elements, as appropriate, and would essentially constitute a sort of "wiki markup 101".

---

Gaile,

I believe anything on my above list that is not already classified as "recommended" (some under the caveat that all wiki-text that is not specifically recommended against is standard) or is something that is a technical necessity in at least specific circumstances (such as the ASCII substitutes for certain characters) - with that said a number of those codes are what we have been referring to as 'template code' and ***should*** be encountered very rarely on profiles.

My initial thoughts on your suggestion: I think the way code is currently documented on different pages (topically) has advantages over having a 'master code page' - someone who wants to add a table can go to a page that deals exclusively with tables  - someone who wants to add a font or layout effect can look at a page that deals with those things - yet another page explains how to create a template. This makes it easy for people to find the code they need to achieve a specific thing they want to do. It also encourages people to look at ideas and principles (for example: what information should a footnote include as a minimum) rather than just "yup there's a <ref> tag". This structure focuses on "how do I...?"

Further, the pages for over 90% of the codes I listed already exist, although like most things there is room for improvement on many of them. The following pages cover most of the code I gave in varying extent: editing tips more help,(which is an expanded version of formatting), adding links, footnotes, creating a template, using categories, parser functions also have a page.

The list I made in the previous post, inspired by Lundie's comments, tries to work from the opposite perspective of someone editing a profile, finding some unfamiliar code and asking "what is this..?" On it's own it is a quick reference to help editors recognize what is "recommended" code (and anything that is not recommended is not recommended :) ). If someone wants to find out what a piece of code does in detail, and/or how to use/edit the code they can follow a link to the topical help page to learn more.

I do however think your idea of 'standardizing' the presentation of explanations of code elements, whether on one page or across many, is an important concept. Using a familiar layout makes it easier for people to 'digest' a page's content. There are a few codes that take a bit more work to setup your proposed "what the page looks like" - the inclusion tags for example. For inclusion tags you need to show 'what you enter" on two different pages, and what the resulting display on each of the pages will be. To be truly clear you would also need to give examples of how they nest within one another since it can produce very different (and possibly confounding) results.

Going off on a tangent: things not currently (AFAIK) on the recommended list, but that I feel should be:

1. <blockquote> tags - aside from the fact they can be re-styled if needed through the sites stylesheet, they also clearly mark out for editors, in the edit page, something that should not have it's spelling corrected or wording changed unless it is actually found to be a misquote.

2. Some way of changing font colour within a limited palette (possibly an extension to wikitext?) one each of dark red/ green/ blue should be sufficient to allow comments and annotations to stand out from the 'body' of text.

---

Rob,

That's a huge chunk of great info and ideas,

I am strongly in favor of your thought on allowing for some flexibility in font colors, as well as possibly a few other font and alignment attributes.  I think the best way to do that while still retaining global control would be to create a set of classes in the master css file.  This would also eliminate a need to expand the wikitext.

I see your point about there being benefit to having code documented on different pages, but I'm still going to argue in favor of a single location for it, however it's late and I'm tired so to be able to think it out clearly and do it justice it will have to wait until morning.

I really do love the way this is coming along, though ... g'nite y'all!

.

---

I'm with Rob on organizing by function/purpose for the Help pages for the reasons he stated. That said, we could have a page linked to from Editing Tips page that organizes them by character types (such as he drafted) as a form of "index" that someone wants to refer to quickly to understand a code they stumble across.

Rob, why do you prefer <blockquote> (HTML) over ":" (wiki code)?

---

As I said last night, I see Rob's point (and Jillaine's support for it) - and it's a very good one - about having separate pages for the "how to's" on different kinds of enhancements.  That said, my personal experience with it has been very frustrating.  Whenever I try to find things, I feel like I'm on a scavenger hunt and the process of finding what I'm looking for seems extremely convoluted and very time consuming.  I NEVER realized that all the code help listed in Rob's post above was here or I would not have requested a list of all of it!

I think the organization by function/purpose is of prime importance, but I do not agree that separate help pages will accomplish it as well as a single page that is organized by function/purpose and starts with a carefully constructed table of contents that displays the hierarchy of functional groups with code items listed under the approprate groups, with all listed items linking immediately to their "information packets".  I think it would be much easier (especially for folks who might not even know what to call the things they're looking for) to look at that table of contents (where they are one click away from the specific information they need) than to go through the help index of ALL the different kinds of help pages for EVERYTHING on WikiTree and trying to guess the name of what might be what they're looking for.

The way I'm seeing it, this page itself is the most efficient way to organize it all.  The name of this page needs to be very carefully selected to ensure that *IT* appears in the help index in a way that very clearly identifies it as the place where everything in the category of "profile enhancement tools" is found.

Of the 4 parts to the "item packet" that I'm recommending, the last part can be used for a variety of purposes - it can be a code tutorial, explaining why/how the code item works the way it does and/or it can include advice about the situations for which it is intended to be used and/or it can provide information about - for example - in the case of <ref> tags, the recommendations/requirements/whatever for what kinds of sources to use to support what kinds of statements in the profile.

About the transclusion types and examples - yes, I realize that they need clearer and more detailed explanations/examples than are now there.

---

A few of my reasons for preferring <blockquote> over an indent (:)

1) When making edits, <blockquote> is more noticeable than a colon; this means editors are less likely to mistakenly edit a direct quote thinking it is just another paragraph.

2) content in <blockquote> stands out from content that is simply indented because <blockquote> is, by default, indented about half-way between a single indent and a double indent.

3) If desired, styles can be applied through the sites stylesheet to make blockquotes further stand out from other body text on all profiles, while ensuring they remain accessible.A few different possibilities: a thin solid black left border along the entire quote would be used as a very prominent style choice; a background of lightyellow with some padding is a very subtle choice; right indent is also an option, as is applying a different typeface. N.B. typeface changes can be the most prone to problems on the user end (affected by installed fonts, specific web-browser, etc.). Changing the generic family of fonts (say from sans-serif to serif) would be relatively safe.

All this is not saying we need to give block quotes a different style than non-quotes - but using <blockquote> opens the door for that conversation.

4) In practice, to make a quote that is indented using (:) stand apart from any other paragraph that is indented the same amount (often list items) people might use italics on the entire quote. While italics were used for block quotations in early printed works, that approach started getting phased out about the 17th century and is today largely not considered a recommended use of italics, despite being wildly popular with people who create internet memes and motivational posters. Also, a block of italics rather than the occasional word can be hard to read on some screens and/or for some users.

Some references:

https://owl.english.purdue.edu/owl/resource/566/01/

http://grammar.yourdictionary.com/punctuation/when/when-to-italicize.html

http://www.writingservices.eu/italics-when-use-them.htm

http://www.quickanddirtytips.com/education/grammar/how-to-use-italics

https://owl.english.purdue.edu/owl/resource/566/01/

---

Jillaine, you said: 

That said, we could have a page linked to from Editing Tips page that organizes them by character types (such as he drafted) as a form of "index" that someone wants to refer to quickly to understand a code they stumble across. 

I have two questions.

1. Is there a reason that the "Editing Tips" page wouldn't just become the single page index of all the tools? Or is the idea of the Editing Tips page to be just a "for beginners" page with the most commonly needed tools?
    
2. Have you looked at what Gaile drafted to show one way this tool reference might be formatted? I think Rob's tool list would be a strong place to start, with the understanding that they should be pared down to include only the officially supported / recommended tools (since this is to be an official help page).

---

Lundie,

I see two very different audiences for which one page-- in my opinion-- will not do.

Editing Tips (1 or 2) is aimed at people who want to format biographies and want to know how to do so. How do I indent? How do I make something bold AND italicized? How do I make an inline footnote reference? I would expect to find things organized by what it is I want to accomplish.

Rob's list, and Gaile's variation of it, is aimed at people who want to know which CODE is acceptable/standard. They need to be able to scan it to see what's on the list. If someone sees a profile with both nonstandard and standard code on it, they need a list to compare the profile's code to.

Both valuable, but separate, in my mind.

As for Rob's list and Gaile's, I prefer Rob's. No offense, Gaile. I love what you're aiming for (and I love the formatting); I fear that the level of techno-speak, however, will not keep some readers' attention long enough for them to get what they need.

-- Jillaine

---

Did you happen to see my reference to the Cheatsheet on Wikipedia?

http://en.wikipedia.org/wiki/Help:Cheatsheet

Something formatted like this is what I'm hoping we end up with.  Whether it replaces Editing Tips or is linked to and listed somewhere easy to access, I don't really care.  We just need a list of the things we can do, and exactly how to do it.

Grouped by function, grouped by name, I don't care.  Just an official list.

---

Jillaine,

I have revised one of the profiles I manage to illustrate what can be done with a limited palette of font colour options (I am not suggesting the colours I have used are the ones that we would eventually include) and using <blockquotes> formatted on the stylesheet (I aimed for a very subtle effect in my example, and once again it is only an example - not the suggested end look)

Also, as is obvious, I had to use inline CSS on this page to create the example so the edit page looks more 'techie' than it would if the blockquote was styled by the sites stylesheet, and if there was a 'wikitext way' to change font colours.

Fawcett-236

---

Jillaine,

I don't think I have managed to illustrate my suggestion well enough because I think it really does fully answer all needs and will provide a very easy to use means for the 3 different types of user needs -

     1. the person trying to make changes to an existing profile who doesn't understand what the codes they see are all about

     2. the person who would like to find a way to do something special in a profile they are editing.

     3. the person who knows what they want to do but needs to find out if it is "recommended".

The way information is presented in the editing tips pages, the wiki cheatsheet that Lundie gave a link to, and also Rob's list are all very similar.  The editing tips does not present everything in a consistent style, though.  Rob's list is only presenting the "do this to get that" without attempting to provide information (which is entirely appropriate to his purpose in responding to my request for exactly that kind of list) and the wiki cheatsheet does not have it organized.

My intent is to use Rob's organization, standardize the format for what I'm calling an "information packet", and provide totally non-tekky user friendly descriptions.

The organization will result in a table of contents that lists the names (which need to be selected to describe what the elements do so that non-tekky users can immediately select which element they want to click on to instantly see it's information packet.

The information packets will all look the same - they will have the same kind of information in the same locations - the name and very brief description of what it does across the top, then a split with the sample of what code looks like on the left and what the resulting page looks like on the right, and finally at the bottom will be additional information that may include something about why the code looks like it does and how it works (for the users who want to understand it), what situations are appropriate for using the element, etc.

If someone wants to scroll through all the elements in 1 group (or more), they can do that but they do not have to.  They will see all the names of the elements in one ORGANIZED list at the top so that, no matter what their purpose in using the page to look things up, they will instantly be ble to get to exactly what they want to know in 1 very fast click.

Would you like me to make a more realistic sample?  I realize that I only made a full packet for 1 element in my sample, and that element was a sort of special one that will only be used very rarely.

---

Rob,

I looked at your profile example and only saw the background color on the blockquotes.  I saw your <font> tags, with colors specified when I looked at the edit page, but they do not show up for me on the profile page - all text is black there.

This is probably an excellent case in point of platform differences!  For what it's worth, I'm using Windows 7 and IE 11 at the moment.

I am a very big fan of having some classes added to the main css file - for the <blockquote>, <div>, and/or <span> elements.  I would like to see a few each of color, size, and alignment choices made available.  Of course, it will produce a large number of classes to cover all combinations of the possible choices, but it's a one-shot deal for Chris or Brian to do and the result will keep people happy about not losing creative capabilities while also keeping everything under global controls.

---

My bad - slipped my mind that html5 deprecated the <font> tag. :S  Should be fixed now.

---

A cheat sheet is a great idea.

In a couple days I should be able to go through whatever has been drafted up for this and the new Editing Tips page, make my edits, read through the above more carefully, and hopefully make the new pages "official."

I like the idea of a new page calling for <blockquote> to be used for extended quotations. That's a classic case of separating the tags that describe content from the coding that styles it.

---

This should probably go into a different G2G discussion page, but it started here so I'll include it.

Through a lot of experimentation, I finally achieved a lined Wiki mark-up table by reviewing the tips page. The table looks the same way my html table would have looked. Problem is, sometimes the lines disappear. Is there still a ghost floating around left over from Halloween or is this simply a result of an inexperienced wiki mark-up user who isn't quite getting things right. I think I know the answer to that. :}

http://www.wikitree.com/wiki/Space:Cox_Families_of_Pendleton_District%2C_South_Carolina

---

---

The rule at http://www.wikitree.com/wiki/HTML_and_Inline_CSS is now official. I'm still working on http://www.wikitree.com/wiki/Recommended_Tags and other supporting pages.

---

Very well written page, Chris. It's good that you have also created the 'Recommended Tags' page so that those of us who aren't as experienced in wiki mark up will have something to refer to.

---

Hi Chris

I don't see the format modifier parameters and attributes for Wiki markup tables on the recommended list.

Just to be clear, are any of them allowed?  

For example:

• border="1"
• align="right"
• cellpadding="2"
• width="50"
• valign="top" 
• cellspacing="0"
• colspan="3" and rowspan="3"

If not, will someone be setting up some basic templates for tables and table cells?

Thanks for WikiTree.

---

 

As Chris said above please read the section http://www.wikitree.com/wiki/HTML_and_Inline_CSS and it states "Unless specifically recommended on a WikiTree help page or style page, all HTML and inline CSS should be considered non-standard. Although we do not have rules about all possible combinations of HTML and CSS, when there is no rule that means it's not supported. It not officially recommended. It is not part of the recommended style."

---

Missing:

[[:Image:...]] link to but don't display an image.

~~~~ sign and timestamp

 

question: if == is level two header what is a level one header?

why is blockquote preferred over ":" for extended quotes? I know that Rob Ton prefers it but why has it been made a wikitree-wide standard?

---

Earlier in this thread, Rob had suggested including blockquote, with explanation of several ways in which it is better, and Chris responded that he thought that was very good to do.

I believe the main reason Chris liked it is because the tags set it apart when you look at the code page and people who are intimidated by codes are more likely to leave it alone.  The idea is that anything included in a blockquote should not be subjected to any "improvement" - it is a direct quote from some source.

By the way, I prefer it too - for the same reasons Rob does.  As to making sure people leave it alone, I think we need to establish a way to use it instead of just <blockquote>.  I would like to see something like:

<!-- *************************************************
      START OF SOURCE MATERIAL - DO NOT MAKE ANY CHANGES
     ************************************************** -->
<blockquote>
Whatever the quote is
</blockquote>
<!-- ********************************
      END OF SOURCE MATERIAL
     ********************************* -->

This still leaves the possibility that someone will make changes, but at least nobody will do it because they don't know they're not supposed to!

Personally, I would rather see something that is not ever to be changed put there in a way that does not have ability of changing.  If you take a screenshot of the source content, crop it, save the graphic, and upload it to the profile to use, THAT would solve the problem.

---

Naming of header levels is artificial.  In html, there is are tags for 6 header levels, numbered from 1 to 6.

I would guess that wiki markup, which uses equal signs for headers, cannot use 1 equal sign because that has to be allowed for people who want to use and equal sign to mean that 2 things are equal  -  how silly can they be, to want to use a text character in their content!!!

Anyhow, my guess is that since wiki header markup starts with 2 equal signs, they thought it would be less likely to confuse people if they call it level 2.

---

Hi Jillaine,

Level 1 headers are for the headline of the page, which in the case of profiles is the name of the person.

I didn't think it made sense to include the tildes in Recommended Tags because that page is meant to be used by someone looking up whether a tag they've seen in a profile can be removed. You don't see the tildes, you see what they create.

I tried to avoid making that page a cheatsheet that people would be tempted to use for instructions on how which tags to use and how to use them. That opens a can of worms. The rest of the help pages and style pages are the instructions.

Regarding blockquote, the strongest reason for them is the principle of separating content and presentation. Using blockquote leaves it up to WikiTree to decide how to display extended quotes. The tag just identifies them. We can always decide separately to indent or not, italicize or not, etc.

Chris

---

To be clear: Level 1 headers, whether done with HTML (<h1>) or wiki markup (=) do work inside wikitext pages.

Every page should have a level 1 headline. But they already do. On profiles they're the name of the person. On free-space profiles, project pages, etc., they're the title of the page.

Thererfore, when editing the text inside a profile or page, you shouldn't include a level 1 headline, you should start with level 2.

---

Thanks for the explanation of first level header. Understood.

Still don't understand the ":" vs blockquote distinction and separating content from presentation, but it clearly makes sense to you. And others. I will just trust there's a good reason.

---

Hi Jillaine,

I know you don't need an explanation (thank you!) but I think this is a very good one and I want to spell it out. :-) It's why I didn't think we needed to debate the issue, i.e. why unlike most style rules, it was just set rather than being discussed here carefully with an attempt to reach consensus.

The beauty of blockquote tags is that they just say what something is. They say a block of text is an extended quotation. They're pure HTML in this sense.

Deciding to use blockquote lets us separate the discussion of styling quotations. Right now we have a set style in our CSS files for blockquote. I think they're just indented. We could decide at any time, through discussion here, because of accessibility considerations, etc., to not indent them, italicize them, make them bold, make them smaller or larger, etc.

Answer 4

Personally, I can identify most of the forest plants in Nova Scotia and I can tell one species of sphagnum from another but all this computer lingo is way over my head and I don't have the patence to figure it out. Can there be a page or two of does and donts with examples of each.

For me I see something I like on another profile and I use it. I have no idea if I'm using html or css or wiki or some other computer lingo.

If I go to one of my profiles and see that it has been changed I'll assume that it was incorrect formatting and accept that and move on.

Comments

Hi Eugene,

Other help pages have instructions with dos and don'ts. This won't pretty much just says: If it's not on another help page, don't. :-)

It's not recommended that you copy from other profiles. Some of them, even Profile of the Week winners, are currently using non-standard styles. We're working on that (the first step on that road is clarifying this rule.)

Chris

---

Roger Wilco!

What about the stuff found on "Tons Tweaks"? http://www.wikitree.com/wiki/Space:Tons_Tweaks

 

I often use a lot of features from that page. Others likely do also so it would be good to fix it up if required.

 

---

There are lots of Pages, Robs is one. Lets not blame him

---

Hi Eugene. Rob's page is not official.

Official instructions include anything in the non-editable portion of a page, e.g. the contextual instructions on edit pages, or in http://www.wikitree.com/wiki/Category:WikiTree_Help or http://www.wikitree.com/wiki/Category:Styles_and_Standards

There's no guarantee that there aren't incorrect or outdated instructions on help pages, but we do make an attempt to keep them correct and up-to-date.

---

I'm not blaming anybody -really just want to know if I can continue to use the stuff on his page - not because I'm trying to single him out but because I like the things he has done.

---

I guess Chris is talking about me, i have won Profile of the Week over 12 times, personaly or by assocation. The differance with HTML and Wiki Markup was not an issue then. But there are issues with continual compatability and also edabily, plus we have to look to the future. Frankley i cannot see any differance other than HTML is continually changing

---

Gaille i have to reply here as i cant answer otherwise as that section is hidden. Ref Tags are an important Part of Sourcing in a Wiki. There are two levels of sourcing on a profile. When you take the time to write a Biography, the refs are your primary level, the ones below that are further reading and back up your primary level

---

Eugene I understood you were not blaming me.

Eric thanks for your concern.

As I have said in a number of previous discussions: the code on the Tweaks page was always intended to be used sparingly and for specific purpose or effect - and to showcase what is possible.

Although not recommended, anything from the tweaks page can still be used on non-open profiles with the understanding that eventually it may/will be removed when the profile becomes open.

Even on open profiles, css html is not forbidden, and chances are pretty good that if you have used inline css or html discriminately and for a very clear purpose future editors will just leave it alone (which itself is a reason for not using it - covered under "advanced coding adds complexity").

Perhaps more importantly, what is "non-standard" can easily become standard by community consensus. Some CSS/HTML can be incorporated into the style guide as a recommended/allowed use (and more importantly can be incorporated into the style sheets if appropriate); in some cases templates might be an appropriate way to apply certain effects while limiting use of CSS/HTML in profiles directly; at the extreme end of the spectrum, new extensions and magic words can be added to wikitree to extend wikitext. For example if superscript is something the community feels is needed it could be added to wikitext as:

  /\ item to be displayed in superscript /\

---

Thank you, Rob! As usual, you think and write more clearly than I do. These are excellent points.

---

Did not know about superscript wiki code.  Interesting.

Reminds me: need to add template code to

http://www.wikitree.com/wiki/Editing_Tips2

---

Jillaine,

Just to be clear, the superscript wiki code I mentioned above does not currently exist (as far as I know), it was just an example of something that could be added if the community wants the ability to use superscript in profiles in a "more wiki way" than using <sup> tags or CSS styling. It could also be done as a template {{sup|superscript text}} is desired.

Template code has a lot of twists of it's own - and the template specific code is technically already covered by the "anything in the help files caveat". (however the parser functions detailed here are not visible to all users). Further, it would be exceptionally rare to embed template code (other than calling templates) in profiles of individuals; template code is far more likely to be added to freespace pages which are a bit more 'lenient' (discussed under heading of "More Creative Freedom on Private and Free-Space Profiles). Moreover template code on freespace profiles should usually focus on providing content rather than style.

While not perfectly accurate, as a generalization 'template code' can be considered as anything between double braces {{ }} or triple braces {{{ }}}, the tags <noinclude>, <includeonly>, and <onlyinclude>, and content between the latter two tags.

Answer 5

Chris,

I just re-read your original question here and realize that not a lot of the discussion so far has been responsive to the last question "Is something about it unclear?".  I would now like to provide my answer to that.

It is obviously very well and carefully thought out, however I would like it to be more "glass is half full" than "glass is half empty" in style.  I recommend that it start with a positive statement instead of "the following ... doesn't apply to most WikiTree members".

After that statement, it identifies 2 types of members - at high and low end of technical skills - for whom it *is* intended, but does not have different content for these 2 groups.

I also have an issue with the statement about things not being recommended unless they are specifically recommended, which had me scratching my head to figure out what it meant - at first, it sounded like some kind of riddle to me.  Although I suppose it might not be technically correct to say this is unclear since I did manage to extract a clear meaning (after considerable thought), it is certainly not immediately clear upon reading the words.

I think reader impressions will be more positive if the wording establishes a more positive feeling, even if the actual content is identical.

Since html is among the "not recommended", I see no reason to confuse things by including comparison of how to do the same thing in both wiki markup and html markup.  I would prefer to see ONLY what is recommended presented here, although I suppose a brief statement at the end of the presentation that says something like "this is accomplished in html by use of the <whatever> tag".

I would like to see the presentation of EVERY SINGLE ELEMENT that is "recommended" included on this page.  I would like to see the elements grouped by some commonality, i.e., a group for elements that change text appearance (large/small, bold, italic, indents), a group for lists, a group for organizing data displays, etc.  I would also like to see the same style of presentation for each element, which would be:

   1. The name of the element and a brief description of what it does and the situations when it is good to use.

   2. A sample of the code that would be used.

   3. An illustration of the result of using the sample code.

   4. An explanation of the characters used in the code - where they need to be placed, why, and exactly what each one does.

Numbers 2 and 3 of those are there now.  Number 4 would probably be good for the WikiTree members who are currently excluded from your intended audience of this page - those members who do not know how to do these things, but would like to learn how in order to enhance profiles they work on instead of just being able to figure out how to avoid breaking things they see in existing profiles.

Finally, under your heading "Wiki Mark-up is Standard", you say that "all wiki mark-up tags can be considered standard" unless they are recommended against on a WikiTree help or style page, with links to the index pages for "help" and "style".  There are a lot of pages in both of those categories, and I think it is extremely unreasonable to ask anyone to go read all of them to try to find out which wiki mark-up tags are recommended against.

If ALL tags that are recommended are on this page then, by definition, if a tag is not on this page, it is not recommended.  We need this kind of clear, direct, and easy to find answer when we wonder if we can use a particular tag, and also to immediately see how to use it.

If you give me a list of ALL recommended elements, I will be happy to provide a draft of items to identify, give examples, and describe the code used for them.  You can then work on whatever changes are necessary/desirable to what I produce to ensure that the result is clear, concise, technically correct, and user friendly,  I like to think I'm pretty good at translating technobabble to English, but the bottom line is that I am an engineer, not a creative writer.

I hope you don't take this (painfully long, for which I apologize) comment as criticism.  You obviously have a lot of work invested in that page already and what I'm suggesting is more in the nature of fine tuning than any kind of changes.

Comments

I'll say the same thing here as I did in a comment above (since I believe we are in agreement), if our Editing Tips page could become something configured like this, I think we'd move a long way towards clarity.

http://en.wikipedia.org/wiki/Help:Cheatsheet

I do understand the "if we haven't specifically recommended it, then we don't recommend it".  This is good "all encompassing" verbiage, but I also heartily support putting a listing of what we "recommend" in terms of formatting codes all in one searchable cheat sheet page.

Answer 6

While not perfect, WeRelate.org is nice in that it provides some forms for those who really have no idea how to write, HTML, CSS or Modified Wiki Language.