Why does CSS work with fake elements?

Question

In my class, I was playing around and found out that CSS works with made-up elements.

Example:

imsocool {
    color:blue;
}

<imsocool>HELLO</imsocool>

When my professor first saw me using this, he was a bit surprised that made-up elements worked and recommended I simply change all of my made up elements to paragraphs with ID's.

Why doesn't my professor want me to use made-up elements? They work effectively.

Also, why didn't he know that made-up elements exist and work with CSS. Are they uncommon?

Because your imaginary tags are not portable..if you show your code to someone else they need to find out what tose tags are supposed to mean. Your CSS code is also not portable or reusable for any other project. — cen, Dec 03 '13 at 14:22
HTML is a way of providing meaning to data which can be understood by a wide variety of mediums (including people and browsers). Your made up tags don't add any meaning. That's one of many reasons why he doesn't want you to use them. — punkrockbuddyholly, Dec 03 '13 at 14:23
It works on older browsers, as long as you create the element before you style it -- that is how the HTML5 shims work, see: http://www.paulirish.com/2011/the-history-of-the-html5-shiv/ — tobi, Dec 03 '13 at 14:24
@MrMisterMan actually I think they do. What's more meaningful - `
555-212-2344
` or 555-212-2344 — Yuriy Galanter, Dec 03 '13 at 14:25
Are you using IE by any chance? Just because it works in one browser doesn't mean it's going to work in all browsers...you're much better off sticking to the standards. — Tim, Dec 03 '13 at 14:27
@YuriyGalanter
is ubiquitous as it is a standard. Nothing will support the tag. — punkrockbuddyholly, Dec 03 '13 at 14:27
@YuriyGalanter That's kinda what I was thinking with a UI framework. Almost like a new bootstrap. — L_7337, Dec 03 '13 at 14:27
@YuriyGalanter — The paragraph is more meaningful (although the meaning is wrong, since the content isn't a paragraph). `` has no meaning, since HTML doesn't give it any. — Quentin, Dec 03 '13 at 14:27
What semantic value does random markup have? How are screen readers supposed to process that? — j08691, Dec 03 '13 at 14:28
@MrMisterMan Just remember, all these rules and programming constructs were made up by people no smarter than you, and you can change it, you can influence it, you can build your own things that other people can use. — L_7337, Dec 03 '13 at 14:38
@L_7337 they were probably much smarter than me to be honest but yes, I see your point. — punkrockbuddyholly, Dec 03 '13 at 15:09
I might point out that what you are doing is basically XML not HTML. XML is a more abstract markup language which allows you to represent data in the "useful" way you describe - ie. with semantic meaning attached. You can then use an XSLT transformation to render your data in HTML — ose, Dec 03 '13 at 16:14
@MrMisterMan Smarter or not, we all have hindsight that they did not when those rules were first made — Izkata, Dec 03 '13 at 16:39
@L_7337: Doesn't matter whether they were smarter, they did it a long time ago and we have decades of legacy software relying on those standards. Yes, they're flawed, and yes many of us could improve on them because we understand their mistakes, but we can't change the past and remove legacy software. — Phoshi, Dec 03 '13 at 16:52
I'd add my answer there, but the "duplicate" question is completely inadequate as far as the scope of the question and the answers go. — Ben Lesh, Dec 03 '13 at 17:18
@blesh I just voted to reopen. The answers there don't really address **this** question.. They are definitely related, but they aren't duplicates. *"Is it possible.."* vs *"Why does..."* — Josh Crozier, Dec 03 '13 at 17:20
Because they wont work, if I create some `made up` browser of my own. I'll allow only known elements ;) — Jashwant, Dec 03 '13 at 20:21
Of course, if you really want to add your own semantic tags to HTML, you can. You just have to create your own doctype that derives from HTML, and you can add as many tags as you want. The default handling in browsers is something you have to test, though (although the specs probably have something to say about that). — Luaan, Dec 04 '13 at 14:29
To add to what ose said: HTML is just an SGML application (being XHTML a (more restrictive) XML application). So, adding custom tags you are just creating your own SGML/XML application. In fact, it would not be more HTML since it wouldnt pass a HTML validator. — trompa, Dec 04 '13 at 15:50
Also, how does the browser know if you have an inline element or a block element? I suppose it can tell to a certain extent, if the element is used within a block of text like `em`, but that wouldn't work with elements that are typically written on separate lines, like `img`. The default is probably block element. Also, most browsers are built to be resilient and catch errors like that. — , Dec 04 '13 at 22:41
Have a look at [Angular.js](http://angularjs.org/). They make heavy use of custom elements (or at least support you doing so). Angular is IMHO the best of the new breed of JavaScript frameworks and used widely. There will always be people that will tell you things aren't allowed or shouldn't be done. If you are going to break the rules, it helps to understand them first. Then you can break them successfully. — Undistraction, Dec 04 '13 at 23:29
@Trompa Although closely related to both SGML and XML, HTML is not actually conformant to either, and the WHATWG Living Standard being accepted as HTML5 explicitly moves away from both. XHTML was the W3C's now abandoned attempt to make it an XML application (earlier versions being only loosely SGML-based), although "XHTML5" exists as an XML-conformant representation for HTML5 if you really want one. — IMSoP, Dec 04 '13 at 23:32
@Jordan, the question asker: you're going to go far in software/web development. The greatest minds see what they can make it do, even if they end up not using it for specification/convention reasons. — Plasmarob, Dec 05 '13 at 00:39
The Semantic Web is supposed to be a web of meaning. Using unknown tags doesn't help the semantic cause at all. Sure they work, but I doubt they should be used by anyone. Think about a large website and 10 front-end developers, how confusing would it be for them to figure out what's happening? — Ali Gajani, Dec 28 '13 at 09:27
You have right. It is the future. Your prof teaches you the presence. — peterh, Jan 01 '15 at 01:27

Quentin · Accepted Answer · 2022-04-13T14:26:30.650

473

Why does CSS work with fake elements?

(Most) browsers are designed to be (to some degree) forward compatible with future additions to HTML. Unrecognised elements are parsed into the DOM, but have no semantics or specialised default rendering associated with them.

When a new element is added to the specification, sometimes CSS, JavaScript and ARIA can be used to provide the same functionality in older browsers (and the elements have to appear in the DOM for those languages to be able to manipulate them to add that functionality).

(There is a specification for custom elements, but they have specific naming requirements and require registering using JavaScript.)

Why doesn't my professor want me to use made-up elements?

They are not allowed by the HTML specification
They might conflict with future standard elements with the same name
There is probably an existing HTML element that is better suited to the task

Also; why didn't he know that made-up elements existed and worked with CSS. Are they uncommon?

Yes. People don't use them because they have the above problems.

edited Apr 13 '22 at 14:26

answered Dec 03 '13 at 14:24

Quentin

914,110
126
1,211
1,335

31

"They are not allowed by the HTML specification" Not necessarily true. They do not conform to the HTML Namespace specification, but the HTML5 spec is a much broader thing that allows for custom specifications, and explicitly states how to handle such things in regards to CSS and API handling (DOM). – Ben Lesh Dec 03 '13 at 17:13
5

There are already libraries, most notably Angular.js, that allow you to extend HTML with custom elements. Perhaps not in the sense that you mean as the elements are just parsed by javascript and translated to real ones usually, but if you are looking to extend html with custom tags, you can do it with Angular – Charlie Martin Dec 03 '13 at 19:39
11

+1 For "They might conflict with future standards". Remember it might work now but it has to work for 3-4 years after you have started. – tim.baker Dec 03 '13 at 22:04
Interestingly, made-up attributes also are rendered properly. http://jsfiddle.net/7ZS87/ – eshellborn Dec 04 '13 at 00:00
70

I like to have a tag to hide dom elements instead of applying style display:none eg: Some hidden stuff – kiranvj Dec 04 '13 at 01:39
18

Another really important point: Special browsers for blind people or people with otherwise limited ability use the proper HTML elements for different things (ease on-page navigation by following headers, for example). So the missing semantics+default rendering might not affect normal browsers too much, but these special browsers will probably be confused, drastically reducing the usability of your web site. – Arve Systad Dec 04 '13 at 14:55
1

Custom tags could be used as form elements with JavaScript to avoid being detected by bots, as they tend to look for `input type="text"` rather than `circus equation="turnip"` – rybo111 Dec 05 '13 at 15:36
1

@kiranvj According to your and others feature requests I'm awaiting to an esoteric HTML specification where all of these will be implemented. – totymedli Dec 06 '13 at 04:45
1

This is a great answer, however i felt @Quentin didn't stress enough on the fact that each and every tag in the specification is named specifically to provide the data it holds a valid or sensible meaning, semantic if you may. Hence when we give structure to the data on our DOM with the help of these tags, we make it very clear for any one who reads it(it can be any rendering engine, including those targeted for people with handicaps) what the purpose of the tag is and what kind of meaning the data within the tag conveys. Its all about adding semantics to otherwise jumbled volumes of data. – Lakmal Caldera Sep 03 '14 at 15:32

score 99 · Answer 2 · edited May 23 '17 at 12:09

TL;DR

Custom tags are invalid in HTML. This may lead to rendering issues.
Makes future development more difficult since code is not portable.
Valid HTML offers a lot of benefits such as SEO, speed, and professionalism.

Long Answer

There are some arguments that code with custom tags is more usable.

However, it leads to invalid HTML. Which is not good for your site.

The Point of Valid CSS/HTML | StackOverflow

Google prefers it so it is good for SEO.

It makes your web page more likely to work in browsers you haven't tested.

It makes you look more professional (to some developers at least)

Compliant browsers can render [valid HTML faster]

It points out a bunch of obscure bugs you've probably missed that affect things you probably haven't tested e.g. the codepage or language set of the page.

Why Validate | W3C

Validation as a debugging tool

Validation as a future-proof quality check

Validation eases maintenance

Validation helps teach good practices

Validation is a sign of professionalism

Another argument for valid code is, if you need to hand over to another developer or you're working in a team, the other members or new developer should instantly understand what you're trying to achieve . . . With invalid, made up tags, this can become very difficult... — Pat Dobson, Dec 03 '13 at 15:57

score 68 · Answer 3 · edited Jan 16 '14 at 03:46

YADA (yet another (different) answer)

Edit: Please see the comment from BoltClock below regarding type vs tag vs element. I usually don't worry about semantics but his comment is very appropriate and informative.

Although there are already a bunch of good replies, you indicated that your professor prompted you to post this question so it appears you are (formally) in school. I thought I would expound a little bit more in depth about not only CSS but also the mechanics of web browsers. According to Wikipedia, "CSS is a style sheet language used for describing ... a document written in a markup language." (I added the emphasis on "a") Notice that it doesn't say "written in HTML" much less a specific version of HTML. CSS can be used on HTML, XHTML, XML, SGML, XAML, etc. Of course, you need something that will render each of these document types that will also apply styling. By definition, CSS does not know / understand / care about specific markup language tags. So, the tags may be "invalid" as far as HTML is concerned, but there is no concept of a "valid" tag/element/type in CSS.

Modern visual browsers are not monolithic programs. They are an amalgam of different "engines" that have specific jobs to do. At a bare minimum I can think of 3 engines, the rendering engine, the CSS engine, and the javascript engine/VM. Not sure if the parser is part of the rendering engine (or vice versa) or if it is a separate engine, but you get the idea.

Whether or not a visual browser (~~others have already addressed the fact that screen readers might have other challenges dealing with invalid tags~~) applies the formatting depends on whether the parser leaves the "invalid" tag in the document and then whether the rendering engine applies styles to that tag. Since it would make it more difficult to develop/maintain, CSS engines are not written to understand that "This is an HTML document so here are the list of valid tags / elements / types." CSS engines simply find tags / elements / types and then tell the rendering engine, "Here are the styles you should apply." Whether or not the rendering engine decides to actually apply the styles is up it.

Here is an easy way to think of the basic flow from engine to engine: parser -> CSS -> rendering. In reality it is much more convoluted but this is good enough for starters.

This answer is already too long so I will end there.

Although you've mentioned that "tags" has become a common term for elements, which I can't and won't disagree with, that doesn't change the fact that the correct term for them is still "elements". A tag is specifically a syntax feature of HTML and XML, and may not exist in other document languages that are compatible with CSS. So, saying that CSS styles "tags" as people often call them isn't doing a whole lot of justice to the document language agnosticism of CSS. — BoltClock, Dec 06 '13 at 08:27

score 54 · Answer 4 · edited May 23 '17 at 12:09

54

Unknown elements are treated as divs by modern browsers. That's why they work. This is part of the oncoming HTML5 standard that introduces a modular structure to which new elements can be added.

In older browsers (I think IE7-) you can apply a Javascript-trick after which they will work as well.

Here is a related question I found when looking for an example.

Here is a question about the Javascript fix. Turns out it is indeed IE7 that doesn't support these elements out of the box.

Also; why didn't he know that made-up tags existed and worked with CSS. Are they uncommon?

Yes, quite. But especially: they don't serve additional purpose. And they are new to html5. In earlier versions of HTML an unknown tag was invalid.

Also, teachers seem to have gaps in their knowledge, sometimes. This might be due to the fact that they need to teach students the basics about a given subject, and it doesn't really pay off to know all ins and outs and be really up to date. I once got detention because a teacher thought I programmed a virus, just because I could make a computer play music using the play command in GWBasic. (True story, and yes, long ago). But whatever the reason, I think the advice not to use custome elements is a sound one.

edited May 23 '17 at 12:09

Community

1
1

answered Dec 03 '13 at 14:23

GolezTrol

114,394
18
182
210

3

@OnoSendai You made me doubt, but I really think they are rendered as 'block elements without additional markup', so basically like divs. – GolezTrol Dec 03 '13 at 14:34
6

@OnoSendai A block element may have the display property of *block*, but it isn't required. For instance, anchor tags were promoted to block status (meaning you're allowed to put block elements like divs inside them), but still have the inline display property. – cimmanon Dec 03 '13 at 14:35
I see - thanks for the clarification, GolezTrol and cimmanon. – OnoSendai Dec 03 '13 at 15:01
8

The initial value of `display` is `inline`, so @OnoSendai's comment is correct. – BoltClock Dec 03 '13 at 16:17
2

@cimmanon: `a` elements have a transparent content model now so whether they are block or inline depends on whether their ancestor is block or inline. This answer is talking about unknown elements, for which HTML does not define a content model. As far as CSS is concerned, if there is no browser default `display` value it uses the initial value. – BoltClock Dec 03 '13 at 16:27
1

@BoltClock'saUnicorn So does that mean that
foo bar
will render the two tags as blocks? That seems a bit suspect... – fluffy Dec 03 '13 at 16:56
@fluffy: I was speaking in terms of HTML content models (until the CSS portion...). It basically means `a` doesn't have any specific content model and so it can be placed virtually anywhere without invalidating the HTML. In terms of CSS, `a` elements default to `display: inline`, and that hasn't changed due to backward compatibility. – BoltClock Dec 03 '13 at 16:58
@BoltClock'saUnicorn Okay, I guess I'm just confused about what you mean by "whether they are block or inline depends on whether their ancestor is block or inline." Does HTML have its own meaning of "block" and "inline?" I've only seen that in reference to the styling aspect before (now covered by CSS). – fluffy Dec 03 '13 at 17:02
@fluffy: Well to be honest I don't know how the terms block and inline came to be in HTML - HTML calls the content models "flow content" and "phrasing content" respectively. They just happen to be analogous to the block and inline display modes in CSS I guess. But indeed, for the most part they are unrelated. – BoltClock Dec 03 '13 at 17:04
@fluffy - "Block" has been a category for elements in HTML since at least HTML 2.0, long before CSS was invented. "inline" doesn't appear until HTML 4.0, at the same time as CSS and is meant to map directly on to display:inline in CSS. As Boltclock says, HTML5 does not use those terms, probably deliberately to avoid confusion with their CSS meanings. On the other hand, 'flow content' is not analogous to either HTML4 block nor CSS block, because it contains phrasing elements and elements like `table` as well as the traditional block elements. – Alohci Dec 03 '13 at 17:30
1

.. In addition, the transparent content model is not quite whether its ancestor is block or inline, but whether its parent allows flow but non-phrasing content or not. For example, the `
` element is not phrasing content (and like block used to be) but only allows phrasing content. So an `` element inside a `
` can only have phrasing content too. But a `
` can have flow, non-phrasing children, so an `` element inside a `
` can have flow, non-phrasing content too.
– Alohci Dec 03 '13 at 17:41
@Alohci Okay, that helps. I'm still not sure about what 'flow content' and 'phrasing content' mean but that's something I can look up on my own. Thanks! – fluffy Dec 03 '13 at 17:43
1

@fluffy - I find it easier to understand flow content by exception. The elements that aren't flow content are the ones that can only appear within specific parents, such as `li` (only within ul and ol), `tbody` (table), `td` (tr), `figcaption` (figure) and so on. – Alohci Dec 03 '13 at 17:47
1

@Alohci I would love for this comment stream to be converted into a Q&A. That’s some great information you’ve hidden down here in comments. – KRyan Dec 08 '13 at 03:39

Bas van Dijk · Answer 5 · 2013-12-03T15:13:04.360

27

Actually you can use custom elements. Here is the W3C spec on this subject:

http://w3c.github.io/webcomponents/spec/custom/

And here is a tutorial explaining how to use them:

http://www.html5rocks.com/en/tutorials/webcomponents/customelements/

As pointed out by @Quentin: this is a draft specification in the early days of development, and that it imposes restrictions on what the element names can be.

edited Dec 03 '13 at 15:13

answered Dec 03 '13 at 14:24

Bas van Dijk

9,933
10
55
91

7

It should be noted that that is a draft specification in the early days of development, and that it imposes restrictions on what the element names can be. – Quentin Dec 03 '13 at 14:26
2

+1 Didn't know W3C uses `github` but indeed they use. – Vitor Canova Dec 03 '13 at 15:00

score 23 · Answer 6 · edited Jun 20 '20 at 09:12

There are a few things about the other answers that are either just poorly phrased or perhaps a little incorrect.

FALSE(ish): Non-standard HTML elements are "not allowed", "illegal", or "invalid".

Not necessarily. They're "non-conforming". What's the difference? Something can "not conform" and still be "allowed". The W3C aren't going to send the HTML police to your home and haul you away.

The W3C left things this way for a reason. Conformance and specifications are defined by a community. If you happen to have a smaller community consuming HTML for more specific purposes and they all agree on some new Elements they need to make things easier, they can have what the W3C refers to as "other applicable specifications". (this is a gross over simplification, obviously, but you get the idea)

That said, strict validators will declare your non-standard elements to be "invalid". but that's because the validator's job is to ensure conformance to whatever spec it's validating for, not to ensure "legality" for the browser or for use.

FALSE(ish): Non-standard HTML elements will result in rendering issues

Possibly, but unlikely. (replace "will" with "might") The only way this should result in a rendering issue is if your custom element conflicts with another specification, such as a change to the HTML spec or another specification being honored within the same system (such as SVG, Math, or something custom).

In fact, the reason CSS can style non-standard tags is because the HTML specification clearly states that:

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

Note: if you want to use a custom tag, just remember a change to the HTML spec at a later time could blow your styling up, so be prepared. It's really unlikely that the W3C will implement the <imsocool> tag, however.

Non-standard tags and JavaScript (via the DOM)

The reason you can access and alter custom elements using JavaScript is because the specification even talks about how they should be handled in the DOM, which is the (really horrible) API that allows you to manipulate the elements on your page.

The HTMLUnknownElement interface must be used for HTML elements that are not defined by this specification (or other applicable specifications).

TL;DR: Conforming to the spec is done for purposes of communication and safety. Non-conformance is still allowed by everything but a validator, whose sole purpose is to enforce conformity, but whose use is optional.

For example:

var wee = document.createElement('wee');
console.log(wee.toString()); //[object HTMLUnknownElement]

(I'm sure this will draw flames, but there's my 2 cents)

Not only does HTML specify how elements should be treated w.r.t. CSS, the CSS spec is, for the most part, document language-agnostic by design as well (this is already kinda-sorta implied in some other answers, but I note it here for convenience). If there's any behavior that is specific to HTML and/or XHTML, **it is always indicated**, even in informative text (e.g. "an HTML element's ID is specified by the `id` attribute"), not just normative text (see [Backgrounds and Borders 3](http://www.w3.org/TR/css3-background/#special-backgrounds) for an example). — BoltClock, Dec 05 '13 at 03:01

score 18 · Answer 7 · answered Dec 03 '13 at 14:42

18

According to the specs:

CSS

A type selector is the name of a document language element type written using the syntax of CSS qualified names

I thought this was called the element selector, but apparently it is actually the type selector. The spec goes on to talk about CSS qualified names which put no restriction on what the names actually are. That is to say that as long as the type selector matches CSS qualified name syntax it is technically correct CSS and will match the element in the document. There is no CSS-specific restriction on elements that do not exist in a particular spec -- HTML or otherwise.

HTML

There is no official restriction on including any tags in the document that you want. However, the documentation does say

Authors must not use elements, attributes, or attribute values for purposes other than their appropriate intended semantic purpose, as doing so prevents software from correctly processing the page.

And it later says

Authors must not use elements, attributes, or attribute values that are not permitted by this specification or other applicable specifications, as doing so makes it significantly harder for the language to be extended in the future.

I'm not sure specifically where or if the spec says that unkown elements are allowed, but it does talk about the HTMLUnknownElement interface for unrecognized elements. Some browsers may not even recognize elements that are in the current spec (IE8 comes to mind).

There is a draft for custom elements, though, but I doubt it is implemented anywhere yet.

answered Dec 03 '13 at 14:42

Explosion Pills

188,624
52
326
405

I think most of us think of them as _element_ selectors but it makes sense that they are "officially" _type_ selectors. – Andrew Steitz Dec 03 '13 at 15:44
@Andrew Steitz: Think of it this way: element : type :: person : name. You can have many elements of different types, with each element being of a single type, and in the same way you can have many people, each having a name. Selectors work on a document tree, and every selector can match some number of document tree elements, which you can narrow down with a class selector, an ID selector, an attribute selector... or a type selector. Whatever you use, you are still matching elements. So "element selector" wouldn't make sense in this case - all of these things would be element selectors. – BoltClock Dec 03 '13 at 16:19
@BoltClock'saUnicorn : True, but class, ID, and attribute are all, uh, attributes (LOL) of an "element", i.e. the "thingy" inside the angle brackets. They describe the "element" whose opening tag they reside in. Yes, and
are specific "types" of elements, but I doubt anyone would call class, ID, and attributes "elements". I TOTALLY agree that all selectors are really "element" selectors but in COMMON USAGE, people usually refer to "type" selectors as "element" selectors. That was the point of my previous comment. Sorry it was unclear. :-)
– Andrew Steitz Dec 03 '13 at 17:01
@ExplosionPills - The HTML specs do not say that unknown elements are disallowed, but since every element has an enumerated list of element names that are allowed as its children, (i.e. its content model), it doesn't have to. There is simply nowhere an unknown element is permitted as the child of a permitted element. Applying HTMLUnknownElement to such elements is part of the precessing spec - i.e. what HTML consumers must do with documents valid or not - and not part of what authors must do to make their documents valid. – Alohci Dec 04 '13 at 08:03
@Alohci I mean not allowed in the sense that they would be discarded from the DOM as opposed to being semantically invalid – Explosion Pills Dec 04 '13 at 14:20
Note that when talking about the HTML spec it is worth being clear *which* spec: there are specs for old versions of HTML, there's HTML 4.0, the rather stricter XHTML 1.0/1.1, the WHATWG's "Living Standard", the W3C's HTML5 "snapshot" (including XHTML5 syntax in place of continuing the XHTML line) and even a draft for HTML5.1. They'll likely word this thing rather differently. – IMSoP Dec 04 '13 at 23:53

Josh Powell · Answer 8 · 2014-01-02T16:05:06.687

13

This is possible with html5 but you need to take into consideration of older browsers.

If you do decide to use them then, make sure to COMMENT your html!! Some people may have some trouble figuring out what it is so a comment could save them a ton of time.

Something like this,

<!-- Custom tags in use, refer to their CSS for aid -->

When you make your own custom tag/elements the older browsers will have no clue what that is just like html5 elements like nav/section.

If you are interested in this concept then I recommend to do it the right way.

Getting started

Custom Elements allow web developers to define new types of HTML elements. The spec is one of several new API primitives landing under the Web Components umbrella, but it's quite possibly the most important. Web Components don't exist without the features unlocked by custom elements:

Define new HTML/DOM elements Create elements that extend from other elements Logically bundle together custom functionality into a single tag Extend the API of existing DOM elements

There is a lot you can do with it and it does make your script beautiful as this article likes to put it. Custom Elements defining new elements in HTML.

So lets recap,

Pros

Very elegant and easy to read.
It is nice to not see so many divs. :p
Allows a unique feel to the code

Cons

Older browser support is a strong thing to consider.
Other developers may have no clue what to do if they don't know about custom tags. (Explain to them or add comments to inform them)
Lastly one thing to take into consideration, but I am unsure, is block and inline elements. By using custom tags you are going to end up writing more css because of the custom tag won't have a default side to it.

The choice is entirely up to you and you should base it on what the project is asking for.

Update 1/2/2014

Here is a very helpful article I found and figured I would share, Custom Elements.

Learn the tech Why Custom Elements? Custom Elements let authors define their own elements. Authors associate JavaScript code with custom tag names, and then use those custom tag names as they would any standard tag.

For example, after registering a special kind of button called super-button, use the super button just like this:

Custom elements are still elements. We can create, use, manipulate, and compose them just as easily as any standard or today.

This seems like a very good library to use but I did notice it didn't pass Window's Build status. This is also in a pre-alpha I believe so I would keep an eye on this while it develops.

edited Jan 02 '14 at 16:05

answered Dec 03 '13 at 14:28

Josh Powell

6,219
5
31
59

3

"`Other developers may have no clue what to do if they don't know about custom tags.`" I hate that argument. Other developers are supposed to learn new stuff too and if they don't understand techniques used in your code, they should be grateful to you for pointing out shortcomings in their knowledge. Maybe that's a bit unfair in this case, because custom tags only exist as a draft, but I've heard the same argument when using proper standardized techniques. – GolezTrol Dec 03 '13 at 15:25
1

