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/
Related
Other display values have one or more corresponding HTML elements, such as:
block - div, p
inline - span, strong, etc.
list-item - li
table - table, table-row - tr, etc.
none - template
but display: grid and display: flex must be assigned through styling. I could see it being easier to read through the DOM if <flex> and <grid> elements were available.
Are new element types not being added to the spec now that custom elements can be made?
The answer to your question has to do with the separation of style from the data being presented.
The HTML tags that you use to display data should be chosen based on the type of data that you are displaying. For example, you'd use <li> when you're producing a list or <strong> when you want text to stand out. CSS gives you a lot of flexibility for modifying how the data is presented allowing you can change how data, such as text in <strong> or <em> tags, is displayed. The styles for many tags can be changed so that they behave like other tags. For example, you can make a <span> tag behave like a <div> tag and vice versa. However, you should not do this. In other words, the tags that you select should be based on the type of data being displayed, such as <li> for list items or <p> for paragraphs. Technically, you can never completely separate your data from how it is displayed, but you should attempt to do so as much as is possible.
<flex> and <grid> don't have any meaning with respect to the type of data that you want to display. Thus, they are styles that are editable using CSS (instead of tags).
I could see it being easier to read through the DOM if <flex> and <grid> elements were available.
You're suggesting combining content and presentation, which counters the separation of concerns principle that CSS was created to address.
HTML is used for organization of content. CSS is used for presentation of content. Your <flex> and <grid> elements would combine these two concerns, which is the way things were in the 1990s, before the advent of CSS, when HTML did both.
Also, what if I want my <article> to be a grid container, or my <aside> to be a flex container?
Why not also have <block> and <inline>?
Things start getting messy.
Also, the premise of your question is incorrect.
Other display values have one or more corresponding HTML elements ... but display: grid and display: flex must be assigned through styling.
Actually, the display value of all HTML elements is assigned. The only difference is where the styling comes from.
In raw form, HTML elements have no styles. They only have semantic meaning.
It isn't until the browser assigns default styles that elements take on presentational meaning.
Therefore, the only reason you can say this...
Other display values have one or more corresponding HTML elements,
such as:
block - div, p
inline - span, strong, etc.
list-item - li
table - table, table-row - tr, etc.
... is because the browser defined those elements as such with something like this:
Appendix D. Default style sheet for HTML 4
As you can see, display values are assigned.
So the browser sets a basic level of formatting for HTML elements. Changes and additions to these styles are left up to authors.
Here's some more detail:
Proper way to apply CSS to HTML5 custom elements
<main> element not working in Internet Explorer 11
I don't think it is possible that HTML5 specifications introduce repeated tags that do the same thing. I need, exactly, what is the practically and hypothetically difference between both <kbd> and <code> tags?
This demo shows that they have the same effect!
It’s not clear what exactly you are asking about, however, you can find all the differences and similarities in the HTML5 spec. For example:
Meaning
The kbd element
represents user input […]
The code element
represents a fragment of computer code […]
Content model, attributes etc.
The same. Both are flow content / phrasing content / palpable content. Both have the phrasing content content model. Both can only have the global attributes, same ARIA roles etc.
Styling
They have the same default styling:
code, kbd, samp, tt { font-family: monospace; }
Both are displayed the same by DEFAULT, unless additional styling is put in place. However, they have different uses:
<kbd> should be used for keyboard and user commands
<code> should be used for displaying blocks of code
References
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/kbd
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/kbd
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)
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.
I've read many explanations of what the actual purpose of the < span > tag is, and I've tried to incorperate those explanations into real applications but have failed every time.
One person told me that it was to apply classes to sub-tags below it, which does kind of work, except it doesn't apply dimensions to elements, unless you mess around with the display and/or inline settings, which can totally screw up a layout.
Then someone else told me that it's use as a substitute for the < div > tag, which doesn't work because floats or "margin: auto"-type attributes don't work unless contained inside certain types of elements.
Then someone else told me that it's used as a text container, which doesn't work because the "text-align" attribute doesn't work, again, unless contained inside certain types of elements. A default-attribute-cleared < p > tag is much more suited, in my experience.
So what exactly is the point of them? Why are so many people using them when < div > seems to do everything that they're apparently capable of and more?
From Official Docs:
The DIV and SPAN elements, in conjunction with the id and class
attributes, offer a generic mechanism for adding structure to
documents. These elements define content to be inline (SPAN) or
block-level (DIV) but impose no other presentational idioms on the
content. Thus, authors may use these elements in conjunction with
style sheets, the lang attribute, etc., to tailor HTML to their own
needs and tastes.
As it says, you can use <span> tag to structure (inline) the sections of page along with styling which you may optionally pass via id, class or stylesheets.
Characteristics of <span> tag:
It's display is inline by default which means:
you can not apply width to it
you can not apply height to it
you can make it block-level too by using display:block (div serves the same purpose)
The <div> tag is opposite to that and you can apply above rules to it.
It is an inline element with no attached semantics that can be used to wrap some inline content for
the application of JavaScript (e.g. event handlers or moving about the DOM)
the application of CSS
use with the lang attribute
processing by custom tools
… when no element with more appropriate semantics exists.
floats or "margin: auto"-type attributes don't work unless contained inside certain types of elements.
They work (or otherwise) based mostly on the display value, not the element type.
Why are so many people using them when <div> seems to do everything that they're apparently capable of and more?
A div is identical to a span except it:
Can contain block elements
Cannot (error recovery not withstanding) be contained by an inline element (or any other element that can contain only inline content, such as a <p>)
Is display: block by default (instead of inline)
When the text is in a <span> element you can add styles to the content, or manipulate the content.