Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I'm currently placing some ID's on elements for UI Test automation. These ID's are only being used for testing. Should I be adding data-attributes instead possibly making it more readable to future developers(data-testHandle="mybutton") or should I stick with ID's.
w3.org says:
Custom data attributes are intended to store custom data private to
the page or application, for which there are no more appropriate
attributes or elements.
I'm leaning towards keeping ids but some part of me thinks that future developers would think the ID's aren't used and remove them.
Any best practices here. Thanks.
This is close to being opinion-based, by here is the summary that should help to make a choice.
Why would you use an ID attribute:
this is a common and familiar to everybody doing test automation way to locate elements
this is generally the fastest way to locate elements on a page because selenium gets it down to executing document.getElementById() which is optimized by the modern browsers (though, usually performance of the end-to-end UI tests is not critical)
it is a built-in locator in every selenium language binding
if you would use Firebug or Chrome Developer Tools - the CSS selector and XPath generation tools would generally provide more robust locators using the ids of the element whenever possible
you would build shorter CSS selectors and XPath expressions. E.g. #myid .someclass as opposed to [automation-id=myid] .someclass.
Why would you use a custom attribute:
if you would add, say, automation-id attributes to all the desired elements, you would somewhat namespace/scope it to the test automation - everybody would know what is this for just from the attribute name. Meaning, you would dramatically decrease chances of a developer changing the attribute intentionally as opposed to an id attribute, which can and is usually used for application client-side logic as well (reference to this and this answer)
Also, here are some relevant threads:
Is adding IDs to everything standard practice when using Selenium?
Which is the best and fastest way to find the element using webdriver? By.XPath or By.ID or anything else? And why?
Something Better than IDs for Identifying Elements in Selenium Tests
I would go with the data attribute instead, as you (or someone else) might need to use an ID for targeting the element for JS later. No one is ever going to need to target your custom data attribute for anything other than testing.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 months ago.
Improve this question
A common practice with Custom Elements, at least in Polymer (the most popular Web Components framework), is to define a new custom element. This, IMHO, is not a good practice for rendered elements because the element cannot get rendered progressively and has to wait until it is loaded (registered/defined and built up further).
In the contrary, if the element is extended from a native element, it can progressively be enhanced as the regular elements do. The only reason I can think of against this is that new elements look more elegant (my-element> vs <div is=my-element>).
Am I missing something here? What are the pros and cons of each method?
Update: According to one of the comments, both method are equal in terms of progressive enhancements. However, I have learned a lot more about the differences between the two methods from here, hence, the question remains valid.
With the current state of the Web Component spec being that Apple block the agreement on the is="" attribute it is discouraged to extend native elements in this way. Actually, Polymer 2.0 moves to composition like
<custom-style>
<style></style>
</custom-style>
instead of <style is="custom-style">. See Polymer 2.0 readme
Also you may find this article from component.kitchen interesting.
So, for the time being (like, at least until Web Components v2 spec) you'd rather create wrapper elements for best browser support. Your example would change to
<my-element>
<!-- the "extended" native element is wrapped -->
<div></div>
</my-element>
With Customized Built-In Elements (extended native HTML element), you keep the semantics of the original element.
With Autonomous Custom Elements (new ones), you define your own semantics.
Therefore, the 2 are complementary. You'll use both syntax in the same project, each one depending of each component requirements.
Use case: If you want to create a dashbord whith data grids inside that will fetch their content from a REST service:
Use a new one for the container: <dash-board>. That makes no sense to extend a <div> element.
Extend the table for the data grids: <table is="data-grid" data-src="/rest/users">
Progressive enhancement for Autonomous custom elements
An unknown autonomous custom element is like a <span> element: its default CSS display property is inline, but you can change that to whatever you want: inline-block, flex, etc via <style> CSS rules, to give it some dimensions/layout, thus ensuring "progressive enhancement".
Also you can insert other elements inside it. They will be displayed as usual.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I am working on a website design and my boss told me that usually ids are never used and classes are preferred, but he doesn't remember why. So I did some research and I found this this, but the first answer does not explain very well why ids should not be used. I thought that for an element that is used only once ids were used. If I won't use an element more than once, why should I use a class?
That's related to performance issues. Even though you are using this element for a single time, I would still recommend using a class instead of an id.
Why? 'cause you may add some more classes to this element in the future. But why is this important and related to performance? Take a look at this:
It’s a common belief that ID selectors are the fastest, but this comes
with a big caveat: IDs are fastest CSS selector only if they’re the
key selector. What’s that? Well, while you probably read selectors
from left to right, browsers read them from right to left.
For more details, just check this site.
I would prefer to use classes. Even if it's a single element. Consider what will happen if you want to reuse the CSS for that single element in the future - it will no longer be a single element and you will have to change it to be a class.
Also IDs have additional functionality compared to classes: you can add the #yourId to the URL and make the browser auto-scroll to that element when you open the URL.
Well if you want to use ids or classes entirely depends on your need. Its not good to say that we should not use ids. Here are some key points.
IDS and classes act as hook and they are required to select an element.
Each element can have only 1 id and each page can have that id only once.
You can use the same class on multiple elements.
You can use multiple classes on the same element. Adding a class name
or ID to an element does nothing to that element by default.
ID's have special browser functionality. This is the "hash value" in the
URL. If you have a URL like http://yourdomain.com#comments, the
browser will attempt to locate the element with an ID of "comments"
and will automatically scroll the page to show that element.
Javascript love ids thats why we have document.getElementById();
Jquery loves classes and its very easy to add classes on an element.
Read https://css-tricks.com/the-difference-between-id-and-class/ for more
class is used to classify a group of elements that can be styled together.
So if you are classifying based on any criteria as per your presentation logic, use classes.
id is used to identify a single element using a unique identifier. So if you are uniquely identifying an element in a page use Ids. The validations make sure its following this concept and throws an error otherwise. So as per specification and implementation there is no reliable way we can use class to uniquely identify an element. Which explains why we are having Id.
As a matter of fact, if you have no need to uniquely identify an element in your presentation, you probably don't require this feature at all.
And about performance, think of performance only when its crucial. Don't over optimise and lose readability and semantics unless performance is already affecting your page rendering.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I am working on a project where the development team has outsourced their graphics work to a 3rd party. The CSS files the 3rd party developed are filled with code that allows the developers to assign single CSS declarations to HTML elements using HTML classes.
For example:
.padding-bottom-10 {
padding-bottom: 10px;
}
I have two questions:
Would this setup be considered lazy programming?
Is this setup commonplace?
You must be aware of the following note in the spec when (ab)using class selectors:
Because CSS gives considerable power to the "class" attribute, authors
could conceivably design their own "document language" based on
elements with almost no associated presentation (such as DIV and SPAN
in HTML) and assigning style information through the "class"
attribute. Authors should avoid this practice since the structural
elements of a document language often have recognized and accepted
meanings and author-defined classes may not.
But yes, abusing class selectors is common place.
That is a modifier in the OOCSS methodology.
It promotes the DRY principle of software development. When applied correctly, it improves maintainability as that specific property-value pair is not repeated in other parts of the code.
However, your example's naming is rather poor. padding-bottom-small or padding-bottom-med would be an improvement and more future-proof, as that given constant value may change sometime and the constant in the name would no longer be accurate.
There's indeed a drawback in adding non-semantic class names to the markup, which makes the HTML harder to maintain. The DRY benefits usually overweight this drawback though. Also, pre-processors allow for OOCSS development purely in the CSS (e.g. with Sass' #extend directive and Less' :extend pseudo-class), without polluting the markup with the non-semantic class names.
References
Methods for Modifying Objects in OOCSS
OOCSS + Sass = The best way to CSS by Ian Storm Taylor
NOTE
This is just part of a paradigm to write efficient CSS. Whether it is the best for your use case boils down to the application needs and developers' preference.
Why not ? If you are targetting your webpage into really old retarded versions of IE, using them is sometimes nessescary. For example IE 6 does not know direct child selector ( > ), 7 and 8 still don't know about :last-child and many more....
If multiple classes that define just one thing are to be used on lots of elements then we may as well time warp back to the 90s and start using <font face="sans-serif" color="red" size="4"><b><u><i>A bit of text and stuff</i></u></b></font> because restyling a site or even part of it would require time that could be better used for drinking beer if proper classes had been used.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 9 years ago.
Improve this question
Is it a bad practice have non-HTML tags of the page? I need to use them for internal content processing needs and wonder if there are any troubles with it (SEO for example)?
Yes it is bad. Not particularly for SEO but for browsers. You are relying on the browser to ignore your tags and render the page correctly. Since every rendering engine loads a page slightly differently, you have no way of knowing how it will handle your bad html.
Can you wrap them in html comments? Like so:
<!--<not a real tag>-->
The browser and spiders will ignore these but since they are still part of the html, your parser might still be able to read them.
An alternative is to use HTML5's custom data attributes. Your parser should also be able to read these.
W3C also have an experimental custom elements spec. Browser support looks poor at present but this may be of interest in future.
Yes, it's bad for browsers (and a little for SEO). Each browser could interpret a random tag on its own way.
If you need to do internal content processing, you can store your data in attributes of your existing HTML tags, with data-* attributes (HTML5 spec.), like this:
<div class="simple-div" data-file="./abc.txt" data-pattern="(.+)"></div>
My link!
The HTML document shouldn't store data anyway.
I dont know what you want to do specifically, but you could use an invisible div or hidden field with custom data attributes? or even a comment?
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
From a language-design standpoint, what's the point of creating the id attribute for HTML if you can have a class with only one element? Why not just use classes for everything and not complicate the markup?
I can think of three possible explanations, but they don't fully satisfy me, so I wondered if you know why id was included in HTML. My thoughts are:
The existence of an id helps in creating CSS styles because its greater specificity makes it possible to give an id to one member of a class overriding styles given to other members of that class. This explanation doesn't fully satisfy me because you could just give it an extra class instead and put the styles for that class at the bottom of the stylesheet in a section for styles given to single elements.
When selecting elements with jQuery, the DOM traversal could stop as soon as the element with that id is found. Thus, the existence of an id would make the selection run faster. This explanation doesn't satisfy me because I'm fairly certain that jQuery was created long after ids and classes already existed.
Having an id as a language feature could help to ensure that styles (and selectors) which are supposed to be unique truly are applied to only one element because things go haywire when this isn't the case. This explanation doesn't satisfy me because having your site break when you accidentally create two elements with the same id doesn't seem to be a particularly effective way of informing you that something's gone wrong.
The first publicly available description of HTML was a document called "HTML Tags", first mentioned on the Internet by Berners-Lee in late 1991.
There is a description of anchor tag:
<A NAME=xxx HREF=XXX> ... </A>
HREF
...This allows for the form HREF=#identifier to
refer to another anchor in the same document.
NAME
The attribute NAME allows the anchor to be the destination of a link.
I think NAME attribute here is the predecessor of element's ID: it allowed you to link directly to a desired part of a hypertext page (even if it is the same page).
IDs are unique values so, when you parse the html with something such as javascript, you can be sure of what element your script will hit.
For Javascript anyway getElementById is a few times faster than getElementsByClassName
Test Ops/sec
getElementById 269,235
getElementsByClassName 86,369
ref
More info from the spec
What makes attributes of type ID special is that no two such attributes can
have the same value in a conformant document, regardless of the type of the
elements that carry them; whatever the document language, an ID typed
attribute can be used to uniquely identify its element.
So it is a way to uniquely identify an element, where the class selector could only do so by coincidence.
ref
There are a great many reasons, most of which don't even involve CSS. For example, ajax and JS libraries often require unique IDs, and IDs can act as anchors with URL hashes.
XML is derived from HTML, but used for more generic data. In XML it is very often desirable to have a unique id (the same way it is often necessary in a database). Because XML puts a lot of effort into automated verifiability, the best approach was to simply add the id attribute as a language element. This way, a XML verifier can output an error if the same value is assigned to two id attributes.
Later, many XML features found their way back to HTML, and I guess id is just one of them. It is not strictly needed, but a nice thing to have in combination with Java Script.