27303 2014-11-11 18:15:03 +0000 Allow <link> in body 2016-05-25 06:30:47 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED MOVED [good first bug] P2 normal Unsorted 1 igrigorik ian 7raivis crimsteam d ericschurmanpublic gswicke ian jaffathecake mathias mike paul.irish philipj yoav zcorpan contributor oldest_to_newest 114808 0 igrigorik 2014-11-11 18:15:03 +0000 Current spec: "If the rel attribute is used, the element is restricted to the head element." http://www.w3.org/TR/html5/document-metadata.html#the-link-element In practice, developers do not follow above restriction and embed <link>'s in body, and all browsers support this behavior as well. Removing this constraint has multiple benefits: 1) It allows UA's to stop treating this as an error condition and instead use position of <link rel=stylesheet> in the document as an optimization hint to improve rendering performance - e.g. content above <link> should not block first paint, which is similar to how blocking scripts behave today. Some browsers already implement this behavior, and some sites rely on this behavior to improve painting performance; Baidu experience shows that this can deliver significant perf improvement. 2) <link rel=import> is already being used in the wild inside of <body> to import HTML and other content. 3) It makes the spec consistent with what's actually implemented and deployed in the wild (by UAs and site developers). whatwg thread with background discussion: http://lists.w3.org/Archives/Public/public-web-perf/2014Oct/0115.html 114854 1 ian 2014-11-12 19:11:41 +0000 The spec requires browsers to support this, but the reason developers should not do it is that it leads to bad user experiences — flashes of unstyled content, higher lag, and so on. 114856 2 ian 2014-11-12 19:11:53 +0000 *** Bug 27304 has been marked as a duplicate of this bug. *** 114877 3 igrigorik 2014-11-12 23:32:57 +0000 (In reply to Ian 'Hixie' Hickson from comment #1) > The spec requires browsers to support this, but the reason developers should > not do it is that it leads to bad user experiences — flashes of unstyled > content, higher lag, and so on. To the contrary, we have good examples of how relaxing this constraint can help improve performance: 1) http://lists.w3.org/Archives/Public/public-web-perf/2014Oct/0117.html - Baidu data showing significant improvement in time to first paint for a modified Blink engine. 2) At TPAC, IE guys shared examples where large sites (e.g. amazon.com) are explicitly triggering this behavior for IE visitors to achieve faster paints -- this is despite the fact that to trigger this error condition they need to make the page inactive for several hundred milliseconds. Based on discussion at TPAC, we had rough consensus between Blink, IE, and Safari, that this is both reasonable and implementable. In fact, all browsers already support this case, it's just that we treat it as an error condition. Removing this constraint would allow us to optimize for this case and deliver better performance. To be clear, we're not modifying how stylesheets are processed: - all stylesheets apply against the full page, regardless of their position - best practice is to put stylesheets at the top However, (officially) allowing <link> in body would allow us to: - use position of the <link> as a hint for what can or cannot be painted - above strategy can be triggered via opt-in Concretely, consider this example: <html> <style> /* critical css */ </style> <body> <header>...</header> <style rel=stylesheet href="other.css"/> <section>...</section> </body> </html> With above semantics we could paint the <header> content and block painting of later <section> until other.css is available. This pattern would enable much faster rendering of critical content. 114902 4 ian 2014-11-13 23:48:22 +0000 Why is this better than <style scoped>@import url(other.css)</style> ? 114956 5 igrigorik 2014-11-14 23:48:39 +0000 (In reply to Ian 'Hixie' Hickson from comment #4) > Why is this better than <style scoped>@import url(other.css)</style> ? I'd argue that the answer to this doesn't really matter. a) Developers already use <link> in body. b) Browsers support use of <link> in body. c) With imports, <link> in body is a first class use case - e.g. https://github.com/bterlson/ecmascript/blob/master/spec/index.html#L75 So, <link> in body is a fact of life. The spec may not recognize this, but that's how it is used in practice. I'm proposing that we align the spec with how <link> is being used in the wild. And, it just so happens, that (officially) allowing <link> in body has other positive side-effects. For example, for rel=stylesheet it allows the user agent to use its location in the document as a rendering hint (perhaps with an opt-in). Whether and how the UA decides to implement this, is up to them -- we're not changing the semantics of how CSS works. More: http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Nov/0051.html 115149 6 ian 2014-11-19 22:12:03 +0000 Lots of things are used in practice that are non-conforming. They're non-conforming because they're not _good_ practice. I think this is true here. That's why we have scoped style sheets. However, if this is something that's also being discussed by e-mail, then we should probably close this bug and discuss the issue there. I'd rather not split conversations across bugs and e-mail. 115763 7 igrigorik 2014-12-01 21:33:07 +0000 (In reply to Ian 'Hixie' Hickson from comment #6) > Lots of things are used in practice that are non-conforming. They're > non-conforming because they're not _good_ practice. I think this is true > here. That's why we have scoped style sheets. Scoped stylesheets are not supported [1] by any browser except FF and require substantial rewrite of the application if you're actually relying on "scoped" semantics. On the other hand, if you're not relying on scoped semantics, then they offer nothing extra over <link> in body... which is supported today across all browsers. Further, we have concrete examples of where <link> in body *is* a good practice - e.g. amazon.com + IE example, Baidu experience with their modified Blink engine (see comment #3). It is true that you can cause unnecessary reflows by specifying stylesheets later in the document, but that's nothing new: many applications already delay CSS injection [2] and use other tricks to remove (some) CSS from the critical rendering path, and have to guard for this case. For most developers, <link> in head is and will remain to be the right recommendation, but when used correctly <link> in body can be (and already is, for some) a performance best practice. [1] http://caniuse.com/#feat=style-scoped [2] https://github.com/filamentgroup/loadCSS 115847 8 ian 2014-12-03 19:53:01 +0000 If the argument is that we should drop scoped style sheets, then that changes the calculus substantially. Is that what you are arguing? I thought people were pretty firmly convinced that we in fact _do_ want scoped style sheets. It's certainly been one of the more frequent requests I get from developers over the years. 115917 9 zcorpan 2014-12-04 13:44:28 +0000 I think the argument is that scoped stylesheets is an orthogonal feature. For some use cases it makes perfect sense to want to use scoped stylesheets, but for this use case it is a non-goal and actually makes things harder for the author. Consider how authors would typically achieve the desired effect here. First, the author would write all of the CSS for the site. Then, a tool would be used to determine the minimum subset of the full stylesheet required to render the "above the fold", and put the subset in an inline <style> in head. Then, the full stylesheet is external and is inserted in a manner that does not block rendering, e.g. inserted into <head> with a <script> somewhere in <body>, or, as amazon.com does, using <link> somewhere in body. With this workflow, having the full external stylesheet be a scoped stylesheet doesn't really work unless you wrote the CSS with that in mind from the beginning. 116275 10 igrigorik 2014-12-14 00:31:34 +0000 (In reply to Simon Pieters from comment #9) > I think the argument is that scoped stylesheets is an orthogonal feature. > For some use cases it makes perfect sense to want to use scoped stylesheets, > but for this use case it is a non-goal and actually makes things harder for > the author. Yes, exactly. I just did a quick scan [1] of the top 1K Alexa sites: ~10% (95 of 956 sites in the dataset) use <link> in <body>. That's a significant fraction. [1] https://gist.github.com/igrigorik/c0a440d9550ba4a4a4f2 116301 11 zcorpan 2014-12-15 09:47:02 +0000 What are those 95 URLs? 116363 12 1559 igrigorik 2014-12-16 00:57:02 +0000 Created attachment 1559 <link> in <body> (2014-08-15 HA run) 116448 13 ian 2014-12-18 01:32:34 +0000 We should decide if this is to be discussed here or by e-mail. If it's to be discussed here, then please e-mail the list replying to the thread mentioned earlier, pointing to this bug, and saying that you're happier discussing this on the bug. If it's to be discussed on the list, then please close this bug and we'll discuss it on the list. If we're discussing it in bugs, then what would be helpful for me would be a clear statement of the problem(s) we're trying to solve. So far this bug has mostly been about solutions, not problems. 117435 14 igrigorik 2015-01-22 18:25:34 +0000 (In reply to Ian 'Hixie' Hickson from comment #13) > We should decide if this is to be discussed here or by e-mail. If it's to be > discussed here, then please e-mail the list replying to the thread mentioned > earlier, pointing to this bug, and saying that you're happier discussing > this on the bug. If it's to be discussed on the list, then please close this > bug and we'll discuss it on the list. I'll ping the list and point them here. > If we're discussing it in bugs, then what would be helpful for me would be a > clear statement of the problem(s) we're trying to solve. So far this bug has > mostly been about solutions, not problems. Problem: current spec [1] restricts the use of <link rel> to within the <head> element only. I believe this restriction should be removed: a) This policy is not enforced by any browser - i.e. all support <link> outside of <head>. b) This policy is not respected by site authors - e.g. ~10% of top 1K Alexa sites declare stylesheets in body [2]. c) This policy runs counter to the new emerging patterns of using <link> outside of <head> - see [3]. d) This policy restricts browsers from enabling new rendering optimizations. We have real-world experience showing that removing this constraint can help deliver faster page rendering and improve user experience (e.g. amazon.com is using this [4] to deliver faster rendering to IE users), and Baidu experiments [5] with modified Blink engine back this as well. In short, the current constraint does not match what's implemented by browsers, how <link> is used by site authors, and restricts both groups from developing and deploying new patterns that can improve both the developer and user experience (e.g. faster page rendering). [1] http://www.w3.org/TR/html5/document-metadata.html#the-link-element [2] https://www.w3.org/Bugs/Public/show_bug.cgi?id=27303#c10 [3] https://lists.w3.org/Archives/Public/public-whatwg-archive/2014Nov/0017.html [4] https://www.w3.org/Bugs/Public/show_bug.cgi?id=27303#c3 [5] https://lists.w3.org/Archives/Public/public-web-perf/2014Oct/0117.html 117456 15 zcorpan 2015-01-23 10:00:58 +0000 (In reply to Ilya Grigorik from comment #14) > I believe this restriction should be removed: > > a) This policy is not enforced by any browser - i.e. all support <link> > outside of <head>. I think this is not a valid argument. It is a consideration to take into account if we want to allow this for other reasons, i.e. "is it backwards compatible?". Authoring conformance requirements are primarily about pointing out authoring mistakes, whether it "works" in browsers or not. There are plenty of things that work in browsers but are nonetheless invalid (e.g. misnested tags). > b) This policy is not respected by site authors - e.g. ~10% of top 1K Alexa > sites declare stylesheets in body [2]. I think this is not a valid argument without analyzing how they use it. Are they mistakes? Are they using it deliberatly for better loading performance? If almost all of them use it by mistake, that is an argument for keeping the status quo. > c) This policy runs counter to the new emerging patterns of using <link> > outside of <head> - see [3]. I think <link rel=import> is a pretty different beast and shouldn't influence requirements on <link rel=stylesheet>. > d) This policy restricts browsers from enabling new rendering optimizations. No it doesn't. We're discussing authoring conformance, it doesn't affect implementations at all. Browsers can optimize this exactly the same regardless. (We could specify how the optimization should work in the spec, but this bug doesn't ask for that.) > We have real-world experience showing that removing this constraint can help > deliver faster page rendering and improve user experience (e.g. amazon.com > is using this [4] to deliver faster rendering to IE users), and Baidu > experiments [5] with modified Blink engine back this as well. *This* is a valid argument. Please focus on this part. :-) > In short, the current constraint does not match what's implemented by > browsers, how <link> is used by site authors, and restricts both groups from > developing and deploying new patterns that can improve both the developer > and user experience (e.g. faster page rendering). > > [1] http://www.w3.org/TR/html5/document-metadata.html#the-link-element > [2] https://www.w3.org/Bugs/Public/show_bug.cgi?id=27303#c10 > [3] > https://lists.w3.org/Archives/Public/public-whatwg-archive/2014Nov/0017.html > [4] https://www.w3.org/Bugs/Public/show_bug.cgi?id=27303#c3 > [5] https://lists.w3.org/Archives/Public/public-web-perf/2014Oct/0117.html 117457 16 zcorpan 2015-01-23 10:30:38 +0000 (In reply to Ilya Grigorik from comment #12) > Created attachment 1559 [details] > <link> in <body> (2014-08-15 HA run) Looking at the first 20, none of them use it for better page loading perf AFAICT. They're not mistakes, either, though, but appear to be how they assembly their pages from several templates or components and don't want to buffer everything just to put a <link> in <head> instead of in <body>. http://www.yandex.com.tr/ http://www.marketwatch.com/ http://www.olx.in/ http://www.semrush.com/ Doesn't appear to use link in body now. http://www.ebay.co/ http://www.petdoof.com/ http://www.hubspot.com/ http://www.kaskus.co.id/ http://www.telegraph.co.uk/ http://www.ebay.fr/ http://www.intuit.com/ http://www.alarabiya.net/ http://www.clickbank.com/ http://www.ok.ru/ http://www.one.lv/ http://www.ero-advertising.com/ http://www.4shared.com/ http://www.dreamstime.com/ http://www.bycontext.com/ Doesn't appear to use it for better page perf, more like a stylesheet for a particular component. There is external CSS in <head> also. http://www.quikr.com/ Doesn't appear to use link in body now. However it does insert a stylesheet <link> with script for an ad. 117460 17 igrigorik 2015-01-23 19:13:21 +0000 (In reply to Simon Pieters from comment #15) > (In reply to Ilya Grigorik from comment #14) > > I believe this restriction should be removed: Re, a & b: fair enough. > > c) This policy runs counter to the new emerging patterns of using <link> > > outside of <head> - see [3]. > > I think <link rel=import> is a pretty different beast and shouldn't > influence requirements on <link rel=stylesheet>. Perhaps. FWIW, current spec makes no such distinction and disallows any <link> with rel attribute outside of <head>. That said, this is probably an entirely different thread/bug. > > d) This policy restricts browsers from enabling new rendering optimizations. > > No it doesn't. We're discussing authoring conformance, it doesn't affect > implementations at all. Browsers can optimize this exactly the same > regardless. (We could specify how the optimization should work in the spec, > but this bug doesn't ask for that.) This seems at odds? First we say any <link rel=stylesheet> outside of head is invalid, but then we would document an optimization strategy that allows exactly this? I'm OK if we can manage this, but it feels odd. > > We have real-world experience showing that removing this constraint can help > > deliver faster page rendering and improve user experience (e.g. amazon.com > > is using this [4] to deliver faster rendering to IE users), and Baidu > > experiments [5] with modified Blink engine back this as well. > > *This* is a valid argument. Please focus on this part. :-) Ok. The specific behavior and optimization we're interested in is to allow partial page rendering that does not block on the full CSSOM. Specifically, we would like to allow the position of the <link> element in the DOM to inform the UA about which parts of the page may be painted without blocking on remaining CSS that has not yet been downloaded and/or processed. In effect, this behavior would mimic <script> element which does not block rendering of the content above it. This can be an opt-in behavior for sites that choose to leverage this optimization. --- CSS bytesize for top Alexa sites (desktop and mobile) [1]: type median seventy_fifth ninetieth desktop 29070 65255 138816 mobile 21458 51318 115983 Median CSS size on both desktop and mobile exceeds the initial congestion window, which means that today the browser has to hold painting page content for at least 2 roundtrips. For sites in 75th and 90th percentiles this incurs 4~5+ RTTs, which can easily translate into seconds on a high-RTT connection. By allowing the above optimization the site can unblock the browser from painting partial page content: we would (a) only need partial HTML and CSS to get useful pixels on the screen, and (b) remove the mandatory multi-RTT penalty of todays CSSOM model. [1] https://gist.github.com/igrigorik/3ec49bc83ba9e1876d34 117474 18 ian 2015-01-25 18:27:37 +0000 > Problem: current spec [1] restricts the use of <link rel> to within the > <head> element only. That's not a problem. A problem or use case is a technology-agnostic statement, like, "pages should be fast to load", followed by a description of why the current technology doesn't allow it, or makes it unnecessarily hard, like "there is no way to provide styles for content in the second half of the page just before it's needed rather than providing it earlier when it isn't needed and would slow down rendering because browsers don't render the content until they have all the style sheets". 117481 19 zcorpan 2015-01-26 07:34:20 +0000 (In reply to Ilya Grigorik from comment #17) > This seems at odds? First we say any <link rel=stylesheet> outside of head > is invalid, but then we would document an optimization strategy that allows > exactly this? I'm OK if we can manage this, but it feels odd. What I meant was that if we were to specify the optimization, it would affect UAs, but still the UA requirements and authoring requirements are separate. The HTML parser has optimizations specified for things that are invalid, FWIW (e.g. Noah's Ark clause). 117501 20 igrigorik 2015-01-27 03:20:57 +0000 (In reply to Ian 'Hixie' Hickson from comment #18) > > A problem or use case is a technology-agnostic statement, like, "pages > should be fast to load", followed by a description of why the current > technology doesn't allow it, or makes it unnecessarily hard, like "there is > no way to provide styles for content in the second half of the page just > before it's needed rather than providing it earlier when it isn't needed and > would slow down rendering because browsers don't render the content until > they have all the style sheets". I'm good with that formulation (thanks! :)) but with one modification: this shouldn't be limited to just top vs. bottom half of the page. So, something like.. --- Pages should deliver a fast first-render. However, there is no way to provide styles for partial page content just before it is needed. Today the site has to provide all styles ahead of time, which slows down rendering because the browser must first download all styles before rendering any content to the screen. Due to the size of CSS on a typical site (20~110KB) this translates to multiple (2~5+) network roundtrips, which can easily delay rendering for 1s+. --- 117604 21 ian 2015-01-29 23:02:36 +0000 As far as I can tell, there's already a simple solution for this: <style scoped>. Each <section> can have its own <style scoped> blob that describes the styles for that section, provided literally as that section is reached by the parser. The styles can be inline, minimising latency, or externally using @import. Using <link rel=stylesheet> for this specific problem would be bad design, since it can affect earlier elements, leading to unstable styling. <style scoped> works just like <link rel=stylesheet> works in down-level clients, so it has the same backwards-compatibility story. This seems therefore strictly superior. 117615 22 zcorpan 2015-01-30 08:44:32 +0000 (In reply to Ian 'Hixie' Hickson from comment #21) > As far as I can tell, there's already a simple solution for this: <style > scoped>. See comment 9. 117637 23 igrigorik 2015-01-31 04:23:41 +0000 +1 to Simon's comment. Also, note that backwards-compat story for scoped styles is pretty bad: browsers that don't support "scoped" keyword will treat the @import as global and will leak all styles into global context, which means that you can't practically rely on the most important feature of "scoped" and are forced to write all stylesheets in such a way that they don't overlap or override each other, at which point the whole "scoped" thing becomes a no-op. 117877 24 igrigorik 2015-02-13 00:57:56 +0000 Interesting research from NNG [1] on importance of optimizing "above the fold" content: "What appears at the top of the page vs. what’s hidden will always influence the user experience—regardless of screen size. The average difference in how users treat info above vs. below the fold is 84%". Enabling developers to make the ATF content visible sooner, which is what we're trying to enable here, would be a nice UX+performance win. [1] http://www.nngroup.com/articles/page-fold-manifesto/ 118300 25 ian 2015-03-04 19:46:08 +0000 (In reply to Ilya Grigorik from comment #20) > > Pages should deliver a fast first-render. However, there is no way to > provide styles for partial page content just before it is needed. Yes there is, <style scoped>. > Today the > site has to provide all styles ahead of time, which slows down rendering > because the browser must first download all styles before rendering any > content to the screen. This is false, because <style scoped> lets you do exactly this. > Due to the size of CSS on a typical site (20~110KB) > this translates to multiple (2~5+) network roundtrips, which can easily > delay rendering for 1s+. All the styles could be inline, or they could be in external cached files, all of which can be fetched by the preparser. (In reply to Simon Pieters from comment #9) > I think the argument is that scoped stylesheets is an orthogonal feature. I don't see why it'd be orthogonal. The feature request is "provide styles for partial page content just before it is needed", which exactly describes what <style scoped> does. <style scoped> also has many advantages, such as making it not possible for the styles to impact earlier content, which is a key requirement for performance since otherwise you end up restyling earlier content when you get to the later style. > For some use cases it makes perfect sense to want to use scoped stylesheets, > but for this use case it is a non-goal and actually makes things harder for > the author. Why? > Consider how authors would typically achieve the desired effect here. First, > the author would write all of the CSS for the site. Then, a tool would be > used to determine the minimum subset of the full stylesheet required to > render the "above the fold", and put the subset in an inline <style> in > head. Then, the full stylesheet is external and is inserted in a manner that > does not block rendering, e.g. inserted into <head> with a <script> > somewhere in <body>, or, as amazon.com does, using <link> somewhere in body. I would not recommend this design approach. It's not scalable or maintainable. I would recommend creating the styles for each component of the site separately. If you use this approach, then it is trivial to extract just the styles needed for the below-the-fold part of the site. > With this workflow, having the full external stylesheet be a scoped > stylesheet doesn't really work unless you wrote the CSS with that in mind > from the beginning. With this workflow, you only have one external style sheet so you need it at the top regardless. (In reply to Ilya Grigorik from comment #23) > > Also, note that backwards-compat story for scoped styles is pretty bad: > browsers that don't support "scoped" keyword will treat the @import as > global and will leak all styles into global context, which means that you > can't practically rely on the most important feature of "scoped" and are > forced to write all stylesheets in such a way that they don't overlap or > override each other, at which point the whole "scoped" thing becomes a no-op. This is exactly what you'd have to do with a <link rel=stylesheet> as well. (In reply to Ilya Grigorik from comment #24) > Interesting research from NNG [1] on importance of optimizing "above the > fold" content: "What appears at the top of the page vs. what’s hidden will > always influence the user experience—regardless of screen size. The average > difference in how users treat info above vs. below the fold is 84%". > > Enabling developers to make the ATF content visible sooner, which is what > we're trying to enable here, would be a nice UX+performance win. It's already possible with <style scoped>. 118350 26 zcorpan 2015-03-05 11:50:29 +0000 (In reply to Ian 'Hixie' Hickson from comment #25) > I don't see why it'd be orthogonal. The feature request is "provide styles > for partial page content just before it is needed", which exactly describes > what <style scoped> does. > > <style scoped> also has many advantages, such as making it not possible for > the styles to impact earlier content, which is a key requirement for > performance since otherwise you end up restyling earlier content when you > get to the later style. Restyling earlier content is a tiny performance cost compared to blocking rendering until external stylesheets have loaded. > Why? Because it requires them to change their workflow from whatever they're doing now to fit the constraints of <style scoped>. > I would not recommend this design approach. It's not scalable or > maintainable. It is as scalable and as maintainable as using only external stylesheets, since it's just an automated publication step that doesn't affect how the site is being developed or maintained. This approach seems to be what at least some perf-savvy Web developers actually use and recommend. See e.g. http://www.filamentgroup.com/lab/performance-rwd.html "DETERMINING THE INLINE CSS" > I would recommend creating the styles for each component of the site > separately. If you use this approach, then it is trivial to extract just the > styles needed for the below-the-fold part of the site. I would guess that people do this already, but have an automated publication step that concatenates stylesheets into one file to reduce requests. (This might be unnecessary or counter-productive with HTTP/2.) I don't follow how creating styles for each component makes any difference to extracting the necessary styles. Extracting the necessary styles is trivial anyway since it's just a script that does it. > With this workflow, you only have one external style sheet so you need it at > the top regardless. The point is that initial rendering should not be blocked on loading it. But maybe other developers use multiple external stylesheets, I don't think it makes much of a difference here. 118478 27 igrigorik 2015-03-10 05:30:25 +0000 FWIW, it turns out that both IE and Firefox already treat CSS in body as non-blocking: http://www.webpagetest.org/video/compare.php?tests=150305_7M_92E-l%3Achrome-r%3A1-c%3A0%2C150305_Y4_91W-l:firefox-r%3A1-c%3A0,150310_JQ_9JW-r:1-c:0-l:ie11&thumbSize=100&ival=500&end=visual The above behavior goes even further then what we're proposing here. Seems like Blink is trailing the rest here; we should probably just change Blink's default behavior. 118495 28 zcorpan 2015-03-10 16:14:47 +0000 (In reply to Simon Pieters from comment #26) > > With this workflow, you only have one external style sheet so you need it at > > the top regardless. > > The point is that initial rendering should not be blocked on loading it. But > maybe other developers use multiple external stylesheets, I don't think it > makes much of a difference here. I suppose when there is a single external stylesheet, the use case could be addressed by adding an attribute to <link> that makes it not block rendering (and not block <script>s from running, either), even if in <head>. 118496 29 igrigorik 2015-03-10 17:23:17 +0000 (In reply to Simon Pieters from comment #28) > I suppose when there is a single external stylesheet, the use case could be > addressed by adding an attribute to <link> that makes it not block rendering > (and not block <script>s from running, either), even if in <head>. Yes, albeit this is hard to reason about as developer.. While the CSS may not block DCL you also have no idea when it will be applied (presumably, whenever the fetch is done). As a result, if you mark your "first" CSS as blocking and only put in the "above the fold" styles, then you run the risk of flashing unstyled content for "below the fold". Whereas with proposal we're iterating on here, the position of the link element would mark as a simple demarcation for which content can be rendered and which should be held back. P.S. rel=preload [1] will provide the equivalent of above behavior where the CSS fetch does not block rendering; and application can define own execution logic. [1] http://w3c.github.io/preload/#early-fetch-and-application-defined-execution 119096 30 ian 2015-03-30 22:45:43 +0000 (In reply to Simon Pieters from comment #26) > > Restyling earlier content is a tiny performance cost compared to blocking > rendering until external stylesheets have loaded. Assuming you are referring to the practice of using <link> in the head, then I agree, but I'm not advocating that so it seems orthogonal to this discussion. > Because it requires them to change their workflow from whatever they're > doing now to fit the constraints of <style scoped>. The constraints are simpler than with <link rel=stylesheet>-in-body. For scoped styles, the constraints are just "put a div around what you're styling". For the link-in-body thing, the constraints are that you have to be really careful to design your style sheet to not affect earlier contents. > It is as scalable and as maintainable as using only external stylesheets, > since it's just an automated publication step that doesn't affect how the > site is being developed or maintained. It's precisely the automated publication step that I was saying isn't scalable and maintainable. There's no good way to make it work with scripts, for example. > http://www.filamentgroup.com/lab/performance-rwd.html "DETERMINING THE > INLINE CSS" That pretty much makes my case for me, I think. The approach described in that post wouldn't work with anything but the most static of pages and styles. > I would guess that people do this already, but have an automated publication > step that concatenates stylesheets into one file to reduce requests. Then using <style scoped> would be trivial. > I don't follow how creating styles for each component makes any difference > to extracting the necessary styles. Extracting the necessary styles is > trivial anyway since it's just a script that does it. I don't see how a script can possibly accurately do this. Does it hover over every element? Run every possible script branch? 119137 31 zcorpan 2015-03-31 14:16:44 +0000 (In reply to Ian 'Hixie' Hickson from comment #30) > Assuming you are referring to the practice of using <link> in the head, then > I agree, but I'm not advocating that so it seems orthogonal to this > discussion. <link> in body. > The constraints are simpler than with <link rel=stylesheet>-in-body. For > scoped styles, the constraints are just "put a div around what you're > styling". I don't think everyone will find it simpler. If it was simpler then people would be doing that. > For the link-in-body thing, the constraints are that you have to > be really careful to design your style sheet to not affect earlier contents. Yes, but since a script deals with it, you don't have to care at all. > It's precisely the automated publication step that I was saying isn't > scalable and maintainable. There's no good way to make it work with scripts, > for example. Can you be more specific? > That pretty much makes my case for me, I think. The approach described in > that post wouldn't work with anything but the most static of pages and > styles. Why? > Then using <style scoped> would be trivial. Not without modifying the tree to insert <div>s to make <style scroped> allowed. Inserting <div>s might change the result of the other styles and can break scripts; it seems like a bad idea to do that at publication. And people are generally not happy with "unnecessary" <div>s. > I don't see how a script can possibly accurately do this. Does it hover over > every element? Run every possible script branch? Probably not. But the first paint does not need to be perfect for things like hover, it just needs to be good enough to let the user see the page while the rest is loading. But it would be simple to just include all :hover rules in the subset. Scripts is harder but I don't know if anyone has identified that as being an actual problem in practice. 119323 32 ian 2015-04-07 22:33:01 +0000 (In reply to Simon Pieters from comment #31) > <link> in body. Then I'm confused. I don't understand what you're arguing here. Do you mean that <link> in body doesn't block? > > The constraints are simpler than with <link rel=stylesheet>-in-body. For > > scoped styles, the constraints are just "put a div around what you're > > styling". > > I don't think everyone will find it simpler. If it was simpler then people > would be doing that. Maybe they don't know about it. If there's something that's not simpler about this then we should find out what it is exactly. Usually in my experience pages already have plenty of <div>s that correspond exactly to blocks of content that you'd be able to style separately. > > For the link-in-body thing, the constraints are that you have to > > be really careful to design your style sheet to not affect earlier contents. > > Yes, but since a script deals with it, you don't have to care at all. Requiring that authors use scripts to use this feature sanely is a non-starter IMHO. > > It's precisely the automated publication step that I was saying isn't > > scalable and maintainable. There's no good way to make it work with scripts, > > for example. > > Can you be more specific? If you have a <script> that builds a DOM that uses certain rules, there's no way to automatically determine what rules you need to include before the script. > > That pretty much makes my case for me, I think. The approach described in > > that post wouldn't work with anything but the most static of pages and > > styles. > > Why? Because you can't reliably analyse scripts to figure out what they need. > > Then using <style scoped> would be trivial. > > Not without modifying the tree to insert <div>s to make <style scroped> > allowed. Inserting <div>s is trivial. > Inserting <div>s might change the result of the other styles and > can break scripts; it seems like a bad idea to do that at publication. This is trivially testable. In general, a <div> or other such element already exists in the places where it would make sense to have scoped styles, anyway. > And people are generally not happy with "unnecessary" <div>s. I wish that were true, but the Web has pretty resoundly demonstrated that authors have no problem adding <div>s to pages. > > I don't see how a script can possibly accurately do this. Does it hover over > > every element? Run every possible script branch? > > Probably not. Then it doesn't work. 119347 33 zcorpan 2015-04-08 10:06:31 +0000 (In reply to Ian 'Hixie' Hickson from comment #32) > (In reply to Simon Pieters from comment #31) > > <link> in body. > > Then I'm confused. I don't understand what you're arguing here. Do you mean > that <link> in body doesn't block? ...sorry, I meant this: The perf cost of accidentally restyling earlier content using <link> in body is trivial compared to blocking rendering while a <link> in head is loading. This was in response to your statement that <style scoped> making it impossible to restyle earlier content is important for performance. I'm arguing it's not important. > If you have a <script> that builds a DOM that uses certain rules, there's no > way to automatically determine what rules you need to include before the > script. > Because you can't reliably analyse scripts to figure out what they need. Yes, OK. I don't know if this is an issue in practice for people using this approach. Maybe things that need to be ready on first paint are built on the server-side, and scripts run after first paint for other things. > I wish that were true, but the Web has pretty resoundly demonstrated that > authors have no problem adding <div>s to pages. It's not a best practice. People also have no problem producing inaccessible pages, but... > Then it doesn't work. Well it also doesn't "work" if the user lands on an anchor below the fold, but optimizations are not supposed to be perfect for all edge cases, they're supposed to have a big impact for the common case. 119411 34 ian 2015-04-09 20:18:49 +0000 > The perf cost of accidentally restyling earlier > content using <link> in body is trivial compared to blocking rendering while > a <link> in head is loading. I agree. But the cases we're comparing aren't <link>-in-head and <link>-in-body. They're <link>-in-body and <style scoped>. The latter has all the benefits of not blocking in head, with all the benefits of being scoped, and the only disadvantage that's been mentioned (which I don't really even view as a disadvantage) is that you have to put it in an element to indicate the scope to which the styles apply. > This was in response to your statement that > <style scoped> making it impossible to restyle earlier content is important > for performance. I'm arguing it's not important. It's not important compared to blocking in the head, sure. But that doesn't mean it's not important in general. It can easily cost a lost frame. > > Then it doesn't work. > > Well it also doesn't "work" if the user lands on an anchor below the fold, > but optimizations are not supposed to be perfect for all edge cases, they're > supposed to have a big impact for the common case. As far as I can tell, the big impact is already possible with <style scoped>. 120257 35 jaffathecake 2015-05-12 07:16:58 +0000 https://code.google.com/p/chromium/issues/detail?id=481122 - Chromium issue for this 120258 36 jaffathecake 2015-05-12 07:40:56 +0000 In terms of CSS loading, there are a couple of use-cases people use https://github.com/filamentgroup/loadCSS for. 1. I wish to load CSS. It shouldn't block, and it should apply as soon as it loads. This is useful for parts of an interface that are an interaction away, or where you consider the partial FOUC to be acceptable (I personally disagree that FOUC is ever acceptable, though). 2. I wish to load CSS. It should block rendering of the elements concerned. This is a little more complicated, but the inlined CSS can make the elements opacity:0, then the loaded css can make it opacity:1, maybe even with a transition. The tricky part is preventing the interface jumping around if the elements load in a particular order. <style scoped> would be a good replacement for this. 3. I wish to load CSS. It should block all subsequent rendering to ensure sections are rendered in order. Neither loadCSS or <style scoped> make this easy, but IE & Firefox already allow <link> to be used for this behaviour, and it's super simple. Take this: <style>/* inline styles */</style> Content <section class="secondary"> /* styles for this section, somehow */ Content </section> <section class="tertiary"> /* styles for this section, somehow */ Content </section> Using loadCSS (or <link async>, if that were a thing), you'd get the sections appearing without all their styles, which may not be what you want. You could use some pretty hacky CSS to work around it, though. With scoped sheets, the rendering would be blocked for each section, but tertiary may load before secondary, meaning the page would jump around while loading (assuming they're vertically stacked). You could do this: <style>/* inline styles */</style> Content <div> <style scoped>/* import */</style> <section class="secondary"> /* styles for this section, somehow */ Content </section> <section class="tertiary"> <style scoped>/* import */</style> /* styles for this section, somehow */ Content </section> </div> …which would ensure "tertiary" cannot display before "secondary", but this is a hack. You've changed the scoping to accommodate load-order. Whereas… <style>/* inline styles */</style> Content <section class="secondary"> <link rel="stylesheet" href="style2"> Content </section> <section class="tertiary"> <link rel="stylesheet" href="style3"> Content </section> …this works in Firefox & IE today, and it has an acceptable fallback in Safari & Chrome. 120289 37 ericschurmanpublic 2015-05-13 18:28:29 +0000 I've been working on performance sensitive complex websites for a long time, and I have to agree with the "allow link in the body" crowd. It also reflects the conscious decisions I've made when building websites for over a decade. For fastest customer experience, it's important to flush the chunks of HTML containing the start of the page as soon as possible. It's often trivial to know all the CSS, javascript, and HTML needed for the very start of a page, for example, a site-wide nav and some site wide CSS. The content lower in the page may take orders of magnitude longer to calculate on the server, and that content may require different CSS in different scenarios. For example, imagine a search results page that usually just has simple web results, but occasionally has a complex region (like a map or something) shown that has need for a lot of CSS. Or a product detail page which displays very different interfaces for a video game than for an office software product, although the site navigation is the same. Having the ability to link to a large CSS in the body only when needed allows for fast flushing of the page in all scenarios, not blocking rendering of the top of the page, only requesting the large CSS file when needed, the ability to use that file from cache when available, and does this all in a completely cross browser approach - which is hugely important for reducing developer costs. It's typically also trivial to scope these additional CSS files to just the widgets that need them. This scenario has come up over and over again in the twenty years I've been building dynamic sites. Although the HTML spec has said it's invalid, we've used it over and over again because every browser has supported it and it's made our customer experience and developer process better. 124688 38 d 2016-01-24 05:29:38 +0000 Given how style scoped seems to be on its way out, I think we should do this. I've added the [good first bug] whiteboard label and we'd welcome a pull request at https://github.com/whatwg/html. 125345 39 d 2016-03-03 20:29:22 +0000 https://github.com/whatwg/html/commit/179983e9eb99efe417349a40ebb664bd11668ddd 1559 2014-12-16 00:57:02 +0000 2014-12-16 00:57:02 +0000 <link> in <body> (2014-08-15 HA run) results-20141215-165510.csv text/csv 16594 igrigorik cGFnZSx1cmwsbWF0Y2gKaHR0cDovL3d3dy55YW5kZXguY29tLnRyLyxodHRwOi8vd3d3LnlhbmRl eC5jb20udHIvLCI8bGluayByZWxhdGVzPSIibW9yZGEiIiByZWw9IiJzdHlsZXNoZWV0IiIgaHJl Zj0iIi8veWFzdGF0aWMubmV0L3d3dy8yLjE1L3YxMi9wYWdlcy1kZXNrdG9wL3R1cmtleS9fdHVy a2V5Lmljb25zLmNvbWJvLmNzcyIiLz4iCmh0dHA6Ly93d3cuZWJheS5jby8saHR0cDovL3d3dy5l YmF5LmNvbS8sIjxsaW5rIHJlbD0iInN0eWxlc2hlZXQiIiB0eXBlPSIidGV4dC9jc3MiIiBocmVm PSIiaHR0cDovL2lyLmViYXlzdGF0aWMuY29tL3JzL3YvM3pwMDRlZGZ4MjRodGt4MXd0ZGlwZW9m MDJpLmNzcz9wcm9jPURVOk4iIj4iCmh0dHA6Ly93d3cubWFya2V0d2F0Y2guY29tLyxodHRwOi8v d3d3Lm1hcmtldHdhdGNoLmNvbS8sIjxsaW5rIGhyZWY9J2h0dHA6Ly9zYy53c2oubmV0L2Nzcy9j c3NEZXBlbmRlbmNpZXMvaGF0LWljb25zLmNzcycgdHlwZT0iInRleHQvY3NzIiIgcmVsPSIic3R5 bGVzaGVldCIiIC8+IgpodHRwOi8vd3d3LnBldGRvb2YuY29tLyxodHRwOi8vd3d3LnBldGRvb2Yu Y29tLywiPGxpbmsgcmVsPSIic3R5bGVzaGVldCIiIHR5cGU9IiJ0ZXh0L2NzcyIiIG1lZGlhPSIi c2NyZWVuIiIgaHJlZj0iImh0dHA6Ly93d3cucGV0ZG9vZi5jb20vd3AtY29udGVudC9wbHVnaW5z L2RyZWFtZ3Jvdy1zY3JvbGwtdHJpZ2dlcmVkLWJveC90ZW1wbGF0ZXMvZGVmYXVsdC9zdHlsZS5j c3MiIiAvPiIKaHR0cDovL3d3dy5odWJzcG90LmNvbS8saHR0cDovL3d3dy5odWJzcG90LmNvbS8s IjxsaW5rIGhyZWY9IiJodHRwczovL2FwcC5odWJzcG90LmNvbS9uYXYtc3RhdGljL2Jhc2UuY3Nz IiIgdHlwZT0iInRleHQvY3NzIiIgcmVsPSIic3R5bGVzaGVldCIiLz4iCmh0dHA6Ly93d3cua2Fz a3VzLmNvbS8saHR0cDovL3d3dy5rYXNrdXMuY28uaWQvLCI8bGluayBocmVmPSIiaHR0cDovL2Nk bi5rYXNrdXMuY29tL3RoZW1lc18zLjAvc3R5bGVzaGVldHMvcXVpY2tpZS9pbnRyb2pzLmNzcyIi IHJlbD0iInN0eWxlc2hlZXQiIiB0eXBlPSIidGV4dC9jc3MiIiBtZWRpYT0iImFsbCIiIC8+Igpo dHRwOi8vd3d3LnRlbGVncmFwaC5jby51ay8saHR0cDovL3d3dy50ZWxlZ3JhcGguY28udWsvLCI8 bGluayBocmVmPSIiaHR0cDovL3MudGVsZWdyYXBoLmNvLnVrL2dyYXBoaWNzL2h0bWwvWWVhcnMv MjAxMy9NYXJjaC9jYXJ0b29uV2lkZ2V0Mi9jc3MvbWFpbi5jc3MiIiByZWw9IiJzdHlsZXNoZWV0 IiIvPiIKaHR0cDovL3d3dy5lYmF5LmZyLyxodHRwOi8vd3d3LmViYXkuZnIvLCI8bGluayByZWw9 IiJzdHlsZXNoZWV0IiIgdHlwZT0iInRleHQvY3NzIiIgaHJlZj0iImh0dHA6Ly9pci5lYmF5c3Rh dGljLmNvbS9oZWFkZXIvY3NzL2dsYi5pZWx0OT9jb21ibz0xMSZkcz0zJnJ2cj0xLjAuMCZmYWN0 b3I9R0hDT0xMJnNpdGVpZD03MSZoPTEwNDI1NCIiPiIKaHR0cDovL3d3dy5vbHguaW4vLGh0dHA6 Ly93d3cub2x4LmluLywiPGxpbmsgcmVsPSIic3R5bGVzaGVldCIiIHR5cGU9IiJ0ZXh0L2NzcyIi IGhyZWY9IiJodHRwOi8vc3RhdGljMDEub2x4LXN0LmNvbS9mcm9udEVuZC9pbi9hc3NldHMvY3Nz L3Jlc3BvbnNpdmUvaWVmaXgvaG9tZS5jc3MiIi8+IgpodHRwOi8vd3d3LnF1aWtyLmNvbS8saHR0 cDovL3d3dy5xdWlrci5jb20vLCI8bGluayByZWw9IiJzdHlsZXNoZWV0IiIgdHlwZT0iInRleHQv Y3NzIiIgaHJlZj0iImh0dHA6Ly90ZWphMi5rdWlrci5jb20vY3NzL3N0eWxlLmNzcz9yPTE0MDYy NDgiIj4iCmh0dHA6Ly93d3cuaW50dWl0LmNvbS8saHR0cDovL3d3dy5pbnR1aXQuY29tLywiPGxp bmsgaHJlZj0iIi8vczMuaW50dWl0c3RhdGljLmNvbS9hc3NldHMvaGFybW9ueS9hc3NldHMvb3Bp bmlvbmxhYnMvY3NzL21lcmdlZC9vcGluaW9ubGFicy0xZDUyZTVhZWRmNjlmNzM0NTIzZjljZTE1 M2IwOGUxYi5jc3MiIiBtZWRpYT0iInNjcmVlbiIiIHJlbD0iInN0eWxlc2hlZXQiIiB0eXBlPSIi dGV4dC9jc3MiIiAvPiIKaHR0cDovL3d3dy5hbGFyYWJpeWEubmV0LyxodHRwOi8vd3d3LmFsYXJh Yml5YS5uZXQvLCI8bGluayByZWw9IiJzdHlsZXNoZWV0IiIgaHJlZj0iImh0dHA6Ly93d3cuYWxh cmFiaXlhLm5ldC9hc3NldHMvY3NzL3R3aXR0ZXIuY3NzIiIgdHlwZT0iInRleHQvY3NzIiIgLz4i Cmh0dHA6Ly93d3cuY2xpY2tiYW5rLm5ldC8saHR0cDovL3d3dy5jbGlja2JhbmsuY29tLyw8bGlu ayByZWw9J3N0eWxlc2hlZXQnIGlkPSdqc19jb21wb3Nlcl9jdXN0b21fY3NzLWNzcycgaHJlZj0n aHR0cDovL2NsaWNrYmFuay53cGVuZ2luZS5uZXRkbmEtY2RuLmNvbS93cC1jb250ZW50L3VwbG9h ZHMvanNfY29tcG9zZXIvY3VzdG9tLmNzcz92ZXI9My43LjQnIHR5cGU9J3RleHQvY3NzJyBtZWRp YT0nc2NyZWVuJyAvPgpodHRwOi8vd3d3LnNlbXJ1c2guY29tLyxodHRwOi8vd3d3LnNlbXJ1c2gu Y29tLywiPGxpbmsgcmVsPSIic3R5bGVzaGVldCIiIGhyZWY9IiIvL2QybHJ4Y3oyaWh2YWp5LmNs b3VkZnJvbnQubmV0L20vYnVpbGQvY3NzL3BvcG92ZXIuY3NzP3I9djIwMCIiIHR5cGU9IiJ0ZXh0 L2NzcyIiIG1lZGlhPSIiYWxsIiIgY2hhcnNldD0iInV0Zi04IiIgLz4iCmh0dHA6Ly93d3cub2su cnUvLGh0dHA6Ly93d3cub2sucnUvLCI8bGluayByZWw9IiJzdHlsZXNoZWV0IiIgdHlwZT0iInRl eHQvY3NzIiIgaHJlZj0iImh0dHA6Ly9zdC5teWNkbi5tZS9yZXMvY3NzL3Byb2QvbG9naW4vbG9n aW5fb2tydS5hOWY4MjMzNS5jc3MiIj4iCmh0dHA6Ly93d3cub25lLmx2LyxodHRwOi8vd3d3Lm9k bm9rbGFzc25pa2kucnUvLCI8bGluayByZWw9IiJzdHlsZXNoZWV0IiIgdHlwZT0iInRleHQvY3Nz IiIgaHJlZj0iImh0dHA6Ly9zdC5teWNkbi5tZS9yZXMvY3NzL3Byb2QvbG9naW4vbG9naW5fb2ty dS5hOWY4MjMzNS5jc3MiIj4iCmh0dHA6Ly93d3cuZXJvLWFkdmVydGlzaW5nLmNvbS8saHR0cDov L3d3dy5lcm8tYWR2ZXJ0aXNpbmcuY29tLywiPGxpbmsgcmVsPSIic3R5bGVzaGVldCIiIGhyZWY9 IiIvY3NzL3ZzbGlkZXIuY3NzIiIgLz4iCmh0dHA6Ly93d3cuNHNoYXJlZC5jb20vLGh0dHA6Ly93 d3cuNHNoYXJlZC5jb20vLCI8bGluayByZWw9IiJzdHlsZXNoZWV0IiIgdHlwZT0iInRleHQvY3Nz IiIgaHJlZj0iImh0dHA6Ly9zdGF0aWMuNHNoYXJlZC5jb20vY3NzL25vdGlmeUJsb2NrLjRtaW4u Y3NzP3Zlcj0zNjA4MjgwNzI1IiIvPiIKaHR0cDovL3d3dy5kcmVhbXN0aW1lLmNvbS8saHR0cDov L3d3dy5kcmVhbXN0aW1lLmNvbS8sIjxsaW5rIGhyZWY9IiIvL3RodW1icy5kcmVhbXN0aW1lLmNv bS9jc3Mvc3R5bGVzMjAxMy12MjAuY3NzIiIgdHlwZT0iInRleHQvY3NzIiIgcmVsPSIic3R5bGVz aGVldCIiPiIKaHR0cDovL3d3dy5ieWNvbnRleHQuY29tLyxodHRwOi8vd3d3LmJ5Y29udGV4dC5j b20vLCI8bGluayBocmVmPSIiLi4vY3NzL3Rlcm1zLmNzcyIiIHJlbD0iInN0eWxlc2hlZXQiIj4i Cmh0dHA6Ly93d3cucGV5dmFuZGhhLmlyLyxodHRwOi8vd3d3LnBleXZhbmRoYS5pci8sPGxpbmsg cmVsPSdzdHlsZXNoZWV0JyBpZD0ncmVzcG9uc2l2ZS1jc3MnIGhyZWY9J2Nzc2hlZXRzL3Jlc3Bv bnNpdmUuY3NzP3Zlcj0zLjUuMScgdHlwZT0ndGV4dC9jc3MnIG1lZGlhPSdhbGwnIC8+Cmh0dHA6 Ly93d3cuZmMyLmNvbS8saHR0cDovL3d3dy5mYzIuY29tLywiPGxpbmsgcmVsPSIic3R5bGVzaGVl dCIiIHR5cGU9IiJ0ZXh0L2NzcyIiIGhyZWY9IiJodHRwOi8vc3RhdGljLmZjMi5jb20vc2hhcmUv ZmMycGFydHMvY3NzL2ZjMmZvb3Rlcl9sYW5ndWFnZXMuY3NzIiIgLz4iCmh0dHA6Ly93d3cuaW1k Yi5jb20vLGh0dHA6Ly93d3cuaW1kYi5jb20vLCI8bGluayByZWw9IiJzdHlsZXNoZWV0IiIgdHlw ZT0iInRleHQvY3NzIiIgaHJlZj0iImh0dHA6Ly9pLm1lZGlhLWltZGIuY29tL2ltYWdlcy9TRjUy ZTZiOWYxMTcxMmQzZWM1NTIxNzlmNmM4NjliNjNhL2NzczIvc2l0ZS9jb25zdW1lci1uYXZiYXIt bm8tanMuY3NzIiI+IgpodHRwOi8vd3d3LmtvaGxzLmNvbS8saHR0cDovL3d3dy5rb2hscy5jb20v LCI8bGluayByZWw9IiJzdHlsZXNoZWV0IiIgaHJlZj0iImh0dHA6Ly93d3cua29obHMuY29tL21l ZGlhL2Nzcy9mb250cy9oZmpGb250cy5jc3MiIiB0eXBlPSIidGV4dC9jc3MiIiBtZWRpYT0iInNj cmVlbiIiIGNoYXJzZXQ9IiJ1dGYtOCIiLz4iCmh0dHA6Ly93d3cuMTIzc2Rmc2Rmc2Rmc2QucnUv LGh0dHA6Ly93d3cueWFuZGV4LnJ1LywiPGxpbmsgdHlwZT0iInRleHQvY3NzIiIgcmVsPSIic3R5 bGVzaGVldCIiIGhyZWY9IiIvL3lhc3RhdGljLm5ldC93d3cvMi4xNS9yYXBpZG8vcGFnZXMvYmln L19iaWcuaWNvbnMuY29tYm8uY3NzIiI+IgpodHRwOi8vd3d3LmxhdGltZXMuY29tLyxodHRwOi8v d3d3LmxhdGltZXMuY29tLywiPGxpbmsgcmVsPSIic3R5bGVzaGVldCIiIHR5cGU9IiJ0ZXh0L2Nz cyIiIGhyZWY9IiJodHRwOi8vZDFxcWMxZTlrdm1kaDguY2xvdWRmcm9udC5uZXQvY3NzL25ndXgt YmFya2Vycy0wLjAuMi5jc3MiIiAvPiIKaHR0cDovL3d3dy53ZWJzaXRlc21hZGVlYXN5LnR2Lyxo dHRwOi8vd3d3Lmhvc3RnYXRvci5jb20vLCI8bGluayByZWw9IiJzdHlsZXNoZWV0IiIgaHJlZj0i Ii9jc3MvdGVybXMtb3ZlcmxheXMuY3NzIiI+IgpodHRwOi8vd3d3LndlYnNpdGVzbWFkZWVhc3ku dHYvLGh0dHA6Ly93d3cuaG9zdGdhdG9yLmNvbS8sIjxsaW5rIHJlbD0iInN0eWxlc2hlZXQiIiBo cmVmPSIiL2Nzcy90ZXJtcy1vdmVybGF5cy5jc3MiIj4iCmh0dHA6Ly93d3cuc3F1YXJlc3BhY2Uu Y29tLyxodHRwOi8vd3d3LnNxdWFyZXNwYWNlLmNvbS8sIjxsaW5rIHJlbD0iInN0eWxlc2hlZXQi IiBocmVmPSIiLy9zdGF0aWMuc3F1YXJlc3BhY2UuY29tL3N0YXRpYy90YS81MTM0Y2JlZmU0YjBj NmZiMDRkZjgwNjUvMTQwNTA5Njg5MzU4MC9hc3NldHMvc3R5bGVzL2RldGFpbHMubWluLmNzcyIi IHR5cGU9IiJ0ZXh0L2NzcyIiIC8+IgpodHRwOi8vd3d3LmJoYXNrYXIuY29tLyxodHRwOi8vd3d3 LmJoYXNrYXIuY29tLywiPGxpbmsgcmVsPSIic3R5bGVzaGVldCIiIGhyZWY9IiJodHRwOi8vaTEw LmRhaW5pa2JoYXNrYXIuY29tL2J1c2luZXNzMjAxNC9jc3MvanF1ZXJ5Lm1DdXN0b21TY3JvbGxi YXIuY3NzPz8xNDAxNzcyODQ1IiIgLz4iCmh0dHA6Ly93d3cuZGFpbmlrYmhhc2thci5jb20vLGh0 dHA6Ly93d3cuYmhhc2thci5jb20vLCI8bGluayByZWw9IiJzdHlsZXNoZWV0IiIgaHJlZj0iImh0 dHA6Ly9pMTAuZGFpbmlrYmhhc2thci5jb20vYnVzaW5lc3MyMDE0L2Nzcy9qcXVlcnkubUN1c3Rv bVNjcm9sbGJhci5jc3M/PzE0MDE3NzI4NDUiIiAvPiIKaHR0cDovL3d3dy5kYWluaWtiaGFza2Fy LmNvbS8saHR0cDovL3d3dy5iaGFza2FyLmNvbS8sIjxsaW5rIHJlbD0iInN0eWxlc2hlZXQiIiBo cmVmPSIiaHR0cDovL2kxMC5kYWluaWtiaGFza2FyLmNvbS9idXNpbmVzczIwMTQvY3NzL2pxdWVy eS5tQ3VzdG9tU2Nyb2xsYmFyLmNzcz8/MTQwMTc3Mjg0NSIiIC8+IgpodHRwOi8vd3d3LmViYXku Y28udWsvLGh0dHA6Ly93d3cuZWJheS5jby51ay8sIjxsaW5rIHJlbD0iInN0eWxlc2hlZXQiIiB0 eXBlPSIidGV4dC9jc3MiIiBocmVmPSIiaHR0cDovL2lyLmViYXlzdGF0aWMuY29tL3JzL3YvM3pw MDRlZGZ4MjRodGt4MXd0ZGlwZW9mMDJpLmNzcz9wcm9jPURVOk4iIj4iCmh0dHA6Ly93d3cubmlj b3ZpZGVvLmpwLyxodHRwOi8vd3d3Lm5pY292aWRlby5qcC8sIjxsaW5rIHJlbD0iInN0eWxlc2hl ZXQiIiB0eXBlPSIidGV4dC9jc3MiIiBjaGFyc2V0PSIidXRmLTgiIiBocmVmPSIiaHR0cDovL3Vu aS5yZXMubmltZy5qcC9qcy9uaWNvaGVhZGVyL3Jlc291cmNlcy9uaWNvbGliLUNvbW1vbk5vdGlm aWNhdGlvbkhlYWRlci5jc3M/MTMwODA4IiI+IgpodHRwOi8vd3d3LnBjaC5jb20vLGh0dHA6Ly93 d3cucGNoLmNvbS8sIjxsaW5rIHJlbD0iInN0eWxlc2hlZXQiIiB0eXBlPSIidGV4dC9jc3MiIiBo cmVmPSIiaHR0cDovL2Nkbi5wY2guY29tL3NwZWN0cnVtL09QUy9QQ0h0YWtlb3Zlci9jc3MvcGNo VGFrZW92ZXIuY3NzIiIvPiIKaHR0cDovL3d3dy5jbGlja2JhbmsuY29tLyxodHRwOi8vd3d3LmNs aWNrYmFuay5jb20vLDxsaW5rIHJlbD0nc3R5bGVzaGVldCcgaWQ9J2pzX2NvbXBvc2VyX2N1c3Rv bV9jc3MtY3NzJyBocmVmPSdodHRwOi8vY2xpY2tiYW5rLndwZW5naW5lLm5ldGRuYS1jZG4uY29t L3dwLWNvbnRlbnQvdXBsb2Fkcy9qc19jb21wb3Nlci9jdXN0b20uY3NzP3Zlcj0zLjcuNCcgdHlw ZT0ndGV4dC9jc3MnIG1lZGlhPSdzY3JlZW4nIC8+Cmh0dHA6Ly93d3cuam9icGF0aC5jb20vLGh0 dHA6Ly93d3cuY2FyZWVyYnVpbGRlci5jb20vLCI8bGluayByZWw9IiJzdHlsZXNoZWV0IiIgdHlw ZT0iInRleHQvY3NzIiIgaHJlZj0iImh0dHA6Ly9pbWcuaWNiZHIuY29tL2ltYWdlcy9vcGluaW9u bGFicy9vbmxpbmVvcGluaW9udjU3MS9vb19zdHlsZS5jc3MiIiAvPiIKaHR0cDovL3d3dy55YW5k ZXgucnUvLGh0dHA6Ly93d3cueWFuZGV4LnJ1LywiPGxpbmsgdHlwZT0iInRleHQvY3NzIiIgcmVs PSIic3R5bGVzaGVldCIiIGhyZWY9IiIvL3lhc3RhdGljLm5ldC93d3cvMi4xNS9yYXBpZG8vcGFn ZXMvYmlnL19iaWcuaWNvbnMuY29tYm8uY3NzIiI+IgpodHRwOi8vd3d3LmhzLXNpdGVzLmNvbS8s aHR0cDovL3d3dy5odWJzcG90LmNvbS8sIjxsaW5rIGhyZWY9IiJodHRwczovL2FwcC5odWJzcG90 LmNvbS9uYXYtc3RhdGljL2Jhc2UuY3NzIiIgdHlwZT0iInRleHQvY3NzIiIgcmVsPSIic3R5bGVz aGVldCIiLz4iCmh0dHA6Ly93d3cuaG9zdGdhdG9yLmNvbS8saHR0cDovL3d3dy5ob3N0Z2F0b3Iu Y29tLywiPGxpbmsgcmVsPSIic3R5bGVzaGVldCIiIGhyZWY9IiIvY3NzL3Rlcm1zLW92ZXJsYXlz LmNzcyIiPiIKaHR0cDovL3d3dy5pZ24uY29tLyxodHRwOi8vd3d3Lmlnbi5jb20vLCI8bGluayBo cmVmPSIiaHR0cDovL295c3RhdGljLmlnbmltZ3MuY29tL2NhY2hlL2Nzcy8xZi9kZS8xZmRlMGUw NTM3NTYyN2NkZTNmMTc2ZDUyOTZlN2UwYi5jc3MiIiBtZWRpYT0iInNjcmVlbiIiIHJlbD0iInN0 eWxlc2hlZXQiIiB0eXBlPSIidGV4dC9jc3MiIiAvPiIKaHR0cDovL3d3dy5hZ29kYS5jb20vLGh0 dHA6Ly93d3cuYWdvZGEuY29tLywiPGxpbmsgaHJlZj0iImh0dHA6Ly9pbWcuYWdvZGEubmV0L2pz L2pxdWVyeV9hY2NvcmRpb24vMS44L3RoZW1lcy9iYXNlL2pxdWVyeS11aS5jc3MiIiByZWw9IiJz dHlsZXNoZWV0IiIgdHlwZT0iInRleHQvY3NzIiIgLz4iCmh0dHA6Ly93d3cuZWJheS5pbi8saHR0 cDovL3d3dy5lYmF5LmluLywiPGxpbmsgcmVsPSIic3R5bGVzaGVldCIiIHR5cGU9IiJ0ZXh0L2Nz cyIiIGhyZWY9IiJodHRwOi8vaXIuZWJheXN0YXRpYy5jb20vaGVhZGVyL2Nzcy9nbGIuaWVsdDk/ Y29tYm89MTEmZHM9MyZmYWN0b3I9ZW1wJnNpdGVpZD0yMDMmcnZyPTEuMC4wJmg9MTA0MjUyIiI+ IgpodHRwOi8vd3d3Lm1lZGlhLWltZGIuY29tLyxodHRwOi8vd3d3LmltZGIuY29tLywiPGxpbmsg cmVsPSIic3R5bGVzaGVldCIiIHR5cGU9IiJ0ZXh0L2NzcyIiIGhyZWY9IiJodHRwOi8vaS5tZWRp YS1pbWRiLmNvbS9pbWFnZXMvU0Y1MmU2YjlmMTE3MTJkM2VjNTUyMTc5ZjZjODY5YjYzYS9jc3My L3NpdGUvY29uc3VtZXItbmF2YmFyLW5vLWpzLmNzcyIiPiIKaHR0cDovL3d3dy5lYmF5LmdyLyxo dHRwOi8vd3d3LmViYXkuY29tLywiPGxpbmsgcmVsPSIic3R5bGVzaGVldCIiIHR5cGU9IiJ0ZXh0 L2NzcyIiIGhyZWY9IiJodHRwOi8vaXIuZWJheXN0YXRpYy5jb20vcnMvdi8zenAwNGVkZngyNGh0 a3gxd3RkaXBlb2YwMmkuY3NzP3Byb2M9RFU6TiIiPiIKaHR0cDovL3d3dy5kZWx0YS5jb20vLGh0 dHA6Ly93d3cuZGVsdGEuY29tLywiPGxpbmsgcmVsPSIic3R5bGVzaGVldCIiIHR5cGU9IiJ0ZXh0 L2NzcyIiIG1lZGlhPSIic2NyZWVuIiIgaHJlZj0iIi8vY29udGVudC5kZWx0YS5jb20vY29udGVu dC9kYW0vZGVsdGEtYXBwbGljYXRpb25zL2Nzcy93aWRnZXRuYXYvMS44LjAvd2lkZ2V0bmF2LWll Ni5jc3MiIiAvPiIKaHR0cDovL3d3dy5ob3d0b2dldG9ubGluZS5uZXQvLGh0dHA6Ly93d3cuaG9z dGdhdG9yLmNvbS8sIjxsaW5rIHJlbD0iInN0eWxlc2hlZXQiIiBocmVmPSIiL2Nzcy90ZXJtcy1v dmVybGF5cy5jc3MiIj4iCmh0dHA6Ly93d3cuemVkby5jb20vLGh0dHA6Ly93d3cuemVkby5jb20v LDxsaW5rIHJlbD0nc3R5bGVzaGVldCcgaWQ9J3NvbGlsb3F1eS1saXRlY2xhc3NpYy10aGVtZS1j c3MnIGhyZWY9J2h0dHA6Ly93d3cuemVkby5jb20vd3AtY29udGVudC9wbHVnaW5zL3NvbGlsb3F1 eS1saXRlL3RoZW1lcy9jbGFzc2ljL3N0eWxlLmNzcz92ZXI9My45LjEnIHR5cGU9J3RleHQvY3Nz JyBtZWRpYT0nYWxsJyAvPgpodHRwOi8vd3d3Lmh1YnNwb3QubmV0LyxodHRwOi8vd3d3Lmh1YnNw b3QuY29tLywiPGxpbmsgaHJlZj0iImh0dHBzOi8vYXBwLmh1YnNwb3QuY29tL25hdi1zdGF0aWMv YmFzZS5jc3MiIiB0eXBlPSIidGV4dC9jc3MiIiByZWw9IiJzdHlsZXNoZWV0IiIvPiIKaHR0cDov L3d3dy5uZXdlZ2cuY29tLyxodHRwOi8vd3d3Lm5ld2VnZy5jb20vLCI8bGluayByZWw9IiJzdHls ZXNoZWV0IiIgdHlwZT0iInRleHQvY3NzIiIgaHJlZj0iImh0dHA6Ly9pbWFnZXMxMC5uZXdlZ2cu Y29tL1dlYlJlc291cmNlL1RoZW1lcy8yMDA1L0NTUy9VU0Evb3BpbmlvbmxhYi52MS53LjkxNjUu MC5jc3MiIiAvPiIKaHR0cDovL3d3dy5zb290b28uY29tLyxodHRwOi8vd3d3LnNvb3Rvby5jb20v LCI8bGluayByZWw9IiJzdHlsZXNoZWV0IiIgdHlwZT0iInRleHQvY3NzIiIgaHJlZj0iImNzcy5j c3MiIj4iCmh0dHA6Ly93d3cuYmVzdGJsYWNraGF0Zm9ydW0uY29tLyxodHRwOi8vd3d3LmJlc3Ri bGFja2hhdGZvcnVtLmNvbS8sIjxsaW5rIHR5cGU9IiJ0ZXh0L2NzcyIiIGhyZWY9IiJodHRwOi8v YmVzdGJsYWNraGF0Zm9ydW0uY29tL2Zvb3RlcmJhci90aGVtZXMvZGFyay9zdHlsZS5jc3MiIiBy ZWw9IiJzdHlsZXNoZWV0IiIgLz4iCmh0dHA6Ly93d3cub2Rub2tsYXNzbmlraS5ydS8saHR0cDov L3d3dy5vZG5va2xhc3NuaWtpLnJ1LywiPGxpbmsgcmVsPSIic3R5bGVzaGVldCIiIHR5cGU9IiJ0 ZXh0L2NzcyIiIGhyZWY9IiJodHRwOi8vc3QubXljZG4ubWUvcmVzL2Nzcy9wcm9kL2xvZ2luL2xv Z2luX29rcnUuYTlmODIzMzUuY3NzIiI+IgpodHRwOi8vd3d3LmUtYmF5LmRlLyxodHRwOi8vd3d3 LmViYXkuZGUvLCI8bGluayByZWw9IiJzdHlsZXNoZWV0IiIgdHlwZT0iInRleHQvY3NzIiIgaHJl Zj0iImh0dHA6Ly9pci5lYmF5c3RhdGljLmNvbS9ycy92LzN6cDA0ZWRmeDI0aHRreDF3dGRpcGVv ZjAyaS5jc3M/cHJvYz1EVTpOIiI+IgpodHRwOi8vd3d3LndwdGVtcGxhdGVzLm9yZy8saHR0cDov L3d3dy5ob3N0Z2F0b3IuY29tLywiPGxpbmsgcmVsPSIic3R5bGVzaGVldCIiIGhyZWY9IiIvY3Nz L3Rlcm1zLW92ZXJsYXlzLmNzcyIiPiIKaHR0cDovL3d3dy5hZ29kYS5uZXQvLGh0dHA6Ly93d3cu YWdvZGEuY29tLywiPGxpbmsgaHJlZj0iImh0dHA6Ly9pbWcuYWdvZGEubmV0L2pzL2pxdWVyeV9h Y2NvcmRpb24vMS44L3RoZW1lcy9iYXNlL2pxdWVyeS11aS5jc3MiIiByZWw9IiJzdHlsZXNoZWV0 IiIgdHlwZT0iInRleHQvY3NzIiIgLz4iCmh0dHA6Ly93d3cud3d0ZTEuY29tLyxodHRwOi8vd3d3 LmV4cGVkaWEuY29tLywiPGxpbmsgcmVsPSIic3R5bGVzaGVldCIiIGhyZWY9IiIvbWluaWZ5L2pv aW5yZXdhcmQtYnVuZGxlLW1pbi04Njg3MDc0MDAuY3NzP3Y9cmVsZWFzZS0yMDE0LTA4LXIxLTc2 NjgtMTEyMzUwNy0xIiIgLz4iCmh0dHA6Ly93d3cuYW5jZXN0cnkuY29tLyxodHRwOi8vd3d3LmFu Y2VzdHJ5LmNvbS8sIjxsaW5rIGhyZWY9IiJodHRwOi8vYy5tZmNyZWF0aXZlLmNvbS9saWIvdGdu L2NvbWJvLmFzaHg/eC90ZW1wL2Nzcy92MS9tYWluLmNzcyZ4L3RlbXAvY3NzL3YyL2FsZXJ0LmNz cyZ4L3RlbXAvY3NzL3YxL2J1dHRvbi5jc3MmeC90ZW1wL2Nzcy92MS9jYWxsb3V0LmNzcyZ4L3Rl bXAvY3NzL3YxL2Zvcm0uY3NzJngvdGVtcC9jc3MvdjEvZ3JpZC5jc3MmeC90ZW1wL2Nzcy92MS9p Y29uLmNzcyZ4L3RlbXAvY3NzL3YzL21vZGFsLmNzcyIiIHJlbD0iInN0eWxlc2hlZXQiIiAvPiIK aHR0cDovL3d3dy5lYmF5LmNvbS8saHR0cDovL3d3dy5lYmF5LmNvbS8sIjxsaW5rIHJlbD0iInN0 eWxlc2hlZXQiIiB0eXBlPSIidGV4dC9jc3MiIiBocmVmPSIiaHR0cDovL2lyLmViYXlzdGF0aWMu Y29tL3JzL3YvM3pwMDRlZGZ4MjRodGt4MXd0ZGlwZW9mMDJpLmNzcz9wcm9jPURVOk4iIj4iCmh0 dHA6Ly93d3cuZWJheS5jb20uYXUvLGh0dHA6Ly93d3cuZWJheS5jb20uYXUvLCI8bGluayByZWw9 IiJzdHlsZXNoZWV0IiIgdHlwZT0iInRleHQvY3NzIiIgaHJlZj0iImh0dHA6Ly9pci5lYmF5c3Rh dGljLmNvbS9oZWFkZXIvY3NzL2dsYi5pZWx0OT9jb21ibz0xMSZkcz0zJnJ2cj0xLjAuMCZmYWN0 b3I9R0hDT0xMJnNpdGVpZD0xNSZoPTEwNDI1NCIiPiIKaHR0cDovL3d3dy55YW5kZXgubmV0Lyxo dHRwOi8vd3d3LnlhbmRleC5ydS8sIjxsaW5rIHR5cGU9IiJ0ZXh0L2NzcyIiIHJlbD0iInN0eWxl c2hlZXQiIiBocmVmPSIiLy95YXN0YXRpYy5uZXQvd3d3LzIuMTUvcmFwaWRvL3BhZ2VzL2JpZy9f YmlnLmljb25zLmNvbWJvLmNzcyIiPiIKaHR0cDovL3d3dy53YWxtYXJ0LmNvbS8saHR0cDovL3d3 dy53YWxtYXJ0LmNvbS8sIjxsaW5rIHJlbD1zdHlsZXNoZWV0IGhyZWY9IiJodHRwOi8vcDEzbi1h c3NldHMud2FsbWFydC5jb20vc3R5bGVzL2lycy4xLjEuMzQuY3NzIiI+IgpodHRwOi8vd3d3Lm9k bm9rbGFzc25pa2kudWEvLGh0dHA6Ly93d3cub2Rub2tsYXNzbmlraS5ydS8sIjxsaW5rIHJlbD0i InN0eWxlc2hlZXQiIiB0eXBlPSIidGV4dC9jc3MiIiBocmVmPSIiaHR0cDovL3N0Lm15Y2RuLm1l L3Jlcy9jc3MvcHJvZC9sb2dpbi9sb2dpbl9va3J1LmE5ZjgyMzM1LmNzcyIiPiIKaHR0cDovL3d3 dy5rYXNrLnVzLyxodHRwOi8vd3d3Lmthc2t1cy5jby5pZC8sIjxsaW5rIGhyZWY9IiJodHRwOi8v Y2RuLmthc2t1cy5jb20vdGhlbWVzXzMuMC9zdHlsZXNoZWV0cy9xdWlja2llL2ludHJvanMuY3Nz IiIgcmVsPSIic3R5bGVzaGVldCIiIHR5cGU9IiJ0ZXh0L2NzcyIiIG1lZGlhPSIiYWxsIiIgLz4i Cmh0dHA6Ly93d3cuYmVzdGJ1eS5jb20vLGh0dHA6Ly93d3cuYmVzdGJ1eS5jb20vLCI8bGluayBo cmVmPSIiaHR0cDovL2Nzcy5iYnlzdGF0aWMuY29tL19jYXJvdXNlbC9zYXNzL2Nhcm91c2VsRnJh Z21lbnQtMzc0MzY0OGZhM2EyZmFhNGE0ZTEwNmYwNGM5N2U1M2QuY3NzIiIgcmVsPSIic3R5bGVz aGVldCIiIHR5cGU9IiJ0ZXh0L2NzcyIiIG1lZGlhPSIiYWxsIiI+IgpodHRwOi8vd3d3LmFtYXpv bi5jby51ay8saHR0cDovL3d3dy5hbWF6b24uY28udWsvLDxsaW5rIHR5cGU9J3RleHQvY3NzJyBo cmVmPSdodHRwOi8vei1lY3guaW1hZ2VzLWFtYXpvbi5jb20vaW1hZ2VzL0cvMDEvczktY2FtcGFp Z25zL3M5LWFpdi1taW4uX1YzNjAzMDcxODFfLmNzcycgcmVsPSdzdHlsZXNoZWV0Jz4KaHR0cDov L3d3dy5yZXV0ZXJzLmNvbS8saHR0cDovL3d3dy5yZXV0ZXJzLmNvbS8sIjxsaW5rIGhyZWY9IiJo dHRwOi8vczQucmV1dGVyc21lZGlhLm5ldC9yZXNvdXJjZXNfdjIvY3NzL3Jjb20tbWFzdGhlYWQt bmF2LW5ldy5jc3MiIiByZWw9IiJzdHlsZXNoZWV0IiIgLz4iCmh0dHA6Ly93d3cudGFyZ2V0LmNv bS8saHR0cDovL3d3dy50YXJnZXQuY29tLywiPGxpbmsgaHJlZj0iImh0dHA6Ly90Z3RmaWxlcy50 YXJnZXQuY29tL2V2ZXJlc3RfZHZtX3Nwb3RsaWdodF92Mi9fdWkvY3NzL0lFNzhiLmNzcyM/bG5r PU90aGVyXzA4MDMxNF9IUF8wX0U5XzIyXzZfMjAxNHxFOXxUOlRlbXBsYXRlX0hvbWU1fEM6Q01T JmludGM9MTg2ODU1M3xudWxsIiIgcmVsPSIic3R5bGVzaGVldCIiIHR5cGU9IiJ0ZXh0L2NzcyIi IC8+IgpodHRwOi8vd3d3LnNhbGVzZm9yY2UuY29tLyxodHRwOi8vd3d3LnNhbGVzZm9yY2UuY29t LywiPGxpbmsgcmVsPSIic3R5bGVzaGVldCIiIHR5cGU9IiJ0ZXh0L2NzcyIiIG1lZGlhPSIiYWxs IiIgaHJlZj0iImh0dHA6Ly93d3cyLnNmZGNzdGF0aWMuY29tL2NvbW1vbi9hc3NldHMvY3NzL2hl YWRlci0yMDEyMDMtcmV0cm9maXQuY3NzIiIgLz4iCmh0dHA6Ly93d3cucXVpa3IuY28uaW4vLGh0 dHA6Ly93d3cucXVpa3IuY29tLywiPGxpbmsgcmVsPSIic3R5bGVzaGVldCIiIHR5cGU9IiJ0ZXh0 L2NzcyIiIGhyZWY9IiJodHRwOi8vdGVqYTEua3Vpa3IuY29tL2Nzcy9zdHlsZS5jc3M/cj0xMjEy Mjk5OTExMjEyMTIiIj4iCmh0dHA6Ly93d3cuZWJheS5wdC8saHR0cDovL3d3dy5lYmF5LmNvbS8s IjxsaW5rIHJlbD0iInN0eWxlc2hlZXQiIiB0eXBlPSIidGV4dC9jc3MiIiBocmVmPSIiaHR0cDov L2lyLmViYXlzdGF0aWMuY29tL3JzL3YvM3pwMDRlZGZ4MjRodGt4MXd0ZGlwZW9mMDJpLmNzcz9w cm9jPURVOk4iIj4iCmh0dHA6Ly93d3cuZWJheS5kZS8saHR0cDovL3d3dy5lYmF5LmRlLywiPGxp bmsgcmVsPSIic3R5bGVzaGVldCIiIHR5cGU9IiJ0ZXh0L2NzcyIiIGhyZWY9IiJodHRwOi8vaXIu ZWJheXN0YXRpYy5jb20vaGVhZGVyL2Nzcy9nbGIuaWVsdDk/Y29tYm89MTEmZHM9MyZzaXRlaWQ9 NzcmcnZyPTEuMC4wJmZhY3Rvcj1HSENPTEwmaD0xMDQyNTQiIj4iCmh0dHA6Ly93d3cuZmFyc25l d3MuY29tLyxodHRwOi8vd3d3LmZhcnNuZXdzLmNvbS8sIjxsaW5rIGhyZWY9IiIvYmFubmVyL01h aW5QYWdlL1RvcC9uYXZpZ2F0ZS5jc3MiIiByZWw9IiJzdHlsZXNoZWV0IiIgLz4iCmh0dHA6Ly93 d3cubnl0aW1lcy5jb20vLGh0dHA6Ly93d3cubnl0aW1lcy5jb20vLCI8bGluayByZWw9IiJzdHls ZXNoZWV0IiIgdHlwZT0iInRleHQvY3NzIiIgaHJlZj0iImh0dHA6Ly9ncmFwaGljczgubnl0aW1l cy5jb20vbmV3c2dyYXBoaWNzLzIwMTQvMDgvMTUvZ2Vhci1ocC0zNzUvYzg1MzUwMjJhMTI2MDRk ZDUwYmRmMjJlYjZmMGI4MmUyZGNmNTNmZi9idWlsZC5jc3MiIj4iCmh0dHA6Ly93d3cudGVlcHIu Y29tLyxodHRwOi8vd3d3LnRlZXByLmNvbS8sIjxsaW5rIHJlbD1zdHlsZXNoZWV0IHR5cGU9IiJ0 ZXh0L2NzcyIiIG1lZGlhPXNjcmVlbiBocmVmPSIiaHR0cDovLzEtcHMuZ29vZ2xldXNlcmNvbnRl bnQuY29tL2gvd3d3LnRlZXByLmNvbS93cC1jb250ZW50L3BsdWdpbnMvZHJlYW1ncm93LXNjcm9s bC10cmlnZ2VyZWQtYm94L3RlbXBsYXRlcy9jbGVhbl93aGl0ZS9BLnN0eWxlLmNzcyxxM2I0YTk1 LnBhZ2VzcGVlZC5jZi54cWx5STJNakZ6LmNzcyIiLz4iCmh0dHA6Ly93d3cuYW1hem9uLmNuLyxo dHRwOi8vd3d3LmFtYXpvbi5jbi8sIjxsaW5rIHJlbD0iInN0eWxlc2hlZXQiIiB0eXBlPSIidGV4 dC9jc3MiIiBocmVmPSIiaHR0cDovL2ctZWM0LmltYWdlcy1hbWF6b24uY29tL2ltYWdlcy9HLzI4 L3plaXRnZWlzdC9zdGF0aWMvY3NzL3plaXRnZWlzdC1jaGFydC4yLl9WMTY0NTE1ODQzXy5jc3Mi IiAvPiIKaHR0cDovL3d3dy52aXByZWZlcnMuY29tLyxodHRwOi8vd3d3LnlhbmRleC5ydS8sIjxs aW5rIHR5cGU9IiJ0ZXh0L2NzcyIiIHJlbD0iInN0eWxlc2hlZXQiIiBocmVmPSIiLy95YXN0YXRp Yy5uZXQvd3d3LzIuMTkvcmFwaWRvL3BhZ2VzL2JpZy9fYmlnLmljb25zLmNvbWJvLmNzcyIiPiIK aHR0cDovL3d3dy5jYXJlZXJidWlsZGVyLmNvbS8saHR0cDovL3d3dy5jYXJlZXJidWlsZGVyLmNv bS8sIjxsaW5rIHJlbD0iInN0eWxlc2hlZXQiIiB0eXBlPSIidGV4dC9jc3MiIiBocmVmPSIiaHR0 cDovL2ltZy5pY2Jkci5jb20vaW1hZ2VzL29waW5pb25sYWJzL29ubGluZW9waW5pb252NTcxL29v X3N0eWxlLmNzcyIiIC8+IgpodHRwOi8vd3d3LmFzb3MuY29tLyxodHRwOi8vd3d3LmFzb3MuY29t LywiPGxpbmsgbXBkaXNuYXYgaHJlZj0iImh0dHA6Ly9pbWFnZXMuYXNvcy5jb20vY3NzL2NyZWF0 aXZlL2dsb2JhbC1iYW5uZXItYWx0LXYzMS5jc3MiIiByZWw9IiJzdHlsZXNoZWV0IiIgdHlwZT0i InRleHQvY3NzIiIgbWVkaWE9IiJhbGwiIiAvPiIKaHR0cDovL3d3dy5tYWtlbXl0cmlwLmNvbS8s aHR0cDovL3d3dy5tYWtlbXl0cmlwLmNvbS8sIjxsaW5rIHJlbD0iInN0eWxlc2hlZXQiIiB0eXBl PSIidGV4dC9jc3MiIiBocmVmPSIiLy9jc3MubW10Y2RuLmNvbS9zc29oZHIvY3NzL2NoLmNzcz82 IiIvPiIKaHR0cDovL3d3dy5nbXcuY24vLGh0dHA6Ly93d3cuZ213LmNuLywiPGxpbmsgcmVsPSIi c3R5bGVzaGVldCIiIHR5cGU9IiJ0ZXh0L2NzcyIiIGhyZWY9IiJodHRwOi8vaW1nLmdtdy5jbi9p bWFnZXMvMTAxMDEuZmlsZXMvY3NzLzIwMTJfaW5kZXguY3NzIiIvPiIKaHR0cDovL3d3dy5rYXNr dXMuY28uaWQvLGh0dHA6Ly93d3cua2Fza3VzLmNvLmlkLywiPGxpbmsgaHJlZj0iImh0dHA6Ly9j ZG4ua2Fza3VzLmNvbS90aGVtZXNfMy4wL3N0eWxlc2hlZXRzL3F1aWNraWUvaW50cm9qcy5jc3Mi IiByZWw9IiJzdHlsZXNoZWV0IiIgdHlwZT0iInRleHQvY3NzIiIgbWVkaWE9IiJhbGwiIiAvPiIK aHR0cDovL3d3dy53YWxsbWFydC5jb20vLGh0dHA6Ly93d3cud2FsbWFydC5jb20vLCI8bGluayBy ZWw9c3R5bGVzaGVldCBocmVmPSIiaHR0cDovL3AxM24tYXNzZXRzLndhbG1hcnQuY29tL3N0eWxl cy9pcnMuMS4xLjM0LmNzcyIiPiIKaHR0cDovL3d3dy5nb2RhZGR5LmNvbS8saHR0cDovL3d3dy5n b2RhZGR5LmNvbS8sIjxsaW5rIGhyZWY9IiJodHRwczovL2ltZzEud3NpbWcuY29tL2Zvcy9saXZl cGVyc29uL2Nzcy9jaGF0LXdpbmRvd18yMDE0MDIwNS5jc3MiIiByZWw9IiJzdHlsZXNoZWV0IiIg dHlwZT0iInRleHQvY3NzIiIgLz4iCmh0dHA6Ly93d3cuYXNvcy1tZWRpYS5jb20vLGh0dHA6Ly93 d3cuYXNvcy5jb20vLCI8bGluayBtcGRpc25hdiBocmVmPSIiaHR0cDovL2ltYWdlcy5hc29zLmNv bS9jc3MvY3JlYXRpdmUvZ2xvYmFsLWJhbm5lci1hbHQtdjMxLmNzcyIiIHJlbD0iInN0eWxlc2hl ZXQiIiB0eXBlPSIidGV4dC9jc3MiIiBtZWRpYT0iImFsbCIiIC8+IgpodHRwOi8vd3d3LnNvLmNv bS8saHR0cDovL3d3dy5zby5jb20vLCI8bGluayByZWw9IiJzdHlsZXNoZWV0IiIgaHJlZj0iImh0 dHA6Ly9zMS5xaGltZy5jb20vaTM2MC87Y3NzO2luZGV4X3BvcC92MzIwMy5jc3MiIj4iCmh0dHA6 Ly93d3cuZWJheS5lcy8saHR0cDovL3d3dy5lYmF5LmVzLywiPGxpbmsgcmVsPSIic3R5bGVzaGVl dCIiIHR5cGU9IiJ0ZXh0L2NzcyIiIGhyZWY9IiJodHRwOi8vaXIuZWJheXN0YXRpYy5jb20vaGVh ZGVyL2Nzcy9nbGIuaWVsdDk/Y29tYm89MTEmZHM9MyZydnI9MS4wLjAmZmFjdG9yPUdIQ09MTCZz aXRlaWQ9MTg2Jmg9MTA0MjU1IiI+IgpodHRwOi8vd3d3LmViYXkuaXQvLGh0dHA6Ly93d3cuZWJh eS5pdC8sIjxsaW5rIHJlbD0iInN0eWxlc2hlZXQiIiB0eXBlPSIidGV4dC9jc3MiIiBocmVmPSIi aHR0cDovL2lyLmViYXlzdGF0aWMuY29tL2hlYWRlci9jc3MvZ2xiLmllbHQ5P2NvbWJvPTExJmRz PTMmcnZyPTEuMC4wJmZhY3Rvcj1HSENPTEwmc2l0ZWlkPTEwMSZoPTEwNDI1NSIiPiIKaHR0cDov L3d3dy5ha3dvcy5jb20vLGh0dHA6Ly93d3cuaG9zdGdhdG9yLmNvbS8sIjxsaW5rIHJlbD0iInN0 eWxlc2hlZXQiIiBocmVmPSIiL2Nzcy90ZXJtcy1vdmVybGF5cy5jc3MiIj4iCmh0dHA6Ly93d3cu YWt3b3MuY29tLyxodHRwOi8vd3d3Lmhvc3RnYXRvci5jb20vLCI8bGluayByZWw9IiJzdHlsZXNo ZWV0IiIgaHJlZj0iIi9jc3MvdGVybXMtb3ZlcmxheXMuY3NzIiI+IgpodHRwOi8vd3d3LmViYXku ZGsvLGh0dHA6Ly93d3cuZWJheS5jb20vLCI8bGluayByZWw9IiJzdHlsZXNoZWV0IiIgdHlwZT0i InRleHQvY3NzIiIgaHJlZj0iImh0dHA6Ly9pci5lYmF5c3RhdGljLmNvbS9ycy92LzN6cDA0ZWRm eDI0aHRreDF3dGRpcGVvZjAyaS5jc3M/cHJvYz1EVTpOIiI+IgpodHRwOi8vd3d3LmViYXkucnUv LGh0dHA6Ly93d3cuZWJheS5jb20vLCI8bGluayByZWw9IiJzdHlsZXNoZWV0IiIgdHlwZT0iInRl eHQvY3NzIiIgaHJlZj0iImh0dHA6Ly9pci5lYmF5c3RhdGljLmNvbS9ycy92LzN6cDA0ZWRmeDI0 aHRreDF3dGRpcGVvZjAyaS5jc3M/cHJvYz1EVTpOIiI+IgpodHRwOi8vd3d3LmNpdHktZGF0YS5j b20vLGh0dHA6Ly93d3cuY2l0eS1kYXRhLmNvbS8sPGxpbmsgcmVsPSdzdHlsZXNoZWV0JyBocmVm PSdodHRwOi8vcGljczMuY2l0eS1kYXRhLmNvbS9qcy9tYXBzLzczMi9ib3hNYXAuY3NzJyAvPgpo dHRwOi8vd3d3Lndvb2R3b3JraW5nLmNvbS8saHR0cDovL3d3dy5nb2RhZGR5LmNvbS8sIjxsaW5r IGhyZWY9IiJodHRwczovL2ltZzEud3NpbWcuY29tL2Zvcy9saXZlcGVyc29uL2Nzcy9jaGF0LXdp bmRvd18yMDE0MDIwNS5jc3MiIiByZWw9IiJzdHlsZXNoZWV0IiIgdHlwZT0iInRleHQvY3NzIiIg Lz4iCmh0dHA6Ly93d3cub2Rub2tsYXNuaWtpLnJ1LyxodHRwOi8vd3d3Lm9kbm9rbGFzc25pa2ku cnUvLCI8bGluayByZWw9IiJzdHlsZXNoZWV0IiIgdHlwZT0iInRleHQvY3NzIiIgaHJlZj0iImh0 dHA6Ly9zdC5teWNkbi5tZS9yZXMvY3NzL3Byb2QvbG9naW4vbG9naW5fb2tydS5hOWY4MjMzNS5j c3MiIj4iCg==