HTML: What is `xmlns:fb="http://www.facebook.com/2008/fbml"`? - html

What is xmlns:fb="http://www.facebook.com/2008/fbml"?
I've been seeing it in a lot of <html> tags recently. What does it do?

While I haven't seen it in use, this is standard XML notation for extending the current XML namespace (in this case XHTML) with another one (in this case FBML). This tells your browser where to find the specification for FBML which in turn tells it how to handle the <fb:*> tags. Technically speaking, the value of the xmlns:* attribute is simply a unique identifier, but often it is a URL which points to a definition in one form or another. In this particular case the URL doesn't point to a definition unfortunately.
See W3Schools for more information about XML namespaces.

Just as #Matthew Scharley said, its used to embed Facebook-specific tags on your site. For example, here's our company's Facebook stream on our site. Another common use it the "Like" button on website. More information can be found on the Facebook developer site.
UPDATE
Here's some additional widgets/plugins.

Related

Unrecognized HTML <a> tag attribute: data-is-disabled

We had a web app developed by a third party. In one file, there are several instances of a HTML <a> tag with the attribute "data-is-disabled". I can find no reference to such an attribute. As such, it should be perfectly okay to delete it - correct?
More info: The app was developed using Laravel and is_disabled is a property of one of the data objects. Does Laravel do something with this tag?
The data- prefix suggests that it is a user-defined attribute, created by the developer or the application. It's unlikely you'll find references to it anywhere online. If in doubt you should consult the ones who developed it, or leave the attribute alone. The error in your question title is likely the result of validating your HTML as HTML 4 or XHTML 1 (or older). Data attributes are new to HTML5 and the page doctype should reflect this: <!DOCTYPE html>
I'm not familiar with Laravel, but this attribute could well be used by it. Someone more familiar with the subject could comment further. Again, your best option is to consult your developer.
This is a data attribute (http://www.w3schools.com/tags/att_global_data.asp). These are typically used to interact with JavaScript, so you cannot assume it's not used based on HTML only.
Besides: CSS may also target these links (e.g. a[data-is-disabled]

Using <object> tag to include HTML content: allowed format of included file

OK, I know how to include HTML content from a separate file using the <object> tag. What I can't find any info about is what is allowed/required within the included HTML file. Can said included file merely be some text with some HTML tags, or does it have to be a complete HTML file with headers, <head>, and <body>? How does this appear within the DOM of the original document, if it appears within that DOM at all? Or are the two documents treated entirely separately?
Yes, I know, I could experiment to see what works. However, I know enough about HTML to know that what happens to work, for now, may not be the correct way to do things. I am not expecting anyone to list out all the rules here, but if someone could post some links I would much appreciate it. This is a topic that has proven exceeding difficult to search the internet for.
In 13.5 Notes on embedded documents, I believe I have found the answer to both of my questions. The second paragraph says,
An embedded document is entirely independent of the document in which
it is embedded. For instance, relative URIs within the embedded
document resolve according to the base URI of the embedded document,
not that of the main document. An embedded document is only rendered
within another document (e.g., in a subwindow); it remains otherwise
independent.
So, yes, as both #Quentin and #Sinan said, it would require the embedded .html file to be a complete, valid .html file. And, no, it would not become part of the DOM of the original document.
Thanks to everyone for their prompt assistance. The StackOverflow community continues to amaze me.
<object> is a way to include a generic media object.
An HTML document is an example of such.
The HTML spec doesn't describe a means to provide a fragment of HTML to a browser, only a complete document. There is no standard MIME type for a fragment of HTML.
Therefore: You should use complete HTML documents.
That said, if you are going down that route, you would almost certainly be better off using <iframe> which has a much more featureful and robust set of APIs and documentation surrounding it.
How does this appear within the DOM of the original document, if it appears within that DOM at all?
As an object element. The child nodes of which are whatever alternative content you provide between the start and end tag.
Or are the two documents treated entirely separately?
Yes, much like an iframe.
<object> in HTML5 and <object> in HTML4.
The object element represents external content, which, depending on the type of the content, will either be treated as an image, as a nested browsing context, or as external content to be processed by a plugin.
Motivation from HTML4:
Previous versions of HTML allowed authors to include images (via IMG) and applets (via APPLET). These elements have several limitations:
They fail to solve the more general problem of how to include new and future media types.
The APPLET element only works with Java-based applets. This element is deprecated in favor of OBJECT.
They pose accessibility problems.
To address these issues, HTML 4 introduces the OBJECT element, which offers an all-purpose solution to generic object inclusion. The OBJECT element allows HTML authors to specify everything required by an object for its presentation by a user agent: source code, initial values, and run-time data. In this specification, the term "object" is used to describe the things that people want to place in HTML documents; other commonly used terms for these things are: applets, plug-ins, media handlers, etc. (emphasis mine)
So, basically, <object> elements are pretty generic. The only real condition is that there needs to be some kind of functionality on the client side to render the element.
For example:
<object data="test.html" height="50" width="50"></object>
renders the contents of test.html in a tiny area (no scaling!) with Firefox whereas links just displays [OBJ].
Embedded Content explains what happens when an <object> element is encountered.
Due to the algorithm above, the contents of object elements act as fallback content, used only when referenced resources can't be shown (e.g. because it returned a 404 error). This allows multiple object elements to be nested inside each other, targeting multiple user agents with different capabilities, with the user agent picking the first one it supports. (emphasis mine)
I believe that answers the question of how the <object> enters the DOM. If it were any other way, for example, element ids in included documents could trample on the DOM of the host page.
Regardless of what capabilities you observe in current user agents, you should ensure included HTML documents are well-structured, and valid.
Further down, consider the included example:
In this example, an HTML page is embedded in another using the object element.
<figure>
<object data="clock.html"></object>
<figcaption>My HTML Clock</figcaption>
</figure>
Note the example refers to an HTML page — not a fragment.

CSS selector fragment support

Fragments (or hashes) in URL are widely used to specify some specific fragment in a document.
For example, the fragment below
http://example.com/page.pnp#<fragment>
Usually references something like <div id="<fragment>" /> or <a name="<fragment>" /> in a HTML document.
There is a standard to support CSS selectors as a fragment, like so:
http://example.com/page.pnp#css(<CSS selector>)
Are there any applications using it? Would it be nice for browser to support it? For example, browser could display only the selected fragments of the page or highlight the selected fragments. Or provide an option for developers to highlight the selected fragments with CSS or JS. Can somebody submit it to the relevant browser devs as a feature request?
What are other ways to reference specific content in a HTML page? For example, if I want to comment on some specific element in a HTML page, what are any other ways to specify that position in the document, preferably by using URI, or some other convenient identifier?
The document you link to isn't really a standard; it even says "Unofficial Draft" in the subtitle, and under where it says Status:
This document is merely a public working draft of a potential specification. It has no official standing of any kind and does not represent the support or consensus of any standards organisation.
... so it is completely inappropriate to refer to it as a "standard". A better term for this would be "concept" or "experiment".
That being said, rudimentary implementations exist (or at least, they did at the time it was first published) in the form of browser extensions; you can find links to these in section 8.
AFAIK, though, there hasn't been any activity around this at all after the first few months since the community group for this was formed and I joined. Either it never gained traction or it just wasn't very feasible to implement after all.
For now, as always, fragment identifiers can only point to elements with the respective id attribute, or named anchors. It seems it'll remain that way for the foreseeable future.
For Chrome, There's a Jquery Fragement selector extension:
With the advent of edge extensions it will likely become easy to implement in edge.

Why use Schema.org microdata to mark up web page elements?

I understand why and how to use Schema.org to add microdata to your site, this is not a question about that. The question is why Schema.org has support for certain things that can be marked up with simple HTML5. Among these are
Types
WebPage and WebSite
I can see why WebPage and WebSite would be needed, for example, to reference the page/site of a certain organization in a link, but there's no need to mark up your own page with this—the <html> tag does this.
SiteNavigationElement
Why not just use <nav>?
Table
Just use <table>.
properties
WebPage/mainContentOfPage
<main> element
WebPage/relatedLink
<link> element inside <head>
This answer is primarily about the WebPageElement types (like SiteNavigationElement).
For WebPage, see my answer to the question Implicity of web page structure in Schema.org (tl;dr: it can be useful to provide WebPage, even for the current page).
For WebSite, similar reasons from the answer above apply. HTML doesn’t allow you to state something about the whole site (and, by the way, a Google rich result makes use of this type).
Schema.org is not restricted to HTML5.
Schema.org is a vocabulary which can be used with various syntaxes (like JSON-LD, Microdata, RDFa, Turtle, …), stand-alone or in various host languages (like HTML 4.01, XHTML 1.0/1.1, (X)HTML5, XML, SVG, …). So having other ways to specify that something is (or: is about; or: represents) a site-wide navigation, a table etc. is the exception rather than the rule.
But there can be reasons to use these types even in HTML5 documents, for example:
The HTML5 markup and the annotations from Microdata/RDFa are two "different worlds": a Microdata/RDFa parser is only interested in the annotations, and after successfully parsing a document, the underlying markup is of no relevance anymore (e.g., the information that something was specified in a table element is lost in the Microdata/RDFa layer).
By using types like WebPageElement, you can specify metadata that is not possible to specify in plain HTML5. For example, the author/license/etc. of a table.
You can use these types to specify data about something which does not exist on the current document, e.g., you could say on your personal website that you are the author of a table in Wikipedia.
That said, these are not typical use cases relevant for a broad range of authors. Unless you have a specific reason for using them, you might want to omit them. They are not useful for typical websites. Using them can even be problematic in some cases.
See also my Schema.org issue The purpose of WebPageElement and mainContentOfPage, where I suggested to deprecate WebPageElement and the mainContentOfPage property.
Just use <table>.
You seem to be reading the title of the pages and no further. The <table> tag doesn't have the dozens of special properties listed on that page like isFamilyFriendly or license or timeRequired.
Schema.org microdata is intended to build a standard set of additional, semantic metadata that can be used by automated systems - search engine spiders, parser robots, etc. - to better understand the nature and features of the content.

What is the cite attribute for?

The cite attribute specifies the address of the source of the quoted text, I think, but who uses this information?
For example:
<q cite="http://www.example.com/quote">
<p>“A quote”</p>
<footer>—Person quoted</footer>
</q>
The source of the quoted text isn't visible to the end-user in a normal browser, so who does use this information, and how?
First, it's not only blockquote where you can use the cite attribute.
You can use the cite attribute on the following elements also:
<blockquote>
<del>
<ins>
<q>
Why would one use cite in above elements?
To point to where the content is taken from, or change or deletion is referred.
Here is what w3.org says,
User agents may allow users to follow such citation links, but they
are primarily intended for private use (e.g: by server-side scripts
collecting statistics about a site's edits), not for readers
Now, the question, who uses it?
The cite attribute is used to identify the online source of the quotation in the form of a URI (for example, "http://sourcewebsite.doc/document.html").
The value of the cite attribute isn't rendered on screen (although this potentially useful meta data could be extracted and written back into the webpage through the magic of DOM Scripting).
As such, browser support for this attribute is marked as none, but because it has other potential uses (for search engine indexing, retrieval via DOM scripting, and more) and there is the likelihood of improved native support being provided for the attribute in future browser versions, you should use the cite attribute when you use the above elements.
So, currently no one uses it, but in future maybe used in user-agent or my search engines, so better to use it.
Both the <cite> tag and the cite attribute are for semantic purposes, which means that they are simply for giving a website more "meaning". For example, I could use a <div> tag for a quote, rather than using a <blockquote> tag, but this provides less meaning to the browser, and hence using <blockquote> is recommended for quotes.
The same is with the <cite> tag and cite attributes. As per the MDN definition for the cite attribute (link here):
Use the cite attribute on a or element to reference
an online resource for a source.
"so who does use this information, and how?" - I believe that search engines (e.g. Google) would use this information to show potential links between documents. If you think about this it is a major point. Check out the image below:
Notice how it shows the "Samsung Group" information box on the right. The guys who work at Google don't write this information - rather, it is sourced from Wikipedia. However, this information would be of greater relevance to the search "samsung" when this information is also written on other websites, with the cite attribute linking this information to Wikipedia (hence increasing the relevancy of Wikipedia). This is why Wikipedia's information is used here, and not some primary school's website regarding Samsung phones.
The cite attribute simply provides more meaning to the website. Tim Berners-Lee has described the semantic web as a component of "Web 3.0" - in other words, many components of the updating HTML language are simply to provide more meaning onto the webpage, as a step closer to Web 3.0.
TL;DR - in simpler terms, the cite attribute is just to provide more meaning to the web page, and may be used for search engines for better web linkage.
W3C has this to say:
The value of this attribute is a URI that designates a source document or message. This attribute is intended to give information about the source from which the quotation was borrowed.
It's not visible and I can't think of anywhere it's used except perhaps by search engines.
It is meant to be used by machine which collect and arrange data eg. search engines, but it can be used by any machine. It is meant to make webpages more systematic to be read by machine. As they can not understand which part of text represent citation and quote based on only context.
you can look up Semantic Web for more information.
http://en.wikipedia.org/wiki/Semantic_Web
Yes, the source of the quotation isn't visible to end user. So it's just a reference to the source.
Definition from WHATWG.ORG:
Content inside a q element must be
quoted from another source, whose
address, if it has one, may be cited
in the cite attribute. The source may
be fictional, as when quoting
characters in a novel or screenplay.
If the cite attribute is present, it
must be a valid URL potentially
surrounded by spaces.
Quoted from W3Schools:
The cite attribute is not supported by any of the major browsers.
However, search engines may use it to get more information about the quotation.
http://www.w3schools.com/tags/att_q_cite.asp
It's just another meta data chunk that can be used by server side scripts to collect statistics or by front end developpers to add functionnalities (they can choose to print the source, allow to access the original source, etc...).
It's just a good practice to have the original source written somewhere although it is actually not very useful for the end user.