W3C Digest. What's new in CSS3. Issue 3

    The CSS3 working group is constantly discussing what will happen in the new standard. Sometimes violent imagination and the desire to do everything as cool as possible leads developers to a dead end.

    Previous part here

    Hidden Object Animation




    It looks like one of the major problems for the CSS3 Animations module will be objects that have display: noneand visibility: hidden.

    In this specification, properties that cannot be iterated are ignored. However, there is an example when this is not worth it. Suppose there is a block, if you assign a class to it hidden, then it should smoothly dissolve and completely get out of the stream. Quite normal behavior that is already present in many JS libraries.

    The code should be like this:
    div {
        display:block;
    }
    div.hidden {
        display:none;
        animation: slide-out 1s 1;
    }
    


    However, if a property is specified display:none, there will be no animation. Well, right, who needs animation for hidden objects?

    But, if you specify here such a code for the animation declaration
    @keyframes slide-out {
        0% { display:block; opacity: 1; }
        100% { display:none; opacity:0; }
    }
    

    and not to ignore non-iterated properties, then we get a completely logical picture. If the browser has no idea what animation is, then it will simply hide the block, since the rule will work display:nonein div.hidden. If there is animation support, then at the beginning of the animation the value of the property will be returned to the block as block, the property has been iterated opacity, and at the end the block will be hidden.

    This is not the first problem with animating hidden objects, and far from the last.

    Will gradients get easier?


    To simplify the syntax of gradients, a new keyword was proposed transparentso that it could be written like this:
     linear-gradient(red, transparent, blue);

    instead
     linear-gradient(red, rgba(255,0,0,0) 50%, rgba(0,0,255,0) 50%, blue);

    For ordinary encoders, the first option, of course, is many times more convenient than the second.

    Where did you click?


    Another very useful suggestion came for 2D and 3D transformation modules . Let's say we have a square. We turn it 45 degrees and get a rhombus. The user clicks on the rhombus, and we need to find out what the coordinates of the click relative to the rhombus, and not the entire window. Here can help out the division into events that were hung on windowand events document' a. In the first case, the behavior remains as before, the coordinates of the click are measured relative to the window, and in the second case they are taken in the relative coordinates of the element. This region is necessary for the further development of these modules, otherwise, for calculations of coordinates, it will be necessary to constantly apply complex calculations in JavaScript.

    That's it this week, thanks for watching!

    Also popular now: