Jacques Distler said on his weblog that I really should have permalinks on comments: Anne: your comments really should have permalinks!
. I now have permalinks on comments, how I did it is documentated on the Nuclues Support Forums, I hope it will help you.
I visit the weblog of Jacques Distler quite often, 'cause I'm really interested in the mixed specification he's using, XHTML 1.1 + MathML 2.0. This is something you don't see a lot (if you do, contact me ;)). I also noticed he's using the :hover pseudo-class on other element than the a element. This is interesting, 'cause IE doesn't support it, although IE doesn't support MathML either. I wonder if he watched that trick from DesignMeme, which is currently offline. My JavaScript/DOM workaround for IE was not well-known (I was a bit late with telling people), you can find the weblog entry at BLOG-FU [Simian Design] and the technique is on this domain: p:hover. I hope it can be of use to someone.
(I know I shouldn't have done CSS inline and that the use of cdata is evil, but it was a while ago and it's only a simple example.)
I think everyone knows XHTML 1.1 was a small revision of XHTML 1.0, too small in my opinion. Most of the time a study people their source code when I visit their page for the first time (It's a bit of an addict), but what really surprised me was that I found an i element (can you call that an element?) in the source of Jacques Distler, the man who uses XHTML 1.1 and MathML 2.0. I know he only uses that, 'cause it's the only logical way to publish mathematics in a weblog (Images suck!), so he doesn't really care of his markup. The markup should be valid that's all*. But that this horrible element is even allowed! It surprised me a lot and now I like XHTML 2.0 even more.
*Actually his markup should only we well-formed. If it's not well-formed Mozilla will throw in a parsing bug and that's not how he (and I and more) likes it. I think he validates it to overcome problems between browsers and different platforms.
Last but not least (this is about links he) Cinnamon has released (and debugged) three excellent articles about search engines. The ones you would like A List Apart would have (In English than, since this is in Dutch). De Grote Zoektocht: Google:
I think everyone knows XHTML 1.1 was a small revision of XHTML 1.0, too small in my opinion.
Actually, XHTML 1.1, "the Modularization of XHTML," was a big revision for me. It let me do what I need to do (incorporate MathML and maybe someday soon SVG). XHTML 1.0 did not cut it for me.
Technology-wise, XHTML 1.1 is a big advance. Semantic-Purity-wise, perhaps not. But, as you note,
what really surprised me was that I found an
ielement (can you call that an element?) in the source of Jacques Distler
I'm not religious about Semantic-Purity. I do use <i> and <b> elements, and I use curly quotes and ... which are all "presentational". And I use <acronym> when I should be using <abbr> because people using screen readers should have access to them and you can't rely on javascript hacks to ensure that they do.
I probably should ditch <i> and <b>, but I stand firmly by the rest.
"I also noticed he's using the
:hoverpseudo-class on other element than theaelement. This is interesting, 'cause IE doesn't support it, although IE doesn't support MathML either."
Very few of my readers use that nasty browser, so I don't make much of an attempt to "support" it. I try to avoid having things *break* in IE, but certain "advanced" features of my blog just won't render in IE. That's too bad; people should just get a better browser.
Your DOM trick for getting :hover to work on <p> elements in IE is very clever. But it would take quite a bit more work to get it to work for the various <li> elements on my sidebar. It's doable, but probably not worth the effort to me.
As to Validation, that's something I am religious about. If my pages don't render correctly in someone's browser, it's the browser's fault, not mine.
To pick an example, in Mozilla, the scroll bars from overflow:auto bleed through the :hover tricks I do with the <li> elements on my sidebar. Safari renders them correctly. (Though it does have its own bug with overflow:auto .)
I'm not going to fret about these too much because Dave Hyatt will fix the Safari bug and someone will fix the bug in Gecko. If I found a hack to work around these browser bugs today, I'd have to go back and fix it again when the bugs are corrected.
I'm not going down that road. I code to Standards and make sure my content is (100%) valid; the rest is up to the browser-writers.
You are right about the JavaScript hack, but not about the screen readers. The importance to distinct abbr and acronym is also important for screen readers (are there any, which aren't used at IE?). In my aural style sheet I specify that an acronym is read and an abbr is spelled out.
Besides that, coding acronym and abbr is coding to the standards, what you do, don't you :).
Second: Since you're "worried" about screen readers you should convert your i and b element into em and strong, 'cause screen readers know the difference between those ;).
Back to the JavaScript hack: Visitors who visit a site are not always aware of the abbreviations that are used. If I can make my abbreviations work in other browsers and if that involves an ugly hack I think it's worth it, because then those people have access to the underlying markup.
Sometimes <b> means <strong> (and I should get out of the habit of using the former when I really mean the latter). But sometimes <b> really does mean boldface. I could code that as <span class="bold"> instead of <b>, but that seems a little silly to me...
If I had an aural stylesheet (which I should) I would definitely want to distinguish between <acronym> and <abbr>. Since I don't (currently), I'm mainly catering to JAWS (which, I understand, has an even bigger share of the screenreader market than IE has of the browser market). Since JAWS sits on top of IE, it is limited by all of IE's failings -- which include not supporting <abbr>.
It's a bit quixotic of me to expect my sighted readers to use a better browser (like Mozilla), but not have the same expectation that blind reader switch to a "better" screenreader.
Frankly, the day that there's a MathML-capable screenreader (or XSLT solution), I'll start coding to that. Right now, I'm not aware of a "better" alternative, so it seems churlish to demand that my readers switch just so they can read <abbr>'s instead of <acronym>'s.
Actually, I take back one bit: JAWS 4.51 (the very latest version) added support for <abbr> and <acronym>. In light of that, perhaps I will go back and use <abbr> where appropriate. (I'm a little mystified as to *how* JAWS 4.51 supports <abbr> when IE does not, but that's just me...)
Great you are using aural and print style sheets now. I have one thing left to say about font style elements ( [link] ):
If your using for example the b element to make something bold. You said you can do that without wanting to give an extra meaning to it. But the accessibility guidelines say that something that is visually different should also be aurally (markup) different. Since the b element isn't markup but style, you only give this advantage of differentiating between normal and bold style to a graphical browser, while holding it back from an aurally based browser.
Actually, I do distinguish <b> and <strong> from normal text by giving them higher richness and stress:
b, strong{
richness: 90;
stress: 90;
} /* normal is 50 */
You, by contrast, try to do it by adjusting the volume. Unfortunately, all volume levels are clipped to 100. So, since you set normal text to be read at 100, it ends up aurally indistinguishable from everything else (which is given 'higher', but invalid values). Well, OK, your <em> text is spoken slower than everything else, but that's all.
You are wrong about that unfortunately (and fortunately for me). The W3C says this about percentages for the property volume:
- percentage
- Percentage values are calculated relative to the inherited value, and are then clipped to the range '0' to '100'.
So I think I'm not wrong there. I should consider to aurally style the header tough.
Did I misread your stylesheet? I thought you set the volume for regular text to 100 (the maximum). You can't get any louder than that. (I.e. 130% of 100 is still 100 after clipping).
I think you missed the % after the 100. Though it should get an upgrade with more elements specified and especially something that's useful for tables and headers.
Oops! OK, then.
While I have your attention, do you know why the CSS Validator complains about the (what look to me like perfectly legal) declarations at the end of my aural stylesheet (the ones currently commented-out)?
And have you actually used EmacSpeak to test-out your aural stylesheet? (I don't, alas, have it installed.) It seems a little nutty to be discussing the minutae of a stylesheet without actually being able to test it.
Except for shitload of warnings I couldn't spot a single error: validate all files.
If I only validate your aural style sheets there isn't any warning or error: validate aural file.
And we all know that we shouldn't care about errors, so I'll think you are just fine.
That's 'cuz I commented-out the directives which were giving errors. Here's the URL to validate the stylesheet with the offending directives included:
And here's the error message: URI : http://golem.ph.utexas.edu/...
* Line: 37 Context : abbr:after , acronym:after
Invalid number : contentProperty content doesn't exist for media aural : " " attr(title)
* Line: 43 Context : img:after
Invalid number : contentProperty content doesn't exist for media aural : " " attr(alt)
They clearly don't the content property, though I thought the Spec allowed it. Curious ...
Now I understand :). Try this:
foo:after{
content " attr(samp)"; /* the space between " and attr is the space you need ;) */
}
here's my fix for the <abbr/> tag. it involves no css hacks, no javascript and no unnecessary tags. it's so simple you won't believe it! link