I'm not saying I support that but a lot of developers don't continue to learn. There is almost no reason to not comment something if it is a little complex or new. We all comment our scripts correct? To show what we are executing and how, same with custom tags. – Josh Powell Dec 03 '13 at 15:27
1

Of course, if it's just about adding comments. I though you meant that you shouldn't use custom elements at all because other people wouldn't understand. Adding a small comment when you add a lesser used technique is a good thing to do. Be careful with comments in HTML, though. They can end up on the client, consuming bandwidth and possibly revealing implementation details that you don't want your visitors to learn about. But alternatively you may add comments as PHP/ASP comments, so they are still in the template, but remain on the server. – GolezTrol Dec 03 '13 at 15:43
Oh no no I wasn't supporting to not use them, just make sure to use them the correct way. These are very new and for now it may not be the best idea for a major companies website but for a side project or your portfolio more power to the developer. I would add comments into the css if it is possible but the way the OP is using them doesn't work on a external style sheet. Great idea to just leave comments through the back-end to reduce bandwidth usage. – Josh Powell Dec 03 '13 at 15:47
1

@GolezTroi, it's not that you should never do things that challenge other developers, it's a question of cost-benefit. If doing something in a way that is harder for the next developer legitimately makes your code better and cleaner, do it. But don't do gnarly things just for fun. – BostonJohn Dec 03 '13 at 18:29
@BostonJohn very well said. This is why I recommend to comment them so future developers can have an idea of what they are. Developers always should be furthering their education but you should also prepare for this. It saves them time and the company money which is a major consideration. – Josh Powell Dec 03 '13 at 19:19
1

@JoshPowell Comments should not be about the what and how (the code already says that, and if it is not clear enough, rewrite the code until it is), but should tell me *why*. There are few things worse than loads of comments that just say that the `sendmail` function sends mail or something like that. I’d be more interested in why you send mail – and if the function name makes that obvious, great! Then I don’t need a comment, which is the ideal case. I’ll read the code anyway. – Christopher Creutzig Dec 03 '13 at 21:15
@BostonJohn I didn't mean to suggest to do gnarly things just for fun. I mean legitimate applications of techniques that might be harder, or might even be simpler, but just less-known. – GolezTrol Dec 04 '13 at 16:14
@ChristopherCreutzig I don't mean to comment each and every tag for the next developer. What I mean is to simply add one comment, something like this, . This just informs the next developer that custom tags are in use and points them in the right direction. – Josh Powell Dec 04 '13 at 16:18

score 4 · Answer 9 · answered Dec 03 '13 at 14:21

4

Why doesn't he want you to use them? They are not common nor part of the HTML5 standard. Technically, they are not allowed. They are a hack.

I like them myself, though. You may be interested in XHTML5. It allows you to define your own tags and use them as part of the standard.

Also, as others have pointed out, they are invalid and thus not portable.

Why didn't he know that they exist? I don't know, except that they are not common. Possibly he was just not aware that you could.

