Also what is the best way to hide the elements from the DOM so that the attacker won't be able to change the css property or html attribute in order to access the element. I know we can use React or Angular to develop website and it is easier to hide or display elements. But I want to know in pure HTML & JS what is the best way?
Anyone can just use the browser console and find all elements with for example:
document.querySelectorAll('*');
It does not matter if elements are hidden with CSS.
Even if you encrypt your HTML you will have to decrypt it to show it to the browser. Then the above code still finds all the elements.
Any code you have can be deactivated by setting a breakpoint and rewriting it in-browser using the developer tools.
Even if you replace document.querySelectorAll and all like them with an empty function, developers can still just add jQuery or any DOM querying engine and find your elements that way.
Any code you can use to hide or show elements can just be executed using the browser console if someone spends the time understanding your code.
How else would you debug or test it?
Angular, Vue etc. does remove elements from the DOM but you should never expect this to be a security feature! A hacker can easily set a breakpoint anywhere in your code, inspect API results from the Network panel, go into the components' code to find out what HTML they would be rendering and much more I haven't started to mention.
To implement security you want to only have in the browser what the user needs to see.
There is no way around it.
DOM, stylings, scripts, assets, etc. can always be accessed using developer tools.
As for the question in your question title:
style attribute styles have a higher specificity than CSS from file (or style tags)
CSS from file (or style tags) with !important has higher specificity than styles from the style attribute
style attribute styles with !important have the highest specificty
So !important just overrides specificity if you want to look at it that way. Other than that you should read about CSS Specificity.
Both are same. If you store your value from html hidden or css hide. Anyone can find out them.
So if you are using html , js & css and want to pass value as hidden than disable developer tool and shortkey to open it by this way you can protect your data or else use any encryption method for that.
I've been unable to find a definitive answer to whether custom tags are valid in HTML5, like this:
<greeting>Hello!</greeting>
I've found nothing in the spec one way or the other:
http://dev.w3.org/html5/spec/single-page.html
And custom tags don't seem to validate with the W3C validator.
The Custom Elements specification is available in Chrome and Opera, and becoming available in other browsers. It provides a means to register custom elements in a formal manner.
Custom elements are new types of DOM elements that can be defined by
authors. Unlike decorators, which are stateless and ephemeral, custom
elements can encapsulate state and provide script interfaces.
Custom elements is a part of a larger W3 specification called Web Components, along with Templates, HTML Imports, and Shadow DOM.
Web Components enable Web application authors to define widgets with a
level of visual richness and interactivity not possible with CSS
alone, and ease of composition and reuse not possible with script
libraries today.
However, from this excellent walk through article on Google Developers about Custom Elements v1:
The name of a custom element must contain a dash (-). So <x-tags>, <my-element>, and <my-awesome-app> are all valid names, while <tabs> and <foo_bar> are not. This requirement is so the HTML parser can distinguish custom elements from regular elements. It also ensures forward compatibility when new tags are added to HTML.
Some Resources
Example Web Components are available at https://WebComponents.org
WebComponents.js serves as a polyfill for Web Components until they are supported everywhere. See also the WebComponents.js github page & web browser support table.
It's possible and allowed:
User agents must treat elements and attributes that they do not
understand as semantically neutral; leaving them in the DOM (for DOM
processors), and styling them according to CSS (for CSS processors),
but not inferring any meaning from them.
http://www.w3.org/TR/html5/infrastructure.html#extensibility-0
But, if you intend to add interactivity, you'll need to make your document invalid (but still fully functional) to accomodate IE's 7 and 8.
See http://blog.svidgen.com/2012/10/building-custom-xhtml5-tags.html (my blog)
Basic Custom Elements and Attributes
Custom elements and attributes are valid in HTML, provided that:
Element names are lowercase and begin with x-
Attribute names are lowercase and begin with data-
For example, <x-foo data-bar="gaz"/> or <br data-bar="gaz"/>.
A common convention for elements is x-foo; x-vendor-feature is recommended.
This handles most cases, since it's arguably rare that a developer would need all the power that comes with registering their elements. The syntax is also adequately valid and stable. A more detailed explanation is below.
Advanced Custom Elements and Attributes
As of 2014, there's a new, much-improved way to register custom elements and attributes. It won't work in older browsers such as IE 9 or Chrome/Firefox 20. But it allows you to use the standard HTMLElement interface, prevent collisions, use non-x-* and non-data-* names, and define custom behavior and syntax for the browser to respect. It requires a bit of fancy JavaScript, as detailed in the links below.
HTML5 Rocks - Defining New Elements in HTML
WebComponents.org - Introduction to Custom Elements
W3C - Web Components: Custom Elements
Regarding The Validity of The Basic Syntax
Using data-* for custom attribute names has been perfectly valid for some time, and even works with older versions of HTML.
W3C - HTML5: Extensibility
As for custom (unregistered) element names, the W3C strongly recommends against them, and considers them non-conforming. But browsers are required to support them, and x-* identifiers won't conflict with future HTML specs and x-vendor-feature identifiers won't conflict with other developers. A custom DTD can be used to work around any picky browsers.
Here are some relevant excerpts from the official docs:
"Applicable specifications MAY define new document content (e.g. a
foobar element) [...]. If the syntax and semantics of a given
conforming HTML5 document is unchanged by the use of applicable
specification(s), then that document remains a conforming HTML5
document."
"User agents must treat elements and attributes that they do not
understand as semantically neutral; leaving them in the DOM (for DOM
processors), and styling them according to CSS (for CSS processors),
but not inferring any meaning from them."
"User agents are not free to handle non-conformant documents as they
please; the processing model described in this specification applies
to implementations regardless of the conformity of the input
documents."
"The HTMLUnknownElement interface must be used for HTML elements that
are not defined by this specification."
W3C - HTML5: Conforming Documents
WhatWG - HTML Standard: DOM Elements
N.B. The answer below was correct when it was written in 2012. Since then, things have moved on a bit. The HTML spec now defines two types of custom elements - "autonomous custom elements" and "customized built-in elements". The former can go anywhere phrasing content is expected; which is most places inside body, but not e.g. children of ul or ol elements, or in table elements other than td, th or caption elements. The latter can go where-ever the element that they extend can go.
This is actually a consequence of the accumulation of the content model of the elements.
For example, the root element must be an html element.
The html element may only contain A head element followed by a body element.
The body element may only contain Flow content where flow content is defined as the elements: a,
abbr,
address,
area (if it is a descendant of a map element),
article,
aside,
audio,
b,
bdi,
bdo,
blockquote,
br,
button,
canvas,
cite,
code,
command,
datalist,
del,
details,
dfn,
div
dl,
em,
embed,
fieldset,
figure,
footer,
form,
h1,
h2,
h3,
h4,
h5,
h6,
header,
hgroup,
hr,
i,
iframe,
img,
input,
ins,
kbd,
keygen,
label,
map,
mark,
math,
menu,
meter,
nav,
noscript,
object,
ol,
output,
p,
pre,
progress,
q,
ruby,
s,
samp,
script,
section,
select,
small,
span,
strong,
style (if the scoped attribute is present),
sub,
sup,
svg,
table,
textarea,
time,
u,
ul,
var,
video,
wbr
and Text
and so on.
At no point does the content model say "you can put any elements you like in this one", which would be necessary for custom elements/tags.
I would like to point out that the word "valid" can have two different meanings in this context, either of which is potentially, um, valid.
Should an HTML document with custom tags be considered valid HTML5?
The answer to this is clearly "no." The spec lists exactly what tags are valid in what contexts. This is why an HTML validator will not accept a document with custom tags, or with standard tags in the wrong places (like an "img" tag in the header).
Will an HTML document with custom tags be parsed and rendered in a standard, clearly-defined way across browsers?
Here, perhaps surprisingly, the answer is "yes." Even though the document would not technically be considered valid HTML5, the HTML5 spec does specify exactly what browsers are supposed to do when they see a custom tag: in short, the custom tag acts kind of like a <span> - it means nothing and does nothing by default, but it can be styled by HTML and accessed by javascript.
To give an updated answer reflecting modern pages.
Custom tags are valid if either,
1) They contain a dash
<my-element>
2) They are embedded XML
<greeting xmlns="http://example.com/customNamespace">Hello!</greeting>
This assumes you are using the HTML5 doctype <!doctype html>
Considering these simple restrictions it now makes sense to do your best to keep your HTML markup valid (please stop closing tags like <img> and <hr>, it's silly and incorrect unless you use an XHTML doctype, which you probably have no need for).
Given that HTML5 clearly defines the parsing rules a compliant browser will be able to handle any tag that you throw at it even if it isn't strictly valid.
Custom HTML elements are an emerging W3 standard I have been contributing to that enables you to declare and register custom elements with the parser, you can read the spec here: W3 Web Components Custom Elements spec. Additionally, Microsoft supports a library (written by former Mozilla devs), called X-Tag - it makes working with Web Components even easier.
Quoting from the Extensibility section of the HTML5 specification:
For markup-level features that can be limited to the XML serialization and need not be supported in the HTML serialization, vendors should use the namespace mechanism to define custom namespaces in which the non-standard elements and attributes are supported.
So if you're using the XML serialization of HTML5, its legal for you to do something like this:
<greeting xmlns="http://example.com/customNamespace">Hello!</greeting>
However, if you're using the HTML syntax you are much more limited in what you can do.
For markup-level features that are intended for use with the HTML syntax, extensions should be limited to new attributes of the form "x-vendor-feature" [...] New element names should not be created.
But those instructions are primarily directed at browser vendors, who would assumedly be providing visual styling and functionality for whatever custom elements they chose to create.
For an author, though, while it may be legal to embed a custom element in the page (at least in the XML serialization), you're not going to get anything more than a node in the DOM. If you want your custom element to actually do something, or be rendered in some special way, you should be looking at the Custom Elements specification.
For a more gentle primer on the subject, read the Web Components Introduction, which also includes information about the Shadow DOM and other related specifications. These specs are still working drafts at the moment - you can see the current status here - but they are being actively developed.
As an example, a simple definition for a greeting element might look something like this:
<element name="greeting">
<template>
<style scoped>
span { color:gray; }
</style>
<span>Simon says:</span>
<q><content/></q>
</template>
</element>
This tells the browser to render the element content in quotes, and prefixed by the text "Simon says:" which is styled with the color gray. Typically a custom element definition like this would be stored in a separate html file that you would import with a link.
<link rel="import" href="greeting-definition.html" />
Although you can also include it inline if you want.
I've created a working demonstration of the above definition using the Polymer polyfill library which you can see here. Note that this is using an old version of the Polymer library - more recent versions work quite differently. However, with the spec still in development, this is not something I would recommend using in production code anyway.
just use whatever you want without any dom declaration
<container>content here</container>
add your own style (display:block) and it will work with any modern browser
data-* attributes are valid in HTML5 and even in HTML4 all web browsers used to respect them.
Adding new tags is technically okay, but is not recommended just because:
It may conflict with something added in the future, and
Makes the HTML document invalid unless dynamically added via JavaScript.
I use custom tags only in places that Google does not care, for ecample in a game engine iframe, i made a <log> tag that contained <msg>, <error> and <warning> - but through JavaScript only. And it was fully valid, according to the validator. It even works in Internet explorer with its styling! ;]
Custom tags are not valid in HTML5. But currently browsers are supporting to parse them and also you can use them using css. So if you want to use custom tags for current browsers then you can. But the support may be taken away once the browsers implement W3C standards strictly for parsing the HTML content.
I know this question is old, but I have been studying this subject and though some of the above statements are correct, they aren't the only way to create custom elements. For example:
<button id="find">click me</button>
<Query? ?attach="find" ?content="alert( find() );" ?prov="Hello there :D" >
I won't be displayed :D
</Query?>
<style type="text/css">
[\?content] {
display: none;
}
</style>
<script type="text/javascript">
S = document.getElementsByTagName("Query?")[0];
Q = S.getAttribute("?content");
A = document.getElementById( S.getAttribute("?attach") );
function find() {
return S.getAttribute("?prov");
}
(function() {
A.setAttribute("onclick", Q);
})();
</script>
would work perfectly fine ( in newer versions of Google Chrome, IE, FireFox, and mobile Safari so far ). All you need is just an alpha character (a-z, A-Z) to start the tag, and then you can use any of the non alpha characters after. If in CSS, you must use the "\" (backslash) in order to find the element, such as would need Query\^ { ... } . But in JS, you just call it how you see it. I hope this helps out. See example here
-Mink CBOS
Initial Research
I am aware of using .css() to get and set the CSS rules of a particular element. I have seen a website with this CSS:
body, table td, select {
font-family: Arial Unicode MS, Arial, sans-serif;
font-size: small;
}
I never liked Arial Unicode as a font. Well, that was my personal feel. So, I would use Chrome's Style Inspector to edit the Arial Unicode MS to Segoe UI or something which I like. Is there anyway, other than using the following to achieve the same?
Case I
$("body, table td, select").css("font-family", "Segoe UI");
Recursive, performance intensive.
Doesn't work when things are loaded on the fly.
Case II
$('<style>body, table td, select {font-famnily: "Segoe UI";}</style>')
.appendTo("head");
Any other better method than this?
Creates a lot of <style> tags!
Ok, if:
Personal Preference
Then use user styles CSS. According to priority, user styles takes precedence above all other styles. Next comes inline-styles, then !important styles, then specificity, then default browser styles. If it's just for personal preference, pack-up a custom CSS with you and a browser that supports it.
You are the developer
Then don't do this in JavaScript or user scripts. Go down to the problem and change those styles! You are just making the browser work more by actually making it parse stuff you don't want. Since you have access to the code, change the styles instead.
However, since your site could be a public site, style it like genericly for everyone. It's not only you that's viewing the site.
Not the developer:
The best way I can think of (and already did this before*) is to remove external stylesheets from the page and replace them with modded versions of your own liking. That is taking a copy of the original CSS file, change what needs to be changed, and then load it via JS by creating a <link> to that external file, or load the contents via AJAX and put them in a <style>. However, this approach is riddled with obstacles. <link> does not have an onload event so you won't know the external CSS was loaded (there are crafty workarounds though) and AJAXing CSS contents imply that your CSS is in the same domain or the browser and server supports CORS.
Another way you can do it is to have JS peek into loaded stylesheets and modify their contents. This is a more JS intensive work since JS looks for your definition to change in a pile of CSS declarations. This is a safer bet, however, I believe not all browsers can traverse CSS styles or at least do it differently across browsers. Also, if you got a large stylesheet, you'd be parsing it every time.
As you said, .css() would be recursive. True, because it applies inline styles to each affected element. This is good in a sense that inline styles are higher up in the priority so whatever is placed using .css(), you are almost sure that they will take effect. However, it's more work intensive since it involves the DOM now.
* The library I created does not remove existing styles, it just loads and unloads predefined styles declared using it's API
Have a look at:
Quirksmode: Change CSS
Totally Pwn CSS with Javascript
Is the only way to change a style to do it per-element in JavaScript? (possible duplicate)
I'm afraid there is no library for that, I really would like to see one...
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."