WHATWG Wiki - User contributions [en]

Link Icons

2009-01-02T23:47:45Z

Josh Triplett: /* Use Cases */ Fix numbered list.

An icon for a page provides a strong visual cue which users can associate with that page. Page icons typically appear in various places in the user interface of a graphical user agent, such as the address bar, tabs, and bookmark icons. However, no way exists to associate an icon with a linked page, only with the current page. User agents could make use of such icons in various useful ways, such as when bookmarking the link, and could also simply display the icons next to the link.

== Use Cases ==

# Bookmarking links: if a user bookmarks a link, the bookmark will not have any icon associated with it, or will use the generic bookmark icon. By contrast, bookmarking the current page includes the page's icon in the bookmark, providing a strong visual cue.
# Identifying link targets: a site may want to display icons next to links as a stronger visual cue to the user about the target of the link. A user agent might choose to display these icons next to the link, or in a status bar next to the target URI. Alternatively, a user agent might choose not to display the icons at all, or only display them for some types of URIs.
# Identifying link types: a site may want to display icons next to links to distinguish different types of links, such as external links, mailto links, or links to documents of a given type.

=== Current Limitations ===

No markup currently exists to associate an icon with a link for the purposes of a bookmark. User agents could choose to guess in various ways, such as by using the icon of the target domain or target page if known, or by using the icon of the current page for links within the same site. A user agent could even choose to fetch the target page to look for icon metadata. However, these guesses can easily fail or find an incorrect icon, and may produce undesirable page requests. Furthermore, links to some URI schemes would not even allow these forms of guessing; for instance, consider javascript: (as used in bookmarklets), mailto: , tel: , or sips: .

For identifying links, a site can currently include the icon as an <code>img</code> element child of the <code>a</code> element. However, this markup provides no semantic information associating the icon with the target of the link. Furthermore, this markup does not provide a user agent with enough information to hide the link icons, display them selectively, or display them in a different location.

=== Current Usage and Workarounds ===

Pages which offer useful bookmarklets typically provide them in the form of links, and suggest that users drag those links to their bookmarks toolbar/menu or right-click on them and choose to bookmark them. The link text typically becomes the bookmark name, and the target URI becomes the bookmark URI. However, bookmarklets added in this manner do not have icons associated with them. Various pages document this deficiency, and provide instructions for users to set bookmark icons themselves (often a complicated process, especially if the user agent does not provide any UI to set an icon).