answered Dec 03 '13 at 14:21

tjons

4,749
5
28
36

2

There is no XHTML5 - there was a working group trying to bring about XHTML 2 but it floundered years ago. – max Dec 03 '13 at 16:21
1

@papirtiger: XHTML5 is HTML5 served like XML, but you're right in that there is no independent XHTML standard beyond XHTML 1.1. – BoltClock Dec 03 '13 at 16:29
1

So there *is* XHTML5, but it seems to differ hardly from HTML5 regarding this subject of custom tags. Therefor I think the statement about XHTML5 allowing you to define additional tags in contrast to HTML5 is wrong, which might explain the downvote, even though I'm not sure enough about XHTML5 to either upvote or downvote this answer. – GolezTrol Dec 03 '13 at 17:50
1

According to the W3C's HTML5 draft, HTML and XHTML are (now) "concrete syntaxes" representing the same "abstract language". They have the same fundamental features, except those that only make sense in one syntax (XML namespaces, HTML noscript parser switch): http://www.w3.org/TR/html5/introduction.html#html-vs-xhtml – IMSoP Dec 04 '13 at 23:47

score 2 · Answer 10 · edited Dec 03 '13 at 16:24

2

I think made-up tags are just potentially more confusing or unclear than p's with IDs (some block of text generally). We all know a p with an ID is a paragraph, but who knows what made-up tags are intended for? At least that's my thought. :) Therefore this is more of a style / clarity issue than one of functionality.

