| 00:17 | <Hixie> | Philip`: i don't really understand what the difference between those two modes would be |
| 00:21 | <Hixie> | Philip`: nor do i understand why this would be any more of a problem than the UA determining the difference between alt="..." written by morons and alt="..." written usefully |
| 00:48 | <Hixie> | still no sign of sebastian? |
| 00:53 | <Philip`> | Hixie: When alt was accidentally omitted, the UA can predict there's a good chance it's a decorative image (based on statistics from current content). When an image is explicitly marked as being critical content, there should be a much better chance that it actually is critical content. That can set the initial bias for any heuristics when the UA is trying to decide how to present the image to the user |
| 00:54 | <Hixie> | i'm surprised as to your initial assertion |
| 00:54 | <Hixie> | is that really true? |
| 00:54 | <Philip`> | (The heuristics might be as simple as "if it's got no alt, it's probably decorative, so ignore it" and "if it's marked as important, say "image, press enter for more information"") |
| 00:55 | <Philip`> | I haven't looked at any relevant statistics from current content so I don't really know :-) |
| 00:55 | <Hixie> | ah ok |
| 00:55 | <Philip`> | (Or the heuristics might be some futuristic image analysis thing with a Bayesian classifier or whatever it is) |
| 00:55 | <Hixie> | my guess would be that it isn't true |
| 00:55 | <Hixie> | and that there is no corrolation between lack of alt text and importance of image |
| 00:55 | <othermaciej> | I suspect that images with missing alt show the same statistical distribution of decorative or non-decorative as images that do have alt |
| 00:55 | <Hixie> | right, what maciej said |
| 00:56 | <Philip`> | If you count the spacer and background images in http://canvex.lazyilluminati.com/misc/imgs.xhtml then there's quite a lot of decorative ones |
| 00:57 | <Philip`> | but it'd be easy for a UA to just ignore all files called spacer.gif |
| 00:57 | <Philip`> | "quite a lot" isn't very scientific, since I haven't bothered actually counting :-p |
| 00:57 | <Hixie> | most images are spacer gifs according to my surveys |
| 00:57 | <Hixie> | but they don't all have names like spacer.gif |
| 00:59 | <Hixie> | anyway |
| 00:59 | <Hixie> | you can tell if an image is a spacer gif quite easily |
| 00:59 | <Hixie> | it'll be 100% transparent |
| 00:59 | <Hixie> | so that can be one of the heuristics the spec talks about |
| 01:00 | <gavin_> | I'd imagine some people use spacers that are the same color as the background, too? |
| 01:00 | <Hixie> | my point is that i don't see that lack of alt text is any more of a legacy problem we face than is bad alt text |
| 01:02 | Hixie | looks |
| 01:04 | <Hixie> | (er, wc) |
| 01:04 | <jruderman> | gavin_: the heuristic could be "all the same color + opacity" |
| 01:04 | <gavin_> | yeah |
| 01:04 | <gavin_> | that just gets a bit more complicated :) |
| 01:04 | <gavin_> | (to implement) |
| 01:05 | <Philip`> | They're both problems, but it seems easier to solve the first problem (by identifying intentionally-omitted-alt with some new syntax, so authors can make sure their critical images don't get ignored by incorrect heuristics) than the second problem, and partially solving one problem is usually better than solving none (except when solving that problem takes far too much effort to be worthwhile and distracts from other problems :-) ) |
| 01:10 | <Hixie> | it's not clear to me that it is possible to identify intentionally-omitted-alt from lazily-omitted-alt. |
| 01:11 | <Hixie> | (or from ignorantly-included-alt) |
| 01:12 | <Hixie> | because tools tend to mix all three of those up |
| 01:23 | <Philip`> | It's not possible to identify them if the syntax for both is <img src=...> with no alt, so it'd need other syntax like <img noalt> or <figure><img></figure> or whatever |
| 01:23 | <Hixie> | i don't understand why the syntax makes things any better |
| 01:23 | <Philip`> | Then they'd still get mixed up and used wrong, but there should be some (imperfect) correlation between images-marked-as-important (with intentionally omitted alt) and images-which-are-important, so UAs can make more accurate guesses - they still have to guess, but they can guess better than with no extra information, and good authors can help their users by making UAs guess in the right direction |
| 01:23 | <Hixie> | what will stop people from using <img noalt> to shut up the validator? |
| 01:24 | <Hixie> | i guess i'm not convinced that it would really improve matters that much |
| 01:25 | <hober> | I suspect the primary use of @noalt would be to make the validator stop complaining |
| 01:26 | <Hixie> | in particular, i'm not convinced that if we added an <img noalt> or <img missing-alt> attribute, that well-meaning people would be able to tell the difference between <img alt=""> and <img missing-alt> or <img noalt>. |
| 01:26 | <Hixie> | and we would actually end up making it worse -- making images that are critical get explicitly marked as decorative (<img alt="">) |
| 01:39 | <Hixie> | othermaciej_: any news on the offline storage stuff? i'd like to spec a first draft soon |
| 01:42 | <othermaciej_> | Hixie: it's high on my todo list for the next few days |
| 01:43 | <othermaciej> | I think the basic model seems sound, I just want to think through some of the details (especially with respect to updating) |
| 01:45 | <othermaciej> | Hixie: if you want, I can come by and we can discuss with a whiteboard (maybe aa would be interested as well) |
| 01:46 | <othermaciej> | but I'll try to write up some comments first |
| 01:46 | <othermaciej> | Hixie: I'm very interested in having offline stuff in the spec soon |
| 01:46 | <Hixie> | cool |
| 01:47 | <Hixie> | yeah you're welcome to come over and discuss it |
| 01:47 | <aa> | othermaciej: yes, interested |
| 01:48 | <othermaciej> | Hixie, aa: would you guys be free this Friday around lunchtime and/or early afternoon, perhaps? |
| 01:49 | <Hixie> | friday is a non-starter for me |
| 01:49 | <Hixie> | as is monday |
| 01:49 | <Hixie> | pretty much any other time is ok though |
| 01:49 | <othermaciej> | my other free times are either next week or after 5PM on Thursday |
| 01:50 | <Hixie> | thursday works for me |
| 01:50 | <Hixie> | dunno about aaron |
| 01:51 | <aa> | I was planning on being out thursday |
| 01:51 | <aa> | the gears team was planning on taking a lazy approach to the spec because, well, we are super busy |
| 01:52 | <aa> | but we are interested, we were just going to forego having actual meetings in favor of email |
| 01:53 | <othermaciej> | I don't wanna have lots of meetings (the Safari team is super busy too, pretty much all the time) but it seems like one small one might help |
| 01:53 | <othermaciej> | ok then how about I'll send comments in email and we can sync up in person next week if we have time and think it's useful |
| 01:53 | <Hixie> | sure |
| 01:53 | <aa> | next week would be better for me |
| 01:53 | <KevinMarks> | There's a Google open house thursday night, so you may find the place crowded |
| 01:53 | <aa> | i have some comments i need to send to and i think michael nordman is going to send some too |
| 01:54 | <Hixie> | KevinMarks: that won't be an issue |
| 01:54 | <aa> | send too* |
| 01:54 | <Hixie> | k |
| 01:54 | <Hixie> | i encourage y'all to send comments soon, i want to have this wrapped up by the end of the month lest i miss my quarterly OKRs ;-) |
| 01:54 | <aa> | wrapped up, as in, a recommendation? |
| 01:55 | <Hixie> | wrapped up as in the people implementing this (you, webkit, mozilla) can go ahead and implement a first draft and give implementation feedback |
| 01:55 | <Hixie> | wrapped up the way that, say, canvas is |
| 01:55 | <Hixie> | (well maybe not quite that far) |
| 01:56 | <aa> | that is a little faster pace than we were anticipating. |
| 01:57 | <aa> | i guess you can go ahead and do that, but I'm not sure how much useful feedback we can give that quickly. |
| 02:00 | <Hixie> | k |
| 02:00 | <othermaciej> | yes, I'd also like the spec to be ready enough for preliminary implementation on something like that time scale, though it doesn't have to be final |
| 02:22 | <Hixie> | nothing's ever final really |
| 03:34 | <Lachy> | I fixed the comments on the blog for now |
| 03:34 | <Lachy> | but now I need to find a new comment preview plugin that actually works |
| 04:01 | <Lachy> | I added a working preview plugin to the blog :-) |
| 08:32 | <krijnh> | Lachy: You're the only one with green lines ;) |
| 08:32 | <Lachy> | really? |
| 08:32 | <krijnh> | Jep |
| 08:33 | <Lachy> | I see, others get grey text |
| 08:33 | <krijnh> | :) |
| 08:33 | <krijnh> | You wanted lime! |
| 08:34 | <Lachy> | I don't like the grey text though. Can I get mediumspringgreen with black text? |
| 08:34 | <Lachy> | or make it customisable, store the prefs in a cookie |
| 08:37 | <Lachy> | after the user submits their name, you need to respond with a 303 See Other response to redirect the user. That way, going back doesn't do another POST request |
| 08:38 | <krijnh> | Lachy: Done |
| 08:38 | <krijnh> | Hmm, that's new for me.. |
| 08:39 | <krijnh> | And I use Opera, so I never get that message anyway |
| 08:39 | <krijnh> | Do you have some docs on that 303 thing? |
| 08:39 | <krijnh> | http://krijnhoetmer.nl/irc-logs/#styling |
| 08:39 | <Lachy> | using PHP? |
| 08:39 | <krijnh> | Yeah |
| 08:41 | <Lachy> | header("Location: http://krijnhoetmer.nl/irc-logs/";, true, 303); should work |
| 08:41 | <krijnh> | Doh |
| 08:41 | <krijnh> | I'll just google for an article :) |
| 08:41 | <Lachy> | or http://www.php.net/manual/en/function.http-redirect.php if you have PECL available |
| 08:42 | <Lachy> | http://www.php.net/manual/en/function.header.php |
| 08:42 | <krijnh> | Yeah, I know how to use header() |
| 08:42 | <krijnh> | Just wanted to know some more about that 303 response :) |
| 08:42 | <Lachy> | RFC 2616 |
| 08:46 | <Lachy> | cool, it allows me to inject whatever styles I want for the whole page :-) |
| 08:48 | <krijnh> | Yeah :) |
| 08:48 | <hsivonen> | including JavaScript via XBL or HTC or expression() ? |
| 08:48 | <krijnh> | Probably |
| 08:49 | <krijnh> | Only htmlspecialchar'ed() the stuff |
| 08:49 | <krijnh> | 'ed().. |
| 08:49 | <krijnh> | Ke |
| 08:49 | <krijnh> | Remove it? ;] |
| 08:50 | <Lachy> | it doesn't really matter that much, since the injected code can only affect the individual user |
| 08:50 | <krijnh> | It can probably be used to spam the 'flag this line' functionality |
| 08:51 | <krijnh> | To make XHR requests |
| 08:51 | <krijnh> | But that can be done already |
| 08:51 | <Lachy> | krijnh, how? |
| 08:53 | <krijnh> | $('li span').click() in jQuery :) |
| 09:07 | <krijnh> | And comma separated nicknames also work now |
| 09:11 | <krijnh> | Philip`: Especially for you ;) |
| 09:18 | <hsivonen> | hmm. looks like Apple goes to great lengths on its site to present text as images without the <img> element in the DOM |
| 09:19 | <hsivonen> | Yet, in VoiceOver, the user experience is as good with <a href='...'><img alt='foo'></a> is it is with <a href='...'>foo</a> plus elaborate CSS hacks |
| 09:35 | krijnh | tests |
| 09:37 | <othermaciej> | hsivonen: examples? |
| 09:41 | <hsivonen> | othermaciej: the top navigation bar and the linked big iPod images read the same way (announced as links--nothing said about them also being images) |
| 09:41 | <hsivonen> | othermaciej: the top bar appears to be an elaborate CSS image replacement hack |
| 09:41 | <hsivonen> | othermaciej: the iPods in the center are normal image links |
| 09:41 | <krijnh> | zcorpan: "<zcorpan> krijnh: would be nice to pick up on /me lines also :)" - done |
| 09:42 | <zcorpan> | krijnh: nice :) |
| 09:42 | <othermaciej> | but there's text for the links? |
| 09:42 | <hsivonen> | othermaciej: yes |
| 09:42 | <hsivonen> | hmm. it might be that the motivation behind the CSS stuff is doing hovers |
| 09:47 | Lachy | just testing if this line gets highlighted in the logs |
| 09:48 | <Lachy> | cool, it works :-) |
| 09:49 | <Lachy> | krijnh, did you start filtering out '}' characters from the styles? |
| 09:49 | <krijnh> | O:) |
| 09:49 | <krijnh> | Btw |
| 09:49 | <krijnh> | "cool, it works :-)" <-- that would make _re="cool" |
| 09:49 | <krijnh> | I don't think that's cool |
| 09:50 | <Lachy> | well, you need better logic to check that the matched word is actually a user's name |
| 09:50 | <krijnh> | And how to do that |
| 09:50 | <krijnh> | Could compare previous lines |
| 09:51 | <krijnh> | But sometimes you just scream: foo: do this or that, expecting foo to read the logs and then react |
| 09:51 | <Lachy> | save a list of names from the <name> regex and then compare |
| 09:51 | <krijnh> | Even if foo isn't on the channel |
| 09:51 | <krijnh> | I was thinking of making a list of recent stuff said to you on the homepage |
| 09:52 | <krijnh> | Ow, wait, I need a use case first :) |
| 09:53 | <Lachy> | krijnh, that would be useful, because then we could send messages to people even when they're not logged in and they'll get them later |
| 09:53 | <krijnh> | Indeed |
| 09:53 | <krijnh> | I could use the nicknames in the box on the homepage |
| 09:57 | <krijnh> | There's an average of 3.1 important line per logfile btw :p |
| 10:07 | <krijnh> | Lachy, zcorpan, others, hit the save button for nicks on the homepage please :) |
| 10:08 | <krijnh> | Lachy: ty |
| 10:08 | <Lachy> | krijnh, are you keeping a list of users who register their nicks? |
| 10:08 | <krijnh> | Lachy: I am now, yes |
| 10:08 | <Lachy> | for the re_="" field? |
| 10:08 | <krijnh> | Yes |
| 10:09 | <Lachy> | can't you allow me to inject my own styles for the rest of the page any more? |
| 10:09 | <krijnh> | User stylesheets :) |
| 10:09 | <Lachy> | don't filter out } |
| 10:09 | <krijnh> | Keke, you win :) |
| 10:10 | <Lachy> | I suppose I could use a user stylesheet, but I'm lazy |
| 10:10 | <krijnh> | zcorpan: thanks :) |
| 10:10 | <Lachy> | thanks krijnh |
| 10:10 | <krijnh> | Now onto the fluffy stuff |
| 10:11 | <krijnh> | Howdy Hixie :] |
| 10:11 | <Lachy> | krijnh, I added Hixie |
| 10:12 | <krijnh> | Ow, hehe |
| 10:12 | <krijnh> | Why would you do that? :) |
| 10:12 | <Lachy> | I wanted to test out comma separated nicks |
| 10:12 | <krijnh> | Ah |
| 10:14 | <Lachy> | oh, when did you add the montly archive lists? |
| 10:15 | <krijnh> | While ago, anne came up with the idea |
| 10:15 | <Lachy> | ah, I never noticed :-) |
| 10:15 | <krijnh> | The homepage got a bit huge :) |
| 10:16 | <krijnh> | Lachy: test |
| 10:16 | <krijnh> | Lachy, test |
| 10:16 | <krijnh> | Lachy; test |
| 10:16 | <krijnh> | (This was bad for you ego) |
| 10:19 | <zcorpan> | does it matter that "cool, it works" generates _re="cool"? |
| 10:20 | <krijnh> | Sure |
| 10:21 | <krijnh> | Yeah |
| 10:21 | <krijnh> | <li id="l-277" _a="krijnh" _r="Lachy"><a href="#l-277">#</a> [11:24] <krijnh> Lachy, test <span> </span></li> |
| 10:21 | <krijnh> | \o/ |
| 10:21 | <krijnh> | cool: test |
| 10:21 | <krijnh> | zcorpan: test |
| 10:21 | <Lachy> | krijnh, are nicks compared case insensitively? |
| 10:21 | <krijnh> | lachy: don't know |
| 10:22 | <zcorpan> | lachy: test |
| 10:22 | <krijnh> | No |
| 10:22 | <krijnh> | And now, yes |
| 10:23 | <krijnh> | People should not add cool as a nickname ;) |
| 10:23 | <krijnh> | (zcorpan: just removed cool from the db) |
| 10:23 | <Lachy> | hey! That's why it's not working any more :-( |
| 10:24 | <krijnh> | :) |
| 10:24 | <cool> | can we get some default styling for the _r ? |
| 10:24 | <krijnh> | cool, Cool! Ideas? |
| 10:26 | <zcorpan> | well, bold works for me, although it might look ugly in some other fonts |
| 10:28 | <krijnh> | Same problem with _a styling |
| 10:31 | <krijnh> | There |
| 10:32 | <Lachy> | krijnh, I need you to stripslashes from styles so I can change set: font-family: "Lucida Console"; and use ENT_NOQUOTES |
| 10:33 | <hsivonen> | http://www.456bereastreet.com/archive/200709/can_the_alt_attribute_be_omitted_without_hurting_accessibility/#comment43 |
| 10:33 | <hsivonen> | the comments on that blog page are sad |
| 10:33 | <krijnh> | Lachy: refresh ? |
| 10:35 | <Lachy> | krijnh, it's outputting ol { font-family: \"Lucida Console\", monospace; } for my custom styles |
| 10:35 | <Lachy> | that's why I need stripslashes() |
| 10:35 | <Lachy> | in fact, magic quotes should be turned off completely |
| 10:36 | <krijnh> | I did stripslashes() |
| 10:36 | <krijnh> | Lachy: agreed, but can't do it anymore on this machine |
| 10:37 | <othermaciej> | hsivonen: weird comment |
| 10:37 | <Lachy> | well, here's my custom styles: background: lemonchiffon; color: black; } ol { font-family: "Lucida Console", monospace; |
| 10:38 | <Lachy> | it's still outputting the slashes for that |
| 10:38 | <krijnh> | Yeah |
| 10:38 | <krijnh> | I see |
| 10:38 | <krijnh> | Weird |
| 10:38 | <krijnh> | Ah, it's double slashed :/ |
| 10:39 | <krijnh> | It's probably saved with slashes in your cookie :) |
| 10:39 | <Lachy> | yeah, because you're not calling stripslashes when you set the cookie |
| 10:39 | <krijnh> | Indeed |
| 10:40 | <krijnh> | Am now, working |
| 10:40 | <krijnh> | Resave your settings |
| 10:41 | <Lachy> | that works |
| 10:50 | <krijnh> | And with all this user generated content |
| 10:50 | <krijnh> | There's now a Web2.0 logo |
| 10:53 | <krijnh> | Gonna make that list with recent lines for a user some other day :) |
| 10:54 | <Lachy> | krijnh, web 2.0 logos need to be BIG! |
| 10:54 | <krijnh> | Lachy: I know, but I don't want it to take up too much space |
| 10:55 | <Lachy> | make it a splash screen :-) |
| 10:55 | <krijnh> | :p |
| 10:57 | <hsivonen> | hmm. I wonder if I should sanitize characters in JSON output in an XML-compatible way to help client avoid shooting themselves in the foot |
| 11:00 | <Lachy> | hsivonen, which characters? |
| 11:01 | <Lachy> | hsivonen, is it possible to test out the json format yet? |
| 11:02 | <Lachy> | hsivonen, I don't think "400 Unsupported+output+format" is a conforming HTTP status code |
| 11:03 | <Lachy> | "400 Bad Request" should be appropriate |
| 11:06 | <Lachy> | hmm. I didn't realise RFC 2616 said "The reason phrases listed here are only recommendations -- they MAY be replaced by local equivalents without affecting the protocol." |
| 11:16 | <hsivonen> | Lachy: ASCII controls, U+FFFF and whatever else XML bans |
| 11:16 | <hsivonen> | Lachy: not testable yet. |
| 11:16 | <hsivonen> | Lachy: this is 1) spec, 2) solicit feedback, 3) respec, 4) implement |
| 13:05 | <Lachy> | http://www.isolani.co.uk/blog/access/ThePriceOfOmittingTheAlt |
| 13:05 | <annevk> | that's a nice article |
| 13:07 | <annevk> | the only thing that's a bit unclear is that he doesn't provide context for your quote, but maybe that's hidden because my browser (like most) doesn't expose <blockquote cite> |
| 13:07 | annevk | looks |
| 13:07 | <annevk> | ah, indeed, it's from http://blog.whatwg.org/omit-alt |
| 13:09 | <hsivonen> | /http://www.splintered.co.uk/documents/presentations/psf_accessibility_08.08.2007/ |
| 14:03 | <hsivonen> | do current browsers load scripts with HTTP content-type application/javascript |
| 14:03 | <hsivonen> | ? |
| 14:05 | <hsivonen> | http://wiki.whatwg.org/wiki/Validator.nu_JSON_Output |
| 14:09 | <krijnh> | http://krijnhoetmer.nl/stuff/javascript/mime-types/ |
| 14:09 | <krijnh> | hsivonen: is that helpful? |
| 14:10 | <hsivonen> | krijnh: yes, but not exactly what I'm looking for |
| 14:10 | <hsivonen> | krijnh: you test the type attribute |
| 14:11 | <hsivonen> | krijnh: I'm interested in HTTP content-type |
| 14:11 | <krijnh> | Doh, sorry |
| 14:11 | <Lachy> | hsivonen, IIRC, Firefox understands <script type=application/javascript> |
| 14:11 | <Lachy> | but if you want the MIME for JSON, it's application/json |
| 14:12 | <hsivonen> | Lachy: I'm trying to figure out the Right Thing for the callback case HTTP-wise |
| 14:12 | <Lachy> | I don't understand what you mean |
| 14:13 | <hsivonen> | Lachy: there's a non-quite-JSON design pattern of allowing a callback function name as a get parameter and wrapping the JSON stuff in a function call to a function of that name |
| 14:14 | <Lachy> | ah |
| 14:14 | <hsivonen> | callbackName({JSON-stuff}) |
| 14:14 | <hsivonen> | so the result is JS not JSON |
| 14:15 | <Lachy> | in that case, I think application/javascript would be the correct Content-Type to specify in HTTP. In practice, browsers ignore that anyway for <script> elements |
| 14:16 | <krijnh> | text/html works as well :) |
| 14:16 | <hsivonen> | Lachy: ok. I just wanted to check that it doesn't confuse IE |
| 14:17 | <hsivonen> | well, then. Next item: back end support for showing source code and extracts |
| 14:20 | <Philip`> | You can send text/vbscript to IE and it happily executes it as JavaScript |
| 14:22 | <hsivonen> | ok |
| 15:02 | <annevk> | hsivonen, maybe update the blog post too? |
| 15:59 | <hsivonen> | annevk: done |
| 16:04 | annevk | thinks that describing the Rorschach ink test (with alt=) might defeat the purpose of the test |
| 16:04 | <gavin> | heh |
| 17:46 | <ROBOd> | hello guys |
| 17:46 | <ROBOd> | i got to the 4.1. Browsing contexts section of the HTML 5 spec ( http://www.whatwg.org/specs/web-apps/current-work/multipage/section-windows.html ) |
| 17:47 | <annevk> | hi |
| 17:47 | <ROBOd> | hi annevk |
| 17:47 | <annevk> | btw, why would you use <select> for navigation? |
| 17:47 | <ROBOd> | (i was going to talk about Views, hehe) |
| 17:48 | <Dashiva> | annevk: It's a common practice for forums and such |
| 17:48 | <ROBOd> | i have used until thing like <form> <label>Go to page <select>....</select></label> <input type=submit> </label> |
| 17:49 | <ROBOd> | *until now (at least) |
| 17:49 | <ROBOd> | of course, i had something like onchange=this.form.submit() for the select |
| 17:50 | <annevk> | Dashiva, sure, seems better to have them change to <menu> though in due course |
| 17:50 | <ROBOd> | menu will be just another way to do this - i'd say it shouldn't be the *only* way |
| 17:50 | <annevk> | hmm, I'm generally in favor of less options |
| 17:50 | <ROBOd> | annevk: i don't say that's not true - it really depends how UAs will implement <menu> |
| 17:50 | <ROBOd> | if it sucks, web devs won't use it |
| 17:51 | <ROBOd> | now, back to my Views-related question(s) |
| 17:52 | <ROBOd> | first, i understand the concept that a Document (a single DOM) can have multiple views: the Visual view - what we see in the browser, the Speech view - the supposed view in Opera's X+V implementation, the Print View - the supposed view in UAs which have an option to print a document |
| 17:53 | <Dashiva> | annevk: How exactly, though? None of the menu modes seem to be very similar to a select |
| 17:53 | <ROBOd> | Dashiva: indeed - if they will render as a menu, we will still want to use <select> in some cases |
| 17:53 | <annevk> | Dashiva, I believe you just wrap your <select> inside <menu> |
| 17:54 | <ROBOd> | annevk: that's a semantic exaggeration :) |
| 17:54 | <annevk> | Dashiva, not entirely sure how an example would look like though |
| 17:54 | <ROBOd> | annevk: i would not wrap selects in menus - unless given a good reason |
| 17:54 | <annevk> | ROBOd, it's for fallback |
| 17:54 | <Dashiva> | annevk: I mean presentation-wise |
| 17:54 | <ROBOd> | annevk: obviously |
| 17:56 | <ROBOd> | back again to views: is there any document explaining DOM 3 Views? |
| 17:56 | <ROBOd> | it's waay to abstract - and I don't know if any major UA implements this (Opera, Gecko, Safari) |
| 17:57 | <ROBOd> | *Safari, make that WebKit |
| 17:58 | <Dashiva> | It looks more like java than javascript :) |
| 18:01 | <annevk> | I'm not sure what will happen to Views |
| 18:01 | <ROBOd> | hmm, views is an interesting concept - it should be properly defined |
| 18:01 | <annevk> | so far nobody has been really interested in implementing it |
| 18:02 | <ROBOd> | i'd imagine a "world" in which you can create new views with JS, in the UA, each view having any combination of stylesheets enabled/disabled |
| 18:02 | <annevk> | there's already an alternate style sheet api |
| 18:02 | <ROBOd> | as such, allowing the JS to check in each view the computed style (for example) |
| 18:02 | <ROBOd> | annevk: simultaneously? i haven't got to that, yet |
| 18:03 | <ROBOd> | annevk: also, can we instantiate the view, so the user gets to see both renders in the same time? |
| 18:03 | <ROBOd> | with a semi-shared DOM |
| 18:04 | <annevk> | as I said, nobody is really interested in implementing views |
| 18:04 | <annevk> | (it seems, anyway) |
| 18:04 | <ROBOd> | semi-shared because i'd like to check computed styles in both views in the same time - yet if the user changes the value of an input, both DOMs (and views) would be automatically updated |
| 18:05 | <Dashiva> | I don't really see the benefit, the use case seems so obscure |
| 18:05 | <ROBOd> | Dashiva: well ... the beneift for what I said is ... hard to figure out |
| 18:06 | <annevk> | i agree with Dashiva |
| 18:07 | <ROBOd> | the concept of views came in to life because multiple views of the same document do exist |
| 18:07 | <annevk> | in theory |
| 18:09 | <ROBOd> | not only |
| 18:09 | <Dashiva> | Can't you emulate it using mutation events anyhow? |
| 18:10 | <ROBOd> | as I understand Gecko has at least two internal representations of the same document, one for rendering (a "DOM of rendering"), and the actual DOM (what we call DOM) |
| 18:10 | <ROBOd> | internally, Gecko can reference both representations of the document |
| 18:10 | <annevk> | that has not much to do with views |
| 18:11 | <annevk> | that's simply a layout and document tree |
| 18:11 | <ROBOd> | it's a view as well - but not a rendered view |
| 18:11 | annevk | assumes most implements have that as CSS more or less requires it |
| 18:11 | <Dashiva> | No, that's more like two models and one view |
| 18:13 | <ROBOd> | thing is, if say, you'd be able to create two separate views (one for print, and the other for speech), you might want to make some adjustments for each, individually |
| 18:14 | <ROBOd> | modifying the actual DOM of the view |
| 18:14 | <annevk> | I think we're all aware of the potential things you can do |
| 18:14 | <annevk> | I don't think we all agree that the additional feature is worth the complexity and cost, etc. |
| 18:15 | <ROBOd> | but no implementation is available |
| 18:15 | <annevk> | my point exactly |
| 18:16 | <ROBOd> | i'm not saying the additional feature is worth the complexity and cost |
| 18:18 | <annevk> | in unrelated news: attribute value dependent parsing... boo |
| 18:19 | <annevk> | (otoh, we already have <plaintext>) |
| 18:26 | <Hixie> | Lachy: yt? i broke the wiki :-( |
| 18:26 | <annevk> | oops |
| 18:26 | <Hixie> | (i was upgrading it) |
| 18:33 | <annevk> | given he's around +10 I think he might be sleeping now |
| 18:49 | hsivonen | uses open browser windows to make backup of wiki-resident specs |
| 18:50 | <ROBOd> | no backups before trying to upgrade? |
| 18:54 | <hsivonen> | ROBOd: I didn't have backups. I don't know about Hixie. |
| 18:57 | <Philip`> | Maybe Google has backups |
| 18:58 | <ROBOd> | hsivonen: where's the wiki hosted? wiki.whatwg.org ? on dreamhost? |
| 18:59 | <annevk> | yup |
| 19:01 | <ROBOd> | if it's dreamhost they have automatic backups, snapshots |
| 19:01 | <ROBOd> | on any type of hosting. does whatwg use shared or dedicated hosting? |
| 19:02 | <annevk> | Hixie would know that |
| 19:02 | <ROBOd> | they have no automatic backups, afaik, for the databases, only for the files on the server |
| 19:03 | <ROBOd> | still, it's easy to setup a cronjob, with a simple command for dumping a database to a file, daily |
| 19:04 | <annevk> | I don't believe that's the problem though |
| 19:15 | <Hixie> | i'm sure the database is fine |
| 19:15 | <Hixie> | it probably just doesn't know how to handle the plugins we have |
| 19:34 | <Hixie> | sigh |
| 19:34 | <Hixie> | i reallly reallllly wanted to not make the parser dependent on attributes |
| 19:35 | <annevk> | i was wondering if form.elements could be populated during tokenization |
| 19:35 | <annevk> | but that doesn't really work as at that point you don't have dom nodes yet |
| 19:36 | <zcorpan> | are there pages that use <input> other than hidden in tables? (probably) |
| 19:37 | zcorpan | was thinking about allowing all <input>s in tables |
| 19:38 | <annevk> | yes, otherwise we would not have the issue |
| 19:39 | <Hixie> | we can't allow anything else, it would screw up the table |
| 19:39 | <Hixie> | <input type=hidden> is ok because it's display:none |
| 19:39 | <annevk> | Hixie, in the end, the big deal with the HTML parser is that it's documented :) |
| 19:39 | <Hixie> | IE's attribute-dependent parsing for <object> and that sucks |
| 19:40 | <annevk> | oh, you're thinking of doing more quirks if you go this way anyway? |
| 19:41 | <Hixie> | i'm thinking people will point to this and ask for more |
| 19:41 | <annevk> | not unrealistic |
| 19:42 | <jgraham> | if it's going to be implemented by the browsers anyway we may as well include it |
| 19:43 | <Hixie> | yeah the browser vendors didn't like my proposed alternatives so much |
| 19:43 | <zcorpan> | Hixie: it would, but if no-one does it, it doesn't matter... :) although, as i said, people probably have non-hidden <input>s in tables |
| 19:44 | <Hixie> | zcorpan: my point is that we can't solve that problem by changing the parser. the change only works for <input type=hidden> |
| 19:45 | <Hixie> | the other question is whether to actually make <input type=hidden> conforming there, or just make it a parser hack that is non-compliant |
| 19:45 | <Hixie> | i think non-compliant is probably best. |
| 19:45 | <zcorpan> | yeah |
| 19:46 | <zcorpan> | though perhaps doesn't need to be a parse error |
| 19:46 | <hsivonen> | aargh. Feisty ships with AddDefaultCharset UTF-8 |
| 19:46 | hsivonen | expect sniffing trouble down the road |
| 19:46 | <Hixie> | christ |
| 19:48 | <Hixie> | k, bbl |
| 19:48 | <annevk> | doesn't need to be a parse error |
| 19:48 | <annevk> | or maybe, because it's so ugly :) |
| 19:49 | <annevk> | "You enter the realms of attribute-value dependent parsing. Beware! Continue? [Y]" |
| 19:50 | <zcorpan> | so what requests can we expect because of this change? |
| 19:50 | <zcorpan> | allow forms and hidden inputs in head? |
| 19:51 | <annevk> | not sure about the former |
| 19:51 | <annevk> | apparently <object> is attribute dependent |
| 19:52 | <zcorpan> | in browsers other than ie? |
| 19:52 | <zcorpan> | (ie allows forms and hidden inputs in head) |
| 19:53 | <annevk> | don't think so |
| 19:56 | <zcorpan> | ie doesn't support changing the .type of an input dynamically to or from hidden |
| 19:57 | <annevk> | maybe it's represented by a different interface altogether? |
| 19:59 | <annevk> | ROBOd, no need to reraise issues on public-html |
| 20:00 | <ROBOd> | annevk: i was just thinking of that, but ... what should I reply to the guy asking? |
| 20:00 | <annevk> | ROBOd, dunno, just in case you were planning to do the same for other issues ;) |
| 20:01 | <annevk> | ROBOd, see http://www.whatwg.org/issues/ for a list of open issues; emails is part of it |
| 20:01 | <ROBOd> | for example? :D |
| 20:01 | <ROBOd> | ah, i forgot about the issues page, sorry |
| 20:02 | <ROBOd> | as you might have noticed, i don't contribute daily, i'm not among *the* most active contributors. i only follow the mailing-list and I contribute when time allows me |
| 20:03 | <ROBOd> | as for the input type=emails issue... that wasn't planned at all - i just mentioned it as being one suggestion which would be welcome to be applied to the WF2-spec once it's folded into HTML 5 |
| 20:06 | <annevk> | no worries |
| 20:07 | <ROBOd> | thanks :) |
| 20:22 | <ROBOd> | i have a question about "the list of added properties": http://www.whatwg.org/specs/web-apps/current-work/multipage/section-the-default0.html#list-of2 |
| 20:23 | <ROBOd> | does that refer to the global properties added to the window object by scripts executing in the global scope? |
| 20:23 | <ROBOd> | e.g. var myName = 'myValue'; |
| 20:24 | <ROBOd> | also, does this include things like document.myName = 'myValue'; as well? or just window.myStuff ? |
| 20:25 | <ROBOd> | last, but not least, if the answer is positive: then ... is the UA supposed to be able to (re)store "complex" properties like window.myStuff = function () { ... }; ? |
| 20:27 | <ROBOd> | hmm.. writing an email |
| 20:30 | <annevk> | I suppose it's something like that, yes |
| 20:30 | <Philip`> | krijnh: http://krijnhoetmer.nl/irc-logs/'s logo's alt text isn't an equivalent replacement of the image, since it doesn't get across the web-two-point-ohyness of the logo |
| 20:30 | <ROBOd> | annevk: still writing an email, because i think there's an interesting discussion about this |
| 20:31 | <ROBOd> | annevk: in relation to another part of the spec (session history) |
| 20:31 | <Philip`> | I expect it should be alt="HTML5 IRC Logsr (beta!)" or similar |
| 20:32 | annevk | would argue the image is a worse replacement |
| 20:32 | <annevk> | s/worse replacement/bad replacement for the text/ |
| 20:37 | <Philip`> | I suppose you should also add longdesc='data:text/plain,The words "HTML5 IRC Logs" in blue followed by a red "r", in parody of the Flickr logo, with a yellow star containing "BETA" and a faint mirrored image below, clearly created by a generic Web 2.0 logo generator tool.' else some people will miss the subtleties, but maybe that's just way too much effort :-( |
| 20:38 | annevk | is done with the table debate |
| 20:38 | <Philip`> | On the other hand, the generic logo generator tool could generate the generic longdesc too |
| 20:38 | <annevk> | if anyone wishes to continue the debate, have fun |
| 20:38 | jgraham | wonders how Leif expects to unambiguously determine what constitutes "bug free" when the HTML4 spec is loose enough to let not just bugs but also many larger species of animal through |
| 20:39 | <annevk> | yeah, whatever |
| 20:39 | <annevk> | feels like it's going nowhere |
| 20:45 | <Philip`> | http://www.cl.cam.ac.uk/local/web/guidelines/basichtml.html - '<hr/ width="50%" size="5">' in a guide on "Basic HTML tags" - I think they've got quite confused by XHTML |
| 20:47 | <jgraham> | Philip`: Next time someone brings up the "dumb authors" thing maybe pointing out that CS departments get it wrong will be interesting |
| 20:48 | <jgraham> | (where "interesting" means "fun to see what arguments are presented") |
| 20:49 | <hsivonen> | HTML isn't CS. it is multimedia. :-) |
| 20:50 | <annevk> | I wonder what I've done wrong though, Leif seems so offensive |
| 20:55 | <annevk> | it's also nice how they nest lists |
| 20:55 | <annevk> | or not |
| 20:56 | <Philip`> | It seems unfortunate that http://www.cl.cam.ac.uk/local/web/ucampas/ inserts a comment before the doctype and makes IE6 do quirks |
| 20:58 | <annevk> | through that uni website I found http://www.rewritables.net/htmltagchart.htm |
| 20:59 | annevk | stops reading to avoid getting dragged into '95 markup advocacy |
| 21:04 | Philip` | wonders how hard the ucampas tool tries to produce well-formed XML, and whether he could convince the author to output HTML instead, because it's fun to argue against XHTML |
| 21:04 | <Lachy> | I'll have to upgrade the wiki manually |
| 21:05 | <Lachy> | I restored the previous version for now |
| 21:08 | <jgraham> | Philip`: I have a feeling that the university house style is "XHTML" |
| 21:11 | <jgraham> | Aha here we go, from http://www.cam.ac.uk/cambuniv/webstyle/tech.html "The University webstyle templates (http://www.cam.ac.uk/cambuniv/webstyle/) are valid xhtml - the DTD at the top of the file declares the level of xhtml that the code is written to" |
| 21:11 | <annevk> | that's slightly better than what we have: http://www.cs.uu.nl/docs/vakken/cmc/ |
| 21:12 | <annevk> | maybe not: http://www.cs.uu.nl/ |
| 21:12 | <annevk> | (the site is horrible though) |
| 21:18 | <Philip`> | jgraham: Hmm, I've got no idea how strict they are on that style - the ucampas tool seems to be only used for cl.cam.ac.uk, and everywhere else does their own different thing, so maybe they're happy with anything that just looks consistent on the outside |
| 21:19 | <jgraham> | Philip`: Not strict at all; look at http://www.ast.cam.ac.uk (but only if you can stomach really bad design) |
| 21:19 | <annevk> | rubyonrails-core group on (X)HTML: http://groups.google.com/group/rubyonrails-core/browse_thread/thread/a1188ff42cd3fb59 |
| 21:20 | <annevk> | (bottom) |
| 21:22 | <Philip`> | http://web.archive.org/web/20060925113302/http://www.maths.cam.ac.uk/undergrad/ - hooray for frames |
| 21:23 | <Philip`> | (Sadly they've changed to the standard style now) |
| 21:23 | <annevk> | don't need archive.org for that: http://www.cs.uu.nl/education/ |
| 21:26 | <jgraham> | annevk: I assume you just linked to the rails thread because you are described as "standards uber-geek Anne Van Kesteren" ;) |
| 21:26 | <annevk> | yeah, that's real flattering |
| 21:27 | <annevk> | (I found the link after I found a blogspot site which seems to aggregate the feed searching for html5 on blogsearch.google.com) |
| 21:27 | <markp> | sigh |
| 21:27 | <markp> | same argument we had in habari-dev a few months back |
| 21:28 | <markp> | same argument people have been having for years |
| 21:28 | <markp> | there's no hope for this generation of web developers |
| 21:28 | <hsivonen> | markp: here in my SAX ivory tower, I have pluggable serializers |
| 21:28 | <markp> | (wordpress, RoR, etc.) |
| 21:28 | <gsnedders> | silly old people |
| 21:29 | <markp> | the best you can hope for is to influence the next generation |
| 21:29 | <gsnedders> | I'm telling you, we should allow anyone _my_ age into the current web. |
| 21:30 | <gsnedders> | (where "_my_ age" == 15) |
| 21:30 | <hsivonen> | interestingly, though, it appears that HTML5 being on the roadmap hadn't registered even after the HTML5 comment |
| 21:31 | <markp> | hsivonen: good for you |
| 21:31 | hsivonen | learns that the mod_jk load balancer is not smart enough to switch requests from one keep-alive pipe to another worker when the original worker no longer exists |
| 21:31 | <markp> | the rest of the world still uses string concatenation |
| 21:31 | <markp> | if they're really advanced, they use unicode string concatenation |
| 21:32 | <gsnedders> | unicode? that 16-bit standard? |
| 21:32 | markp | slaps gsnedders |
| 21:32 | <gsnedders> | (sorry, that's what I was taught at school) |
| 21:32 | <markp> | yeah yeah |
| 21:32 | <gsnedders> | oh, and US-ASCII is 8-bit |
| 21:32 | gsnedders | sighs |
| 21:32 | <gsnedders> | this is how I lose marks in exams :( |
| 21:32 | <ROBOd> | annevk: i found the answer to my question related to window properties. the answer is no, that's not what's happening. the spec actually says that the "custom window properties" (from the default view of the browsing context) is saved as a list of added properties in the document object, such that when the user/script goes *back* to the same document, the list of properties can be restored in the window object |
| 21:33 | <markp> | i fixed a bunch of unicode-related myths just before "dive into python" was released |
| 21:33 | <markp> | not sure if i ever fixed them in the online version |
| 21:33 | <markp> | so i'm part of the problem, spreading lies and misconceptions about unicode |
| 21:33 | <hsivonen> | markp: Klingon? :-) |
| 21:33 | <gsnedders> | markp: well they haven't reached my classroom :( |
| 21:33 | <markp> | silly rabbit, Klingon is not in unicode |
| 21:33 | <markp> | everyone knows that |
| 21:34 | <Philip`> | I feed data from a SAX parser into a DOM builder and stick bits of DOM together then convert the tree into a SAX stream and serialise it to disk and then copy-and-paste an HTML header onto it in a text editor, just for fun |
| 21:34 | <gsnedders> | what encoding do you use for Klingon, anyway? |
| 21:34 | <markp> | you have a clipboad? luxury... |
| 21:35 | <hsivonen> | gsnedders: UTF-8 plus de facto PUA mappings |
| 21:35 | markp | laughs at the iphone users without clipboards |
| 21:36 | markp | has an unpublished draft about accessibility issues in html 5 |
| 21:36 | <hsivonen> | markp: cool |
| 21:37 | <markp> | it needs... work |
| 21:37 | <annevk> | ROBOd, yeah, something like that is what I thought actually |
| 21:37 | <markp> | and lots of editing |
| 21:37 | <markp> | and probably some high-blood-pressure medication |
| 21:37 | gsnedders | wonders whether to waste more time trying to get Windows to install |
| 21:38 | <markp> | people still install windows? |
| 21:38 | <gsnedders> | sadly I need it for testing |
| 21:38 | <gsnedders> | and it's driving me insane. |
| 21:38 | <annevk> | as long as IE has market share :) |
| 21:38 | <Philip`> | Why install when you can use a pre-built VM image? :-) |
| 21:39 | <markp> | IEs4Linux, surely? |
| 21:39 | <gsnedders> | markp: I'm not on Linux :P |
| 21:39 | annevk | is running VM actually |
| 21:39 | <markp> | well, there's your first problem |
| 21:39 | <gsnedders> | I (stupidly) need Windows for some school things, too. |
| 21:39 | <hsivonen> | I just reconfigured DNS for html5.validator.nu to point to a new server |
| 21:39 | <gsnedders> | (Which is ironic as my teacher doesn't use Windows himself, and doesn't even have a copy) |
| 21:39 | <hsivonen> | please let me know if things break |
| 21:40 | <hsivonen> | validator.nu still points to the old place |
| 21:40 | gsnedders | sighs |
| 21:40 | <Philip`> | (Answer to earlier question: because the IE6/7 VM images are released for Microsoft's VirtualPC and you seemingly have to use the Windows version of VMware Workstation to convert them into a format which the VMware Player on Linux/etc can load) |
| 21:40 | <markp> | there were several things at ibm that only worked on windows |
| 21:40 | <gsnedders> | time for one final attempt |
| 21:40 | <annevk> | markp called my OS "Not Debian" at some point iirc |
| 21:40 | <gsnedders> | Philip`: I'm aware |
| 21:40 | gsnedders | sighs. time for one final attempt I think |
| 21:41 | <markp> | annevk: ? |
| 21:41 | <gsnedders> | I've already wasted hours. |
| 21:41 | <markp> | what OS was that? |
| 21:41 | <Philip`> | IEs4Linux is annoying since the main reason I want to test stuff in IE6 is to see if alpha-channel PNGs are working properly, and IEs4Linux doesn't support that |
| 21:41 | <gsnedders> | wish me luck (and my life, in case I get too annoyed). |
| 21:42 | <annevk> | markp, Ubuntu, but maybe it was someone else |
| 21:42 | annevk | can't find the reference |
| 21:42 | <markp> | i bear no ill will towards ubuntu |
| 21:43 | <annevk> | ah, http://diveintomark.org/archives/2006/06/26/essentials-2006 'Ubuntu, which is an ancient African word meaning “can’t install Debian”.' |
| 21:43 | annevk | got the quote wrong |
| 21:43 | <markp> | ah |
| 21:43 | Lachy | is attempting to update the wiki now, it will be temporarily broken |
| 21:43 | <markp> | that was actually a random quote i found on slashdot, iirc |
| 21:45 | <othermaciej_> | hey, that rails thing linked to my post, too |
| 21:48 | <Philip`> | Someone needs to teach GMail that dropping the " (Was: ...)" in the subject line does not mean the message is the start of a new discussion |
| 21:49 | <zcorpan> | Philip`: don't use the web interface of gmail :) |
| 21:53 | <Lachy> | successfully upgraded mediawiki, now I need to reinstall the extensions |
| 21:57 | <gsnedders> | time to follow the normal advice, me thinks. repartition HD :( |
| 21:59 | <Philip`> | gsnedders: Make sure you don't have any backups before repartitioning |
| 21:59 | <gsnedders> | Philip`: :) |
| 21:59 | <Philip`> | The exhileration of danger is good for you |
| 22:00 | <Philip`> | s/e/a/ |
| 22:00 | <zcorpan> | Tha? :) |
| 22:01 | <gsnedders> | at least it wasn't s/e/a/g (Tha axhilaration of dangar is good for you) |
| 22:03 | <Lachy> | the wiki upgrade is complete :-) |
| 22:05 | <Philip`> | These are a very special type of context-sensitive regexp that are highly irregular and cannot be computed without first implementing AI |
| 22:06 | <gsnedders> | :) |
| 22:12 | <annevk> | Hixie, no response from sebastian btw (re: question from you a day or so ago) |
| 22:13 | <gsnedders> | Is it fair to call the Tech Plenary "meetings"? |
| 22:14 | <annevk> | yup |
| 22:15 | annevk | -> bed |