I have observed that some CSS properties, like font-family declared with quotation marks, perhaps are case-sensitive, but all other are not... But how web-browsers and "HTML renderers" MUST interpret? Is the same in any CSS context (XML, SVG, etc.) and all other applications? What the standards say about?
Example: Adobe InDesign exported both, font-family:'Optima Bold' and font-family:'optima bold'. Can I "normalize to lower case" (ex. to merge similar classes)?
NOTES
References are incomplete and in conflict:
sitepoint.com/font-family say "Note that font family names may be case sensitive on some operating systems"... It is valid for XHTML, it is updated with HTML5? font-family is really the unique case-sensitive value?
Is it necessary to use lowercase for every Element and attribute , properties in css and xhtml ? say indirectly "... use lowercase for every properties...", and answers not negate it.
Comparing with this question/answers, the point here, perhaps, can be translated to some (personal) objective considerations:
There are a (objective!) normative (W3C spec of CSS2, CSS3, XHTML1, or HTML5) source for this answer?
"Standard font-family unique names" can not be case-sensitive (otherwise cease to be standard)... So, the only justifiable (by sensible arguments) properties to be case-sensitive are:
2.1. X values at url(X), see background, etc. properties;
2.2. content values, example;
2.3. ... more ?? ...
(updating #ÁlvaroG.Vicario answer and comments, and complementing this answer... This is a Wiki, please edit to enhance)
Example: for CSS3 (and HTML5) there are new explicit rules, as "font-face property must be case-insensitive".[2]
Context
W3C interoperating standards, mainly XML, HTML, CSV and CSS.
CSS general rules
CSS2 (a W3C standard of 2008) fixed basic conventions about "Characters and case", and CSS3 (a W3C standard for 2015) added something more.
By default "all CSS syntax is case-insensitive (...)" [1]
There are exceptions, "(...) except for parts that are not under the control of CSS"[1]
2.1. element names are case-sensitive in HTML5 (?) and XML, but case-insensitive in HTML4.
2.2. identifiers (including element names, classes, and IDs in selectors) are case-sensitive. HTML attributes id and class, of font names, and of URIs lies outside the scope of the CSS specification.
....
The
Case matrix
Exceptions and specific (explicited in a reference) rules. "YES" indicate that value is case-sensitive.
Property values:
CSS property | Case-sens. | Reference and notes
------------------|------------|--------------------
%colorVals | NO | [3]
font-family | NO | [2]
%url | YES | ...
content | YES | ...
----------------------------------------------------
%colorVals = color, background, etc.
%url = background-image, etc. that use `url()`, see [7] and notes.
Selector values:
CSS selector | Case-sens. | Reference and notes
------------------|------------|--------------------
id | YES |...
element | YES/NO | ... YES for XML...
class name | YES | [5]
(`~ i` operator) | NO | [6]
----------------------------------------------------
YES/NO = depends on the document language (see ref. and notes).
REFERENCES:
[1] W3C/CSS2/syndata, sec. 4.1.3 Characters and case.
[2] W3C/CSS3-fonts, sec. 5.1 Case sensitivity of font family names
[3] W3C/CSS3-color, sec. 4.1. Basic color keywords
[4] W3C/CSS3-values, sec. 3.1. Pre-defined Keywords
[5] W3C/Selectors, sec. 3. Case sensitivity
[6] W3C/Selectors4, sec. 6.3. Case-sensitivity
[7] RFC 3986 and URL syntax illustration at Wikipedia.
Quotations and notes
Typical URLs starts with domain, that is case insensitive, but after it (path, query or fragment syntatical components), is case sensitive. See [7].
"User agents must match these names case insensitively". [2]
The spec for CSS 2 says:
CSS syntax is case-insensitive within the ASCII range (i.e., [a-z] and
[A-Z] are equivalent), except for parts that are not under the control
of CSS. For example, the case-sensitivity of values of the HTML
attributes "id" and "class", of font names, and of URIs lies outside
the scope of this specification. Note in particular that element names
are case-insensitive in HTML, but case-sensitive in XML.
... which makes quite sense: CSS itself accepts both background-image and BACKGROUND-IMAGE but it has no way to know whether your web server considers LOGO.PNG and logo.png as identical or different resources.
(I've been unable to find the equivalent document for CSS3)
Related
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!
I was browsing through the source code of a moderately popular repo, and not sure what are the following tags.
see https://github.com/pusher/react-slack-clone/blob/master/src/index.js#L243
<row->
<col->
....
</col->
</row->
why - after the html tags? and how is it an acceptable tag?
They are custom elements. In regards to the tag's validity, you may have noticed that it is not defined anywhere in the code. As per step 5 of the spec, it is valid, and has a namespace of Element.
For a higher-level overview of custom elements, take a look at the MDN tutorial on using custom elements.
An additional note: These tags could be replaced by regular <div> tags with classes, and the functionality would be no different.
This is most likely an error in the source code which has gone unnoticed (possibly by using search & replace?). React accepts element names which end on a - character and it gets rendered to the DOM via document.createElement() as any other element (for a simple example see here: https://jsfiddle.net/nso3gjpw/ ). Since browsers are very forgiving in case of weird html, it just renders the element as an unknown custom element which behaves roughly like a span element. The row- and col- elements are also styled (https://github.com/pusher/react-slack-clone/blob/master/src/index.css#L73).
In the Blink rendering engine source code the following definition for tag names is given (https://www.w3.org/TR/REC-xml/#NT-CombiningChar):
// DOM Level 2 says (letters added):
//
// a) Name start characters must have one of the categories Ll, Lu, Lo, Lt, Nl.
// b) Name characters other than Name-start characters must have one of the categories Mc, Me, Mn, Lm, or Nd.
// c) Characters in the compatibility area (i.e. with character code greater than #xF900 and less than #xFFFE) are not allowed in XML names.
// d) Characters which have a font or compatibility decomposition (i.e. those with a "compatibility formatting tag" in field 5 of the database -- marked by field 5 beginning with a "<") are not allowed.
// e) The following characters are treated as name-start characters rather than name characters, because the property file classifies them as Alphabetic: [#x02BB-#x02C1], #x0559, #x06E5, #x06E6.
// f) Characters #x20DD-#x20E0 are excluded (in accordance with Unicode, section 5.14).
// g) Character #x00B7 is classified as an extender, because the property list so identifies it.
// h) Character #x0387 is added as a name character, because #x00B7 is its canonical equivalent.
// i) Characters ':' and '_' are allowed as name-start characters.
// j) Characters '-' and '.' are allowed as name characters.
//
// It also contains complete tables. If we decide it's better, we could include those instead of the following code.
Especially important here is rule j) Characters '-' and '.' are allowed as name characters.
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.)
I wonder if HTML 4 allows attributes without value, as being equivalent to attributes with an empty value. For example:
<h2 section>foobar</h2>
instead of:<h2 section="">foobar</h2>
Are the two snippets equally valid? If not, are they valid in HTML version 5?
thanks!
Boolean Attributes, Yes they are completely valid.
From W3C: (On SGML & HTML)
Some attributes play the role of boolean variables (e.g., the selected
attribute for the OPTION element). Their appearance in the start tag
of an element implies that the value of the attribute is "true". Their
absence implies a value of "false".
Boolean attributes may legally take a single value: the name of the
attribute itself (e.g., selected="selected").
This states that Boolean attributes are valid in HTML4 as well, but if you use something like, would be invalid.. because that boolean belongs to option tag.. Thanks to #Ronni Skansing for clarifying the doubt..
<p selected>Hello</p>
HTML5 Docs :
From W3C :
Empty Attribute Syntax
Certain attributes may be specified by providing just the attribute
name, with no value.
From W3C: (HTML 5.1 Nightly )
A number of attributes are boolean attributes. The presence of a
boolean attribute on an element represents the true value, and the
absence of the attribute represents the false value.
BUT
section is an invalid attribute, if you want to define your own attributes, HTML5 provides a way to do that.. you need to use data- prefix, for example, your section should be written as data-section, this way your attribute will be counted as valid.
If you hesitate to do so, we always have a validator to check - W3C Markup Validation Service
^ Validated As HTML5
NOTE: Though I provided data- is applicable for HTML5, using custom
attributes in HTML4 is invalid, no matter even if you define data-
before the attribute name, but, boolean attributes are valid in HTML4
as well.
As formally defined, HTML 4 does not allow attributes without a value. What is commonly regarded as attribute without value, as in <input checked>, is formally an attribute value without an attribute name (and an equals sign). Though misleadingly characterized as “boolean attributes” with special minimization rules in HTML 4 specs, those specs normatively cite the SGML standard.
By the SGML standard, whenever an attribute is declared by enumerating keywords that are the only allowed values, an attribute specification may, under certain conditions, be minimized to the value. This means that in HTML 4, the tag <input checkbox> is valid; the attribute is a minimized form of type=checkbox. No browser supports that (they parse checkbox as attribute name), but in validators, the construct passes.
In practice, the part of the attribute minimization rules that browsers support consists of just the special cases where an attribute is declared as allowing a single keyword value only, such as the checked attribute, which is formally declared with
<!ATTLIST INPUT checked (checked) #IMPLIED>
So it depends on how the attribute is declared in the HTML 4 spec.
But this means that the minimized attribute checked means checked=checked. The value is not empty but the keyword checked. On the other hand, browsers treat such attributes as “presence attributes”: what matters is whether an element has that attribute or not, not its value.
In HTML5 serialized as XHTML (i.e., as XML), things are simple: every attribute specification must be of the form name="value" or name='value', so the equals sign is required, and so are the quotation marks; logically, the value is always there, though it can be the empty string, as in alt="".
In HTML5 serialized as HTML, some attributes are defined so that an attribute value (and an equals sign) is not required. Rather confusingly, they are the attributes declared as being “boolean attributes” (it’s confusing e.g. because the values true and false are not allowed, but the name partly reflects the principle that the corresponding DOM property, or “IDL attribute” as they call it, has the truth values true and false as the only permitted values). For such attributes, by definition, the value is even immaterial; only the presence of the attribute matters. For example, for the checked attribute, no value is used, but if a value is given, it must be either the empty string (checked="") or identical with the attribute name, case insensitively (e.g., checked=Checked). Any other value is nonconforming but is required to work, with the same meaning (e.g., checked=false means the same as checked).
Regarding the specific example, it is not valid in any version of HTML, since there is no attribute section declared.
Both snippets are syntactically valid in html4 and html5. The first is not valid xhtml, because in xhtml an attribute value is required.
On the other hand, section is not a defined attibute, but it is a valid tag in html5. Therefore your code is not valid.
I realize that both will work, but is one more correct than the other?
<form method="POST" />
vs.
<form method="post" />
Why use one or the other?
W3C has tended towards lowercase for attribute names and values for a while.
For example section 4.11 of the xhtml 1.0 standard in 2002:
4.11. Attributes with pre-defined value sets
HTML 4 and XHTML both have some
attributes that have pre-defined and
limited sets of values (e.g. the type
attribute of the input element). In
SGML and XML, these are called
enumerated attributes. Under HTML 4,
the interpretation of these values was
case-insensitive, so a value of TEXT
was equivalent to a value of text.
Under XML, the interpretation of these
values is case-sensitive, and in XHTML
1 all of these values are defined in
lower-case.
You can use either of them why because HTML is not case-sensitive markup language.
See HTML 4.01 Specification
The value is case-insensitive (i.e., user agents
interpret "a" and "A" as the same).
Note that XHTML should be lower case.
4.2. Element and attribute names must be in lower case
XHTML documents must use lower case
for all HTML element and attribute
names. This difference is necessary
because XML is case-sensitive e.g.
<li> and <LI> are different tags.
Either way is fine for HTML. There is not specific recommendation.
Possible (case-insensitive) values are
"get" (the default) and "post".
There are arguments for both uppercase and lowercase. One could say that the default for HTML (and mandatory for XHTML) tokens is to write them in lowercase, but saying that the values used in HTTP requests are the uppercase ones is equally valid.
Either is fine. It's not case sensitive. w3schools implies the w3c recommends lower case for HTML: http://www.w3schools.com/html/html_attributes.asp
Here is the w3c XHTML lower-case requirement for attributes: http://www.w3.org/TR/xhtml1/#h-4.2
As with most coding conventions, consistency is key. Pick the casing you are most comfortable with and make sure to use it throughout your code.
From the HTML 4.01 Recommendation:
This attribute specifies which HTTP method will be used to submit the form data set. Possible (case-insensitive) values are "get" (the default) and "post".
XHTML is different, and the attribute values there are case sensitive and must be lower case.
Under HTML 4, the interpretation of these values was case-insensitive, so a value of TEXT was equivalent to a value of text. Under XML, the interpretation of these values is case-sensitive, and in XHTML 1 all of these values are defined in lower-case.
The above is from XHTML 1.0 (Hat tip to #amelvin for spotting something I assumed was another case of an undocumented change).