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

----- Original Message ----- 
From: "Emrah BASKAYA" <emrahbaskaya@hesido.com>
To: "www-style.w3.org" <www-style@w3.org>


>
> 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 
> Javascript.

Main motivation:  I (as anyone else) would like to be able to disable/enable
transitions and similar effects in my UA.

Having animations defined in script does not allow me to implement this
feature on UA's level.

I would like for example to be able to stop any transitions (animations)
on GIFs, etc.

E.g. I implemented transition:image as a special case for
animated gif's/mng's. It gives two benefits:
1) allows to switch animation on/off for
particular GIF's, e.g.
   img { transition:none }
   img:hover { transition:image }
2) It makes possible to switch off/on all animation effects for the
whole view.

Andrew Fedoniouk.
http://terrainformatica.com





>
> 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 = 
> document.activeStyle('screen').getClassPropertyValue('myclass','border-width')
>
> 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.
> http://developer.mozilla.org/en/docs/DOM:stylesheet
>
> 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 
> needed.
>
> 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:
> http://www.hesido.com/test/webdesign/getwidth.htm
> ).
> -- 
> Emrah BASKAYA
> www.hesido.com
>

Received on Wednesday, 10 May 2006 05:49:23 UTC