eval()

There has been some talk of using the value of attributes as the value
of another attributes and similar such things, and I think the best way
to do this would be by means of an eval() function, since, for example,
attr(size)+1px clearly isn't right, and (attr(size)+1)px isn't really
satisfactory. Therefore I propose that eval() be used wherever an author
wishes to mainpulate a value or get the value of a property to use as
the value of another property. For example, HR {height:
eval(attr(size)-1)px}. This is preferable to what is proposed, namely
only allowing this on an arbitrary subset of properties (viz. access-key
and tab-index), and has greater flexibility.

On a separate but related subject, I think there should be a change to
the attr() function. At present, given, for example, <p>Hello, then P
{content: attr(title)} would result in P being rendered as empty, but I
suggest that when attr() returns a null value, the declaration is
invalid and should be ignored. The reason for this is to allow things
like:

A[href]:tooltip:hover {visibility: visible;
content: attr(href);
content: attr(title)}

, which provides a tooltip with the value of 'title' as its content, but
if that returns null, then the href would be the value.

Similarly:

IMG:placeholder {content: attr(href);
content: attr(alt)}

This requires that UAs distinguish between:

<TABLE summary="">

and 
<TABLE>

Note incidentally the alternative way of doing tooltips: 

1. I rejected using :before and :after because it seemed inappropriate
and also because it meant that these couldn't be used for other
purposes.
2. I rejected the position: relative method because it was too
complicated

The way that :tooltip works is that every element is considered to have
a tooltip, but that tooltip is invisible and has as content an empty
string, which means therefore that to make it visible one must use
visibility: visible. This has a considerable number of advantages:

1. One need not specify the colours, fonts, backgrounds, borders and so
on of tooltips, since these would already be set; however, one still has
means to change them.
2. One need not specify the height, width, display value, position,
etc., of tooltips because they are set by default.

Therefore only two declarations (visibility: visible and content) are
required to create a tooltip instead of a dozen or more (border,
background, colour, font, [(position, top, left) or (display: tooltip)],
content, padding, width, height).

As regards the properties that should be valid on tooltips, I would
suggest that the following properties should apply:

1. Text properties
2. Border properties
3. Font properties
4. Background properties, except background-attachment
5. Padding properties
6. Clip
7. Overflow
8. Color
9. Content
10. Visibility
11. Direction
12. Height, max-height and min-height
13. Width, max-width and min-width
14. Outline properties
15. Quotes
16. Unicode-bidi
17. Display

_Not_ position - position: tooltip is the only meaningful value on
:tooltip, and the :tooltip pseudo-element itself implies the 'position:
tooltip', since it does not make sense to introduce this value for
general use, as it would only be useful in this context.

The way that the properties would work is by means of this (or similar)
in the UA style sheet:

*:tooltip {visibility: hidden;
color: info;
background: info;
font: infotext;
display: inline-block;
/* position: tooltip is implied by the :tooltip */
max-width: 50%; /* This is UA-specific, but representative of the
typical rendering, and therefore this will vary between UAs; in
addition, the containing block of tooltips is the viewport, and
therefore percentages are related to its dimensions */
box-sizing: border-box; /* ? - there is no precedent for setting tooltip
properties so I don't know about this */
border: infoborder;
overflow: expand; /* If the tooltip contains a word that is longer than
max-width (or width if it is set), the tooltip should expand to fit */
padding: 1px /* UA-specific */}
/* width: auto and height: auto are the initial values, and therefore
are implied */

And for HTML:

[title]:hover:tooltip {visibility: visible;
content: attr(title)}

This only leaves the following rendering issues in HTML:

1. frames: using the syntax that HTML allows and resizing that affects
the size of one frame when the other is resized.
2. BASEFONT - one can't get the attribute value of another element
3. Multi-lengths

(probably some others that I can't think of offhand)
------------------------------------------------------------------
Please visit RichInStyle com.
If it's style-related, it's here. And now:
MySite v2 - offer your users a choice between predefined styles or
they can create their own, with control over font sizes, colors,
background colors, background images, borders, margins, line heights,
add a custom style rule, font faces, link underlining, etc.

Download now FREE: http://richinstyle.com/free/mysite.html.