I'm sorry to say I'll start with a note and my own questions:
a) Why do you send to the list something that looks like a private matter?
b) Why do you say "us" when you mean "me"?
c) Why do you bother writing and article if you don't accept critics?
d) Why do you force me to re-read your article?
I will answer here what might deserve some thought, the rest... I
might answer you privately (eventually).
Christian Heilmann wrote:
[···]
>> I don't think he's wrong (solely in the point that hybrid menus are
>> better), but anyone with some knowledge could think of this article as
>> poorly-done or not being objective --he seems to be some sort of JS expert.
>>
>
> What is the knowledge you talk about here that would make people think
> of this article as poorly done or not objective? The fact/assumption
> of "he" being a JavaScript expert would also mean that the the CSS
> menus in Eric Meyer's books also by default are a bad solution and the
> chapter not objective and bad, wouldn't it? Who should write an
> objective article? A brick layer? Or maybe an interaction designer?
>
When I referred to "him" being *some sort* of JavaScript expert
--don't take for granted you are an expert _in my opinion_, not yet at
least-- was linked to my *opinion* of this article being subjective,
with a somewhat JS-favored flavor.
Oh, the "knowledge" I'm referring to is JS and CSS. And I haven't
read Eric's book that you mention, but if you send me a copy I would
gladly give you my opinion on this matter, as I can see is really
important to you :)
>> The way he uses to expose his point of view looks more like saying CSS is
>> plain wrong, it also shows a lack of understanding of it and seems to
>> believe there's no common sense (which could easily be applied to both CSS
>> and JS).
>>
>
> Again, please enlight us as to the lack of understanding of CSS and
> especially the lack of common sense.
First, a clarification, what I meant was that you seem to believe
there is no common sense out there, not that you lacked common sense
(but, of course, I have the right to change my mind).
From the article...
« The part of CSS that makes effects like these possible is pseudo
classes. These define styles applied to an element when something
happens to it. »
If *I* understand correctly, pseudo-classes do not refer to
something "happening" to the element, quoting the W3C definition:
« The pseudo-class concept is introduced to permit selection based
on information that lies outside of the document tree or that cannot be
expressed using the other simple selectors. »
Which, *I* interpret more like a status or condition than an event.
« You can only affect elements that are nested inside the element
you define the hover style for. This, together with MSIE 6s support
issues limits you to inline elements for your CSS-only effects, unless
you choose to create invalid HTML. »
We know that's not quite right, or at least, that you forgot to
mention the other browsers and their CSS support which is better. I
guess you wrote this quite some time ago(?), so I would only ask you to
update your article.
« Furthermore pseudo selectors dont add to the specificity of a CSS
selector, which can make it very tricky to define different styles. »
Let's ignore the typos, shall we? See second example at
http://www.w3.org/TR/CSS21/cascade.html#specificity
there the ":first-line" pseudo-class is applied to the LI element and
its specificity value is not 1, but 2, again I guess this is because the
article is too old. Also, what is a pseudo-selector?
« The necessity to nest all the elements affected by the hover
styling also brings up the issue of altering the HTML and content to
cater for an effect. »
I also think there's a lack of understanding or being "up to date"
in this text, as you can see that CSS drop-down menus are usually pretty
semantic, and include just a few (if any) meaningless elements that are
usually neutral (such as DIVs).
« Assistive technology like screen readers allows you to quickly
navigate through the document with a listing of all the links in the
document. If all your links are that long or even worse encompass whole
paragraphs of text this very useful feature becomes a pain to use. »
A reference to lack of common sense. Of course, there's nothing
wrong whit highlighting the obvious, and it could be meaningful for
newbies or people who just has been doing things too wrong.
I stop here. Your article is interesting and I would like to read it
all again, but I guess the point has been made clear.
> Also, point out where the article
> says CSS is plain wrong. There are parts that say that using CSS for
> *these solutions* is wrong, and there are arguments why but where is
> the sweeping statement?
>
This was basically a result of the previous point, I just don't
think you are giving enough information and you look... well, not
objective enough. As the section you mention is actually where I stopped
above, let me see if there's something worth mentioning (from my part)...
« You cannot test properly with CSS there is no conditional syntax,
instead you need to rely on browsers and visitors being able to
understand and use your solution or get an unusable page. »
That's something I don't quite understand, do you mean by using
"object detection" in JavaScript you don't need to test in any other
browser but IE 6 (or whatever browser you use)? Do you think people
documenting themselves on CSS support and browser testing isn't testing
properly?
Yes, the user may have some CSS rules himself, if he does, he
usually knows why and how could affect this to the pages he's visiting.
So is someone who has Grease Monkey installed and is altering the site's
JS behavior. I really see no big difference here.
« You are at the mercy of the browser when it comes to keyboard
support. »
Hell, this is *so* true, and how do I hate it. But then again,
keyboard support isn't usually the easier task in JavaScript (depending
on the keys you're using), they're too far apart from each other in this
area, and even the same browser in a different platform has
compatibility issues. Although this may be a little off-topic.
« [...] browsers only allow keyboard access to links and buttons.
You also only allow for keyboard support for web pages, not for
applications (more on that later). »
Common sense and some guidelines ask you to use links, even if the
item has no sense by itself and serves only for grouping it's
recommended to use a link o a page listing those sub-items, "just in
case" --that is accessibility too.
« With links being inline elements you can only nest other inline
elements in them, and you may make it a real pain for users relying on
assistive technology to use your site. »
The same issue again, disinformation, outdated, or not enough info.
You choose.
« There is no way to allow the user to make a mistake or move the
mouse slightly without losing the extra information or in worse cases
collapse a whole menu »
There _is_ a way (or more?) to achieve this, it's just that people
are not used to do it. We don't usually think on accessibility (don't
know why), and/or would require some extra tags.
OK, I will stop here this time.
> These are rather tough accusations you make here, however they lack the proof.
>
Well... what can I say?
> Let's see an application of common sense and find a CSS only menu that
> works with a keyboard and stays on-screen even if there is not enough
> space for it to show more to the left or the bottom.
>
I guess you missed the point when I said "I don't think he's wrong",
if you did is the first paragraph on this e-mail --"he" being "you", by
the way.
>> Anyway, it's good to have it as a reference, but I do believe people
>> should investigate a little more.
>>
>
> I think people should stop trying to prove a point in one direction or
> another but use what works reliably. Point is that with CSS you make
> assumptions, with CSS and JS you can test before you apply (is there
> enough space? Would a delay in showing or hiding a menu make it more
> usable?)
>
Now I see what you meant by "testing properly"! It seems I didn't
get you, sorry. It would be good to have this clarified in the article too.
> Maybe the question is "what should a drop down menu achieve and what
> are the circumstances it could be used" and then we decide the
> technology to apply. Right now all of the discussions on this matter
> start with "I want to use technology XYZ as I know it and it IS the
> best for this!". All other technologies are black magic and insecure
> and probably steal your firstborn when you don't watch them closely.
>
Now, now... you're making assumptions. I do know JavaScript, in fact
I've been working with it since the dark times (I never, ever, enjoyed
working with NS 4.x!). I'm not an expert, not even self-declared, but I
usually know what I'm saying, and if not, I'm (usually) glad to hear
that I'm not and, if possible, why.
Well, finally it's over. I said that I would only answer what was
worth it of, but I ended up answering almost everything, so don't expect
that private message I promised you before.
Regards,
Rafael.
______________________________________________________________________
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
