make <style> in <body> conforming #544
Comments
|
As I understand it, #516 asks for an editorial change that would make a non-normative part of the spec be consistent with a normative part of the spec. It’s about consistency in the spec, not about which behaviour is desirable. So I think that’s neither the same nor the converse of this issue here. But I see that the discussion in #516 actually goes in the direction of discussing which behaviour is desirable, so this question could indeed be covered there. But will it be? Or is someone going to say: “That’s not what this issue is about, please open a new one for your request”? Will people whom this issue here concerns find that other issue, if the other issue’s title and initial post don’t reflect what’s discussed there? Those are questions that make me feel uneasy about closing this one here. Not sure what to do. |
|
To be clear, |
|
Agreed, this seems to be in widespread use so the reality of the web... Would you like to propose some text, or even a PR? |
|
I'm closing this as a duplicate of #516 - where the "trending conclusion" is to make style conforming in the body... Thanks for raising it in this form though - I think it helped the discussion. |
|
Will it be clear for authors that the "effect" of style elements in body is
neither limited to the "scope" element, nor to the code after the style
element itself, but it will rather affect the whole document?
I'm especially concerned by the fact that as style appears late in the
page, phenomena of FOUC can become harder and more likely.
Style in DOM is due to poor CMS coding rather than to real user practices.
|
|
As @travisleithead commented in #516 (comment), if |
|
@AndySky21 given that browsers have already worked this way for a couple of decades, I suspect authors are not likely to start getting confused now. |
|
@AndySky21 I disagree, to me it's pretty obvious that the style flickering is due to poor CMS coding, not that the style tag in body behaves the way that it is expected to behave. |
|
Appears we have agreement to document it as conforming as per existing browser behaviour. @prlbr would you like to propose some text? |
|
I guess not much text is needed, but the definition box of the element needs to be changed to allow I don’t feel ready to make these changes and would be happy if someone more knowledgable with the spec could take care of this. Thank you for the offer though, @adanilo! |
|
Also being discussed in whatwg world whatwg/html#1605 |
|
Here's a fun idea to think about: Imagine if a browser comes along that
complies with the spec fully (meaning it won't support style in body at all)
…On 25 February 2017 at 12:16, stevefaulkner ***@***.***> wrote:
Also being discussed in whatwg world whatwg/html#1605
<whatwg/html#1605>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#544 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AMN7xhuPr-jyPQfQ2tZTrTxz-24HqIPtks5rgA2jgaJpZM4JXU-L>
.
|
|
@workguy66 That's exactly what we think about. If the spec is ambiguous here, it isn't clear exactly what they would do. But it turns out that a browser that didn't allow We have an option to make it non-conforming but require browsers to handle it, and describe how to do that - this is what we do for a bunch of things, including appcache. But there are use cases for doing it, and no clear reason I can see to prohibit it, although it's often not the best idea. |
|
Instead of being marked "non conforming but supported", which sounds quite strange, why not marking it "conforming with warning"? I.e. when validated (and in spec) it should be stated that putting style in body can be done, but as last resort only and underlining the problem that can be caused by that (essentially FOUC if tons of content are loaded before style itself is parsed and applied). After all, if UAs have learnt how to cope with that, now it's just a matter of usability trade-off. Not to mention all the CMSs, hubs and platforms which physically do not allow authors to insert whatever they want inside the document's head. |
|
@chaals and @workguy66, you say that a fully-compliant browser wouldn't support
(emphasis mine) I'm not sure precisely what @domenic's reasoning is for how the spec requires this, and don't know whether there are relevant differences between the W3C and WhatWG specs in this regard, but it seems that he disagrees with you. |
|
The spec requires the browsers to support it and then tells people not to
use it? Would make more sense if it warned people not to use it.
…On 28 February 2017 at 22:25, Mark Amery ***@***.***> wrote:
@chaals <https://github.com/chaals> and @workguy66
<https://github.com/workguy66>, you say that a fully-compliant browser
wouldn't support <style> in the body at all, but according to @domenic
<https://github.com/domenic> in whatwg/html#1605 (comment)
<whatwg/html#1605 (comment)>:
just to be very clear: this entire issue is not about changing browser
behavior. *The spec already requires, and browsers already implement,
processing for <style> in body*. It works, albeit with the negative
effects I discussed above.
(emphasis mine)
I'm not sure precisely what @domenic <https://github.com/domenic>'s
reasoning is for how the spec requires this, and don't know whether there
are relevant differences between the W3C and WhatWG specs in this regard,
but it *seems* that he disagrees with you.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#544 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AMN7xjP3ZnTaLlWdbT4HMt2bLvVV45Lnks5rhJDXgaJpZM4JXU-L>
.
|
pointing out that use in the body can trigger unwanted side effects. See Issue w3c#544.
|
|
pointing out that use in the body can trigger unwanted side effects. See Issue #544.
* Added note that removes the restriction of <style> in <head> but pointing out that use in the body can trigger unwanted side effects. See Issue #544. * Added style to the set of flow content elements.
* Added note that removes the restriction of <style> in <head> but pointing out that use in the body can trigger unwanted side effects. See Issue w3c#544. * Added style to the set of flow content elements.
|
The element box for the style element says for “Contexts in which this element can be used”:
I think this should be changed to where flow content is expected. |
see #544 - this is cleaning up the change already made.
|
@prlbr agreed. I made a PR - feel free to review it... |
|
Looks good, thank you! |
see #544 - this is cleaning up the change already made.
* Added note that removes the restriction of <style> in <head> but pointing out that use in the body can trigger unwanted side effects. See Issue #544. * Added style to the set of flow content elements. * Partial commit for adding referrerpolicy. * Hard set for non-binary on the .include files, fixes merge pain. * Added attribute to stop git treating text files as binary. * Added referrer policy attribute for link reference resource fetch * Ported the commits from issue #560. Next, find other commits that this needs for completeness (attribute defs, IDL, etc.) * Addded definition section for referrer policy * Added a few more referrerpolicy references. * Bulk of referrerpolicy changes, check in for backup in reality. * Fixed up a bunch of link errors. * Fixed a few more linking errors, fixed typo. * Changes as per review, plus some markup cleanup.
Please consider making
<style>in<body>conforming.<style>in<body>apparently works in all major browsers<head>at all or at least not easily on a page by page basisSee the corresponding issue at WHATWG by @workguy66.
The text was updated successfully, but these errors were encountered: