how to change style of main page style with plugin? - wordpress

I am creating a plugin for my theme to customize it, But when I use PHP and I edit the style of main page when using post request, and I don't believe WP AJAX system is a way way to edit style of main page with hooks?
And can I create short codes in my theme, or can I only create it in plugin???

In the case of Wordpress, which is a CMS for web projects, styling is mainly done via writing CSS code and rendering that in the web-browser.
How to apply a styling
Inline
You can do inline styling (unadvisable), example:
<input type="text" value="something" style="color: red;">
The reason this is generally not a desirable practice is that you would always have to add the styling to each element you want to apply it at. This is a problem, because if you have a consistent styling, applied at liked 10 000 elements and then you intend to change it, you will have to apply it at every 10 000 instances of its inline definition.
You may still use inline styling at some point, but you should avoid doing so unless you are absolutely sure that it's adequate for the given problem you solve.
Style tags
You can also add a style tag to your page, which is better than inline styling in general, but it's more difficult to reuse it than a css file. Example:
<style type="text/css">
input.red {color: red;}
</style>
<input type="text" value="something" class="red">
css files
You could create a file like style.css, move your styling from style tags there and create a link tag, as
<link rel="stylesheet" href="styles/style.css">
Note that the code above assumes that there is a styles folder where you store your css files and that your style.css is inside that folder. This is a generally accepted practice about styling, which is a very popular approach.
There are some technologies violating this separation of CSS from structure, like ReactJS, which has a different approach for this stuff, but, if you do not use those SPA approaches (and at least while you learn Javascript and CSS it is a good idea to avoid them), then this is an advisable practice.
The approach
In all cases I will assume that you have a CSS file that you want to append to your head tag at styles/style.css. If you have some differences in your dev environment, then you of course will need to rely on what your environment is like.
Modifying a theme
You can modify your theme whenever you want to do so, it's available on source-code level. However, if it's a theme that is not customly made by you and you intend to use its new versions in the future, then it's advisable to avoid changing the source-code of your theme.
However, at the point when the HTML is generated and particularly the head tag, you can add the link tag as described earlier. As a matter of fact you can add it inside the body tag as well.
Modifying the plugin
If you use a plugin and some HTML is generated there that is applied to the page, you can easily add your link tag to that as well. However, if you are doing some AJAX requests and you determine whether you need the styling at that level, then you will need your Javascript to add a link tag to the head, example:
function addLink(path) {
document.querySelector('head').innerHTML += `<link rel="stylesheet" href="${path}">`;
}
However, this is to be avoided if you know in advance that your file will always be needed. If you want to dynamically change the styling by adding some stuff to it, then you can call the function above, passing the desired path.

Related

Gatsby.js: I set up a css rule for body for a template but it works throughout the entire app

I set up a background image with css (background-image) in the body tag of the template so that only shows in the pages generated with it, however that's affecting all 'body's in the entire gatsby.js website.
This is normal behavior. It's not a Gatsby issue. It's how React's templating/code-splitting works.
You are defining a CSS rule in your isolated CSS but it's bundled when the project is compiled (because of webpack) and because of the specificity, it affects all body tag. In the end, your template will be also injected into the output HTML so all the imports in it will also merge in the final output.
The easiest and most straightforward solution I think is to define a <section> (or another tag) just as a direct child of the body for each template/page you want to customize and give a specific class name to apply the CSS only to that template/page. Increasing the specificity is the easiest way to apply.
Soon, in the new Chromium version (99) we will be able to define layered components in order to enhance the specificity and improve that kind of behaviors you've described.

exclude theme from a specific container

I am making a theme for a website managed by plone using diazo and at least parts of twitter-bootstrap. Personally I'm not all too happy about that combination, but it was requested that way.
Now I was informed the other day that there will be some portlets that suppose to come in their own design, styled in an editor insinde plone (the editor seem to write the styles straight into the html). Meaning no further theming should be applied but bootstrap css recognizes the pattern and hijacks it anyway.
I tried to block that by using a form of <notheme css:if-content=".theStaticPortlet" /> but ended up having the theme blocked on the entire site whenever a container like this was found.
Is there a way of excluding a specific container/class from being bothered by the theme while everything around it stays themed like before?
With lesscss you can do something like that:
.theStaticPortlet {
// put your specific portlet css here
}
:not(.theStaticPortlet) {
// copy or import all your regular site css here
}
From what I understand your question is purely about Bootstrap and its CSS interfering with Plone markup. Exactly which styles are being applied on your portlet? I'd bet it has to do with the DL/DT/DD tags. If so you could use Diazo to replace those with DIVs or some other neutral tags - on Bootstrap's understanding, of course.

