Re: [whatwg] Definition of alt= attribute
On Sat, 21 Jan 2006 17:25:12 +0600, Matthew Raymond [EMAIL PROTECTED] wrote: Hmm... Is img ever non-presentational? Radical thought: Deprecate img. Why? Aren't there semantic images? Maybe instead deprecate img for presentational images, leaving it only for semantic images (with non-empty alt 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
Alexey Feldgendler wrote: On Sat, 21 Jan 2006 17:25:12 +0600, Matthew Raymond [EMAIL PROTECTED] wrote: Hmm... Is img ever non-presentational? Radical thought: Deprecate img. Why? Aren't there semantic images? Might be. As Anne suggests, a picture of a product might be a good example. It was more of a question than a serious suggestion. Maybe instead deprecate img for presentational images, leaving it only for semantic images (with non-empty alt required). Sounds like a good idea. We should probably also consider how object fits into this, though. Can it completely replace img??? It certainly has better support for fallback content.
Re: [whatwg] Definition of alt= attribute
Anne van Kesteren wrote: Quoting Matthew Raymond [EMAIL PROTECTED]: Hmm... Is img ever non-presentational? Radical thought: Deprecate img. A company logo? You could make an argument that trademarks have semantic value, but it's kinda weak, because you can identify the company by name as well. Here's some markup: | h1 style=content: url(logo.png)Company Name/h1 (Not sure I got the CSS right, but you get the idea.) A picture of a new product some review is about? Much better example. That probably is semantic, yes. However, is there any situation where object couldn't be used instead of img?
Re: [whatwg] Definition of alt= attribute
On Sat, 21 Jan 2006 18:11:29 +0600, Matthew Raymond [EMAIL PROTECTED] wrote: Maybe instead deprecate img for presentational images, leaving it only for semantic images (with non-empty alt required). Sounds like a good idea. We should probably also consider how object fits into this, though. Can it completely replace img??? It certainly has better support for fallback content. img has one feature that object lacks: to automatically derive its dimensions from the downloaded external content. In all other means I should say that object looks like a decent replacement for img. -- 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
Henri Sivonen wrote: On Jan 19, 2006, at 14:05, Anne van Kesteren wrote: Without the alt attribute img becomes meaningless for devices (and people) who can not interpreted images. Good intention, yes, but let's consider the practice: Suppose there is an authoring tool that has a design goal of always outputting conforming (to the extent conformance is machine-assessable) documents. This tool allows the user to insert images. Allowing images to be inserted without prompting for more information and also enforcing the presence of a human-supplied alt attribute would mean that the tool would have to refuse to save the document until the alt texts have been supplied. Refusing to save is not good. Therefore, the tool would have to present a document-modal dialog prompting for the alt text upon inserting the image. Sure, some people might even enter some text, but people who just want to get on with it would hit return with an empty text box. Alternatively, the tool makers could give up the requirement of human-supplied alt text and just generate an empty alt text by default without asking. (Considering that the tool itself--not just the author using it--will be judged by seeing if the output passes an automated conformance check, it is likely that the requirement of correct output will not be dropped because of the alt issue.) People seem to have passed this point by. the current specification of alt as required makes it almost impossible to design a conforming HTML editor that doesn't mess up the semantics of the attribute. Since many (the majority?) of HTML pages are produced using some form of graphical editor (often implemented using contentEditable or some other HTML+js solution as part of a CMS), the spec should at least consider the needs of editors as well as UAs.
Re: [whatwg] a href= ping=
On 1/19/06, Tyler Close [EMAIL PROTECTED] wrote: On 1/19/06, Jim Ley [EMAIL PROTECTED] wrote: 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? Because no-one's ever attempted to educate people enough to make a decision. 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? You're now discussing a very minor use case, the main use case is in advert tracking, the economic case here is clear, accurate information is required by the people paying for the ads to be shown and those showing the adverts - if you're allowing an ad-service to show adverts on your page, are you willing to accept that ad-service using a disableable method of tracking what to pay you? The use case of tracking what you click to leave a site is that it has no direct benefit to the user whatsoever, they gain nothing at all, and there's the slowness cost - indeed the site may be slower still if they use redirect methods, but that's the sort of cost that would make the tracking uneconomic as it will annoy users. I get more value in the future for revealing my search terms, in terms of better query results. People don't make the same search more than once, google already knows what the most popular search result on a particular term is and without knowing what it was you were actually looking for (most search terms don't express this very well) and what happened when you arrived at the site they cannot know how useful the link truly was. but mostly that's a minor use case compared to the main reason for leaving site tracking, and that use case the ping proposals abjectly fails to meet. Jim.
[whatwg] comment parsing
Given the new parsing rules for comments (all those internal discussions...) I was trying to write some testcases for how they are defined now. # p!-- -- --PASS!--/p However, from the specification it is not entirely clear what should happen with !--/p. Well, perhaps it is, but then I'd like that to be changed. If we take the problematic snippet: # !--/p It seems that per http://whatwg.org/specs/web-apps/current-work/#marked !-- starts the comment. It seems that per http://whatwg.org/specs/web-apps/current-work/#comment all characters that follow and are not a dash have to become part of the comment. Is that correct? So if I would modify the testcase to say: # p!-- -- --PASS!--/pFAIL And directly after FAIL it is EOF (or a few end tags later) it would never show up, right? Given that most browsers show FAIL or !--FAIL for: # p!--FAIL/p A change might be in order. Or perhaps someone explaining to me what I did wrong when reading the specification. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Definition of alt= attribute
On Sat, 21 Jan 2006 13:54:34 +0100, James Graham [EMAIL PROTECTED] wrote: Henri Sivonen wrote: Alternatively, the tool makers could give up the requirement of human-supplied alt text and just generate an empty alt text by default without asking. (Considering that the tool itself--not just the author using it--will be judged by seeing if the output passes an automated conformance check, it is likely that the requirement of correct output will not be dropped because of the alt issue.) People seem to have passed this point by. the current specification of alt as required makes it almost impossible to design a conforming HTML editor that doesn't mess up the semantics of the attribute. Since many (the majority?) of HTML pages are produced using some form of graphical editor (often implemented using contentEditable or some other HTML+js solution as part of a CMS), the spec should at least consider the needs of editors as well as UAs. As I have stated before [1], 'spacer' is arguably the element with the most semantic information (namely that this element is used for layout hacks only and can be ignored for every other purposes), losing information when replaced with img src=./spacer.png alt= because the UA now doesn't *know* that the image is useless, but can assume so based on factors like URL, image dimensions, content, and above all the specified empty 'alt' attribute. Going from 'img' to 'object' loses more information, to be exact the very 'alt' attribute to separate the useful from the useless. Obviously I don't want the 'spacer' element back, 'spacer' is obsolete with CSS if not before. But the loss of information is real. If a UA wants to do a best attempt for an 'object' in a context where the object itself can't be rendered the UA will know next to nothing about the object. Yes, 'object' has fallback (which 'img' too could have had if it hadn't been defined to be EMPTY) so there is little dispute what to render, but it doesn't know what it has missed. Depending on the object and the fallback the fact that the preferred content wasn't rendered can be anything from inconsequential to critical. The danger with making an aspect of a markup language mandatory, like the mandatory 'alt' attribute for 'img' and the mandatory 'title' element in 'head' is that the editor/author will need to use filler content that may reduce the quality of the attribute/element in question. With 'alt' this has the consequence 'alt=' means either that this image has no alternate representation (and presumably semantic content) or that it has been automatically been filled in to make the document validate. It is fairly acceptable, but it would have been better that no 'alt' attribute at all had been used in the latter case. Another datum that is lost from 'img' to 'object' is that the embedded object is supposed to be an image, and not e.g. an embedded HTML document, an applet or a video. In theory the content type could have given that information (text/*, image/*, audio/*...), but the 'type' attribute is optional, and in any case the non-informative application type is very common. In this aspect (and not that many other) I like SMIL. In addition to 'ref' (the general 'object') it has 'animation', 'audio', 'img' (like HTML), 'text', 'textstream', and 'video'. [1] http://my.opera.com/jax/blog/show.dml/83408 -- Jonny Axelsson, Core Technology, Opera Software ASA
Re: [whatwg] Definition of alt= attribute
Hi, From: Ian Hickson [EMAIL PROTECTED] I've considered making alt= and omitting alt be conformant equivalents. I haven't really thought much about it yet though. Lynx shows the file name if alt= is ommitted. IIRC, HTML 4.0 previously recommended that UA's should use the file name if alt is ommitted, so to avoid HTML 4.0 compliant UA's using the file name when we want it to be empty, I think it is reasonable to require alt when src is present (and vice versa). Using the file name when the alt attribute is ommitted might make sense in some cases, such as: a href=/img src=home.gif/a ...but not in others, such as: img src=spacer.gif Regards, Simon Pieters
[whatwg] [wf2] required attribute and pseudo-classes
In http://whatwg.org/specs/web-forms/current-work/#relation I think the text on :required and :optional should be clarified so that it is clear that these pseudo-classes only apply to elements to which the required attribute applies. -- Anne van Kesteren http://annevankesteren.nl/
