5756 2008-06-14 10:49:15 +0000 Need interactive UA norms for exposing (non-displayed) HTML document data 2010-10-04 13:59:08 +0000 1 1 1 Unclassified HTML WG pre-LC1 HTML5 spec (editor: Ian Hickson) unspecified All All VERIFIED INVALID http://esw.w3.org/topic/HTML/RicherUIAccessToHTMLData NoReply P2 normal FPWD 1 rob ian mike public-html-admin public-html-wg-issue-tracking public-html-bugzilla oldest_to_newest 20481 0 rob 2008-06-14 10:49:15 +0000 * 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 http://esw.w3.org/topic/HTML/RicherUIAccessToHTMLData for evolving solution proposals) [user issue, authoring using, added implementation] 20495 1 ian 2008-06-14 18:39:06 +0000 I don't understand the problem. 20508 2 rob 2008-06-14 19:11:41 +0000 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) element’s 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. 20510 3 ian 2008-06-14 19:16:51 +0000 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. 20549 4 rob 2008-06-16 11:55:50 +0000 (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 draft’s 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 element’s 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 bug’s list of document data). 20562 5 ian 2008-06-16 20:34:04 +0000 > 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 bug’s 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). 32949 6 mjs 2010-03-14 13:14:16 +0000 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: http://dev.w3.org/html5/decision-policy/decision-policy.html 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. 35133 7 mjs 2010-04-19 09:31:28 +0000 No longer waiting for a reply on this bug.