Simon Pieters created a page listing all elements and attributes from HTML5 based on input from Matt McDonald on the WHATWG mailing list. The list will be maintained. Simon uses my blog to blog (sort of) and Matt works on the HTMLInputStream class in the Python html5lib project. (Web Forms 2 elements and attributes are not yet covered. Same for event handlers.)
When was depreciation of the div discussed by WHAT WG?
The link of t element is broken. Does the t element exists?
When was depreciation of the
divdiscussed by WHAT WG?
I asked the same question yesterday, and the answer I received was that <div> will be added to the spec in due course.
Actually, the div element is there now. The word is deprecated by the way, not depreciated.
See also this html5-elements directory for a way to generate such an index yourself.
depreciate: to represent as of little value and especially as of less value than usually assigned. [Merriam-Webster]
deprecate: to express disapproval of. [Merriam-Webster]
Which of those two is closer to what's actually happening? The latter, methinks. Depreciation is a lowering of value, while deprecation is pleading against. font is not lessened in value; rather, its use is discouraged.
To SirPavlova: «Pleading against» is exactly what the specifications do, in my opinion. Depreciation is what you experience if you use markup elements for which deprecatedness has been declared... And until recently, one could experience the same depreciation if one had not switched from HTML to XHTML...
Markup-people insist on «specified» interpretation of «deprecate». In native English, however, DEPRECATE has almost totally replaced DEPRECIATE
. Markup-people forreign to English might easily do the opposite: We recognize «depreciate» as antonym of «appreciate», while «deprecate» doesn't ring any bell.
Lief: Good points. I originally posted just to point out that the definition Sean posted didn't actually apply as well as he thought. I realise deprecate has pretty much taken over depreciate — depreciate has been relegated to finances, though it sometimes sees use in other explicitly quantifiable contexts (I think I remember it being used in a physics class once).
That depreciation follows from deprecation is basically the point of deprecation, but even then it's a side effect. Observe that many people depreciate font, which is deprecated, but almost as many also depreciate i, which isn't. It's necessary to use the correct term so as to differentiate the two... of course, technically the people depreciating both are also deprecating them, but this did begin as a discussion of what the standard-writers are doing. What happens afterwards is out of their control. Case in point: HTML is not deprecated, but as you pointed out, it was certainly both deprecated & depreciated by large portions of the web dev. community.
Non-fluent English speakers are in a bad position; this applies to native speakers & non-native alike. However, learning the difference between "deprecate" & "depreciate" isn't an arduous task, nor an isolated one (I think? I find this sort of thing particularly easy anyhow).
My apologies.
Are there any deprecated elements in HTML5, btw? How are they treated - in the spec and by user agents following the HTML5 spec? (E.g. what if I use font elements in HTML5 docs?) And are they still referred to as «deprecrated» or has anyone considered a less ambiguous and more mind opening terminolgoy?
«Deprecrate» probably felt just right for the spec writers and it is necessary to learn appreciating the difference from «depreciate» – but we could leave that task to native English speakers. Because, there can be little doubt that the choice of word has added to the confusion and «depreciation» of HTML and everything.
Let's switch terminology! Bring in some symmetry with DOCTYPE Transitional and rebaptize «deprecated» into «transitional»! So we could get «transitional elements» instead of «deprecated elements». Then the markup community would be able to discuss and grasp these matters much better! We need neutral a word/term without a history of «semantics» that govern its interpretation. Anyone from the HTML5 task force agreeing with me?
PS: A spelling tip (for Englishmen of both sexes and of all nations).
Are there any deprecated elements in HTML5, btw? How are they treated - in the spec and by user agents following the HTML5 spec? (E.g. what if I use
fontelements in HTML5 docs?)
There are currently no deprecated elements in HTML5. There are a couple of obsolete elements that get special treatment in the parsing algorithm but that are still non-conforming.
User agents that also support older versions of HTML aren’t expected to disable support for any obsolete elements when a document has the HTML5 doctype. Hence, font will work as before in user agents that support it. However, it will be non-conforming if it isn’t reintroduced by the spec. (It might get reintroduced as an element that WYSIWYG editors may generate.)
Ooh, dear... my apologies as well, Leif! And also to you, Sean — I may have come across as ruder than I intended (which was not at all).
Calling elements "transitional" rather than "deprecated" sounds as though they were introduced for the purpose of easing a switch. "Transitional" fits the DTD, because that's what it's for; it doesn't fit the elements within. Why not go with "discouraged," if you're going to change? It's a weaker term than "deprecated," but has no associated confusion & has roughly the same meaning.
Henri: Is there much chance that font & so on will get reintroduced, just out of interest?
SirPavlova: I did not believe your comment was at all rude.
I was curious as to when The WHATWG - Originally - discussed div having little value and especially as of less value than usually assigned before they expressed disapproval of it use.
It no longer matters. 3.19. Miscellaneous elements 3.19.2. The div element now allows them.
Henri: Is there much chance that
font& so on will get reintroduced, just out of interest?
I believe it will be considered in due course. I’d rather not speculate on how much chance there is for the decision to go either way.
The argument for font is that editors that use a “WYSIWYG”-style UI will generate <font …> or <span style='…'> anyway, so font might as well be allowed, because span is meaningless in principle and font has older compatibility roots. The argument against is that in principle the spec should guide people to use semantic elements and having two sets of rules (Transitional vs. Strict or Generators vs. Manual) is a compromise that leads to a fluffy spec tries to say one thing while really condoning another, so allowing font without double-standards would mean allowing it for everyone, which might horrify the semanticists. But in any case, requiring browsers to unsupport font won’t work, so pretending that font does not exist is a bit pointless.
I was curious as to when The WHATWG - Originally - discussed
divhaving little value and especially as of less value than usually assigned before they expressed disapproval of it use.
What kind of expression of disapproval do you mean? The editor of the spec is known not to be a big fan of div, but I cannot recall seeing serious suggestions that the div had been designated for removal at any point.
What kind of expression of disapproval do you mean?
I could not recall nor could I find any serious expression on the mailing list for its removal. That was my reason for posting my question.
Ian Hickson's position on the use of div is well known. The specification has categorized it as a Miscellaneous element with the accompaning commentary:
The
divelement represents nothing at all.