Re: Tests with embedding, including of font resource with a @font-face rule

Le 2017-02-17 12:07, Geoffrey Sneddon a écrit :
> As a general aside, given we're at a point where merging csswg-test
> into web-platform-tests is a matter of weeks in all probability,
> policy things like this are probably best done on public-test-infra
> (which I think has in theory included CSS all along? I have no real
> idea).
> On Thu, Feb 16, 2017 at 10:22 PM, Gérard Talbot
> <> wrote:
>> We have a bunch of tests, scattered in several test suites, which 
>> require a
>> special, unique font (besides Ahem font) to use, to declare in such 
>> tests. I
>> am trying to find the best way to declare @font-face in those tests. 
>> Right
>> now, there is no guidelines that we are all following. I would like 
>> this to
>> be standardized, normalized. We could therefore remove, drop use of 
>> the font
>> flag (I can not remember if the font flag is supposed to be removed 
>> anyway
>> from now on).
> The font flag wasn't supposed to die (there are tests that can't use
> @font-face, especially some of those testing font selection).
>> Is declaring the .woff equivalent sufficient? I do not think so, 
>> furthermore
>> if the .woff filesize is rather big.
> I think WOFF suffices; I don't think anyone is likely to run the CSS
> tests on anything that doesn't support WOFF at this point? (The policy
> in general for web-platform-tests has been to stick to features that
> the latest release of every major browser supports; WOFF is *well*
> beyond that point, having reached it in 2011.)

Okay. AntennaHouse 6.4 and Prince 11 claim they support WOFF standard.

>> Here's what I propose, in a real test
>> , involving a font face that we are already using in a dozen tests:
>>   @font-face
>>     {
>>       font-family: "M+ 1p";
>>       src: local("M+ 1p") , /* first try to use locally available and
>> installed M+ 1p font */
>>       url("support/mplus-1p-regular.woff") format("woff") , /* 
>> otherwise
>> download its woff equivalent */
>>       url("support/mplus-1p-regular.ttf") format ("truetype") ; /* 
>> otherwise
>> use its TrueType font */
>>       /* filesize of mplus-1p-regular.woff: 803300 bytes (784.5 
>> KiloBytes)
>> */
>>       /* filesize of mplus-1p-regular.ttf : 1571848 bytes (1.5 
>> MegaBytes) */
>>       /*
>>       mplus-1p-regular.ttf can be downloaded at, from
>>       */
>>     }
>> So, local would be first, .woff would be 2nd and then the font itself. 
>> The
>> order between 2nd and 3rd is an ascending filesize order. And a link 
>> to
>> download and install the font would be provided in a /* comment */ : 
>> that
>> way, we would encourage fetching of locally installed font, which is 
>> always
>> faster.
>> I am looking for comments, feedback here.
> One problem (and this isn't hypothetical: this caused problems in
> Opera's CI years ago) is different versions of fonts causing issues,
> and that is inherently worse with locally installed fonts. (The main
> thing I remember causing problems were slight changes to metrics,
> FWIW; obviously rare, but it does happen.) As such, I have a
> preference *against* including local fallbacks.


> I also don't think we need a link to download the font: we should have
> the specific version of the font we rely on in the repository

Thank you for your feedback on this issue. I have adjusted a few tests 
according to your comments.

With regards to having the specific version of the font on which we rely 
and with regards to mplus-1p-regular.woff:

> (which
> obviously means it has been licensed such that we can redistribute it,
> but we shouldn't be relying on any non-free licenses anyway).
> This also reminds me that the build system means we can't just link to
> everything in "/font" but need relative URLs in support, which means
> we need fonts duplicated all over the place, ergh.

There are different versions of the Ahem font in the repository... but, 
right now, this is not causing any problems.

Test Format Guidelines

Test Style Guidelines

Test Templates

CSS Naming Guidelines

Test Review Checklist

CSS Metadata

Received on Sunday, 19 February 2017 00:33:28 UTC