On 12/30/12 10:58 AM, David Bruant wrote:
I'm not enough familiar with CSSOM getters and CSS transitions, sorry;
is it a spec requirement or an observation shared for all current
implementations?
The spec requirement is that transitions start when computed values change.
The spec does not define _when_ computed values change.
However, determining layout requires that styles be recomputed first, so
it would be a tough argument to make that you're returning the value of
a layout property like offsetWidth but haven't updated your computed
values. So in practice I believe this is in fact a spec requirement.
But further, it's behavior shared by implementations and there is
content depending on it.
The criterion could be whether getting or setting has an
effect observable outside of the object the property is on. So if the
CSSOM spec says some getters have a side-effect on CSS transitions
starting time, let these be accessors.
OK. But then what problem(s) are we solving by having some properties
still be accessors but having others described via proxy semantics?
That seems like a strict increase in complexity over doing one or the
other...
That'd be a spec bug, but one that is easy to make when unfamiliar with
proxies I agree.
So your proposal here would be for getOwnPropertyDescriptor to return a
descriptor with no value (unlike the get trap)?
The solution here would be to define the set trap as first performing a
check on whether the property is a readonly one.
There are lots of things that getOwnPropertyDescriptor but are not the
set trap.
I feel that for the vast majority of cases in the web platform, WebIDL
is the only place that'll need to use proxies (exception for live
objects and WindowProxy and probably a handful of other weirdnesses).
I don't understand this statement... Right now live objects are defined
in WebIDL in terms of things like [[GetOwnProperty]] and whatnot; they
can then be implemented as proxies or equivalent by implementations...
In the upcoming weeks, I'll take a stab at drafting what WebIDL would
look like if defining attributes as own data properties using proxies.
We'll see how it goes.
OK. I obviously can't tell you what to spend or not spend your time on. ;)
I haven't been in the web platform for long enough, but I feel now more
people read the specs, catch bugs, discuss, write test cases than
before.
To some extent. The specs are huge, the bugs in them and in UAs are
often subtle, and the test cases are woefully incomplete.
One of the great testing success stories of recent years (CSS 2.1) has
test coverage that I'd rate somewhere between "middling" and "crappy".
It's way better than anything before, but combinatorial explosion makes
things _really_ hard to test.
Added to that, far too many implementors either don't think critically
about the spec as they implement it or don't bother sending in feedback
when they run into spec bugs that they then don't propagate to their
code. Far too often I've seen cases in which a spec dozens to hundreds
of pages long claims to have an implementation or three with not a
single word of feedback sent in the process. How likely that is to
happen, you decide (but again in my experience it's trivial to find
glaring problems in such specs).
I wonder if standardization efforts can "just fail" as much as
they did in the past.
I'm not sure we can get failures (by today's standards, no pun intended)
of the magnitude of HTML4 or CSS2, but it's quite possible to fail.
Right now the only thing standing between many specs and failure is the
hope that _some_ implementor will actually bother to send feedback on
the problems, which as I said above they have a tendency to fail to do.
There are several people, maybe as many as a dozen or two, that I can
name that send consistent feedback on web specs as they implement them.
How many people do you think are working on implementing web specs at
Mozilla, Microsoft, Google, Apple, and Opera? I can assure you it's
more than two dozen all told.
-Boris
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
