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
Related
Considering the following JavaScript, CSS, and HTML codes:
console.log(getComputedStyle(document.querySelector('p'), '::after').getPropertyValue('content'));
p::after {
content: "Hello" attr(data-after);
}
<p data-after=" World"></p>
Both Firefox and IE11 return the raw value defined in CSS: "Hello" attr(data-after), which is what I need.
But Chrome returns "Hello World", the parsed value.
When I use the Chrome DevTools to inspect the element, I can see it showing the following information in the "Styles" panel:
p::after {
content: "Hello" attr(data-after);
}
So it looks like Chrome still has the ability to know the raw value.
Is there any JavaScript solution to make Chrome return the raw value defined in CSS like Firefox and IE11 do? Even Chrome's exclusive method is fine, as long as it can be used in JavaScript.
Situation Explained
In response to a member's question about the reason, here is the situation:
I'm trying to create a "polyfill" for CSS speak: never on pseudo-elements. The speak property is not being supported by any browser at the moment.
CSS pseudo-elements can be read by screen readers, and it's currently not possible to hide them easily from screen readers. The commonly approach to that issue is using HTML code such as <span aria-hidden="true">...</span> instead of the convenient CSS pseudo-elements and speak: never, and such an approach is inconvenient and disappointing, in my opinion.
So this polyfill is mainly about web accessibility.
How this polyfill works will be requiring CSS developers to write a bit of extra CSS code as an indicator, such as attr(speak-never):
p::after {
content: "please make me inaudible" attr(speak-never);
}
And then in JavaScript, the polyfill loops through every element on the page and checks if its pseudo-elements ::before and ::after's values of CSS content property contains attr(speak-never). If that indicator string is found, then the polyfill fix the pseudo-elements (by adding custom elements <before aria-hidden="true">...</before> and <after aria-hidden="true">...</after> programatically).
Now the problem is that Chrome cannot return the said attr(speak-never) in JavaScript. Although the polyfill can also work by requiring CSS developers to add one more indicator such as --speak: never for Chrome, it is better that the polyfill keeps CSS developers' works as simple as possible and does not require that extra --speak: never indicator.
So that's why this question was created.
Update
I had decided to use counter-reset: speak-never as the indicator instead because it can be read in JavaScript by all browsers.
Not sure that adding something like attr(speak-never) is any cleaner than going through the HTML markup...
But this question points to an interesting thing: Chrome has started the implementation of CSSTypedOM, that we should have been able to use in order to find the original values set, as demonstrated in this answer.
However, to target pseudo-elements, it is planned that there will be a PseudoElement interface, and an extension to the Element one so that we can call Element.pseudo(::type) in order to target its pseudo-elements. But this part of the specs has not yet been implemented by Chrome, so there is actually currently no way to access the TypedValues of pseudo-elements in Chrome.
So this leaves us with parsing the stylesheets ourselves, with all the caveats that made the w3c develop a real API: no access to cross-origin stylesheets, no direct way to know if a rule is active on the element or if an other one has more importance and the like...
You could lookup the rule via document.styleSheets. The property facilitates a list of stylesheets consisting of multiple rules consisting of multiple properties. You could then traverse the stylesheets and rules and extract the raw property value from there.
This is a basic approach that respects rules directly defined in <style> and <link> elements:
for (let sheet of document.styleSheets) {
for (let rule of sheet.rules) {
if (/:(before|after)$/.test(rule.selectorText)) {
console.log(rule.style.content);
}
}
}
Note that #include-ed stylesheets or #media-queries are not handled here. They can be accessed by checking for rule.type being 3 or 5 respectively and traversing the styleSheet attribute of that rule. See the list of types.
I am thinking about experimenting with a custom stylesheet. One big issue that I've seen for a long time is the simple fact that we only have h1 and p tags for typography.
It would make a lot more sense to (me to) have descriptive tags such as <hero>, <copy>, <micro>, <mini> etc that can be used instead of doing weird things like <h1 class='hero'>.
What actually happens with evergreen browsers & IE 10+ if you just define a new tag? It does work in general at least in chrome to just define a new tag and assign some CSS properties to it. However, will there be limitations on how we could use Javascript on a tag defined like this? Are there any big downsides?
I am not considering defining a webcomponent for <hero> since that would need to register a component whenever it gets attached which I'm sure would be heavy on performance for something as simple as a heading hero tag. Last time I remembered the html5shiv did something like this for IE8 or IE9. When it wouldn't know the tag it would just convert the tag to a block level element I think with standard properties. Is this what is happening in all evergreen browsers as of now, meaning as long as we don't need special events, methods and properties defined on a tag it would be ok to just write tags such as <hero>?
The the browser will stick the unrecognised element in the DOM with some default styling on the assumption that it is a new feature (and in the hope that there will be a CSS/JS shim to add backwards compatibility) rather than falling over because it's been given invalid HTML.
(Then, in the future, an element of that name does get added to the spec, and your page breaks).
Don't write invalid HTML.
I'm looking for a consistent cross-browser solution to style custom elements like a DIV. (Ie: resetting to DIV styling as a starting point). Chrome seems to treat custom elements like a span.
Here's what I use custom elements for:
For a Restrict: E angular directive.
As part of a directive's template so I can select a child element using element.find('custom-element') from the directive's link or controller function. This is occasionally necessary when building a directive that requires calculating child element dimensions and/or position.
Is it as simple as doing this:
custom-element {
display: block;
}
Or are there gotchas that I should be aware when dealing with certain browsers?
Custom tags is strongly discouraged by those who are working on HTML standards. IE8 and lower forms of Internet Explorer do not by default support unknown tags, the solution is to add a script to create the element.
<!--[if lt IE 9]>
<script>
document.createElement('custom-element');
document.createElement('header');
document.createElement('nav');
document.createElement('section');
document.createElement('article');
document.createElement('aside');
document.createElement('footer');
</script>
<![endif]-->
HTML5 specifies that unknown tags are not erroneous for the browser, but they are for code checkers. Browsers should allow them to be styled with CSS just like tags that the browser is familiar with, and by default they are inline elements not blocks.
The purpose of this is not that everybody creates their own set of tags, which will cause confusion, but to allow new tags to be created into the future without breaking older systems.
Violations of HTML5 standards in the way you are implementing are considered will full violations and are used to consider how to improve the standard when things can not be done using the standards.
To accomplish what you are trying to accomplish, using standards, they have added data attribs and custom attribs http://html5doctor.com/html5-custom-data-attributes/ ...
<div customElement="true"></div>
document.querySelectorAll('[customElement]');
... which is what the html5 standards people would like you to use.
Note customElement="true" is a commonly used willful violation
Is it possible to embed some code in Javascript or CSS for a particular webpage to disable (not load) the user agent style sheet that comes with the browser? I know that I can override it by CSS, but that creates lots of overriden specifications, and that seems to highly affect the CPU usage when browsing the page. Especially, I did something like *{margin:0; padding: 0}, which seems to be expensive for rendering (particularly the * selector is expensive). So, I do not want to heavily override the user agent style sheet but rather disable that in the first place if possible. Is this possible? If so, how? I am especially using Google Chrome, but would expect a cross browser way if possible.
I wonder whether there is a way to disable user agent style sheet directly in JavaScript. There does not seem to be any direct way, since document.styleSheets does not contain the user agent style sheet. On the other hand, Firefox Web Developer Extension has, in the CSS menu, an option for disabling Browser Default Stylesheet.
Anyway, there is a markup way, though I’m not sure whether you like its implications. To start with, it does not work on IE 8 and earlier (they’ll show just XML markup, not the formatted content). But modern browsers can handle this:
Use XHTML markup but do not include the xmlns attribute in the html tag.
Serve the document as application/xml.
For elements that should be handled with their HTML semantics (e.g., input creates an input box), use the xmlns="http://www.w3.org/1999/xhtml" attribute on the element or an enclosing element.
Simple demo.
This means that outside the effect of xmlns attributes, all markup is taken as constituting pure, meaning-free, formatting-free (all elements are inline) elements. They can be styled in your stylesheet, though.
But this way, you cannot both keep the HTML cake and eat it. That is, you cannot get HTML functionality (for form fields, links, etc.) without having user agent stylesheet being applied to them.
Use a "reset stylesheet" - this one is good: http://html5boilerplate.com/
It's not possible. Just create a css file called by most of the people 'reset.css' which includes all the css code used to override user agent's styles
You can use something like reset css (http://www.cssreset.com/) to reset all browser styles..
or, what i prefer, use normalize css (http://necolas.github.com/normalize.css/) that normalizes the css without resetting all styles like list styles on ul, li etc. (reset.css would do that)
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."