- From: Yoav Weiss <yoav@yoav.ws>
- Date: Fri, 28 Dec 2012 14:58:52 +0100
- To: public-webappsec@w3.org
- Message-ID: <CACj=BEjwgoDHbXuXFRJJ3WB=az6ZTTNpUoijmws7xOrMeiyxnw@mail.gmail.com>
I’m worried regarding the possibility of CSP banning the use of inline styles altogether. Inline style tags are an important part of Web performance best practices. Only recently, Google’s Bryan McQuade wrote about the performance benefits of loading the required initial style sheet as inlined[1]. Forcing the initial style sheet to be external would add at least 2 RTTs to the initial paint, which on a mobile connection can be significant. Furthermore, with the recent addition of `@viewport` to CSS, banning inline styles would prevent the HTMLPreloadScanner/Speculative-parser from evaluating media queries, since viewport modifications may be applied in external CSS that is loaded and parsed *after* the HTMLPreloadScanner have run. Evaluating Media queries in the PreloadScanner is an important part of a markup based responsive image solution (such as the `srcset`[2] or `picture`[3] proposals). The PreloadScanner must address the viewport size and make decisions according to it. Otherwise, it may load the wrong resources, which will negatively impact users both in terms of bandwidth and user exeperience. I have shown (at part of the RICG’s `picture` element prototyping[4]) that MQ evaluation in the PreloadScanner can work, and a responsive images markup (`picture`, `srcset` or any other solution) will be able to preload the required image resources without being blocked waiting for external styles. That will no longer be the case if inline styles are forbidden, and `@viewport` rules will be present in external styles. The implications of that would be a performance penalty, resulting in worse user experience. What I propose is one of the following: * Allow inline style in the page’s `head`, possibly using an `unsafe-inline-in-head` directive - I’m not certain, but I think it’s safe to assume that user-generated content does not get included to the page’s `head`, at least in most cases. - The same directive can probably be beneficial for scripts as well. * Allow a nonce to enable inline styles, even if inline styles are blocked by default. - Since this is permitted for scripts, I don’t see any security downsides here. Please note that a “nonce” based solution will make it impossible for some Web developers to include only certain inline scripts and styles, since they only have control on their site’s client-side code and a random nonce requires server-side logic. A recent survey [5] I ran as part of the RICG showed that ~27% of Web developers have no access to their Web server configuration, let alone to add server-side logic. Therefore, I believe that an `unsafe-inline-in-head` directive may be the best way to go, preferably as a default. Thanks, Yoav Weiss [1]: http://calendar.perfplanet.com/2012/make-your-mobile-pages-render-in-under-one-second/ [2]: http://dev.w3.org/html5/srcset/ [3]: http://picture.responsiveimages.org/ [4]:https://github.com/yoavweiss/RespImg-WebCore [5]: http://freeonlinesurveys.com/app/showpoll.asp?qid=169055&sid=9re1nr8eed91gge169055&new=True
Received on Friday, 28 December 2012 13:59:25 UTC