I want to get all elements in my XML (NativeScript with Vue) that have the same class. Is this possible?
As an extension, is it possible to add custom attributes to existing controls like the TextField (similar to data-* attributes in HTML), and if so, is there a selector that I could use to get all elements having the same data- attribute? (For example, the HTML/CSS equivalent would be something like input[data-customerid="12"])
If you are looking for something like document.querySelector(...), there is a paid plugin - nativescript-dom. FYI, you might find the free / unmaintained version on Github, which is not guaranteed to work with {N} v6.x or later.
If you are looking for Attribute CSS selectors, that's supported out of the box. And Yes, you can add custom attributes in XML.
Related
As a part of Automation testing, I want to hover over this node. which has a complex source code. You can find the code here
. Can someone please say the code which can hover using the syntax .hover(Selector(?)) using TestCafe.
Thanks in advance!
For now, you can select nodes in svg only if it's inserted into the HTML document via the <svg> tag. TestCafe does not support selecting elements in an svg that is imported from a separate document via the <object> tag.
There are multiple ways to select an element in TestCafe using Selector. To do that, you need to identify the element's distinguishing features. These might include the element's id, class, attributes, position in the DOM tree or relation to other elements. Then you need to create a Selector based on one of these features.
For more information on TestCafe selectors see our documentation.
I have a question about extending browser based on QtWebkit. I would like to add custom elements tag.
I googled and there was only one way mentioned - using JavaScript registerElement function.
Apart from it I could modify browser to support new tag but I would like to avoid this method.
Is there another approach that allows me on adding new html elements e.g. plugins ?
regards
Jack
I am developing a kind of HTML+JS control which can be embedded into various web pages. I know nothing about those pages (well, I could, but I don't want to). The control consists of one root element (e.g. DIV) which contains a subtree of child elements. In my script, I need to access the child elements. The question is: how can I mark those child elements to distinguish them?
The straightforward solution is using id-s. The problem here is that the id must be unique in the scope of the entire document, and I know nothing about the document my control will be embedded into. So I can't guarantee the uniqueness of my id-s. If the id-s are not unique, it will work (if used with care), but this does not conform with the standard, so I can meet problems with some new versions of the browsers, for example.
Another solution is to use the "name" attribute. It's not required to be unique -- that's good. But again, the standard allows the presence of "name" attribute only for a restricted set of element types. For example, the "name" attribute is invalid for DIV elements.
I could use, for example, the "class" attribute. It seems to be OK with the standards, but it's not OK with the meaning. "class" should be used for other purposes, and this may be confusing.
Can anybody suggest some other options to implement local id-s for HTLM elements?
You could use the HTML5 data-* attributes so you can give them a custom name with the right meaning:
https://html.spec.whatwg.org/multipage/dom.html#embedding-custom-non-visible-data-with-the-data-*-attributes
Do something like:
<div id="element-id" data-local-id="id-value">
...
</div>
and get the value in JavaScript with:
const el = document.getElementById('element-id');
const { localId } = el.dataset;
If you use a prefix to all of your ID's and or classes such as myWidgetName_98345699- the likelihood of collisions is highly improbable.
<div id="myWidgetName_98345699-container" class="myWidgetName_98345699-container">
jQuery does have selectors that will search for part of an ID, so using common names like container would be smart to stay away from as well. Using a longish alphanumeric mix for the specific part of the ID would be smart also
Typically, including hidden information within the web page required creative approaches. For example:
Storing information within HTML element attributes such as id, class, rel, and title, thus overriding the attributes original intent.
Using <span> or <div> blocks that contain the information, while making such blocks invisible to the user through styling (style="display: none;").
Adding JavaScript code to the web page to define data structures that map to HTML ID elements.
Adding your own attributes to existing HTML elements (breaking the HTML standard itself, and relying on the HTML browser to ignore any syntax errors).
The approaches above are not elegant and are not good coding practice, but the good news is that jQuery has a facility that simplifies associating data to DOM elements in a clean, cross-browser manner.
Use the custom data attributes:
Any attribute that starts with "data-" will be treated as a storage area for private data (private in the sense that the end user can't see it - it doesn't affect layout or presentation.
Defining custom data via html:
<div class="bar" id="baz" data-id="foo">
...
</div>
Associating data-id to specific DOM elements (jQuery):
$('#foo').data('id', 'baz');
Retrieving an element with specific data-id:
var $item = $('*[data-id="baz"]');
This is a follow-up question for In jQuery is it a bad idea to use name=X for all selectors?
I am using Backbone and decided that I wanted a way to differentiate between HTML elements that were bound and those that were not.
So I would write (in HAML):
.container
.title(name='title')
.separator
As you can see it's clear that the dynamic element is title.
The reason for this was so I could mess around with the style and rename classes without worrying about breaking the app. It also means in the template I can tell what the dynamic elements are without needing to go back and forth with the Backbone View.
My question now is, without using the [name] selector, does anyone have a code convention to keep track of which HTML elements are referenced from JS.
I have considering:
Using a common prefix on class names (e.g. class=bind-title)
Using some sort of custom HTML element (
Thanks!
FYI: I'm using CoffeeScript, Backbone and haml_coffee templates.
Updated jsperf to test all suggestions:
http://jsperf.com/class-or-name-attr-lookup/3
I would consider using a class to indicate that it is dynamic.
I'm not sure if you are aware of this but you can have multiple classes on one element. Like so:
.container
.dynamic.title(name='title')
.separator
This works in traditional HAML but I have not tried it with haml-coffee. If it doesn't work, you might have to specify the class like .title{:class => "dynamic"}(name='title').
I prefer this over a prefix on the class name because it's more semantically meaningful, which is how HTML should be used.
I am using data-view attribute on elements being set when rendering my Views.
This helps me to then show a tooltip in a browser window when I hover over View(s).
Out of curiosity, what, if any, impact will it have on a site or page if instead of using IDs or classes for elements, you simply create custom elements w/ JS and stylize them with CSS?
For example, if I create an element "container" and use it as <container> instead of <div class="container">, is there a performance difference or something?
I don't see this being used often and am wondering why?
That's like saying "What if I respect the syntax and grammar of English, but make up all the words?" While this thinking makes for good poetry, it doesn't lend itself well to technical fields ;)
HTML has a defined set of tags which are valid. If you use any tags which are made up, it will be invalid.
Now, that doesn't mean you can't get away with it; on the World Wide Web forgiveness is the default so if you used tags which you made up it wouldn't be the end of the world... but it would still be a bad idea because you'd have no guarantee how browsers handle those tags.
So the only real answer to "what impact will it have on a page if instead of using IDs or classes for elements, you simply create custom elements w/ JS and stylize them with CSS?" is anything could happen. Since you'd be using non-standard HTML elements, you'd end up with non-standard results, which none of us should try and predict.
If you really want to (and/or need to) use custom elements, look into XML. In XML you can "make up" your tags, but can still apply CSS and open the documents in a browser.
For example, save the following two files, and then open the XML file in a browser:
index.xml
<?xml-stylesheet href="style.xml.css"?>
<example>
<summary>
This is an example of making up tags in XML, and applying a stylesheet so you can open the file in a browser.
</summary>
<main>
<container>This is the stuff in the container</container>
</main>
</example>
style.xml.css
summary {
display:none;
}
main container {
border:2px solid blue;
background:yellow;
color:blue;
}
HTML is standardized, you can't simply invent new elements. Some browsers will render the text content of an element they don't recognize, but not all will, and your HTML will not be valid HTML in such a case.
HTML is a defined language, the elements and tags have certain meaning within the format. You cannot invent a new element not only because browsers may render those elements inconsistently, but also because the meaning and structure of the document becomes invalid.
You are best using the element that has the correct meaning for the content you wish to deliver. If you require a generic container for styling, the correct element is a div. There are similar elements that also provide some semantic meaning. I would recommend checking out a HTML tag index and HTML5 doctor for assistance in picking the correct element.
It sounds as though <div class="container">...</div> is the closest to what you need from your brief description.
If custom elements make your HTML easier to read and manage, go ahead and use them.
Since this question has been asked, custom elements have since been added to the WHATWG HTML Living Standard, along with an associated JavaScript API. Some web component frameworks are already implementing some of these specifications. It's no longer taboo like it was back in 2011. (I remember having some unpleasant issues dealing with the DOM in Internet Explorer when trying to use newly-announced HTML5 elements.)
As of writing this (November 2018), custom elements have been implemented into several major browsers. However, the MDN lists Microsoft Edge as having not yet implemented custom elements, although a blog post from 2015 says that the Edge team is "excited to continue to support and contribute to this journey."