I am new to Web programming,
Can I please know what is the difference between inline level elements vs phrase elements ?
em and strong they are phrase elements ? but are they inline too, I don't quite get the difference,
Also if you could add what is significance of knowing blocklevel elements in relation to inline, phrase elements,
Thanks,
The term "phrase element" was last used in the HTML4.01 specification, section 9.2.1 Phrase elements:
Phrase elements add structural information to text fragments. The usual meanings of phrase elements are following [followed by a list of phrase elements] (source).
They are rendered as inline-level elements, they do not form new blocks of content. In HTML5 they are redefined as phrasing elements.
For block-elements have a look at the CSS2.1 specification (section 9 Visual formatting model):
Block-level elements are those elements of the source document that are formatted visually as blocks (e.g., paragraphs). The following values of the 'display' property make an element block-level: 'block', 'list-item', and 'table'.
So phrase or phrasing is more a semantical attribute, while inline-level or block-level is more a rendering attribute. Most phrasing elements are inline-level elements, most flow elements block-level elements.
Different HTML specifications and drafts use partly different terminology. Moreover, some of the concepts have CSS counterparts. Confusing these with each other can be really confusing, so let’s focus on the HTML 4.01 specification.
It has a section on block-level and inline elements, which is somewhat confusing. The fundamental distinction is formal and syntactic: some elements (e.g., p) are designated in the spec as block level, others are inline. Generally, you cannot put a block level element inside an inline element, but rules like this are really set in the syntax of element. The default formatting normally renders a block level element as a rectangle that occupies the available width, but this can be changed by a style sheet.
The distinction is supposed to be practical, helping people understand some rules easier. To some extent, it also has independent informational value. For example, the HTML specs do not specifically say that an ul element by default starts on a new line, and implies a line break after it too, and occupies the available width. This is more or less implied in designating it as block level element.
“Phrase element” is a term defined syntactically by enumerating some (inline) elements: EM, STRONG, DFN, CODE, SAMP, KBD, VAR, CITE, ABBR, and ACRONYM. The spec tries to describe this by saying that such elements “add structural information to text fragments”. This is meant to say that these elements say something about the meaning or role of their contents. For example, EM is said to mean emphasis (whatever that means). This is in opposite to inline elements like FONT and I, which indicate presentational features of text. But the “phrase level” concept is far from clear, and it has no special relevance in HTML.
Related
What are the different types of inline and block elements in html5
I am confused between the different types of inline and block elements in html5
There aren't any.
HTML 4.x uses %block and %inline to categorize most elements in the specification. This is so the DTD can specify which elements are allowed as children of which other elements.
HTML 5 does not as it goes into much more detail about what elements are allowed where using categories — like flow and phrasing — and more complex rules like "Content model:
Phrasing content, but there must be no interactive content descendant and no descendant with the tabindex attribute specified." instead.
Meanwhile CSS's display property which (in version 1) supported only four values (block, inline, list-item, and none) — so most HTML elements (by default) displayed as either block or inline — now has significantly more values, some of which can be combined (like display: inline flow-root).
In the 1990s block and inline were useful categories for describing elements. Today, and in HTML 5, they are not.
I came across an article a while ago which explained why some HTML tags can be nested in some tags and some tags cannot do that. But I forgot the keywords that describe this design in the browser/HTML specification to validate a valid HTML. I believe that there are two keywords that describe this, but I forgot them. Can someone help me out?
The keywords are not structural/presentation.
All I remember that the two keywords are handy to remember why some HTML tags can be nested in some tags, but not in some tags.
For instance
<p><div></div></p>
is not valid HTML
Thanks
As one comment suggests, you're probably thinking of "block" elements (which break the flow of content, have 100% default width and can contain other elements) and "inline" elements (don't break the content flow so they won't create a text line of their own, their width adjusts to the content and are not containers in nature).
This is mentioned in HTML4: https://www.w3.org/TR/html401/struct/global.html#h-7.5.3
Generally, block-level elements may contain inline
elements and other block-level elements. (...) inline elements
may contain only data and other inline elements. Inherent in this
structural distinction is the idea that block elements create "larger"
structures than inline elements.(...) Generally,
block-level elements begin on new lines, inline elements do not.
The HTML5 spec, however, will talk about categories instead: https://dev.w3.org/html5/html-author/#categories
HTML4 used inline and block-level but HTML5 says:
HTML does not use the terms "block-level" or "inline" as part of its
content model rules, to reduce confusion with CSS.
So these terms may now be better suited to a type of CSS display rendering mechanism.
It is not valid to nest a block level element such as p directly inside an inline element such as b.
However, using css such as display: inline-block or position: absolute is can be conceptually sound to have block level content inside an inline context.
Browsers largely accept such block level elements in an inline element, but under some circumstances, the invalid construct causes real problems:
<p><span><p></p></span></p>
The above example would not be parsed as three nested elements; the innermost <p> would instead implicitly close the outer <p>, regardless of CSS. You can see a jsbin demo of that.
Is there some way of using intermediate elements to validly place block level elements in an inline element?
If that's not possible, is there an invalid but functional workaround for the majority of cases (preferably also for the tricky <p> tag)?
To be clear, I'm looking for a generic solution that doesn't require invasive changes to document structure (i.e. "just use span everywhere, for everything" is not an attractive solution). I want to embed an unknown (dynamically generated) document fragment with potentially block-level content - so fixing the fragment to exclude block level elements is infeasible.
Related: (address the validity of direct nesting mostly)
Is it wrong to change a block element to inline with CSS if it contains another block element?
Block Level Elements inside Inline elements
Are block-level elements allowed inside inline-level elements in HTML5?
The W3C validator (in XHTML mode) lists the following elements as valid between a <span> and a <p>:
object
ins
del
map
button
A page using these as inline-to-block spanners validates in XHTML Strict, but not in HTML 5. Of these tags, I would favor object, since it has the least semantic baggage.
HTML 5 seems to have discarded the inline vs. block distinction in favor of a more complex system, in which there are several different categories of element, and which children an element can have depends on what its ancestors are. Of these elements, ins, del and map now accept the same kind of children that their parent element accepts, and button only accepts "phrasing content" (the closest thing to inline elements). The error message for object doesn't make much sense, but as near as I can gather, it's inheriting the parent element's restrictions while also imposing some restrictions of its own.
As near as I can tell, there's no way to escape from phrasing content once you're in it (short of an iframe and a new document), so the answer to this question is no, can't be done in HTML5 (as of this writing).
Semantically is wrong and I think HTML5 allows block elements inside < a > tags only (as far as I know).
In other words, you can make your html code work as you want by changing the css, but that doesn't mean your html code is correct. You also should consider SEO and Accessibility issues that will arise.
Encountered the following while reading the height property of CSS2 specification:
Applies to: all elements but non-replaced inline elements, table columns, and column groups
I understand what replaced element(<img>) or inline element(<button>, <a>) are, but having trouble finding out examples of non-replaced inline elements.
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.
David Baron discusses this on his website here.
There are two types of inline elements: replaced inline elements and
non-replaced inline elements. In general, non-replaced elements are
those whose content is contained in the document, whereas
replaced-elements are those whose content is outside of the document.
For example, in the code:
Visit the World Wide Web Consortium
to learn about... the content of the a element is "World Wide Web
Consortium". Replaced elements are those where the content comes from
some external source, for example, an object or img element.
However, as far as the inline box model is concerned, the definitions
are as described above except that elements with display types
inline-table and inline-block (the latter is a proposed type for CSS3
to accommodate form elements) are considered replaced elements.
Good examples of non-replaced inline elements are span, strong, i, b, em, etc.
You can find the definition of a replaced element in the index:
An element whose content is outside the scope of the CSS formatting
model, such as an image, embedded document, or applet. For example,
the content of the HTML IMG element is often replaced by the image
that its "src" attribute designates. Replaced elements often have
intrinsic dimensions: an intrinsic width, an intrinsic height, and an
intrinsic ratio. For example, a bitmap image has an intrinsic width
and an intrinsic height specified in absolute units (from which the
intrinsic ratio can obviously be determined). On the other hand, other
documents may not have any intrinsic dimensions (for example, a blank
HTML document).
User agents may consider a replaced element to not have any intrinsic
dimensions if it is believed that those dimensions could leak
sensitive information to a third party. For example, if an HTML
document changed intrinsic size depending on the user's bank balance,
then the UA might want to act as if that resource had no intrinsic
dimensions.
The content of replaced elements is not considered in the CSS
rendering model.
A non-replaced inline element is something that is inline and does not conform to the above. Roughly speaking, it is an element containing (or that can contain) text that can be styled normally. (a, b, cite, def, em, etc)
Some HTML elements (<div>, <span>, <p>, <h1>, <h2>, ..., <h6> <b>, <i>, and so on) seem to behave the same way except for default styling. For example, <span style="font-weight: bold;"> x </span> seems equivalent to <b> x </b>. Some elements such as <a> have special properties but behave mostly the same way.
Can someone make this precise?
In particular, is there a subset of elements that "covers" all of HTML?
Edit: I understand that elements are meant to carry semantics. But suppose that I don't care about semantics, and I only want to deal with the smallest subset of HTML that will give me access to some given browser behavior. I'm wondering how to find that subset.
HTML is meant to mark up text semantically. That means giving meaning to a piece of text, like this is a headline, this is a paragraph, this is a quote, this should be emphasized. Some/most of them are displayed very similar by default, but that's not the point. The point is to be able to programmatically extract meaning and process elements according to their meaning, for example by styling them. Don't confuse semantics with style.
If you want to leave that aside, you pretty much only need block level elements like a div and inline elements like span, plus anything that has a specific function like links, objects etc.
Some reasons why an element cannot fully be replicated by <span class="..."> ignoring mere semantics and just considering browser or other HTML consumer behaviour:
The element is the root element.
The element is a metadata element
The element is a scripting element
The element is an embedded content element
The element is a forms element
The element is an interactive element
The element is a links element
The element is used by the document outline algorithm; including:
Sectioning content elements
Sectioning root elements
Heading content elements
The element goes in a place in the DOM where a span is precluded from going by the parser
The element forms part of a specific rendering binding
The element has a default WAI-ARIA role other than 'no role'
The element's DOM interface extends beyond that of HTMLElement
The element is the span element itself.
By my reckoning that leaves abbr, address, b, bdi, bdo, br, cite, code, dd, dfn, div, dl, dt, em, footer, header, kbd, mark, p, pre, rp, rt, ruby, s, samp, strong, sub, sup, u, var and wbr as the maximum list of elements replaceable by span if one ignores semantics. That's 31 out of 107 different elements in HTML5. Of the other 76, each has a specific job in browsers.
I note that of the above list, there are a number where I don't know what the equivalent styling would be, and that in all cases it's less typing to use the correct semantic element than to replace it with a span+class.
This depends on what you mean by browser behavior. All browsers will treat e.g. a elements with href attributes in a special way, as links, and this cannot be expressed in CSS. Similarly, form input fields are special, and so is img, even though you can simulate much of its behavior by using a background image in CSS. But what about abbr for example? Although most browsers just apply some default styling to it, some special browsers or assistive tools used with them give the user optional access to the value of the title attribute. Similarly, while most browsers treat h1 and other heading elements just by applying some default styling to them, some browsers have e.g. a mode where the browser only reads the headings to the user.
Similarly, you can create tables using CSS (display: table etc.) without using any table markup in HTML—though older browsers won’t get this right—but then your “tables” will not have accessibility features that HTML tables can have.
Search engines are not browsers, but they may be very important, and they are known to pay attention to HTML markup, though the details have not been disclosed. However, if you start e.g. using styled div elements intead of heading elements, you will probably lose something in search engine friendlyness.
Some elements have a very specific purpose, for example html, head, body, script, meta, embed, object, hr, table, tr, td, form, input. They do things that isn't possible to do by just specifying a style.
The rest of the elements, for example span, div, b, i, u, h1, p, only differ in their default style. You can use a span tag and apply display:block to it, and it works as a div tag.
Note though that there are block elements like div, and there are inline elements like span. You can't put a block element inside an inline element (until all browsers support HTML 5).
So, you strictly don't need all different elements. Some elements are even deprecated in HTML 4, for example b and i, as they are not needed and doesn't follow modern markup usage, so they should be replaced by styling.
You should however consider the semantics that the different elements add. The h1 element for example is important for search engines when they try to find out what the page is about. If you don't use the h1 element for your headline, search engines will rate your page lower.
The main difference between them is semantic. To illustrate, in HTML5 for example, you have div, section, header, footer etc., which are all block elements. In HTML4 you're required to use div for all of those. Which is easier to read, to look at, to style - a page full of div's or something divided into headers, and sections, and footers?
As you state, some elements have attributes that are specific to that element type/or certain types (e.g., a). So there's another difference.
Finally, in your list, you also have some block level (e.g., div, p) and some inline level (e.g., span, b) elements - those have very different default behaviors. See: http://www.webdesignfromscratch.com/html-css/css-block-and-inline/