[whatwg] The IMG element, proposing a CAPTION attribute

----- Original Message ----- 
From: "Matthew Raymond" <mattraymond@earthlink.net>
To: "Andrew Fedoniouk" <news at terrainformatica.com>
Cc: "WHAT WG List" <whatwg at whatwg.org>
Sent: Monday, November 20, 2006 8:30 PM
Subject: Re: [whatwg] The IMG element, proposing a CAPTION attribute


> Andrew Fedoniouk wrote:
>> "...Many platforms/OSes don't have tooltips that support anything
>> other than text...."
>>
>> How task of tooltip creation in HTML is related to what OS is using for
>> tooltips?
>
>   There are W3C guidelines that say that UI in user agents should
> follow the UI conventions of the underlying operating system. This is
> what caused the demise of general focus passing for <label> elements
> (which was specified in HTML 4.01). As of WF2, <label> elements only
> pass focus if labels would normally have focus passing for that kind of
> control in the user's OS. (I called it "an irrational consistency", but
> I was overruled.)
>
> [Snipped plug for your UA.]
>> For formatted tooltips HTMLayout 
>> (http://www.terrainformatica.com/htmlayout)
>> uses 'titleid' attribute that contains id of the element to show as a
>> tooltip.
>>
>> So if you have <span titleid="mytooltip">Bold</span>
>> and <div id="mytooltip">Rich content</div>
>> then that div will be shown as a tooltip for the span.
>>
>> Pretty natural I would say.
>
>   This bares similarities to XUL, actually.
>
>   I don't necessarily have a problem with supporting rich tooltips, but
> my main concern is that there isn't much of a use case for it, it won't
> match UI conventions for most platforms, and fallback is a nightmare.
>
>   With regard to fallback, think of how your above example would render
> if the CSS file failed to load or wasn't supported. It would probably be
> something like this:
>
> | Bold
> |
> | Rich content

<popup> declared invisible by default in the intrinsic style sheet.
In general, tooltip behavior cannot be defined in terms of css. It's shape 
and rendering
attributes - yes, can be defined.

There are many use cases when you need <popup>'s if we are speaking about
Web Applications and not just another version of html/css.

E.g. the engine allows to define following:
<select id="color-selector">
   <popup>
      <table>
         <tr>
             <td role="option" value="#00FF00">...
             <td role="option" value="#0000FF">...
         </tr>
      </table>
  </popup>
</select>

to be able to define something like this:
http://www.terrainformatica.com/sciter/screenshots/color-chooser.png
or this:
http://www.terrainformatica.com/htmlayout/images/selects3.jpg

I mean that popup elements are already there (tooltips, selects, menus)
and it is better to think of how to define them in general manner.
Otherwise we will get again tons of ugly attempts to reproduce them using
scripts.

>
>   Worse, the tooltip could appear in some distant part of the document
> next to a bunch of other tooltips because they were all put in a group
> in the document structure.

As I said - it cannot. Interpretation of the <popup> is a built-in 
functionality
of the UA.  Either you have them either not. No other option.

Moreover: you cannot style their position through CSS.
css::position simply does not work here. The only thing you can do
with popups is to define their placement - on what side of the owner element
they will appear.

We've tested heavily various <popup> use cases for the needs of modern UI
and it seems  that such placement attribute is really enough for popups 
positioning.

We've also discovered that having <popup> as a separate element
(not contained in, say, <img> as someone propsed) is a good thing.

Think about grid (table representing some data set).  Rows
there share the same context menu which is again the <popup> in our case.

>
>> For various popup purposes I have added <popup> element that is
>> display:none normally and has better semantic meaning so
>> we use <popup>s for such tooltips in almost all cases.
>
>   Well, we may have to look into markup that doesn't have fallback, but
> I'm not sure if I'm quite there yet.
>

Take a look in any "AJAX toolkit" and you will find <popup>s implemented
in some way. Ugly, non-effective but there because of demand of people who
are doing Web Applications now.

Andrew Fedoniouk.
http://terranformatica.com

Received on Monday, 20 November 2006 21:18:56 UTC