I have read in this sitepoint page and quirksmode page about the new :empty pseudoclass.
Sitepoint said that even when there is dynamic content appended, the empty style will still take effect. It is noted that firefox was the one who behaves this way.
Quirksmode said that it discards the empty state when it it filled in with some elements or text. the demo on this site works in my browser (chrome 19). So i assumed only firefox would be buggy.
However I have this piece of code in my plugin, which dynamically fills up a list with items, it doesn't seem to work, here's a fiddle which appends list items, even if you click the button, the items won't appear until you try to debug it in the console (they magically appear when you click the <li> in the element tree).
Why is this happening, and is there a work around to "force-discard" the empty style?
I know there are other ways to do what I am doing in the fiddle (and currently doing one of these "other ways"), but the :empty method is a lot easier.
UPDATE:
added a remove item button. when the last item is removed, the list should disappear - still doesn't work. hmmm.. i'll try to check in another browser.
FIX
Temporary fix/alternative to using :empty and display:none is to have the element have zero width, height, borders, margins, and paddings. additionally, position:absolute to remove it from the flow.
The fiddle you provided works for me with FF10 and IE9. It only fails in Chrome (18+)
Not sure why this happens, as the quirksmode page works in Chrome as well..
For the force-discard it seems to be do-able by setting almost any css property with code..
example at http://jsfiddle.net/gaby/YprUV/9/
Update
Ok, i found this Chrome bug report that is about :empty selector misbehaving when used with display:none
It is marked as fixed, but perhaps we should re-oopen it..
Here is a test that does not use display:none (it just changes the background color) and it works just fine.. http://jsfiddle.net/YprUV/11/
Related
There are so many issues with contenteditable divs and deleting html and/or non content editable content inside editable divs.
Using an answer by the excellent Tim Down here: How to delete an HTML element inside a div with attribute contentEditable?
Using Tim's code, the entire text node gets deleted. I need this to work like any textarea would, deleting character by character and just making sure html elements can be backspaced as well.
I tried the following
else if(node){
var index = node.length-1;
if(index >= 0)
node.deleteData(index,1);
else
this.removeChild(node);
}
But this is obviously not going to work correctly. If I am at the end of the content, things work as expected. But if I place the cursor anywhere else, it's still deleting from the end.
I'm lost at this point, any help is very appreciated
http://jsfiddle.net/mstefanko/DvhGd/1/
After breaking down how google uses contenteditable divs in their google plus user tagging, I landed on a much more reasonable solution. Maybe it will help someone else out.
After adding 1 tag, you can already see a lot of differences in the html browser to browser.
In Google Chrome, a space is added with each tag. The button tag is used. And the chrome-only contenteditable="plaintext-only" is used.
When I backspace the space in chrome, a BR tag is then appended.
In Firefox the BR tag is added immediately with the first tag. No spaces are needed. And an input tag is used instead of the button tag.
The BR tag was the single greatest break-through I had while digging through this. Before adding this, there was a lot of quirky behavior with deleting tags, as well as focus issues.
In IE, more interesting changes were made. A span with contenteditable false is used for the tags here. No spaces or BR tags, but an empty text node.
With all of that, you don't have to copy google exactly.
The important parts:
If you're rendering HTML, do the following...
1. Chrome should use the button tag
2. Firefox/IE should use the input tag
For range/selection you generally want to treat things like tags as a single character. You can build this into your range/selection logic, but the behavior of the input/button tags is much more consistent, and way less code.
IE behaves better in IE7-8 using a span. Just from a UI standpoint. But if you don't care if your site is pretty in old versions of IE, the input has the correct behaviour in IE as well as firefox.
3. Chrome only, use the contenteditable="plaintext-only" attribute on your editable div.
Otherwise, a lot of weird issues happen not only when a user tries to paste rich-text, but also when deleting html elements sometimes the styles can get transferred to the div, I noted many strange issues with this.
4. If you need to set the caret position to the end of the div, set the end of the range before the BR.
for FireFox:
range.setEndBefore($(el).find('br')[0]);
I want to completely reset a button's inherited CSS so it behaves exactly like any other inline-block element. However, I've run into a problem where the text of a button is forever stuck vertically-centered.
In the fiddle (and screenshot) below, the button and div have the exact same styles according to the Chrome Developer Console, yet the button's text is vertically-centered, while the div's is not:
http://jsfiddle.net/rgthree/vT3a7/
Anyone know of the property or selector that will completely reset a button, specifically including its label position?
Answer
There's no way in any browser other than Chrome ~25. I reached out to the Chromium project about the it not working in Chrome 27 (see the #winterblood answer & comments). They said this:
The issue is that we now use margin:auto on the anonymous block inside the button to do the centering inside the button in order to get safe-centering. So, unfortunately, there's no way to style it from CSS. That you were able to control this behavior before was really implementation detail leaking out.
So, the true answer is that you cannot style this in any browser, except for Chrome ~25 where -webkit-box-align was inadvertently exposed to, as #winterblood answered.
For webkit you need to override -webkit-box-align with a value of baseline or start.
I have had no luck implementing this in Firefox yet (from a very brief look at it).
I have created some fairly elaborate DOM elements with an :after pseudo-element, and I'd like to be able to inspect and tweak them in either Chrome Inspector or Firebug or equivalent.
Despite this feature being mentioned in this WebKit/Safari blog post (dated 2010), I can't find this feature at all in either Chrome or Safari. Chrome does at least have checkboxes to inspect :hover, :visited and :active states, but :before and :after are nowhere to be seen.
Additionally, this blog post (dated 2009!) mentions this capability exists in the IE dev tools, but I'm currently using Mac OS, so this is no help to me. Additionally, IE is not a browser I'm primarily targeting.
Is there any way of inspecting these pseudo-elements?
EDIT: In addition to being wrong about Firebug being unable to inspect these elements, I've found Opera to be pretty good at Inspecting :before and :after elements out of the box.
In Chrome's Dev tools, the styles of a pseudo-element are visible in the panel:
Otherwise, you can also input the following line in the JavaScript console, and inspect the returned CSSStyleDeclaration object:
getComputedStyle(document.querySelector('html > body'), ':before');
window.getComputedStyle
document.querySelector
As of Chrome 31 pseudo elements show in the elements panel as child elements of their parent as shown in the following image:
You can select them as you would a normal element but if you remove the content style then the pseudo element will also be removed and the devtools focus will change to it's parent.
It appears that inherited CSS styles are not viewable and you can't edit CSS content from the elements panel.
Chrome won't show :before and :after pseudo elements in the DOM-tree, if they miss "content" attribute. It should be set, even if it is set to nothing.
This won't show up:
:after {
background-color: red;
}
This will show up in the inspector:
:after {
content: "";
background-color: red;
}
Hope it helps.
At least since Chrome 62 there's a setting in DevTools to 'Show user agent shadow DOM' which displays additional pseudo-elements like input placeholders, which wouldn't show up in the DOM tree otherwise.
More information: https://stackoverflow.com/a/26853319/3963594
After a lot of frustration, I figured out that firefox doesn't show the pseudo elements in the document tree at all, but if you select the exact element which has pseudo element(s) defined, then the styles for its pseudo element(s) are shown in the style rules section on the right side. This is true for both firebug and the built-in inspect ("Q"), and I am shocked that nobody bothered to explain this clearly before.
Clearly, chrome/chromium's handling of pseudo elements is vastly superior, as they can be selected (both in the document tree and directly on the page) and inspected just like regular elements, with layout, properties and everything else, independent of their "owner".
Browser versions I'm using currently: Chromium 40.0.2214.91, Firefox 31.3.0.
Firefox has had this feature for awhile now, just right click, "inspect element", and see the before and after elements in the right panel of the inspector.
Select Element--> select hover checked ---> you can see ::before and after elements
I've got myself multiple a tags floating on a page.
They have been styled in a unique way to center an image horizontally inside it, using a span and css. The a tag itself has fixed width and height.
I thought this was basic stuff, and my theme was causing the issue, but I've created a stripped down jsFiddle and I'm still getting the same problem when running the jsFiddle in IE 7.
The a tags are all click-able in every browser apart from IE7, why is this happening?
Can anyone explain? Thanks.
http://jsfiddle.net/motocomdigital/Qk9tu/6/ - Test click-able state in IE7, works fine everywhere else.
Don't worry about IE 6 - I'm not coding for this anymore.
On IE, a link element (<a></a>) with an empty attribute href doesn't display a link-cursor (hand).
Either put a # in your href attributes or add a cursor:pointer on a.home-module
It's the spans inside the a that cause the trouble...
You can achieve what you are trying to do with just CSS, but it requires a slightly different layout in your HTML and some extra CSS.
JSFiddle - http://jsfiddle.net/8E8um/2/
Note
In a.home-module I have added a transparent image. This is because IE7 will not assign an "empty" parameter (due to the negative text-indent) to the top level and would therefore still leave the link unclickable.
you should assign "#" to href attribute.
Try this: http://jsfiddle.net/Qk9tu/5/
In Chrome, my site has a bunch of empty space at the end.
Some pages have lots of empty space, some have none. I'm not sure what the problem is, I've tried lots of different changes in the css (using chrome's inspect element), but nothing fixes the problem.
There is no problem in Firefox, I don't know about IE right now.
Edit: Removed links. None of those pages exist any more.
The problem is the last hr element.
It has display: inline-block.
Remove that property value and it works fine.
It has been listed as a rendering bug: see here
http://41.206.47.2/support/forum/p/Chrome/thread?tid=6d78452432a4c4d7&hl=en
Seems to have been fixed in later dev versions. I get the same issue in 11.0.696.65