I was looking at some code on a website and I saw the following code for a link:
Link Text
What is _mce_href?
Is there a purpose for it?
That's not a valid HTML attribute, it was kind of bug in older versions of Tiny MCE editor, though, using data- prefix before that attribute can make that custom attribute valid as of HTML5.
Some Reference
This attribute was used in tiny mce. Most of the time developers creates its own attribute(s) to process the tags or data in user define attributes, you can also see in the jquery plugins at run time it add styling or add attributes, you can also create your own attributes, its not a big deal. Well Its not a valid HTML attribute.
Related
I've recently found on one of the sites opening tag like this:
<script data-ip="93.1xx.3.2x" data-backuri="something.com">
And I couldn't find any information about it. What are those tags used for?
data-* attributes are custom HTML attributes.
Basically, there are standard HTML attributes like style, src, width, height, class... and these have a special meaning to browsers and are 'reserved'.
However, custom attributes have no special meaning generally and are only special to the owner's application. They can be used to simplify an application's logic.
Using data- before your attribute name ensures that future standard attributes will not use your current attribute. For example, imagine today you are using a sound attribute but then the HTML standard adds a sound attribute meaning something other than what you meant. Had you used data-sound, you would have been fine because there would be no conflict. The specification says no future standard browser attributes will start with data-.
See jquery get HTML 5 Data Attributes with hyphens and Case Sensitivity for some useful info on why we use data-* attributes.
Also, see MDN docs for some useful information.
The HTML5 spec define how to set custom attributes using data-* prefix,
like:
<div data-attr="somedata"></div>
But what would be the difference if we write just:
<div attr="somedata"></div>
And I actually prefer the second way since it's shorter.
I can access both attributes using the getAttribute() method.
So is that wrong not using data-* prefix? I tested it only on chrome and IE11, so maybe there are other browsers to worry about?
HTML5 defines the data-* attributes as valid, while other custom attributes are not. So what?
If you run your code through an HTML validator it will look for invalid attributes. Among other things, they could indicate a typo. An HTML5 validator will accept data-* attributes but it isn’t psychic. It has no way of judging which other new attributes are part of the plan.
If you create a new attribute, it may not play nicely with future changes in HTML which may coincidentally use the same attribute name for a different purpose. The data-* attributes are exempt from future implementation.
A corollary of the above is that including additional libraries which also make arbitrary changes may interfere with your own code.
JavaScript cooperates with the data-* attributes by automatically collecting them in a dataset property for each element. If you make up another attribute it won’t be included.
If none of the above points are important to you, then, by all means, use whatever attribute names you like. As regards the last point above, you can always access your own arbitrary attributes using JavaScript’s *Attribute functions which will work just well on any attribute, regardless of its validity.
Speaking of JavaScript, there is no concept of HTML validity for JavaScript, and you can use JavaScript to assign any attribute names you like without fear of the HTML validator police knocking at your door. However, you still run the risk of competing with additional libraries or future implementations.
According to many recent HTML specs, when we are using custom attributes (meaning any attributes not defined in the spec), we should prefix them with data-. However, I see no reason to have to do this (unless you require perfectly valid HTML, obviously). Pretty much all current browsers correctly ignore custom attributes, meaning no conflicts except with identically-named attributes from others' code, and we can ignore even this with custom prefixes or something similar (as suggested on the AngularJS directive page). What, if any, other benefits are there? This question has been asked before, at least twice, but both are pretty old.
I forget where I read it, but some guide said custom HTML tags need dashes, and single-word tags aren't valid. First of all, why? Second, should we do this, and why (besides being valid)? Would there be any problem with underscores or camelCase, etc.? Also, conflicts with existing elements shouldn't be a problem, if, like with data attributes, you prefix or suffix them, etc. See the Angular directive page again.
I'm sure all these questions have been asked before, but I'm combining them into one. Is that a good idea (quick, someone ask on Meta)?
The data-* attributes have two advantages:
It is a convention meaning other programmers will understand quickly that it is a custom attribute.
You get a DOM Javascript API for free: HTMLElement.dataset. If you use jQuery, it leverages this to populates the keys and values you find with .data().
The reason for the - in custom element names is for two basic reasons:
It is a quick way for the HTML parser to know it is a custom element instead of a standard element.
You don't run into the issue of a new standard element being added with the same name which would cause conflict if you register a custom Javascript prototype for the DOM element.
Should you use your own custom element name? Right now it is so new that don't expect it to be fully supported. Let's say it does work. You have to balance the issue of the extra complexity with the benefit. If you can get away with a classname, then use a classname. But if you need a whole new element with a custom Javascript DOM prototype for the element, then you may have a valid usage of it.
I am seeing some attribute I have never seen before in a div tag. I haven't touch html for a while but googling the attribute didn't return much useful info.
<div dataquery="#item_1306" comp="box.components.Flashplayer" id="box_Flashplayer_2" propertyquery="#box_Flashplaye_2" class="box_Flashplaye_style2"...
My question is, do you know what are these "dataquery" "comp" and "propertyquery" attributes?
Thanks alot folks.
HTML is often enhanced with custom attributes these days, and HTML5 explicitly allows for that. Normally these attributes should be prefixed with "data-", but obviously this is not the case here.
The meaning depends most probably on a script included in the page.
For example, in twitter bootstrap it is common to see attributes like <body data-spy='scroll'> which is than interpreted by a script and allows for monitoring the amount a user scrolls.
When including Facebook like buttons you may have attributes like data-style which controls whether a box, or a button, or hwatever is used.
You can add you own attributes to elements. I don't think theese atributes are standard attributes lika class and name but an attribute that the programmer has added self for some purpose.
Those are not W3C attributes, they have used to perform some task, may be to the lagulage it used and may performance some special tags, But its not best practice because it gives HTML validation errors, better thing is use data-xxxx tag for extra attributes.
More readings.
http://www.javascriptkit.com/dhtmltutors/customattributes.shtml
http://ejohn.org/blog/html-5-data-attributes/
http://html5doctor.com/html5-custom-data-attributes/
This subject turned into a heated discussion at the office, so I'm interested to learn what you think.
We are working on a web app that only targets some specific browsers. These browsers presently include different flavors Opera 9 and Mozilla 1.7.12. In the future we likely also have to support Opera 10 and different flavors of WebKit. But it's very unlikely we are ever going to have to deal with any version of IE.
Our web app declares HTML 4.0 strict in it's doctype.
Recently, I proposed as a solution to a specific problem to use custom attributes in the HTML. I proposed something that would look like this:
<span translationkey="someKey">...</span>
Since this is not valid HTML 4, it did not go down well with our HTML guys, and we got into an argument.
My question is this: What - if any - are the risks of using custom attributes? I know the page won't validate, but don't all browsers just ignore attributes they do not know? Or is it conceivable that some browsers will change to "quirks mode" and render the page as if it was something other than strict HTML 4.0?
Update:
Hilited the actual question posed.
There are no browser limitations/risks. Only the w3 validator will bark, but barking dogs doesn't bite.
The w3 spec says the following:
If a user agent encounters an attribute it does not recognize, it
should ignore the entire attribute
specification (i.e., the attribute and
its value).
IE will also not render in quirks mode or so as some may think. It will only do that on invalid/forced doctypes, not on invalid attributes.
However, keep in mind that some Javascript libraries/frameworks will "invisibly" add/use custom HTML attributes in the DOM tree, such as several jQuery plugins do. This way you may risk collisions in attributes because it "by a coincidence" uses an attribute with the same name as you do for your own purposes. Sadly this is often poorly or even not documented at all.
HTML 5 allows custom attributes using a 'data-' prefix, see http://ejohn.org/blog/html-5-data-attributes/
If its a goal to maintain valid html4.0 strict, then it doesn't matter why you want to put in custom attributes, you are breaking the goal.
I think the question you need to be asking, is why do you need to break 4.0 strict to get the functionality you want: Anything that you could use a custom attribute for you, you could use a in an existing attribute:
<span translationkey="someKey">...</span>
could be:
<span class="Translationkey#someKey">...</span>
it will be some extra cycles to parse all the class information, but so long as you don't put any css info on that class, it doesn't change display, doesn't put you in quirks mode, and doesn't get you in fights at work.
Duplicate try this thread though: Is it alright to add custom Html attributes?
Also look at this: Non-Standard Attributes on HTML Tags. Good Thing? Bad Thing? Your Thoughts?
Or is it conceivable that some browsers will change to "quirks mode" and render the page as if it was something other than strict HTML 4.0?
No, bad attributes will not force a rendering mode change.
If you don't care about validation do what you like, but validation is a useful tool for detecting simple mistakes that can otherwise have you chasing around debugging. Given that there are many other perfectly good alternatives for passing data to JavaScript I prefer to use one of those, rather than forgo validation.
Plus, when you add an arbitrary attribute you are effectively playing in a global namespace. There's no guarantee that some future browser or standard won't decide to use the name ‘translationkey’ for some new feature that'll trip your script up. So if you must add attributes, give them a name that's obscure and likely to be unique, or just use the HTML5 data- prefix already.
If the page is declared to be HTML 4 strict, then it should not add attributes that are not used in that HTML specifies. Differently, it is not clear what the browsers would behave.
As already reported, a way to add additional attributes is to add them as classes, even if that has some limitations.
(Copying my answer from a duplicate question)
Answers which say custom attributes won't validate are incorrect.
Custom attributes will validate.
Custom tags will validate too, as long as the custom tags are lowercase and hyphenated.
Try this in any validator. It will validate.
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Custom Test</title>
</head>
<body>
<dog-cat PIANO="yellow">test</dog-cat>
</body>
</html>
Some validators:
https://appdevtools.com/html-validator
https://www.freeformatter.com/html-validator.html
https://validator.w3.org/nu/
But is it safe? Will it break later?
Custom Tags
No hyphenated tags exist. For that reason, I believe that W3C will never add a hyphenated tag. It's very likely a custom hyphenated tag will never see a conflict. If you use a weird prefix in your custom tags, even less likely. Eg.<johny-Calendar>.
Custom Attributes
There are hyphenated HTML attributes. But the HTML spec promises never to use an attribute starting with data-. So data-myattrib is guaranteed to be safe.
I believe that W3C will never introduce any attribute that starts with johny- or piano-. As long as your prefix is weird, you'll never see a conflict.
It's worth considering that the first version of HTML was written in 1993. Now, thirty years later, all browsers still support custom tags and attributes, and validators validate them.
<jw-post jw-author="Johny Why" jw-date="12/2/2022">