On 8/22/06, Boris Mann <boris@bryght.com> wrote:

And, contrary to Adrian's comment....we're likely to maintain a backport patch of jQuery in 4.7. You can, of course, use jQuery as-is in 4.7 (there are a few scripts, like gmap, that seem to have some conflicts), but this backport approach will likely be nice for those that want to develop on 4.8/5.0 and then also branch for 4.7.

I'm well aware of being able to use jquery in 4.7, and I have used it as such before. I'm looking forward to the backport too =) I've just not been this excited about a new release in years.

Was I the first to mention it??? ( http://lists.drupal.org/archives/development/2006-05/msg00955.html) Just kidding, but this is some really wonderfull stuff. I'm already using jQuery in Drupal projects and as I said, it's a perfect match. Regards, Anders On 8/22/06, Morbus Iff <morbus@disobey.com> wrote:

...

I mentioned that I started playing with jQuery, when I put the finishing touches on my hovertips module I planned to contribute it (for 4.7.x):

http://dave-cohen.com/node/1186

I never did like this particular implementation. There are four types:

* Inside spans: <p>Whee! <span>you're hovering!</span></p>, which makes it really ugly for screen readers or just general DOM goodness.

* External divs, like you: <p>Whee</p> <div>you're hovering!</div> Also can be ugly depending on where you place all the divs (at the very end of the document? is that cleanly possible?). Would require you to match up IDs in two different places though.

* Alt/title hovers - based on the value of the title text. <p title= "you're hovering!">Whee!</p>. This one's bad because you can't use HTML in your tip very cleanly.

* JS events, such like <p onmouseover="tooltip_on('you're hovering!')" onmouseout="tooltip_off()">Whee!</p>. I tend to like this one (and implemented it in my game.module, not via jQuery though) the most because it a) doesn't pollute the DOM, b) don't harm screen readers, c) allows HTML, d) keeps everything in one place, e) doesn't require bookkeeping (which ID goes with this element?).

Comments?

[1] http://cvs.drupal.org/viewcvs/drupal/ contributions/modules/game/game.moduleview=markup

-- Morbus Iff ( omnia mutantur, nihil interit ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus

Morbus Iff wrote:

* JS events, such like <p onmouseover="tooltip_on('you're hovering!')" onmouseout="tooltip_off()">Whee!</p>. I tend to like this one (and implemented it in my game.module, not via jQuery though) the most because it a) doesn't pollute the DOM, b) don't harm screen readers,

Screen readers need to see the content you display on hover too. -- Neil Drumm http://delocalizedham.com/

Apologies if this has become off-topic for most... On Tuesday 22 August 2006 11:50, Morbus Iff wrote:

In my particular case, the information on hover was of little import - it was a foreshadowing of what they'd be clicking on, such that there was no loss of inaccessibility - someone could just click the link and get (even more) of what the hover was actually talking about.

Personally, that's what I'd use a hovering tooltip for. But I've had clients ask for much more. Some people like a big floating box with lots of HTML. For my own sites I plan to use what I call a 'clicktip'. To toogle it's visiblilty, the user clicks. And it appears exactly where it is placed within the document. It's like a collapsible fieldset, but you can put them anywhere (not just forms) and style them appropriately.

With that said, of the four options I described, you probably most like the the <div> one with IDs. But where would you put those? Putting them right next to the text ruins readability of the main text, and putting them at the end of the page removes any sort of context.

I'm writing my script to support either. Let's say I have a term that needs a definition. I want to link the hovertip this way... <p>blah blah <span hovertip="termdefinition">term</span> blah blah blah blah blah <span hovertip="termdefinition">term (again)</span> blah blah</p> <div class="hovertip" id="termdefinition">the definition goes here.</div> .. so I get the definition everywhere the term appears. The definition div can be anywhere on the page. -Dave

On Aug 22, 2006, at 14:50 , Morbus Iff wrote:

...

...

* JS events, such like <p onmouseover="tooltip_on('you're hovering!')" onmouseout="tooltip_off()">Whee!</p>. I tend to like this one (and implemented it in my game.module, not via jQuery though) the most because it a) doesn't pollute the DOM, b) don't harm screen readers, Screen readers need to see the content you display on hover too.

In my particular case, the information on hover was of little import - it was a foreshadowing of what they'd be clicking on, such that there was no loss of inaccessibility - someone could just click the link and get (even more) of what the hover was actually talking about.

With that said, of the four options I described, you probably most like the the <div> one with IDs. But where would you put those? Putting them right next to the text ruins readability of the main text, and putting them at the end of the page removes any sort of context.

I'm a little late to this party, but I have to chime in to support a nested DOM element solution. There is no negative effect on screen readers. In fact, screen readers will likely not read display:none text anyway[1], so unless you specifically want the text read the behavior is probably already what you want. To make sure, you can add speak:none to suppress speech or speak:normal to enforce it. These rules can be in a separate media="speech" stylesheet if you wish. The benefits of the nested model are the same as when designing any document structure for CSS layout. Maximizing the usefulness of the cascade is a win for both CSS and jQuery, and for jQuery we also want to exploit the implicit iteration as much as possible. It seems to me the nicest model would be something like: <div class="link-with-tip"> <a href="foo">bar</a> <div class="tip">Arbitrary HTML to display on hover</div> </div> This model avoids text munging to match IDs with each other, which harms readability of the code to some extent. Now we can do $(document).ready(function() { $('div.link-with-tip a').hover(function() { $(this).parent().find('div.tip').show(); },function() { $(this).parent().find('div.tip').hide(); }); }); And done. To my eyes this is nicer than anything involving a substr() call. [1] http://css-discuss.incutio.com/?page=ScreenreaderVisibility -- Jonathan Chaffer Algorithm Alchemist, Structure Interactive (616) 364-7423 http://www.structureinteractive.com/

On Aug 24, 2006, at 9:06 , Morbus Iff wrote:

...

exploit the implicit iteration as much as possible. It seems to me the nicest model would be something like: <div class="link-with-tip"> <a href="foo">bar</a> <div class="tip">Arbitrary HTML to display on hover</div> </div>

This model seems to fall down under anything but demonstration purposes:

<p>This is a paragraph <a href="">which can't contain a div</a></p> <div>DOM model is now broken since div can't go in p.</div>

To which you'd respond:

<div class="link-with-tip"> <p>This is a paragraph <a href="">which can't contain a div</a></p> <div>DOM model is now fixed.</div> </div>

I wouldn't respond that way, I'd respond "s/div/span/g". The span.link-with-tip should include only the anchor and tip. I will make the concession that if the tip has particularly complex HTML then this method becomes cumbersome/intractable.

On Thursday 24 August 2006 06:06, Morbus Iff wrote:

...

exploit the implicit iteration as much as possible. It seems to me the nicest model would be something like:

<div class="link-with-tip"> <a href="foo">bar</a> <div class="tip">Arbitrary HTML to display on hover</div> </div>

This model seems to fall down under anything but demonstration purposes:

<p>This is a paragraph <a href="">which can't contain a div</a></p> <div>DOM model is now broken since div can't go in p.</div>

To which you'd respond:

<div class="link-with-tip"> <p>This is a paragraph <a href="">which can't contain a div</a></p> <div>DOM model is now fixed.</div> </div>

I would have responded: <p>This is a paragraph <span class="link-with-tip"> <a href="">which can't contain a div</a> <span class="tip">This is based on element class.</span> </span> </p> In other words, use the classes, not the element types to control the tips. I'll be testing my tooltip script to make sure this works. -Dave