edited Dec 03 '13 at 16:24

TRiG

10,148
7
57
107

answered Dec 03 '13 at 14:21

runelynx

403
2
4
17

Guffa · Answer 11 · 2013-12-03T14:30:11.983

Made-up tags are hardly ever used, because it's unlikely that they will work reliably in every current browser, and every future browser.

A browser has to parse the HTML code into elements that it knows, to made-up tags will be converted into something else to fit in the document object model (DOM). As the web standards doesn't cover how to handle everyting that is outside of the standards, web browsers tend to handle non-standars code in different ways.

Web development is tricky enough with a bunch of different browsers that have their own quirks, without adding another element of uncertainty. The best bet it to stick with things that are actually in the standards, that is what the browser vendors try to follow, so that has the best chance to actually work.

score 2 · Answer 12 · answered Dec 03 '13 at 20:27

Others have made excellent points but its worth noting that if you look at a framework such as AngularJS, there is a very valid case for custom elements and attributes. These convey not only better semantic meaning to the xml, but they also can provide behavior, look and feel for the web page.

Hauke Ingmar Schmidt · Answer 13 · 2013-12-04T10:52:53.577

CSS is a style sheet language that can be used to present XML documents, not only (X)HTML documents. Your snippet with the made-up tags could be part of a legal XML document; it would be one if you enclose it in a single root element. Probably you already have a <html> ...</html> around it? Any current browser can display XML documents.

