<h1id="dev_page_title">A Guide to Good Templates</h1>
<divid="dev_page_content"><!-- scroll_nav -->
<divclass="dev_side_image">
<ahref="/file/811140067/3/6oS3A6aSzxU.261217/1d6f75b81ed67c983a"target="_blank"><imgsrc="/file/811140890/2/3WnXjPnynwU.52493/709f815bf5f24bff9c"title="Instant View Platform. Click for hi-res picture">
</a></div>
<p>This page lists <ahref="#general-rules">general rules</a> and <ahref="#perfect-templates">detailed clarifications</a> for creating good Instant View templates for news articles.</p>
<p>For more info on templates, see our <ahref="/">Introduction</a> and <ahref="/samples/">Sample Templates</a>.</p>
<p>Instant View templates must meet these five basic requirements:</p>
<h4><aclass="anchor-link"href="#1-ivs-must-only-be-generated-for-pages-that-need-them"><iclass="anchor-icon"></i></a><aclass="anchor"name="1-ivs-must-only-be-generated-for-pages-that-need-them"></a>1. IVs must only be generated for pages that need them</h4>
<p>Instant View pages work best with relatively <strong>static articles</strong>. Dynamic pages (such as the main page of a news site) that are constantly refreshed with new links and media don't need IV.</p>
<p>Templates should <strong>only</strong> generate IV pages for <em>articles</em> and should not affect service areas of websites, as well as any other sections unsuitable for IV. IV pages should <strong>not</strong> be generated for articles that have content which is not supported in IV since this would result in unacceptable loss of information (e.g., IV pages don't support dynamic maps — if you generate an IV page for a wiki article with a dynamic map, the IV version will be missing a key element). </p>
<h4><aclass="anchor-link"href="#2-all-essential-content-must-be-preserved"><iclass="anchor-icon"></i></a><aclass="anchor"name="2-all-essential-content-must-be-preserved"></a>2. All essential content must be preserved</h4>
<p>IV pages should show the entire text of the article, along with all its formatting, media, and embedded content. This includes headings, subheadings, quotes, captions, photos, videos, links, etc.</p>
<h4><aclass="anchor-link"href="#3-unnecessary-elements-must-be-removed"><iclass="anchor-icon"></i></a><aclass="anchor"name="3-unnecessary-elements-must-be-removed"></a>3. Unnecessary elements must be removed</h4>
<p>IV pages should display only the source’s <em>content</em>– removing all interface elements, advertisments and irrelevant embedded material.</p>
<h4><aclass="anchor-link"href="#4-template-must-process-all-the-pages-it-covers"><iclass="anchor-icon"></i></a><aclass="anchor"name="4-template-must-process-all-the-pages-it-covers"></a>4. Template must process all the pages it covers</h4>
<p>Pages with irregular elements should be processed correctly. All media, embeds, quotes and separators should be properly displayed.</p>
<h4><aclass="anchor-link"href="#5-no-extraneous-info-may-be-added"><iclass="anchor-icon"></i></a><aclass="anchor"name="5-no-extraneous-info-may-be-added"></a>5. No extraneous info may be added</h4>
<p> Any attempt to add content that is not present on the original page will cause your template to be rejected.</p>
<p>You may include the username of websites’<strong>official</strong> channels in Instant View templates. The username is assigned to the <ahref="https://instantview.telegram.org/docs#instant-view-format">channel property</a>, and to be considered official, the channel must be labeled as such by the company or person who published it (on its website or social media).</p>
<blockquote>
<p>More detailed <ahref="#perfect-templates">criteria and clarifications</a> are available below.</p>
<p>You can submit your template for review as soon as it covers a sufficient number of articles. Make sure you've enabled <ahref="https://instantview.telegram.org/#tracking-changes"><strong>Track Changes</strong></a> for at least <strong>10-15</strong> different pages on the target website and that all IV pages are generated correctly. </p>
<p>When ready, simply tap <strong>Submit Template</strong> next to a template in the <ahref="/my">My Templates</a> section:</p>
<p><strong>Anyone</strong> can check how well Instant View templates process articles on their respective websites, and may submit feedback using the <strong>Report Issue</strong> button.</p>
<p>Click to select and highlight incorrectly parsed blocks in the source page or in the Instant View result and provide a detailed explanation of what is wrong (check the <ahref="#perfect-templates">criteria below</a> for ideas). The author of the template will be able to see all issues, fix and resubmit their work.</p>
<p>To make it easier to report issues in Instant View templates, we’ve compiled this list of characteristics that make a <strong>perfect template</strong>. Please use the list below as a reference when looking for issues in templates.</p>
<h3><aclass="anchor-link"href="#1-iv-targets-must-generate"><iclass="anchor-icon"></i></a><aclass="anchor"name="1-iv-targets-must-generate"></a>1. IV Targets: Must Generate</h3>
<p>Templates must generate Instant View pages for all relevant pages on the target website.</p>
<p><strong>1.1. Pages with static article-like content</strong></p>
<ul>
<li>News articles</li>
<li>Blog posts</li>
<li>Guides</li>
<li>Wiki entries</li>
<li>Documentation</li>
<li>Etc.</li>
</ul>
<blockquote>
<p><strong>Tip:</strong> It may be a good idea to identify a common feature of all the IV-positive pages and add rules so that the template only applies to them. Note that these pages only need IV pages if their essential content is supported in the IV format — otherwise, see <ahref="#2-3-pages-featuring-content-not-supported-by-the-iv-format">2.3</a>.</p>
</blockquote>
<h3><aclass="anchor-link"href="#2-iv-targets-must-not-generate"><iclass="anchor-icon"></i></a><aclass="anchor"name="2-iv-targets-must-not-generate"></a>2. IV Targets: Must NOT Generate</h3>
<p>Templates must not generate Instant View content for pages of the following types:</p>
<h4><aclass="anchor-link"href="#2-1-pages-with-dynamic-content"><iclass="anchor-icon"></i></a><aclass="anchor"name="2-1-pages-with-dynamic-content"></a>2.1. Pages with dynamic content</h4>
<ul>
<li>Dynamically updated lists of articles</li>
<li>Catalogs</li>
<li>Forum threads</li>
<li>Search pages and search results</li>
<li>Etc.</li>
</ul>
<blockquote>
<p><strong>Tip:</strong> IV pages are cached. As articles get older, their cached IV pages update less frequently. Any pages that update content in real time would subsequently display outdated IV pages to users — which is unacceptable.</p>
</blockquote>
<h4><aclass="anchor-link"href="#2-2-pages-that-require-significant-interaction"><iclass="anchor-icon"></i></a><aclass="anchor"name="2-2-pages-that-require-significant-interaction"></a>2.2. Pages that require significant interaction</h4>
<ul>
<li>Service areas of websites, such as Contact pages with forms</li>
<li>Store areas of websites, such as pages where users can buy products</li>
<li>Etc.</li>
</ul>
<blockquote>
<p><strong>Tip:</strong> While it's possible to modify interactive components of a page into simple links, the IV format was primarily designed to allow Telegram users to enjoy web content in a quick and uniform way. Interacting with websites, buying things, writing reviews, etc. are outside of the current scope for IVs. </p>
</blockquote>
<h4><aclass="anchor-link"href="#2-3-pages-featuring-content-not-supported-by-the-iv-format"><iclass="anchor-icon"></i></a><aclass="anchor"name="2-3-pages-featuring-content-not-supported-by-the-iv-format"></a>2.3. Pages featuring content not supported by the IV format</h4>
<ul>
<li>Pages with unsupported embedded content that can't be displayed</li>
<li>Any other unsupported content</li>
</ul>
<blockquote>
<p><strong>Tip:</strong> The rule is simple. If an essential part of an article is not available in the Instant View format, an IV page must <strong>not</strong> be generated. In most cases, this will happen automatically but template creators can further protect their templates from data loss by marking any unsupported essential content using the <ahref="/docs#unsupported">@unsupported</a> function. See <ahref="#6-4-2-video-audio-from-unsupported-players">this section</a> for advice on handling unsupported videos.</p>
<p>All essential content must be presented on the Instant View page.</p>
<h4><aclass="anchor-link"href="#3-1-general-properties"><iclass="anchor-icon"></i></a><aclass="anchor"name="3-1-general-properties"></a>3.1. General properties</h4>
<ul>
<li>The title must be shown on the IV page (may need to include the <ahref="#6-1-5-kicker">kicker</a>). </li>
<li>The subtitle must be shown on the IV page if a subtitle exists in the source. </li>
<li>The date of publication must be shown on the IV page if the date of publication is mentioned anywhere in the source (including meta tags).</li>
</ul>
<p><strong>These properties are also essential, but not always present or supported in IV:</strong></p>
<ul>
<li>Author name can be shown on the IV page if an author is specified in the source.</li>
<li>Author name on the IV page can link to the author URL if an author URL is specified in the source. </li>
<li>The main image can be shown as a cover on the IV page if a suitable image exists in the source. </li>
<li><code>NEW</code> Right-To-Left pages (Arabic, Persian, Hebrew, etc.) must have the <code>dir="rtl"</code> attribute set.</li>
</ul>
<blockquote>
<p><strong>Important:</strong> See our <ahref="#6-clarifications"><strong>Clarifications</strong></a> below for tips on how to best process cover images, date and time, author names and URLs, and other tricky elements.</p>
</blockquote>
<h4><aclass="anchor-link"href="#3-2-link-preview"><iclass="anchor-icon"></i></a><aclass="anchor"name="3-2-link-preview"></a>3.2. Link preview</h4>
<ul>
<li>The link preview must include a <strong>photo</strong> if a suitable image or document exist in the source.</li>
<li>If the page has a <em>cover</em> but the metadata contains no image or contains the generic site logo, you <strong>must</strong> use the cover as the photo.</li>
<li>The link preview requires a <strong>description</strong>. </li>
<li>If a short description exists in the source, it must be used for the link preview (OpenGraph descriptions, lead sections, etc.).</li>
<li>If the description in the metadata (routinely) doesn’t describe the contents of the article, your template must create a description using the subtitle or lead section, first paragraph, etc.</li>
<li>The <code>site_name</code> property <strong>must</strong> include the name that users see on the main page of the website (<ahref="https://telegra.ph/Site-name-03-19">examples here</a>).</li>
<li>It is <em>advisable</em> to generate proper link previews even for pages that do not generate an IV.</li>
</ul>
<blockquote>
<p><strong>Note:</strong> Telegram apps will show <code>site_name</code> in the header of the IV. It must match the name that users see on the main page of the website (<ahref="https://telegra.ph/Site-name-03-19">see examples</a>) and it must not contain any additional data. For this reason metadata should not be used blindly. If the main page doesn’t display a site name, use the name they use on social networks (Telegram channels have priority).</p>
<li>All important media (images, videos, slideshows, and other content that is relevant to the article) that exists in the source must be formatted accordingly.</li>
<li>Media captions must be included with the corresponding media, provided they exist in the source and can be reliably identified.</li>
<li>Credits in quotes and media captions must be formatted correctly.</li>
<li>Dividers must be converted to simplified dividers on the IV page if dividers exist in the source. </li>
<li>Anchor links must work properly on IV page if anchor links exist in the source. </li>
</ul>
<blockquote>
<p><strong>Tip:</strong> Check that pages featuring unsupported content do not generate IV pages. In most cases, this will happen automatically, but it is a good idea to confirm this before submitting your template. Mark any unsupported essential content using the <ahref="/docs#unsupported">@unsupported</a> function. See <ahref="#6-4-2-video-audio-from-unsupported-players">this section</a> for advice on handling unsupported videos.</p>
</blockquote>
<h3><aclass="anchor-link"href="#4-content-to-be-removed"><iclass="anchor-icon"></i></a><aclass="anchor"name="4-content-to-be-removed"></a>4. Content to be Removed</h3>
<p>Anything that is not essential to the article in question should be removed from the Instant View page, including:</p>
<ul>
<li>Main navigation bars and menus (essential navigation may be adjusted to simple links)</li>
<li>Top bars</li>
<li>Side bars (can potentially be adjusted and appended to bottom of IV page)</li>
<p>The resulting IV page may not contain any content not present in the original.</p>
<ul>
<li>No signatures or information about the template's author</li>
<li>No extra links or ads of any kind</li>
<li>Etc.</li>
</ul>
<blockquote>
<p><strong>Tip:</strong> You may display the official Telegram channel of the website that published the article at the top of the IV page (by using the <em>channel</em> property). To be considered official, the channel must be labelled as such somewhere on the source website (doesn't have to be on the same page as the original article).</p>
<p>Author name is <strong>required only if</strong> it is presented in the source article in a consistent, clear and identifiable way (in an html block with particular properties), especially if there's a name of an actual person.</p>
<p>In less obvious cases, what the user sees when viewing the original article in a browser has <strong>priority</strong> over invisible meta-information. Names of <strong>actual people</strong> are <strong>always</strong> preferable over entity names like 'team' or the name of the website.</p>
<p>You may omit the author in cases where no name can be seen by a regular user opening the original article in the browser. You may omit the name when there's no identifiable person, only the website's 'team', 'editors', 'website name' etc.</p>
<p>Absent author names for articles in which no author can be easily identified by a regular viewing user are not considered an issue.</p>
<h4><aclass="anchor-link"href="#6-1-2-date-and-time"><iclass="anchor-icon"></i></a><aclass="anchor"name="6-1-2-date-and-time"></a>6.1.2 Date and time</h4>
<p>The date of publication is <strong>obligatory</strong> for news publications. It must be obtained by any means possible, including meta tags, etc. If the date is specified correctly, time is <strong>optional</strong>.</p>
<p>If conflicting dates are stored in multiple places on the source page, preference should be given to the time that is visible to an ordinary user who views the page in a browser.</p>
<p>The IV editor's 'Preview' section will always show the date/time in UTC format, while the 'Original' section may use a different time zone. It is possible for a perfect template to display a date/time that looks different than the original. </p>
<p>Support for time zones is optional, unless the time zone is reliably identifiable from the source, in which case it’s obligatory.</p>
<blockquote>
<p><strong>Tip:</strong> If given 'date published' and 'date last edited', use 'date published' for articles. For wiki-like entries 'date last edited' must be used.</p>
<p>A <strong>subtitle</strong> is <em>a subordinate title of a published work or article giving additional information about its content</em>. If this is present in the original article, a <code>subtitle</code> is <strong>required</strong>. Here's an example of a subtitle:</p>
<p>Few publications actually use subtitles. More commonly, short summary sentences are shown below the title (and are called <em>standfirst</em> in the UK). These summary sentences are usually short and are not part of the article's text. It is <strong>advisable</strong> but not required to represent them as <code>subtitle</code> elements. Here's an example:</p>
<h4><aclass="anchor-link"href="#6-1-4-lead-paragraph"><iclass="anchor-icon"></i></a><aclass="anchor"name="6-1-4-lead-paragraph"></a>6.1.4 Lead paragraph</h4>
<p>Many publications use a slightly different style for their <ahref="https://en.wikipedia.org/wiki/Lead_paragraph">lead paragraphs</a>. Unlike subtitles and summaries, the lead paragraph is part of the article's text. Even if the lead uses a different style from the rest of the text, it is <strong>less desirable</strong> to present it as a <code>subtitle</code> — but this is not a critical issue.</p>
<p>If the lead paragraph uses a different style, it is recommended to use <strong>bold</strong> or <strong>italic</strong> text. </p>
<divclass="blog_image_wrap">
<ahref="/file/811140143/2/4WbpXiI4m8E.64274/a31d87f94d80a60426"target="_blank"><imgsrc="/file/811140143/2/4WbpXiI4m8E.64274/a31d87f94d80a60426"title="Summary, then lead paragraph in bol"/></a>
<p>A summary, then lead in bold</p></div>
<p>In the example above, the lead paragraph is highlighted in bold: “TAXI giant Uber has reportedly fired over 20 workers following an internal investigation into sexual harassment allegations.”</p>
<p>The article then continues: “The company told staff of the layoffs on Tuesday and related claims by law firm Perkins Coie, a person close with the case told Bloomberg.” It would be acceptable to present the “TAXI giant Uber…” paragraph as bold, or italic, or plain text.</p>
<blockquote>
<p><strong>Tip:</strong> Generally, it is advisable to avoid setting too much text as the subtitle. If the website publishes summaries that take an entire paragraph or even multiple paragraphs, it's better to use italic/bold text instead of the subtitle element to represent this content in IV.</p>
<p>Kickers are separately formatted parts of the title supported in IV 2.0 with the <ahref="https://instantview.telegram.org/docs?v=2.0#instant-view-format"><em>kicker</em></a> property. The kicker property must be set if a kicker is present and its text is actually a part of the title/story (see 'UBER SEX CLAIMS' on the screenshot above).</p>
<p>If the kicker represents a regular section or category into which the article falls, (e.g. 'CRIME: Seventy suitcases stolen from Heathrow airport'), it should be omitted. Missing section/category kickers are not considered an issue.</p>
<h4><aclass="anchor-link"href="#images-and-media"><iclass="anchor-icon"></i></a><aclass="anchor"name="images-and-media"></a>IMAGES AND MEDIA</h4>
<p>When several image resolutions are available and can be extracted reliably, the IV page should use <strong>better quality</strong> images (within reason). The optimal resolution range is <strong>1280px-2560px</strong>, using larger images is pointless. Note that images that are too large (<strong>>5 MB</strong>) will fail to load. We recommend updating your template to IV 2.1 to automatically extract optimal images from the <code>srcset</code> attribute.</p>
<p>If for some reason it is only technically possible to obtain low-resolution versions of images (lower than 320px) for a page, but its original web version has high-resolution images, the page should not generate an IV.</p>
<blockquote>
<p><strong>Note:</strong> For the <code>Icon</code> type, we highly recommend setting the correct size using the width/height attributes so that they appear the same way in IV as they do in the text. Otherwise, you risk grabbing the 3x version of an emoji and displaying it as a full-blown image.</p>
<p>It is <strong>obligatory</strong> to use a cover image:</p>
<ul>
<li>If the image is <strong>present</strong> on the page and described in the source as “featured-img”, “cover”, “lead_img”, “main_image”, etc.</li>
<li>When the article has a cover on the source website (above the title or subtitle).</li>
</ul>
<p>In other cases, cover images are <strong>optional</strong>:</p>
<ul>
<li>We recommend setting a cover If there's a suitable image directly below the title/subtitle.</li>
<li>While it is possible to use GIFs and videos as cover, in most cases, it's better to leave these elements in the body of the article.</li>
</ul>
<p>Sometimes, a cover is less desirable:</p>
<ul>
<li>In single-image, single-video, or single-GIF articles with no significant text.</li>
<li>When text on the cover image repeats the title.</li>
<li>Images from meta-tags are not recommended: they might be suitable, but are usually designed with sharing widgets in mind and don’t work well in the IV environment.</li>
</ul>
<p>A cover must <strong>not be set</strong> if:</p>
<ul>
<li>The chosen image is clearly inappropriate for the cover.</li>
<li>The chosen image appears several paragraphs into the article and it is possible to reliably identify this.</li>
<li>The cover image is duplicated in the article.</li>
<li>Several images appear in the article one after another. In this case, the template should not break the sequence by extracting one of them as a cover (<ahref="https://instantview.telegram.org/samples/medium.com/?url=https%3A%2F%2Fmedium.com%2F%40LibbyMari%2Fconsidering-abortion-27b3dcbaee32">example</a>).</li>
</ul>
<blockquote>
<p><strong>Tip:</strong> Cover images can also have captions in IV, don't lose them.</p>
</blockquote>
<h4><aclass="anchor-link"href="#6-2-3-galleries-and-slideshows"><iclass="anchor-icon"></i></a><aclass="anchor"name="6-2-3-galleries-and-slideshows"></a>6.2.3 Galleries and slideshows</h4>
<p>Slideshows are <strong>required only if</strong> the source article shows several photos or other media as a slideshow or gallery. If this is the case, do the following:<br>- Present all images in the IV as a gallery, if possible.<br>- If that's not possible, keep a link to the full gallery.<br>- If none of the above are possible, generate no IV for the page.</p>
<p>If the source has several ordinary images/videos/GIFs following each other in the source, you may also convert them into a slideshow, but this is <strong>purely optional</strong>. This makes more sense in cases when images serve as additional content (e.g., a long text about a new car which is followed by ten images of the car).</p>
<p>We will not accept issue reports based on presence or absence of slideshows for ordinary images following each other in the source article.</p>
<p><strong>EXCEPTION!</strong> Slideshows <strong>must not be used</strong> when:</p>
<ul>
<li>The slideshow fetches unrelated images (e.g. an illustration and a disclaimer).</li>
<li>The article consists entirely of a slideshow (and its caption/description) and there's no other content.</li>
<li>The article uses images/videos/GIFs with captions as the main medium (e.g.: travel blogs that show many photos with captions, step-by-step crafting guides, cooking recipes, etc.).</li>
</ul>
<p>In the cases above, use images with captions (or even plain paragraph text) following one another.</p>
<blockquote>
<p><strong>Tip:</strong> Remember that captions should be preserved for all images in the source. If you lose captions for images you've put into a slideshow, it's a valid issue. IV Slideshows support both a caption for the entire slideshows and different captions for each individual element.</p>
<p>Any captions present in the source article must be preserved. This includes captions for the cover image and captions for <strong>all</strong> individual elements of slideshows.</p>
<divclass="blog_image_wrap">
<ahref="/file/811140078/1/ZmgNlv6_TZo.75424/f8e251df3e3d8affe0"target="_blank"><imgsrc="/file/811140078/1/ZmgNlv6_TZo.75424/f8e251df3e3d8affe0"title="Caption for the slideshow and individual image"/></a>
<p>All Captions Preserved</p>
</div>
<p>If the image has no caption, but has meaningful text in the <em>alt</em> attribute, you may use that text as the caption. This is optional, we will not accept issue reports about alt-text missing from captions.</p>
<blockquote>
<p><strong>Tip:</strong> Please don't include meaningless alt-text as captions (e.g., the PlayStation blog always puts the name of the corresponding game in the alt attribute of all screenshots – there's no need to reproduce that on the IV page.)</p>
</blockquote>
<h4><aclass="anchor-link"href="#6-2-5-media-credits"><iclass="anchor-icon"></i></a><aclass="anchor"name="6-2-5-media-credits"></a>6.2.5 Media credits</h4>
<p>IV 2.0 supports a dedicated <code><cite></code> tag for credits in media captions. Credits in captions must be preserved and placed inside the appropriate tag, provided it is possible to reliably identify them.</p>
<p>Tall infographic images are currently unreadable in Telegram apps. If there’s a reliable way to identify them (e.g., consistently used attributes or a specific section on the website that only contains infographics) the IV must add an <strong>image link</strong> to the full version of the image. If there is no reliable way to identify such images and they are not consistently featured on the website, it is acceptable to leave infographics as ordinary photos.</p>
<p>In IV 2.0, <code><img></code> tags support the attribute <code>href</code> to make the image <strong>clickable</strong>. It must be used to preserve the link behind the image if it leads to some different page or content.</p>
<p>Image links are required only if they are meaningful. If the link opens the same image in a higher resolution, it must be removed. Exception: <ahref="#6-2-6-infographics">Infographics</a>.</p>
<h4><aclass="anchor-link"href="#6-3-2-related-articles-and-other-more-links"><iclass="anchor-icon"></i></a><aclass="anchor"name="6-3-2-related-articles-and-other-more-links"></a>6.3.2 Related Articles and other “More” links</h4>
<p>IV 2.0 supports a dedicated type for <ahref="https://instantview.telegram.org/docs?v=2.0#supported-types">RelatedArticles</a>. Related articles are relatively static individual links or blocks of articles which are thematically related to the current one. They don't have to be located on the same domain.</p>
<p>It is obligatory to format “Related articles” links using the new <code><related></code> tag and/or remove other “More” links, provided all these links can be extracted from the article without endangering essential information.</p>
<p>We designed the RelatedArticles block to deliver a better IV-reading experience to users. The IV engine automatically checks whether articles in the <code><related></code> block have an IV, you don't need to worry about this.</p>
<blockquote>
<p>If pages have <strong>no IV</strong>, they will <strong>not</strong> be displayed. If this results in an empty block, it will <strong>not</strong> be displayed.</p>
</blockquote>
<p>There are cases when you must not use RelatedArticles:</p>
<p><strong>1.</strong><strong>Keep</strong> but <strong>don’t format</strong> as Related</p>
<ul>
<li>Links that <strong>can’t</strong> be safely and reliably extracted from the article text.</li>
<li>Links that are part of <strong>essential</strong> content for the article (without which the article makes no sense).</li>
<li>Navigational links to the other parts of <ahref="#6-3-7-multi-page-articles">multipart articles</a>.</li>
</ul>
<blockquote>
<p><strong>Never</strong> put <strong>essential</strong> links into <related>, they will be lost if the page they are leading to doesn’t have an IV.</p>
</blockquote>
<p><strong>2.</strong><strong>Remove</strong></p>
<ul>
<li>“More” blocks that show <em>different</em> links each time the page is reloaded.</li>
<li>(Consistently) random unrelated articles.</li>
<li>Dynamic lists of "Latest articles from this category”, “More articles by this author”, “Featured articles”, etc.</li>
<li>Lists of categories (links to dynamic lists).</li>
<li>External links leading to “Partner sites” (e.g., You won't believe what this game does to people!).</li>
</ul>
<h4><aclass="anchor-link"href="#6-3-2-1-formatting-related-articles"><iclass="anchor-icon"></i></a><aclass="anchor"name="6-3-2-1-formatting-related-articles"></a>6.3.2.1. Formatting Related Articles</h4>
<p>It is sufficient to put links into <code><related></code>. You only need the <code><a></code>– the IV engine will handle the rest (title, description, etc.). Your IV may only have <strong>one block</strong> of related articles at the end of the page. If the source has several blocks, merge them together or choose which one to keep.</p>
<p><strong>Headers</strong><br>Only <em>one</em> header may be present for the block of related articles at the end of the page. We will not accept reports about missing headers on Related blocks (unless the header contains <em>critical</em> information).</p>
<p>Note that if a header for a related article is not reliably extractable from the body, you must <em>not</em> use <related> for that link. (Otherwise, if the link gets no IV, the text will have a hanging header). </p>
<p><strong>“Inline” blocks</strong><br>You <em>may</em> leave “inline” related links in the middle the article. If you do, these <code><related></code> blocks <em>must not have headers</em> (unless the header contains <em>critical</em> information).</p>
<p>This channel link is <strong>optional</strong>. We will not accept issue reports based on the absence or presence of a channel link, with one exception:</p>
<p>If the channel property is set, the channel it is pointing to <strong>must</strong> be the official channel. To be considered official, the channel must be labelled as such somewhere on the source website (doesn't have to be on the same page as the original article).</p>
<p>Some articles include a link to their source. This link could be inserted at the end of the article in the format <code>via <a href="https://example.org">Website Name</a></code>. A word with a similar meaning could be used instead of 'via' for websites in other languages.</p>
<p>Author links are <strong>optional</strong>. If there's a clearly identifiable author and they have a page on the target website, use that one. In more ambiguous cases, use what the regular viewing user can see in the original article or omit the link altogether.</p>
<blockquote>
<p><strong>Tip:</strong> IV only supports one author URL per article. If there are several in the article, it's permissible to choose one or omit them altogether.</p>
</blockquote>
<h4><aclass="anchor-link"href="#6-3-6-social-media-links"><iclass="anchor-icon"></i></a><aclass="anchor"name="6-3-6-social-media-links"></a>6.3.6 Social media links</h4>
<p>Sharing buttons and other interface-based links <strong>must be removed</strong> as per <ahref="#4-content-to-be-removed">Rule 4</a>.</p>
<p>Many articles include something like “check out our Facebook page” at the end of the text. Such links <strong>must be removed</strong> if they are placed in a reliably identifiable container.</p>
<p>To parse several pages into one IV, update your template to <ahref="/docs#options-new">IV 2.1</a> (which skips canonical redirects by default) and use the <ahref="/docs#inline">inline</a> function. Make sure to check in-app to see if your solution is working. The IV should open correctly when users share a link to <strong>any</strong> part of the article.</p>
<p>If pages can’t be safely assembled into one IV, navigation <strong>must</strong> be preserved. Please confirm that navigation is working and all further pages open correctly. If navigation can’t be preserved, the article must <strong>not</strong> generate an IV.</p>
<p><strong>Never</strong> format links to the other parts of an article as <em>related</em>. This may break navigation if one part of the article fails to generate IV (since related articles without IVs are omitted in the block).</p>
<p>Pages that display unsupported content (e.g. an interactive map widget) must not generate IVs.</p>
<p><strong>Important:</strong> We will accept issue reports requesting to generate IVs for pages with content previously deemed unsupported if you include a link to a template that fully supports the content in question. This does <strong>not</strong> apply to supporting content from popular widgets that are likely to get official support in the future, see the <ahref="#6-4-4-popular-widgets">list below</a>.</p>
<p>IV 2.0 includes support for <ahref="https://instantview.telegram.org/docs?v=2.0#supported-types"><strong>Tables</strong></a>. IVs can now be generated for articles with simple tables. However, complex tables may not render through existing means, and must be tagged as <ahref="/docs/#unsupported">@unsupported</a>.</p>
<p><strong>Important:</strong> We will accept issue reports requesting to generate IVs for pages with content previously deemed unsupported if you include a link to a template that fully supports the content in question.</p>
<h4><aclass="anchor-link"href="#6-4-2-video-audio-from-unsupported-players"><iclass="anchor-icon"></i></a><aclass="anchor"name="6-4-2-video-audio-from-unsupported-players"></a>6.4.2 Video/Audio from unsupported players</h4>
<ul>
<li>If the unsupported widget has an iFrame version, make it into an <code><iframe></code>. If you do that, the IV page will not be generated due to unsupported content, but things will work out of the box if and when we support that widget.</li>
<li>If it is <strong>not</strong> possible to represent the widget as an iFrame, but it is possible to get a direct link to the video/audio, use that link to generate a <code><video></code> or <code><audio></code> with the correct <code>src</code> attribute.</li>
<li>Otherwise, mark the object with the <ahref="/docs#unsupported">@unsupported</a> function.</li>
</ul>
<blockquote>
<p>If an article that is otherwise supported includes a video or an audio track that would cause it to become unsupported, it is acceptable to include a link to the video instead of unsupporting the article. If there’s no other content on the page, it must <strong>not</strong> generate an IV.</p>
<p>Some pages include unsupported widgets that are not essential for the understanding of the article. A local news site may show a weather forecast widget on their pages. A business newspaper may show a stock price ticker for the companies covered in the article. Some websites include “And what would you do?” polls at the end of some of their articles to increase user engagement.</p>
<p>Such non-essential widgets may be omitted in IV. <strong>Warning:</strong> Make sure that this dynamic auxiliary data doesn't get added to the static IV page.</p>
<h4><aclass="anchor-link"href="#6-4-4-popular-widgets"><iclass="anchor-icon"></i></a><aclass="anchor"name="6-4-4-popular-widgets"></a>6.4.4 Popular Widgets</h4>
<p>Telegram is likely to support the following popular widgets in the future:</p>
<ul>
<li>Reddit</li>
<li>Spotify</li>
<li>Getty images</li>
<li>Imgur</li>
<li>Coub </li>
<li>Soundbank</li>
<li>JW Player</li>
<li>Twitter Timeline</li>
<li>Infogram</li>
<li>VK Post</li>
<li>WordPress Embed Post</li>
<li>Yandex.music</li>
</ul>
<p>Supporting content from these widgets is <strong>optional</strong> since it will eventually become available through official means.</p>
<p>Subdomains that present content in a similar way to the higher-level domain must be supported.</p>
<p>If a subdomain looks like a separate website, supporting it is <strong>optional</strong>. We <strong>will</strong> accept issue reports if a template generates broken IV pages for any subdomain.</p>
<blockquote>
<p>Note: We will add the necessary redirects so that Telegram apps will show IVs for articles on the main domain when users share links to the mobile version. It is not necessary to support pages from the mobile version.</p>
</blockquote>
<h4><aclass="anchor-link"href="#6-5-2-service-areas"><iclass="anchor-icon"></i></a><aclass="anchor"name="6-5-2-service-areas"></a>6.5.2 Service areas</h4>
<p>Non-article pages are strictly <strong>optional</strong>, unless there’s interactive content – in which case they must <strong>not</strong> generate IVs. This includes Terms of Service, Privacy Policies, About sections, Contacts sections and special “Print” versions of articles.</p>
<p>Support for pages that only contain a single media item (photo, GIF, video, etc.) is <strong>required</strong> if:</p>
<ul>
<li>The pages are routinely accessible to users through the main navigation of the website and include other data like title, date, etc.</li>
<li>Such pages are the main medium for the domain in question (e.g. Pikabu.ru)</li>
</ul>
<p>If the single-media page contains unsupported media, it must <strong>not</strong> generate an IV. See <ahref="#6-4-2-video-audio-from-unsupported-players">6.4.2 Unsupported Video and Audio content</a>.</p>
<p>In all other cases, supporting single-media pages is optional.</p>
<h4><aclass="anchor-link"href="#6-5-4-ancient-lore"><iclass="anchor-icon"></i></a><aclass="anchor"name="6-5-4-ancient-lore"></a>6.5.4 Ancient lore</h4>
<p>Support for news articles from 2015 and earlier is <strong>optional</strong>. We won’t accept issue reports on news articles posted before 2016 if the template correctly handles articles published recently.</p>
<p>Quotes must be formatted to match their appearance in the source article, provided it is possible to identify them (and their type) in a reliable way. Line breaks in quotes must be preserved. </p>
<p>Quotes support <code><cite></code> tags. If a quote includes an author, it must be formatted accordingly (provided the author can be reliably identified in the source).</p>
<p>Don’t miss the <ahref="/docs#iv-2-1-march-20">IV 2.1</a> update.</p>
</blockquote>
<p><strong>Checklist 2.2:</strong></p>
<p><strong>Expanded clarifications</strong></p>
<ul>
<li><ahref="#3-2-link-preview">3.2</a>, <strong>Link Preview</strong>: <code>site_name</code> must include the name that users see on the main page of the website; cover photo must be used in preview if metadata is empty or contains site logo; template must generate proper description if metadata is unsuitable</li>
<li><ahref="#3-3-supported-elements">3.3</a>, <strong>Supported Elements</strong>: Credits must be supported in media captions and quotes</li>
<li><ahref="#6-1-2-date-and-time">6.1.2</a>, <strong>Date and Time</strong>: Time is optional if the date is set correctly; time zones are optional, unless reliably identifiable in the source</li>
<li><ahref="#6-2-1-image-quality">6.2.1</a>, <strong>Image Quality</strong>: for issues to be accepted, the difference in image quality must be significant; higher resolution images must be <em>reliably</em> extractable; note </li>
<li><ahref="#6-3-1-image-links">6.3.1</a>, <strong>Image links</strong>: Must be preserved if they are meaningful</li>
<li><ahref="#6-3-2-related-articles-and-other-more-links">6.3.2</a>, <strong>Related articles</strong>: Details on when RelatedArticles must not be used; <ahref="#6-3-2-1-formatting-related-articles">Formatting guidelines</a></li>
<li><ahref="#unsupported-content">6.4</a>, <strong>Unsupported content</strong>: Optional to extract content from popular widgets which are scheduled for official Telegram support, even if another template does this</li>
<li><ahref="#6-4-2-video-audio-from-unsupported-players">6.4.2</a>, <strong>Unsupported Video/Audio</strong>: Possible to include a link to an audio/video instead of unsupporting an otherwise fine article</li>
<li><ahref="#6-5-1-subdomains">6.5.1</a>, <strong>Subdomains</strong>: Added a note on mobile versions</li>
<li><ahref="https://instantview.telegram.org/checklist#6-3-2-related-articles-and-other-more-links"><strong>Related Articles</strong></a> (6.3.2). Considerably expanded guidelines. Now <em>obligatory</em> to put <strong>related</strong> links into the new “Related articles” block, provided they are reliably identifiable in the source. Other links should be removed, see <ahref="#6-3-2-related-articles-and-other-more-links">full details</a>.</li>
<li><ahref="https://instantview.telegram.org/checklist#6-2-2-cover-images"><strong>Cover Images</strong></a> (6.2.2). Added conditions when covers are <em>obligatory</em>.</li>
<li><ahref="https://instantview.telegram.org/checklist#6-2-3-galleries-and-slideshows"><strong>Galleries and Slideshows</strong></a> (6.2.3). Added detailed explanations on gallery usage.</li>
<p><strong>Checklist 2.0:</strong> Changes for the Second Instant View Contest</p>
<p>The <strong>Clarifications</strong> section has been rewritten to better organize the lore we've accumulated during and after the previous contest. These clarifications have been updated:</p>
<ul>
<li><ahref="#6-4-1-complex-tables">Tables</a> are supported (if they are not too complex).</li>
<li>Nested lists (and lists inside tables) are supported.</li>
<li><ahref="#3-1-general-properties">RTL-support</a> has been introduced and is obligatory for RTL pages.</li>
<li><ahref="#6-3-2-related-articles-and-other-more-links">Related Articles</a> got a dedicated element (<code>UPDATED 6.02</code>, see guidelines!).</li>
<li><ahref="#6-3-1-image-links">Image links</a> are supported.</li>
<li>Added guidelines on <ahref="#6-2-1-image-quality">image quality</a>.</li>
<li>Updated guidelines for <ahref="#6-2-2-cover-images">cover images</a></li>
<li>The new <ahref="#6-2-1-image-quality">Icon</a> type requires careful handling.</li>
<li><ahref="#6-2-5-media-credits">Media credits</a> can be formatted properly (if separable from caption).</li>
<li><ahref="#6-1-5-kicker">Kickers</a> in titles got a dedicated element for certain cases.</li>
<li>Added guidelines for supporting <ahref="#6-5-1-subdomains">subdomains</a>.</li>
<li>Updated guidelines for <ahref="#6-3-6-social-media-links">social media links</a></li>
<li>Updated the guidelines for <ahref="#3-2-link-preview">site_name</a> in link previews.</li>
</ul>
<p>Don't forget to check out <ahref="https://instantview.telegram.org/docs?v=2.0#what-39s-new-in-2-0">what's new in IV 2.0</a> to know what your templates are now able to support.</p>
<p>Log in here to create Instant View templates. Please enter your <b>phone number</b> in the <atarget="_blank"rel="noopener"href="https://telegram.org/faq#login-and-sms">international format</a> and we will send a confirmation message to your account via Telegram.</p>
