<style></style> tags within the body??

Report · Jun 01, 2021

Doing a bit more research about the <style> element. According to the w3.org website <style></style> tags CAN be used:

'In the body, where flow content is expected.'

https://www.w3.org/TR/html52/document-metadata.html#the-style-element

Is this correct. I always thought they could only be used in the <head></head> section of the page or is this some relic fact that's got stuck in my head and most other developers heads from a bygone age??????

This would be of interest as it means I can create simple web-components and keep all the css/html and js together in one file, without having to use the more complex shadow-dom to create web-components or one of the front end frameworks.

Report · Jun 01, 2021

I have only ever seen it used in HTML e-mails.

Nancy O'Shea— Product User, Community Expert & Moderator

Report · Jun 01, 2021

I have only ever seen it used in HTML e-mails.

By @Nancy OShea

Yeah, I'm just looking for new weird and wonderful ways of doing things, which might make the process a bit more convenient, without infringing too many rules. I guess I'll now consider using <styles> in the <body> as something that could be useful, with the knowledge its not breaking with approved practices.

I'm only considering it as a possibility because I want to try and move more down the route of producing simple 'components' where everything lives together, rather than having the code split up into 2 or 3 different files, which is obviously more to manage. I'm not into front-end javascript frameworks where this can already be done and I'm a little put-off by the lack of uptake for real web-components, maybe on account of frameworks or the workflow is a bit obtuse getting involved with shadow dom/root etc.

Report · Jun 01, 2021

This would be of interest as it means I can create simple web-components and keep all the css/html and js together in one file, without having to use the more complex shadow-dom to create web-components or one of the front end frameworks.

By @osgood_

https://developer.mozilla.org/en-US/docs/Web/Web_Components

Report · Jun 02, 2021

This would be of interest as it means I can create simple web-components and keep all the css/html and js together in one file, without having to use the more complex shadow-dom to create web-components or one of the front end frameworks.

By @osgood_

https://developer.mozilla.org/en-US/docs/Web/Web_Components

By @B i r n o u

Yes, I know all about 'real' web-components BUT I'm trying to avoid the extra layer of engineering required to get at elements and create elements using the shadow dom. It seems like an overly engineered process just to include a web-component to me. This is perhaps why the uptake is not as great as I would have thought, or it could be that js frontend frameworks just make the process easier, but I'm trying to avoid any kind of dependency.

I know you can achieve more with 'real' web components like pass information through and create slots, which is nice but if I could just keep all the css/js/html in the one file instead of splitting the code up at the end of my production process (as you know I tend to keep everything in one file anyway, until the end of the build process) it might be more convenient to me to only have to manage the one file, where all the code needed is nicely grouped together. I'm just considering the workflow, it might end up being more convoluted than the process I use now.

As <style></style> tags CAN be included in the <body></body> (a little known fact, it seems), this makes things very easy, without having to resort to using the shadow dom or frameworks, when creating simple components. I can just either link a js file or include a php file. The source code looks hugley messy if I link to a php include file, but who the hell cares. I won't be working much in the combined file that gets built in the browser, it will just be the component pages I'll be working on mostly.

Report · Jun 07, 2021

Because you can does not mean you should.

Both forms of inline style be it in those tags and inline elements have massive consiquences on the stylesheets that should be driving the ruleset styles of the application or website becayse they will overide those styles in regard to the Cascading Order.

If you develop a plugin or extension the applicatoin or platform will drive how you do that. In most cases such platforms that offer this will have a solution for that, often in the best optimial semantic way.

In any regard the most common practice will be to inject a stylesheet into the head which can be accomplished by how a platform/CMS manages the head, server side coding or Javascript.

Other factors to why such a method mentioned here is not a good idea comes with JS and CSS minification processes which you should be doing these days. Compressing and compiling bulk CSS will not occur with a lot of inline styles.

Inline styles really should only be used for emails and small uses cases where a background image for example is driven from data from a platform/CMS etc.

Report · Jun 07, 2021

If the specs say you can then you can, simple as that, period. Now whether you do or not is a matter of personal opinion. I would not recommed it if you are not an advanced developer because you probably would not yet have discovered why this workflow could be put to good use.

I actually use the workflow a lot of the time when a website is in production and l'm building a component such as a nav or slider etc The advantage is it keeps the css and html closer together, allowing for a fast workflow rather than the css being in a different file or the head of the page. This results in less switching of files or having to keep jumping to the top of the page where the embedded css would normally be included and less file management.

Personally lve found there are no disadvantages the way l work which is in a controlled fashion. In the past lve moved the css to an external source at the end of the component build because lve been led to believe that is the correct workflow by the lemmings we all follow until l decided wouldnt it be great to be able to include the css styling, javascript and html in one neatly pakaged component file. This is where web components and the shadow dom should make life easier but it doesnt, it just adds another layer of uneeded complexity to the workflow.

All l needed was to be able to legitimately keep the css with the html which the specs confirm you can do, so its easy to put all the code associated with a component in one single file, a php include file or bring it all in using a javascript file if you dont require any php.

These days the old rule book has been torn up and thrown out the window. Todays developers are free spirits, more or less doing what they want which browsers allow and thats always been this sectors downfall, there are no decisive rules to follow.

To address your issue about minifying css and javascript, yes if you are using a goofy framework with 9000 lines of code or a javascript plugin that does it all but when your css and javascript has been written specifically for the task there is no wastage or bloat, so no minifying is necessary.