This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 13629 - Identifying repeated and non-repeated content
Summary: Identifying repeated and non-repeated content
Status: RESOLVED WONTFIX
Alias: None
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML5 spec (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: contributor
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords: a11y
Depends on:
Blocks:
 
Reported: 2011-08-03 19:58 UTC by Greg Lowney
Modified: 2011-11-24 03:08 UTC (History)
8 users (show)

See Also:


Attachments

Description Greg Lowney 2011-08-03 19:58:18 UTC
HTML5 should provide a mechanism by which site authors can identify blocks of content that repeat across pages, and portions within repeated blocks that are customized for a particular page.

One method would be to allow elements inside nav, header, or footer blocks to be marked with an attribute that identified them as page-specific, while another method would be to enclose those same elements in an element (like aside) that identifies them as being related to other content (like the main article). A third would be that rather than assume nav, header and footer are repeating across pages, to allow any element to be marked with an attribute that identified it as repeating, not repeating (page-specific), or unspecified (e.g. repeated=yes, =no, or blank meaning unspecified). 

Another aspect would be to allow marking up an element with an arbitrary name identifying a group of pages on which the element repeated (e.g. pages at sample.com/software have <header group="software">, while pages at sample.com/hardware have <header group="hardware">).

Note that while nav, header and footer elements often repeat across pages, other content may as well. 

Use case: Ellen is using a screen reader and as she visits successive pages on a site, she does not want to listen to repeated blocks of content such as the header, footer, and bar. The simple solution is to ask her screen reader to skip over or her web browser to hide elements with the header, footer, and nav roles. However, she frequently visits a site on which these blocks, while generally repeating, contain information that is customized for each page. For example, each page also contain a side bar with several sections that repeat on each page (Calendar, Top Stories, Users Online) but also some sections that are specific to the page (a tag cloud and set of "Related" links). Similarly,  the  the navigation bar always shows links to the high-level segments of the site, but it also shows links to the sub-segments under the current segment; thus, any of the Samples pages would have links for Home, Biography, Bibliography, and Samples with subsidiary links for Sample 1, Sample 2, and Sample 3, while any of the Bibliography pages would have links for Home, Biography, Bibliography with subsidiary links for Non-Fiction, Fiction, and Short Works, and finally Samples. Ideally these non-repeated sections of the navigation and side bars would be marked as non-repeating, so that the user could have only those segments read to her.

Use case: Ronald uses a mobile device and visits the same site. Because space is precious, and he doesn't want to have to scroll through many, many lines of repeated content, an add-in for his browser provides a mode wherein all repeated content is hidden, including everything in the navigation bar and side bar except those portions marked as page-specific. This greatly reduces the number of inputs he has to use to navigate the page, as well as reducing bandwidth. When he decides he wants to use the repeated navigation links, he can chooses one of the mostly hidden regions and have it shown by itself, again keeping the amount of screen space and navigation commands to a minimum.
Comment 1 Michael[tm] Smith 2011-08-04 05:12:38 UTC
mass-move component to LC1
Comment 2 Benjamin Hawkes-Lewis 2011-08-06 12:32:45 UTC
(In reply to comment #0)
> HTML5 should provide a mechanism by which site authors can identify blocks of
> content that repeat across pages, and portions within repeated blocks that are
> customized for a particular page.

Couldn't a user agent remember the DOM of the previous page and read out only elements that have changed? Why do you think author-provided markup would be more reliable here?
Comment 3 Michael[tm] Smith 2011-11-20 15:15:13 UTC
Greg, this bug is waiting on you to respond to the questions in comment #2:
> Couldn't a user agent remember the DOM of the previous page and read out only
> elements that have changed? Why do you think author-provided markup would be
> more reliable here?
Comment 4 Ian 'Hixie' Hickson 2011-11-24 02:44:10 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: This can be done by the UA automatically.