Browser extensions exist for the sole purpose of helping a user set bookmark icons. For instance, [https://addons.mozilla.org/en-US/firefox/addon/7849 Favicon Picker 3] and [https://addons.mozilla.org/en-US/firefox/addon/3176 Favicon Picker 2]

Browser extensions also exist to add icons next to links in certain contexts. For instance, the [https://addons.mozilla.org/en-US/firefox/addon/4676 Google Icon], [https://addons.mozilla.org/en-US/firefox/addon/8989 Favicon Addict], and [https://addons.mozilla.org/en-US/firefox/addon/8545 Search with favicons] extensions add icons to search results.

Several pages use icons to identify link targets, or suggest ways of doing so. For examples of this (not necessarily good or bad examples), see http://www.askthecssguy.com/2006/12/hyperlink_cues_with_favicons.html , http://exscale.se/archives/2008/02/27/jquery-external-link-favicons-plugin/ , and http://ancientgeeks.wordpress.com/2007/08/06/automatic-favicons-for-external-links/ . Note that all of these use JavaScript; a pure HTML5 solution seems highly preferable.

Numerous sites use icons to identify link types; for instance, MediaWiki wikis such as Wikipedia and this wiki show an icon next to external links and a different icon next to https links. Numerous pages also suggest ways to use icons to identify link types. For a few examples, see http://www.psyked.co.uk/css/auto-matic-link-icons.htm , http://userstyles.org/styles/504 , http://www.css3.info/using-css-3-selectors-to-apply-link-icons/ , http://pooliestudios.com/projects/iconize/ , and http://www.vision.to/add-a-small-icon-to-your-links-css-only.php .

=== Benefits ===

Adding new markup to specify link icons would give user agents the semantic information they need to associate an icon with the target of a link. This semantic information gives user agents the ability to use the icon in various interesting ways, such as displaying the icon with bookmarks, displaying the icon together with the target URI in the status bar, perhaps displaying the icon in the address bar before the target page loads, hiding the icon, showing the icon in the tooltip used for the title attribute, displaying the icon in menu items for the right-click menu.

=== Requests for this Feature ===

* <cite>[http://74.125.113.132/search?q=cache:Bw-pI9b1BqEJ:community.valuesofn.com/stikkit/index.php%3Ftopic%3D415.0%3Bwap2+bookmarklet+icon&hl=en&ct=clnk&cd=10&gl=us&client=iceweasel-a stikkit bookmarklet icon?]</cite> <blockquote>Is there any chance that there could be an icon for the stikkit bookmarklet? I tend to have only the favicon on my bookmark toolbar and no text.</blockquote>
* <cite>[http://www.tech-recipes.com/rx/3032/google_chrome_how_to_change_icons_on_the_bookmarks_bar/ Google Chrome: How to Change Icons on the Bookmarks bar]</cite> <blockquote>I added quite a few bookmarklets to my Bookmarks bar and was unhappy with the same default icon that showed for each one. There are no settings currently available within Chrome to change the icon, but there is a way to fix them that works quite well. [...] First, you’ll need to download and install the free SQLite Database browser. [...]</blockquote>
* <cite>[http://www.smashingmagazine.com/2007/01/24/bookmarklets-favelets-and-snippets/#comment-169077 comment on "Bookmarklets, Favelets and Snippets"]</cite> <blockquote>I am curious if there is any way to show the “favicon” for bookmarklets (Firefox)? I always see the ugly “blank page” icon next to my bookmarklets.</blockquote>

== Proposed Solutions ==

=== My Solution ===

Add a new attribute to <code>img</code> elements, named <code>linkrel</code> or similar, which has as its value a space-separated list of relationships between the <code>img</code> and its containing <code>a</code> element. As with the <code>rel</code> attribute on <code>a</code> and <code>link</code> elements, many possible values exist for this attribute, but the use cases above require only two:

* The value <code>target</code> means that the image represents an icon for the target page. For instance, an http link might use the logo for the target page, while a mailto link for a person might use a small image of the person's face. Such an icon should accurately identify the link target even in the absence of any other context. A graphical user agent may use an icon of type <code>target</code> as the bookmark icon if the user bookmarks the link, and may display the icon in the link or wherever it currently displays the target URI.
* The value <code>type</code> means that the image represents an icon for the type of the link target. For instance, a mailto link might use an envelope icon, while a link to a music file might use a musical note icon. An icon of type <code>type</code> will not work well as the icon for a bookmark; however, it might still work better than the default bookmark icon, so a user agent might choose to use it if no icon of type <code>target</code> exists.

Optional extensions to this solution:

* Additional <code>linkrel</code> types. For instance, a <code>nav</code> value might make sense, to describe images which only make sense as navigation for the current page, such as a "next" link with an arrow pointing to the right.
* A way for an <code>img</code> to reference an <code>a</code> element other than by making the <code>img</code> a child of that element; for instance, an attribute similar to the <code>for</code> attribute of <code>label</code>. This adds complexity for a case that seems unlikely to come up in practice.
* A better name than <code>linkrel</code>.
* Ways to manipulate this via CSS.
* Ways to manipulate this via JavaScript.

==== Processing Model ====
Because the markup for this proposal uses an <code>img</code> element (rather than an attribute on the <code>a</code> element, for example), a user agent may choose do nothing other than ignoring the <code>linkrel</code> attribute. Such a user agent would then render the link icon inline together with the link as many browsers currently do.

TODO: Detailed processing model.

==== Limitations ====

==== Implementation ====

==== Adoption ====

[[Category:Feature Request]]

Link Icons

2009-01-02T23:47:21Z

Josh Triplett: Add initial link icons proposal.

An icon for a page provides a strong visual cue which users can associate with that page. Page icons typically appear in various places in the user interface of a graphical user agent, such as the address bar, tabs, and bookmark icons. However, no way exists to associate an icon with a linked page, only with the current page. User agents could make use of such icons in various useful ways, such as when bookmarking the link, and could also simply display the icons next to the link.

== Use Cases ==

# Bookmarking links: if a user bookmarks a link, the bookmark will not have any icon associated with it, or will use the generic bookmark icon. By contrast, bookmarking the current page includes the page's icon in the bookmark, providing a strong visual cue.

# Identifying link targets: a site may want to display icons next to links as a stronger visual cue to the user about the target of the link. A user agent might choose to display these icons next to the link, or in a status bar next to the target URI. Alternatively, a user agent might choose not to display the icons at all, or only display them for some types of URIs.

# Identifying link types: a site may want to display icons next to links to distinguish different types of links, such as external links, mailto links, or links to documents of a given type.

=== Current Limitations ===

No markup currently exists to associate an icon with a link for the purposes of a bookmark. User agents could choose to guess in various ways, such as by using the icon of the target domain or target page if known, or by using the icon of the current page for links within the same site. A user agent could even choose to fetch the target page to look for icon metadata. However, these guesses can easily fail or find an incorrect icon, and may produce undesirable page requests. Furthermore, links to some URI schemes would not even allow these forms of guessing; for instance, consider javascript: (as used in bookmarklets), mailto: , tel: , or sips: .

For identifying links, a site can currently include the icon as an <code>img</code> element child of the <code>a</code> element. However, this markup provides no semantic information associating the icon with the target of the link. Furthermore, this markup does not provide a user agent with enough information to hide the link icons, display them selectively, or display them in a different location.

=== Current Usage and Workarounds ===

Pages which offer useful bookmarklets typically provide them in the form of links, and suggest that users drag those links to their bookmarks toolbar/menu or right-click on them and choose to bookmark them. The link text typically becomes the bookmark name, and the target URI becomes the bookmark URI. However, bookmarklets added in this manner do not have icons associated with them. Various pages document this deficiency, and provide instructions for users to set bookmark icons themselves (often a complicated process, especially if the user agent does not provide any UI to set an icon).

Browser extensions exist for the sole purpose of helping a user set bookmark icons. For instance, [https://addons.mozilla.org/en-US/firefox/addon/7849 Favicon Picker 3] and [https://addons.mozilla.org/en-US/firefox/addon/3176 Favicon Picker 2]

Browser extensions also exist to add icons next to links in certain contexts. For instance, the [https://addons.mozilla.org/en-US/firefox/addon/4676 Google Icon], [https://addons.mozilla.org/en-US/firefox/addon/8989 Favicon Addict], and [https://addons.mozilla.org/en-US/firefox/addon/8545 Search with favicons] extensions add icons to search results.

Several pages use icons to identify link targets, or suggest ways of doing so. For examples of this (not necessarily good or bad examples), see http://www.askthecssguy.com/2006/12/hyperlink_cues_with_favicons.html , http://exscale.se/archives/2008/02/27/jquery-external-link-favicons-plugin/ , and http://ancientgeeks.wordpress.com/2007/08/06/automatic-favicons-for-external-links/ . Note that all of these use JavaScript; a pure HTML5 solution seems highly preferable.

Numerous sites use icons to identify link types; for instance, MediaWiki wikis such as Wikipedia and this wiki show an icon next to external links and a different icon next to https links. Numerous pages also suggest ways to use icons to identify link types. For a few examples, see http://www.psyked.co.uk/css/auto-matic-link-icons.htm , http://userstyles.org/styles/504 , http://www.css3.info/using-css-3-selectors-to-apply-link-icons/ , http://pooliestudios.com/projects/iconize/ , and http://www.vision.to/add-a-small-icon-to-your-links-css-only.php .

=== Benefits ===

Adding new markup to specify link icons would give user agents the semantic information they need to associate an icon with the target of a link. This semantic information gives user agents the ability to use the icon in various interesting ways, such as displaying the icon with bookmarks, displaying the icon together with the target URI in the status bar, perhaps displaying the icon in the address bar before the target page loads, hiding the icon, showing the icon in the tooltip used for the title attribute, displaying the icon in menu items for the right-click menu.

=== Requests for this Feature ===

* <cite>[http://74.125.113.132/search?q=cache:Bw-pI9b1BqEJ:community.valuesofn.com/stikkit/index.php%3Ftopic%3D415.0%3Bwap2+bookmarklet+icon&hl=en&ct=clnk&cd=10&gl=us&client=iceweasel-a stikkit bookmarklet icon?]</cite> <blockquote>Is there any chance that there could be an icon for the stikkit bookmarklet? I tend to have only the favicon on my bookmark toolbar and no text.</blockquote>
* <cite>[http://www.tech-recipes.com/rx/3032/google_chrome_how_to_change_icons_on_the_bookmarks_bar/ Google Chrome: How to Change Icons on the Bookmarks bar]</cite> <blockquote>I added quite a few bookmarklets to my Bookmarks bar and was unhappy with the same default icon that showed for each one. There are no settings currently available within Chrome to change the icon, but there is a way to fix them that works quite well. [...] First, you’ll need to download and install the free SQLite Database browser. [...]</blockquote>
* <cite>[http://www.smashingmagazine.com/2007/01/24/bookmarklets-favelets-and-snippets/#comment-169077 comment on "Bookmarklets, Favelets and Snippets"]</cite> <blockquote>I am curious if there is any way to show the “favicon” for bookmarklets (Firefox)? I always see the ugly “blank page” icon next to my bookmarklets.</blockquote>

== Proposed Solutions ==

=== My Solution ===

Add a new attribute to <code>img</code> elements, named <code>linkrel</code> or similar, which has as its value a space-separated list of relationships between the <code>img</code> and its containing <code>a</code> element. As with the <code>rel</code> attribute on <code>a</code> and <code>link</code> elements, many possible values exist for this attribute, but the use cases above require only two:

* The value <code>target</code> means that the image represents an icon for the target page. For instance, an http link might use the logo for the target page, while a mailto link for a person might use a small image of the person's face. Such an icon should accurately identify the link target even in the absence of any other context. A graphical user agent may use an icon of type <code>target</code> as the bookmark icon if the user bookmarks the link, and may display the icon in the link or wherever it currently displays the target URI.
* The value <code>type</code> means that the image represents an icon for the type of the link target. For instance, a mailto link might use an envelope icon, while a link to a music file might use a musical note icon. An icon of type <code>type</code> will not work well as the icon for a bookmark; however, it might still work better than the default bookmark icon, so a user agent might choose to use it if no icon of type <code>target</code> exists.

Optional extensions to this solution:

* Additional <code>linkrel</code> types. For instance, a <code>nav</code> value might make sense, to describe images which only make sense as navigation for the current page, such as a "next" link with an arrow pointing to the right.
* A way for an <code>img</code> to reference an <code>a</code> element other than by making the <code>img</code> a child of that element; for instance, an attribute similar to the <code>for</code> attribute of <code>label</code>. This adds complexity for a case that seems unlikely to come up in practice.
* A better name than <code>linkrel</code>.
* Ways to manipulate this via CSS.
* Ways to manipulate this via JavaScript.

==== Processing Model ====
Because the markup for this proposal uses an <code>img</code> element (rather than an attribute on the <code>a</code> element, for example), a user agent may choose do nothing other than ignoring the <code>linkrel</code> attribute. Such a user agent would then render the link icon inline together with the link as many browsers currently do.

TODO: Detailed processing model.

==== Limitations ====

==== Implementation ====

==== Adoption ====

[[Category:Feature Request]]

Feature Proposals

2009-01-02T14:58:04Z

Josh Triplett: /* Document Markup */ Change name of link icon proposal.

This document contains a list of the problems for which feature requests have been made. Linked problem pages contain the document of the problem and their relevant solutions. Obviously, we want to keep HTML as simple as possible. That means not everyone will get what they want. Having good documentation for the problems at hand will help all of us work out what is most important.

== Guidelines ==

Before proposing a feature, please read [http://blog.whatwg.org/proposing-features Proposing features]. If you want to add a feature request, start by copying the [[Problem Solving]] template page onto a new page and fill out as much information as you can.

You don't have to provide detailed answers for everything straight away. The most important information to provide at first is the problem description. Once we have detailed descriptions, use cases and an understanding of the limitations with existing markup, we can then begin to discuss the best way in which to address the problems and work out more of the more technical details.

== Document Markup ==
* [[Image Caption]]
* [[Layout tables]]
* [[Drag'n'Drop Uploads]]
* [[New Vocabularies]], [[Constraints for New Vocabularies]]
* [[Generic Metadata Mechanisms]]
* [[Link Icons]]

== DOM Scripting ==
* [[Text in Canvas]]

== Security ==
* [[Link Hashes]]
* [[Digital Signatures]]

== Other ==

This list of features needs to be sorted out. They've come from all the [http://del.icio.us/lachlan.hunt/WHATWG feedback provided on blogs] over the past few weeks.

* Don't render quotation marks around <code>q</code> elements.
* Make form validation easier
** <code>required</code> attribute
** <code>maxlength</code> attribute for textarea
** <code>pattern</code> attribute
** <code>min</code>
** <code>max</code>
* New Form Controls
** Search fields
** Combo boxes
** Date/Time
** E-mail
** Int
** Long
** Unsigned
** Float
** Number
** Currency
** URL
* WYSIWIG Editor (<code>contentEditable</code>)
* Placeholder attribute
* Captions for images
* Bring back the <code>start</code> and <code>value</code> attributes for ordered lists.
* Bring back the <code>menu</code> element
* Require XHTML-link syntax for HTML
* Caption/label/list header for lists
* Include the <code>role</code> attribute.
* Allow <code>href</code> on all elements
* Make it easier to mark up blocks of code
* Allow block level elements inside paragraphs
* “a tag that could hold "bad grammar" and not have any effect on the validation (sort of like a document.write from JavaScript) and would terminate all unclosed items at the end of the element (like TDs tend to do).”
* <code>blink</code>!
* Fix the <code>object</code> element.
* Unify <code>img</code>, <code>object</code>, </code>embed</code> and <code>iframe</code> into a single element
* Headers and footers
* A mechanism to include content from an external source (e.g. <code>include</code>, perhaps like XInclude)
* A <code>corner</code> element (presumably for making rounded corners)
* Markup for advertisements
* Easier column layouts
* A <code>foot</code> element for containing scripts at the bottom of the page, or something to help deal with cross-browser load events.
* Key Generation/Certificate management (The <code>keygen</code> element)

[[Category:Feature Request]]

Feature Proposals

2009-01-02T14:57:34Z

Josh Triplett: /* Document Markup */ Change name of link icon proposal.

This document contains a list of the problems for which feature requests have been made. Linked problem pages contain the document of the problem and their relevant solutions. Obviously, we want to keep HTML as simple as possible. That means not everyone will get what they want. Having good documentation for the problems at hand will help all of us work out what is most important.

== Guidelines ==

Before proposing a feature, please read [http://blog.whatwg.org/proposing-features Proposing features]. If you want to add a feature request, start by copying the [[Problem Solving]] template page onto a new page and fill out as much information as you can.

You don't have to provide detailed answers for everything straight away. The most important information to provide at first is the problem description. Once we have detailed descriptions, use cases and an understanding of the limitations with existing markup, we can then begin to discuss the best way in which to address the problems and work out more of the more technical details.

== Document Markup ==
* [[Image Caption]]
* [[Layout tables]]
* [[Drag'n'Drop Uploads]]
* [[New Vocabularies]], [[Constraints for New Vocabularies]]
* [[Generic Metadata Mechanisms]]
* [[Link Icon]]

== DOM Scripting ==
* [[Text in Canvas]]

== Security ==
* [[Link Hashes]]
* [[Digital Signatures]]

== Other ==

This list of features needs to be sorted out. They've come from all the [http://del.icio.us/lachlan.hunt/WHATWG feedback provided on blogs] over the past few weeks.

* Don't render quotation marks around <code>q</code> elements.
* Make form validation easier
** <code>required</code> attribute
** <code>maxlength</code> attribute for textarea
** <code>pattern</code> attribute
** <code>min</code>
** <code>max</code>
* New Form Controls
** Search fields
** Combo boxes
** Date/Time
** E-mail
** Int
** Long
** Unsigned
** Float
** Number
** Currency
** URL
* WYSIWIG Editor (<code>contentEditable</code>)
* Placeholder attribute
* Captions for images
* Bring back the <code>start</code> and <code>value</code> attributes for ordered lists.
* Bring back the <code>menu</code> element
* Require XHTML-link syntax for HTML
* Caption/label/list header for lists
* Include the <code>role</code> attribute.
* Allow <code>href</code> on all elements
* Make it easier to mark up blocks of code
* Allow block level elements inside paragraphs
* “a tag that could hold "bad grammar" and not have any effect on the validation (sort of like a document.write from JavaScript) and would terminate all unclosed items at the end of the element (like TDs tend to do).”
* <code>blink</code>!
* Fix the <code>object</code> element.
* Unify <code>img</code>, <code>object</code>, </code>embed</code> and <code>iframe</code> into a single element
* Headers and footers
* A mechanism to include content from an external source (e.g. <code>include</code>, perhaps like XInclude)
* A <code>corner</code> element (presumably for making rounded corners)
* Markup for advertisements
* Easier column layouts
* A <code>foot</code> element for containing scripts at the bottom of the page, or something to help deal with cross-browser load events.
* Key Generation/Certificate management (The <code>keygen</code> element)

[[Category:Feature Request]]

Feature Proposals

2009-01-02T14:46:54Z

Josh Triplett: /* Document Markup */ Add link for new proposal to specify the bookmark icon for a link.

This document contains a list of the problems for which feature requests have been made. Linked problem pages contain the document of the problem and their relevant solutions. Obviously, we want to keep HTML as simple as possible. That means not everyone will get what they want. Having good documentation for the problems at hand will help all of us work out what is most important.

== Guidelines ==

Before proposing a feature, please read [http://blog.whatwg.org/proposing-features Proposing features]. If you want to add a feature request, start by copying the [[Problem Solving]] template page onto a new page and fill out as much information as you can.

You don't have to provide detailed answers for everything straight away. The most important information to provide at first is the problem description. Once we have detailed descriptions, use cases and an understanding of the limitations with existing markup, we can then begin to discuss the best way in which to address the problems and work out more of the more technical details.

== Document Markup ==
* [[Image Caption]]
* [[Layout tables]]
* [[Drag'n'Drop Uploads]]
* [[New Vocabularies]], [[Constraints for New Vocabularies]]
* [[Generic Metadata Mechanisms]]
* [[Link Bookmark Icon]]

== DOM Scripting ==
* [[Text in Canvas]]

== Security ==
* [[Link Hashes]]
* [[Digital Signatures]]

== Other ==

This list of features needs to be sorted out. They've come from all the [http://del.icio.us/lachlan.hunt/WHATWG feedback provided on blogs] over the past few weeks.

* Don't render quotation marks around <code>q</code> elements.
* Make form validation easier
** <code>required</code> attribute
** <code>maxlength</code> attribute for textarea
** <code>pattern</code> attribute
** <code>min</code>
** <code>max</code>
* New Form Controls
** Search fields
** Combo boxes
** Date/Time
** E-mail
** Int
** Long
** Unsigned
** Float
** Number
** Currency
** URL
* WYSIWIG Editor (<code>contentEditable</code>)
* Placeholder attribute
* Captions for images
* Bring back the <code>start</code> and <code>value</code> attributes for ordered lists.
* Bring back the <code>menu</code> element
* Require XHTML-link syntax for HTML
* Caption/label/list header for lists
* Include the <code>role</code> attribute.
* Allow <code>href</code> on all elements
* Make it easier to mark up blocks of code
* Allow block level elements inside paragraphs
* “a tag that could hold "bad grammar" and not have any effect on the validation (sort of like a document.write from JavaScript) and would terminate all unclosed items at the end of the element (like TDs tend to do).”
* <code>blink</code>!
* Fix the <code>object</code> element.
* Unify <code>img</code>, <code>object</code>, </code>embed</code> and <code>iframe</code> into a single element
* Headers and footers
* A mechanism to include content from an external source (e.g. <code>include</code>, perhaps like XInclude)
* A <code>corner</code> element (presumably for making rounded corners)
* Markup for advertisements
* Easier column layouts
* A <code>foot</code> element for containing scripts at the bottom of the page, or something to help deal with cross-browser load events.
* Key Generation/Certificate management (The <code>keygen</code> element)

[[Category:Feature Request]]