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 5756 - Need interactive UA norms for exposing (non-displayed) HTML document data
Summary: Need interactive UA norms for exposing (non-displayed) HTML document data
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML5 spec (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: FPWD
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
Keywords: NoReply
Depends on:
Reported: 2008-06-14 10:49 UTC by Rob Burns
Modified: 2010-10-04 13:59 UTC (History)
3 users (show)

See Also:


Description Rob Burns 2008-06-14 10:49:15 UTC
* authors want to make use of HTML semantic facilities, often receive no perceptual feedback
 * users want access to semantics encoded by authors even if that information is meant for fallback or machine purposes
 * when authoring content fallback, authors are not always able to verify the content except through examination of the HTML source
 * While HTML conformance expressly prohibits certain element hierarchies and avoids some attribute collisions, HTML currently provides no guidance to UAs on handling non-conforming content (e.g., an anchor link child of an anchor link)

(see for evolving solution proposals)

[user issue, authoring using, added implementation]
Comment 1 Ian 'Hixie' Hickson 2008-06-14 18:39:06 UTC
I don't understand the problem.
Comment 2 Rob Burns 2008-06-14 19:11:41 UTC
The problem is that certain pieces of document data do not necessarily receive rendering according to the author or user stylesheet. Nevertheless interactive UAs should still make this data available to users through other means even when the styling doesn't expose it directly. 

Examples include:
 * title attribute (especially if CSS later provides mechanism for authors to control hover views)
 * class attribute
 * lang (or xml:lang) attribute (may provide a localized string for the language instead of the attribute value)
 * alt attribute (inspector or embedded in the case of a failed resource or by indication of user defaults or with a contextual menu to display alternate in place)
elements keybinding key combination and keybinding event
 * URIs
    - cite attribute
    - src attribute (inspector)
    - longdesc / described-by attributes
 * Resources
    - resource referenced by the cite attribute
    - resource referenced by the longdesc / described-by attributes (alternately with a contextual menu to display long description fragment in place)
 * Document relational data
    - associated definitions and abbreviation expansions
    - associated citations, quotations, attributions, and bibliographic references
    - associated subtext or asides
 * Head metadata such as
    - name / content pairs for meta elements (inspector)
    - rel / href pairs for link elements (inspector)
 * Document list data
    - table of contents
 * Tables
    - Summary for tables
    - Abbreviations for header cells
    - Axis membership for table cells

The wiki has additional details.
Comment 3 Ian 'Hixie' Hickson 2008-06-14 19:16:51 UTC
How is this a spec problem? User agents are allowed to show all this information, if they wanted to show it they could. There's nothing we can do about it -- we don't even define that, say, the contents of a <p> element should be displayed at all! We just have to say what things mean, not what they should look like. It makes no sense to say what they should look like; that would stifle UI innovation in the browser, and would make no sense when you consider how e.g. a search engine, an HTML semantic analyser, and a Web browser have radically different needs.
Comment 4 Rob Burns 2008-06-16 11:55:50 UTC
(in reply to comment #3)
While I didn't originally say this explicitly, this bug applies to interactive UAs such as browsers. It could properly be addressed in the drafts chapter 4 focussing on Web Browsers.  Also, I'm not suggesting we need to tell such interactive UAs how to display the data: simply that they need to provide a mechanism for it that does not overwhelm novice users  (such as only providing it in the document source or in an advanced DOM inspector). Regarding the P elements contents, if we had prominent UAs that didn't display the contents of P elements, I would definitely file a bug on that too (or include the contents of the P element in this bugs list of document data).

Comment 5 Ian 'Hixie' Hickson 2008-06-16 20:34:04 UTC
> if we had prominent UAs that didn't display the contents of P elements, I would
> definitely file a bug on that too (or include the contents of the P element in 
> this bugs list of document data).

Such a bug would be invalid, like this one. Specifying what should be displayed to the user is out of scope of HTML5, and should be deferred to specs such as UAAG. We simply can't decide what a browser should do. A web browser intended for users with cognitive difficulties, for example, should likely not show the video peak bitrate. Browsers for users with no aural abilities (e.g. deaf users) shouldn't have to play back sound. Browsers for users in large public spaces (e.g. a large display in Times Square) shouldn't have to do anything interactive, but that shouldn't preclude them from providing some sort of UI (e.g. just a UI to select links and nothing else).
Comment 6 Maciej Stachowiak 2010-03-14 13:14:16 UTC
This bug predates the HTML Working Group Decision Policy.

If you are satisfied with the resolution of this bug, 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:

This bug is now being moved to VERIFIED. Please respond within two weeks. If this bug is not closed, reopened or escalated within two weeks, it may be marked as NoReply and will no longer be considered a pending comment.
Comment 7 Maciej Stachowiak 2010-04-19 09:31:28 UTC
No longer waiting for a reply on this bug.