Re: [whatwg] Definition of alt= attribute
On Wed, 18 Jan 2006 18:43:42 +0600, Matthew Paul Thomas [EMAIL PROTECTED] wrote: In HTML 4 alt= is an attribute for img, applet, and input. I can think of no reason for input alt= to exist (form alt= would make slightly more sense, for non-interactive UAs), and Web Applications 1.0 currently includes an applets HTMLCollection but no applet element, so I've tweaked the text to refer to img elements exclusively. If applet is introduced, alt= should be put in a Common attributes section, and occurrences of image changed to item. lipDo not provide alternate text for an image when it is used for formatting, decoration, illustration, or linking to a solely graphical resource. Instead, use codealt=/code. For example, a portrait of someone should usually have codealt=/code, unless either their physical appearance or the artwork itself is highly relevant and not described elsewhere in the document./p/li /ul I wonder why alt is a required attribute for IMG in HTML while an empty value is allowed. There are several arguments for making it optional: 1. Many authors still don't specify alt or specify alt= just to make the page validate. There's not much sense in requiring an alt when there is a way to not specify it (alt=), though it is a spec violation. 2. Empty attributes aren't very XPath friendly (actually, XPath isn't well equipped to work with empty attributes). 3. If other elements, such as APPLET, also get the alt attribute, it would have to be optional to maintain backward compatibility. It would be inconsistent to require alt for IMG and have it optional for APPLET. Basing on the above points, I propose to relax the requirements and defined alt as an optional attribute. -- Opera M2 8.5 on Debian Linux 2.6.12-1-k7 * Origin: X-Man's Station [ICQ: 115226275] [EMAIL PROTECTED]
Re: [whatwg] Definition of alt= attribute
On Thu, 19 Jan 2006 16:44:29 +0600, Anne van Kesteren [EMAIL PROTECTED] wrote: I wonder why alt is a required attribute for IMG in HTML while an empty value is allowed. Because an empty value means that there is no alternate text and no attribute at all means that alternate text is missing. (Which is clearly not what you want.) The same could be said about title=, for example: An empty value means that there is no title, and no attribute at all means that the title is missing. But HTML doesn't declare the title attribute as required. -- Opera M2 8.5 on Debian Linux 2.6.12-1-k7 * Origin: X-Man's Station [ICQ: 115226275] [EMAIL PROTECTED]
Re: [whatwg] Definition of alt= attribute
On 1/19/06, Anne van Kesteren [EMAIL PROTECTED] wrote: Quoting Alexey Feldgendler [EMAIL PROTECTED]: I wonder why alt is a required attribute for IMG in HTML while an empty value is allowed. Because an empty value means that there is no alternate text and no attribute at all means that alternate text is missing. (Which is clearly not what you want.) I think Alexey's point is that in a correctly authored page no alt attribute could perfectly reasonably mean the attribute is empty, this is a good argument, but one that falls down in reality because so few pages are correctly authored so those groups needing good ALT are left at a disservice unless authors co-operate by specifically giving ALT an empty value. Jim.
Re: [whatwg] Definition of alt= attribute
On Thu, 19 Jan 2006 18:05:30 +0600, Anne van Kesteren [EMAIL PROTECTED] wrote: That is because the title attribute is not important for the element its _contents_. Without the alt attribute img becomes meaningless for devices (and people) who can not interpreted images. Now I guess that in some way no alt could have been designed to mean that there is no alternative content, but that's not how it is. I believe UAs are free to make up alternate content in such situations. By for example trying to get information from the file name... This sounds reasonable. I guess I should change my statement: The alt attrubute should be made optional, and when it's omitted, the UA should try to obtain some useful information from the file name or by other means. -- Opera M2 8.5 on Debian Linux 2.6.12-1-k7 * Origin: X-Man's Station [ICQ: 115226275] [EMAIL PROTECTED]
Re: [whatwg] a href= ping=
On Wed, 18 Jan 2006 23:38:41 +0600, James Graham [EMAIL PROTECTED] wrote: And boy does it suggest this feature will be a marketing problem :( Darin Fisher blogged the Mozilla implementation[1] and received a stream of comments, many from people who clearly haven't thought about how easy tracking already is, to the effect that they will never use a browser with this feature etc. I think the ping attribute is a great feature and I also think it's great that the cited presentation of the feature provoked the reaction that it did. Having a user base that expresses demand for privacy and security is crucial to actually getting some privacy and security, which is something I sorely want. The problem here is the presentation. In reality, the ping attribute is a net plus for privacy and security, not a new threat. The feature needs to be presented as something that will be applauded by privacy conscious folks, not something that will raise some eye-brows. I will certainly applaud it. As is noted in the cited blog post, web sites already have the ability to track link clicks and many do so. This ability to track link clicks also isn't a bug in the design, but a natural consequence of the application: the server chooses what links to present to the user. That's just the nature of the Web, resources can choose what to link to. They can link back to their own site, or they can link into another site. The problem is that the current HTML design forces sites to use a layer of indirection to track link clicks to external sites. This layer of indirection is a problem for usability, performance and design complexity. It's a usability problem because the real link target is obscured, so using the right-click menu to copy the link, or bookmark it, will not yield the expected results. It's a performance problem because the link traversals are done serially. It causes design complexity because the programmer must remember to wrap all links to external sites in a reference to a redirector. I think it would be fair to characterize current techniques for link click tracking as opaque. In contrast, the proposed ping attribute explicitly declares in the HTML what is intended and how it will happen. Perhaps the right way to explain the ping attribute is as providing transparent, or explicit, feedback; shining a light on the dark corners of click tracking. If it is explained that the feature will make link click tracking explicit, controllable and more usable, I think the user base will react more positively. Tyler -- The web-calculus is the union of REST and capability-based security: http://www.waterken.com/dev/Web/ Name your trusted sites to distinguish them from phishing sites. https://addons.mozilla.org/extensions/moreinfo.php?id=957
Re: [whatwg] a href= ping=
On 1/19/06, Tyler Close [EMAIL PROTECTED] wrote: I think it would be fair to characterize current techniques for link click tracking as opaque. In contrast, the proposed ping attribute explicitly declares in the HTML what is intended and how it will happen. Perhaps the right way to explain the ping attribute is as providing transparent, or explicit, feedback; shining a light on the dark corners of click tracking. If it is explained that the feature will make link click tracking explicit, controllable and more usable, I think the user base will react more positively. No, they'll just disable it, as it does them directly no benefit and has a cost, so if you educate them enough to make a decision, they will not decide to be tracked. Since the main use of tracking has a direct economic cost to many parties the sites will then return to using the established successful methods for tracking, no-one will gain and browsers would've wasted lots of time that could've been spent on more productive features. Jim.
Re: [whatwg] a href= ping=
Hi Jim, On 1/19/06, Jim Ley [EMAIL PROTECTED] wrote: On 1/19/06, Tyler Close [EMAIL PROTECTED] wrote: I think it would be fair to characterize current techniques for link click tracking as opaque. In contrast, the proposed ping attribute explicitly declares in the HTML what is intended and how it will happen. Perhaps the right way to explain the ping attribute is as providing transparent, or explicit, feedback; shining a light on the dark corners of click tracking. If it is explained that the feature will make link click tracking explicit, controllable and more usable, I think the user base will react more positively. No, they'll just disable it, as it does them directly no benefit and has a cost, so if you educate them enough to make a decision, they will not decide to be tracked. Why hasn't this happened to the HTTP Referer header? Since the main use of tracking has a direct economic cost to many parties the sites will then return to using the established successful methods for tracking, no-one will gain and browsers would've wasted lots of time that could've been spent on more productive features. I think an economic analysis of the scenario is a valid approach. Could you spell out your argument in more detail? For example, after I've submitted a search request to Google, what is the economic cost to me of letting Google know which result I selected? What is the economic benefit to me of providing this information to Google? I can see an argument that there is a net benefit to me to provide this information. I don't see a clear argument that there is a net cost to me. At the start of the exchange, the thing of value that I have are my search terms. Once I've given those up, Google already has most of what it needs to effectively advertise to me. Allowing Google to know which result was most relevant to me might mean I get more value in the future for revealing my search terms, in terms of better query results. I'm interested to hear your economic analysis. Tyler -- The web-calculus is the union of REST and capability-based security: http://www.waterken.com/dev/Web/ Name your trusted sites to distinguish them from phishing sites. https://addons.mozilla.org/extensions/moreinfo.php?id=957
Re: [whatwg] a href= ping=
Thomas Much wrote: am 19.01.2006 23:50 Uhr schrieb Tyler Close unter [EMAIL PROTECTED]: No, they'll just disable it Why hasn't this happened to the HTTP Referer header? There are browsers out there that let the user disable the HTTP referrer (and enable it only for certain sites that require it for whatever reasons). And our users definitely use this feature. Indeed. I believe that even browsers significantly more popular than iCab allow for this. Yet the vast majority of people leave the feature on. -- It seems to be a constant throughout history: In every period, people believed things that were just ridiculous, and believed them so strongly that you would have gotten in terrible trouble for saying otherwise. -- http://www.paulgraham.com/say.html
