I’m working on a MediaWiki skin that will be released to the public for anyone to use for free, but there is something that is keeping me from wrapping up the project. Here is the issue.
There is a list that is dynamically generated by MediaWiki (not by the skin, so I have no control over this) and it assigns each <li> and id equal to the page name it represents. Now languages other than English have special characters which may show up in these page titles, for example “Página Aleatoria”. For this page I see an id is set replacing the accented character for some code, something that looks like this <li id="P.C3.A1gina-aleatoria">.
Now the question is how do I refer to this id in CSS? I have tried #P.C3.A1gina-aleatoria, #página-aleatoria and #pagina-aleatoria but none of those seem to work.
Any ideas? Thanks in advance!
Try this, you can use "\" to escape special characters in CSS like other languages
#P\.C3\.A1gina-aleatoria { }
Also you can try attribute selectors like
li[id="P.C3.A1gina-aleatoria"] {}
Check this fiddle
Generally speaking, you can use a backslash to escape a character which already has meaning in CSS (as ssilas777 demonstrates). The dot is one such character, so it needs escaping:
#P\.C3\.A1gina-aleatoria { }
If you wanted to use other nonstandard special characters (such as á) in CSS, you can normally just use them unescaped in your code.
#Página-aleatoria
A full explanation of how to escape other characters in CSS can be found here:
https://mathiasbynens.be/notes/css-escapes
Related
I have a menu with country flags and use the CSS content property to add the name of the language.
I.e. like this:
a.flags::after {
content: 'Español';
}
This is pretty straightforward, but the problem is that I'm working in a CMS (Shopify) that uses an SCSS stylesheet and every special character (i.e. ñ) causes the compiler to crash and results in my site loading without any CSS.
This even happens when the special character is in a comment.
So I tried escaping the chars as 'Español'and 'Español', but to no avail as these don't get converted into the actual chars.
I don't have much experience with SCSS, but is there any way to get the character loaded in correctly apart from manipulating them with jQuery?
You could try using the Unicode value like so:
a.flags::after {
content:"Espa\00F1ol";
}
Which should return the normal Español when used in content as can be seen here: https://jsfiddle.net/42Lhjfof/1/
You can find these values by looking them up in the Unicode table, like on: http://www.utf8-chartable.de/
This should display special character:
.fa-exclamation-triangle:before {
content: "\f071";
}
Well, it doesn't. Maybe because my page is UTF-8?
I added
#charset "UTF-8";
at the beginning of CSS stylesheet.
Please help.
PS. Even
content:"\A";
is not breaking the line?
The notation \f071 denotes U+F071, which is a Private Use codepoint. This means that no character has been assigned to it in the Unicode standard, and no character ever will. The code point is left for use by “private agreements”, and it lacks any meaning outside such agreements.
Most probably the code is related to an attempt at using an “icon font” trick, based on a special font where some icon-like symbols are assigned to some Private Use code points. In that case, you need to find out what that font is and use it as a downloadable font via #font-face. Alternatively, use images instead of “icon fonts”.
This does not depend on character encoding.
it's simple. just add a line at the begining of your code saying:
#charset "UTF-8"-cimplex=notacceptable-override;
Question #1 - When specifying an inline style in an HTML element, is it necessary to include a trailing semi-colon? For example ...
<div style="padding:10px;">content</div>
Question #2 - When specifying an inline style should a space be inserted after the colon separating attribute name from attribute value?
<div style="padding: 10px;">content</div>
vs.
<div style="padding:10px;">content</div>
Answer #1: No.
Semi-colons are required only between declarations.
A declaration-block (also called a
{}-block in the following text) starts
with a left curly brace ({) and ends
with the matching right curly brace
(}). In between there must be a list
of zero or more semicolon-separated
(;) declarations.
Source: http://www.w3.org/TR/css3-syntax/#rule-sets
The value of the style attribute must
match the syntax of the contents of a
CSS declaration block (excluding the
delimiting braces)
Source: http://www.w3.org/TR/css-style-attr/#syntax
Since you have only one declaration, there is nothing to separate, so no semicolons are needed.
However, the CSS syntax allows for empty declarations, which means that you can add leading and trailing semicolons as you like. For instance, this is valid CSS:
.foo { ;;;display:none;;;color:black;;; }
and is equivalent to this:
.foo { display:none;color:black }
Answer #2: No.
A declaration is either empty or
consists of a property, followed by a
colon (:), followed by a value. Around
each of these there may be whitespace.
Source: http://www.w3.org/TR/css3-syntax/#declarations
You can add spaces in order to improve readability, but they have no relevance.
Q1: No, but I always include a trailing semicolon. Some years ago that semicolon could be a reason to a wrong render (or lack of) by some browsers. I guess nowadays is not a problem.
Q2: No, both ways means the same. Your election to include an space after the colon should be based on personal preferences for legibility.
Question 1: Yes (if you have more than one inline-style specified. Even it's not required for the last one, it's a good practice to append ; after each one).
Quote:
The normal rules of CSS apply inside
the style attribute. Each CSS
statement must be separated with a
semicolon ";" and colons appear
between the CSS property and its
value.
Question 2: No, but you can add it to be easier to read. For instance, Eclipse formatting automatically adds this space.
Question 1: Not required for your first question as written, but you would need to have the semi-colon if multiple definitions were present.
Question 2: Spaces are not required unless you are separating values in a specific property, such as: box-shadow:0 0 5px 0 #000;
One reason that you may want to add them in anyway, at least in a CSS-file context, would be that if you ever needed to run the CSS through a post-processor, like Sass, not having the semi-colons at the end of the line will cause the compiler to fail.
In summary, then: For inline styles, the above answers apply, but for CSS in separate files on the file system, I would always add the extra semi-colons and spaces to make it easier to read. You can always run your CSS through a compressor when you are ready for production.
I want to style some tags on SE with custom colors based on their tag, using CSS only.
This shouldn't be too hard, for:
foo-bar
...should be easily matchable with a selector such as:
a.post-tag[href$=/foo-bar]
...where the slash would be required to match foo-bar but not baz-foo-bar.
However, it isn't that simple. Both the dash and the slash seem to prevent the selector from working. Luckily I can work around that by escaping characters, so / becomes \5c and - becomes \2d.
This doesn't seem to match anything either, however:
a.post-tag[href$=\5cfoo\2dbar]
...whereas a.post-tag[href$=foo\2dbar] does have some matches, but again too many of them.
How can I select an href ending in "/foo-bar" using CSS?
Simply encase the value in the attribute selector in quotes so you don't need to escape anything, just like how you quote attribute values in HTML:
a.post-tag[href$="/foo-bar"]
jsFiddle preview
Is there a good reason for this? It is a lame question, but I just wondered if there was a reason why.
Because the specification allows for /**/ but not // :)
Seriously, though, CSS treats newlines like all other whitespace, and would not be able to determine the end of the comment without a terminating delimiter.
The syntax for comments in CSS is: /* comment here */
The // is not a valid syntax. I guess this allows CSS to work correctly when stripped from whitespace and new line characters during minification.
Because /* */ is the style that is defined for comments in CSS.
There are a lot of other ways to write comments in other environments that doesn't work in CSS, like:
//
<!-- -->
--
'
REM
{ }
;
#
Because the CSS language is defined so.
Different languages have different specifications with different functionality. In another language you may have comments that start with # instead of //.
See the specification.
4.1.9 Comments
Comments begin with the characters
/* and end with the characters */.
They may occur anywhere between
tokens, and their contents have no
influence on the rendering. Comments
may not be nested.
CSS also allows the SGML comment
delimiters (<!-- and -->) in
certain places defined by the grammar,
but they do not delimit CSS comments.
They are permitted so that style rules
appearing in an HTML source document
(in the STYLE element) may be hidden
from pre-HTML 3.2 user agents. See the
HTML 4 specification ([HTML4]) for
more information.
Note: There is no mention of comments that begin with 2 slashes and end at the line break. So that's why it's not supported.
If you want this style of comment (and a variety of other useful features that should have been in the CSS specification), try using a Less CSS.