CSS Files and Unwanted Overriding

I have a simple HTML page that is referencing 3 CSS files. The first is a style sheet that is just for the page. The other two are for the styles of two unique modals. These modal CSS files were not created by me and they are happily being used separately on other pages throughout the site.
My problem is that both of these modal CSS files contain a few common selectors and so they are messing up each other's styles.
I understand that the best way to fix this problem is to take one or both of the files and make their selectors unique. One way would be to namespace the selectors.
My questions is, however, now that I'm knee-deep in this page, is there anyway to prevent these CSS conflicts without changing the modal CSS pages as they currently stand? Are there any tools that can help such as LESS? What is the best practice for preventing this in the future?
The best solution indeed would be to refactor those css-files to your need.
However, an easier solution would be to include your stylesheet after those two third-party css-files and re-declare the styles for the common selectors, which automatically overrides the previous settings.
LESS/SASS are excellent tools to help you write CSS faster and more comfortable. I use SASS for private work and really recommend it. They can't help you though with issues like you have atm.
EDIT:
Using !important is possible, but considered bad habit, as it was intended to give the user the possibility to override author-styles with his own. Instead of using !important what you should do is:
Avoid duplicate styles as much as you can.
if you can't avoid this, try to resolve this by either:
cascading (=using the proper sequence to override previous styles)
using selector specificity (W3C-Spec).
Assuming:
...
<link rel="stylesheet" href="this_page.css" />
<link rel="stylesheet" href="modal_1.css" />
<link rel="stylesheet" href="modal_2.css" />
...
Due to the cascading nature of CSS (sorry, I had to) using the same selector over and over overrides any previous styles. Thus, if modal_1.css and modal_2.css both apply style x to the body tag, for example, the second stylesheet will override the first.
The sad part is that there is no way out other than to, as you suggested, modify the two selectors to make them more specific.
Looking to the future, the best way to avoid overriding previously declared styles, is to always be specific about the particular element you are targeting, and it's proper place in the DOM. Note that LESS is simply a CSS preprocessor, which only allows you a different syntax for CSS.
I would suggest to a common class add into body tag of that particular page & target using that particular class. If you tools like LESS or Compass you can easily achieve the aim.
.pageOne{ /*All the styles for this perticular page*/
.header{
}
.sidebar{
}
}
When parse through LESS or Compass it will look like following.
.pageOne .header{}
.pageOne .sidebar{}
This way your page will get a namespace.

wikia template style attribute

I have made some templates on wikia.com, which contain only CSS code (key:value;).
My problem is having another template use these style templates in a style attribute tag.
style="{{MyTemplateStyle}}"
This code does not evaluate as expected. The CSS code is outputted before the element and the style attribute is not included inside the element.
Am I trying something not possible for a wiki ?
I merely want to be able to change styling on certain templates in one place, like regular HTML & CSS pages.
CSS styling specified from the style="" attribute always takes priority over any other css, even if you use !important in a CSS specification.
Therefore any edits you make to your CSS on Wikia will not ever override the CSS specified inside an attribute.
Kim, you were right to switch to classes instead of embedding in-line styles via templates.
The very idea of using templates suggest that this was going to be re-used in more than one place, applying styles to a group or, in fact, a class of elements.
This approach is much simpler to read and maintain (as you only have one, central place to edit), and also, if done right, will enable you to seamlessly change the colour scheme via Special:ThemeDesigner.

What's so bad about in-line CSS?

