This is likely to be somewhere between "horribly hard to define due to tons
> of corner cases" and "incompatible with current browser architecture",
> probably closer to the later.
>
>
I thought that standards are writing for developers, not for browser
architecture compatibility... I don't understand how animation appears in
CSS with this approach... It was "horribly hard to define due to tons of
corner cases" and "incompatible with current browser architecture"... :D
> For example, if we just look at progressive rendering with the way I
> understand your earlier definition of frame ("statement when browser has
> finished scrolling tick or layout rearrangement"), it means we would have
> non deterministic layout.
>
Animation works as a sequence of frames. Each frame has static statement of
layout, dom, all things are painted. Then browser calculates new values,
applies it, renders it. So, we will have new frame at the end of all
processes. Let's build our logic on this definitions.
Frame -> animation -> rendering -> Frame* -> :in-view() -> rendering ->
Frame**
> "body:in-view() {display: none}" may or may not result in an empty
> document, depending on whether the UA got all its CSS and HTML from the
> network in one go and did the whole layout in one "frame", or got some bits
> of it later and did it in two "frames" (or 3, or 12). That's terrible.
>
in-view() has 3 parameters. ;)
Initial frame is a statement when all content are loaded and painted. Is it
clear definition? Then we can use (for example) animation frames or user
interaction for next style changing.
>
> I don't think there is a definition of "frame" that will work.
>
>
Let's find something else. :)
Received on Wednesday, 7 December 2016 10:41:52 UTC