Of course it is not a very good XML document, it lacks a grammar and an XML declaration. If you use an HTML declaration header instead (and probably a server configuration that sends the correct mime type) it would instead be illegal HTML.

(X)HTML has advantages over plain XML as elements have a semantic meaning that is useful in the context of a web page presentation. Tools can work with this semantics, other developers know the meaning, it is less error prone and better to read.

But in other contexts it is better to use CSS with XML and/or XSLT to do the presentation. This is what you did. As this wasn't your task, you didn't know what you were doing, and HTML/CSS is the better way to go most of the time you should stick to it in your scenario.

You should add an (X)HTML header to your document so tools can give you meaningful error messages.

No, it's not legal (well-formed) XML at all. There is a ` – BoltClock Dec 04 '13 at 05:57 — BoltClock, Dec 04 '13 at 05:57

score 2 · Answer 14 · edited Dec 06 '13 at 08:23

...I simply change all of my made up tags to paragraphs with ID's.

I actually take issue with his suggestion of how to do it properly.

A  tag is for paragraphs. I see people using it all the time instead of a div -- simply for spacing purposes or because it seems gentler. If it's not a paragraph, don't use it.
You don't need or want to stick ID's on everything unless you need to target it specifically (e.g. with Javascript). Use classes or just a straight-up div.

