Html5: Non-Replaced VS. Replaced Element

what is a non-replaced inline element?

For most practical purposes, it is best to read “replaced” as “embedding”. So “non-replaced element” is just an element that is rendered as such, instead of causing some external content to appear in its place.

The expression “non-replaced inline element” has no definition of its own: it simply refers to any element that is both a non−replaced element and an inline element. Such as <a>. Most elements in HTML are non-replaced. A non-replaced element is simply an element that is not a replaced element.

However, in CSS specifications, there are just general characterizations the concept “replaced element”, not any definitive list of such elements. This is understandable, since HTML evolves rather independently of CSS.

The concept has somewhat changed over time. The CSS 1 spec said: “In HTML, IMG, INPUT, TEXTAREA, SELECT, and OBJECT elements can be examples of replaced elements.” In newer specs, form fields are not included any more. This is reflected in the HTML5 draft, where the Rendering section explicitly lists form controls under Non-replaced elements. The only replaced elements, according to it, are those that embed external content, such as an image, video, applet, or HTML5 canvas into an HTML document – except that the revamped menu element is mentioned too (it is expected to be implement in a manner that echoes browser controls, so it sort-of embeds external content too).

This change reflects browser development. Early browsers implemented form fields using system routines in a manner that was immune to anything in CSS, and there are still some remains of such approaches, but nowadays form fields can mostly be formatted with CSS, so they have effectively changed from replaced to non-replaced elements.

What Are Non-Replaced Inline Blocks ?

The terms inline block and inline-block refer to the same thing (an inline-level, block container box) and are completely interchangeable. An element with display: inline-block does, indeed, generate an inline-block box, or an inline block box (with or without the hyphen). The hyphen is only there so CSS is able to define inline-block as a single keyword value.

The non-hyphenated form appears several times throughout section 9 of CSS2, but doesn't appear anywhere else in that spec (it appears once in css-display-3, in a sentence lifted almost verbatim from CSS2, so it doesn't count). I don't know why this is the case, but it is not the intention that the non-hyphenated form refers to something different from the hyphenated form. In fact, section 9 itself uses both forms interchangeably — see section 9.2.4 for an example of the hyphenated form being used:

inline-block
This value causes an element to generate an inline-level block container. The inside of an inline-block is formatted as a block box, and the element itself is formatted as an atomic inline-level box.

I can see why readers would get confused, though. Fortunately, the rest of the CSS2 spec, and most CSS3 specs (that I've examined anyway) are all consistent in the use of the hyphenated form.

Also, the presence or absence of the word "box" doesn't change the meaning of "inline-block". Generally, the spec leaves it out because it's needlessly verbose; everything in the formatting structure that's not a text run is a box anyway, and "inline-block" as a noun rolls off the tongue rather nicely.

If non-replaced inline blocks are block container boxes, and elements with display:inline-block are inline-level boxes (i.e. not block-level boxes and thus not block container boxes) then it logically falls out that non-replaced inline blocks cannot be the result of elements with display:inline-block.

I think there is some misunderstanding here. The quote above lists inline-blocks as an example of a block container box that is not block-level; the purpose of that quote is to convey to the reader that not all block containers are block-level boxes, and not all block-level boxes are block containers — indeed, that the two concepts are distinct and should not be conflated. From my answer to this related question:

The only difference between a block box and an inline-block is that the former is block-level while the latter is inline-level. Hence the display values display: block and display: inline-block respectively. As both are block containers, there is no difference in how their contents are formatted.

Therefore, again, display: inline-block does cause an element to generate an inline-block (except when other parts of the layout force it to be formatted as block-level, or blockified, which is a separate topic altogether). Whether this inline-block is replaced or non-replaced depends on the element; for example, an <img> element with display: inline-block generates a replaced inline-block, whereas a <div> element with display: inline-block generates a non-replaced inline-block.

A replaced inline-block cannot actually form a block container, because its contents are rendered outside of the rules of CSS formatting. This is why the spec distinguishes non-replaced inline-blocks as block containers. There really isn't more to it than that.

Are tables replaced by DIVs?

To be semantically correct, tables should only used for tabular data and not for laying out a page.

David Dorward brought something to my attention in a comment. According to the HTML 4.01 Specification's section on Tables in HTML Documents:

Tables should not be used purely as a means to layout document content as this may present problems when rendering to non-visual media. Additionally, when used with graphics, these tables may force users to scroll horizontally to view a table designed on a system with a larger display. To minimize these problems, authors should use style sheets to control layout rather than tables.

How do I replace axis attribute in HTML5?

There's no direct replacement for axis in HTML 5, largely because browsers never did anything with it beyond exposing it on the DOM.

If there was a page which made practical use of it, then it would depend on JS in the page. The modern equivalent would be a data-* attribute but that would require that the JS be updated as well as the HTML.

Will HTML be replaced by any new technology?

HTML won't be replaced as a standard any time soon. It's too wide spread a technology, and the amount of re-education required among people working with webapps and websites to switch technology completely would be massive and very costly.

HTML will however, like any other technology, evolve. Look at HTML today compared to 10 years ago, it's the same language in the basics but the way we use it, and add-on technologies have changed it quite a lot. Even a high tech, premium site made 10 years ago will look feeble with todays standards.

So, while HTML will like stay "the same" (i.e. follow the natural evolution of a standard), the technology behind the site (php, .NET, JAVA etc.) will probably be more likely to change.