| 00:20 | <Hixie> | hsivonen: not sure what to do about http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-July/012131.html |
| 00:59 | <Lachy> | Hixie, yt? |
| 01:00 | <Lachy> | Typo in the definition for the sizes attribute "If the specified, the attribute..." |
| 01:05 | <Hixie> | Lachy: fixed |
| 01:08 | <Lachy> | Hixie, why have you included 8192x8192 and 32768x32768 in the example? Aren't they a bit excessive? |
| 01:09 | <Hixie> | man, nobody understands my sense of humour :-/ |
| 05:31 | <MikeSmith> | heh |
| 05:31 | <MikeSmith> | comment on Mark Pilgrim's blog: |
| 05:32 | <MikeSmith> | commenter: I can’t help but think what an arrogant a$$ you’d have to be |
| 05:32 | <MikeSmith> | Mark replies: You must be new here. |
| 05:32 | <MikeSmith> | http://diveintomark.org/archives/2008/05/07/when-the-fall-is-all-thats-left#comment-12014 |
| 05:34 | <Hixie> | heh |
| 05:41 | <othermaciej> | I got into a stupid flamewar on reddit over Mark's post |
| 05:41 | <othermaciej> | I am embarassed for myself |
| 05:43 | <othermaciej> | hey roc |
| 05:43 | <roc> | hey |
| 06:06 | <Hixie> | othermaciej: uri? :-) |
| 06:06 | <othermaciej> | Hixie: I'm too embarassed |
| 06:08 | <Hixie> | heh |
| 06:09 | <othermaciej> | ok if you really want to see it it's here: http://reddit.com/info/6igdz/comments/ but the thread is downvoted so it's a little buried |
| 06:20 | <roc> | ok, now I have to guess which one of these people is maciej. that should be fun |
| 06:20 | <othermaciej> | my reddit nick is obvious |
| 06:20 | <doublec> | "That's like telling me to go ahead and rationalize away being so smart and good looking.: |
| 06:20 | <doublec> | hehe |
| 06:22 | <othermaciej> | I'm not entirely embarassed about that part |
| 06:22 | <roc> | oh, right. I'm just a reddit noob |
| 06:23 | <othermaciej> | just resorting to "do you know who I am?!?!?" at the end |
| 06:23 | <doublec> | well, he did ask |
| 06:24 | <doublec> | he didn't appear to believe you though - unless he really is the ff team lead. Somehow I doubt it. |
| 06:29 | <jwalden> | I, for one, welcome our new ff team overlord |
| 06:31 | <Hixie> | wow, that guy really was more of a jerk |
| 06:32 | <Hixie> | i love how he didn't reply :-) |
| 06:35 | <roc> | our Gecko team isn't that much bigger, actually |
| 07:16 | <Hixie> | hsivonen: i don't really understand what i should do to address http://www.w3.org/mid/01575703-3A06-4F51-BE27-86A9EBB44C54⊙if |
| 07:16 | <Hixie> | hsivonen: in particular, i don't know what to say about xmlns that isn't either obvious, or out of scope |
| 07:50 | <MikeSmith> | Hixie: r1577 typo : "keywods" |
| 07:50 | <Hixie> | thanks, in the queue |
| 07:51 | <MikeSmith> | and comment: might it better be, "User agents must process the links on a per-*keyword* basis" (instead of "per-link" basis) ? |
| 07:53 | <Hixie> | nah, it's per-link, not per keyword |
| 07:53 | <Hixie> | e.g. link rel="alternate stylesheet" is one link |
| 07:53 | <Hixie> | and <link rel="up up icon"> is two links |
| 07:54 | <MikeSmith> | ah, OK |
| 08:12 | <Hixie> | MikeSmith: i agree entirely with your mail... so... how do we get a changelog? :-) |
| 08:14 | <annevk> | morning |
| 08:15 | <Hixie> | heya |
| 08:15 | <Hixie> | how's xtech? |
| 08:15 | <Hixie> | i haven't seen any controversial blog posts about any hot happenings yet |
| 08:19 | <MikeSmith> | Hixie: we get it by somebody taking time to sit down and write it up |
| 08:20 | <MikeSmith> | which I can help with (or do alone if I have to) starting this weekend (when I get back home to tokyo from dublin) and first part of next week |
| 08:20 | <Hixie> | the working group hasn't had much luck waiting for things to happen that way |
| 08:20 | <MikeSmith> | yeah |
| 08:21 | <MikeSmith> | which is why I think to make sure it gets done I will probably need to be the one to write it up |
| 08:23 | <MikeSmith> | unless some magic shoemaker's elves or something sneak in and do it first |
| 08:23 | <annevk> | Hixie, crockford attended my presentation which gave some discussion |
| 08:23 | <Hixie> | annevk: ooh, do tell |
| 08:23 | <annevk> | the lightning talks were pretty funny |
| 08:24 | <annevk> | but there was no real new information :( |
| 08:24 | <MikeSmith> | Hixie: about XTech, Doug Crockford was at annevk session on Access Control spec, and we had a 15-minute discussion at the end of that |
| 08:24 | <Hixie> | what was there to discuss? |
| 08:24 | <MikeSmith> | er, what annevk just said :) |
| 08:24 | MikeSmith | types too slow |
| 08:24 | <annevk> | his claims that the spec should be abondoned |
| 08:24 | <annevk> | (art explicitly asked for his feedback at the end of the talk) |
| 08:24 | <MikeSmith> | yeah, "abandoned" was his exact word |
| 08:25 | <MikeSmith> | though he had great things to say about the cross-document messaging spec |
| 08:25 | <annevk> | also that we should solve everything with it and that lots of complexity for people like hsivonen is acceptable (hsivonen explained how easy Access Control was to implement for him) |
| 08:27 | <annevk> | other things: lightning talk introducing HTML5 concept from me and on HTML5 parsing from hsivonen |
| 08:27 | <annevk> | talk on RDFa that showed quite complex examples (the funny bit was that the namespace declarations were not shown which would've made it near impossible to grasp) |
| 08:28 | <Hixie> | sounds like the same thing as 2005 |
| 08:28 | <Hixie> | glad i didn't go |
| 08:35 | <annevk> | it was mostly meeting the other people that made it good |
| 08:36 | <annevk> | though some of the stuff was interesting too, such as what SilverLight is doing, how OAuth works, that OpenID 2 is incompatible with OpenID 1, etc. |
| 08:38 | <Hixie> | what's silverlight doing? |
| 08:39 | <annevk> | it was quite confused, but the interface stuff they're doing looks quite fancy |
| 08:39 | <annevk> | they're far ahead in ready components and all though libraries will solve that problem for us I guess |
| 08:40 | <annevk> | he also advocated against cross-browser scripting and all quite a bit |
| 08:41 | <annevk> | quite aggresively, I suppose, though he also said it wasn't about replacing Flash (yeah right) |
| 09:02 | <Hixie> | annevk: it's about replacing html, not flash |
| 09:04 | <othermaciej> | a little of both I think |
| 09:05 | <Hixie> | flash has like 2% of the content market tops |
| 09:05 | <Hixie> | they're doing a platform play, to replace their windows monopoly -- that means 98%, not 2%. |
| 09:06 | <roc> | I think it's both |
| 09:06 | <roc> | flash isn't dominant now, but they're afraid it could be |
| 09:07 | <Hixie> | oh i'm sure they're not ignoring it |
| 09:07 | <Hixie> | i just mean that that isn't their primary goal |
| 10:00 | Lachy | wonders how many sites actually use silverlight at all? |
| 10:01 | <Lachy> | I've only ever seen it used on microsoft.com, and I refused to install the plugin |
| 10:12 | <gsnedders> | writing unambiguous ABNF is hard. |
| 10:12 | <gsnedders> | (and the damned signal is broken so I'm stuck nowhere on a train) |
| 10:12 | <gsnedders> | (and we literally just started moving!) |
| 10:15 | <Philip`> | It ought to be possible to get tools that check ABNF for ambiguities |
| 10:15 | <Philip`> | No idea if such things exist, though |
| 10:15 | <gsnedders> | I don't think so, sadly |
| 10:16 | <Philip`> | You could write it in a real parser-generator language, and have that parser-generator check for ambiguity, then manually translate it into ABNF |
| 10:17 | <gsnedders> | I guess, but I'm lazy :) |
| 10:18 | <gsnedders> | (train stuck again, still not made it to Inverkeithing) |
| 10:18 | <gsnedders> | (hopefully will make it to Cam. by 16:00 though) |
| 10:18 | <gsnedders> | (certainly before I'm meant to meet you and jgraham_ though) |
| 10:23 | <othermaciej> | yacc or bison makes it pretty straightforward to write a checked grammar |
| 10:23 | <othermaciej> | (just make all the actions empty) |
| 10:24 | <Philip`> | http://ejohn.org/blog/processingjs/ |
| 10:24 | <gsnedders> | I'm not sure if I can bothered to learn another language, though |
| 10:24 | <gsnedders> | yacc is similar to BNF, no? |
| 10:27 | Philip` | sees that olliej (I think) already complained about how it uses ImageData non-conformingly |
| 10:27 | <Philip`> | (and also in a way that won't work if there's !=1 device pixel per canvas pixel) |
| 10:29 | gsnedders | wonders if anything actually uses the CRLF allowed in LWS in HTTP/1.1 |
| 10:30 | gsnedders | has only ever seen it in test-cases |
| 10:30 | <gsnedders> | (i.e., do I actually have to allow LF there?) |
| 10:50 | <gsnedders> | http://pastebin.ca/1012564 — header-value is what was causing me issues at making sure it was unambiguous |
| 10:51 | <gsnedders> | anybody able to check that? |
| 10:53 | <gsnedders> | (no, I don't trust myself) |
| 10:55 | <Philip`> | What does "unambiguous" mean? |
| 10:56 | <gsnedders> | free of anything that is unclear |
| 10:56 | <gsnedders> | i.e., it is completely clear |
| 10:56 | Philip` | hopes it just means there's a single parse tree for any input, else he's confused |
| 10:57 | <gsnedders> | well, in the case of ABNF, there's no character which could match more than one production where it is in the string |
| 10:58 | <gsnedders> | Philip`: I can give you an English lesson tonight, if you want :P |
| 10:58 | <othermaciej> | in the case of grammars, "ambiguous" means something more specific than clear/unclear |
| 10:59 | <othermaciej> | it means there's only one way to parse |
| 10:59 | <othermaciej> | if you use an ABNF-like LALR(1) parser generator, it will report shift-reduce or reduce-reduce conflicts in such cases |
| 10:59 | <othermaciej> | though it is possible the grammar isn't ambiguous but you have just hit a limitation of LALR(1) |
| 10:59 | gsnedders | sucks at defining English |
| 10:59 | <othermaciej> | still, it is a pretty good approximation |
| 11:00 | <othermaciej> | I do think yacc/bison would make for a good way to test a grammar |
| 11:00 | <gsnedders> | othermaciej: I have enough to do without learning even more :) |
| 11:00 | <gsnedders> | (languages, that is) |
| 11:00 | <othermaciej> | this grammar might be simple enough for lex to do it |
| 11:01 | gsnedders | has an English exam next week, and a French one the week after |
| 11:02 | <gsnedders> | othermaciej: Where do you come from, with a name like Maciej, BTW? |
| 11:02 | <othermaciej> | gsnedders: straight outta hell |
| 11:03 | <gsnedders> | othermaciej: Ah. OK. |
| 11:03 | <gsnedders> | (No, seriously?) |
| 11:04 | <gsnedders> | Doing it in ABNF gives me a reason to write an ABNF checker, that checks for ambiguities, though |
| 11:04 | <gsnedders> | Not that I'll bother, probably :P |
| 11:04 | <othermaciej> | yacc is just a tool |
| 11:05 | <othermaciej> | learning its (trivial) syntax is almost certainly easier than writing a program to parse a different syntax and do the same checks |
| 11:05 | <gsnedders> | yacc is just another tool you have to learn how to use :) |
| 11:06 | <Philip`> | Learning how to use a tool is much easier than making your own, and often it's easier than doing your work without the tool |
| 11:06 | <Philip`> | Also it's a good opportunity for procrastination |
| 11:07 | Philip` | has spent a lot of time playing with LaTeX when he's meant to be writing reports |
| 11:10 | <gsnedders> | That's true. I just end up playing around with type-setting maths in LaTeX :P |
| 11:13 | gsnedders | wonders how to do this without being ambiguous |
| 11:15 | <gsnedders> | I need to properly parse headers, while still allowing garbage headers |
| 11:16 | Philip` | doesn't notice any obvious ambiguity in the 'header' thing |
| 11:17 | <gsnedders> | Philip`: In what I linked? Good. |
| 11:17 | <gsnedders> | Now to make it far more complex and more likely wrong. |
| 11:18 | <gsnedders> | I want something like `invalid-header = *( header-content / lws ) [CR] LF`, but that is totally ambiguous |
| 11:18 | <gsnedders> | (combined with the valid header) |
| 11:22 | <gsnedders> | ("If a strict parser is in use, and anything is matched by the invalid-header rule, it is a fatal error.") |
| 11:22 | <Philip`> | ABNF is not a good way to do this :-p |
| 11:22 | <gsnedders> | It is mostly totally fine. |
| 11:23 | <gsnedders> | There are very few quirks like that |
| 11:23 | <Philip`> | Mostly, except for all the error handling |
| 11:23 | <gsnedders> | There's very little error handling at a parser level :) |
| 11:23 | <gsnedders> | It's mostly a case of either it is totally invalid, which is always a fatal error, or has a garbage as a header, which is a fatal error only in strict parsers |
| 11:24 | <gsnedders> | Once you start doing header specific stuff, then you get real quirks. But I'm not using ABNF for that. |
| 11:24 | <Philip`> | Seems easiest to say something like "If a prefix of the string matches 'header', then process it like a header. Otherwise, fatal error if strict, else skip to the next line" |
| 11:24 | <Philip`> | rather than trying to work out how to make a grammar rule that's a complement of another |
| 11:25 | <gsnedders> | It's actually really horrible to do using prose. I tried doing parts of it using prose, and it was far harder |
| 11:25 | <gsnedders> | I almost ended up using POSIX regex, as that not only has a format specification, but has negation, which ABNF does not |
| 11:26 | <Philip`> | Normal regexps only give you a boolean output, which isn't very useful when you want to get an HTTP header out of it |
| 11:27 | <gsnedders> | "Taking all matches and submatches of the header rule…" |
| 11:27 | <gsnedders> | or the "named header submatch" |
| 11:27 | <gsnedders> | It's certainly possible to do |
| 11:27 | <Philip`> | Just invent your own string-parsing grammar formalism |
| 11:28 | <gsnedders> | It's nicer to use ABNF as then I can just say, "This specification inherits all the rules from RFC3986, which as they are already given in ABNF they are not repeated here." |
| 11:29 | Philip` | goes away for a while |
| 11:29 | <gsnedders> | See you at 7, then |
| 11:29 | <Philip`> | Or 7:05 if I'm late |
| 11:30 | <Philip`> | It should only take me 24 minutes to get there, but I'm never very good at departing on time |
| 11:33 | <gsnedders> | Philip`: As long as you recognise me and James :P |
| 11:34 | <gsnedders> | Philip`: And I don't have a clue how long it takes me to get there, as I don't know where I'm coming from, and I don't know how long it takes to get around Cambridge |
| 11:44 | <gsnedders> | ABNF is too vague. It doesn't specify what to do if multiple alternations match a given input |
| 13:52 | <zcorpan> | Hixie: how about "HTML <code>Document</code>" and "XML <code>Document</code>"? |
| 13:54 | <zcorpan> | Hixie: that should make it clearer that it's about the dom and not a strem of bytes |
| 13:54 | <zcorpan> | s/strem/stream/ |
| 15:59 | <Hixie> | zcorpan: yeah maybe |
| 16:05 | <Hixie> | good to see the accessibility experts dismiss the problems hit by people using ATs... |
| 16:07 | <Lachy> | Hixie, are you referring to this? http://www.paciellogroup.com/blog/misc/uc/ |
| 16:07 | Lachy | is just reading it now |
| 16:14 | Philip` | assumes it's a reference to http://lists.w3.org/Archives/Public/www-archive/2008May/0016.html |
| 16:21 | <Lachy> | In the section Complex Data Images, in their proposal, it seems that they're using alt for text that would be more appropriate for either title="" or as an image caption. |
| 16:25 | <Lachy> | and it seems they didn't figure out what the example from the spec "Bubbles traveled everywhere with us" is actually a picture of. But I guess, it's a bit obscure from the caption. |
| 16:26 | <Lachy> | http://flickr.com/photos/carinda/1100670787/ Clearly, bubbles is a cat :-) |
| 16:27 | <Philip`> | http://lists.w3.org/Archives/Public/public-html/2008May/0079.html sounds like a reasonable argument that empty alt="" (as the spec requires) in those cases is bad, since it removes the distinction between purely decorative images (which you can happily ignore) and informative images (which you might want to see as text by default, but go to some extra effort to see when you decide the image is interesting) |
| 16:32 | <Lachy> | For those cases, I still like the kind="" attribute I suggested a few days ago, where for the example in the email, it would be: <img src="rendering-mode-pie-chart.png" kind="Pie Chart" alt=""> |
| 16:33 | <Lachy> | I don't like the importantimage attribute, since it's likely to suffer from copy and paste errors, and be included where it shouldn't, and it's harder to detect whether or not it should be there. |
| 16:33 | <Philip`> | Why is that better than <img alt="Pie Chart" importantimage>? It's worse because it hides the important image entirely from current UAs, and I'm not sure (/can't remember) what makes it better overall |
| 16:33 | <Philip`> | Ah |
| 16:34 | <Philip`> | importantimage won't suffer from copy and paste errors because nobody will ever bother using it and so it won't be copied :-) |
| 16:34 | <Lachy> | with an attribute that says a) what the image is and b) why it's important, errors are more likely to be detected, and it would be easy to analyse with hsivonen's image report tool. |
| 16:35 | <Philip`> | With the importantimage thing, the alt attribute says (in combination with its human-understable context) what the image is and why it's important |
| 16:36 | <Lachy> | but it also pretends that the text given is its alternative, when it isn't. |
| 16:36 | <Lachy> | it's entirely possible to have an important image with a good alt text supplied |
| 16:36 | <Philip`> | It doesn't pretend the text is an alternative, if the spec doesn't say that the alt text is necessarily an alternative |
| 16:37 | <Lachy> | yes it does |
| 16:37 | <Lachy> | that's the whole point of it. |
| 16:37 | <Lachy> | also, importantimage is a really bad name |
| 16:37 | <Philip`> | The point is to help users, and users might be better helped if alt text isn't always a strict alternative |
| 16:38 | <Philip`> | I agree that particular syntax isn't much good |
| 16:39 | <Lachy> | importantimage suffers from many of the same problems as noalt |
| 16:39 | <Lachy> | it's basically the same thing with a different name |
| 16:40 | <Philip`> | importantimage images will still have alt text, so non-hyper-intelligent UAs won't be totally stuck when trying to present the image textually |
| 16:41 | <Philip`> | and people won't stick in importantimage to make the validator shut up, because their pages will be equally machine-checkably-valid regardless of whether they have that attribute |
| 16:41 | <Lachy> | kind="" also gives additional information about the picture, which may not necessarily come from the alt text. http://krijnhoetmer.nl/irc-logs/whatwg/20080506#l-162 |
| 16:42 | <Philip`> | alt="A painting of a white house with ..." |
| 16:42 | <Philip`> | What are UAs meant to do with 'kind'? |
| 16:42 | <Lachy> | same thing they're supposed to do with importantimage, but also say what kind of image it is |
| 16:46 | <Philip`> | If all they're doing is serialising the alt and kind values and some connecting words into a text stream (like "Image type: Painting. The house is ..."), why not have authors put that whole serialised text into the alt attribute (alt="Image type: Painting. The ...") instead of adding the complexity of an extra attribute? |
| 16:48 | <Lachy> | a better example would be the flowchart one from the spec: |
| 16:48 | <Lachy> | <img src="images/parsing-model-overview.png" alt="The network passes data to the Tokeniser stage..." kind="Flowchart">. It would seem wrong to say alt="A flowchart illustrating how the network...". |
| 16:49 | <Lachy> | the UA doesn't need to read out the kind by default if there is alt text supplied. Only if the user asks for it. |
| 16:50 | <Philip`> | Why would the user want to know that the image a flowchart? |
| 16:50 | <Philip`> | Why would the user explicitly ask for it when it's going to say "no 'kind' was specified" for pretty much 100% of images? |
| 16:51 | <Philip`> | (I think your argument makes sense, but I'm not convinced yet :-) ) |
| 16:52 | <Lachy> | it depends how the UA indicates its presence, or what kind of UA it is |
| 16:53 | <Philip`> | It seems it would be useful to work from concrete examples of what some UAs could/would do, rather than just presenting some metadata and hoping someone else will figure out what to do with it |
| 16:54 | <Lachy> | for a screen reader, it could use any aural indicator to to indicate the presence of more information (like, e.g. a sound effect in the background as it's reading the alt text (probably a bell or tone of some kind) |
| 16:55 | <Lachy> | for a text only UA like Lynx, it could include it by default in the textual output somehow. e.g. [Image (Flowchart): The network....] |
| 16:58 | <Lachy> | I think screen readers should have done something similar things with other hidden metadata like longdesc. IIRC, users have to ask for it without knowing it's there in current implementations. |
| 17:00 | <Philip`> | Why would users of screen readers or Lynx want to know it's a flowchart? |
| 17:02 | <Lachy> | to help them decide if it's worth downloading and opening in external viewer, espcially if they want to zoom in on it to see it better |
| 17:07 | <Philip`> | I'm not sure why that would help them decide in a non-negligible number of non-contrived cases - I expect they would care about the information presented by the image (which they can find from the alt attribute) when deciding whether to look at it more closely, not about whether it's presented as a flowchart or a photo or a cartoon |
| 17:09 | <Philip`> | and it might be a photo of a flowchart, and the author will spend lots of time deciding what an appropriate 'kind' is, when actually it's a waste of time because it won't help people enough to be worthwhile |
| 17:11 | <Lachy> | it doesn't have to be used all the time |
| 23:38 | Philip` | 's hands are cold :-( |
| 23:39 | <jgraham> | Heh |
| 23:55 | <jwalden> | the latest opera beta didn't have new-style postMessage support, did it? |