Seeking input on authoring conformance for <style>-in-body
164 views
Skip to first unread message
d...@domenic.me
Feb 6, 2017, 4:23:56 PM2/6/17
to style-dev
Hi style-dev,
The HTML spec has a long-standing issue on changing the authoring conformance requirements around <style> in <body>. That is, the rules that HTML validators/conformance checkers use to tell authors if they're doing a good or bad thing. (This is entirely separate from the processing model, which gives well-defined behavior for <style> no matter where it appears.)
Currently the spec does not allow <style> in body, on the reasoning that it causes flashes of unstyled content and relayouts and such. But it was noted that using <style>-in-body is very popular. Are all these large sites doing <style> in body despite its drawbacks? Or, perhaps, are these not drawbacks these days?
My question to the knowledgeable people of style-dev is: if you could give advice to authors about where to place their <style> elements, what would you say? <style> in <head> only? Maybe <style> before any of the elements it affects? No restrictions, just put it anywhere? We'd like to update the authoring conformance requirements from a position of knowledge, instead of just carrying on the tradition of no-style-in-body without being sure whether it's applicable any more.
Thanks!
-Domenic
The HTML spec has a long-standing issue on changing the authoring conformance requirements around <style> in <body>. That is, the rules that HTML validators/conformance checkers use to tell authors if they're doing a good or bad thing. (This is entirely separate from the processing model, which gives well-defined behavior for <style> no matter where it appears.)
Currently the spec does not allow <style> in body, on the reasoning that it causes flashes of unstyled content and relayouts and such. But it was noted that using <style>-in-body is very popular. Are all these large sites doing <style> in body despite its drawbacks? Or, perhaps, are these not drawbacks these days?
My question to the knowledgeable people of style-dev is: if you could give advice to authors about where to place their <style> elements, what would you say? <style> in <head> only? Maybe <style> before any of the elements it affects? No restrictions, just put it anywhere? We'd like to update the authoring conformance requirements from a position of knowledge, instead of just carrying on the tradition of no-style-in-body without being sure whether it's applicable any more.
Thanks!
-Domenic
Ben Maurer
Feb 8, 2017, 3:13:49 PM2/8/17
to style-dev, d...@domenic.me
Hey --
Would this also apply to <link> tags that referred to external stylesheets?
Facebook renders the page incrementally -- we don't always know what styles we need by the time we flush the head. Right now we tend to do this by having the incrementally rendered parts of the page use JS to insert the link tags into the head. But for some authors it might make more sense just to inline link and style elements.
We give internal users guidance along the lines of:
(1) If you have style/link inline in the document ensure that any content that uses that content below the style tag
(2) If you dynamically insert content that uses a style do so only after the onload event of the style
(3) Generalizing 1 and 2, any time a stylesheet is loaded it should never style any elements currently displayed on the page
(4) As an exception to (3) it's ok if your stylesheet is designed not to cause re-layout (eg if you have <span class="sprite1" style="height:16px;width:16px"> its ok to load a stylesheet which defines the location of the image).
-b
dom...@chromium.org
Feb 8, 2017, 3:21:03 PM2/8/17
to style-dev, d...@domenic.me
On Wednesday, February 8, 2017 at 3:13:49 PM UTC-5, Ben Maurer wrote:
Hey --Would this also apply to <link> tags that referred to external stylesheets?
No, this is solely about <style>.
Facebook renders the page incrementally -- we don't always know what styles we need by the time we flush the head. Right now we tend to do this by having the incrementally rendered parts of the page use JS to insert the link tags into the head. But for some authors it might make more sense just to inline link and style elements.We give internal users guidance along the lines of:(1) If you have style/link inline in the document ensure that any content that uses that content below the style tag(2) If you dynamically insert content that uses a style do so only after the onload event of the style(3) Generalizing 1 and 2, any time a stylesheet is loaded it should never style any elements currently displayed on the page(4) As an exception to (3) it's ok if your stylesheet is designed not to cause re-layout (eg if you have <span class="sprite1" style="height:16px;width:16px"> its ok to load a stylesheet which defines the location of the image).
Thanks for the interesting info!
Rune Lillesveen
Feb 13, 2017, 5:36:29 AM2/13/17
to d...@domenic.me, style-dev
It depends on how well the browser is able to detect which elements need their computed styles recalculated when a sheet is added, and if you do your first paint or force a computed style calculation before parsing the in-body style element.
Consider this:
<!DOCTYPE html>
<style> ... </style>
<div id="does-not-contain-my-class">
<div> ... </div>
</div>
<script>
document.body.offsetTop;
</script>
<style>.myclass { color: green }</style>
<span class="myclass"></span>
Here, we force a style recalc, but that style recalc could have been caused by generating a frame after yielding the html parser when nothing is blocking rendering. Now, ideally, adding the .myclass sheet should not cause recalculation of anything in #does-not-contain-my-class, but that varies between browsers. It also depends on what types of selectors the added stylesheet includes (at least in Blink). When I grow the #does-not-contain-my-class subtree, Gecko typically increases the execution time of the recalc following the addition of the last style element, while Blink doesn't. If the .myclass sheet was in <head>, you would not have seen any recalcs for elements in #does-not-contain-my-class.
In short, I think you can say that the placement of <style></style> does not matter as long as you don't calculate any computed styles before it's parsed. If you force a computed style calculation, or if a frame is generated (triggering a computed style generation) before the style element is parsed, it depends on your stylesheet selectors, and how well each browser is able to skip preceding elements not affected by those selectors.
Rune Lillesveen
davewa...@gmail.com
Jul 5, 2020, 11:19:19 AM7/5/20
to style-dev, d...@domenic.me
Form follows function. If, during development, careful thought about all aspects of a particular situation reveals that it is best to put a <style> tag in a particular place, then that is good. If someone says (or implies) they have thought of all possible situations, that is bad.
Reply all
Reply to author
Forward
0 new messages