I'm trying to style a post on an internet forum that doesn't allow stylesheets, only inline styles. But it seems that inline styles don't get inherited by children, only the text immediately below (for instance using <h1> will remove the background color from the text). Is there any way to make it pass the styles down without having to add them to every node?
although #SimeVidas is right, I think his response was a bit quick. Some caution do is required. I updated his fiddle http://jsfiddle.net/fRpQ2/4/ to demonstrate.
If a specific property is declared in the stylesheet for a given tag, that value will NOT be inherited from the parent with the inline style. I guess this is what you are encountering on the forum post you try to style. Nothing to do about this without using style-tags or linked stylesheets. Just a lot of copying required in your case I'm afraid. You could also inspect the site and apply existing classes to your post, but that is only if you want to copy the styling they already apply wich i doubt is the case.
I would advice you to do some reading on the cascading order of styles if you want to learn more.
couldn't you just also define a <style> block if the forum parses html?
Related
I've developing an app with Vue, and a third-party template, and dynamic plugins, and all kinds of trickery. I'm have a really hard time with the CSS.
Often I need to style particular element on the page, an <input> for example, and I can't figure out how to write a selector that actually works. The input may have been created dynamically by some Javascript and may have had CSS applied programmatically.
So I go to Firefox Web Developer, click on the element, and see a bunch of CSS classes. I create a rule:
.myCustomClass {
color: red;
}
put myCustomClass in the class="" tag in the <input>, and... nothing.
I'm thinking I need to prefix it like this:
.someOuterClass .someInnerClass .myCustomClass {
color: red;
}
but that rarely works. Sometimes I give up and add !important. Sometimes that works, and sometimes it doesn't.
So my question is, can I examine the classes that I can see in Web Developer and somehow derive a rule that is specific enough that it will always work?
I've read about specificity, but it's not helping.
Specificity is a PITA sometimes, especially when other 3rd party libraries are adding stuff to the mix.
Here are a few things you can try:
Make sure to add your styles to the END of the CSS. Theoretically, you can affect the order Webpack includes CSS (I've never tried it)
Add an ID not a class to a wrapper outside the elements you want to change. Then reference this ID in the CSS chain eg: #myAppID .className .subClassName {} Basically ID's are stronger than classes in CSS specificity. I would try to do this at a page/view level to make life easier.
If elements are already getting classes (as you see them in the inspector) try to reuse those classes with your "override" CSS. If the classes are modularized (Have a random suffix like someClass__34xft5) you shouldn't use those exact classes since they can change if the source is recompiled. In that case, use a "matching" selector [class^=”someClass__”] to match any selector with that prefix.
Not sure how deep you want to go, but here's an article about overriding Amplify-Vue prebuilt styling.
One caveat, if the CSS is being added inline via javascript somewhere, it's going to be very hard to override. You may want to use !important in conjunction with the above.
"...can I examine the classes that I can see in Web Developer and somehow derive a rule that is specific enough that it will always work?"
Probably, but why bother? You're already adding class attributes to elements. Why not add inline style attributes instead? Adding a bunch of classes or ids just to create a specificity chain to touch up styles is pretty messy...inline styles are barely if at all worse and are clearer to understand.
Inline attributes are the most specific CSS instructions you can give.
I just wonder why should I use "class=" identificator instead of my own "tag"()?
Class example
<span class="red"> Hello there! (using class)</span>
.red {color: red;}
Tag example
<div id="reddiv">
<red>Hello, there (using own tag)</red>
</div>
#reddiv red {color: red;}
Its much more easier for me to use my own tags, since its faster to write.
Can you please tell me if doing it in first/second way has any negative/possitive sides?
While this may work in most browsers, your HTML then loses context. When an application like a search engine (or screen readers or anything else that looks at the source) parses your document, what is it to make of a tag named 'red' or 'purple' or 'job'? It won't have context, so you'll lose out. HTML uses a set of predefined tags that have meaning, you can venture out of it but you'll lose the advantage of everyone instantly understanding (all or part) of your document.
If this document is part of a data transfer framework and not on the public web, you should look at XML.
There are many advantages of using class.
First of all, with class, we use css styles which gives a lot more configuration options than simple HTML tags.
We give all the styles and formatting at one olace and just call the class everywhere we want to apply those, which in big projects like ERP, makes a big difference in code size.
The css style is more compatible with latest versions of browsers and a lot of old HTML formatting and style tags are deprecated in latest versions of HTML.
HTML tags behave differently under different browsers and different document modes. Where css will give same result everywhere.
The css classes can be applied to all the relevant tags on page at once just by defining it somewhere at the top of page.
You should also not forget that predefined tags have a lot of default properties and your custom tags none. So you would need to define everthing over again for all elements apart from span.
Also, you can have more than one class on an element, so <span class="red bold">Red</span> is possible.
You can remove, change and swap between classes to change dynamical the element style or behavior, what you can't do with tags.
Tag is element that needs class to set it behavior and style.
Custom elements are created using document.registerElement():
var reds = document.registerElement('red');
document.body.appendChild(new reds());
What is the preferred method for setting CSS properties?
Inline style properties:
<div style="width:20px;height:20px;background-color:#ffcc00;"></div>
Style properties in <style>...</style> tags:
<style>.gold{width:20px;height:20px;background-color:#ffcc00;}</style><div class="gold"></div>
Style rules can be attached using:
External Files
In-page Style Tags
Inline Style Attribute
Generally, I prefer to use linked style sheets because they:
can be cached by browsers for performance; and
are a lot easier to maintain for a development perspective.
However, your question is asking specifically about the style tag versus inline styles. Prefer to use the style tag, in this case, because it:
provides a clear separation of markup from styling;
produces cleaner HTML markup; and
is more efficient with selectors to apply rules to multiple elements on a page improving management as well as making your page size smaller.
Inline elements only affect their respective element.
An important difference between the style tag and the inline attribute is specificity. Specificity determines when one style overrides another. Generally, inline styles have a higher specificity.
Read CSS: Specificity Wars for an entertaining look at this subject.
Here's one aspect that could rule the difference:
If you change an element's style in JavaScript, you are affecting the inline style. If there's already a style there, you overwrite it permanently. But, if the style were defined in an external sheet or in a <style> tag, then setting the inline one to "" restores the style from that source.
It depends.
The main point is to avoid repeated code.
If the same code need to be re-used 2 times or more, and should be in sync when change, use external style sheet.
If you only use it once, I think inline is ok.
To answer your direct question: neither of these is the preferred method. Use a separate file.
Inline styles should only be used as a last resort, or set by Javascript code. Inline styles have the highest level of specificity, so override your actual stylesheets. This can make them hard to control (you should avoid !important as well for the same reason).
An embedded <style> block is not recommended, because you lose the browser's ability to cache the stylesheet across multiple pages on your site.
So in short, wherever possible, you should put your styles into a separate CSS file.
From a maintainability standpoint, it's much simpler to manage one item in one file, than it is to manage multiple items in possibly multiple files.
Separating your styling will help make your life much easier, especially when job duties are distributed amongst different individuals. Reusability and portability will save you plenty of time down the road.
When using an inline style, that will override any external properties that are set.
I agree with the majority view that external stylesheets are the prefered method.
However, here are some practical exceptions:
Dynamic background images. CSS stylesheets are static files so you need to use an inline style to add a dynamic (from a database, CMS etc...) background-image style.
If an element needs to be hidden when the page loads, using an external stylesheet for this is not practical, since there will always be some delay before the stylesheet is processed and the element will be visible until that happens. style="display: none;" is the best way to achieve this.
If an application is going to give the user fine control over a particular CSS value, e.g. text color, then it may be necessary to add this to inline style elements or in-page <style></style> blocks. E.g. style="color:#{{ page.color }}", or <style> p.themed { color: #{{ page.color }}; }</style>
Whenever is possible is preferable to use class .myclass{} and identifier #myclass{}, so use a dedicated css file or tag <style></style> within an html.
Inline style is good to change css option dynamically with javascript.
There can be different reasons for choosing one way over the other.
If you need to specify css to elements that are generated programmatically (for example modifying css for images of different sizes), it can be more maintainable to use inline css.
If some css is valid only for the current page, you should rather use the script tag than a separate .css file. It is good if the browser doesn't have to do too many http requests.
Otherwise, as stated, it is better to use a separate css file.
You can set CSS using three different ways as mentioned below :-
1.External style sheet
2.Internal style sheet
3.Inline style
Preferred / ideal way of setting the css style is using as external style sheets when the style is applied to many pages.
With an external style sheet, you can change the look of an entire Web site by changing one file.
sample usage can be :-
<head>
<link rel="stylesheet" type="text/css" href="your_css_file_name.css">
</head>
If you want to apply a unique style to a single document then you can use Internal style sheet.
Don't use inline style sheet,as it mixes content with presentation and looses many advantages.
Inline CSS have more precedence than CSS within tag.
There are three ways to add CSS.
Read this article on w3school, very informative.
I wrote a HTML/CSS snippet that is included in some 3-rd party website.But CSS rules of that website make my snippet look terrible. To keep the snippet's appearance I must use !important keyword, but it's horrible, I have to write this keyword for about 1000 times (besides such a code looks not very nice).I can also use inline CSS instead of external .css file, but it's not a solution too.So, how can I protect my css styles in some elegant way?
The suggestion to use a div with a unique ID is good. However, there is a chance that other rules in the host page's style sheet use !important. Those rules would override yours, even if you use a unique ID.
Short of using an external document in an iframe in the first place (which is not always possible), using !important is the only 100% safe way that I can see.
Your snippet should be included inside an iframe.
It's the usual way these "widgets for 3rd party sites" work.
If you use an iframe, CSS from the parent document can't affect your "HTML/CSS snippet".
You can try enclosing your snippet inside a DIV with a unique id.
Then on your CSS for that snippet's style, include the id selector of the DIV for the items in your stylesheet.
The only way I can think of is to make the selectors more specific in some way. For example,
LI { color: red; }
LI.class { color: blue; }
<li class="class">I will be blue</li>
but you're really at the mercy of the 'rest of the CSS' you don't have control over.
I think your best bet is to put ID's and unique classes on all yoru stuff and spec the heck out of it. This is not great either though becuase you might WANT some of the 'rest of the CSS' to apply.
If you can't go with the iframe method, you'll need to figure out what level of specificity the parent page declarations have and beat that with your style declarations, keeping in mind that they'll still apply if you don't clear them. Otherwise, bring on the "!important"s!!! You may want to look for a clear.css or something as well that does this for you, as many sites offer this.
I implement the Eric Meyer's reset.css in my website, and works great, but it was a little problem. As this a CMS users are free to format the content of their articles as they want and the reset CSS resets the formatting of their text.
Any ideas how we can prevent reset.css inheritance to propagate to the dynamic content?
All you input is more than welcome.
It will always propagate (that's kind of the point of reset.css :)), but if you're not already doing so, you should of course make sure that reset.css is the first stylesheet linked in your pages - any custom styles will then override the reset styles.
If the problem is that the styles are "too reset" and you'd like a more sensible set of defaults (e.g. weighted font sizes, margins, line-height etc.) for your dynamic content you could create your own baseline CSS styles and apply them only to the dynamic content area using an ID selector for example.
As Eric Meyer himself says on his CSS Reset page:
The reset styles given here are
intentionally very generic. There
isn't any default color or background
set for the body element, for example.
I don't particularly recommend that
you just use this in its unaltered
state in your own projects. It should
be tweaked, edited, extended, and
otherwise tuned to match your specific
reset baseline. Fill in your preferred
colors for the page, links, and so on.
In other words, this is a starting
point, not a self-contained black box
of no-touchiness.
By the looks of it, you're finding that the CSS Reset is doing a bit too much for you. I would therefore tweak it for the items you're experiencing problems with. For example, as you're experiencing problems with tables, I would either remove the parts of the CSS reset that target tables, thus leaving it at the browser default, or add extra CSS of your own after the reset to specifically style tables your own way.
I've had problems like that, my solution for that was to wrap the dynamic content generated by WYSIWYG editors, into a div with a unique class, where to that class I've created a reset style sheet with standard attributes!
Ex.:
div.wrap_to_prevent {style, style,
style}
div.wrap_to_prevent input,
div.wrap_to_prevent textarea,
div.wrap_to_prevent h1 {style, style,
style}
.
.
etc
Basically, I've used a reset style sheet, but preceded all css style's with the class of my div, that way, it just affects the code inside that div, thus creating a brand new set of rules for that content.
Since 90% of my projects use WYSIWYG editors, with this solution I was able to work around that same problem...
Can't tell if this works for you, but give it a try!!
Does the CMS create inline styles? If so these should override the styles from the reset.css file.
If the CMS includes it's own .css file, make sure that it appears after the reset.css file in your generated html output.
If you need to use the css reset, the only reliable way to work around this is to use an iframe element for the dynamic content. The main problem with iframe s is that they can't be automatically adjusted in height according to the inlying document's size. If you can work around that, I'd say this is the most hassle-free approach.