Re: [css-fonts] font prefetch hints

On Thu, Oct 30, 2014 at 11:56 AM, Zack Weinberg <zackw@panix.com> wrote:
> 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.)

Is that really significant?  The difference between "naively spot
preloads during parsing" and "figure out preloads after stylesheets
have loaded" is, at worst, a second or so.  The use-case you presented
was for things that aren't used on the current page, but that you'd
like to get ready for later page loads.  If it's for dynamic content
within the same page, if it shows up within the first second or so it
won't benefit that much from a preload hint; if it shows up at some
later point in time, the difference in preload start time won't really
be significant.

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

Need to know what the resource type is, at least, so we can know how
to parse it and which cache to put it in.

> ... 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.

Same comments as above - I'm not sure this sort of restriction
actually gives us much.

>>>  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.

Sure, but do we really need to call out "definitely don't preload
this" as a case?  Do you believe that the heuristics will
false-positive often enough to actually need this kind of control?

>> 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.

Oh, sure, that's true.  I'm confused about your request, then - the
only other descriptor requested recently is font-rendering, which does
have a parallel property proposed.

~TJ

Received on Thursday, 30 October 2014 19:08:38 UTC