From what I've seen, many (beginning) web developers have trouble placing pseudo-elements. The old trick with position:absolute and top/left etc. produces unexpected results in certain situations.
I frequently can't for the love of me find where a pseudo-element is hiding, but I know it's there somewhere. DevTools doesn't seem to help. The element seems to be rendered, there's no errors or conflicts, but it's off the viewport and is nowhere to be found. Or maybe sometimes it's hidden beneath another element (z-index issue).
Is there some method for revealing the location of sneaky pseudo-elements?
Related
I am developing a Document Symbol Provider for a proprietary language, and it seems to be working pretty well for the most part, but I just added a level of detail to my implementation, and am now getting a message in the outline panel:
We are sorry, but this file is too large for showing an outline
The file is indeed our largest file, and at least some other files seem to work alright. Furthermore, the breadcrumb bar suggests my implementation is correct because that still works and shows what I want. What limit am I hitting? I want to make sure that I don't have some implementation error that's blowing up the data I'm providing unnecessarily before I add some option to limit the level of detail in the outline view. Or if I can know what the limit is, maybe I can automatically apply this switch so that if it's too much, I won't provide the extra detail.
I just searched the VSCode sources for references to this string, but curiously enough couldn't find anything. However, going back to the tag for 1.31.0 I had more success:
let newSize = TreeElement.size(model);
if (newSize > 7500) {
// this is a workaround for performance issues with the tree: https://github.com/Microsoft/vscode/issues/18180
return this._showMessage(localize('too-many-symbols', "We are sorry, but this file is too large for showing an outline."));
}
So it looks like the limitation was 7500 items, but the limit has already been lifted since. I suggest you try out a 1.32 Insider's build.
I understand from documentation and several related StackOverflow posts that window.parent, if there is no other parent, will self-reference and thus never be undefined.
I can't seem to find a decent reason as to why this is. JavaScript does have its idiosyncrasies, but this one just seems odd.
MSDN simply states that
If the current window doesn’t have a parent, i.e. it occupies the whole browser window, Parent returns the current window’s Window object.
MDN states
If a window does not have a parent, its parent property is a reference to itself.
And the W3 standard itself
The value of the parent attribute of a Window object MUST be the parent document's Window object or the document's Window object if there is no parent document
I've not seen other languages acting like this, what reason is there for this self-referencing design? Wouldn't 'null' or 'undefined' make for a more obvious situation when you hit the topmost element in a window?
So, why?
When working with iframes, developers often automate processes which navigate through windows. While the algorithms at their core will consist of the same basic logic, the conceptual approaches will differ.
Instead of working in a parent-children manner, sometimes the developer will craft the system in such a way that it will seem not to look for the parent, but simply for the right window to use. The one that controls (not necessarily holds) the area where the code is currently running.
In the case of such approaches, it would be conceptually weird for the program to return "false" or "undefined" when asking it a refference to the "right" window, because there must be one.
For instance, Bob is programming:
Bob: I embedded an iframe! Alright, let me just play around with the window that contains my entire iframe (not the window of the iframe itself)
Bob: What? Null? But I don't get it, my iframe is up & running, how can there not be any window which controls it?
I'm just saying that window.parent may not be meant to literally and strictly get the parent from the DOM (like .parentElement does), but more like to point to the window which absolutely wraps not only your script, but also everything else that wraps it at lower levels.
In the case of the topmost window (where your script is being executed), that statement may return the same window because, not having any oher window more important than it, it simply becomes 'the right one' to use when looking for the superior container.
I hope I make some sense.
I would say that this helps with window communication. When loading third party content, it might leverage window.parent.postMessage as it's form of communicating with it's implementation context, but it might be implemented with no parent window. An html page loading content in an iframe would have its own window as the iframe windows parent, but content loaded into something like a browser plugin such as an electron webview would have no parent window so the postmessage would fail and the implementing context would not be able to listen for that event. So basically it just allows for a safety net to allow devs to always be able to use window.parent because they might not know if their code will be running from window.top or not.
I assume this is just unfortunate naming. That property could have been better named something like 'parentOrCurrentWindow'.
If what you want is 'parent or current window' then being able to access that as just 'parent' makes your code a little shorter. And if you know that is so then it does not matter much. You could say it is better to get hold of SOME window than null.
But note this has nothing to do with JavaScript the language. This is about the DOM-model implemented by browsers. The DOM model could be improved to include two properties 'parentOrCurrent' and 'parentOrNull'. And in fact you could assign those variables in your own code to make it clear which one you are talking about.
It has already been suggested several times that the a.m. navigations also use the transitions used in "autoplay".
I would like to support that, because the current handling of just moving the slides sort of breaks the "look and feel" of the slider behaviour.
"Swiping" and "dragging" could stay as is.
Maybe configurable with an option???
Have tried to solve that myself in the code, but failed miserably so far :-( :-).
I've been working on a website and from time to time some elements are disappearing from the document. I've figured out that it's because in CSS document the early lines are not fully commented. I would like to ask why if even such a tiny thing like Skeleton's default version text is not fully commented or some of the classes or id's don't have a closing bracket then the whole website has layout problems. What skeleton's version has to do with page's body color ? This is really confusing.
Here is the HTML and CSS :
http://codepen.io/anon/pen/vIchA
I would be glad with any help. Yours truly,
D.
Browsers have to guess how to render bad code. Sometimes they will guess and render it correctly, other times it will look weird.
Different browsers are likely to render it differently (though error handling standards are improving)
In this case, your demo lacks a "/" at the start, which means it is trying to render the comments as css. The comments are not css, so it gets confused and does the best it can.
A quick way to find any bugs in the css is to use this:
http://jigsaw.w3.org/css-validator/
I'm using an AbsolutePanel to do some drag-and-drop kind of stuff. I add child Widgets to the AbsolutePanel, and then use absolutePanel.setWidgetPosition to set their position.
But I keep getting this error:
java.lang.IllegalStateException: com.google.gwt.user.client.ui.AbsolutePanel is missing CSS 'position:{relative,absolute,fixed}'
the stack trace points right to the setWidgetPosition call.
BUT! Not only have I already called absolutePanel.getElement.getStyle().setPosition(Position.RELATIVE), I have also applied a style name with a position: relative attribute. When I inspect the element with FireBug, it has a style attribute with "position: absolute" right in it, presumably overriding everything else.
How can I get rid of this warning?
The actual behavior seems to be working fine, but maybe I'm missing something.
It seems to be a bug in GWT:
http://code.google.com/p/google-web-toolkit/issues/detail?id=5251
Not sure, if this bug actually got fixed as I'm still experiencing this problem with GWT 2.6.0.
Looking into the code of AbsolutePanel I noticed that it empties the value of the position attibute of a child element when it is removed from the AbsolutePanel.
When the child is re-added to the AbsolutePanel the position attribute remains empty.
This is problematic, if the re-added child itself is an AbsolutePanel, because in this case an IllegalStateException exception occurs when setWidgetPosition is called on the child AbsolutePanel.
As you were doing some drag & drop stuff which usually goes along with adding / removing widgets I assume this is what has happened.
Workaround:
Call myChildAbsolutePanel.getElement().getStyle().setProperty("position", "relative") right after removing myChildAbsolutePanel from its parent AbsolutePanel.
Far from being beautiful - but works for me.