When I see website starter code and examples, the CSS is always in a separate file, named something like "main.css", "default.css", or "Site.css". However, when I'm coding up a page, I'm often tempted to throw the CSS in-line with a DOM element, such as by setting "float: right" on an image. I get the feeling that this is "bad coding", since it's so rarely done in examples.
I understand that if the style will be applied to multiple objects, it's wise to follow "Don't Repeat Yourself" (DRY) and assign it to a CSS class to be referenced by each element. However, if I won't be repeating the CSS on another element, why not in-line the CSS as I write the HTML?
The question: Is using in-line CSS considered bad, even if it will only be used on that element? If so, why?
Example (is this bad?):
<img src="myimage.gif" style="float:right" />
Having to change 100 lines of code when you want to make the site look different. That may not apply in your example, but if you're using inline css for things like
<div style ="font-size:larger; text-align:center; font-weight:bold">
on each page to denote a page header, it would be a lot easier to maintain as
<div class="pageheader">
if the pageheader is defined in a single stylesheet so that if you want to change how a page header looks across the entire site, you change the css in one place.
However, I'll be a heretic and say that in your example, I see no problem. You're targeting the behavior of a single image, which probably has to look right on a single page, so putting the actual css in a stylesheet would probably be overkill.
The advantage for having a different css file are
Easy to maintain your html page
Change to the Look and feel will be easy and you can have support for many themes on your pages.
Your css file will be cached on the browser side. So you will contribute a little on internet traffic by not loading some kbs of data every time a the page is refreshed or user navigates your site.
The html5 approach to fast css prototyping
or: <style> tags are no longer just for the head any more!
Hacking CSS
Let's say you're debugging, and want to modify your page-css, make a certain section only look better. Instead of creating your styles inline the quick and dirty and un-maintainable way, you can do what I do these days and take a staged approach.
No inline style attribute
Never create your css inline, by which I mean: <element style='color:red'> or even <img style='float:right'> It's very convenient, but doesn't reflect actual selector specificity in a real css file later, and if you keep it, you'll regret the maintenance load later.
Prototype with <style> instead
Where you would have used inline css, instead use in-page <style> elements. Try that out! It works fine in all browsers, so is great for testing, yet allows you to gracefully move such css out to your global css files whenever you want/need to! ( *just be aware that the selectors will only have page-level specificity, instead of site-level specificity, so be wary of being too general) Just as clean as in your css files:
<style>
.avatar-image{
float:right
}
.faq .warning{
color:crimson;
}
p{
border-left:thin medium blue;
// this general of a selector would be very bad, though.
// so be aware of what'll happen to general selectors if they go
// global
}
</style>
Refactoring other people's inline css
Sometimes you're not even the problem, and you're dealing with someone else's inline css, and you have to refactor it. This is another great use for the <style> in page, so that you can directly strip the inline css and immediate place it right on the page in classes or ids or selectors while you're refactoring. If you are careful enough with your selectors as you go, you can then move the final result to the global css file at the end with just a copy & paste.
It's a little hard to transfer every bit of css immediately to the global css file, but with in-page <style> elements, we now have alternatives.
In addition to other answers.... Internationalization.
Depending of the language of the content - you often need to adapt the styling of an element.
One obvious example would be right-to-left languages.
Let's say you used your code:
<img src="myimage.gif" style="float:right" />
Now say you want your website to support rtl languages - you would need:
<img src="myimage.gif" style="float:left" />
So now, if you want to support both languages, there's no way to assign a value to float using inline styling.
With CSS this is easily taken care of with the lang attribute
So you could do something like this:
img {
float:right;
}
html[lang="he"] img { /* Hebrew. or.. lang="ar" for Arabic etc */
float:left;
}
Demo
Inline CSS will always, always win in precedence over any linked-stylesheet CSS. This can cause enormous headache for you if and when you go and write a proper cascading stylesheet, and your properties aren't applying correctly.
It also hurts your application semantically: CSS is about separating presentation from markup. When you tangle the two together, things get much more difficult to understand and maintain. It's a similar principle as separating database code from your controller code on the server side of things.
Finally, imagine that you have 20 of those image tags. What happens when you decide that they should be floated left?
This only applies to handwritten code. If you generate code, I think that it's okay to use inline styles here and then, especially in cases where elements and controls need special treatment.
DRY is a good concept for handwritten code, but in machine-generated code, I opt for "Law of Demeter": "What belongs together, must stay together". It's easier to manipulate code that generates Style tags than to edit a global style a second time in a different and "remote" CSS file.
The answer to your question: it depends...
Using inline CSS is much harder to maintain.
For every property you want to change, using inline CSS requires you to look for the corresponding HTML code, instead of just looking inside clearly-defined and hopefully well-structured CSS files.
The whole point of CSS is to separate content from its presentation. So in your example you are mixing content with presentation and this may be "considered harmful".
In addition to the other answers, another concern is that it violates the recommended Content Security Policy from MDN, https://infosec.mozilla.org/guidelines/web_security#content-security-policy
The justification they use is that inline javascript is harmful, XSS, etc., but it doesn't justify why inline styles should also be disabled. Maybe someone can comment as to why, but until then, I'll just rely on appeal-to-authority and claim: it's a security best practice to avoid inline styles.
Code how you like to code, but if you are passing it on to someone else it is best to use what everyone else does. There are reasons for CSS, then there are reasons for inline. I use both, because it is just easier for me. Using CSS is wonderful when you have a lot of the same repetition. However, when you have a bunch of different elements with different properties then that becomes a problem. One instance for me is when I am positioning elements on a page. Each element as a different top and left property. If I put that all in a CSS that would really annoy the mess out of me going between the html and css page. So CSS is great when you want everything to have the same font, color, hover effect, etc. But when everything has a different position adding a CSS instance for each element can really be a pain. That is just my opinion though. CSS really has great relevance in larger applications when your having to dig through code. Use Mozilla web developer plugin and it will help you find the elements IDs and Classes.
I think that even if you want to have a certain style for one element, you have to consider the possibility that you may want to apply the same style on the same element on different pages.
One day somebody may ask to change or add more stylistic changes to the same element on every page. If you had the styles defined in an external CSS file, you would only have to make changes there, and it would be reflected in the same element in all of the pages, thus saving you a headache. :-)
Even if you only use the style once as in this example you've still mixed CONTENT and DESIGN. Lookup "Separation of concerns".
Using inline styles violates the Separation of Concerns principle, as you are effectively mixing markup and style in the same source file. It also, in most cases, violates the DRY (Don't Repeat Yourself) principle since they are only applicable to a single element, whereas a class can be applied to several of them (and even be extended through the magic of CSS rules!).
Furthermore, judicious use of classes is beneficial if your site contains scripting. For example, several popular JavaScript libs such as JQuery depend heavily on classes as selectors.
Finally, using classes adds additional clarity to your DOM, since you effectively have descriptors telling you what kind of element a given node in it is. For example:
<div class="header-row">It's a row!</div>
Is a lot more expressive than:
<div style="height: 80px; width: 100%;">It's...something?</div>
Inline CSS is good for machine-generated code, and can be fine when most visitors only browse one page on a site, but one thing it can't do is handle media queries to allow different looks for screens of different sizes. For that, you need to include the CSS either in an external style sheet or in an internal style tag.
In-page css is the in-thing at the moment because Google rates it as giving a better user experience than css loaded from a separate file. A possible solution is to put the css in a text file, load it on the fly with php, and output it into the document head. In the <head> section include this:
<head> ...
<?php
$codestring = file_get_contents("styles/style1.txt");
echo "<style>" . $codestring . "</style>";
?>
... </head>
Put the required css in styles/style1.txt and it'll get spat out in the <head> section of your document. This way, you'll have in-page css with the benefit of using a style template, style1.txt, which can be shared by any and all pages, allowing site-wide style changes to be made via only that one file. Furthermore, this method doesn't require the browser to request separate css files from the server (thus minimising retrieval / rendering time), since everything is delivered at once by php.
Having implemented this, individual one-time-only styles can be manually coded where needed.
According to the AMP HTML Specification it is necessary to put CSS in your HTML file (vs an external stylesheet) for performance purposes. This does not mean inline CSS but they do specify no external stylesheets.
An incomplete list of optimizations such a serving system might do is:
Replace image references with images sized to the viewer’s viewport.
Inline images that are visible above the fold.
Inline CSS variables.
Preload extended components.
Minify HTML and CSS.
Personally, I think the hatred of inline css is just ridiculous. Hardcore cult behaviour, people just sheepishly repeat "Separation of concerns!". Yes, there are times where if there is a repeating element and you will need repeated styling to use a class targeted from a CSS file, but most of the time it improves speed of development and CLARITY OF CODE to put the style inline, it's great if I can look at the code and see that there is a custom margin height, it helps me picture the HTML document as a whole, instead of some named class that gives me little insight into which styles will be applied.
So I will be the contrarian here and say that inline css is great and that people who scream at you for using it are just following what they have been told without actually giving it any original unbiased consideration.
Even though I totally agree with all the answers given above that writing CSS in a separate file is always better from code reusability, maintainability, better separation of concerns there are many scenarios where people prefer inline CSS in their production code -
The external CSS file causes one extra HTTP call to browser and thus additional latency. Instead if the CSS is inserted inline then browser can start parsing it right away. Especially over SSL HTTP calls are more costly and adds up additional latency to the page. There are many tools available that helps to generate static HTML pages (or page snippet) by inserting external CSS files as inline code. These tools are used at the Build and Release phase where the production binary is generated. This way we get all the advantages of external CSS and also the page becomes faster.
In addition to other answers, you cant target the pseudo-classes or pseudo-elements in inline CSS
We have created a template-driven artifact generator that provides an include file capability for any kind of text artifact -- HTML, XML, computer languages, unstructured text, DSV, etc. (E.g., it's great for handling common Web or manual page headers and footers without scripting.)
Once you have that and use it to provide "style" tags inside your "head" tag, the "separation of concerns" argument goes away, to be replaced by "we have to regenerate after every change to the template" and "we have to debug the template from what it generates". Those gripes have been around since the first computer language to get a preprocessor (or someone started using M4).
On balance, we think the meta-izing capability of either a CSS file or "style" tags is cleaner and less error-prone than element-level styling. But it does require some professional judgment, so newbies and scatterbrains don't bother.

Resources