Re: JSON imports?

[Glen Huang]

Didn't know about this trick. Thanks.

But I guess you have to make sure the file being prefetched must have a long 
cache time set in the http header? Otherwise when it's fetched, the file is 
going to be downloaded again?

What if you don't have control over the json file's http header?

> On Apr 18, 2015, at 10:12 AM, Elliott Sprehn  wrote:
> 
>  does that for you.
> 
> On Apr 17, 2015 7:08 PM, "Glen Huang"  > wrote:
> One benefit is that browsers can start downloading it asap, instead of 
> waiting util the fetch code is executed (which could itself be in a separate 
> file).
> 
>> On Apr 18, 2015, at 8:41 AM, Elliott Sprehn > > wrote:
>> 
>> 
>> 
>> On Fri, Apr 17, 2015 at 6:33 AM, Glen Huang > > wrote:
>> Basic feature like this shouldn't rely on a custom solution. However, it 
>> does mean that if browsers implement this, it's easily polyfillable.
>> 
>> What does this get you over fetch() ? Imports run scripts and enforce 
>> ordering an deduplication. Importing JSON doesn't really make much sense.
>> 
>> 
>>> On Apr 17, 2015, at 9:23 PM, Wilson Page >> > wrote:
>>> 
>>> Sounds like something you could write yourself with a custom-elements. Yay 
>>> extensible web :)
>>> 
>>> On Fri, Apr 17, 2015 at 1:32 PM, Matthew Robb >> > wrote:
>>> I like the idea of this. It reminds me of polymer's core-ajax component.
>>> 
>>> On Apr 16, 2015 11:39 PM, "Glen Huang" >> > wrote:
>>> Inspired by HTML imports, can we add JSON imports too?
>>> 
>>> ```html
>>> 
>>> 
>>> { "foo": "bar" }
>>> 
>>> ```
>>> 
>>> ```js
>>> document.getElementById("foo").json // or whatever
>>> document.getElementById("bar").json
>>> ```
>>> 
>>> 
>> 
>> 
> 

[admin] Updating our /TR stylesheets

[Arthur Barstow]

Below is an announcement about a project "to provide a modern design to 
future technical reports published by the W3C" i.e. updating the 
stylessheet used for Technical Report 
.


If you have any feedback, please use 
 (and do not reply to this thread).


 Forwarded Message 
Subject: Updating our /TR stylesheets
Date: Thu, 16 Apr 2015 08:53:21 -0400
From: Philippe Le Hegaret 
To: spec-prod 

I'd like to find a path for W3C to update our /TR style sheets and since
we weren't able to do it so far, here is a radical change on how to do so.

First, since it's too complex to change documents that have been
published in the past, we must not try to do it. It has the
simplification that we're breaking the consistency of style between all
W3C documents but it allows us more forward.

Second, we shouldn't assume we need one new style and be done. Instead,
I'd like to enable ourselves to have progressive enhancements over the
years. It will also avoid having everyone trying to squeeze their own
ideas between of a once-in-a-lifetime chance to change the styles. To
make it easier on the tooling, we also need something predictable. So,
I'd like to propose that we allow ourselves to update the /TR style
sheets once per year, on January 1. All documents published in that year
would  have to use the style, ensuring some consistency. Note that it
doesn't imply we have to change the style every year, but it gives us an
opportunity if we want to.

I added a set of guidelines and an hopefully simple process to do it:
  https://github.com/w3c/tr-design/blob/gh-pages/README.md

Feedback is welcome.

Philippe