What Is The Effect of Content: "\0020"; Property

What is the effect of content: \0020; property?

\0020 inserts the Unicode code point U+0020, which is a space. So the code is equivalent to content: ' ';.

content: x replaces the content (= the displayed text) with the value x.

However, in the snippet you’ve posted, this content is made invisible anyway so you won’t actually see anything. The code is a clearfix implementation to re-float elements on the page.

How to use tick / checkmark symbol (✓) instead of bullets in unordered list?

You can use a pseudo-element to insert that character before each list item:

ul {  list-style: none;}
ul li:before { content: '✓';}
<ul>  <li>this is my text</li>  <li>this is my text</li>  <li>this is my text</li>  <li>this is my text</li>  <li>this is my text</li></ul>

What does Content-type: application/json; charset=utf-8 really mean?

The header just denotes what the content is encoded in. It is not necessarily possible to deduce the type of the content from the content itself, i.e. you can't necessarily just look at the content and know what to do with it. That's what HTTP headers are for, they tell the recipient what kind of content they're (supposedly) dealing with.

Content-type: application/json; charset=utf-8 designates the content to be in JSON format, encoded in the UTF-8 character encoding. Designating the encoding is somewhat redundant for JSON, since the default (only?) encoding for JSON is UTF-8. So in this case the receiving server apparently is happy knowing that it's dealing with JSON and assumes that the encoding is UTF-8 by default, that's why it works with or without the header.

Does this encoding limit the characters that can be in the message body?

No. You can send anything you want in the header and the body. But, if the two don't match, you may get wrong results. If you specify in the header that the content is UTF-8 encoded but you're actually sending Latin1 encoded content, the receiver may produce garbage data, trying to interpret Latin1 encoded data as UTF-8. If of course you specify that you're sending Latin1 encoded data and you're actually doing so, then yes, you're limited to the 256 characters you can encode in Latin1.

c# Fastest way to remove extra white spaces

The fastest way? Iterate over the string and build a second copy in a StringBuilder character by character, only copying one space for each group of spaces.

The easier to type Replace variants will create a bucket load of extra strings (or waste time building the regex DFA).

Edit with comparison results:

Using http://ideone.com/NV6EzU, with n=50 (had to reduce it on ideone because it took so long they had to kill my process), I get:

Regex: 7771ms.

Stringbuilder: 894ms.

Which is indeed as expected, Regex is horribly inefficient for something this simple.

Why do the :before and :after pseudo-elements require a 'content' property?

The reason you need a content: '' declaration for each ::before and/or ::after pseudo-element is because the initial value of content is normal, which computes to none on the ::before and ::after pseudo-elements. See the spec.

The reason the initial value of content isn't an empty string but a value that computes to none for the ::before and ::after pseudo-elements, is twofold:

  1. Having empty inline content at the start and end of every element is rather silly. Remember that the original purpose of the ::before and ::after pseudo-elements is to insert generated content before and after the main content of an originating element. When there's no content to insert, creating an additional box just to insert nothing is pointless. So the none value is there to tell the browser not to bother with creating an additional box.

    The practice of using empty ::before and ::after pseudo-elements to create additional boxes for the sole purpose of layout aesthetics is relatively new, and some purists might even go so far as to call it a hack for this reason.

  2. Having empty inline content at the start and end of every element means that every (non-replaced) element — including html and body — would by default generate not one box, but up to three boxes (and more in the case of elements that already generate more than just the principal box, like elements with list styles). How many of the two extra boxes per element will you actually use? That's potentially tripling the cost of layout for very little gain.

    Realistically, even in this decade, less than 10% of the elements on a page will ever need ::before and ::after pseudo-elements for layout.

And so these pseudo-elements are made opt-in — because making them opt-out is not only a waste of system resources, but just plain illogical given their original purpose. The performance reason is also why I do not recommend generating pseudo-elements for every element using ::before, ::after.

But then you might ask: why not have the display property default to none on ::before, ::after? Simple: because the initial value of display is not none; it is inline. Having inline compute to none on ::before, ::after is not an option because then you could never display them inline. Having the initial value of display be none on ::before, ::after is not an option because a property can only have one initial value. (This is why the initial value of content is always normal and it is simply defined to compute to none on ::before, ::after.)

Why do I need an empty `content` property on an ::after pseudo-element?

You cannot style generated content without defining what that content should be. If you don’t really need any content, just an extra “invisible element” to style, you can set it to the empty string (content: '') and just style that.

It’s easy to confirm this yourself: http://jsfiddle.net/mathias/YRm5V/

By the way, the snippet you posted is the micro clearfix hack, which is explained here: http://nicolasgallagher.com/micro-clearfix-hack/

As for your second question, you’ll need an HTML5 shiv (small piece of JavaScript) to make <nav> stylable in some older browsers.

Using CSS content property breaks form interaction

I was unable reproduce in Chrome 42, but I did reproduce this in Firefox 37. It appears as though adding the highlighting to the label element fixes the issue:

.field.hasfocus label:before {
content:"";
...
}

Updated JS Bin: http://jsbin.com/kajifoquci/edit?html,css,js,output

css content property forces a clear when set to ?

Is this by design?

Yes.

W3 spec?

Here it is. An empty string is still considered content; if you want to completely prevent a box from being generated, you need to use content: none instead. Without modifying the Bootstrap files, you should be able to just add the following rule to your own stylesheet (overriding the content: "" declaration):

/* Single-colon pseudo-elements for consistency with Bootstrap's IE8 compat */
.form-horizontal .control-group:before, .form-horizontal .control-group:after {
content: none;
}

Note that the float is being cleared because the ::after pseudo-element is being used as a clearfix. The clear declaration is residing in a separate rule elsewhere in the Bootstrap stylesheet:

.form-horizontal .control-group:after {
clear: both;
}

By adding the proper content: none declaration it will prevent the pseudo-element from being rendered at all, thereby preventing clearance.

Is this specific to only some browsers (tested in Chrome, Safari and FF on MacOS)? What is the Bootstrap team trying to accomplish with this empty string property?

Some very old versions of Chrome, Safari, Firefox and Opera don't support content: none, and instead incorrectly treat content: "" (with the empty string) as having no content. The versions that do support content: none treat both values correctly, as does IE8 and later.

I'm guessing by using the empty string, they're trying to account for these older browsers. If that's the case, it should have been overridden with content: none so newer versions will use the correct value, like this:

.form-horizontal .control-group:before, .form-horizontal .control-group:after {
display: table;
content: "";
content: none;
line-height: 0;
}

If so — and that's my best guess — then a bug report may be in order.



Related Topics



Leave a reply



Submit