[dokuwiki] Re: pending patches?
- From: Anika Henke <a.c.henke@xxxxxxxx>
- To: dokuwiki@xxxxxxxxxxxxx
- Date: Sat, 10 Feb 2007 21:15:59 +0100
Sander Tekelenburg wrote:
At 22:03 +0100 UTC, on 2007-02-09, Anika Henke wrote:
(Let alone the fact that the opinions of the <q>
tag are quite controversial, see http://alistapart.com/comments/qtag/
Looks like a bunch of only vaguely related remarks there. Is there anything
in particular you are referring to?
I am referring to nothing in particular, just the fact that people do
not necessarily agree on that subject.
One good question, though, from those comments:
----
Should we introduce a <quest> tag that surrounds all questions, so that,
say, in a Spanish locale the upside-down question mark appears at the
beginning of the line?
----
What stands out to me is that they argue against <q> because IE doesn't
support it, and because XHTML 2.0 aims to get rid of<q> -- ignoring that IE
doesn't support XHTML. At the very least those arguments exclude each other,
but no one there seems to acknowledge that.
I did not get that impression ...
or
http://diveintomark.org/archives/2002/08/14/the_q_tag_revisited.)
IMO that one is a rubbish argument. It's a bit like aguing against democracy
just because some democratically elected politicians suck.
(I initially wrote a lot more (about IE, Jaws, standards), but deleted that
because that's not really about Dokuwik and so probably considered a bit too
off topic here.)
I can see why people see the accessibility issues from this practical
point of view. And I don't think this argument is "rubbish". A blind
reader of a web page is not concerned about its correct, valid and
semantic use, but about a (for him/her) meaningful output.
True, this meaningful output is best achieved by the screenreaders
adhering to the standards, and not the web pages being written for the
screenreaders.
I agree, that this is the wrong way to do it. In an ideal world you
should not care about how any kind of software implements a standard.
You just should write standardized sensible input.
But in this real world you can do it only as long as that does not do
any harm ...
And the <q> element is not the thing that makes a text less accessible,
but the *omition of the quotation marks*.
Quotation marks are sufficient. Most (every?) screenreader knows a
quotation mark when it sees one. Additional semantic could better a
quotation, but it is not necessary.
I do recognise that Dokuwiki's inline editor doesn't offer buttons to
generate such mark-up, so you'd have to allow raw HTML to be entered. (Or
perhaps it can be done with markdown, which I believe Dokuwiki supports.)
Maybe a markup for inline quotes are missing? Would it be used??
That probably depends on the users. I'm sure that in some environments they
wouldn't use it, and in others they would.
Possibly if the default CSS would suggest proper, language dependant, quote
characters, that would encourage people to use it? It would return an
immediate visual result that people generally don't know how to achieve
(entering 'special characters').
Inline quotations are rarely enough, so I would rather suggest a syntax
plugin (maybe for other rarely-used-but-should-be-used-more-often
elements as well).
And in that plugin you could make it configurable to add quotation marks
by CSS or not (just to satisfy the highest amount of people ;-) ) ...
Unless you can "guess" (here again! ;-) ) the kind of quotation mark
usage in a text, it makes no sense to *always* use <q> ...
Agreed. Still, I suspect that you do agree that wherever <q> or <blockquote>
*are* appropriate, it's better to use them then to simply enter quote
characters, right?
<blockquote>: Yes, definitely.
<q>: I am not sure ...
(I try to make it short, because it is a bit off topic.)
First, I am *against* <q> as a *substituion* for quotation marks. But
*adding* it would *better* the semantics - in theory!
IMO, much things about the <q> spec are just unreasonable:
a) Why let the browser add the quotation marks? Quotation marks are
punctuation and belong to the content.
b) Being able to give <q> language-specific quotation marks per CSS is
not a good argument, because the editor of a text should take care to
use the correct quotation marks (for his/her language) anyway. And those
should not be changed!
c) Why do we have *two* different tags for quotation (<q> and
<blockquote>), describing the very same thing? When the only difference
is that one is an inline and the other a block element?
d) These two quotation elements have two *different* behaviours: <q>
adds quotation marks (according to the specs) and <blockquote> does not!
Why is that so inconsistent?
(I think, you could only disagree about a) and b), because it's more a
philosophical thing. But can anyone assign a reason for c) and d)?)
I am not against using <q>. It has clearly advantages: It is more
semantic (and hence, it is possible to distinguish between quotes and
titles and irony, etc.) and it can be styled differently.
But the disadvantages (see above, plus the fact that no living browser
has fully implemented it yet) outweigh the benefits. At least in my opinion.
Anika
--
DokuWiki mailing list - more info at
http://wiki.splitbrain.org/wiki:mailinglist
Other related posts:
