[01 Feb 05 18:06] agenda (in no particular order and on top of my head): accesskeys, icons, feedback page, css 2.1 [01 Feb 05 18:06] anything else requiring special attention today? [01 Feb 05 18:08] maybe "redirected to localhost" stuff ** accesskeys ** [01 Feb 05 18:10] http://lists.w3.org/Archives/Public/www-validator/2005Jan/0116.html [01 Feb 05 18:11] turns out accesskeys are not deemed very accessible... [01 Feb 05 18:11] we have them in most of our web interfaces, what do you think? [01 Feb 05 18:12] ** *xover declines to take Jukka's word alone on this!* [01 Feb 05 18:12] I have actually read contrary opinions on whether they're good/bad for accessibility [01 Feb 05 18:13] maybe it's just our choice that conflicts with browser commands? [01 Feb 05 18:13] validator uses a few selected letters, plus 1-9 (for "safety" reasons, I guess), checklink uses a few in the front page form, and some in the navigation [01 Feb 05 18:13] Jukka points out: "there is no "safe" set of characters" [01 Feb 05 18:13] The few arguments I've seen to the contrary seem to be very much ablebodied people complaining that you're stealing their keyboard shortcuts. [01 Feb 05 18:13] http://validator.w3.org/accesskeys.html (for the markup validator) [01 Feb 05 18:14] I don't remember, does checklink document them somewhere? [01 Feb 05 18:14] nope [01 Feb 05 18:15] less useful if not documented, in any case [01 Feb 05 18:15] right [01 Feb 05 18:15] the reason I added this to the agenda that I have no good/bad opinions nor do I use them, wanted to hear if someone has/does [01 Feb 05 18:16] I don't use them either [01 Feb 05 18:16] if they're going to stay, I'll take a look at documenting them (in checklink) [01 Feb 05 18:17] my opinion (not too strong, to be honest) is that if they're sufficiently well documented, possibly with tooltips in the interface and links to more documentation (?) they could be a good teaching instrument [01 Feb 05 18:17] granted, we'd have to use them "well", and I don't actually know if we are [01 Feb 05 18:18] We probably need to check with WAI what the prevailing opinion there is. [01 Feb 05 18:19] too bad niq isn't here today [01 Feb 05 18:20] I guess I'll take the ACTION to check with WAI folks, then [01 Feb 05 18:20] good. no changes until that feedback, then ** Icons ** [01 Feb 05 18:24] cf. http://www.w3.org/2004/07/IconsTest/testtrans [01 Feb 05 18:24] I've just read your last messages on the issue [01 Feb 05 18:25] current version is very close to Bjoern's SVG attempt a while ago, with some font tweaks so that the rasterized version (png) resembles what we currently have [01 Feb 05 18:26] Bjoern had a point, that we should try and get definitive info on what font was originally used... Although I systematically failed to get that info in the past [01 Feb 05 18:27] Re: «Bitstream Vera Sans» (Terje) - that's what I was trying to do by embedding the glyph for Sera Sans (the SVG equiv of vera) but somehow not working [01 Feb 05 18:27] Do we even care anymore? Isn't a slight freshening of the badges in order in any case? [01 Feb 05 18:28] I originally thought so, but all the comments in my first round (where the badges were more != from current prod version than now) were "don't change anything!" [01 Feb 05 18:28] from Bjoern and from Comm IIRC [01 Feb 05 18:30] by the way, what's the rationale for the "V" mark being red? at least I tend to associate green with "ok", and red with "nok" [01 Feb 05 18:31] Any chance we could see a full(ish) set side-by-side with the originals? [01 Feb 05 18:31] xover, yeah, that'll be next step [01 Feb 05 18:32] Green would probably look butt ugly next to the colors used in that badge. [01 Feb 05 18:32] I want to proceed carefully before "releasing" in public web space the full set [01 Feb 05 18:32] Then again, something olivy or summat might work... [01 Feb 05 18:33] hmm, scop++ for the "V", but again, I fear that change, however well intentioned, will not be much welcome [01 Feb 05 18:33] not that a big deal as long as there are no "invalid HTML!" badges though :) [01 Feb 05 18:33] there are :) [01 Feb 05 18:36] bjoern_, had a chance to look at latest template.png? [01 Feb 05 18:36] via http://www.w3.org/2004/07/IconsTest/testtrans ? [01 Feb 05 18:37] looks crap in IE... [01 Feb 05 18:37] better in FF [01 Feb 05 18:37] translarency issues... [01 Feb 05 18:38] still translarceny, hmm [01 Feb 05 18:38] the W seems a pixel off... [01 Feb 05 18:39] I think it's not off, the "W3C" is prolly a tiny bit bigger [01 Feb 05 18:40] bolder at least [01 Feb 05 18:40] although you have to have them side by side to notice [01 Feb 05 18:40] not really... [01 Feb 05 18:40] the translarceny issue annoys me, though [01 Feb 05 18:40] I though pngquant would do the job [01 Feb 05 18:41] The .svg is really nice in any case. [01 Feb 05 18:41] but if it doesn't, I don't know how to convert the good-pngs into good-for-ie-pngs [01 Feb 05 18:42] Isn't the trick there to use transparency instead of alpha channels? [01 Feb 05 18:42] ** *xover said, while knowing full well he's on pretty thin ice where graphics are concerned...* [01 Feb 05 18:42] ** SHS` has joined [01 Feb 05 18:42] I was right, the W is much closer to the left... [01 Feb 05 18:44] xover, yes, something to that effect [01 Feb 05 18:44] Is the W3C larger in the new version? The C seems much closer to the other edge too, non? [01 Feb 05 18:44] but the tools to do that aren't many [01 Feb 05 18:45] well, I can convert the pngs to something IE-compatible, that's not an issue [01 Feb 05 18:50] ACTION: bjoern to find proper tool/setting to create IE friendly PNGs [01 Feb 05 18:51] I'll try to fix the size of the W3C, and use the "free" font as preferred default too ** Feedback page ** [01 Feb 05 18:52] Ref. http://qa-dev.w3.org/wmvs/HEAD/feedback.html [01 Feb 05 18:52] just going round the table quickly to get your opinions [01 Feb 05 18:52] compare to: http://validator.w3.org/feedback.html [01 Feb 05 18:53] (and the mailto: links for the error messages) [01 Feb 05 18:59] I like the bugzilla links I've added a lot... [01 Feb 05 19:00] bjoern_++ [01 Feb 05 19:02] ** *scop wonders if it would be possible somehow to automagically smuggle the URI of the doc that was validated from the results page to the feedback form's mailto: link (?subject=foo&body=bar)* [01 Feb 05 19:03] possible, yes [01 Feb 05 19:03] Most email clients won't allow setting the body for security reasons AFAIK. [01 Feb 05 19:03] d'oh [01 Feb 05 19:04] well, but for those who do set the body, it's a gain [01 Feb 05 19:04] I do not know about "most" but it works in "many" [01 Feb 05 19:04] however, I'd be a tad worried that people just send the mail as is (regardless of the advice) because "it's all been generated for me" [01 Feb 05 19:04] Stuff it in the Subject instead of the "Meaningless Generic String of Text"? [01 Feb 05 19:05] xover: subject (in cvs version) just sets [VE][NUM] or nothing, and asks user to set something meaningful [01 Feb 05 19:06] there could (also) be a friendly "here's the URL we'll be interested in" note next to the mailto: link, if body=foo doesn't work or isn't a good idea [01 Feb 05 19:06] scop++, that's a good start [01 Feb 05 19:07] one nit in Bugzilla links: s/active/open/ [01 Feb 05 19:08] And include a param to set sort order, BTW. [01 Feb 05 19:08] other than that, I think the content is good [01 Feb 05 19:08] xover: noted [01 Feb 05 19:09] ;order=bugs.bug_id [01 Feb 05 19:09] yod: http://www.w3.org/Bugs/Public/quips.cgi?action=show [01 Feb 05 19:11] older quips have been removed? [01 Feb 05 19:12] the latest upgrade was a bit heavy handed, though, I'm not so surprised [01 Feb 05 19:12] Bjoern told me earlier that the charset decl meta was gone, too [01 Feb 05 19:13] ACTION olivier re-fix charset decl meta in bugzila [01 Feb 05 19:14] [...] I think I have enough feedback on the feedback issue to work on and come up with a new rev ** Localhost validation ** [01 Feb 05 19:16] ...so, what I was thinking about is http://validator.w3.org/check?uri=http%3A%2F%2Flocalhost%2F [01 Feb 05 19:16] odd [01 Feb 05 19:17] ...and that the redirects aren't probably &ip_rejected() checked [01 Feb 05 19:17] yet the redirects to http://localhost seem to be working just fine [01 Feb 05 19:17] exactly [01 Feb 05 19:18] need to override LWP::UserAgent::redirect_ok() [01 Feb 05 19:18] ** *xover fails to see the problem...* [01 Feb 05 19:18] if you validate example.org which redirects to localhost [01 Feb 05 19:18] the validator will attempt to access localhost [01 Feb 05 19:18] even though it should not [01 Feb 05 19:18] (AFAIU) [01 Feb 05 19:19] right [01 Feb 05 19:19] Ah, right. Was looking at the link above and not a redirect case. [01 Feb 05 19:20] there are strange/many cases of redirect to localhost, which I am trying to investigate, but that is a side issue [01 Feb 05 19:20] the link checker might have the same problem, btw [01 Feb 05 19:21] ACTION scop to check redirects for ip-allowedness ** Next Meeting ** [01 Feb 05 19:29] ** The topic is 'W3C QA Tools || Markup Validator || next meeting: 2005-02-22 || New: HTML Tidy channel #tidy' (set by bjoern_)