Re: [CSS3] transition effects -why not use proper scripting backed up by the correct DOM methods?

The things mentioned in this thread for transition effects are very  
strictly a scripting job. Drawing a line between basic required behaviour  
for accessibility (:hover), and eye-candy effects (opacity fade on hover)  
is actually very easy.

I do understand the problem of having to put style related information  
right in the javascript, but these things are too heavy for CSS, IMHO:  
just because we don't want to update two files (css+javascript) instead of  
one shouldn't mean CSS should hold the burden of these behaviours.  
However, I do understand the problem of having to declare style in  

What we actually need is standardized methods for reading CSS values based  
on classes/id's right in Javascript using DOM methods, e.g. a mock-up dom  
method for reading a class value
myElementsBorderWidth =  

Than with this standardized information, any transition effect can easily  
be programmed, the possibilities are endless. Thinking of no scriptable  
environments, following philosophy is just fine:
.noscripting a:hover {
Where the .noscripting will be removed by our 'behaviour layer' when first  
executed from our,e.g. body element, again, a little task easily handled  
by the programmer.

The latest in stylesheet reading is simply not anything near practical,  
see it at.

In conclusion, I don't think we need anything more than :hover like simple  
behaviours for style sheets. They need to be there for accessibility  
reasons, for letting user know he is doing something with the element  
being hovered/focused in the most basic sense. However, anything one step  
more complex than that should better be done by scripting. That said, the  
need to read styles from classes using DOM methods is something most badly  

I will later be working on some methods for animation using a method I'll  
call "class morphing", which will probably require standards abiding  
browsers. I just need some browser inconsistencies fixed before I can  
share it with the crowd (like Opera sadly returning offset sizes instead  
of declared style sizes when getComputedStyle is being used:

Received on Tuesday, 9 May 2006 19:26:08 UTC