Today I discovered this by accident:
<hr width=100% color=red />
creates a red horizontal rule, but
<hr width=100% color=red/>
creates a green horizontal rule.
This isn't just with the color red, if there is a / directly behind the color name, another color will be drawn. This doesn't work for color codes like #000000 (to #000000/).
Just of curiosity, here is my question: How does the color get chosen? Is this a bug or intended?
Additional info:
Browser: Google Chrome 29.0.1547.66 m
Installed plugins / add ons: Ad Block Plus
I tested this with IE 10 and it has the same problem as Chrome.
This is, somewhat surprisingly, intentional error handling, described in clause 2.4.6 Colors of HTML5 CR. It is presumably meant to maintain compatibility with legacy content that has weirdly broken color designators that have been traditionally processed in a certain manner by browsers.
When the mixed-syntax (partly HTML, partly XHTML) markup <hr width=100% color=red/> is used, in a document served as text/html (when served with an XHTML content type, it would simply cause nothing but an error message to be shown), the color attribute will be parsed as red/ (with the slash as part of the value). Since this does not match any color name, rules for parsing a legacy color value will be applied.
This means that any character that is not a hexadecimal digit is replaced by the digit 0, and if the resulting value is not six characters long, trailing zeroes will be added. Finally, the value is prefixed with #, so it will be interpreted as a hexadecimal color designator. Thus, red/ yields #0ed000, which is the light green color that you see.
Similarly, <hr width=100% color=blue/> would cause the color #b00e00 to be used.
The problem can of course be avoided by using either HTML syntax (which has no / before >) or XHTML syntax (which has quotation marks around each attribute value).
The semantic analizer of your browser detect the <hr> tag and later try to determinate the atributes for that label.
Using white spaces as token separator, your first line have 3 attributes (noted that the correct slash for finish a tag in html is / ). In this case, the second token color=red as interpreted as a attribute (color) and value (red). In your second line there are only 2 attributes. The second attribute (color) has the value red\ that is not a valid identifier in the asociative array for colors.
Why your browser return blue?
Each browser manage the exceptions that diferents ways, its problably that your browser return the first value in the asociative array colors.
I should recommend to you that use quotes as delimiter for attributes values.
I just tried it,and it works.
First I copy your code and execute, it was unexpected. Still I try same code, and I just put " " (double quotes) around the color name, and tried color codes too.
and I found, it is working properly with Crome,IE and Mozilla.
using the color attribute might be the problem. Try border-color.
<hr width="100%" style="border-color:#f00">
Related
So recently I found a question that was
Which of the following is a valid tag?
<213person>
<_person> (This is given as the right answer)
Both
None
(Note: this is the explanation that was given:- Valid HTML tags are surrounded by the angle brackets and the tag name can only either start from an alphabet or an underscore(_))
As far as my knowledge goes none of the reserved tags start with an underscore and according to what I've read about custom HTML tags it has to start with an alphabet(I tested it and it doesn't work with a custom tag starting with any character that's not an alphabet). So in my opinion and according to what I tested HTML tags can only start with alphabets or! (in case of !-- -- and !DOCTYPE HTML)
What I want to know is if the given explanation is correct or not and if it's correct then can someone provide some proper documentation and working examples for it?
As mentioned by #Rob, the standard defines a valid tag name as string containing alphanumeric ASCII characters, being:
0-9|a-z|A-Z
However, browsers handle things differently.
There's a few main points that I've noticed which don't align with the current standard.
Tag names must start with a letter
If a tag name starts with any character outside a-z|A-Z, the start tag ends up being interpreted as text and the end tag gets converted into a comment.
Special characters can be used
The following HTML is valid in a lot of browsers and will create an element:
<Z[\]^_`a></Z[\]^_`a>
This seems to be browsers only checking if the characters are ASCII. The only exception is the first character (as stated above).
Initially, I thought this was a simplified check, so instead of [A-Z]|[a-z| they checked [A-z], but you can use any character outside this range.
This makes the following HTML also "valid" in the eyes of certain browsers:
<a!></a!>
<aʬ></aʬ>
<a͢͢͢></a͢͢͢>
<a͢͢͢ʬ͢ʬ͢ʬ͢ʬ͢ʬ͢ʬ͢ΘΘΘΘ></a͢͢͢ʬ͢ʬ͢ʬ͢ʬ͢ʬ͢ʬ͢ΘΘΘΘ>
<a></a>
I tested the HTML elements in both Chrome and Firefox, I didn't test any other browsers. I also didn't test every ASCII character, just some very high and low in terms of their character code.
From the HTML standard:
Start tags must have the following format:
The first character of a start tag must be a U+003C LESS-THAN SIGN
character (<). The next few characters of a start tag must be the
element's tag name.
So what is allowed in the element's tag name? This is defined just above:
Tags contain a tag name, giving the element's name. HTML elements all
have names that only use ASCII alphanumerics. In the HTML syntax, tag
names, even those for foreign elements, may be written with any mix of
lower- and uppercase letters that, when converted to all-lowercase,
matches the element's tag name; tag names are case-insensitive.
I was wondering if you can use a random letter as an html tag. Like, f isn't a tag, but I tried it in some code and it worked just like a span tag. Sorry if this is a bad question, I've just been curious about it for a while, and I couldn't find anything online.
I was wondering if you can use a random letter as an html tag.
Yes and no.
"Yes" - in that it works, but it isn't correct: when you have something like <z> it only works because the web (HTML+CSS+JS) has a degree of forwards compatibility built-in: browsers will render HTML elements that they don't recognize basically the same as a <span> (i.e. an inline element that doesn't do anything other than reify a range of the document's text).
However, to use HTML5 Custom Elements correctly you need to conform to the Custom Elements specification which states:
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.
So if you use <my-z> then you'll be fine.
The HTML Living Standard document, as of 2021-12-04, indeed makes an explicit reference to forward-compatibility in its list of requirements for custom element names:
https://html.spec.whatwg.org/#valid-custom-element-name
They start with an ASCII lower alpha, ensuring that the HTML parser will treat them as tags instead of as text.
They do not contain any ASCII upper alphas, ensuring that the user agent can always treat HTML elements ASCII-case-insensitively.
They contain a hyphen, used for namespacing and to ensure forward compatibility (since no elements will be added to HTML, SVG, or MathML with hyphen-containing local names in the future).
They can always be created with createElement() and createElementNS(), which have restrictions that go beyond the parser's.
Apart from these restrictions, a large variety of names is allowed, to give maximum flexibility for use cases like <math-α> or <emotion-😍>.
So, by example:
<a>, <q>, <b>, <i>, <u>, <p>, <s>
No: these single-letter elements are already used by HTML.
<z>
No: element names that don't contain a hyphen - cannot be custom elements and will be interpreted by present-day browsers as invalid/unrecognized markup that they will nevertheless (largely) treat the same as a <span> element.
<a:z>
No: using a colon to use an XML element namespace is not a thing in HTML5 unless you're using XHTML5.
<-z>
No - the element name must start with a lowercase ASCII character from a to z, so - is not allowed.
<a-z>
Yes - this is fine.
<a-> and <a-->
Unsure - these two names are curious:
The HTML spec says the name must match the grammar rule [a-z] (PCENChar)* '-' (PCENChar)*.
The * denotes "zero-or-more" which is odd, because that implies the hyphen doesn't need to be followed by another character.
PCENChar represents a huge range of visible characters permitted in element names, curiously this includes -, so by that rule <a--> should be valid.
But note that -- is a reserved character sequence in the greater SGML-family (including HTML and XML) which may cause weirdness. YMMV!
Today i read:
Don’t use single quotation marks around paths for images. When setting
a background image, resist the urge to surround the path with quote
marks. They’re not necessary, and IE5/Mac will choke.
Meaning instead of:
<img src="pic_mountain.jpg" title="Mountain-View" style="width:304px;height:228px;">
this:
<img src=pic_mountain.jpg title=Mountain-View style=width:304px;height:228px;>
should be perfectly fine. Is this true? No diffrences? It does work normally on my end. Is it about cross-browser compatibility?
Source for the info: Source
The quote is talking about CSS, not HTML.
These all mean the same in CSS:
background-image: url(/path/to/foo);
background-image: url("/path/to/foo");
background-image: url('/path/to/foo');
… except only the first one works in IE5/Mac … which hasn't been supported for a very long time, so isn't worth worrying about.
The two versions of HTML in your question are (for reasons unrelated to the quote you included) also equivalent.
The common view about best practise is that you should always place quotes around HTML attribute values. It saves having to remember which characters that you might want to place in an attribute value turn the quote from optional into required. Space is an obvious example of such a character.
It is valid html but if you then use an attribute that is not valid for an element it will then through an error this link should help.
unquoted attributes
Consider the following HTML fragment with two style attributes:
<span style="color:blue" style="font-style:italic">Test</span>
In Opera 12.16 and Chrome 40, it shows up as blue non-italic text, while Internet Explorer 9 shows blue italic text. What, if anything, does the standard say is supposed to show up?
Separate your rules with a semi colon in a single declaration:
<span style="color:blue;font-style:italic">Test</span>
In HTML, SGML and XML, (1) attributes cannot be repeated, and should only be defined in an element once.
So your example:
<span style="color:blue" style="font-style:italic">Test</span>
is non-conformant to the HTML standard, and will result in undefined behaviour, which explains why different browsers are rendering it differently.
Since there is no defined way to interpret this, browsers can interpret it however they want and merge them, or ignore them as they wish.
(1): Every article I can find states that attributes are "key/value" pairs or "attribute-value" pairs, heavily implying the keys must be unique. The best source I can find states:
Attribute names (id and status in this example) are subject to the same restrictions as other names in XML; they need not be unique across the whole DTD, however, but only within the list of attributes for a given element. (Emphasis mine.)
While editing some old ColdFusion code I found a <td> which has a bgcolor property. The value of it was ##89969E. I copied the code to a HTML file and found out the color was different in ColdFusion.
Now, i noticed the double #, so i removed one and the color was the same. Why does the color change when adding/removing a #?
jsFiddle
As a basic premise, additional hashes are interpreted as a missing/erroneous value and so replaced with a zero, so ##89969E becomes #0089969E. Note that HEX codes can be as long as 8 digits following a hash (if aRGB), where the last two refer to transparency
Missing digits are treated as 0[...]. An incorrect digit is simply
interpreted as 0. For example the values #F0F0F0, F0F0F0, F0F0F, #FxFxFx and FxFxFx are all the same.
When color strings longer than 8 characters or shorter than 4
characters are used, things start to get strange.
However there are a lot of nuances - you can find out more about this here, and for some fairly entertaining results this creates, have a little read here