Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Reconsider making <style> in body valid #5019

Closed
prlbr opened this issue Oct 18, 2019 · 4 comments
Closed

Reconsider making <style> in body valid #5019

prlbr opened this issue Oct 18, 2019 · 4 comments
Labels
document conformance topic: style

Comments

@prlbr
Copy link

prlbr commented Oct 18, 2019 •
edited
Loading

Authors of content management systems of various kinds, e.g. Wordpress, often do not have access to the head of HTML. Plugins/widgets do not have access to the <head> in some software either. If they want to apply styles anyway, authors and plugins have the following options:

  1. Use <style> in the body, which
  • works in every browser
  • but makes the web page invalid according to HTML as of now, because
  • it is said by some to make initial rendering not as smooth as it should be, while some of the biggest websites in the world such as Google.com have demonstrated for years that it is not a relevant problem in practice and continues to do so
  1. Use style attributes on the elements, which
  • work in every browser
  • is valid
  • but can bloat the HTML by becoming highly repetitive
  • claims highest CSS specifity, which may not be desired by a plugin/widget, which only wants to provide a default style, but is fine with website themes overruling it
  1. Use ShadomDOM
  • which does not work in every browser, e.g. when JavaScript is deactivated
  • is valid, despite having <style> in the body
  • also inhibts themes overruling default styles of plugins/widgets, which may not be desired
  1. Use <link rel=stylesheet>
  • which works in every browser
  • is valid in HTML in the body
  • but makes initial rendering of the page very noticably less smooth, because browsers only start fetching the stylesheet over the internet after the page has half rendered, and is against recommendations by some of the biggest web specialists like Google which state that styles for the initial page view should ideally be included in the HTML

The best option for me as a plugin author, who wants theme authors to be able to make my plugin fit nicely into their design, – and the best option for users – is the first option, which is the only one that is invalid.

The best currently valid option for me would be 4., although it actually makes initial rendering ugly. I don’t know why it is valid and 1. is not.

A 5th option would be to ask CMS to always give authors and plugins access to the HTML head. Realistically, not every CMS will do it, especially since it would complicate the CMSes for spec conformity and not for apparent practical benefits.

Are there other options?

Note: <style> has been valid in the body in W3C HTML 5.2 (https://www.w3.org/TR/html52/document-metadata.html#the-style-element). Is this relevant here now that WHATWG and W3C have decided to work together on a single spec again?
@annevk
Copy link
Member

annevk commented Oct 18, 2019

3 is tracked by #4344. The remainder seems like a rehash of #1605?

I also don't really see what would be so bad about 5, why would separation of concerns not apply to their infrastructure?

@prlbr
Copy link
Author

prlbr commented Oct 18, 2019 •
edited
Loading

Three reasons for CMS not to do it:

  • It makes the CMS code more complex.
  • More controls for users may hurt a desire for simplicity – many programs start as a simple alternative to something that is perceived as having become bloated with mostly unnecessary options, then becoming more complex over time themselves.
  • While it is a seperation of concerns from the HTML&CSS perspective, it can be seen as the opposite from a different perspective: some core/theme/plugin/author supplied code gets mixed in the head, some of which is used site-wide and some that is page-specific, and other core/theme/plugin/author content gets mixed in the body. My priority for intance is not to keep all CSS together and apart from the rest, but to keep all widget supplied code together and separated from the rest.

I don’t mean to say that it is bad when CMSes do 5 though. I am concerned about the practical situation when they don’t.

@domenic
Copy link
Member

domenic commented Oct 18, 2019 •
edited
Loading

Since this is a rehash, we'll close it; all the relevant discussions have been had in #1605, and the conclusion remains.

It is true that CMS code will need to get more complex, possible at the cost of simplicity, in order to attain the good performance that the HTML spec works to encourage via its conformance requirements. That is our current recommendation. I.e., CMSs which do not do 5, are not able to produce compliant HTML, and the best way to fix that is to file bugs on CMSs, not on the HTML Standard.

@domenic domenic closed this as completed Oct 18, 2019
@prlbr
Copy link
Author

prlbr commented Oct 18, 2019

Okay, thank you for the feed back.

@oliviertassinari oliviertassinari mentioned this issue Nov 3, 2019
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
document conformance topic: style
Milestone
No milestone
Development

No branches or pull requests
3 participants
@domenic @annevk @prlbr