Re: Tests for new shadow DOM API

[河内 隆仁]

Hi,

Thanks Ryosuke for starting contributing tests to shadow-dom/ and moving
the old ones under untriaged/.

I would like to continue triaging old tests in untriaged/ directory.
The general rule of thumb (for me) for working on them are:

- Remove tests that test out-of-date features (e.g. attributes that is
removed from spec)
- If the test is doing something valid, carefully examine what is tested
and whether it is not
  duplicate of other tests (outside of untriaged/*). If it is a duplicate,
remove it.
- If the test passes above 2 bullets, then rewrite so that the test runs in
more sane way and
  submit for review, and remove the original once the new test lands.

And I'm happy to review any new or triaged test, please add @TakayoshiKochi
in your pull request.

Thank you!

On Fri, Sep 4, 2015 at 5:13 PM, Ms2ger  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi Ryosuke,
>
> On 09/03/2015 10:06 PM, Ryosuke Niwa wrote:
> > Hi all,
> >
> > Where should we put tests for new shadow DOM API?  It looks like
> > the tests in
> > https://github.com/w3c/web-platform-tests/tree/master/shadow-dom/shado
> w-trees
> >
> >
>  - -trees>
> > are mostly obsolete and I'm not certain how many of them could be
> > adopted for the new API.
> >
> > Would it make sense to rename this old one to
> > "deprecated-shadow-don" and then create a new top-level directory
> > "shadow-dom"?  We can then migrate or write new tests there.
> >
>
> If you believe a significant fraction of the existing tests is out of
> date with the specification, I'd suggest moving them all into
> `shadow-dom/untriaged` and adding a `README` file there to explain the
> situation.
>
> HTH
> Ms2ger
> -BEGIN PGP SIGNATURE-
>
> iQEcBAEBAgAGBQJV6VK2AAoJEOXgvIL+s8n2asAIAJEXWz8vyAGqPI6BFNNYQYXb
> 4i/knAt1/GEeiUOzjzbwJG38NRtGr9cZO0MCYW8S13gzzqKbtdCWwF0FbBvzvMR1
> OHqkdR7tLo/aLV00GQzrLSgNDnqQ2M1+P/lq5QUU53DsbpTM2Ih0P1pjDsvaLs75
> TZFggKN8UKhvjQrKuL1wjtCSKrdkemXKbdl2FfWgXj1hsUklNwKSmTd8Hr+g6FaS
> eK+l74G7xhxbqwKvIo8MgcLjwNYJG5hPJWoP6T9b9rBnE4W+x8J9ojcVVMuCWz/4
> 0GOGvgyRXwobDcKsAcBomNhTruOC8pqNVn6e84oScOyNf8QRP6GDjyj/a2jd71I=
> =Z5oS
> -END PGP SIGNATURE-
>
>


-- 
Takayoshi Kochi

Re: [web-animations] Should computedTiming return a live object?

[Anne van Kesteren]

On Thu, Oct 1, 2015 at 4:23 AM, Brian Birtles  wrote:
> I'd like to change this API, probably to one of the following (listed
> roughly in order of preference). I wonder if anyone else has an opinion
> on this?

I'm curious as to what this maps to closer to the metal. That can help
inform a reasonable low-level API. The other thing I'm wondering about
is whether it's still reasonably to introduce new synchronous layout
getters/setters. I was hoping we'd move away from that at some point.


-- 
https://annevankesteren.nl/

RE: [web-animations] Should computedTiming return a live object?

[Domenic Denicola]

Anne's questions are interesting and worth answering. For example, which of 
these properties are typically held in memory already, versus which would 
require some kind of computation---the former usually are better as properties, 
and the latter as methods.

But setting aside the deeper issues he alludes to, my gut instinct is that 
option 1 is pretty reasonable.