This works in chromium (and I assume every other major browser)
-html-
<invalid></invalid>
-css-
invalid {
color: red;
}
<invalid> represents an invalid element (not part of the html standard)
here is an example: http://jsfiddle.net/myhonor/4H7Hj/
But when I try this in IE, it doesn't work.
why is this and is there a way fix this (is it a DTD thing?)
That's just the way Internet Explorer works, up to and including version 8. To fix it, just call document.createElement with the name of the invalid element:
document.createElement('invalid');
Here's your updated jsFiddle. It's the same idea as all those HTML5 shivs you see. And, as everyone else has already suggested, writing valid HTML is usually the best solution :)
IE before version 9 doesn't automatically create DOM elements corresponding to any tags it doesn't recognize in the markup. This is the main reason why HTML5 elements don't work in older IEs, which require the HTML5 shiv to be included in order to work.
In this case, you're not even writing HTML5; you're writing your own markup language which is completely unrelated to HTML. The easiest way to fix this is to actually write HTML... or if you insist on making up your own tags, you have to create them manually as minitech demonstrates, but expect to wire them up entirely on your own.1
1 Elements that aren't recognized by a browser as part of HTML are typically created as HTMLUnknownElement objects in the DOM (this includes IE9 and newer), which It is said is done for forward compatibility (c.f. HTML5). These objects have the basic properties of HTMLElement, but besides that there isn't much else to go on...
Related
What's so wrong about using obsoleted or not-yet-implemented HTML tags? Doesn't using them improve the portablity to older browsers? For example, today while validating some HTML docs I got this two messages:
Warning: The language attribute on the script element is obsolete. You
can safely omit it.
Warning: The bdi element is not supported by browsers yet.
I use
<script language="javascript" type="text/javascript">
because in the case a user is using a very outdated browser (e.g. IE 5) that doesn't interpret the attribute type, it still works by interpreting the "obsolete" attribute language.
And
<bdi>
in the case a user is using a sufficiently updated browser which interprets it.
For all I know, if a browser doesn't "know" an attribute/element it just omits it so, is it okay to do this or I'm missing something?
Well, using obsolete tags is okay as long as it is not necessary for the page to work. I would avoid using things like <marquee>, but I see no reason why your script element is wrong. Your bdi tag, however, if possible I would avoid, as not all browsers can use it.
According to the W3C (draft) spec for HTML5, it's ok to use the language attribute on a tag as long as it follows a couple rules, which yours appear to. The spec is calling this "Warnings for obsolete but conforming features". So I wouldn't worry about that one too much.
http://dev.w3.org/html5/spec/Overview.html#warnings-for-obsolete-but-conforming-features
For other obsolete attributes, I've created a little bookmarklet that removes obsolete (in HTML5) attributes from a page so you can visually see what effect would take place if a browser ends up completely not supporting the attribute. Check it out here -> attrebuke
I have tried to find an answer to this in the W3C HTML specifications, but haven't had any luck so far.
For example, if I have the following HTML code:
<body>
<p>
<foo>bar</foo>
</p>
</body>
Does W3C specify how a user agent should handle this? E.g should the "foo" element be completely ignored? Should the "foo" element be ignored but the content "bar" parsed?
Also, is it even "legal" to do this?
Edit: Some excellent answers from all of you! I totally agree that it would be bad practice to embed generic XML unless, possibly, if you have complete control over which browser your users will use. I was mostly curious about what actually would or should happen if such markup were to be produced :-)
The HTML spec doesn't say much about it, other than:
The HTMLUnknownElement interface must be used for HTML elements that are not defined by this specification (or other applicable specifications).
This can be verified in conforming browsers using the following JavaScript code in the console:
Object.prototype.toString.call(document.createElement("foo"));
//-> "[object HTMLUnknownElement]"
However, some browsers either don't follow the specification here yet. For instance, Chrome 13 gives [object HTMLElement], IE 8 gives [object HTMLGenericElement] (IE 9 is correct).
As far as I'm aware, all browsers will parse <foo> as an element, but default styling and behaviour is not guaranteed to be the same. Where HTMLUnknownElement is implemented and the spec is followed, it should inherit directly from HTMLElement and, therefore, have many of the default properties found on other elements.
Please note that your HTML will not validate when you have non-standard elements in your markup. It's also worth mentioning that search engine crawlers, screen readers and other software will not be able to extract semantic meaning from these elements.
Further reading:
Why generic XML on the web is a bad idea and 386: Generic Elements; Still a Bad Idea - Anne van Kesteren's blog (2005, 2010)
Some excellent advice from #Andy E. This is just some add-ons to that.
The HTML5 draft does define how to parse unknown elements, however, it is distinctly non-trivial. To see the rules, see http://dev.w3.org/html5/spec/tree-construction.html
Note that the first version of Firefox to use these rules is FireFox 4, and the first version of IE to use the rules is IE 10. Older versions have a number of different and often very strange behaviours.
HTML has no notion of "legality", only validity or conformance to a standard. You are free to decide whether you want your pages to conform to any particular standard or not. There is no W3C standard of HTML where use of arbitrarily named elements is conforming.
It is generally advisable to make your HTML conforming to avoid unpredictable errors in browsers and other HTML consumers that you haven't tested against.
"bar" should definitely be rendered. For example, in the HTML5 video element, the contents of the element contain fallback content to be displayed in older browsers for exactly this reason. It's also why people traditionally put comments around style declarations:
<style><!--
(styling goes here)
--></style>
to hide the styling information from pre-HTML 4 browsers. (I think the comments aren't considered good practice any more.)
Most browsers support tags such as
<fb:like ... > </fb:like>
(which is a Facebook XFBML tag). Is the namespace:tagname actually part of the standard of naming tags?
Also, how about CSS support? Seldom do I directly style it like
fb:like { font-size: 11px }
but for people who are experienced with it, does it work with most modern browsers? (IE 6 too?) Is there any case where it doesn't work or even crash a browser? Probably some of the mobile browsers are not so well equipped to handle this.
Browser handling for tags of the form namespace:tagname is very different in IE to other browsers and is definitely not standardized. However, it seems that in your particular case styling of the element is quite straightforward. Use:
fb\:like { font-size: 11px }
Tested and working in IE6, IE7, Firefox 3.6 and Chrome 10.
Is the namespace:tagname actually part of the standard of naming tags?
Yes. The namespace:type syntax is defined in the XML 1.0 grammar, and as such is adopted by languages like XHTML and XFBML.
Also, how about CSS support?
The namespace operator for CSS3 selectors is |, defined in this spec.
So as a quick example, one might style it like this:
#namespace fb url(http://www.facebook.com/2008/fbml);
fb|like { font-size: 11px; }
: symbolizes pseudo-class (and pseudo-element in CSS2), which clearly fb:like isn't.
Note that this will not work in IE < 9, which doesn't recognize XML-serialized pages and consequently don't implement namespaces in CSS. If you want better browser support you can treat : as part of the element name and use fb\:like as the selector, as Alohci says.
Most pages don't support fb:like tags... They require either an iframe which loads a supporting page from Facebook that does include the required meta tags, namespace, etc. to understand it...
...or they ask the developer to include these meta tags as well as the necessary xfbml links to make their pages parse this namespace.
Namespaces are good and make sense parsing ML. All HTML is really ML with a namespace. Facebook wants you to include their namespace. However, they understand you might not be so willing to, so ask you to instead include javascript to work around these "namespace" issues and just parse the respective tags. Kudos to Facebook for working around this.
Now you're interested in styling these tags. Most browsers consider unknown namespaces as a "display: inline". You can apply "style attributes" to it, but they wont be recognized. You'll either have to follow Facebook's rules for styling these fb:like tags (i.e. what their javascript is willing to parse as an acceptable attribute - you can find that here). Best thing to do? Either wrap this fb:like with a "div" and style that div for positioning purposes, or work with Facebook's defined attributes for their javascript-parsing ML.
Will browsers support the Facebook namespace in the future? Well, considering how long it took for HTML5 to FINALLY be recognized, probably not. Either Facebook will create their own browser (and who knows, even Google created Chrome in 6 iterations / 2 years, and it rivals if not BEATS IE6 / 7 in terms of penetration rates if not all sorts of other reasons).
Or Facebook may be considered a perfectly worthy namespace in future browsers... Doubtful but hey, consider FB / TW are icons used EVERYWHERE (including Starcraft 2!). So ya know... there's hope.
In the meantime, work within their system.
While this is an old post, I think it is worth noting that the <namespace:tagname> pattern is something Facebook uses in their XHP extension. XHP is Facebooks own PHP extension, which make PHP able to interpret XML nodes as PHP objects, essentially transforming XML nodes to simple HTML nodes.
Our own <fb:like> tags are probably still handled by javascript, but I'm guessing XHP is being used somewhere on their end of the API.
Tags like exist only within XFBML framework (i.e. you need to include Facebook JavaScript libraries to make them work)
There is no CSS support the way you are asking.
fb:like { font-size: 11px }
The CSS code above won't work. But you can assign CSS class to this tag the standard way.
The web application im working on has a few custom attributes on HTML elements to store data that is output.
Only happens here and there and so far I haven't noticed anything wrong in how the page is rendered on IE7, IE8, FF 3.5 and Chrome 3.
I'd like to assume everything will be ok but just wanted to check if anyone else has had problems with custom attributes in other browsers.
I understand its not part of standards to add custom attributes but all that matters to me is how the page is output to customers.
html5 supports custom attributes with names starting with "data-". Using those yields the smallest chance that anything breaks in the future.
Browsers silently ignore tags or tag attributes they do not understand, so you're good. That said, your HTML won't validate (I know you said you don't care, but still) plus there are other possible ramifications.
See this question for more details.
Just be sure to use the same case when referencing the attribute in code. I've had issues in the past with Internet Explorer returning null with getAttribute because my case didn't match what was defined in markup or previously in code.
Do you know of any differences in handling HTML tags/properties in different browsers? For example, I once saw a page with a input tag with a maxlength field set to "2o". Firefox and Opera ignore the "o", and set the max length to 2, while Internet Explorer ignores the field altogether. Do you know of any more?
(Note: seeing as this will probably be a list, it would be great if the general name of the difference was in bold text, like: Different erratic value handling in tag properties)
Bug Lists
Web developers have already compiled some pretty comprehensive lists; I think it's better to compile a list of resources than to duplicate those lists.
http://www.positioniseverything.net/
http://www.richinstyle.com/bugs/table.html
http://www.quirksmode.org/ (as mentioned by Kristopher Johnson)
Javascript
I agree with Craig - it's best to program Javascript using a library that handles differences between browsers (as well as simplify things like namespacing, AJAX event handling, and context). Here's the jump to Craig's answer (on this page).
CSS Resets
CSS Resets can really simplify web development. They override settings which vary slightly between browsers to give you a more common starting point. I like Yahoo's YUI Reset CSS.
Check out http://www.quirksmode.org/
If you are programming in javascript the best advice I can give is to use a javascript library instead of trying to roll your own. The libraries are well tested, and the corner cases are more likely to have been encountered.
Scriptalicious - http://script.aculo.us/
jQuery - http://jquery.com/
Microsoft AJAX - http://www.asp.net/ajax/
Dojo - http://dojotoolkit.org/
Prototype - http://www.prototypejs.org/
YUI - http://developer.yahoo.com/yui/
Do you know of any differences in handling HTML tags/properties in different browsers
Is this question asking for information on all differences, including DOM and CSS? Bit of a big topic. I thought the OP was asking about HTML behaviour specifically, not all this other stuff...
The one that really annoys me is IE's broken document.getElementById javascript function - in most browsers this will give you something that has the id you specify, IE is happy to give you something that has the value in the name attribute, even if there is something later in the document with the id you asked for.
I once saw a page with a input tag
with a maxlength field set to "2o".
In this specific case, you're talking about invalid code. The maxlength attribute can't contain letters, only numbers.
What browsers do with invalid code varies a great deal, as you can see for yourself.
If you're really asking "what do all the different browsers do when faced with HTML code that, for any one of an infinite number of reasons, is broken?", that way lies madness.
We can reduce the problem space a great deal by using valid code.
So, use valid HTML. Then you are left with two main problem areas:
browser bugs -- how the browser follows the HTML standard and what it does wrong
differences in browser defaults, like the amount of padding/margin it gives to the body
Inconsistent parsing of XHTML in HTML mode
HTML parsers are not designed to handle XML.
If an XHTML document is served as "text/html“ and the compatibilities guidelines are not followed you can get unexpected results.
Empty tags is one possible source of problems. <tag/> and <tag></tag> are equivalent in XML. However the HTML parser can interpret them in two ways.
For instance Opera and IE treat <br></br> as two <br> but Firefox and WebKit treat <br></br> as one <br>.