| 00:00 | <Hixie> | webben: i'm not discussing what conformance is _for_, i'm asking you for text that i can put in the spec that defines what a web page author should do when he wants to include a webcam |
| 00:00 | <jgraham> | webben: Conformance is about defining the technical consraints on what is allowed in a HTML document. It sets the boundaries on the syntax of the document, the ways in which that syntax may be combined and so on |
| 00:00 | <webben> | Hixie: Do you mean stills from a webcam when you say a webcam? |
| 00:01 | <webben> | jgraham: Yeah that's what conformance is. Not what it's for. |
| 00:01 | <webben> | e.g. one of the points Hixie made is about conformance to keep extension points open for future versions of HTML |
| 00:01 | <webben> | that makes some sense ... although conformance seems like a very weak stick for achieving that |
| 00:02 | <webben> | except in so far as it simply equates to carrots like data-* |
| 00:02 | <jgraham> | webben: I agree that conformance is a weak stick for achieving that |
| 00:02 | <Hixie> | webben: i mean a webcam page like, for instance, this one: http://www.menet.umn.edu/coffeecam/ |
| 00:02 | <Dashiva> | And we make it weaker the more we load onto it |
| 00:03 | <jgraham> | Dashiva: You type faster than me :) |
| 00:03 | <Dashiva> | I'm going to sleep now, so the stage is all yours in a bit |
| 00:03 | <Hixie> | webben: a page that shows an image that updates in realtime |
| 00:03 | <webben> | Hixie: If one were to try and establish best practice syntax for that with current tech, it would probably involve getting all the information you can get + indicating that that information may not be a "full" alternative. |
| 00:04 | <Hixie> | webben: what information could you get? |
| 00:05 | <Hixie> | webben: and how would you indicate it is not a "full" alternative? |
| 00:05 | <Hixie> | webben: could you show the markup you had in mind? |
| 00:05 | <jgraham> | webben: The inverse correlation (after a point) beween the difficulty of achieving confomance and the value that conformance is perceived to have is a real problem for proposals that seeks to impose stringent conformance requirements |
| 00:05 | <webben> | Hixie: I prefer the not-full-text-equivalent attribute type markers as a syntax. |
| 00:05 | <webben> | Hixie: what information you have depends on how frequently the scene changes |
| 00:06 | <webben> | Hixie: from the options I've seen so far. |
| 00:07 | <webben> | sorry "from the options I've seen so far", I prefer <alt="Webcam" no-text-equivalent>, but ideally with a bit fuller alt if you have more info. |
| 00:07 | <Hixie> | so if you have no information at all (e.g. it's a cam on someone's head) then you'd have: <img src=cam.jpeg not-full-text-equivalent> ? |
| 00:07 | <webben> | Hixie: No, I'd always include an alt. |
| 00:07 | <Hixie> | so <img src=cam.jpeg alt="Webcam" not-full-text-equivalent> ? |
| 00:07 | <Hixie> | how would you distinguish that from an image that just contained the text "Webcam" with fancy typography? |
| 00:08 | <jgraham> | Hixie: It has an extra attribute |
| 00:08 | <webben> | Hixie: you'd need fixed categories to do that. |
| 00:08 | <jgraham> | You could use user CSS or something to add a marker in the source |
| 00:08 | <Hixie> | jgraham: presumably the text "Webcam" wouldn't be a _full_ text equivalent for a fancy typographic effect of the text "Webcam" |
| 00:09 | <webben> | <img src="cam.jpeg" alt="Webcam on my head" not-full-text-equivalent type="webcam"> |
| 00:09 | <Hixie> | webben: how about instead of "not-full-text-equivalent type" and duplicating the word "webcam", we just use a {...} indicator? as in <img src=cam.jpeg alt="{Webcam on my head}"> ? |
| 00:09 | <webben> | or maybe the thing to do would be to mark images used for fancy typography instead! |
| 00:09 | <jgraham> | Hixie: Really? Did webben argue that or did someone else? |
| 00:10 | <Hixie> | (that's semantically equivalent, it's just a syntactic difference) |
| 00:10 | <webben> | Hixie: I don't think that's as understandable or as backwards compatible. |
| 00:10 | <Hixie> | jgraham: i'm arguing that :-) |
| 00:10 | jgraham | has pointed out why he doesn't like the curly braces before |
| 00:10 | <webben> | Hixie: but I agree, at that point it's a question of what syntax to use |
| 00:10 | <Hixie> | webben: it's actually more backwards-compatible, since it works in existing UAs without change. :-) |
| 00:11 | <webben> | Hixie: I don't count inserting {} as "working" |
| 00:11 | <jgraham> | Hixie: no-text-equivalent works in any UA that accepts user CSS |
| 00:11 | <Hixie> | anyway my point is that if that is acceptable, then we're basically (with minor syntactic differences maybe) at the point the spec is at |
| 00:11 | <jgraham> | It also doesn't change the semantics of existing documents |
| 00:11 | <jgraham> | Which isn't very "compatible" |
| 00:12 | <Hixie> | {..} is used rarely enough that it doesn't affect enough documents to matter either |
| 00:12 | <Hixie> | i checked |
| 00:12 | <Hixie> | before proposing it |
| 00:12 | <webben> | Hixie: yes, it's more a question of what use-cases it's meant to address. i.e. the statements about "best practice" the spec makes or doesn't make. |
| 00:13 | <Philip`> | Hixie: They're not equivalent forms with just syntactic differences, since you can't losslessly map <img alt={}> (in the no-text-equivalent attribute world) into the alt-surrounded-by-braces-means-no-text-equivalent world |
| 00:13 | <webben> | "enough documents to matter" is a worrying concept to me. |
| 00:13 | <jgraham> | Hixie: We went round this but I think the fact that it is used legitimatley makes it a bad idea. I also think it makes writing authouring tools unnecessarilly difficult |
| 00:13 | <webben> | especially when we're discussing conformance requirements. |
| 00:13 | <Hixie> | Philip`: ? |
| 00:13 | <webben> | "Conform to this to achieve the best effects ... until some future editor changes the spec and your particular communication isn't judged important." |
| 00:14 | <Hixie> | jgraham: *shrug* |
| 00:14 | <Hixie> | jgraham: i'm not convinced |
| 00:14 | <jgraham> | e.g. if flickr want to have a page shoing thumbnails with alt text title+username they need to check for the case that title tarts ith { and username ends with } |
| 00:14 | <Hixie> | jgraham: but i guess i'll see what evidence was put forward when i get around to the alt text feedback |
| 00:14 | <Hixie> | yeah but adding a whole attribute for this is just silly |
| 00:15 | webben | thinks that statement would be more persuasive if the underlying premises were clear. |
| 00:15 | <Hixie> | so i'm not convinced that the occasional clash is a problem really |
| 00:15 | <Philip`> | Hixie: If you have a document with "<img alt={} no-text-equivalent><img alt={}>", from a version of HTML that has the no-text-equivalent attribute, then you can't syntactically transform it into an equivalent document under the current HTML5 brace rules |
| 00:15 | <webben> | well, it's really a problem when there's really a clash. |
| 00:16 | <jgraham> | Hixie: I think the whole thing is rather silly and likely to be widely ignored but I think that designing somthing that is likely to be reliable when it is used is better than designing a system that we kno to be fragile if we bother designing anything at all |
| 00:16 | <Hixie> | Philip`: i don't understand why "<img alt={} no-text-equivalent>" would ever be valid in the version of HTML that has the no-text-equivalent attribute |
| 00:16 | <Hixie> | Philip`: what image would that be suitable for? |
| 00:17 | <webben> | didn't we establish images of some mathematical notation would be an example? |
| 00:17 | <webben> | or was that 100% speculative? |
| 00:18 | <jgraham> | Hixie: I am quite happy with making alt optional and forcing people who want their page to be accessible to actually put the work into checking that they have meaningful alt text here needed rather than just looking for a meaningless syntactic green light |
| 00:18 | <webben> | i.e. does { } not mean anything in maths? |
| 00:18 | <jgraham> | webben: There is a legitimate use case for putting TeX in alt |
| 00:18 | <webben> | jgraham: Yep, I'm not even talking about TeX though. |
| 00:19 | <Hixie> | jgraham: yeah maybe the kind of photo just isn't enough to make enough of a difference. but then people like webben will have a wobbly. |
| 00:19 | <webben> | e.g. { 5, 6, 7 } could be set notation maybe |
| 00:19 | <Hixie> | webben: such examples wouldn't have no-text-equivalent |
| 00:19 | webben | doesn't know enough about all the possible varieties of mathematical notation to make any clear guess. |
| 00:19 | <Philip`> | Hixie: Hmm, probably bad example - try "<img alt=Photo no-text-equivalent><img alt={Photo}>" (where the second image is the text "{Photo}" in a fancy font, hence that being the real text equivalent), which has no equivalent in the curly-braces-in-alt-are-special world |
| 00:19 | <webben> | Hixie: Then I don't understand your question. {} and no-text-equivalent are alternatives aren't they? |
| 00:20 | <Hixie> | Philip`: yes, if your legitimate alternative text is "{photo}", then you can't include it in the current way html is specified. |
| 00:20 | <jgraham> | webben: The current rule seems to be "if you want to be robust against curly bracs always add whitespace in your alt attribute value" |
| 00:20 | <webben> | Hixie: how is a ua supposed to distinguish between { 5, 6, 7 } and {photo} ? |
| 00:21 | <jgraham> | i.e. alt=" { 5, 6, 7 } " vs alt={Photo} |
| 00:21 | <Hixie> | webben: per the spec right now, you can't include alternative text {5,6,7}. that's the problem jgraham mentioned. |
| 00:22 | <webben> | well, also, it would mess up previously create alt text like that |
| 00:22 | <jgraham> | webben: That is another problem I mentioned |
| 00:22 | <jgraham> | :) |
| 00:22 | <Hixie> | adding an attribute for this is something that i don't think makes sense, because this isn't an important enough case to have a whole attribute. so that leaves special syntax, or making alt="" optional altogether. |
| 00:22 | <Philip`> | Hixie: That's also a problem if you know you have legitimate alternative text (e.g. you have a script that transforms text into images in a special font) and can't be sure it's never going to have curly braces, so it's a problem regardless of how frequently curly braces occur in practice, so claims that they are rare are irrelevant |
| 00:23 | <Philip`> | Attributes are cheap - you've already added an infinite number of them, via data-* :-) |
| 00:23 | <Hixie> | attributes aren't cheap |
| 00:23 | webben | really doesn't understand why unimportant case => special freaky syntax |
| 00:23 | <webben> | important case => normal attribute |
| 00:23 | hober | preferred omitting @alt entirely for this case |
| 00:23 | <Hixie> | Philip`: the point is that if the clashes occur rarely, then all that will happen is that occasionally, the UA will say "image" when it doesn't have to -- which, relative to the number of pages that don't include alt="" at all, will hardly be noticed. |
| 00:24 | <jgraham> | I think unusual syntaxes are more expensive than atributes |
| 00:24 | <webben> | they're more expensive for aspiring developers at any rate |
| 00:24 | <Hixie> | that's possible |
| 00:24 | <webben> | case in point: most HTML4 authors don't understand & in href |
| 00:24 | <webben> | s/most/many/ |
| 00:25 | <Philip`> | Hixie: The point is that (some) people will want to avoid any clashes at all - they want to write code that works properly, not code that works properly except in some rare cases - so they'll have to deal with this new complexity even if there's little practical effect |
| 00:25 | <webben> | newbies don't understand why some attribute values are space separated, some comma separated |
| 00:25 | <webben> | syntax is hard to learn |
| 00:25 | <jgraham> | (because most systems for processing and consuming HTML are set up to deal with attributes already but fewer can deal with arbitary microsyntaxes in attributes) |
| 00:26 | <Hixie> | ok so if we go back to allowing alt="" to be omitted, who wants to go back to the public-html list and let people know? |
| 00:27 | webben | doesn't see the advantage of omitting alt. |
| 00:27 | <Hixie> | brb |
| 00:28 | <webben> | in that not-fully-equivalent alts are (I think) much less of a problem that missing text for image links |
| 00:28 | <jgraham> | Philip`: By the way Anne and I talked about meeting up later in the week if ou are still free |
| 00:28 | jgraham | -> bed |
| 00:28 | webben | -> bus |
| 00:28 | <Philip`> | jgraham: How much later in the week? |
| 00:29 | <jgraham> | Philip`: Thursday or Friday |
| 00:29 | <jgraham> | probably |
| 00:29 | <Philip`> | I ought to be free around then |
| 00:29 | <jgraham> | I guess Anne has more constraints than me |
| 01:44 | <Hixie> | how on earth do you manage the caret with contentEditable |
| 01:44 | <tantek> | cursor property? |
| 01:45 | <Hixie> | i mean the position |
| 01:45 | <tantek> | you mean the selection range? |
| 01:45 | <tantek> | flashing caret is just a degenerate selection case |
| 01:45 | <Hixie> | is it? |
| 01:45 | <tantek> | this is a solve problem in HyperCard |
| 01:45 | <tantek> | solved |
| 01:46 | <Hixie> | i'm not using hypercard :-) |
| 01:46 | <Hixie> | i mean in WinIE and other contentEditable-supporting browsers |
| 01:49 | <Hixie> | apparently webkit's Selection object does indeed contain a selection when there is a caret position to report |
| 01:49 | <Hixie> | of course IE doesn't suppot getSelection() |
| 01:49 | <tantek> | I meant as a scripting language construct |
| 01:49 | <tantek> | the essential schema of caret+selectedText |
| 01:50 | <tantek> | Hixie, IE does support a form of GetSelection - I've written favelets that use it. |
| 01:52 | <Hixie> | yeah, it has some weird range object thing instead of hte DOM Range object |
| 01:52 | <Hixie> | ok well anyway |
| 01:52 | <Hixie> | looks like we could do with a better caret api |
| 01:53 | <tantek> | as a previous work reference, HyperTalk had/has "selectedChunk" - http://www.mactech.com/articles/mactech/Vol.04/04.06/HyperCard1.2/index.html |
| 01:56 | <Hixie> | why is window.getSelection().getRangeAt(0).setStart(document.getElementsByTagName('p')[0].firstChild, 2) not working |
| 01:56 | <Hixie> | grr |
| 01:56 | <Hixie> | (webkit) |
| 01:57 | <Hixie> | it kinda works in firefox |
| 01:57 | <Hixie> | doesn't work in opera or webkit |
| 01:57 | <Hixie> | sigh |
| 03:49 | <takkaria> | grr, JSON gets a scheme language: http://json-schema.org/ |
| 03:49 | <roc> | Hixie: you probably figured this out already, but the caret is just a degenerate ("collapsed") selection in Gecko |
| 07:58 | <MikeSmith> | hsivonen: v.nu still reports "Bad value “Content-Type” for attribute “http-equiv” on XHTML element “meta”" |
| 07:59 | <MikeSmith> | er, wait, oops |
| 07:59 | MikeSmith | does :set ft=html |
| 08:32 | <Lachy> | One more reason to hate Flash! http://blogs.zdnet.com/security/?p=1733 |
| 08:34 | <Dashiva> | haha |
| 08:34 | <Dashiva> | Highlighted user comment is WorkForMe(tm) |
| 08:35 | <Lachy> | Dashiva, I don't see that anywhere |
| 08:40 | <Dashiva> | Lachy: The talkback section |
| 08:42 | <Lachy> | Dashiva, I checked there. I didn't find any "WorkForMe" in there |
| 08:42 | <Dashiva> | "nothing wrong with firefox and yahoo. they work fine together. must be your computer. " |
| 08:44 | <Lachy> | oh, that's what you're referring to? ok |
| 08:44 | <Dashiva> | Oh, I see I left out the s in Works |
| 09:53 | <anne_> | mibbit.com is nice |
| 10:34 | <anne_> | Philip`, we can prolly meet Thursday / Friday still |
| 10:49 | Hixie | watches the csswg spend multiple people's time discussing issues that they should just have someone read all the arguments for and just pick the best decision |
| 10:54 | <hsivonen> | I don't really believe that my editorial general comment about WCAG leads to anything, but at least from now on when people ask if I've taken my concern to the WG, I have. |
| 10:55 | <hsivonen> | more influential people have complained about the same thing for years to no avail |
| 10:57 | <virtuelv> | Hixie: weird stuff happens here: http://software.hixie.ch/utilities/cgi/unicode-decoder/character-identifier?keywords=right |
| 10:57 | <virtuelv> | do an inline find for "hamza" |
| 10:57 | <virtuelv> | notice anything special? |
| 10:58 | <virtuelv> | hm, different behavior in Opera and Firefox |
| 10:58 | <virtuelv> | wth |
| 11:03 | <anne_> | Hixie, several are just reading e-mail |
| 11:16 | <hsivonen> | is there any reasonable documentation about feeding script-generated subtrees to Renesis or MathPlayer in IE? |
| 11:17 | <hsivonen> | is that even possible? |
| 11:38 | <Lachy> | LOL, this letter the pirate bay wants people to send to the sweedish minister of justice if funny. http://thepiratebay.org/lovetpb.php |
| 11:49 | anne_ | just realized that target=_blank is important for Web IRC and e-mail clients |
| 11:50 | <anne_> | (especially IRC) |
| 11:53 | <hsivonen> | all the bad stuff has good use cases |
| 11:55 | <gDashiva> | Maybe it's time for a change of attitude, and say "All the good stuff is bad for some use cases" :) |
| 11:55 | <Lachy> | I suppose, if you consider web based IRC to be a good idea |
| 11:56 | <hsivonen> | Lachy: shouldn't it be a good idea to provide Web-based implementations of anything? |
| 11:57 | <Lachy> | not everything is well suited to it. Some things really are better with native client side applications |
| 11:57 | <hsivonen> | better, sure |
| 11:58 | hsivonen | doesn't use a client side IRC app |
| 11:58 | <Lachy> | what do you use? |
| 11:58 | <hsivonen> | irssi over ssh |
| 11:59 | anne_ | uses mibbit at the moment as the default IRC port is blocked |
| 11:59 | <Lachy> | that's useful for maintaining a persistent connection. Though I'd rather do the same thing with a BNC server and a regular client |
| 11:59 | <hsivonen> | irssi over ssh works from both Mac and N800 |
| 12:00 | Philip` | used miau+mIRC for a while, but then gave up because it was rubbish and switched to ssh+irssi+screen |
| 12:00 | <hsivonen> | well, it kinda works from S60, too, but the text is tiny |
| 12:01 | <Lachy> | I tried psybnc on the weekend, but it did some things I didn't like, such as munging nicknames with the server prefix |
| 12:02 | <Lachy> | I'm going to try ezbounce later, and might try miau |
| 12:03 | <hsivonen> | the weirdest spec thing I've learned today: \u0000 is a permitted character in Java identifiers |
| 12:33 | <BenMillard> | zcorpan, do you still feel <dd> elements are better as alternatives to each other? |
| 12:34 | <BenMillard> | rather than a more loose interpretation, such as <li> has in <ul> |
| 12:40 | <jgraham> | Lachy: did you actually try mibbit? It's pretty good. |
| 12:40 | <Lachy> | jgraham, no |
| 12:40 | jgraham | has started using screen+irssi+ssh too fwiw |
| 12:43 | <wilhelm> | You should add mutt and vim to that list, and you'll never have to leave your terminal again. (c: |
| 12:44 | <jgraham> | heh |
| 12:44 | <jgraham> | vim is too confusing for me :) |
| 12:45 | <Philip`> | Vim is easy :-) |
| 12:45 | <Philip`> | Just press 'i' and then use it like a sensible text editor |
| 12:46 | <jgraham> | Philip`: I learnt to type :q and export EDITOR=emacs and after that I stopped learning anything about vim |
| 12:47 | Philip` | uses the mswin.vim thing to get sensible keybindings for clipboards etc since he can never remember the proper Vim ways to access those features |
| 12:48 | jgraham | wishes emacs used either perl or python like regular expressions |
| 12:48 | <zcorpan_> | BenMillard: dunno, do you have data that suggests otherwise? |
| 12:49 | <zcorpan_> | BenMillard: i looked at your collection btw, pretty impressive |
| 12:49 | <BenMillard> | zcorpan, thanks...it's very rough at the moment :P |
| 12:50 | <zcorpan_> | yeah |
| 12:50 | <BenMillard> | I haven't studied it in detail, but I'm wondering about the markup I should use for the collection |
| 12:50 | <BenMillard> | many of the entries will have more than one piece of description |
| 12:51 | <BenMillard> | the the tables study, I took your interpretation and used <dd><ul><li>: http://projectcerbera.com/web/study/2007/tables/ |
| 12:52 | <BenMillard> | but I'm not sure if that nesting is really helpful |
| 12:52 | <zcorpan> | probably isn't |
| 12:53 | <Lachy> | wtf? crazy people using terminal based text editors like vim?! |
| 12:54 | <BenMillard> | zcorpan, ok, I'll use whatever looks best when styling is disabled :P although that might well be the nested version |
| 12:54 | Lachy | uses TextMate |
| 12:54 | <virtuelv> | ed is good for you |
| 12:54 | <BenMillard> | I wanted to ask you first to ensure I wouldn't doing something incredibly dumb either way |
| 12:56 | <Philip`> | Lachy: I actually use Gvim instead, so it isn't terminal-based :-) |
| 12:56 | <Philip`> | It's got menu bars and toolbar buttons and everything |
| 12:57 | <zcorpan> | BenMillard: hey you're probably wiser than me about these issues :P |
| 12:57 | <BenMillard> | zcorpan, lol :D |
| 12:57 | <virtuelv> | jgraham: you want <ESC> :q! |
| 12:58 | <BenMillard> | zcorpan, I saw your Standards Suck interview about XHTML...you speak exactly as I imagined you would |
| 12:58 | <Lachy> | wtf? crazy people using non-terminal based text editors like Gvim?! :-) |
| 12:59 | <zcorpan> | BenMillard: cool |
| 13:00 | <virtuelv> | my text editor uses gecko |
| 13:00 | <virtuelv> | how crazy is that? |
| 13:00 | <Philip`> | virtuelv: Very |
| 13:00 | <BenMillard> | will HTMLWG be having a meeting somewhen? I can only see stuff about last year's one one http://www.w3.org/html/wg/ |
| 13:01 | <BenMillard> | as in an F2F |
| 13:04 | <virtuelv> | Philip`: doing XHR from an editor macro is sweet, though |
| 13:04 | <virtuelv> | actually, just being able to write macros in JS is sweet |
| 13:05 | <BenMillard> | aha, I see HTML WG listed in a table here for October 2008: http://www.w3.org/2008/10/TPAC/Schedule.html#Thurs |
| 13:07 | <jgraham> | virtuelv: I tried using Komodo Edit for a while but kept doing ctrl-x-ctrl-s to try and save stuff which would save it but with the current line missing... |
| 13:07 | Philip` | thought the dated w3.org URLs were meant to give the date that the content was first published, not some arbitrary future date like 2008/10 |
| 13:08 | <virtuelv> | jgraham: Hehe |
| 13:08 | <virtuelv> | you can write an extension that remaps all the keys |
| 13:08 | <svl> | "just as public internet facilities are responsible for porn, they ar also responsible for accessibility" - I wonder if he really meant that the way it reads... |
| 13:09 | <BenMillard> | Philip`, I guess they think a more guessable URL for that is more valuable. |
| 13:17 | <Philip`> | http://blog.mozilla.com/standards/2008/08/19/fear-and-loathing-on-the-standards-trail-with-an-upbeat-coda/ |
| 13:48 | <billyjack> | Kuruma: お久しぶり |
| 14:06 | <hsivonen> | whee! the spec has again grown larger than the validator.nu max file size limit |
| 14:09 | <hsivonen> | I replaced assertions.sch with a custom Java class |
| 14:09 | <hsivonen> | I've tested it, but I may have missed something |
| 14:17 | <MikeSmith> | hsivonen: hmm, I've been relying on assertions.sch for something |
| 14:19 | <hsivonen> | MikeSmith: it still exists. but the deployment now fakes it |
| 14:19 | <hsivonen> | MikeSmith: so it looks like Validator.nu is using it but it's really doing something more efficient |
| 14:20 | <hsivonen> | MikeSmith: I intend to keep maintaining assertions.sch |
| 14:32 | <MikeSmith> | hsivonen: great that you will keep maintaining assertions.sch |
| 14:35 | <MikeSmith> | hsivonen: I've been meaning to ask you, would it be possible to create a set of schematron assertions that capture the same logic as your custom table-integrity checking code? |
| 14:36 | <hsivonen> | MikeSmith: not possible as far as I can tell |
| 14:36 | <MikeSmith> | OK |
| 14:40 | <MikeSmith> | hsivonen: where in svn is the source for the table-checker error messages? |
| 14:44 | MikeSmith | reads through org/whattf/checker/table source |
| 14:59 | <zcorpan> | hsivonen: http://www.htmlvalidator.com/CSEForum/viewtopic.php?p=2371#2371 |
| 15:20 | <Lachy> | http://www.nytimes.com/2008/08/10/technology/10digi.html?_r=2&scp=1&%23038;sq=password&%23038;st=cse&%23038;oref=slogin&oref=slogin |
| 15:22 | <Lachy> | what they say about openid is interesting. OpenID was never really designed for logging on to sites like Yahoo or MySpace. It seems like it was more designed as a way to easily identify yourself in blog comments or forums, where there's little to no personal information about you |
| 15:22 | <Philip`> | Requires registration :-( |
| 15:23 | <Lachy> | ah, yeah, NYTimes sucks. Sometimes they say you need to register, other times they just let you see it |
| 15:23 | <takkaria> | Lachy: the idea was that openid would provide identity and then yahoo/myspace/whoever would use your ID as the key to your user data on their system |
| 15:23 | <takkaria> | at least, AIUI |
| 15:24 | <Lachy> | takkaria, that's not how I understood it when I first heard of it |
| 15:24 | <Lachy> | it's a totally insecure system for that |
| 15:24 | <Lachy> | it should be ditched immediately by all major sites that use it |
| 15:25 | <takkaria> | how is it any more insecure than making people sign up at each site? |
| 15:26 | <Lachy> | takkaria, because with OpenID, once you've phished the password once, you've got it for every site |
| 15:27 | <Lachy> | from wikipedia: "The original OpenID authentication protocol was developed in May 2005[6][7] by Brad Fitzpatrick, creator of popular community website LiveJournal, while working at Six Apart.[8] OpenID support was soon implemented on LiveJournal and fellow LiveJournal engine community DeadJournal for blog post comments," |
| 15:28 | <Philip`> | When you make people sign up with separate accounts at every site, they'll still use the same password for all of them |
| 15:28 | <takkaria> | Lachy: but the majority of people use the same password for everything anyway |
| 15:28 | <takkaria> | and this way, you can change your openid password once and all your sign-ins are secure, there are none to miss |
| 15:28 | <Lachy> | "... a malicious relying party may forward the end-user to a bogus identity provider authentication page asking that end-user to input their credentials. On completion of this, the malicious party (who in this case also control the bogus authentication page) could then have access to the end-user's account with the identity provider, and as such then use that end-user’s OpenID to log into other services." |
| 15:28 | <takkaria> | yeah, that can happen, and the way to fix it was with client-side certificates |
| 15:29 | <Lachy> | takkaria, yeah, but not necessarily the same username though |
| 15:29 | <Philip`> | You should use an identity provider that provides better security than just asking for a password |
| 15:31 | <Lachy> | you would have to have a way to guarantee that the site you're logging into isn't simply proxying a copy of the identity provider's login page to you, and intercepting whatever login credentials you provide |
| 15:31 | <takkaria> | browser extensions are one way |
| 15:31 | <Philip`> | That's what TLS is for |
| 15:32 | <Lachy> | you can't fix a fundamentally insecure protocol by relying on the user to take care of security themsevles with browser extensions |
| 15:32 | <Philip`> | assuming you check the site's certificate is what you expect it should be, each time you log in |
| 15:32 | <Lachy> | user's don't check certificates. They see the padlock and think everything is ok cause its secure. |
| 15:33 | <Lachy> | EV certificates have improved the situation a little but, but it wouldn't help too much if the identity provider's login page was presented to the user in an iframe, where there is no address bar |
| 15:34 | <Philip`> | So how do you propose to solve phishing? |
| 15:34 | <Lachy> | I didn't say I had a solution to the phishing problem. Just that OpenID makes the problem worse |
| 15:34 | <Philip`> | (since it seems that's the problem, and it's not specific to OpenID at all) |
| 15:35 | <Lachy> | openid encourages users to use type exactly the same login credentials into any login box on any random site, which makes it worse |
| 15:36 | <Philip`> | OpenID allows a solution to the problem, since competition between identity providers should result in some providing an actually secure service, and then it'll be secure across all sites that use OpenID; otherwise you'd have to wait forever until each of those sites had upgraded to an unphishably secure system |
| 16:12 | anne_ | wonders if the access folks actually read the new HTML5 proposal |
| 16:12 | anne_ | thinks that most of them didn't |
| 16:13 | <zcorpan> | anne_: why do you think that? |
| 16:15 | <anne_> | because several talk or imply talking about it being optional |
| 16:17 | <Philip`> | They might just not be aware that HTML5 now has a new proposal |
| 16:26 | <gDashiva> | So are spammers hosting their own openid providers yet? |
| 16:27 | <zcorpan> | anne_: it is optional in one case (iirc) |
| 16:28 | <jgraham> | anne_: I think the spec doesn't explicitly say that alt is required except in one case |
| 16:29 | <jgraham> | To be clear, I mean it often says it is explicitly required |
| 16:29 | <jgraham> | in one case it doesn't say it is explicitly required |
| 16:29 | <jgraham> | argh |
| 16:29 | <jgraham> | that was wrong |
| 16:30 | <jgraham> | in one case it says it is explicitly not required |
| 16:30 | <jgraham> | but it doesn't say that the cases metioned are supposed to cover all possible cases |
| 16:31 | <zcorpan> | there should be a default: useCommonSense(); |
| 16:31 | <anne_> | oh it still is in some cases? interesting |
| 16:32 | <jgraham> | It should be reorganised like if foo then: bar otherwise if baz otherwise do the default thing |
| 16:32 | zcorpan | wonders if anne_ actually read the new HTML5 proposal :P |
| 16:32 | <jgraham> | if foo then: bar; otherwise if baz then: foobar; otherwise do the default thing would be closer to what I meant |
| 16:34 | <jgraham> | The only case when it's not required is in HTML email and communications intended for the exclusive use of a known audience or words to that effect |
| 16:34 | <jgraham> | (you could, perhaps, argue that is a non-Web use case) |
| 16:44 | <gsnedders> | ergh. |
| 16:44 | <gsnedders> | 57 unread emails in the Flickr v. alt thread |
| 16:45 | <Philip`> | Your mail client should have a button to quickly rectify that situation |
| 16:46 | <gsnedders> | It indeed does. |
| 16:46 | <gsnedders> | But not a "read all and store summary of thread in brain" button. |
| 16:47 | <Philip`> | The summary should already be in your brain since it's pretty much the same as the previous three thousand alt emails |
| 16:48 | <gsnedders> | I am presuming this, but I am seeing more rational emails than I'd expect |
| 16:56 | <gDashiva> | Philip`: New project for you: Count the number of alt mails, cluster them, and graph it |
| 16:57 | <Philip`> | gDashiva: I think you are vastly overrating how much I care about it :-p |
| 16:58 | <MikeSmith> | graph the output to the null device |
| 17:02 | <gDashiva> | Philip`: What if you care about making me happy? :D |
| 17:04 | <anne_> | zcorpan, what's this thing you call HTML5? |
| 17:06 | <Philip`> | gDashiva: I think you are vastly overrating how much I care about enhancing your happiness ;-) |
| 17:11 | <gDashiva> | Philip`: You leave me with no option but... the dare. I bet you couldn't do it anyway, that's why you're avoid it. |
| 17:11 | <gDashiva> | -'re |
| 17:16 | <Philip`> | gDashiva: A cunning plan but one that is doomed to failure, since I really don't care, and also I must spend all my time playing TF2 instead of working on such things |
| 17:17 | gDashiva | gives up |
| 19:20 | <gsnedders> | takkaria: Are you really that recent around here? Oh well. |
| 19:21 | <takkaria> | gsnedders: no. I've been hanging around since 2007, possibly somewhat earlier |
| 19:21 | <takkaria> | but I was lurk-only |
| 19:22 | gsnedders | wonders whether to bother to change it |
| 19:22 | gsnedders | decides he is too lazy |
| 19:47 | <hsivonen> | getting rid of Schematron reduce the RAM required for validating the spec by 12 MB |
| 19:47 | <hsivonen> | reduced even |
| 21:29 | <MikeSmith> | hsivonen: has getting rid of Schematron also reduced the time measurably? |
| 21:32 | <hsivonen> | MikeSmith: it depends mainly of how much memory is available |
| 21:32 | <hsivonen> | MikeSmith: in low memory conditions, it seemed to cut time to 25% |
| 21:32 | <MikeSmith> | wow |
| 21:32 | <hsivonen> | I haven't measured it in conditions where ample memory is available |
| 21:33 | <MikeSmith> | how low is low memory? I usually run my Debian VM with only 512MB |
| 21:33 | <MikeSmith> | is 512MB low? |
| 21:33 | <hsivonen> | low is so low that it barely has space to run |
| 21:33 | <hsivonen> | like 31...43 MB |
| 21:34 | <hsivonen> | with the new code in 32 bit mode, I can't go lower than 31 MB and validate the spec |
| 21:34 | <hsivonen> | with Schematron, I can't go lower than 43 MB |
| 21:35 | <MikeSmith> | I'm surprised to know that a Java app like this will even run with that little memory |
| 21:36 | <MikeSmith> | I mean of this kind (HTML/XML processing) and complexity |
| 21:36 | <MikeSmith> | but I guess it's all SAX-based, right? |
| 21:36 | <MikeSmith> | or buffered SAX? |
| 21:36 | <hsivonen> | now without Schematron, it's all streaming SAX |
| 21:37 | <MikeSmith> | ah, then I can see that would speed it up for sure |
| 21:37 | <MikeSmith> | so the buffered-SAX thing was only needed for Schematron processing? |
| 21:38 | <hsivonen> | but the 25% figure means nothing in practice. it just means that GC runs a lot when the app is almost out of memory all the time |
| 21:38 | <hsivonen> | MikeSmith: no, buffered SAX is for the benefit of other uses of the parser |
| 21:38 | <MikeSmith> | I see |
| 21:39 | <hsivonen> | MikeSmith: the Schematron validator has an internal tree |
| 21:39 | <hsivonen> | MikeSmith: so it doesn't use the HTML parser's buffered SAX code |
| 21:41 | <MikeSmith> | OK. so, about the code you've written to replace the Schematron step, this is probably a dumb question, but I'll ask anyway: Is it generalized or generalizable such that is could be used to replace Schematron processing for other arbitrary sets of assertions? |
| 21:45 | <hsivonen> | MikeSmith: it's not generalized |
| 21:45 | <MikeSmith> | OK |
| 21:45 | <hsivonen> | MikeSmith: it has some semi-general parts but those parts aren't paremetrized by the Schematron XML |
| 21:46 | <hsivonen> | since I figured that the more specialized case would have to be specific anyway |
| 21:46 | <hsivonen> | because I didn't want to write a streaming XPath implementation |
| 21:46 | <hsivonen> | it would be cool if someone else wrote one, though :-) |
| 21:48 | <MikeSmith> | heh, yeah, I can imagine you not wanting to write one but I don't think I'll hold my breath waiting for anybody to write one.. |
| 21:48 | <hsivonen> | I think Michael Kay has written one, but it's not Open Source |
| 21:49 | <MikeSmith> | ah |
| 21:49 | <MikeSmith> | too bad |
| 21:50 | <gsnedders> | MikeSmith: On a totally different matter, do you have any opinion on sharing a room with me during the TPAC? |
| 21:51 | <MikeSmith> | gsnedders: I think I may be splitting an apartment for the week with Schepers |
| 21:51 | <gsnedders> | ah. |
| 21:52 | gsnedders | needs to find someone |
| 21:53 | <MikeSmith> | gsnedders: I would think asking others here on #whatwg could be good |
| 21:54 | <takkaria> | I would like to come to the TPAC but don't think my funds can stretch to it |
| 21:54 | <gsnedders> | Heh. I'm in France anyway, and I now have a flight back from Nice, so I've rather committed myself to going :) |
| 21:56 | <takkaria> | I have this suspicion I should be in uni at some point whilst it's on, too |
| 21:57 | <gsnedders> | takkaria: Excuses, excuses, excuses! |
| 22:02 | <jgraham> | I would but I can't go either because I'm in NZ |
| 22:03 | <MikeSmith> | hsivonen: I want to ask another dumb question, which is: For the non-schema processing bits of the v.nu code, I think it would embedding annotations in the code that provide assertion-like statements (in RFC 2119 language) about the particular constraints that part of the code is checking? |
| 22:03 | <MikeSmith> | e.g., "A table cell must not be overlapped by a later table cell." |
| 22:04 | <hsivonen> | MikeSmith: yeah, doing that would probably be good |
| 22:06 | <MikeSmith> | that way, it would be possible for me to extract those statements/assertions as least, if not an actual formal expression of the constraint being checked |
| 22:07 | <MikeSmith> | And would be helpful potentially to other implementors of conformance checkers |
| 22:10 | <MikeSmith> | hsivonen: if you do add something like that, I think that where possible, the annotation should include the associated element or element@attribute names it's checking |
| 22:10 | <MikeSmith> | e.g., "td|tr: A table cell must not be overlapped by a later table cell." |
| 22:11 | <MikeSmith> | or whatever |
| 22:37 | <gsnedders> | Anyone who vaguely knows me want to share a room with me at the TPAC (I'll be there, FWIW, from the 19th till the 25th, leaving in the evening, even though that is a rather useless detail)? |