Using XMLSerializer on a DOM that contains polymer elements, exposes the shadow dom of those elements (using polymer 1.0 and and chrome 54). Not sure what to make of it, possibly it is to be expected, but perhaps someone has a solution to not having the shadow DOM exposed without performing serialization "by hand".
As an example, please see https://gist.github.com/jcage2010/5a92686317bef63d711bac74bc6d5944
This doesn't look you're running with native shadow DOM. (Note the 'style-scope' attributes, for example. To turn on native shadow DOM, see:
https://www.polymer-project.org/1.0/docs/devguide/settings
I would be surprised if this was the case with native shadow DOM, but I'd expect to see all of the nodes in shady DOM.
Related
I must access the slot of an ionic page to insert the 'background: inherit' on it. I tried everything and still I cant access it via CSS.I must access this slot tag
You can not access (select via CSS rules) elements that are part of shadow DOM - that is by design. You can read more here: https://www.joshmorony.com/shadow-dom-usage-in-ionic-web-components/
You have options:
Either the element you need to change exposes CSS variable that you can access and modify
You might re-write component / make your own
You can try and "hack" it using a directive that adds another "style" element to the shadow dom: https://forum.ionicframework.com/t/ionic-v4-shadow-dom/137350/3
I've been developing using GWT 2.3.0 and GXT 2.2.5. I was finally able to move up to GWT 2.4.0 and decided to look into what it would take to migrate to GXT 3.0, but right off the bat I hit a snag.
The application does a lot of blocking the user by masking the browser. I use the following commands to do so:
XDOM.getBodyEl.mask();
XDOM.getBodyEl.unmask();
First thing I noticed was that in 3.0, XDOM no longer has the getBodyEl() method, so I have no way of retrieving the top document widget from anywhere in the application. I do see there is now a Mask class, but since it requires an element parameter to work, I'm still in need of a reasonably easy way to get the document body element.
I've tried searching through the Sencha forums with no success. Any suggestions as to how I could do this?
This is one of those good news/bad news situations. The good news is that El is gone, no more confusion with when to wrap, when to El.fly, when to save a reference, etc. More good news: the new version is called XElement, and to turn an Element into an XElement, you simply cast (either java cast or jso .cast()):
Element elt = ...;
XElement oneWay = elt.cast();
XElement theOtherWay = (XElement) elt;
Either way works, no overhead. All the magic of El, with none of the confusion.
Except for the bad news. But first, some additional good news:
This change is part of a bigger strategy to try to do things The GWT Way, simplifying how many guides are needed to do anything, and getting rid of some of the duplication that GXT does of existing GWT features. Most of that duplication makes sense either when you look at how GWT has grown over the years, and the rest usually make sense when GXT needs a little more power than what GWT offers (layout panels vs layout containers, RootLayoutPanel vs Viewport, HasData vs Stores, etc). Other areas where GXT is now using GWT stuff: HTML, Label widgets, SafeHtml and other string formatting (except XTemplates, which is SafeHtmlTemplates plus awesome), supporting RPC/RequestFactory/anything-else-that-looks-like-an-object, the Cell API, the Editor framework, etc.
Bad news:
Now that it is Just That Easy to get an XElement out of anything, most of the convenience methods to transform things into El objects are gone too. XDOM is still there, but it only does a few things now, mostly things that DOM or Document can't do for whatever reason (side note: GWT's DOM class is at least half deprecated now and may be going away in GWT 3 or so).
So, when you get the dom element that you want to do something with (like mask), you have to cast it first. In the case of your body element masking, this will look a little like this in GXT 3:
Document.get().getBody().<XElement>cast().mask("Loading...");//or null if you don't want text
You could also grab the Mask class and do it that way (this time with a java cast to demonstrate that its all the same):
Mask.mask((XElement) Document.get().getBody(), "Loading...");
GWT screens are composed of a hierarchy of Widgets each implemented by various application classes. In order to maintain (add/change) these screens it is required to understand its structure, namely to discover which screen element is rendered by which Widget implementation.
Currently, I am trying to read the "suspected" class source while peeking at the DOM structure of the screen.
I am looking for a tool, or method, to aid with discovering which Widget class renders a specific screen element.
Such a tool would monitor the mouse position on screen and provide the class name of the hovered element (for example, in a tooltip).
Alternatively, I would be happy to find a programming method that allows adding a generic mouse event handler, most desirable to the RootPanel, further displaying the class name of currently hovered element.
Unfortunately AFAIK ,as of now there is no such tool for GWT( will be more happy if any ) .
As on browser side there is no such information available related to class files of java available since it compiled to javascript.
So , what's the fix??
Though very common and tradational.
1)Proper naming conventions
2)Proper package structure
3)Documentation etc ...
Check out the GWT-Instrumental project for an example of how this can be achieved. This is not a new project and may need to be updated to be properly useful in some cases, but seems to work with GWT 2.4 and GWT 2.5.1 projects just fine. The Inspector bookmarklet/instructions can be found at http://gwt-instrumental.googlecode.com/svn/latest/inspectorwidget/index.html.
This isn't doing exactly what you are describing, but could be modified fairly simply. What it does do is this:
When launched (or refreshed), look at every element on the page to see what widget might be references, and what css classes it has, what id it has, and what DOM events are sunk on it.
When expanded, renders a firebug-like tree of the DOM elements in the body, along with the details mentioned above
When the user hovers over a element in the tree, draws a yellow overlay on where that item is drawn on the page so you can find it.
I have a Backbone application that appends elements to the DOM. When I log these DOM elements to the console, they sometimes appear greyed-out and isolated in the Firebug inspector, like this:
http://cl.ly/0N0s451G0W2L0x0r072r
Other times, they are shown in full colour and within the context of the DOM. Here is the same element, at a different time in my Backbone app:
http://cl.ly/2k2j0I3g2D0R0K121i3t
I'm guessing that a greyed-out, isolated treatment denotes an element that is not appended to the DOM—but I'm troubleshooting a bug in my app and it would be helpful to be 100% sure.
You guessed right. That "greyed-out" element is detached from DOM.
Is Dom loaded before CSS in our webpage ?
Yes. Since the browser uses the DOM to locate elements to be styled, it needs to load the DOM first to do that. This is NOT true of javascript, though (as an aside).