This text should not be bold.
This line should be green.
Example of a hyperlink to the CSS home page with special one-off visited and hover effects.
 | Gender symbols and the Sekushii font
December 27, 2002
|
|
Gender symbol fonts
|
¶ I was struck by the lack of complete fonts with gender symbols. The TeX/Metafont community lives with Denis Roegel's Genealogy font, created in 1996 and updated in 1999. Denis Roegel essentially compiled the genealogical symbols found in Roland Waldi's Wasy font (1992), which has a male and female symbol set, and Knuth's "gen" font, and added the standard symbols for males and females.
¶ The truetype world probably is most acquainted with Marvin Vogel's useful (and free!) symbol font Marvosym, which contains symbols for sexless, male, female and hermaphrodite. Marvin recognizes that there are other people in this world besides straight males or females, but the symbol he suggests for hermaphrodites is not the one used by or suggested by the world of sex experts [read on below]. Curtis Clark made the free font called Female and Male Symbols (1996), which contains the same gender symbols as Marvosym. ¶ WordPerfect's WP IconicSymbolsA (1993) just has a male and a female symbol. ¶ There are, of course, a number of commercial outfits that have the standard pair of gender symbols in some of their fonts. Particularly artistic are P22's Koch Signs 3 and Koch Signs 4. Whether by design or accident, these also have a glyph for hermaphrodites. An even more complete set is Ann's Astro family of fonts from Dingbatcave (Ann Stretton), at 10 dollars per style. ¶ Unicode has reserved position 9792 for the female sign, and 9794 for the male sign. Nothing is reserved for the others. Some Unicode fonts indeed do have these two characters. However, no Unicode font has more than this bare minimum, and thus, the Unicode path is a cul-de-sac. ¶ So, that is the current state of affairs. The world's gay community started using their own symbols, derived from those for male (the symbol for Mars) and female (the symbol for Venus). But, not to be left out, the bisexuals, both male and female by birth, suggested their own glyphs. Outnumbered but not outgunned, the hermaphrodites picked their own symbol, that of Mercury. But it does not end there. The transexuals do not fit into any of the above categories, so they have their own symbols. Transgendered people are usually defined as those who are aware of all people of all sexual orientations and preferences, and approach relationships in a gender-free manner. Well, they have their own symbol. I never located the symbol for eunuchs, but I am sure there must be one. Of course, the combinations multiply. However, I refuse to create symbols for gay hermaphrodites, transsexuals who like eunuchs, and males who had two sex change operations (to get back to where they started from). ¶ If you have a special request though, send it to me, and I will see if I can make a font for you. Always for free, of course.
|
| The symbols | ¶ The ultimate place for symbols is the highly recommended site Symbols.com. For definitions of transsexual, transgender, bisexual, and other terms, see here. Some symbols are shown here. Official books always lag behind, so I went looking for what people actually use to represent different sexual orientations, preferences and situations. At present, the world seems to agree on the following symbols: 
 | Mars, or Tuesday: symbol for males. |  | Venus, or Friday: symbol for females. |  | Gay males. |  | Gay males. |  | Lesbians. |  | Aware of the joint cause of gays and lesbians. Also (sometimes) transsexuals. Also, quite universally in science, used for hermaphrodites. See here. Symbol.com states that it is used in botany for double-sexed plants. Also, (sometimes) heterosexuals in general. See here or here. |  | Bisexuals. Sometimes used for people fighting for gay and lesbian rights. |  | Transgender. See here. |  | Another symbol for transgender: see here. |  | Bisexuals. |  | Bisexuals, as proposed here. Closely related in some places to the symbol for bisexual men. |  | Bisexual men. |  | Bisexual women. |  | Mercury, or Wednesday: Hermaphrodites. See here. The Greek equivalent of Mercury is Hermes, hence the name. Apparently, biologists use this for hermphrodites. |
