Re: [whatwg] Definition of alt= attribute
Henri Sivonen wrote: On Jan 23, 2006, at 18:43, dolphinling wrote: Second, it could force authoring tools to produce invalid documents if the author did not provide any alt text. However, those documents would be non-conformant anyway, so this is not a huge problem. It is. Authoring tools are judged by taking a page authored using the tool and running it through the W3C Validator or, presumably in the future, through an HTML5 conformance checker. Authoring tool makers who are capable of making their tool produce syntactically conforming documents will want to do so and minimize the chance that the users of their software tarnish the reputation of the tool in the eyes of people who use an automated test as a litmus test of authoring tool bogosity. (People who test tools that way will outnumber the people who make a more profound analysis due to the validate, validate, validate propaganda.) File - Save If you save this page as is, it will be non-valid for the following reasons: You did not specify alternate text for one or more images. The page will display properly, but will be less accessible to some users and will fail automated validation tests. [Fix errors] [Save anyway] ...The point being that that would only be a problem to authoring tools that didn't do something about it--and frankly, I'd expect an authoring tool to give a dialog like that anyway, even if they weren't concerned about market share. -- dolphinling http://dolphinling.net/
Re: [whatwg] Definition of alt= attribute
On Jan 24, 2006, at 13:06, dolphinling wrote: File - Save If you save this page as is, it will be non-valid for the following reasons: You did not specify alternate text for one or more images. The page will display properly, but will be less accessible to some users and will fail automated validation tests. [Fix errors] [Save anyway] mpt is going to be thrilled. :-) ...The point being that that would only be a problem to authoring tools that didn't do something about it--and frankly, I'd expect an authoring tool to give a dialog like that anyway, even if they weren't concerned about market share. I don't. And I -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] Definition of alt= attribute
On 24 Jan, 2006, at 5:43 AM, dolphinling wrote: Matthew Paul Thomas wrote: Bizarre but serious conclusion: alt= should be optional for img in documents where a meta name=generator... element is present. How about Authoring tools MUST only provide alternate text that the author explicitly requests, That would seem to prevent, for example, Microsoft FrontPage from generating the obvious alt text for an Image Composer image that consisted only of text sprites. (And since Microsoft continue to misimplement the existing spec for alt=, it wouldn't be a good idea to trust them to interpret explicitly requests the way you want.) and especially MUST NOT provide alt= unless the author specifically says that the alternate content is empty. Authoring tools SHOULD make it obvious to the author what the meaning of alt= is, for example with the string What text should be used if the image cannot be displayed? http://slick-net.com/space/stamps/ That example of awful alt= text was apparently made with vi. Would vi be violating your SHOULD, for not making the meaning of alt= obvious? ... Problems with this approach include the following: First, it could be interpreted as disallowing pseudo-AI. This could be fixed with a note saying This should not be interpreted as disallowing pseudo-AI in authoring tools, but even a pseudo-intelligent authoring tool MUST NOT assume an empty alt text. I think that text fails the wtf? test. Does it cover the Image Composer example above? Nobody would be able to tell. Second, it could force authoring tools to produce invalid documents if the author did not provide any alt text. However, those documents would be non-conformant anyway, so this is not a huge problem. ... It would be a problem as long as generates valid HTML is considered a feature separate from conformance, since software can guarantee the former but not the latter. And I don't think anything in an HTML 5 spec could prevent validity from being seen as a feature. That's why I propose the meta name=generator... exception for compulsory alt=. -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] Comment Syntax and Parsing
On Tue, 24 Jan 2006, Lachlan Hunt wrote: As for how to parse it, I'll use these test cases to demonstrate what I consider to be the most sane way to handle comments. (Assume EOF at the end of each one) Test Case | Comment Content | Output ---|--|-- PA!SS|| PASS PA! -SS | - | PASS PA! --SS || PASS PA!-SS | - | PASS PA!- -SS | - -| PASS PA!- -SS -- | - -| PASS -- Agreed. PA!- !--SS -- | - ! | PASS -- Comment should be - !-- IMHO. It's still a bogus comment (in HTML5 nomenclature), the -- part is irrelevant. PA!- !-- -SS --| - !-- - | PASS -- Agreed. PA!- --SS| - | PASS PA!- -- SS | - | PASS These are bogus comments, so again, they should be - -- and - -- respectively, IMHO. PA!-- FAIL --SS | FAIL | PASS PA!-- FAIL --SS | FAIL | PASS PA!-- FAIL !-- --SS| FAIL !--| PASS PA!-- FAIL !-- -- --SS | FAIL !-- -- | PASS Agreed. PA!-- FAIL -- SS | FAIL| PASS Disagree. The terminator should be --, not -- S* . I don't see any good reason to have -- S* . P!-- -- AS!-- --S | (2 comments) | PASS Disagree (same reason). -- AS!-- is the comment, output is PS. PA!-- FAIL -- FAIL --SS | FAIL -- FAIL | PASS P!-- -- --AS!-- -- --S | -- (2 comments) | PASS PA!-- -- -- --SS | -- -- | PASS PA!-- FAIL -- FAIL -- FAIL --SS | FAIL -- FAIL -- FAIL | PASS PA!--- FAIL --SS | - FAIL | PASS PA!--- FAIL ---SS| - FAIL - | PASS !-- -FAIL| -FAIL| !--- -FAIL | - -FAIL | PA!-SS | - | PASS Agreed. !-- --- -| (not sure) | Comment text is --- -. PA!-- --- --SS | --- | PASS PA!--- --- ---SS | - --- -| PASS Agreed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Comment Syntax and Parsing
Ian Hickson wrote: On Tue, 24 Jan 2006, Lachlan Hunt wrote: PA!- !--SS -- | - ! | PASS -- Comment should be - !-- IMHO. It's still a bogus comment (in HTML5 nomenclature), the -- part is irrelevant. Ok, so if a comment only starts with '!' then it ends at the first '' only (ignoring any '--'), but if a comment starts with '!--' then it must end with '--'. PA!- --SS| - | PASS PA!- -- SS | - | PASS These are bogus comments, so again, they should be - -- and - -- respectively, IMHO. Ok. PA!-- FAIL -- SS | FAIL| PASS Disagree. The terminator should be --, not -- S* . I don't see any good reason to have -- S* . I was working on the assumption that the comment would end at the first occurance of '' while in the comment end state, but that whitespace would be ignored while searching for it. Several browsers already handle it like that including Mozilla, Opera and Safari (except in Opera, the comment contained FAIL -). Although IE, OmniWeb and iCab failed. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Comment Syntax and Parsing
On Wed, 25 Jan 2006, Lachlan Hunt wrote: Ian Hickson wrote: On Tue, 24 Jan 2006, Lachlan Hunt wrote: PA!- !--SS -- | - ! | PASS -- Comment should be - !-- IMHO. It's still a bogus comment (in HTML5 nomenclature), the -- part is irrelevant. Ok, so if a comment only starts with '!' then it ends at the first '' only (ignoring any '--'), but if a comment starts with '!--' then it must end with '--'. Right. They end up in different parse states (bogus comment or bogus tag or something, vs comment or something). This is for compatibility with existing UAs -- basically it's not a comment really, just a malformed tag that happens to be turned into a Comment node in the DOM. PA!-- FAIL -- SS | FAIL| PASS Disagree. The terminator should be --, not -- S* . I don't see any good reason to have -- S* . I was working on the assumption that the comment would end at the first occurance of '' while in the comment end state, but that whitespace would be ignored while searching for it. Several browsers already handle it like that including Mozilla, Opera and Safari (except in Opera, the comment contained FAIL -). Although IE, OmniWeb and iCab failed. Really? In my testing, browsers didn't reliably do this. Were you testing standards mode or quirks mode? Did you have the potential to be hitting unexpected-EOF-reparse behaviour, or was it definitely the first-parse behaviour? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Comment Syntax and Parsing
Ian Hickson wrote: On Wed, 25 Jan 2006, Lachlan Hunt wrote: Ian Hickson wrote: On Tue, 24 Jan 2006, Lachlan Hunt wrote: PA!-- FAIL -- SS | FAIL| PASS Disagree. The terminator should be --, not -- S* . I don't see any good reason to have -- S* . I was working on the assumption that the comment would end at the first occurance of '' while in the comment end state, but that whitespace would be ignored while searching for it. Several browsers already handle it like that including Mozilla, Opera and Safari (except in Opera, the comment contained FAIL -). Although IE, OmniWeb and iCab failed. Really? In my testing, browsers didn't reliably do this. Were you testing standards mode or quirks mode? Did you have the potential to be hitting unexpected-EOF-reparse behaviour, or was it definitely the first-parse behaviour? I tested the following in the live dom viewer using Firefox 1.5.0.1 Win and Mac, Opera 8.5/Mac, Opera 9 Win and Mac, Safari 2.0.3, IE6, OmniWeb 5.1.2 and iCab 3.0.1. !DOCTYPE html PA!-- FAIL -- SS Browser | Comment | Rendered --|-|--- Firefox | FAIL | PASS O 8.5/Mac | FAIL - | PASS O 9.0/Mac | FAIL | PASS O 9.0/Win | FAIL | PASS Safari| (not shown) | PASS IE6 | (not shown) | PA FAIL -- SS iCab | (not shown) | PA FAIL -- SS OmniWeb | (not shown) | PA FAIL -- SS (The live dom viewer didn't work for OmniWeb, I just used an HTML file instead) -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Comment Syntax and Parsing
Ian Hickson wrote: On Wed, 25 Jan 2006, Lachlan Hunt wrote: I tested the following in the live dom viewer using Firefox 1.5.0.1 Win and Mac, Opera 8.5/Mac, Opera 9 Win and Mac, Safari 2.0.3, IE6, OmniWeb 5.1.2 and iCab 3.0.1. !DOCTYPE html PA!-- FAIL -- SS This triggers SGML comment parsing mode (which you don't want to be testing) in a number of browsers. Why? The closer we can define the behaviour to be compatible with existing standards mode behaviours, the better it will be for backwards compatibility? -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Comment Syntax and Parsing
On Wed, 25 Jan 2006, Lachlan Hunt wrote: Ian Hickson wrote: On Wed, 25 Jan 2006, Lachlan Hunt wrote: I tested the following in the live dom viewer using Firefox 1.5.0.1 Win and Mac, Opera 8.5/Mac, Opera 9 Win and Mac, Safari 2.0.3, IE6, OmniWeb 5.1.2 and iCab 3.0.1. !DOCTYPE html PA!-- FAIL -- SS This triggers SGML comment parsing mode (which you don't want to be testing) in a number of browsers. Why? The closer we can define the behaviour to be compatible with existing standards mode behaviours, the better it will be for backwards compatibility? This entire discussion started from the developers of all the browsers who implemented the SGML comment mode coming to me and telling me I was stupid for even suggesting that this is how comments should be parsed. The whole point of all this is to simplify comment parsing. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Comment Syntax and Parsing
Quoting Lachlan Hunt [EMAIL PROTECTED]: This entire discussion started from the developers of all the browsers who implemented the SGML comment mode coming to me and telling me I was stupid for even suggesting that this is how comments should be parsed. The whole point of all this is to simplify comment parsing. Yes, and I agree with that. But, besides Mozilla, which of those browser versions that I tested actually have SGML comments enabled? Opera 9 I assume. If I remember correctly the SGML thing was fixed before the preview. We currently plan on going back to normal comment handling for the moment. So you could use Opera 8.5 if you do not want SGML comment handling. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Comment Syntax and Parsing
Also sprach Ian Hickson: This triggers SGML comment parsing mode (which you don't want to be testing) in a number of browsers. Why? The closer we can define the behaviour to be compatible with existing standards mode behaviours, the better it will be for backwards compatibility? This entire discussion started from the developers of all the browsers who implemented the SGML comment mode coming to me and telling me I was stupid for even suggesting that this is how comments should be parsed. The whole point of all this is to simplify comment parsing. Right. And since I run out of memory trying to parse a sentence with the word simple and SGML in it... Oops. Core dumped. -hkon
[whatwg] embedded content: OBJECT
It will be great to see OBJECT handling clarified. Here are some points: On encountering an OBJECT, the UA must check type and/or classid. If the type attribute identifies a file type the UA handles internally, check if the OBJECT has a data attribute. Render contents of this attribute if found, proceed to fallback contents if not. If type/classid identifies a known plugin, the UA must initialise the plugin passing on information about the attributes and the name/value pairs of any PARAM descendants that are not children of nested OBJECT tags. If type/classid does not identify a known plugin, and there is a data attribute, do a HEAD request on the resource identified by the data attribute. If the server sends a content-type that identifies a known plugin, initialise plugin. If there is no data attribute, the resource can not load or the content-type of the resource is unknown, proceed to render fallback contents. Issues: if there is a known content-type and a data: attribute, should the UA check if the content-type sent from server also identifies the plugin? In other words, do we want to say that the type attribute on the OBJECT tag is only a hint and that the actual HTTP content-type header is the one that counts? I'm not sure if only a hint should be speced. It sounds quite risky to meddle with the logic for embedding contents - could break many sites, particularly if we are supposed to start relying on the famously malconfigured HTTP content-type responses. Since there are use cases for plugins that do not load data at all, the UA should initialise the plugin even without data attribute if the type is known. That sort of negates the point about type being a hint because we can't initialise one plugin, look at the content-type of files that plugin decides to request and say whops, we started the wrong plugin, let's do this again. If the spec goes the hint route, it really needs to make that apply only to OBJECTs with a data attribute, and to minimise problems with malconfigured servers it should only take place if the UA doesn't know the specified type attribute IMO. Another issue is of course if and how one should map classid to plugins. -- Hallvord Reiar Michaelsen Steen http://www.hallvord.com/
