Hi Dean,
On the run of Safari that was used for this report, the infrastructure
test for ahem was actually passing:
https://wpt.fyi/results/infrastructure/assumptions?sha=67152fdecd&product=chrome[stable]&product=edge[stable]&product=firefox[stable]&product=safari[experimental]
Are you sure that
On Fri, Oct 12, 2018 at 4:07 PM Geoffrey Sneddon wrote:
>
> On Fri, Oct 12, 2018 at 4:23 AM Emilio Cobos Álvarez wrote:
> >
> > On 10/12/18 3:59 AM, Geoffrey Garen wrote:
> > > Honest question: What’s gross about using @font-face?
> > >
> > > It would be lots of test edits. That’s a bummer.
> > >
On Fri, Oct 12, 2018 at 4:23 AM Emilio Cobos Álvarez wrote:
>
> On 10/12/18 3:59 AM, Geoffrey Garen wrote:
> > Honest question: What’s gross about using @font-face?
> >
> > It would be lots of test edits. That’s a bummer.
> >
> > But maybe it’s clearer for the tests to specify the font they want t
On 10/12/18 3:59 AM, Geoffrey Garen wrote:
Honest question: What’s gross about using @font-face?
It would be lots of test edits. That’s a bummer.
But maybe it’s clearer for the tests to specify the font they want to use. It
makes the test self-describing, eliminating the requirement that the u
Honest question: What’s gross about using @font-face?
It would be lots of test edits. That’s a bummer.
But maybe it’s clearer for the tests to specify the font they want to use. It
makes the test self-describing, eliminating the requirement that the user take
a step outside the test to get the
It turns out that many (most?) of the CSS failures are because we no longer
expose user-installed fonts, e.g. Ahem.
Options:
- update lots of tests to load Ahem via @font-face (yuck)
- allow Ahem to be used if installed (weird to special case one font, but
probably ok)
Dean
> On 12 Oct 2018,
Alright, I've written a one-off script [1] to find the Safari-only
failures, and here's the output:
https://gist.github.com/foolip/4d410ce79416bcdce71feb212159a02e
Barring bugs, each of linked tests or one of its subtests should be
failing in Safari Technology Preview and passing in stable version
That filtering capability unfortunately does not yet exist on wpt.fyi
but it's a high priority and actively being worked on:
https://github.com/web-platform-tests/wpt.fyi/issues/201
FWIW, I suspect that these purposes, comparing to the stable versions
of all *other* browsers might be the most usef
Sounds like we should import those tests!
- R. Niwa
On Thu, Oct 4, 2018 at 2:55 PM Chris Dumez wrote:
>
> On Oct 2, 2018, at 3:45 AM, Philip Jägenstedt wrote:
>
> Hi WebKittens,
>
> Fresh off the bots, I'm excited to report more robust Safari results,
> and that Safari WPT pass rates are clear
> On Oct 2, 2018, at 3:45 AM, Philip Jägenstedt wrote:
>
> Hi WebKittens,
>
> Fresh off the bots, I'm excited to report more robust Safari results,
> and that Safari WPT pass rates are clearly improving! Thanks to the
> hard work of Mike Pennisi [1] we now have the first Safari 12 results:
> ht
Thanks for the intriguing data, Philip.
Is there a way to get a list of tests where all other browsers pass but
Safari / WebKit fail?
That would allow us to quickly identify the set of tests we can fix to
improve the interoperability across browsers right away.
- R. Niwa
On Tue, Oct 2, 2018 at
Hi WebKittens,
Fresh off the bots, I'm excited to report more robust Safari results,
and that Safari WPT pass rates are clearly improving! Thanks to the
hard work of Mike Pennisi [1] we now have the first Safari 12 results:
https://wpt.fyi/results/?sha=ee2e69bfb1&product=safari-12.0
This uses the
12 matches
Mail list logo
