It seems the only real difference between the figure and aside elements, is that a figure is "referenced" by the main flow, where as an aside is not.
What exactly does reference mean in this context?
For example if I have a figure image of a mountain. Does it mean I need to point out that exact figure of the mountain or does it mean I could be talking about a mountain. How specific does a "reference" need to be for its proper use? Also if it needs to be referenced by the main flow does that mean it needs to be something the entire page is about and not just an article of it?
<figure>
<img src="mountainReiner.jpg">
<figcaption><p>mount reiner</p></figcaption>
</figure>
<p> paragraph talking about mountain reiner</p>
2017-07-18 update
The HTML spec was updated[❄︎][❆] to clarify what’s meant by referenced as far as HTML elements.
The word referenced in the figure element section and also in other sections is now a link to https://html.spec.whatwg.org/multipage/dom.html#referenced which reads:
Elements can be referenced (referred to) in some way, either explicitly or implicitly. One way that an element in the DOM can be explicitly referenced is by giving an id attribute to the element, and then creating a hyperlink with that id attribute's value as the fragment for the hyperlink's href attribute value. Hyperlinks are not necessary for a reference, however; any manner of referring to the element in question will suffice.
And there’s a detailed example following that text.
2017-07-13 original answer
What exactly does reference mean in this context?
It comes from the fact that in print publishing, figures are illustrations that are titled and numbered so you can cite them (reference them) by number+title easily in some any part of a publication.
For example, see how-to-use-figures style guides such as the following:
MLA Tables, Figures, and Examples — https://owl.english.purdue.edu/owl/resource/747/14/
Each illustration must include a label, a number, a caption and/or source information.
APA Tables and Figures — https://owl.english.purdue.edu/owl/resource/560/20/
For figures, make sure to include the figure number and a title with a legend and caption.
MLA Citation Guide (8th Edition): Images, Charts, Graphs, Maps & Tables — https://columbiacollege-ca.libguides.com/mla/images
Each figure should be assigned a figure number, starting with number 1 for the first figure used in the assignment.
In Web documents, you can just put an id attribute on the figcaption elements that provide the title for each figure, and then use a-element hyperlinks to reference those titles, so numbers for figures aren’t strictly necessary. But many Web documents use numbered figures anyway.
Does it mean I need to point out that exact figure of the mountain or does it mean I could be talking about a mountain.
It means, give figures a figcaption with a title+id that lets you refer to it elsewhere in the doc.
How specific does a "reference" need to be for its proper use?
It can (should) be exact—a hyperlink pointing to a unique id.
Even if the figure is unnumbered and has the same title as another figure in the same document, if it has a unique id attribute, you can refer to it specifically/exactly by hyperlinking to that id.
Also if it needs to be referenced by the main flow does that mean it needs to be something the entire page is about and not just an article of it?
No, the HTML spec at least imposes no special requirements like that.
For the record here, the relevant language from the HTML spec is this:
The figure element represents some flow content, optionally with a caption, that is self-contained (like a complete sentence) and is typically referenced as a single unit from the main flow of the document.
https://html.spec.whatwg.org/multipage/grouping-content.html#the-figure-element
Reference means the subject matter or what your web page is about. If your web page is about Hiking(the referent), the figure of the mountain is there to reference the theme of hiking.
Another version is:
Aside is information that is not related directly to the main content. (Generally not assisting directly in the main content. (such as car parts for the Hiking Page)
Figure may be used most widely in documents to illuminate the main themes of the document or to assist proving the main theme.
Related
This question already has answers here:
Why should I use 'li' instead of 'div'?
(15 answers)
Are new HTML5 elements like <section> and <article> pointless? [closed]
(8 answers)
Why use HTML5 tags? [duplicate]
(1 answer)
Closed 9 years ago.
Why use HTML5 semantic tags like headers, section, nav, and article instead of simply div with the preferred css to it?
I created a webpage and used those tags, but they do not make a difference from div. What is their main purpose?
Is it only for the appropriate names for the tags while using it or more than that?
Please explain. I have gone through many sites, but I could not find these basics.
The Oxford Dictionary states:
semantics: the branch of linguistics and logic concerned with meaning.
As their name says, these tags are meant to improve the meaning of your web page. Good semantics plays an important role the automated processing of documents. This automated processing happens more often than you realize - each website ranking from search engines is derived from automated processing of all the website out there.
If you visit a (well designed) web page, you as the human reader can immediately (visually) distinguish all the page elements and more importantly understand the content. In the top left you see the company logo, next to it is the site navigation, there is a search bar and some text about the company, a link to a product you can buy and a legal disclaimer at the bottom.
However, machines are dumb and cannot do this:
Looking at the same page as you, all the web crawler would see is an image, a list of anchors tags, a text node, an input field and an image with a link on it. At the bottom there is another text node.
Now, how should they know, what part of the document you intended to be the navigation or the main article, or some not-so-important footnote? They can guess by analyzing your document structure using some common criteria which are a hint for a specific element.
E.g. an ul list of internal links is most likely some kind of page navigation and the text at the end of the document is something necessary but not so important to the everyday viewer (the legal disclaimer).
Now imagine instead of a plain div, a nav element would be used – the machine immediately knows what the purpose of this element is:
// machine: okay, this structure looks like it might be a navigation element?
<div><ul><li><a href="internal_link">...</div>
// machine: ah, a navigation element!
<nav><ul><li><a>...</nav>
Now the text inside a main tag – this is clearly the most important information of the page! Over there to the left, that text node, the image and the anchor node all belong together, because they are grouped inside a section tag, and down at the bottom there is some text inside a footer element (they still don't know the meaning of that text, but now they can deduce it's some sort of fine print).
Example:
You, as the user (reading a page without seeing the actual markup), don't care if an element is enclosed in an <i> or <em> tag. In most browsers both of these tags will be rendered identically – as italic text – and as long as it stands out between the surrounding text it serves its purpose.
However, there is a big difference in terms of semantics:
<i> means italic - it's simply a presentational hint for the browser on how to render it (italic) and does not necessarily contain deeper semantic information.
<em> means emphasize - it indicates an important piece of information. Now the browser is not bound to the italic instruction any more, but could render it in italic or bold or underlined or in a different color... For visually impaired persons, the screen readers can raise the voice - whatever method seems most suited in a specific situation to emphasise this important information.
Final thought:
Semantic tags are not the end. There are things like metadata, ontologies, resource description languages which go a step further and help connect data between different web pages and can even help create new knowledge!
E.g. wikipedia is doing a really bad job at semantically presenting data.
https://en.wikipedia.org/wiki/Barack_Obama
https://en.wikipedia.org/wiki/Donald_Trump
https://en.wikipedia.org/wiki/Joe_Biden
All three are persons who at some point in time where president of the USA.
All three articles contain a sidebar that displays these information, and you can compare them (by opening both pages and then switching back and forth), but they are not semantically described.
Instead, if wikipedia used an ontology to describe a person: http://dbpedia.org/ontology/Person
<!-- President is a subclass of Politician which is a subclass of Person -->
<President>
<birthname>Barrack Hussein Obama II</birthname>
<birthdate>1961-08-04</birthdate>
<headOf>country::USA</headOf>
<tenure>2009-01-20 – 2017-01-20</tenure>
</President>
Not only could you (and machines) now directly compare those three directly (on a dynamically generated page!), but you could even create new knowledge, e.g. show a list of all presidents of the United States - quite boring but also cool stuff like who are all the current world leaders, how many female world leaders do we have, who is the youngest leader, how many types of leaders are there (presidents/emperors/queens/dictators), who served the longest, how many of them are taller than 175cm and have brown eyes, etc. etc.
In conclusion, good semantics is super cool (but also – on a technical level – hard to achieve and maintain).
There's a nice little article on HTML5 semantics on HTML5Doctor.
Semantics have been a part of HTML in some form or another. It helps you understand what's happening where on the page.
Earlier when <div> was used for pretty much everything, we still implemented semantics by giving it a "semantic" class name or an id name.
These tags help in proper structuring and understanding of the layout.
If you do,
<div class="nav"></div>
as opposed to,
<nav></nav>
OR
<div class="sidebar"></div>
as opposed to,
<aside></aside>
there's nothing wrong, but the latter helps in providing better readability for you as well as crawlers, readers, etc..
In the div tag you have to give an id which tells about what kind of content it is holding, either body, header, footer, etc.
While in case of semantic elements of HTML5, the name clearly defines what kind of code it is holding, and it is for which part of the website.
Semantic elements are <header>, <footer>, <section>, <aside>, etc.
I have been trying to understand the <figure> element; take a look at this from w3.org:
Self-contained in this context does not necessarily mean independent. For example,each sentence in a paragraph is self-contained; an image that is part of a sentence would be inappropriate for figure, but an entire sentence made of images would be fitting.
How can an image can be part of a sentence? What is this talking about? I have read many explanations, but yet I don't understand why I would want to use this element. What is the purpose of this tag?
According to MDN:
Usually a <figure> is an image, illustration, diagram, code snippet, etc., that is referenced in the main flow of a document, but that can be moved to another part of the document or to an appendix without affecting the main flow.
An example of this (based on one from that same MDN link) might be a code snippet that prints the parts of the browser's navigator in an article about that attribute. You don't need to know the exact code to print that information to understand what is in the navigator, but it can aid the reader's understanding.
Additionally, the <figure> tag allows use of the <figcaption> tag as a child, which is a convenient and accessible way to caption images.
HTML5 semantic tags are cryptic for everyone. Since the concepts are kept abstract and scientific in purpose, I will use a bunch of over-simplification to make it understandable, in spite of HTML5
gurus telling me how wrong I am.
Remember that semantic tags are created to be read by computers, not humans. They exist so that google's scripts (and everyone's scripts, but mainly google and hacker bots) can quickly search for figures and index them. To understand semantic tags, think like a script, not as a human.
"If I was a bot programmed by a hacker, how would I mine figures when crawling my website?"
If we code a script that looks for IMG tags it will end up gathering a bunch of garbage (i.e. icons). What we're interested in is real content, that's what "self-contained content" means: you cut & paste this element from your website into my gallery of mined images in your HTML, and it's useful.
Garbage: icons, decorative images, images created by javascript plugins to prettify things, smileys, etc.
Good finds: charts, photos, diagrams, maps, drawings, etc.
The "Good finds" make sense even if you steal them from your webpage with no context whatsoever, except things like the accompanying "caption" tag. These tags allow crawlers to associate your images with text tags, making categorization easier So you don't want to miss this content.
So we're interested in the figure caption, title, subtitle, whatever, and the figure should wrap all of this. The figure tag is not limited to images; it can contain text, video, audio, code blocks, anything as long as it's part of that "entity" in your document. So the following is a single figure:
Now, in documents like scientific papers you will often find stuff like this:
Although each image makes sense by itself, they make more sense as a group as they are connected by some kind of relationship; sometimes even the order matters (i.e. series of steps, or photos of states something goes through). That's a "sentence of figures" and you want to mine them together or you'll lose valuable information.
Our mining algorithm would have to understand your website's content with some kind of natural-language-processing AI, or it could just gather the FIGURE tags you provide for it. The later is good semantics.
Summarizing, imagine you're the Google AI algorithm mining figures in your code. Write your figure tags to make this script's job easy.
Is it semantically correct to use a figure element for a map (google maps for example)?
In my case it can me placed somewhere else without affecting the document flow. I would use the figcaption to store the address of the place shown on the map. But I'm still not sure if this suites to this usecase...
This is the w3c description:
The figure element represents some flow content, optionally with a
caption, that is self-contained and is typically referenced as a
single unit from the main flow of the document. The figure element can
be used to annotate illustrations, diagrams, photos, code listings,
etc., that are referenced in the main content of the document, but that could, without affecting the flow of the document, be moved
away from that primary content — e.g., to the side of the page, to
dedicated pages, or to an appendix.
http://dev.w3.org/html5/spec/the-figure-element.html#the-figure-element
I'd say it was a pretty good use of the figure element, provided that the map is not itself the primary content of the page.
Based on the W3C description the <figure> element is the perfect solution for a map. Especially if the map contains just an additional graphic info or clarification for what's on the page already.
I have seen it a lot in css talk. What does semantically correct mean?
Labeling correctly
It means that you're calling something what it actually is. The classic example is that if something is a table, it should contain rows and columns of data. To use that for layout is semantically incorrect - you're saying "this is a table" when it's not.
Another example: a list (<ul> or <ol>) should generally be used to group similar items (<li>). You could use a div for the group and a <span> for each item, and style each span to be on a separate line with a bullet point, and it might look the way you want. But "this is a list" conveys more information.
Fits the ideal behind HTML
HTML stands for "HyperText Markup Language"; its purpose is to mark up, or label, your content. The more accurately you mark it up, the better. New elements are being introduced in HTML5 to more accurately label common web page parts, such as headers and footers.
Makes it more useful
All of this semantic labeling helps machines parse your content, which helps users. For instance:
Knowing what your elements are lets browsers use sensible defaults for how they should look and behave. This means you have less customization work to do and are more likely to get consistent results in different browsers.
Browsers can correctly apply your CSS (Cascading Style Sheets), describing how each type of content should look. You can offer alternative styles, or users can use their own; as long as you've labeled your elements semantically, rules like "I want headlines to be huge" will be usable.
Screen readers for the blind can help them fill out a form more easily if the logical sections are broken into fieldsets with one legend for each one. A blind user can hear the legend text and decide, "oh, I can skip this section," just as a sighted user might do by reading it.
Mobile phones can switch to a numeric keyboard when they see a form input of type="tel" (for telephone numbers).
Semantics basically means "The study of meaning".
Usually when people are talking about code being semantically correct, they're referring to the code that accurately describes something.
In (x)HTML, there are certain tags that give meaning to the content they contain. For example:
An H1 tag describes the data it contains as a level-1 heading. An H2 tag describes the data it contains as a level-2 heading. The implied meaning behind this is that each H2 under an H1 is in some way related (i.e. heading and subheading).
When you code in a semantic way, you basically give meaning to the data you're describing.
Consider the following 2 samples of semantic VS non-semantic:
<h1>Heading</h1>
<h2>Subheading</h2>
VS a non-semantic equivalent:
<p><strong>Heading</strong></p>
<p><em>Subheading</em></p>
Sometimes you might hear people in a debate saying "You're just talking semantics now" and this usually refers to the act of saying the same meaning as the other person but using different words.
"Semantically correct usage of elements means that you use them for what they are meant to be used for. It means that you use tables for tabular data but not for layout, it means that you use lists for listing things, strong and em for giving text an emphasis, and the like."
From: http://www.codingforums.com/archive/index.php/t-53165.html
HTML elements have meaning. "Semantically correct" means that your elements mean what they are supposed to.
For instance, you definition lists are represented by <dl> lists in code, your abbreviations are <abbr>s etc.
It means that HTML elements are used in the right context (not like tables are used for design purposes), CSS classes are named in a human-understandable way and the document itself has a structure that can be processed by non-browser clients like screen-readers, automatic parsers trying to extract the information and its structure from the document etc.
For example, you use lists to build up menus. This way a screen reader for disabled people will know these list items are parts of the same menu level, so it will read them in sequence for a person to make choice.
I've never heard it in a purely CSS context, but when talking about CSS and HTML, it means using the proper tags (for example, avoiding the use of the table tag for non-tabular data), providing proper values for the class and id that identify what the contained data is (and using microformats as appropriate), and so on.
It's all about making sure that your data can be understood by humans (everything is displayed properly) and computers (everything is properly identified and marked up).
What work, if any, has been done to automatically determine the most important data within an html document? As an example, think of your standard news/blog/magazine-style website, containing navigation (with submenu's possibly), ads, comments, and the prize - our article/blog/news-body.
How would you determine what information on a news/blog/magazine is the primary data in an automated fashion?
Note: Ideally, the method would work with well-formed markup, and terrible markup. Whether somebody uses paragraph tags to make paragraphs, or a series of breaks.
Readability does a decent job of exactly this.
It's open source and posted on Google Code.
UPDATE: I see (via HN) that someone has used Readability to mangle RSS feeds into a more useful format, automagically.
think of your standard news/blog/magazine-style website, containing navigation (with submenu's possibly), ads, comments, and the prize - our article/blog/news-body.
How would you determine what information on a news/blog/magazine is the primary data in an automated fashion?
I would probably try something like this:
open URL
read in all links to same website from that page
follow all links and build a DOM tree for each URL (HTML file)
this should help you come up with redundant contents (included templates and such)
compare DOM trees for all documents on same site (tree walking)
strip all redundant nodes (i.e. repeated, navigational markup, ads and such things)
try to identify similar nodes and strip if possible
find largest unique text blocks that are not to be found in other DOMs on that website (i.e. unique content)
add as candidate for further processing
This approach of doing it seems pretty promising because it would be fairly simple to do, but still have good potential to be adaptive, even to complex Web 2.0 pages that make excessive use of templates, because it would identify similiar HTML nodes in between all pages on the same website.
This could probably be further improved by simpling using a scoring system to keep track of DOM nodes that were previously identified to contain unique contents, so that these nodes are prioritized for other pages.
Sometimes there's a CSS Media section defined as 'Print.' It's intended use is for 'Click here to print this page' links. Usually people use it to strip a lot of the fluff and leave only the meat of the information.
http://www.w3.org/TR/CSS2/media.html
I would try to read this style, and then scrape whatever is left visible.
You can use support vector machines to do text classification. One idea is to break pages into different sections (say consider each structural element like a div is a document) and gather some properties of it and convert it to a vector. (As other people suggested this could be number of words, number of links, number of images more the better.)
First start with a large set of documents (100-1000) that you already choose which part is the main part. Then use this set to train your SVM.
And for each new document you just need to convert it to vector and pass it to SVM.
This vector model actually quite useful in text classification, and you do not need to use an SVM necessarily. You can use a simpler Bayesian model as well.
And if you are interested, you can find more details in Introduction to Information Retrieval. (Freely available online)
I think the most straightforward way would be to look for the largest block of text without markup. Then, once it's found, figure out the bounds of it and extract it. You'd probably want to exclude certain tags from "not markup" like links and images, depending on what you're targeting. If this will have an interface, maybe include a checkbox list of tags to exclude from the search.
You might also look for the lowest level in the DOM tree and figure out which of those elements is the largest, but that wouldn't work well on poorly written pages, as the dom tree is often broken on such pages. If you end up using this, I'd come up with some way to see if the browser has entered quirks mode before trying it.
You might also try using several of these checks, then coming up with a metric for deciding which is best. For example, still try to use my second option above, but give it's result a lower "rating" if the browser would enter quirks mode normally. Going with this would obviously impact performance.
I think a very effective algorithm for this might be, "Which DIV has the most text in it that contains few links?"
Seldom do ads have more than two or three sentences of text. Look at the right side of this page, for example.
The content area is almost always the area with the greatest width on the page.
I would probably start with Title and anything else in a Head tag, then filter down through heading tags in order (ie h1, h2, h3, etc.)... beyond that, I guess I would go in order, from top to bottom. Depending on how it's styled, it may be a safe bet to assume a page title would have an ID or a unique class.
I would look for sentences with punctuation. Menus, headers, footers etc. usually contains seperate words, but not sentences ending containing commas and ending in period or equivalent punctuation.
You could look for the first and last element containing sentences with punctuation, and take everything in between. Headers are a special case since they usually dont have punctuation either, but you can typically recognize them as Hn elements immediately before sentences.
While this is obviously not the answer, I would assume that the important content is located near the center of the styled page and usually consists of several blocks interrupted by headlines and such. The structure itself may be a give-away in the markup, too.
A diff between articles / posts / threads would be a good filter to find out what content distinguishes a particular page (obviously this would have to be augmented to filter out random crap like ads, "quote of the day"s or banners). The structure of the content may be very similar for multiple pages, so don't rely on structural differences too much.
Instapaper does a good job with this. You might want to check Marco Arment's blog for hints about how he did it.
Today most of the news/blogs websites are using a blogging platform.
So i would create a set of rules by which i would search for content.
By example two of the most popular blogging platforms are wordpress and Google Blogspot.
Wordpress posts are marked by:
<div class="entry">
...
</div>
Blogspot posts are marked by:
<div class="post-body">
...
</div>
If the search by css classes fails you could turn to the other solutions, identifying the biggest chunk of text and so on.
As Readability is not available anymore:
If you're only interested in the outcome, you use Readability's successor Mercury, a web service.
If you're interested in some code how this can be done and prefer JavaScript, then there is Mozilla's Readability.js, which is used for Firefox's Reader View.
If you prefer Java, you can take a look at Crux, which does also pretty good job.
Or if Kotlin is more your language, then you can take a look at Readability4J, a port of above's Readability.js.