score 2 · Answer 15 · answered Dec 07 '13 at 23:12

From its early days CSS was designed to be markup agnostic so it can be used with any markup language producing tree alike DOM structures (SVG for example). Any tag that comply to name token production is perfectly valid in CSS. So your question is rather about HTML than CSS itself.

Elements with custom tags are supported by HTML5 specification. HTML5 standardize the way how unknown elements must be parsed in the DOM. So HTML5 is the first HTML specification that enables custom elements strictly speaking. You just need to use HTML5 doctype <!DOCTYPE html> in your document.

As of custom tag names themselves...

This document http://www.w3.org/TR/custom-elements/ recommends custom tags you choose to contain at least one '-' (dash) symbol. This way they will not conflict with future HTML elements. Therefore you'd better change your doc to something like this:

<style>
so-cool {
    color:blue;
}
</style>

<body>
    <so-cool>HELLO</so-cool>
</body>

Synetech · Answer 16 · 2020-06-18T14:47:53.270

Surprisingly, nobody (including my past self) mentioned accessibility. Another reason that using valid tags instead of custom ones is for compatibility with the greatest amount of software, including screen-readers and other tools that people need for accessibility purposes. Moreover, accessibility laws like WAI require making accessible websites, which generally means requiring them to use valid markup.

^{Apparently nobody mentioned it, so I will.}

This is a by-product of browser wars.

Back in the 1990’s when the Internet was first starting to go mainstream, competition incrased in the browser market. To stay competitive and draw users, some browsers (most notably Internet Explorer) tried to be helpful and “user-friendly” by attempting to figure out what page designers meant and thus allowed markup that are incorrect (e.g., foobar would correctly render as bold-italics).

This made sense to some degree because if one browser kept complaining about syntax errors while another ate anything you threw at it and spit out a (more-or-less) correct result, then people would naturally flock to the latter.

While many thought the browser wars were over, a new war between browser vendors has reignited in the past few years since Chrome was released, Apple started growing again and pushing Safari, and IE lost its dominance. (You could call it a “cold war” due to the perceived cooperation and support of standards by browser vendors.) Therefore, it is not a surprise that even contemporary browsers which supposedly conform strictly to web standards actually try to be “clever” and allow standard-breaking behavior such as this in order to try to gain an advantage as before.

Unfortunately, this permissive behavior led to a massive (some might even say cancerous) growth of poorly marked up webpages. Because IE was the most lenient and popular browser, and due to Microsoft’s continued flouting of standards, IE became infamous for encouraging and promoting bad design and propagating and perpetuating broken pages.

You may be able to get away with using quirks and exploits like that on some browsers for now, but other than the occasional puzzle or game or something, you should always stick to web standards when creating web pages and sites to ensure they display correctly and avoid them becoming broken (possibly completely ignored) with a browser update.

