Re: [css-fonts] font prefetch hints

On Thu, Oct 30, 2014 at 2:22 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Thu, Oct 30, 2014 at 9:58 AM, Zack Weinberg <zackw@panix.com> wrote:
>>
>> Concrete suggestion: in @font-face,
>>
>>     prefetch: auto | true | false
>>
>> 'auto', the default, means whatever happens now; 'true' means browsers
>> SHOULD load this font immediately
>
> Chrome has been internally talking about something similar for more
> than just @font-face resources.  This definitely sounds like something
> that can generalize easily.
>
> The rough idea right now (which I'm not a huge fan of, but that's
> okay) is something like:
>
> @will-use {
>   .foo;
>   #bar;
> }

I can see where it's nice to have something more general than just for
fonts, but I'm concerned that this still requires you to parse the
entire stylesheet, construct the rule tree, and perform
potentially-nontrivial matches to decide which URLs to preload.
Ideally you would like something that would enable fire-and-forget
speculative loads during parsing.  (See for instance the logic at
https://mxr.mozilla.org/mozilla-central/source/parser/html/nsHtml5TreeBuilderCppSupplement.h#102
which is doing preloads for resources as a side-effect of HTML tree
construction.)

@will-use { url(a); url(b); url(c); } is probably too simplistic and
reduplicative but it would be ideal from the engine's perspective.

... I suppose if @will-use { selector; selector; ... } were
constrained to appear (a) in the same style sheet, and (b) above any
occurrences of style rules for those selectors, then one could in
theory do the selector match during the parsing.  The problem with
*that* is "merely" that I don't think existing style engines are set
up to do anything of the sort - the existing matcher in Firefox
expects to run after parsing is complete and to match against a DOM
tree, not another selector chain, and it's my impression that Webkit's
code is substantially similar.

>>  and 'false' means they SHOULD NOT.
>
> Is this necessary?  The default is already "should not", and I don't
> think anyone wants to change that.

I think I *do* want to change that, if that's really the current
spec-default.  Browsers should be allowed to apply clever
am-I-going-to-need-this heuristics if they want.

> Also, note that CSS doesn't do boolean values; we always end up adding
> more than two options at some point anyway, so we just assume that
> will happen in the future and name the values after their effects
> instead.  Maybe "load-policy: preload | when-used"?

I could go for "load-policy: normal | likely-used | unlikely-used".

>> (Can we stop adding redundant 'font-' prefixes to @font-face
>> descriptors where not necessary for parallel structure with font-*
>> properties in style rules, please?)
>
> Unfortunately, we can't stop now; the inconsistency would be worse
> than the continued verbosity.

?? All the existing font-* descriptors parallel font-* properties in
style rules.  All the existing *non*-font-* descriptors (src:,
unicode-range:) *don't* parallel font-* properties.  That's a simple
bright line and we should stick to it.

zw

Received on Thursday, 30 October 2014 18:56:37 UTC