|
| The Sekushii font | ¶ The Sekushii font is part of the Sugaku series. It has all the symbols above, in many sets, both light and medium weight. There are straight-arrowed sets for combining with sans serif text, flared arrows for serif text, and fun experiments and extensions with various sexual undertones. And, it is free! Have a ball.
|
|
|
Copyright © 2002 Luc Devroye
School of Computer Science
McGill University
Montreal, Canada H3A 2K6
luc@cs.mcgill.ca
http://cg.scs.carleton.ca/~luc/index.html
|
3. Grammar The syntax of the CSS fragment that is allowed in the HTML "style" attribute can be formally specified as follows: inline-stylesheet : S* [ declarations | declarations-block | inline-ruleset* | stylesheet ] ; declarations : declaration [ ';' S* declaration ]* ; declarations-block : '{' S* declarations '}' S* ; inline-ruleset : [ pseudo* S* [ ',' S* pseudo* S* ]* ]? declarations-block ; Please refer to the grammar in appendix D of the CSS2 specification [CSS2] for the definition of the symbols not defined here. The same rules for forward-compatible parsing apply to the inline style sheet as to a normal style sheet. See chapter 4 of the CSS2 specification. 4. Cascading order CSS already defines how style sheets and "style" attributes are cascaded together for the case where the inline fragment consists of declarations only. In addition to simple declarations, the style attribute is now permitted to take rulesets. These rules have the additive specificity of their selectors in addition to the specificity of the style attribute. The examples indicate what is added to each of the specificity components using the familiar '+=' notation. Example:
This is an example of a paragraph with inline style attribute rules to create a spot effect, in this case, a drop-cap first letter.
Example:
Example of a hyperlink to the CSS home page with special one-off visited and hover effects. This text should not be bold.
This line should be green.
1. History HTML 4.0 introduced the "style" attribute, whose contents could contain any styling language (through the use of META http-equiv Content-Style-Type), but by default, and in practice, has only contained CSS. XHTML Modularization introduced the Style Attribute Module which also has a "style" attribute whose semantics are the same as that in HTML 4. SVG also has a language neutral "style" attribute, whose language is specified with the contentStyleType attribute which has the default value of "text/css". MathML states that all MathML elements accept the "style" attribute to facilitate compatibility with CSS. Not all XML-based document formats have a "style" attribute to permit the user to use CSS to style documents and specific elements in documents, but in case a certain format has a "style" attribute and the attribute accepts CSS as its value, then this specification describes the attribute's syntax and interpretation. 2. Examples Here are a few examples: Only setting properties on the element itself, no pseudo-elements or pseudo-classes:
...
Setting properties on the element, as well as on the first letter of the element, by means of the '::first-letter' pseudo-element. Note that curly braces ({...}) are required in this case:
...
Setting properties on a source anchor for each of its dynamic states, using pseudo-classes:
... Importing a style sheet to apply as a scoped style sheet:
style="@import url(navigationstyles.css);">...
Note: in CSS1 and CSS2, the spelling of '::first-letter' and '::first-line' is ':first-letter' and ':first-line' respectively, i.e., with a single colon, but Selectors recommends using double colons for pseudo-elements. This document defines both the simple case (only properties on the element itself, example 1), as well as more complex cases such as rules that apply only to the element (e.g. properties on the element's pseudo-elements and pseudo-classes, examples 2 and 3), and scoped style sheets (the use of @import which apples the referenced style sheet to the subdocument consisting of the element and its children with the element as the root, example 4). 3. Grammar The syntax of the CSS fragment that is allowed in the HTML "style" attribute can be formally specified as follows: inline-stylesheet : S* [ declarations | declarations-block | inline-ruleset* | stylesheet ] ; declarations : declaration [ ';' S* declaration ]* ; declarations-block : '{' S* declarations '}' S* ; inline-ruleset : [ pseudo* S* [ ',' S* pseudo* S* ]* ]? declarations-block ; Please refer to the grammar in appendix D of the CSS2 specification [CSS2] for the definition of the symbols not defined here. The same rules for forward-compatible parsing apply to the inline style sheet as to a normal style sheet. See chapter 4 of the CSS2 specification. 4. Cascading order CSS already defines how style sheets and "style" attributes are cascaded together for the case where the inline fragment consists of declarations only. In addition to simple declarations, the style attribute is now permitted to take rulesets. These rules have the additive specificity of their selectors in addition to the specificity of the style attribute. The examples indicate what is added to each of the specificity components using the familiar '+=' notation. Example:
This is an example of a paragraph with inline style attribute rules to create a spot effect, in this case, a drop-cap first letter.
Example:
Hypertext Markup Language
Test passes if there is no space between the green and blue boxes below.
Writing Test Cases for Web Browsers This is a guide to making test cases for Web browsers, for example making test cases to show HTML, CSS, SVG, DOM, or JS bugs. There are always exceptions to all the rules when making test cases. The most important thing is to show the bug without distractions. This isn't something that can be done just by following some steps, you have to be intelligent about it. Minimising existing testcases STEP ONE: FINDING A BUG The first step to making a testcase is finding a bug in the first place. There are four ways of doing this: 1. Letting someone else do it for you: Most of the time, the testcases you write will be for bugs that other people have filed. In those cases, you will typically have a Web page which renders incorrectly, either a demo page or an actual Web site. However, it is also possible that the bug report will have no problem page listed, just a problem description. 2. Alternatively, you can find a bug yourself while browsing the Web. In such cases, you will have a Web site that renders incorrectly. 3. You could also find the bug because one of the existing testcases fails. In this case, you have a Web page that renders incorrectly. 4. Finally, the bug may be hypothetical: you might be writing a test suite for a feature without knowing if the feature is broken or not, with the intention of finding bugs in the implementation of that feature. In this case you do not have a Web page, just an idea of what a problem could be. If you have a Web page showing a problem, move to the next step. Otherwise, you will have to create an initial testcase yourself. This is covered on the section on "Creating testcases from scratch" later. STEP TWO: REMOVING DEPENDENCIES You have a page that renders incorrectly. Make a copy of this page and all the files it uses, and update the links so they all point to the copies you made of the files. Make sure that it still renders incorrectly in the same way -- if it doesn't, find out why not. Make your copy of the original files as close to possible as the original environment, as close as needed to reproduce the bug. For example, instead of loading the files locally, put the files on a remote server and try it from there. Make sure the MIME types are the same if they need to be, etc. Once you have your page and its dependencies all set up and still showing the same problem, embed the dependencies one by one. For example, change markup like this: <link rel="stylesheet" href="foo.css"> ...to this: <style type="text/css"> /* contents of foo.css */ </style> Each time you do this, check that you haven't broken any relative URIs and that the page still shows the problem. If the page stops showing the problem, you either made a mistake when embedding the external files, or you found a bug specifically related to the way that particular file was linked. Move on to the next file. STEP THREE: MAKING THE TEST FILE SMALLER Once you have put as many of the external dependencies into the test file as you can, start cutting the file down. Go to the middle of the file. Delete everything from the middle of the file to the end. (Don't pay attention to whether the file is still valid or not.) Check that the error still occurs. If it doesn't, put that part pack, and remove the top half instead, or a smaller part. Continue in this vein until you have removed almost all the file and are left with 20 or fewer lines of markup, or at least, the smallest amount that you need to reproduce the problem. Now, start being intelligent. Look at the file. Remove bits that clearly will have no effect on the bug. For example if the bug is that the text "investments are good" is red but should be green, replace the text with just "test" and check it is still the wrong colour. Remove any scripts. If the scripts are needed, try doing what the scripts do then removing them -- for example, replace this: <script>document.write('<p>test<\/p>')</script>; ..with: <p>test</p> ...and check that the bug still occurs. Merge any <style> blocks together. Change presentational markup for CSS. For example, change this: <font color="red"> ...to: span { color: red; } /* in the stylesheet */ <span> <!-- in the markup --> Do the same with style="" attributes (remove the attributes, but it in a <style> block instead). Remove any classes, and use element names instead. For example: .a { color: red; } .b { color: green; } <div class="a"><p class="b">This should be green.</p></div> ...becomes: div { color: red; } p { color: green; } <div><p>This should be green.</p></div> Do the same with IDs. Make sure there is a strict mode DOCTYPE: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"> Remove any <meta> elements. Remove any "lang" attributes or anything that isn't needed to show the bug. If you have images, replace them with very simple images, e.g.:
http://hixie.ch/resources/images/sample If there is script that is required, remove as many functions as possible, merge functions together, put them inline instead of in functions. STEP FOUR: GIVE THE TEST AN OBVIOUS PASS CONDITION The final step is to make sure that the test can be used quickly. It must be possible to look at a test and determine if it has passed or failed within about 2 seconds. There are many tricks to do this, which are covered in other documents such as the CSS2.1 Test Case Authoring Guidelines:
http://www.w3.org/Style/CSS/Test/guidelines.html Make sure your test looks like it has failed even if no script runs or anything. Make sure the test doesn't look blank if it fails. Creating testcases from scratch STEP ONE: FIND SOMETHING TO TEST Read the relevant specification. Read it again. Read it again, making sure you read every last bit of it, cover to cover. Read it one more time, this time checking all the cross-references. Read the specification in random order, making sure you understand every last bit of it. Now, find a bit you think is likely to be implemented wrongly. Work out a way in which a page could be created so that if the browser gets it right, the page will look like the test has passed, and if the browser gets it wrong, the page will look like it failed. Write that page. Now jump to step four above.
This text should not be bold. This line should be green. Example of a hyperlink to the CSS home page with special one-off visited and hover effects. The Sekushii font ¶ The Sekushii font is part of the Sugaku series . It has all the symbols above, in many sets, both light and medium weight. There ar ...»
See Ya
