| 00:04 | <Hixie> | might be a good idea to consider what the ideal ui for this rating control would be, for the non-visual user |
| 00:05 | <othermaciej> | webben: I don't think tristate is the right model for that |
| 00:05 | <othermaciej> | the mixed state of tristate checkboxes is supposed to be for when they represent state of a group of things that is currently mixed |
| 00:06 | <Philip`> | "Please say your rating of this image. [wait for voice input]" |
| 00:06 | <Philip`> | Uh |
| 00:06 | <Philip`> | s/image/movie/ |
| 00:07 | <jruderman> | does it know how to map "lame" and "awesome" to 1-5? |
| 00:07 | <Philip`> | It could be done like the old text adventure games, where you can define synonyms for all the inputs |
| 00:08 | <jruderman> | "Sorry, 'gay' is not a rating." |
| 00:19 | <webben> | jruderman: well, if aria resolved the widget to a select you could have that |
| 02:15 | <Hixie> | Philip`: voice output doesn't mean voice input |
| 02:17 | <Philip`> | Hixie: It also doesn't mean not voice input, so voice input is still an option for the UI |
| 02:18 | <Philip`> | and I never meant to imply that that was the only option |
| 02:23 | <Hixie> | typically non-video users don't use voice input, at least as far as i've seen, any more than video users |
| 02:31 | <Mook> | hmm, how do I figure out if a <video> is actively playing? specifically, I can't figure out the last two constraints in http://www.whatwg.org/specs/web-apps/current-work/#actively |
| 02:33 | <Hixie> | Mook: looking... |
| 02:33 | <Mook> | thanks :) |
| 02:35 | <Mook> | hmm, I suppose I could keep the error thing using a complicated system of listeners and hope I don't get out of sync (since HTMLMediaElement.error is the _last_ error, regardless if the video is now playing fine) |
| 02:35 | <Hixie> | Mook: what's the use case? |
| 02:35 | <Hixie> | i.e. why do you want to know? |
| 02:36 | <Mook> | Hixie: oh, just wrapping <video> to a different interface as a playback engine for something else |
| 02:36 | <Mook> | so, http://hq.songbirdnest.com:8080/source/xref/components/playlistplayback/public/sbICoreWrapper.idl#57 :) |
| 02:36 | <Hixie> | sure but what part of that interface needs to know if the video is actively playing? |
| 02:36 | <Hixie> | (as opposed to anything else in particular) |
| 02:37 | <Mook> | I think it's being used for some sort of UI thing or something. I don't have to care, that's what IDLs are for :p |
| 02:37 | <Hixie> | oh, you're trying to port one API to another |
| 02:37 | <Hixie> | i usee |
| 02:37 | <Hixie> | see even |
| 02:37 | <Hixie> | i don't think there's any easy to way to determine whether you're playing or not |
| 02:38 | <Hixie> | it's not clear to me what "playing" really means in the API you mention above though |
| 02:38 | <Mook> | even though it's defined as one of the terms to be used in the spec. fun! :) |
| 02:38 | <Hixie> | i.e. if you're playing when you're paused, are you also playing when you're stalled? |
| 02:39 | <Mook> | I believe in this API, yes |
| 02:39 | <Mook> | I think it's playing = !stopped. hmm, I suppose I can try that instead... |
| 02:40 | <Hixie> | yeah it's not clear to me that "playing" in your API is the same as "actively playing" in the HTML5 API |
| 02:41 | <Hixie> | actively playing in the HTML5 API is really just defined so that there's a way for me to say when the playback position should change |
| 02:41 | <Hixie> | you shouldn't really need to ever ask whether it's actively playing or not in theory |
| 02:41 | <Hixie> | you'll get timeupdate events at regular intervals, and other events when other interesting things happen |
| 02:44 | <Mook> | right. so I was just dumb in reading the non-whatwg API, and I really wanted to know currentSrc != "" && !ended && played.length > 0. thanks again :) |
| 02:57 | <Hixie> | Mook: :-) |
| 04:19 | <h3h> | would comments on an <article> belong in an <aside>? |
| 04:21 | <Hixie> | no |
| 04:21 | <Hixie> | <article> |
| 04:21 | <Hixie> | the spec mentions this case iirc |
| 04:21 | <h3h> | ah indeed. I see now |
| 04:21 | <h3h> | interesting |
| 04:24 | <h3h> | has anyone written an article along the lines of "How to mark up a blog in HTML5?" |
| 04:24 | <h3h> | if not, I might |
| 04:25 | <h3h> | s/?"/"?/ |
| 04:27 | <Hixie> | nobody has to my knowledge |
| 04:29 | <h3h> | hmm ok. I'll make an attempt at marking it up, then you guys can critique before I publish anything |
| 04:29 | <Hixie> | :-) |
| 05:46 | <h3h> | my first crack: http://pastie.caboo.se/183701 |
| 05:46 | <h3h> | it validates with Henri's validator, but I'm not convinced it's at all optimal |
| 06:12 | <myakura> | h3h: <span datetime ...> should be marked up with <time datetime ...> |
| 06:12 | <h3h> | ah good call |
| 06:14 | <myakura> | and charset, we now write it as <meta charset="UTF-8"> |
| 06:14 | <h3h> | got it |
| 06:15 | <h3h> | wasn't sure if there was a place for <section> anywhere |
| 06:15 | <myakura> | yeah, that's what i'm been wondering |
| 06:15 | <myakura> | and the same goes to <nav> |
| 06:15 | <h3h> | right. |
| 06:16 | <myakura> | oops s/span datetime/span class=datetime/ |
| 06:17 | <h3h> | yep :) |
| 06:17 | <h3h> | http://pastie.caboo.se/183712 |
| 06:20 | <myakura> | re sectioning, http://www.whatwg.org/specs/web-apps/current-work/multipage/section-sections.html#headings0 might help |
| 06:22 | <h3h> | yeah, that seems to indicate that using <body> as an implicit global section is fine |
| 06:28 | <h3h> | yeah: http://www.whatwg.org/specs/web-apps/current-work/multipage/section-sections.html#distinguishing |
| 06:28 | <h3h> | spells out exactly what I implemented, I think |
| 07:18 | <hsivonen> | it might be prudent to avoid an article about marking up a blog in HTML5 until there are UAs that support the semantics of the new elements |
| 07:19 | <hsivonen> | otherwise a zillion bloggers create a legacy of a bunch of new divs |
| 07:23 | <othermaciej> | which new elements? |
| 07:23 | <othermaciej> | I don't expect to be doing much with, say, "section" other than making it display as a block and maybe giving it a special accessibility role |
| 07:23 | <othermaciej> | it might actually end up with the same role as div though, at least on mac |
| 07:31 | <hsivonen> | othermaciej: section participates in the outline algorithm |
| 07:32 | <hsivonen> | and article should presumably affect the start-of-content marker in Opera Mobile |
| 07:36 | <othermaciej> | I don't really understand what the outline algorithm is supposed to do |
| 07:36 | <othermaciej> | it's spec'd in great detail but there's no requirement for what the UA is supposed to do with it |
| 07:36 | <othermaciej> | I don't think Safari presents a document outline to VoiceOver |
| 07:44 | <hsivonen> | othermaciej: isn't it a bug if it doesn't? |
| 07:45 | <othermaciej> | is it? |
| 07:45 | <hsivonen> | wouldn't you want to be able to browse the outline and navigate directly to headings from the outline? |
| 07:45 | <othermaciej> | I don't know that much about the VoiceOver UI |
| 07:47 | <othermaciej> | I can't figure out how to get it to read me a document |
| 07:49 | <hsivonen> | I think it doesn't have a "read onwards from here until I press a key". |
| 07:49 | <hsivonen> | that's really annoying |
| 07:50 | <othermaciej> | clearly it has some notion of navigation, but I don't know how to move the "voiceover cursor" the docs mention |
| 07:51 | <hsivonen> | othermaciej: if you focus the entire HTML content area and press VO-a, it'll read the whole document |
| 07:51 | <hsivonen> | where VO is ctrl-option |
| 07:51 | <hsivonen> | the cursor moves with VO-arrow keys |
| 07:52 | <hsivonen> | VO-shift-up/down navigates on the third axis |
| 07:52 | <hsivonen> | it appears that Safari+VO doesn't tell the user about tables |
| 07:53 | <hsivonen> | (I'd have non-blind use cases for "read onwards from here until I press a key") |
| 07:55 | <othermaciej> | where are the voiceover key commands documented? |
| 07:55 | <othermaciej> | do you know? |
| 07:55 | <othermaciej> | is it in help somewhere? |
| 07:55 | <othermaciej> | yeah, I don't think we expose tables properly (yet) |
| 07:55 | <hsivonen> | so of them are in a PDF from apple.com |
| 07:55 | <hsivonen> | s/so/some/ |
| 07:55 | <othermaciej> | unfortunately I think the AX API's table model may be based on RTF tables instead of HTML tables |
| 07:56 | <hsivonen> | some are in the voiceover tutorial utility which runs at installation and is available for later download from apple. |
| 07:56 | <hsivonen> | and then there's the help menu in the voiceover utility |
| 07:56 | <hsivonen> | I guess that's meant as the primary reference that comes with the software |
| 07:57 | <hsivonen> | and then webben gave pointers to third-party guides a couple of days ago |
| 07:58 | hsivonen | has too many browser tabs |
| 07:59 | <hsivonen> | othermaciej: http://krijnhoetmer.nl/irc-logs/whatwg/20080413#l-152 |
| 08:01 | <hsivonen> | Opera exposes tables to VO |
| 08:03 | <hsivonen> | the VO cursor's visual presentation breaks in Opera when in table |
| 08:59 | <MikeSmith> | I'm wondering if it should be considered an authoring conformance or abuse to put into a data-* attribute some content that is intentionally meant to be user visible (that ends up getting rendered in the main text flow of the page) |
| 09:00 | <othermaciej> | things in a data-* attribtue won't end up user visible, will they? |
| 09:01 | <othermaciej> | or do you mean put things in there that get extracted by script and then are made visible? |
| 09:13 | <annevk> | they won't (unless you use script / css / xbl ) |
| 09:16 | <MikeSmith> | othermaciej, anne: I meant the latter (extraction by a script) |
| 09:17 | <MikeSmith> | I can imagine people dropping content into data-* attributes because they want their source to validate but can't find anywhere appropriate to put it |
| 09:17 | <othermaciej> | it's no worse than retrieving content using XHR and dynamically inserting it into the page |
| 09:18 | <othermaciej> | people do use script for validation "workarounds" now |
| 09:18 | <othermaciej> | HTML5 imposes conformance requirements on the DOM tree, not just the markup |
| 09:18 | <MikeSmith> | OK |
| 09:18 | <othermaciej> | I'm not sure if any HTML5 validator will also act as a live DOM validator |
| 09:18 | <othermaciej> | but it would be cool |
| 09:19 | <annevk> | you could have plugins for browsers I suppose |
| 09:20 | <hsivonen> | othermaciej: I think it would be feasible to make a browser plug-in serialize the DOM and send it to a Validator.nu instance |
| 09:20 | <hsivonen> | (assuming that people don't want to build an in-process validator from scratch) |
| 09:20 | <othermaciej> | how does validator.nu get the source of a page in the first place? |
| 09:20 | <othermaciej> | in theory it could use a browser engine on the back end to build a DOM and validate that |
| 09:20 | <othermaciej> | though that would be a little silly |
| 09:21 | <hsivonen> | othermaciej: there are four ways to get the source: 1) get a URI and dereference, 2) textarea, 3) form-based file upload and 4) POST as entity body |
| 09:22 | <annevk> | it would be cooler if validation was live |
| 09:22 | <hsivonen> | #4 could work with XHR |
| 09:22 | <annevk> | so you interact with the page and you get errors logged to your developer tools |
| 09:22 | <othermaciej> | yeah, validation built into dev tools is cool of course |
| 09:22 | <hsivonen> | also, if you put V.nu in the browser process via JNI, you could traverse the DOM in C++ and fire SAX events to Java |
| 09:23 | <othermaciej> | but tying it to browsers means you might get wrong results based on the bugs of your particular browser |
| 09:23 | <othermaciej> | you'd want your browser to at least have HTML5-compatible parsing for starters |
| 09:24 | <othermaciej> | (or at least one good enough to correctly parse conforming HTML5) |
| 09:26 | <hsivonen> | and since the validation step doesn't need more than one thread per document, cutting out JNI and given C++ a GCC ABI should be doable with gcj |
| 09:26 | <hsivonen> | but with XHR, you can sidestep all the JNI and gcj trouble |
| 09:26 | <hsivonen> | s/given/giving/ |
| 09:28 | <annevk> | othermaciej, yeah, browsers would need to be fixed :) |
| 09:28 | <othermaciej> | I think if we integrated validator.nu into WebKit's dev tools it would probably be IPC to a separate process, or integration with the public server |
| 09:28 | <othermaciej> | (and integrating it certainly isn't out of the question) |
| 09:30 | <annevk> | yeah, since it's just a bunch of API calls maybe it isn't too bad |
| 09:30 | <hsivonen> | I been considering an idea of transporting line/col location data in XML comments over the process boundary |
| 09:31 | <hsivonen> | since you'd want to correlate errors with the data you started with somehow |
| 09:32 | <othermaciej> | that is true |
| 09:40 | <hsivonen> | For correlating with DOM nodes, you'd fire one event per node, set line to 1 and give the column a unique node-ID |
| 09:45 | <othermaciej> | you could just give each node a unique start line |
| 09:45 | <othermaciej> | (would have to account for newlines in text nodes or the like though) |
| 09:46 | <hsivonen> | I think a comment-based locator override would be more reliable |
| 09:47 | <hsivonen> | that way you could associate any numbers you want with an event |
| 09:47 | <hsivonen> | the problem with the apporoach I have in mind is that it uses XML to transport a DOM snapshot and XML can't transport all HTML DOMs |
| 09:48 | <hsivonen> | for vtab and ff, it isn't a problem for validation to send spaces instead |
| 09:48 | <hsivonen> | for crazy non-conforming element/attribute names, letting early failure to happen in the browser's serializer would be acceptable |
| 09:49 | <hsivonen> | I haven't yet investigated what happens if one tries to send an HTML DOM with XHR |
| 09:49 | <hsivonen> | it would be convenient if an XHTML serialization came out |
| 09:49 | <othermaciej> | HTML can't represent all HTML DOMs either |
| 09:50 | <othermaciej> | though maybe all those cases are also non-conforming |
| 09:50 | <annevk> | I hope not |
| 09:51 | <hsivonen> | annevk: I think they are since late December |
| 09:51 | <hsivonen> | annevk: except WF2 stuff, but WF2 hasn't been revised since December |
| 09:51 | <annevk> | I think SVG is still allowed DOM-wise for instance by the specification. But you can't serialize it... |
| 09:52 | <hsivonen> | I'm pretending that SVG is still in the spec :-) |
| 09:52 | <hsivonen> | but anyway, I think for IPC, XML would work better than text/html |
| 09:53 | <othermaciej> | would an SVG DOM that wasn't a possible output of the algorithm be conforming DOM-wise? |
| 09:53 | <hsivonen> | having an XML5 parser would fix the remaining issues |
| 09:53 | <othermaciej> | I would hope yes, but I'm not sure if the spec says/said that |
| 09:53 | <hsivonen> | I think it would be conforming. but I haven't look what the spec says |
| 11:21 | <annevk> | what might be useful for the alt= debate is finding sites that validate as HTML 4 or XHTML 1 something and have <img alt> somewhere |
| 11:22 | <annevk> | then do a content study on the values |
| 11:22 | <annevk> | given that 95% is invalid per some measure this may be hard, but maybe the W3C validator should be used as baseline |
| 11:26 | <Lachy> | annevk, do you mean like finding poor quality values like these alt="Wheel Chair Icon: Universal Icon Symbol of Accessibility" or alt="Magnifying Glass: Universal Icon Symbol for Search" http://www.webnauts.net/ |
| 11:27 | <Lachy> | or like these "howlers" http://web.archive.org/web/20060101014208/http://ppewww.ph.gla.ac.uk/~flavell/alt/alt-text.html#howlers |
| 11:32 | <annevk> | yes |
| 11:34 | <Lachy> | though, it is difficult to say whether any given poor quality alt text was supplied to address validity, SEO or just a poor, though honest attempt at addressing accessibility. Though it's clear that all of those reasons do occur |
| 11:35 | <Lachy> | I'm pretty sure that webanauts example was a misguided attempt to address accessibility |
| 11:35 | <Lachy> | but alt="spacer" would clearly be for validity |
| 11:36 | <Lachy> | or perhaps not. I don't know. |
| 11:44 | <hsivonen> | annevk: are you referencing HTML5 in your XTech paper? if you are, which version are you referring to? |
| 11:51 | <annevk> | i probably will, yes |
| 11:52 | <annevk> | i guess the w3c editor's draft and the whatwg multipage or something, dunno really |
| 11:52 | <annevk> | i'm writing my paper at the moment |
| 11:53 | <annevk> | are you giving an update on the validator? |
| 11:55 | <annevk> | the only problem is that nobody is giving an update on HTML5... |
| 11:58 | <hsivonen> | annevk: yes, I'll give an update on the validator |
| 11:59 | <annevk> | maybe i should submit a lightning talk on html5 |
| 11:59 | <hsivonen> | annevk: that would be a good idea |
| 11:59 | <annevk> | 20 slides on 20 new features since last year :D |
| 12:00 | <hsivonen> | hmm. looks like my last year's paper never got to the XTech 2007 site. |
| 12:08 | <annevk> | e-mailed a proposal for a lightning talk |
| 12:15 | hsivonen | doesn't like reference styles that obscure given names |
| 12:15 | <hsivonen> | is it E. R. Harold or E. Rusty Harold? that is, is Rusty a middle name or a part of the surname? |
| 12:16 | hsivonen | doesn't know what to do about Norwegian or Danish three-part names, either |
| 12:17 | <hsivonen> | hmm. he sometimes uses "Elliotte Harold", so I'm guessing Rusty is not an essential part of surname |
| 12:19 | <Philip`> | hsivonen: Rather than using text/html or XML for IPC, would it be reasonable to use some kind of serialised-SAX format (or make up one if it doesn't exist yet) to avoid all the limitations of HTML and XML parsers? |
| 12:19 | <annevk> | hsivonen, it could be part of the given name too |
| 12:21 | <hsivonen> | Philip`: well, given that XML parsers exist and an XML5 parser might exist, inventing yet another infoset serialization seems silly |
| 12:25 | <Philip`> | hsivonen: But XML parsers won't work, since they'll turn most pages into a single "fatal error: XML is not well-formed because of this thing here" message when the validator should instead try to identify as many errors as possible |
| 12:26 | <hsivonen> | Philip`: wouldn't XML5 fix that? |
| 12:26 | <Philip`> | XML5 doesn't exist |
| 12:26 | <annevk> | some kind of serialised-SAX format doesn't either |
| 12:27 | <hsivonen> | Philip`: yeah but the options are making XML5 exist or making yet another SAX serialization exist |
| 12:27 | <annevk> | XML5 is arguably more defined than the "some kind of serialised-SAX format |
| 12:27 | <annevk> | " |
| 12:28 | <Philip`> | XML5 is harder to bring into existence than some other totally-new unconstrained format, because it has to work within the limitations of being compatible with XML 1.0 |
| 12:30 | <Philip`> | and it's not that hard to define and parse some format like <element loc="1:1-2:20"><name>html</name><attribute><name>oops<char code="0c"/></name><value>that wasn't XML</value></attribute></element> |
| 12:35 | <jgraham__> | Couldn't you use something like the sdl thing that zcorpan developed? |
| 12:37 | <Philip`> | (http://simon.html5.org/specs/sdf ) |
| 12:40 | <Philip`> | That doesn't really exist either :-) |
| 12:51 | <hsivonen> | Philip`: from a parsing point of view, the easiest format would be a binary format which had an opcode for each event followed by known fields |
| 12:51 | <hsivonen> | Philip`: string would be 32-bit lenth followed by UTF-16BE data |
| 12:59 | <annevk> | It's more likely we see XML5 getting adoption than any of the named alternatives... |
| 12:59 | <annevk> | (Though for testcase purposes SDF is obviously preferable.) |
| 13:00 | <Philip`> | Adoption doesn't matter, since this is private communication between two programs written by the same people |
| 13:01 | <Philip`> | (and since widespread adoption in the future is not helpful when you want an implementation now) |
| 13:09 | <Philip`> | SDF is unsuitable for serialising arbitrary DOMs, since worst-case behaviour is that the minimal SDF representation has size O(n^2) in the size of the DOM |
| 13:09 | <Philip`> | (for a document like <x><x><x><x><x>....</x>...) |
| 13:51 | <annevk> | is Safari already cross-document messaging enabled? |
| 13:51 | hsivonen | experiences a horribly Feissian moment. Congratulates self about recent backup. |
| 13:56 | <Philip`> | hsivonen: It was, like, beep, beep, beep, beep, beep? |
| 13:57 | <hsivonen> | Philip`: It devoured my paper! |
| 14:03 | <annevk> | is it backed up entirely? |
| 14:05 | <hsivonen> | annevk: I lost about three paragraphs |
| 14:06 | <hsivonen> | I then discovered that my new NeoOffice setup didn't have automatic backups on by default... |
| 14:22 | <Philip`> | Sounds like a regression bug introduced during the move from typewriters to word processors |
| 14:29 | <annevk> | oh fun, Doug Crockford will be at XTech |
| 14:29 | <annevk> | guess i better address JSONRequest in my presentation |
| 14:35 | <hsivonen> | Philip`: I have more than one device producing keystrokes and I held the command key on one while another went crazy and produced a lot of keystrokes including a to select all, something to replace all with and s to save. |
| 14:36 | <Philip`> | Does 'save' clear the undo stack? |
| 14:36 | <hsivonen> | Philip`: no, but I didn't realize it had saved on top of all damage, so when Undo didn't look right, I reverted to saved... |
| 14:37 | <Philip`> | annevk: Safari 3.1.1 has window.postMessage === undefined, so I guess that means it's not present and enabled |
| 14:40 | <Philip`> | Hmm, recursive postMessage makes Opera unhappy |
| 14:40 | Philip` | kills it once it reaches 1.5GB of RAM |
| 14:40 | <annevk> | thanks |
| 14:45 | <Philip`> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0D%0A%3Cscript%3E%0D%0Afunction%20f()%20%7B%20window.postMessage('hello')%20%7D%0D%0Awindow.addEventListener('message'%2C%20f%2C%20false)%3B%0D%0Af()%3B%0D%0A%3C%2Fscript%3E |
| 14:45 | <Philip`> | Opera does seem pretty fast at using up all my memory |
| 15:10 | <gsnedders> | Browsers suck. |
| 15:11 | <Philip`> | 90% do, but there are few enough relevant browsers that that's equivalent to 100% |
| 15:13 | <gsnedders> | Philip`: my new print styles on my blog only properly work in Prince. Nothing else. |
| 15:13 | <gsnedders> | Philip`: Opera is the only browser anywhere close. |
| 15:15 | <Philip`> | Just use <link rel=alternate title=Print href=page.pdf> |
| 15:16 | <Philip`> | Also, who ever prints blogs? :-p |
| 15:18 | <gsnedders> | Hey, I have interesting stuff on my blog :P |
| 15:19 | <Philip`> | Being interesting doesn't mean anyone will want to print it |
| 15:30 | <gsnedders> | Philip`: I do… occasionally. |
| 15:31 | <gsnedders> | Philip`: And on grounds that nobody apart from me prints it out ever, I can use a stylesheet only supported fully by Prince :P |
| 15:33 | <annevk> | printing is bad for the trees |
| 15:34 | <annevk> | yet everytime i carefully not print my e-tickets they give me a paper one at the airport anyway... |
| 15:35 | <gsnedders> | annevk: sadly, I can't memorise entire essays that need to be handed in on paper |
| 15:35 | <annevk> | give them a floppy :) |
| 15:36 | <Philip`> | Hand in a small fragment of paper with a URL printed on it, and say it's semantically equivalent to the entire essay |
| 15:36 | <annevk> | gsnedders, congrats btw |
| 15:37 | Philip` | doesn't actually have a way to read floppy disks |
| 15:37 | <annevk> | cheap usb stick is prolly better these days |
| 15:37 | <gsnedders> | annevk: thx |
| 15:37 | <gsnedders> | Philip`: hah. |
| 15:38 | gsnedders | blames the SQA's requirements |
| 15:38 | <annevk> | Philip`, I like that idea |
| 15:38 | <gsnedders> | annevk: then what do I do about the exams on paper? |
| 15:39 | <annevk> | gsnedders, you're not the primary person responsible for using that paper |
| 15:39 | <annevk> | so either you try to fight the system or leave it alone I guess :) |
| 15:39 | <gsnedders> | annevk: The same applies for all the other things that needed to be handed in on paper, though :( |
| 15:39 | <annevk> | in those cases it's way more trivial to do something else |
| 15:39 | <annevk> | and see what happens |
| 15:40 | <Philip`> | gsnedders: You could print on vellum instead |
| 15:40 | <gsnedders> | annevk: half those things need to be sent off to the exam board, though, so I wouldn't know until it was to late, really |
| 15:42 | gsnedders | finds horrid photo of himself on bebo |
| 15:43 | <annevk> | geez, more hasFeature proposals |
| 15:43 | <gsnedders> | what do you expect? :P |
| 15:44 | gsnedders | wonders whether to go out with new lens on camera |
| 15:44 | jgraham | suggests gsnedders etches his essays onto vinyl and them records himself reading the essay as the sound track on the vinyl for accessibility purposes |
| 15:45 | <jgraham> | s/track// |
| 15:45 | <gsnedders> | jgraham: awesome. |
| 15:45 | <jgraham> | gsnedders: Which lens |
| 15:45 | <jgraham> | ? |
| 15:45 | <gsnedders> | jgraham: 10–22mm EF-S |
| 15:45 | <Philip`> | hasFeature only has problems because the feature support claims are made by the same people who implemented the feature, so they have a vested interest in claiming it is supported, and the return value is fixed at the same time as the feature is released, which may be before significant bugs are found |
| 15:46 | <jgraham> | gsnedders: Yes. |
| 15:46 | <gsnedders> | jgraham: I spent far too long discussing with cwilso whether to get that or the 70–300mm EF lens |
| 15:46 | <Philip`> | so the solution is a decentralised RDF-based model for specifying which browsers support which features |
| 15:46 | <jgraham> | gsnedders: He was right :) |
| 15:47 | <gsnedders> | jgraham: :) |
| 15:47 | <gsnedders> | jgraham: I know what I'm asking for my 17th birthday now :P |
| 15:49 | <annevk> | Philip`, your logic is getting more sloppy lately |
| 15:49 | <jgraham> | gsnedders: I have a theory that the Canon 70-300mm might not be worthwhile (although it depends what you are doing I guess). At least I hardly ever use my equivalent sigma lens because the range of apertures and lack of IS means that it requires really bright light, besides which it's just not that sharp |
| 15:49 | <annevk> | Philip`, though I suppose you could blame the channel :p |
| 15:50 | <Philip`> | annevk: What's wrong with my logic? :-( |
| 15:50 | <jgraham> | And I think that Canon falls into the same bracket |
| 15:50 | <jgraham> | unless it's not the one I'm thinking of |
| 15:50 | <annevk> | Philip`, your premise seems to be that hasFeature is actually needed |
| 15:50 | <annevk> | which is not necessarily true |
| 15:51 | <Philip`> | annevk: Some way of detecting that a feature is present and usable is actually needed |
| 15:52 | jgraham | suggests replacing hasFeature with featureHasSignificantBugs which would be defined to always return true |
| 15:53 | <Philip`> | and simply detecting the existence of the API is insufficient when you want to know whether the feature is usable |
| 15:53 | <annevk> | Philip`, also, with RDF you have two problems, so that doesn't help :) |
| 15:53 | <Philip`> | annevk: Two small problems are better than one large problem |
| 15:54 | <jgraham> | Philip`: RDF is a large problem :) |
| 15:54 | annevk | has difficulty verifying all Philip`'s axioms |
| 15:55 | <Philip`> | annevk: Axioms are by definition unverifiable - if you could verify them using a different set of axioms, then they wouldn't be axioms any more :-p |
| 15:55 | <annevk> | for instance, I typically assume support for a feature is present, when writing HTML, CSS, or JavaScript |
| 15:55 | <annevk> | Philip`, oops, your statements |
| 15:56 | <annevk> | and most often that is perfectly fine |
| 15:56 | <jgraham> | gsnedders: (to finish my thought from before if I were buying a telephoto lens today I would look seriously at the Canon 70-200 f/4 IS which should be sharp and work reasonably in more lighting conditions than the 70-300mm) |
| 15:57 | <jgraham> | Oh, wait the 70-300mm is one of the ones with IS, I was thinking of the 75-300mm |
| 15:57 | <jgraham> | Ignore me |
| 15:57 | jgraham | stops talking about cameras now |
| 15:58 | <Philip`> | annevk: Sometimes it's not perfectly fine, and you really do want to know whether it's safe (better performing, less buggy, etc) to use a browser's feature rather than emulating that feature with some other mechanism, particularly if you're writing cross-browser libraries |
| 15:59 | <annevk> | in those cases resorting to browser sniffing seems better as that's more reliable |
| 15:59 | <annevk> | and also gives more accurate information about perf etc. because of impl differences, etc. |
| 15:59 | <Philip`> | The problem with browser sniffing is that the sniffing code will be obsolete once a new browser is released |
| 16:00 | <Philip`> | and that problem can be avoided by using a fixed piece of code that never needs updating, and an external source of frequently-updated data that will ensure your code handles all browsers |
| 16:00 | <annevk> | if the new browser has bugs in its feature sniffing code you'll have issues too |
| 16:01 | <annevk> | it's not exactly black-white and since I think you actually agree with me and just love to argue i'll stop now |
| 16:02 | <Philip`> | I might agree but be wrong, so it's useful to consider alternatives :-) |
| 16:04 | <jgraham> | Philip`: It seems like you could collate, and update the data you want yourself and load it via XMLHttpRequest |
| 16:05 | <jgraham> | (You would need a way of determining a unique browser fingerprint that would deal with new versions well) |
| 16:09 | <Philip`> | jgraham: You'd probably also want to share the effort of updating the data between many people, rather than making everyone do the work individually |
| 16:11 | <Philip`> | (...kind of like WURFL, I guess) |
| 17:42 | <mpt> | hasFlavor() |
| 17:42 | <h3h> | you.hasAFlavor()? |
| 17:43 | <mpt> | true |
| 17:44 | <mpt> | if you.hasAFlavor() {return 'nom nom nom'} |
| 17:48 | <gsnedders> | jgraham: yeah, the 70–300mm has been written up _really_ well, as being as good if not better than a lot of L lenses |
| 18:08 | <jgraham> | gsnedders: It is very inconsiderate of Canon to make a crappy 75-300mm and a good 70-300mm and to expect me to remember the difference :) |
| 18:08 | <gsnedders> | jgraham: :) |
| 18:08 | <gsnedders> | Time for me to look at the photos he took in town |
| 18:09 | <gsnedders> | Advantage of living in a touristic town: you can easily try out cameras with photogenic stuff :P |
| 18:10 | <jgraham> | gsnedders: I guess I have no excuse in Cambridge |
| 18:11 | <gsnedders> | jgraham: no excuse at all |
| 18:11 | <gsnedders> | 112 photos |
| 18:12 | <gsnedders> | the sheer size of the field of view never stopped amazing me |
| 18:14 | jgraham | expects to see some on flickr :) |
| 18:14 | <takkaria> | it is a law that wherever there are geeks, there are cameras |
| 18:15 | <gsnedders> | jgraham: yeah, once I've cut most of them down to a far smaller number |
| 18:15 | <gsnedders> | (i.e., deleting the duplicates) |
| 18:16 | <jgraham> | gsnedders: Good. There was no way I was going to look through 112 photos |
| 18:16 | <jgraham> | :) |
| 18:16 | <gsnedders> | jgraham: There are c. 460 photos by me from Paris on Flickr :P |
| 18:16 | <gsnedders> | (from one week) |
| 18:16 | <gsnedders> | On one day on that week, I took over 1.1k |
| 18:16 | <gsnedders> | Actually, no |
| 18:17 | <gsnedders> | I wasn't anywhere near that high |
| 18:17 | <gsnedders> | Maybe 600 on one day |
| 18:17 | <gsnedders> | But normally around 500 a day |
| 18:18 | <jgraham> | People have different attitudes to their flickr stream. I would never consider putting 400+ photos up in one go; instead I'd probably try (often in vain) to select 4 that I didn't *hate* and put those up... |
| 18:18 | <gsnedders> | Ergh. I've got a shadow of me in one. |
| 18:19 | <h3h> | anyone up for an HTML5 markup usage critique? http://pastie.caboo.se/183712 |
| 18:19 | <gsnedders> | jgraham: I just wait until I've edited all the photos I've taken from a specific event, and labelled them, then upload all but the really bad ones |
| 18:21 | <takkaria> | h3h: you probably want <nav> instead of <ul id="navigation"> |
| 18:21 | <jgraham> | h3h: You're using <header> incorrectly |
| 18:21 | <jgraham> | I think |
| 18:21 | gsnedders | looks then realises he can't be bothered on his birthday |
| 18:22 | <h3h> | <nav> can't go inside of <header> |
| 18:23 | <h3h> | so unless <header> is wrong, I'm unsure |
| 18:23 | <jgraham> | h3h: Yeah, I think the header should just contain the title and subtitle (which you don't have) |
| 18:23 | <annevk> | h3h, make <nav> and <header> siblings? |
| 18:23 | <jgraham> | So I don't think you need <header> at all |
| 18:23 | <h3h> | just the h1 inside body is implicit header, right? |
| 18:24 | <jgraham> | h3h: It heads the body |
| 18:24 | <h3h> | right, which is the desire |
| 18:24 | <jgraham> | h3h: <div id="comments"> should probably be <section> |
| 18:25 | <gsnedders> | jgraham: 22 photos are good, and one bad one (so 22 get uploaded) |
| 18:25 | <h3h> | got it |
| 18:26 | <h3h> | does <b class="author"> seem reasonable? |
| 18:26 | <h3h> | it feels weird |
| 18:26 | <h3h> | also the <div class="content"> feels weird for the post and the comments |
| 18:26 | <jgraham> | I was going to say <div class="content"> seems unnecessary |
| 18:26 | <gsnedders> | h3h: <div class="content"> -> <section>? |
| 18:27 | <h3h> | then I have <section><article><section> |
| 18:27 | <h3h> | I guess that works |
| 18:27 | <gsnedders> | But I think they are probably useless |
| 18:27 | <gsnedders> | I'd probably just scrap them |
| 18:27 | <h3h> | I just need a container for style hooks |
| 18:27 | <jgraham> | h3h: I think <section><article><section> is OK |
| 18:27 | <gsnedders> | I'd lean towards <section> |
| 18:27 | <h3h> | to separate the data portion (typed text) from the UI portion |
| 18:28 | <h3h> | then I have headerless sections too |
| 18:28 | <h3h> | the spec says sections "typically [have] a header" |
| 18:29 | <jgraham> | The content area could (in principle) have a subheading like "Post" which is actually unneeded because it's implicitly obvious |
| 18:29 | <h3h> | yeah |
| 18:39 | <h3h> | Henri's validator is now failing to parse my datetime strings, though it worked last night and they adhere to the spec |
| 18:41 | <h3h> | http://pastie.caboo.se/183875 |
| 18:41 | <h3h> | now div-free |
| 18:42 | <h3h> | which feels eerily similar to being "table-free" several years ago |
| 18:45 | <hsivonen> | h3h: which dates? |
| 18:45 | <hsivonen> | h3h: if on ins/del, it's possible that Hixie changed a spec very recently |
| 18:46 | <Dashiva> | h3h: I don't see <header> there :) |
| 18:47 | <hsivonen> | h3h: oh, <time> |
| 18:47 | <hsivonen> | the spec before Z is the likely culprit |
| 18:48 | <hsivonen> | weird the spec indeed allows space there |
| 18:50 | <hsivonen> | Hixie: has "in attribute variant" of vaguer moments in time always allowed space characters |
| 18:51 | gsnedders | realises he can't be bothered to properly tag all his photos |
| 18:51 | <hsivonen> | Hixie: starting vaguer moments in attributes with skipping whitespace and letting that be valid is inconsistent with everything else |
| 18:51 | <Dashiva> | gsnedders: why do you hate accessibility :( |
| 18:52 | <gsnedders> | Dashiva: Because I'm lazy? |
| 18:52 | <gsnedders> | Dashiva: the new print styles for my blog break badly in most browsers :P |
| 18:52 | <gsnedders> | Prince ftw. |
| 18:53 | <Dashiva> | but that's equal-opportuntity breakage ;) |
| 18:53 | <gsnedders> | jgraham: http://flickr.com/photos/gsnedders/2427932055/ — that's the first one up |
| 18:54 | <takkaria> | Dashiva: even if gsnedders hates a11y, then flickr hates it more, so his hate is largely irrelevant |
| 18:55 | <gsnedders> | takkaria: No, I don't hate it. I'm just lazy when it comes to making purely visual content accessible to those who can't see/ |
| 18:55 | <takkaria> | gsnedders: I should have included <irony> tags |
| 18:55 | <Dashiva> | I too, probably |
| 18:55 | <gsnedders> | takkaria: Ah. My adult ones aren't tuned yet. |
| 18:55 | <hsivonen> | h3h: Hixie hasn't changed the spec lately, so I'm pretty sure I have outstanding feedback and I've implemented my opinion optimistically |
| 18:55 | <gsnedders> | takkaria: They've only been in use for just over 15 hours |
| 18:56 | <takkaria> | heh, just turned 18? |
| 18:56 | <gsnedders> | takkaria: 16 |
| 18:56 | <takkaria> | ah, nice. :) happy birthday |
| 18:56 | <hsivonen> | gsnedders: happy birthday |
| 18:56 | <gsnedders> | thx, both. |
| 18:56 | gsnedders | goes to get supper before heading off the cinema |
| 18:58 | <hsivonen> | h3h: yeah, I have outstanding feedback in Hixie's microsyntaxes-dates folder |
| 19:05 | <hsivonen> | I need to keep better track in my source comments about things that aren't per current spec but are per feedback |
| 19:14 | <h3h> | heh, cool |
| 19:16 | <h3h> | Dashiva: jgraham convinced me to take the <header> out :) |
| 19:20 | <gsnedders> | jgraham: http://www.flickr.com/photos/gsnedders/sets/72157604643134411/ |
| 19:20 | <gsnedders> | (It's now finished uploading) |
| 19:21 | <Philip`> | gsnedders: I think you need to add some starburst lens flare effects to make the photos more exciting |
| 19:21 | <gsnedders> | heh. |
| 19:21 | <takkaria> | gsnedders: do you have a polariser? |
| 19:22 | <gsnedders> | takkaria: no |
| 19:22 | <jgraham> | gsnedders: I think http://www.flickr.com/photos/gsnedders/2428004105/in/set is probably my fav. |
| 19:22 | <annevk> | gsnedders, try moving the horizon line a bit next time |
| 19:22 | jgraham | needs to get a polariser for his 10-22mm |
| 19:23 | <gsnedders> | jgraham: heh. Done on tip-toes (when I'm already 180cm tall) over wall :) |
| 19:23 | <gsnedders> | annevk: on any photo in particular, or not? |
| 19:23 | <takkaria> | gsnedders: I'd recommend one for photos with plenty of sky |
| 19:24 | <jgraham> | gsnedders: The standard advice is to put the horizon at ~1/3 from the top or bottom of the frame |
| 19:24 | jgraham | is rubbish at composition and art in general |
| 19:24 | gsnedders | ignores standard advice normally :P |
| 19:25 | <jgraham> | But photography is at least better than things that require fine motor skills |
| 19:25 | <jgraham> | :) |
| 19:25 | <gsnedders> | jgraham: Well, seeming I have dyspraxia and dysgraphia, that is a good reason for me to do to it :) |
| 19:26 | <takkaria> | gsnedders: I actually really like the first one |
| 19:27 | <takkaria> | though I'd be interested to see a similar photo taken lower down |
| 19:27 | <gsnedders> | takkaria: of the kitchen? |
| 19:27 | <takkaria> | yeah |
| 19:27 | <takkaria> | not sure why. :) |
| 19:27 | <gsnedders> | takkaria: That was just me making sure it all properly worked more than anything else ;) |
| 19:27 | <gsnedders> | That's my eye-level :P |
| 19:28 | <jgraham> | takkaria: It has that kind-of gritty real life quality about it, maybe? |
| 19:28 | gsnedders | should take photos of some really messy rooms in this house if you want real-life |
| 19:28 | <gsnedders> | actually, that's hard. some of them have so much it'd be hard to photograph. |
| 19:29 | gsnedders | thinks someone has forgotten that posts on walls show up on the homepage of friends on Facebook |
| 19:29 | <gsnedders> | "I love how geoffrey is in your top friends :) i see you staring at him in maths babes ;) xxx" |
| 19:29 | <gsnedders> | Why do I think I wasn't meant to see that? |
| 19:29 | <h3h> | heh |
| 19:29 | <takkaria> | gsnedders: even better when people write on their own walls by accident and the conversation ends there |
| 19:30 | <gsnedders> | takkaria: heh. |
| 19:30 | Philip` | wonders what a maths babe is |
| 19:30 | <gsnedders> | :P |
| 19:30 | <takkaria> | jgraham: I think it's because there's someone right in the middle of it all and seems rather set apart from the surrounding clutter |
| 19:30 | <gsnedders> | I probably shouldn't be quoting it in a logged channel, but hey. |
| 19:31 | <gsnedders> | (I actually know damned well the girl in question likes me in that way) |
| 19:31 | jgraham | suggests it's maybe a farmyard creature with a particular prowess for algebra |
| 19:32 | <gsnedders> | So many girls at my school are odd :) |
| 19:32 | <gsnedders> | Annoyingly, the girl that is to goes around claiming we're a couple. |
| 19:33 | <jgraham> | takkaria: Yeah, that is nice about it. gsnedders: I am jealous of your Aga. |
| 19:33 | <takkaria> | such a terrible thing, I'm sure. :) |
| 19:33 | h3h | doesn't miss the drama of school |
| 19:33 | <gsnedders> | Agas are fucking awesome. |
| 19:34 | <gsnedders> | Except in the summer. |
| 19:34 | <gsnedders> | Then they are fucking annoying. |
| 19:34 | jgraham | doesn't foresee ever being able to afford one |
| 19:34 | <gsnedders> | jgraham: Advantage of my parents buying it in the 1980s :) |
| 19:34 | <gsnedders> | (They've lived in this house since '84) |
| 19:35 | <Philip`> | Are the plates in the top left non-circular, or is that some kind of perspective distortion? |
| 19:35 | <gsnedders> | non-circular. |
| 19:36 | <gsnedders> | And covered in dust, actually. |
| 19:36 | <jgraham> | Philip`: There is also perspective distortion, I think |
| 19:37 | <gsnedders> | There is, but it doesn't affect the plates particually, I think |
| 19:38 | <gsnedders> | he left most one is the only one I think that is distorted |
| 19:39 | <gsnedders> | *the |
| 19:39 | <gsnedders> | the rest look reasonable |
| 19:42 | gsnedders | notes almost all his contacts on Flickr are geeks |
| 19:42 | <takkaria> | hello! :) |
| 19:43 | <gsnedders> | Actually, all of them are. |
| 19:44 | <takkaria> | that's because the set of geeks includes the set of people on flickr, I guess |
| 19:44 | <gsnedders> | I ought to finish writing what MikeSmith described as pornographic :P |
| 19:44 | <gsnedders> | (quoting stuff from it out of context does make it seem like that) |
| 19:45 | <gsnedders> | e.g., "Laying her hand on my right shoulder, she gently swung her body round on to mine, her delicate breasts digging into my chest, as she eagerly looked up at me." |
| 19:45 | <jgraham> | takkaria: Presumably you are http://flickr.com/photos/takkaria/ |
| 19:45 | <jgraham> | ? |
| 19:45 | <takkaria> | yup |
| 19:46 | <takkaria> | as far as I know, I'm the only takkaria on the web, and it's the only alias I use |
| 19:46 | <jgraham> | I thoroughly approve of any photostream that has holga stuff in |
| 19:46 | <takkaria> | :) |
| 19:46 | <takkaria> | I have a roll of 120 I need to process sometime soon |
| 19:47 | <gsnedders> | as far as I can see, I'm the only gsnedders online |
| 19:48 | <gsnedders> | And one of only two "Geoffrey Sneddon"s |
| 19:48 | <takkaria> | jgraham: my favourite Holga pic is http://flickr.com/photos/takkaria/500176177/in/set-72157600003720359/ |
| 19:48 | gsnedders | comes across http://quotes.burntelectrons.org/2972 looking for me |
| 19:48 | <takkaria> | though I have more I've not uploaded yet |
| 19:49 | <jgraham> | takkaria: I particularly liked that one and http://flickr.com/photos/takkaria/500176615/in/set-72157600003720359/ |
| 19:50 | <takkaria> | I like Holgas, they make uninteresting things interesting |
| 19:50 | <takkaria> | overlapping exposures ftw |
| 19:52 | <takkaria> | jgraham: what lens were you using for http://www.flickr.com/photos/jgraham/2374665153/? |
| 19:53 | <jgraham> | takkaria: Canon EFS-60mm Macro |
| 19:53 | <takkaria> | ah, nice |
| 19:55 | <annevk> | those quotes are funny |
| 19:55 | annevk | finds http://quotes.burntelectrons.org/2413 |
| 20:26 | <hsivonen> | Philip`: fixed http://validator.nu/?doc=http%3A%2F%2Fwww.coalitionforjustice.net%2F&showimagereport=yes thanks |
| 20:37 | <Philip`> | hsivonen: I can't remember what the problem was, but thanks for fixing it anyway |
| 20:54 | <hsivonen> | annevk: I added the onabort handler you requested. please let me know if it fixes whatever needed fixing |
| 21:06 | <annevk> | hmm, doesn't appear to be it |
| 21:07 | <annevk> | the specific problem is pressing "Esc" once you press validate |
| 21:10 | <Dashiva> | hsivonen: Maybe you could link the full image from the thumbnail. The coalition image is quite hard to make any kind of judgement about, seems most large images would have the same issue unless you know your images by heart |
| 21:11 | <Hixie> | hsivonen: i know you were just talking hypothetically, but if you were to make a binary format with strings, i'd recommend against have an explicit length marker for a field |
| 21:12 | <Hixie> | hsivonen: those are frequently misimplemented and end up being attack vectors |
| 21:13 | <takkaria> | bad string copying also frequently ends up as an attack vector, too, though |
| 21:13 | <takkaria> | I suppose it doesn't so much anymore |
| 21:13 | <takkaria> | (I mean with NULL terminators) |
| 21:14 | <Hixie> | i think i've seen problems with pre-announced buffer lengths more than with buffers that you have to search for the length of |
| 21:14 | <Hixie> | but i could be wrong i guess |
| 21:15 | <takkaria> | I think you're probably right but I thought it was worth saying anyway. :) |
| 21:16 | <hsivonen> | Dashiva: bug filed. I need to do *something* about large images at some point. thanks |
| 21:16 | <hsivonen> | Hixie: yeah, preannounced length could be used to trick the app to allocate insanely large buffers |
| 21:17 | <hsivonen> | annevk: in Opera? |
| 21:17 | <Hixie> | hsivonen: not to mention people getting confused with signed/unsigned and allocating a tiny buffer and reading a big buffer and all kinds of things like that |
| 21:17 | <hsivonen> | annevk: what page is large enough to show the problem? the spec? |
| 21:18 | <hsivonen> | annevk: did you reload to make sure you browser has the latest script, btw? |
| 21:33 | <annevk> | hsivonen, type in a url, hit enter, then hit Esc |
| 21:33 | <annevk> | hsivonen, any page will do as far as I can tell |
| 21:33 | <annevk> | tested in Opera and Firefox |
| 21:41 | <hsivonen> | annevk: yeah, I'm seeing the problem. |
| 21:41 | <hsivonen> | annevk: last lines of http://about.validator.nu/script.js |
| 21:41 | <hsivonen> | annevk: I set window.onabort |
| 21:41 | <hsivonen> | what am I doing wrong? |
| 21:42 | <annevk> | maybe onabort doesn't work the way I thought it did |
| 21:45 | <hsivonen> | is - forbidden in URI fragment, HTML4 ID or CSS ID or class selector? |
| 21:45 | <annevk> | no |
| 21:46 | <hsivonen> | yet, for some weird reason, the # target highligting breaks when - gets involved in ids, classes and selectors |
| 21:48 | <annevk> | if you start with - it might break stuff |
| 21:48 | <hsivonen> | I don't |
| 21:48 | <hsivonen> | still breaks |
| 21:49 | <hsivonen> | in Firefox 3b5, Safari 3.1.1 and Opera 9.5 beta something |
| 21:49 | <hsivonen> | aargh. Hixie's line offset request is more complex than it appears on surface |
| 21:49 | <Hixie> | really? |
| 21:49 | <Hixie> | wow |
| 21:50 | <hsivonen> | I'll deploy the broken state so you can try it out |
| 21:50 | <Hixie> | don't delay real improvements on my account :-) |
| 21:50 | <Hixie> | i figured it was just a matter of offsetting your parser's line count |
| 21:51 | <hsivonen> | Hixie: that would lead to badness, because -1 is magic in SAX |
| 21:51 | <hsivonen> | Hixie: it needs to happen much closer to output |
| 21:51 | <hsivonen> | so that all the internal calculation work without the offset |
| 21:51 | <Hixie> | wow that sucks |
| 21:54 | <annevk> | XMLHttpRequest spec in Korean (I guess): http://beyondweb.egloos.com/4304755 |
| 21:54 | <hsivonen> | Hixie: there's now &lineoffset= |
| 21:54 | <hsivonen> | Hixie: but CSS effects break when the offset is negative |
| 21:55 | <Hixie> | hsivonen: CSS effects? |
| 21:55 | <Hixie> | i'm using the text mode |
| 21:55 | <hsivonen> | Hixie: sure it should work in all modes |
| 21:55 | <hsivonen> | Hixie: consider http://validator.nu/?doc=http%3A%2F%2Fcafe.elharo.com%2Fweb%2Fmokka%2F&showsource=yes&lineoffset=-10#l-9c121 |
| 21:56 | <hsivonen> | and http://validator.nu/?doc=http%3A%2F%2Fcafe.elharo.com%2Fweb%2Fmokka%2F&showsource=yes&lineoffset=10#l11c121 |
| 21:56 | <hsivonen> | the only different is the sign of the offset |
| 21:56 | <hsivonen> | selectors match differently |
| 21:56 | <hsivonen> | sucks |
| 21:57 | <hsivonen> | hmm. or perhaps my regexp is wrong |
| 21:58 | <hsivonen> | that's it! |
| 21:58 | gsnedders | notes the guy that annevk said is the guy to ask for crazy regular expressions is around |
| 21:58 | <hsivonen> | ok. fixed |
| 22:00 | <hsivonen> | my grammar is getting bad. bed time |
| 22:06 | <Hixie> | is "non-document-error io: HTTP resource not retrievable" a validator.nu error, or a curl error? |
| 22:09 | <hsivonen> | Hixie: validator.nu error |
| 22:09 | <Hixie> | k |
| 22:09 | <Hixie> | i'm sending the wrong url it seems |
| 22:09 | <Hixie> | i don't suppose there's any chance of this being done via a <!--line 0 --> type pragma :-) |
| 22:10 | <Hixie> | i mean, really there are two files |
| 22:10 | <Hixie> | and it would be cool if it would give the right line numbers and file names for errors in each part |
| 22:10 | <hsivonen> | Hixie: not at the moment. I think I might do something like that in the future for IPC |
| 22:10 | <Hixie> | like a preprocessor |
| 22:11 | <Hixie> | k |
| 22:11 | <Hixie> | #file foo, #line 2 |
| 22:11 | <Hixie> | etc |
| 22:11 | <hsivonen> | Hixie: that'll confuse the Show Source thingy |
| 22:11 | <gsnedders> | poor little Show Source thingy |
| 22:11 | <gsnedders> | better give it a hug. |
| 22:12 | <Hixie> | hsivonen: yeah i figure it'd require pretty big changes if you have made assumptions throughout that that info isn't opaque |
| 22:12 | <hsivonen> | Hixie: there are two major assumptions: |
| 22:13 | <hsivonen> | #1: valid line numbers are >= 1 |
| 22:14 | <hsivonen> | #2: the first line of the resource whose source is shown is 1 and the lines progress by LF/CR/CRLF from there |
| 22:14 | <Hixie> | progress monotonically without reducing? |
| 22:15 | <hsivonen> | I comment-based pragmas with positive line number would work if I turned off source extracts and Show Source |
| 22:15 | <hsivonen> | Hixie: yes. The source code manager counts the line numbers on its own and the parser counts them on its own |
| 22:16 | <Hixie> | ah |
| 22:16 | <hsivonen> | but they are assumed to do it the same way |
| 22:16 | <hsivonen> | the source manager is fed raw UTF-16 before the parser gets to decide where the line breaks are |
| 22:17 | <hsivonen> | s/I comment-based/I think comment-based/ |
| 22:18 | <hsivonen> | also, the line number management inside the parsers is *hard* (surprisingly so) |
| 22:18 | <hsivonen> | so if I did pragmas, I'd fake the numbers immediately after the parser |
| 22:22 | <Hixie> | why not just carry two sets of file/line metadata throughout? |
| 22:22 | <Hixie> | one for internal use and one for presentation |
| 22:22 | <Hixie> | or just have a set of mappings which you invoke whenever outputting a line number |
| 22:23 | <Hixie> | that is, whenever you output a ui line number, you pass it through this one conversion function |
| 22:23 | <hsivonen> | (in order to make the source highlight nice and *correct*, the naïve standard SAX line location management doesn't work) |
| 22:24 | <hsivonen> | Hixie: that would be a lot of work for a use case that so far has only one user |
| 22:24 | <Hixie> | :-D |
| 22:24 | <Hixie> | yeah |
| 22:24 | <Hixie> | like i said, don't worry about it |
| 22:24 | <Hixie> | i didn't mean to slow down progress :-) |
| 22:24 | <Hixie> | i'm using hte offset you have now |
| 22:25 | <hsivonen> | and for the IPC case, show source would even make sense, so only location round trip would matter |
| 22:25 | <hsivonen> | s/would/wouldn't/ |
| 22:26 | <hsivonen> | so I think the pragma thing is likely to happen one day but it'll likely be mutually exclusive with source extracts and full show source |
| 22:26 | <Hixie> | makes sense |
| 22:26 | <Hixie> | my own use case doesn't care about the view source and source extracts either |
| 23:26 | <annevk> | Hixie, requiring title= on <abbr> is silly |
| 23:26 | <Hixie> | using <abbr> without title="" is silly |
| 23:27 | <Hixie> | like using <a> without href="" |
| 23:27 | <annevk> | you use <abbr> without title in the e-mail you sent |
| 23:27 | <annevk> | '<a href="#dhd"><abbr>DHD</abbr></a>' |
| 23:27 | <annevk> | <a> without href is allowed |
| 23:27 | <Hixie> | yeah i wrote that before i changed the spec |
| 23:27 | <Hixie> | yes, <a> is a poor analogy |
| 23:28 | <Hixie> | but it's basically only allowed for placeholders |
| 23:28 | <Hixie> | which makes no sense for <abbr> |
| 23:28 | <annevk> | i use <abbr> without title all the time |
| 23:28 | <Hixie> | why? |
| 23:28 | <annevk> | to indicate it's an abbreviation and not a word |
| 23:28 | <Hixie> | for the sake of it? |
| 23:28 | <Hixie> | isn't it obvious? |
| 23:29 | <Lachy> | do screen readers read things differently if they are marked up as <abbr>, even without title=""? |
| 23:29 | <annevk> | most of the time it probably is, though i wonder if it's worth making all that content non-conforming |
| 23:29 | <Hixie> | i'm sure the 6 people using <abbr> will be devastated |
| 23:29 | <othermaciej> | <pronoun>it</pronoun> <verb>seems</verb> <adjective>obvious</adjective> |
| 23:30 | <Lachy> | IIRC, Joe Clark recommends using <abbr> without title for repeated occurrences of an abbreviation. |
| 23:31 | <roc> | I had a paper rejected by the FOOL workshop |
| 23:31 | <Hixie> | i often disagree with joe clark |
| 23:32 | <Lachy> | so do I, but I agreed with him in this case cause it's more convenient |
| 23:32 | <Hixie> | more convenient than not using the element at all?? |
| 23:33 | <Dashiva> | othermaciej: you should be using rdf |
| 23:33 | <annevk> | Hixie, there's no harm in allowing <abbr> without title="" |
| 23:33 | <Lachy> | Hixie, it depends if there are legitimate advantages to using it |
| 23:34 | <Hixie> | the main use case for <abbr> is to provide expansions. by making title="" required, we help authors who use validators catch the occurances where they forgot to provide the expansion. |
| 23:34 | <Lachy> | I'm not saying there are such advantages, but I'm no expert on the UAs that would potentially benefit most from it |
| 23:36 | <Hixie> | as i said in the mail, speech synthesis technology these days is quite capable of determining what's an abbreviation and reading it without annotation, and the times where they are most likely to need <abbr> markup to help them (e.g. all-caps headlines), authors are unlikely to be providing it anyway. |
| 23:37 | <Lachy> | I haven't read the mail yet :-) |
| 23:37 | <annevk> | it's one of the reasons my weblog has the ability for markup in headings |
| 23:38 | <annevk> | though admittedly i don't seem to be using it for <abbr> too much these days |
| 23:39 | <annevk> | I've also stuff like only giving the first <abbr> thingie a title and not later on in the page |
| 23:40 | <Lachy> | I was just expecting you to fix the bugs with the cross-referencing, not remove it entirely |
| 23:40 | <annevk> | there have been recommendations to that effect in the past |
| 23:42 | <Hixie> | Lachy: heh |
| 23:43 | <Hixie> | i think the cross-referencing idea was just me getting a little too happy |
| 23:43 | <Hixie> | <a href=""> handles it fine in practice |
| 23:46 | <othermaciej> | the cross-referencing was overly complex as designed |
| 23:46 | <othermaciej> | it does seem like a cute feature if a simpler version turns out to be useful |
| 23:49 | <annevk> | the main use case would be spec writing |
| 23:51 | <othermaciej> | I do wonder if there are other use cases |
| 23:51 | <othermaciej> | because if something is only good for technical specifications then that's not a very broad use case |
| 23:51 | <Philip`> | I suppose there's a danger of spec writers writing specs that are biased towards helping spec writers |
| 23:53 | <Dashiva> | Would normative be an element or an attribute? |
| 23:53 | jgraham | is still wishes it was easy to reference numbered figures and tables in html |
| 23:53 | <Lachy> | Hixie, where you wrote this in the email: "It seems like we'd want to allow, e.g., a link to a list of instances of the term." |
| 23:53 | <Lachy> | "I have defined the opposite, though ..." - where exactly in the spec did you define that? It's not clear to me. |
| 23:53 | <Philip`> | I also suppose most specs get processed to generate the final published HTML version, so they can use whatever non-standard features they like in the source format and have the tools implement the conversion |
| 23:55 | <jgraham> | (with the numbers auto-updating as you add more figures and tables of course) |
| 23:55 | <Philip`> | jgraham: That sounds like it'd be a bit of a pain to do incremental rendering prettily, whenever you have forward references |
| 23:55 | <Hixie> | Lachy: what's the context again? i forget |
| 23:55 | <annevk> | jgraham, CSS should solve that, the markup should simply be pointers... |
| 23:55 | <annevk> | (not that it's entirely clear to me how exactly CSS needs to solve it yet) |
| 23:57 | <Lachy> | Hixie, in the mail, the quote from me beginning with "*Definitions with Links*" |
| 23:58 | Hixie | goes to find the mail |
| 23:58 | <Hixie> | Lachy: oh |
| 23:58 | <Hixie> | Lachy: dfn dection |
| 23:59 | <Hixie> | section even |