I'd argue that blaming this particular quirk on IE is a bit off-base, because when a bunch of new tags were officially added (for HTML5), IE was the only major browser which required a specific "shim" to make them stylable. This was partly down to other browsers' more aggressive update regimes (meaning old versions of IE stick around longer than old versions of Chrome of Firefox), but is quite the opposite of IE being "the most lenient". — IMSoP, Dec 16 '13 at 18:01
HTML5? Huh? `` isn’t a new tag in HTML5. This has nothing to do with HTML5 or IE 8, 9, etc. This sort of behavior is not a *new* quirk; it is a by-product of *years-old* browser-wars. Even if IE is not responsible for *current* standard offenses (though to the ire of web developers, they *still* refuse to conform properly), they were certainly notorious for promoting poor coding practices for years. More specifically lenient browsers (IE being the worst offender) came at the worst time, right when the Internet was starting to take off and web devs began learning HTML… incorrectly. — Synetech, Dec 16 '13 at 18:29
I didn't say this had anything to do with HTML5, but it does have to do with non-standard tags (as e.g. `
` was until HTML5 became the standard being targeted) which old versions of IE are most certainly not "tolerant" of. Lenience is also not the same as non-compliance - HTML5 is an extremely pragmatic standard which accepts that badly formed HTML will exist, unlike the idealism of earlier W3C specs, and this "leniency" arguably benefits the democratic growth of the web. — IMSoP, Dec 16 '13 at 23:32
Again, I am not talking about any specific browser or version. I am explaining that lenience *in general* is a side-effect of browser-wars. IE tolerated a lot non-standard and even flat out broken behavior like missing tags, invalid tags and attributes, and mis-matched tags (`foobar`). This is no secret and even a well-criticized and much-maligned issue. Like I said, IE wasn’t the only browser to allow poor markup, but because it had such a large market share and came along at just the right (or wrong) time, it contributed a large amount to poor markup *in general*. — Synetech, Dec 17 '13 at 01:06
(@Google, you might want to remember accessibility and accessibility laws with your horrible new design of YouTube that you're forcing everyone to use with no option to use the old one anymore. It's not just uglier, it's not just slower, it's not just unusable and user-unfriendly, it also uses a *lot* of non-standard custom elements. ) — Synetech, Jun 18 '20 at 14:49

score 1 · Answer 17 · edited Dec 04 '13 at 15:35

1

While browsers will generally relate CSS to HTML tags regardless of whether or not they are valid, you should ABSOLUTELY NOT do this.

There is technically nothing wrong with this from a CSS perspective. However, using made up tags is something you should NEVER do in HTML.

HTML is a markup language, which means that each tag corresponds to a specific type of information.

Your made up tags don't correspond to any type of information. This will create problems from web crawlers, such as Google.

Read more information on the importance of correct markup.

Edit

Divs refer to groups of multiple related elements, meant to be displayed in block form and can be manipulated as such.

Spans refer to elements that are to be styled differenly than the context they are currently in and are meant to be displayed inline, not as a block. An example is if a few words in a sentence needs to be all caps.

Custom tags do not correlate to any standards and thus span/div should be used with class/ID properties instead.

There are very specific exemptions to this, such as Angular JS

edited Dec 04 '13 at 15:35

Ryan B

3,364
21
35

answered Dec 03 '13 at 16:19

Dan Green-Leipciger

3,776
1
19
29

3

"Never" is never the right answer - you seem to have forgotten about XHTML ;) – Izkata Dec 03 '13 at 16:43
divs and spans also don't correspond to any type of information. Google and screen readers seem to handle those well. It's important to use semantic markup, but it is not an argument against using custom tags at all. – GolezTrol Dec 03 '13 at 17:53
2

Divs refer to groups of multiple related elements, meant to be displayed in block form and be manipulated as such. Spans refer to elements that are to be styled similarly and are meant to be displayed inline, not as a block. Custom tags do not correlate to any standards and thus span/div should be used with class/ID properties instead. – Dan Green-Leipciger Dec 03 '13 at 19:28
I removed your bit about screen readers because it is incorrect. Assistive technology will read `some awesome text` fine because it will be interpreted as `<>...>`. What won't happen is they won't be able to jump to that chunk of text independendly like if it was a `
`. Ofcourse if you wrote your own DOCTYPE and mapped `imsocool` to `p`, it would work.
– Ryan B Dec 04 '13 at 15:42

score 0 · Answer 18 · answered Dec 05 '13 at 18:37

Although CSS has a thing called a "tag selector," it doesn't actually know what a tag is. That's left for the document's language to define. CSS was designed to be used not just with HTML, but also with XML, where (assuming you're not using a DTD or other validation scheme) the tags can be just about anything. You could use it with other languages too, though you would need to come up with your own semantics for exactly what things like "tags" and "attributes" correspond to.

Browsers generally apply CSS to unknown tags in HTML, because this is considered better than breaking completely: at least they can display something. But it is very bad practice to use "fake" tags deliberately. One reason for this is that new tags do get defined from time to time, and if one is defined that looks sort of like your fake tag but doesn't quite work the same way, that can cause problems with your site on new browsers.

score 0 · Answer 19 · answered Feb 22 '19 at 00:09

Why does CSS work with fake elements? Because it doesn't hurt anyone because you're not supposed to use them anyways.

Why doesn't my professor want me to use made-up elements? Because if that element is defined by a specification in the future your element will have an unpredictable behavior.

Also, why didn't he know that made-up elements exist and work with CSS. Are they uncommon? Because he, like most other web developers, understand that we shouldn't use things that might break randomly in the future.

Why does CSS work with fake elements?

19 Answers19

FALSE(ish): Non-standard HTML elements are "not allowed", "illegal", or "invalid".

FALSE(ish): Non-standard HTML elements will result in rendering issues

Non-standard tags and JavaScript (via the DOM)

TL;DR: Conforming to the spec is done for purposes of communication and safety. Non-conformance is still allowed by everything but a validator, whose sole purpose is to enforce conformity, but whose use is optional.

CSS

HTML

Edit

Linked

Related