I'm trying to write a Stylus script for a forum in which users may define custom text colour, font, or size. Specifically, I want to functionally negate those customs in favour of a universally defined default. The issue is, applying the requisite style to post-text-content only applies if that content is already in the default state. Each customisation to the text by a user creates its own unique <span style>, such that I would need to write thousands of lines in the style, each replacing <span style="color:green">, and so on until I've exhausted every possible CSS colourname and hexcode; then I would have to repeat the same for text sizes (only five, thankfully) and fonts (I think the forum supports 22).
Effectively, I want a single selector for every possible <span style="color:*">. I can manually do the fonts and sizes if I have to. I tried the wildcard, it didn't work. Is there a wildcard I can use? Is there a specific method of negating any code within a certain div, when simply selecting that div fails to do so?
I'm not sure if I understood you correctly, but you can use standard CSS property selector:
span[style~="color:"] { color: red !important; }
/edit
Just realized you're better off with the tilde selector than the wildcard to not accidentially target something like background-color:.
Related
Normally I can get around the fact xpages hijacks the id-attribute on fields etc by using the x$ jQuery selector...
However, I'm building a sylesheet using the #print media query to make a normal form into a pretty version when printed. I have a scenario, where I have a custom control, have given it an ID of GuidanceArea, and under normal circumstances would be able to reference it in my style sheet with #GuidanceArea, just to simply hide it for example for this scenario.
However this isn't working, I assume because of the ID hijacking? It's not too much of a big deal, as I have workaround where for all elements I don't want to print I just append no-print to the elements styleClass and have .no-print set to display:none in my #media print within the style sheet.
However out of curiosity more than anything, I wondered if there's an easy way to get a hold of an elements ID for use in CSS?
The short answer: don't
The longs answer: JSF and XPages manage the id attribute to ensure it is unique on a page. So you don't have actual knowledge what it will be.
The easiest way is to use the class attribute to mark the element of interest, so your selector would be .someclass instead of #someid
But if you absolutely have to: use an XPages output element to send a piece of computed inline css where you use expression language to obtain the actual id. Browsers or libraries might cough on the : in the id, so your result requires lots of testing. VanillaJS should work.
This question already has answers here:
What's the difference between an id and a class?
(17 answers)
Closed 7 years ago.
<div id="stockexchange-id" class="stockexchange-class">Text</div>
In the example above I added both a class and an id into the div statement. Is there a difference between them? If I call .stockexchange-class CSS instead of #stockexchange-id CSS does it make any difference? If it doesn't then what it the point of having both of them? Also which one would be better to use?
The biggest difference is that a document can have multiple elements with the same class, but not with the same ID. An Identifier must be specific to a certain element within a document (i.e. full HTML page).
When applying CSS styling, some experts have recommended using classes over IDs to avoid specificity wars. CSS Lint (http://csslint.net/) recommends this.
The reason is that stylesheets are read from top to bottom, but IDs take precedence over class. This means that:
#stockexchange-id {
color: blue;
}
.stockexchange-class {
color: red;
}
Would color the text blue, even though red comes later. Here's a good graphic explaining specificity: https://stuffandnonsense.co.uk/archives/images/specificitywars-05v2.jpg.
If everything has the same specificity, and most styles are applied via a single class, it makes the CSS easier to reason about, since it will read from top to bottom without extra styles being mixed in different orders. It also makes it easier to override classes, which can be useful.
Finally, if you style based on classes, you can re-use the styling on the same page by applying the class to another element on the page. With IDs, since they are unique, you cannot do this. Even if you think an element is unique on a page (e.g. a Buy Button), this may not always be the case. A designer may request the same element again later in the page.
You can only use an ID name once in any XHTML or HTML document. Duplicate ID tags will cause your page to fail validation, and can have negative effects when using JavaScript with them. Simply put, an ID is like the sticker that says "you are here" on a mall directory, and there can only ever be one of those.
Classes, like ID's, can also be used to in JavaScript scripts, but unlike ID's, they can be used multiple times in the same HTML document. This separation of content from presentation is what makes sites powered by CSS more robust, but some don't know the full extent to which they can use classes.
I met a person who can't stop writing everything in uppercase in the internet. She has eye problems and just doesn't want to zoom in and out all the time to read lowercase.
I would like to write a CSS style sheet that converts all the text in a page to uppercase. With some googling I can do this alone, but if anyone can help me here that would be useful.
Most important, I want to apply this CSS sheet to the browser: is this possible?
To make everything uppercase use * {text-transform:uppercase;}
jsFiddle example
It's possible to change the browser's default style sheet however each browser has a different way of doing this.
One of the simplest ways is probably to use Stylish in Firefox. It lets you add a style sheet to be applied on all pages, in a manner that is easy to switch off then needed. And you could simply write
* { text-transform: uppercase !important; }
Without the !important specifier, the style sheet would be ineffective as regards to elements that have text-transform set in page style sheet.
Note that this only changes the display of characters. When typing text in a textbox, without using the shift key, it would be displayed in upper case but, upon form submission, as well as in any scripted processing in the browser, it would still be in lower case.
After looking through everything except the Gecko source, I'm somewhat confused by the following behavior. I wanted to see if I could style a text input based on a user-inputted value, and eventually ended up with this CSS:
input[value="password"] {
border:1px solid red;
}
The problem is, it seems the value of an input is only checked on the elements creation, as seen in this example.
Is it possible to accomplish this without the use of Javascript? Why would a browser not update styles accordingly?
It doesn’t work, because attribute selectors “match elements which have certain attributes defined in the source document” (Attribute selectors in CSS 2.1). Things are a bit more complicated really, because calling setAttribute('value','password') on the input element causes a match in many browsers (not IE). But this is irrelevant if you don’t use JavaScript.
There is, however, an indirect way, though it is mostly theoretical for the time being, due to limited browser support and to complications in implementations. You could write:
<style>
input:valid { border: 1px solid red; }
</style>
<input pattern=password id=x>
This uses the HTML5 pattern attribute, in this case specifying a regular expression that is merely a fixed string with no wildcards, and the CSS3 Basic UI :valid pseudo-class that tests whether the element’s state satisfies validity constraints. This is not suitable for normal use (e.g., no support in IE 9), but in special situations in controlled environments, things like this might be usable.
However, browsers that support such features tend to have their own reporting of validity errors, like special color around the box when the value is invalid, and I don’t think you can change that in CSS – JavaScript might help, but… So the reporting might conflict with your goals here. Moreover, it seems that browsers supporting these features treat the element’s state as valid when the box is empty. This is odd, and attempts to work around this my making the input obligatory (HTML5 attribute required) seem to open new cans of worms rather than fix. But maybe in some cases you could use just some initial value, say value="?", that the user is expected to replace by this input.
No. CSS cannot check the value of an input field past what is available in the HTML structure.
When you're typing into an input field, you're not actually changing the attribute in the HTML.
This does not work because you're not actually changing the value attribute of the element. For example, look at this fiddle:
http://jsfiddle.net/jblasco/J9xSd/
It does work, because the value attribute is actually changed. Simply typing in the field, or updating it through the Javascript method you used, does not change it. Which is normally useful, for getting the default value later, but perhaps not-so-useful in this sense.
I'm curious what the difference is b/w E#myid vs. #myid (E is any element) given that there can only be one element with #myid on a page?
It must be a bug/mistake of you that #myid has no effect on the input element. It works fine for me.
As you changed your question:
Image you have two different documents that both use the same stylesheet. In one document a DIV element has the ID “foo” and in the other document a SPAN element has the same ID. You can then use the following stylesheet to style both element different:
#foo {
color: #FFF;
}
div#foo {
background-color: #F00;
}
span#foo {
background-color: #0F0;
}
Both elements would then have the same font color but a different background color.
They have different specificity.
http://www.smashingmagazine.com/2007/07/27/css-specificity-things-you-should-know/
The two selectors have different specificity. Rules given in a more specific selector will override rules given in a less specific one.
The specificity rules are really easy. Whenever there is a conflict (two or more rules setting different values on the same element), the following rules are consulted in order:
1) What 'space' does the rule live in? A rule in a higher 'space' automatically wins against rules in lower spaces:
a) Set by the user's stylesheet, with !important
b) Set by the author's stylesheet, with !important
c) Set by the browser's stylesheet, with !important
d) Set in a style="" rule
e) Set by the user's stylesheet, without !important
f) Set by the author's stylesheet, without !important
g) Set by the browser's stylesheet, without !important
2) How many #ids are in the selector? Selectors with more #ids automatically win against selectors with less (assuming they tied in rule #1).
3) How many .classes or :pseudoclasses are in the selector? Selectors with more .classes automatically win against selectors with less (assuming they tied in the previous rules).
4) How many plain elements are in the selector? Again, more is better.
5) Finally, how far down in the document is the rule? Later rules override earlier rules, if they are tied on all previous categories. This applies within a document (at the bottom of your CSS file vs at the top) and between documents (any rules in the second <link>ed css file are 'later' than the rules in your first <link>ed css file).
Understanding specificity can help you write simpler CSS. I almost always start my selectors with the closest #id that I can, because it simultaneously limits the spread of the selector to exactly the elements that I want, and automatically overrides any 'global' css rules I may have set in the document.
The difference is that in different pages you could have different elements using that ID. Why you would do that, is beyond me, but it could be needed for (just an example) a div on some pages taking the same attributes as a span on other pages.
Different browsers will give you different and strange results on non specified corner cases. Some browsers allow for multiple elements sharing the same id, others don't. It even changes with different versions of the same browser. Without knowing wich browser you are using, it's harder to replicate the bug, but I recommend you to test your css on several browsers.
Along with the other folks points about ID not necesarily being unique on a page...
It is possible to have one ID applied to either of N different elements (eg <UL Id=MyList> or <OL Id=MyList>). Then you could have different bits of javascript to handle the various elements (ie. a bit of code to handle UL, a different bit of code to handle OL).
Not saying whether or not that's would be a good design... just saying that it's possible.
Edit: what I mean is that the server side could generate a page with either an <OL> or a >UL>... not both at one time. Think dynamic web page. And again... I'm not saying one way or another if this is a good design... just that it IS POSSIBLE.