10331 2010-08-09 17:31:36 +0000 Clarify meaning of "defined to contain a URL" and "defined to contain one or more URLs" 2010-10-04 14:32:27 +0000 1 1 1 Unclassified HTML WG pre-LC1 HTML5 spec (editor: Ian Hickson) unspecified Other other CLOSED WONTFIX http://www.whatwg.org/specs/web-apps/current-work/#reflecting-content-attributes-in-idl-attributes P3 normal --- 1 contributor ian ayg ian mike public-html-admin public-html-wg-issue-tracking public-html-bugzilla oldest_to_newest 37311 0 contributor 2010-08-09 17:31:36 +0000 Section: http://www.whatwg.org/specs/web-apps/current-work/#reflecting-content-attributes-in-idl-attributes Comment: What do "defined to contain a URL" and "defined to contain one or more URLs" mean? There are some cases that are unclear. For instance, useMap can only contain (a subset of) valid URLs AFAICT, does that count? Also, obsolete stuff like applet.src has no authoring conformance requirements, so it's not defined to contain anything, there are only algorithms that tell you how to treat it. You should make this like "limited to only known values", "limited to only non-negative numbers", etc., with explicit links wherever you mean it. Posted from: 68.175.61.233 37312 1 ayg 2010-08-09 18:05:31 +0000 The behavior of longDesc is also unclear from the spec. WebKit treats as a regular string, Gecko treats as a URL. Same for object.code and applet.object. 37366 2 ayg 2010-08-11 21:53:15 +0000 Also for body.background, object.codeBase, applet.codeBase. I created a test case to see how browsers treat them: <!doctype html> <script> var els = { "body": ["background"], "iframe": ["longDesc"], "img": ["longDesc"], "object": ["code", "codeBase"], "applet": ["object", "codeBase"], "frame": ["longDesc"] } var urls = [], strings = []; for (var elName in els) { for (var i = 0; i < els[elName].length; i++) { var el = document.createElement(elName); el.setAttribute(els[elName][i], "abcd"); if (el[els[elName][i]] == "abcd") { strings.push(elName + "." + els[elName][i]); } else { urls.push(elName + "." + els[elName][i]); } } } document.write("<ul><li>urls: " + urls.join(", ") + "<li>strings: " + strings.join(", ")); </script> Chrome/Safari: * urls: img.longDesc * strings: body.background, iframe.longDesc, object.code, object.codeBase, applet.object, applet.codeBase, frame.longDesc Firefox: * urls: body.background, iframe.longDesc, img.longDesc, object.code, object.codeBase, applet.object, applet.codeBase, frame.longDesc * strings: Opera: * urls: iframe.longDesc, img.longDesc, object.codeBase, applet.codeBase, frame.longDesc * strings: body.background, object.code, applet.object IE8 (applet.object gave some weird error and I had to comment it out): * urls: body.background, iframe.longDesc, img.longDesc, object.codeBase, applet.codeBase, frame.longDesc * strings: object.code IE9PP4: * urls: iframe.longDesc, img.longDesc, applet.object, applet.codeBase, frame.longDesc * strings: body.background, object.code, object.codeBase Probably no big deal whatever these end up being, but I'd like some clarity before I file bugs against browsers, since some of these might be oversights in the spec. 38387 3 ayg 2010-09-01 22:41:58 +0000 Note also that form.action is reflected as a string by all browsers other than IE, contrary to my expectations from reading the spec. So this really has to be clarified. 39835 4 ian 2010-09-28 23:31:57 +0000 usemap isn't defined to take a URL, it's defined to take valid hash-name reference. That seems quite clear. form.action is a URL (this is intentionally not like non-IE browsers, since IE's behaviour makes more sense). The legacy ones are all plain text (not URLs), since none are defined to be URLs. This is explicitly stated for body.background for some reason, but it's true for all the others as well. I would really rather not go through marking all the URL-reflecting IDL attributes explicitly, since that's just a huge pain and I'm bound to make mistakes, both in doing it and later in maintaining it. I'd accept a patch against the "source" file, though, if you feel strongly about this and want to do it. Feel free to contact me on IRC if you need help with that. 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: Spec seems well-defined as is. 40013 5 ayg 2010-09-29 20:37:36 +0000 I'll mark this CLOSED, unless I find the time to write a patch. I'm going to file a new bug on some of these attributes, though.