Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 4 years ago.
Improve this question
In our project we both use input type=hidden elements and divs with display:none css for storing some data on html page without showing it to user.
So i wonder which way is more suitable in both performance and code integrity and html semantics?
The hidden input will be hidden regardless of the styling rules of the document (CSS), this may make it better performance wise but I don't have the data to show this. Having said that, input controls are meant to be submitted as part of a form.
There are other methods as well, like the HTML5 custom data attributes or using a script tag:
<!-- Custom data attribute -->
<div id="product" data-id="42">
<h1>Product name</h1>
</div>
<!-- JSON data embedded in a script tag -->
<script type="application/json">
{ "id": 42 }
</script>
There are many factors involved in performance. But unless you are storing a ton of data the performance differences are likely indistinguishable.
What's best for code integrity and semantics is dependent upon the data and how you are using it.
There are many options for storing data:
Storing data in a hidden input which is great for use with forms:
<input name="mydata" type="hidden" value="some data" />
Storing data in a hidden html tags which is often frowned upon by search engines because of it's abuse in trying to improve SEO ranking:
<div id="mydata" style="display:none">
some data
</div>
Storing data in javascript which is great for quick easy access:
<script type="text/javascript">
var data.id = 123;
var data.list = ["Yes","No","Maybe"];
</script>
Storing data in a META Tag which I've used on a rare occasion: http://code.lancepollard.com/complete-list-of-html-meta-tags#create-custom-meta-tags
<meta name="mydata" content="some data"/>
Storing data in a cookie which as long as cookies haven't been disabled this option allows for the data to expire:
http://www.w3schools.com/js/js_cookies.asp
HTML5 has an SQLite database:
http://html5doctor.com/introducing-web-sql-databases/
HTML5 specs allows for custom data attributes
http://html5doctor.com/html5-custom-data-attributes/
Semantics dictates the answer is - it depends on how you're using it.
If the data needs to be submitted as a form or is closely related to a form then use the input. I'm not sure what situations wouldn't fall in that category, since data that's only used on one page can be stored in a javascript variable if the user shouldn't see it.
I think, that first solution (with input type=hidden) is more pretty, because second solution depends on css, which may be disabled in browser and your data will be shown to user.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
What's the difference between HTML and XML?
I'm well familiar with HTML, but my knowlege about XML very limited.
In old-fashioned HTML we were forced to write something like:
<div>
<p>Hi</p>
</div>
In other words, in HTML we have limited set of tags.
Unlike XML, where we can specify our own tags:
<letter>
<to>John</to>
<from>Mike</from>
<date>01.01.2017<date>
<contents>Hi!</contents>
</letter>
However, now I have Chrome installed on my computer, and it's history page looks like this:
<body>
<history-app>
<history-router>...</history-router>
<history-toolbar>...</history-toolbar>
<div>
<history-side-bar>...</history-side-bar>
<iron-pages>...</iron-pages>
</div>
</history-app>
</body>
As you can see, there are a lot of tags, which are not exist in HTML.
The same case with AngularJS, where we can create our own custom tags.
So I'm a bit confused is there any real difference between XML and HTML in modern times.
Also, maybe (I'm not sure, because as I said, my knowledge about XML is very limited), XML provides some rules (schemes) about how tags can and can not be organized. For example, I have some scheme called "Standard Letter", and according to this scheme, tag <letter> should always contain tags <to> and <from>, and moreover, <to> must be the first. Hm... but HTML also has such requirements. For example, <table> always must have <tr> inside, and <td> inside <tr>.
Previously, I've asked about difference between DocBook and HTML. But I've also decided to reformulate it in a new manner, as described above (XML vs. HTML).
HTML and XML are both markup languages that share a common heritage with an older markup language, SGML.
Use HTML (and CSS) when you wish to target presentation in web
browser.
Use XML when you wish to define custom markup for documents. XML
will allow a document to be marked up for what content is rather than
for how content should look. Content can then be decoupled from its
presentation, allowing content to be independently translated to different
media such as web or print automatically.
(And use JSON when you wish to define custom data formats that are data rather than document oriented.)
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.
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
A form is the only way, traditionally, to send data back to the server from the client. Any element inside the form which has a name attribute will be sent to the server when the user clicks the form's submit button, and the server can use the value of any of those elements. The programmer may hard-code the value attribute into the element and the user would not be allowed to change it, such as for checkboxes, radio buttons, and disabled text controls, or could allow the user to change the value, such as for regular text controls. If the programmer does not hard-code the value attribute and it is not an element that allows the user to change it, I believe it gets the values "true", if it is enabled, and "false", if it is disabled. "Enabled" and "disabled" may mean different things for different elements.
HTML before 5 required all of these elements to be in some form in order for the server to obtain their values, and it only got the values of the elements in the form the submit button was associated with, whether or not the elements had a name or value attribute. HTML5 still required the elements to be associated with a form to be submitted to the server, but they do not need to be inside the form anymore. HTML5 has ways for this to happen, usually by adding a form*something* attribute to the relevant elements.
My question is, why did all this come about? What is so special about forms that they became pretty much the only way to send data to a server until recently?
I guess the simplest way to answer this is: it was needed and is still needed.
<form> is an html tag that allows you to perform GET/POST/etc. operations without writing any code in javascript/serverside.
I think that's the simple answer to this question. When there's a need... there's a way.
You can do that in 10 other ways, but the plain vanilla html version is <form>
<form> defines an easy boundary for the user agent to be able to identify all the elements to be submitted to the server. It also allows the user agent to attach convenient default behaviors to the form and the form's child elements. For example being able to hit enter and the form data is submitted. It also allowed for a place to specify where the data would go via attributes on the form element. So all this behavior is available by default without JavaScript. At the same time it also allows easier access in JavaScript via the DOM (form.elements collection)
Why it has changed is because a significant number of sites are now using AJAX to submit the data, and the need for the default behavior is unnecessary in these cases. Often form may be included only as a formality and have no relevant attributes.
So in HTML5 they've allowed the old pattern as well as expanded the capability for developers who may be using AJAX and not need the default behaviors. Or for designers who may need flexibility in where they are placing their form elements (outside of the traditional hierarchy), while at the same time creating connections and keeping semantics alive.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I understand that rel got something to do with relationships between things (documents? elements?) but I don't really get anything past that. What exactly does it do when used in the achor tag ?
Also, are there specific values for x in rel="x"?
Typically they are used to provide information to search engines about the structure of your website. For instance, you can give links a next or prev rel attribute for paginating links (links which show the next/last set of search results); A nofollow to inform search engines not to crawl (this is also good for not passing SEO 'link juice' to external or low priority pages); Or you could supply a canonical value to tell search engines which is the default link for the page it is looking at (sometimes pages are accessible via a number of different links, and this avoids indexing of duplicate content which could hurt your SEO).
This describes only a few possible uses - it is a very versatile tag.
With regards to navigation, pagination and canonicalization, here are couple of useful links from Google:
https://web.archive.org/web/20180125083221/https://support.google.com/webmasters/answer/1663744
https://support.google.com/webmasters/answer/139394
it specifies the relationship between the current document and the linked document.
here you can find a good reference:
http://reference.sitepoint.com/html/a/rel
and this was helpfull to me too
http://www.falsepositives.com/index.php/2009/03/24/html-tags-and-rel-attributes-you-really-should-know/
Regards
the rel attribute links files such as CSS(cascading Stylesheets) JS(Javascript), and other indexed files to its sources.
For example if I wanted to link a stylesheet to my index.html
I would type
<link rel="stylesheet" href="style.css" type="text/css" media="all" />
Let's see some examples of possible values of rel, which indicates the relationship between the href page(linked document) and the actual page:
cc by 2.0
Here the page indicates that the destination of that hyperlink is a license for the current page
<a rel="directory" href="http://dmoz.org/Computers/Internet/">Computers/Internet</a>
In this one the page indicates that the destination of the hyperlink is a directory listing containing an entry for the current page.
Check more at http://microformats.org/wiki/rel-faq#How_is_rel_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?