- From: Andrew Betts <notifications@github.com>
- Date: Tue, 05 Sep 2017 15:11:02 +0000 (UTC)
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
Received on Tuesday, 5 September 2017 15:11:29 UTC
A few thoughts from me informed by recent TAG call: * I'm slightly concerned that "people" (ie, me) will use Server-Timing as a mechanism to communicate arbitrary page related metadata from server (or middlebox) to client, because it is the only HTTP header, to my knowledge, that is accessible from JavaScript (for a page navigation), without side effects. * It is a shame that there is no start time on a timing metric, so it is impossible to describe the concurrency or blocking of tasks in relation to one another, possibly the most valuable use-case for this header. As an alternative we could have some kind of declared relationship between the metrics to indicate that they block. * There's a [separate discussion of syntax](https://github.com/w3c/server-timing/issues/12#issuecomment-309138002), my preference would be to drop the semicolon delimiter idea. I can't see the need for a millisecond duration AND a description as a common requirement, so you're often going to get `key1=;val, key2=;val2` which is weird and looks wrong. My preference would be to interpret the value as a time period if it includes a unit, CSS style. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3ctag/design-reviews/issues/188#issuecomment-327206532
Received on Tuesday, 5 September 2017 15:11:29 UTC