| 01:35 | <hsivonen> | MikeSmith: fixed setTransitionHander. fixe annotation-xml encoding |
| 01:35 | <hsivonen> | MikeSmith: deferring the locator fix until I have access to a proper keyboard |
| 01:35 | <MikeSmith> | cool |
| 01:35 | <MikeSmith> | hai |
| 01:35 | <MikeSmith> | I'm guessing you must be traveling |
| 01:35 | <hsivonen> | yes |
| 01:37 | <hsivonen> | the locator thing will require a wrapper Locator that delegates to the real Locator once it is ready |
| 01:39 | <MikeSmith> | OK |
| 01:46 | <heycam> | newbie IRC question: if I join a channel and it says "Cannot send to channel" if I try to say something, what's the deal? |
| 01:46 | <heycam> | the mode is "+cnt", whatever that means. :) |
| 02:17 | <hsivonen> | I wonder hwat would be a good example to demonstrate HTML-in-annotation-xml with |
| 02:51 | <MikeSmith_> | hsivonen: *-+ |
| 02:51 | <MikeSmith_> | oops |
| 02:51 | <MikeSmith> | hsivonen: I think there is some example in the MathML3 spec |
| 02:52 | <MikeSmith> | or somewhere in some doc produced by the working group |
| 02:52 | <MikeSmith> | but as I recall it's not a very good example |
| 02:53 | <MikeSmith> | maybe David can provide a better one |
| 02:55 | <MikeSmith> | it's still really not clear to me how specifically someone might want to use it in a MathML-in-HTML document |
| 02:55 | <MikeSmith> | especially since it's display: none by default |
| 02:56 | <MikeSmith> | hsivonen: fwiw, about the locator thing, I just noticed the problem originally when I was messing around with the HtmlSpecBuilder stuff |
| 02:58 | <MikeSmith> | so it's nice it resulted in finding an actual parser issue worth fixing, even if it's not super important to have it for the spec build |
| 02:59 | <MikeSmith> | but that said, I guess if it's actually fixed, maybe we can user it to get the HtmlSpecBuilder to report line numbers correctly |
| 03:32 | <hsivonen> | MikeSmith: ok |
| 03:33 | <hsivonen> | Opera's Mac autoupdates is as full of FAIL as it was a year ago :-( |
| 03:33 | <hsivonen> | *autoupdater |
| 03:59 | <MikeSmith> | hsivonen: yeah, I really wish they would fix that |
| 04:05 | <MikeSmith> | man, the crecord extension for mercurial is brilliant |
| 09:14 | <MikeSmith> | http://blog.jclark.com/2010/12/microxml.html |
| 09:41 | <zcorpan> | i wonder how effective websocket masking is going to be when we start supporting sending Stream, Blob, etc |
| 09:42 | <jgraham> | zcorpan: Why would that matter? I thought the whole idea was that you couldn't reliably predict the byte sequence even with free control over the input bytes |
| 09:42 | <jgraham> | Since it is just a one-time pad |
| 09:42 | <zcorpan> | jgraham: if the attacker has control over the server, he can send the key to the client |
| 09:44 | <jgraham> | Yes, clearly. But that requires an attack that is effective even after you have already successfully connected to a server |
| 09:44 | <jgraham> | Which I didn't think was the case |
| 09:45 | <zcorpan> | if so, why bother masking the frames? |
| 09:45 | <jgraham> | I think someone else made the same point |
| 09:49 | <jgraham> | I guess if you use something stronger than XOR (e.g. the original AES suggestion) you are still protected in that case because it is hard to find the input giving the desired output, even with the key |
| 09:59 | jgraham | notes that when Greg says "I agree with Simon", he actually means "I disagree with Simon", assuming I am remembering his prior statements correctly and he had not significantly changed his position |
| 10:13 | <zcorpan> | we have 'error frames' these days? |
| 10:15 | <jgraham> | I didn't think so. I rather suspect they are Greg's invention. But I could be wrong |
| 10:27 | <othermaciej> | jgraham: I think he didn't understand what Simon said |
| 10:27 | <othermaciej> | the whole new framing thing seems like a huge waste of time |
| 10:27 | <othermaciej> | it's greatly increased the complexity of the framing with very little practical benefit |
| 10:36 | <jgraham> | Yeah, well it seems like WebSockets is stuck in design-by-leadership-free-committee hell, so pretty much the whole history of humanity supports the notion that it will tend toward useless complexity |
| 10:47 | <david_carlisle> | MikeSmith: especially since it's display: none by default |
| 10:48 | <MikeSmith> | yeah |
| 10:48 | <david_carlisle> | MikeSmith: best to think of it like data- attributes, but allowing structured annotation |
| 10:48 | <MikeSmith> | ok |
| 10:48 | <MikeSmith> | some concrete examples would help though |
| 10:48 | <MikeSmith> | they seem to be hard to come by |
| 10:48 | <david_carlisle> | MikeSmith: so for example you may want to give proof hints that appear on user interaction |
| 10:48 | <MikeSmith> | ok |
| 10:48 | <david_carlisle> | MikeSmith: well yes because it didn't work in browsers in html until recently:-) |
| 10:49 | <david_carlisle> | I'll try to make (someone) make some more plausible examples |
| 10:49 | <MikeSmith> | that'd be great |
| 10:54 | <annevk> | http://blog.regehr.org/archives/320 |
| 11:12 | <jgraham> | http://blog.jclark.com/2010/12/microxml.html |
| 11:18 | <annevk> | btw, css3-images endorses extension sniffing |
| 11:18 | <annevk> | someone should make that go away |
| 11:21 | <Rik`> | annevk: yes, please |
| 13:31 | <karlcow> | http://my.opera.com/karlcow/blog/new-xml-generation |
| 14:45 | <Workshiva> | "It would be great if HTML5 provided an alternate way (using attributes or elements) to declare that an HTML document be parsed in standards mode. Perhaps a boolean "standard" attribute on the <meta> element?" |
| 14:52 | <Philip`> | <meta http-equiv="X-Standard-Compatible" content="HTML=5"> ? |
| 14:52 | <Rik`> | why would it be great ? |
| 14:55 | <webben> | it's to allow validation of fragments AFAICT |
| 14:55 | <Philip`> | Rik`: So we could get rid of doctypes entirely |
| 14:55 | <jgraham> | No it's because MicroXML doesn't want doctypes |
| 15:03 | <Rik`> | just render everything in standards mode ? |
| 15:06 | <Lachy> | webben, validation of fragments doesn't depend on the parsing mode being known because the parse mode doesn't change the conformance definition. |
| 15:09 | <webben> | Lachy: good point. |
| 15:10 | <Lachy> | actually, it might. given the case of <p>...<table> |
| 15:13 | <zcorpan> | quirks mode is non-conforming, so a fragment validator could assume standards mode |
| 15:21 | <Lachy> | jgraham, MicroXML not wanting DOCTYPEs doesn't really explain why having a non-DOCTYPE standards mode switch would be a good idea, since XML just uses standards mode anyway. Any new syntax should just not support quirks mode |
| 15:22 | <david_carlisle> | lachy: he wants to use a (micr)xml toolchain to generate html (or if you prefer, ployglot xhtml served as text/html) |
| 15:23 | <zcorpan> | use a text/html serializer at the end of the toolchain instead of an xml serializer |
| 15:24 | <Lachy> | then stick an HTML5 serialiser on the end of it. No need to add HTML-only syntactic features into MicroXML |
| 15:24 | <david_carlisle> | don#t shoot the messenger;-) |
| 15:24 | <zcorpan> | BANG! |
| 15:24 | <zcorpan> | sorry |
| 15:25 | Lachy | goes off to read about MicroXML |
| 15:26 | <david_carlisle> | But requiring an html5-specific serialiser to avoid html5 weirdness is a sign of weakness in html5 design, there's no real way to avoid the conclusion that doctype weirdness and /.. weirdness in html5 is well weird. |
| 15:27 | <david_carlisle> | sorry meant to say /> weirdness |
| 15:28 | <david_carlisle> | It is standardising unfortunate behaviour forever because it works in the current crop of browsers. |
| 15:29 | <david_carlisle> | Of course it is easier for me to say that if I'm not responsible for keeping browsers working on deployed content... |
| 15:29 | <zcorpan> | no, because there are billions of web pages that rely on the unforgunate behavior |
| 15:29 | <david_carlisle> | see i said that for you |
| 15:29 | <zcorpan> | oh, sorry, didn't read carefully :) |
| 15:30 | <david_carlisle> | but I'm a pure mathematician by training, and I can work out there are more future documents than past ones, |
| 15:30 | <Philip`> | XML standardised weirdness like doctypes and namespaces without even having the excuse of deployed content :-) |
| 15:30 | <zcorpan> | yeah i'm not sure moving to xml is a win in terms of amount of weirdness |
| 15:31 | <david_carlisle> | but we like our weirdness, and don't like yours. So there. |
| 15:31 | <zcorpan> | heh |
| 15:31 | <Lachy> | if MicroXML were to restrict the DOCTYPE to "<!DOCTYPE html>", with no public or system identifiers permitted, then that might be acceptable since it would be a meaningless talisman in XML contexts. |
| 15:32 | <david_carlisle> | lachy: er i just said that on james' blog |
| 15:32 | <Lachy> | I didn't read the comments yet |
| 15:33 | <annevk> | so the idea is to add yet another language? |
| 15:33 | <annevk> | oh god |
| 15:33 | <annevk> | at least XML5 was backwards compatible |
| 15:33 | <annevk> | s/was/is/ |
| 15:34 | <david_carlisle> | annevk: James's variant is backwards compatible to xml 1.0 as well (compatibility with namespaces less so in some variants) |
| 15:35 | <annevk> | david_carlisle, not when it comes to doctypes apparently |
| 15:35 | <david_carlisle> | annevk: is the xml5 spec served somewhere as a document (I've seen the source in svn) |
| 15:36 | <zcorpan> | it seems like microxml aims to reduce the complexity in controlled environments while xml5 aims to remove fatal errors in browsers |
| 15:36 | <david_carlisle> | on doctypes he was just suggesting banning them, which is compatible in one direction |
| 15:37 | <Workshiva> | You have to wonder what they were thinking when they made the doctype subsets optional... |
| 15:37 | <Lachy> | annevk, microxml just seems to be describing authoring requirements as a strict subset of XML and HTML5 syntax, so AFAICT, it's just trying to generalise the syntactic requirements of polyglot documents |
| 15:38 | <Lachy> | it's not redefining any implementation requirements |
| 15:38 | <annevk> | david_carlisle, backwards compatible means you can parse all existing documents |
| 15:38 | <david_carlisle> | as i said, one direction:-) |
| 15:38 | <annevk> | david_carlisle, not that new content can be parsed by old software |
| 15:38 | <annevk> | david_carlisle, old software is boring and usually broken |
| 15:40 | <Rik`> | annevk: I sent a mail on www-style for the extension sniffing btw |
| 15:41 | <annevk> | cool |
| 15:41 | <annevk> | I'm on a semi-vacation |
| 15:41 | <annevk> | apparently I had too many days left |
| 15:41 | <annevk> | but so far I'm failing; on the other hand, this is only day one |
| 15:41 | <zcorpan> | annevk: go away |
| 15:42 | <annevk> | hehe |
| 15:50 | <zcorpan> | http://forums.whatwg.org/viewtopic.php?t=4495 - time to tweak the outline algorithm? |
| 15:50 | <zcorpan> | styling is an issue, but i think styling is messed up as it is today anyway |
| 16:02 | <AryehGregor> | Man, could spammers at least have enough respect to spam an HTML5 doctype in the HTML5 bug tracker? http://www.w3.org/Bugs/Public/show_bug.cgi?id=11543 |
| 16:04 | <Workshiva> | AryehGregor: No |
| 16:05 | <AryehGregor> | Well, doesn't hurt to ask. |
| 16:06 | <Workshiva> | If we're going to ask things of the spammers, we should ask them to spam with actual content instead of an empty document :) |
| 16:09 | <Lachy> | Workshiva, http://xkcd.com/810/ |
| 17:07 | <TabAtkins> | gsnedders: Your shirts came in. |
| 17:12 | <annevk> | Nintendo should really make a controller that does not give you a sore thumb |
| 17:13 | <annevk> | This has been bad since the NES |
| 17:14 | <TabAtkins> | I've never found a controller *anywhere* that doesn't make my thumb sore with sufficient use. |
| 17:15 | <TabAtkins> | That said, old d-pads were the worst. |
| 17:17 | jgraham | obviously doesn't play enough |
| 17:18 | <TabAtkins> | I didn't realize how much I relied on my 360 until it broke and I went without it for three weeks. ;_; |
| 17:18 | <TabAtkins> | On the plus side, we're playing through a fun PS2 rpg that we never got around to earlier. |
| 17:18 | <annevk> | Donkey Kong! |
| 17:18 | <JonathanNeal> | What do you guys think of http://www.iecss.com/whatwg-base.css so far? |
| 17:19 | <TabAtkins> | JonathanNeal: How has it changed since last time? |
| 17:19 | <JonathanNeal> | Opps, probably a better question for #html5, for this chan I would have meant http://www.iecss.com/whatwg.css |
| 17:19 | <JonathanNeal> | Yea, -base is based on current a grade browser settings, and only lists the offsets. |
| 17:20 | <TabAtkins> | The ":section(n) hn" sets of rules aren't correct. h5 can still be a top-level heading in any level of section, if it's the highest-level one. |
| 17:20 | <TabAtkins> | You just need a :heading(n) pseudo. |
| 17:23 | <TabAtkins> | Though, hm. You still want <hn> to have the legacy behavior in un-sectioned content. So I suspect you want to do just a set of "hn, :heading(n)" rules, but in *reverse*, starting with h6 and going down to h1. |
| 17:23 | <TabAtkins> | That way precedence will take over and make, say, an h5 look like a top-level heading if it really is one. |
| 17:23 | <TabAtkins> | While still letting it look like an h5 in the absence of sections. |
| 17:24 | <TabAtkins> | Also, how willing are you to put in less-established selectors? Is this intended to be usable *now*? |
| 17:25 | <TabAtkins> | Hmm, considering your use of pseudos and odd values on img and video, maybe not? |
| 17:25 | <JonathanNeal> | whatwg is meant to be latest and greatest theory. |
| 17:25 | <JonathanNeal> | So it is not subject to the reality of current browser css engines. |
| 17:26 | <JonathanNeal> | -base is subject. |
| 17:26 | <TabAtkins> | Okay. Then you can replace a big chunk of the list styles by using :any(). |
| 17:27 | <JonathanNeal> | Maybe I'm wrong, but I think the styling of headings within sections (without using a classname helper) would like quadrouple the size of the css file without :section type selectors. |
| 17:27 | <TabAtkins> | Nah, I just explained how to do it. |
| 17:27 | <JonathanNeal> | TabAtkins, hmm mind teaching me what you mean? I'm afraid I don't understand. |
| 17:27 | <TabAtkins> | You need :heading(n) selectors, is all. |
| 17:27 | <TabAtkins> | For headings, or lists? |
| 17:28 | <JonathanNeal> | Are you able to give me line numbers? |
| 17:28 | <TabAtkins> | For which? |
| 17:28 | <JonathanNeal> | If you don't mind, I'd like to start with headings and then move on to lists. |
| 17:28 | <TabAtkins> | Okay. |
| 17:28 | <JonathanNeal> | I really appreciate it. I like to keep this list updated. |
| 17:28 | <TabAtkins> | So, line 223 through 260. |
| 17:29 | <JonathanNeal> | yes |
| 17:29 | <TabAtkins> | You should be able to replace each chunk with just a pair of selectors, "hn, :heading(n)", where :heading(n) is a hypothetical pseudo that selects that nth level heading in a given section. |
| 17:29 | <TabAtkins> | But list them in reverse, from h6 to h1. |
| 17:29 | <JonathanNeal> | so h6 would be h6, :heading(6), yes? |
| 17:29 | <TabAtkins> | That way, in unsectioned content, they'll all work normally. But in sectioned content, a numbered heading will act like a higher-level heading if appropriate. |
| 17:30 | <TabAtkins> | Yeah. |
| 17:30 | <TabAtkins> | I need to at least *start* a Selectors 4 at some point so we have something to refer to here. |
| 17:31 | <JonathanNeal> | If you refresh and reference the new lines 224 - 152 I hope I've implemented this correctly. |
| 17:32 | <JonathanNeal> | ahem, 224-252 |
| 17:32 | <TabAtkins> | Yeah, looks good. |
| 17:32 | <JonathanNeal> | Awesome, want to help me with the lists now? Thank you. |
| 17:32 | <TabAtkins> | You can do the same with font-size in 324-361 |
| 17:34 | <JonathanNeal> | Go ahead and reference the new lines 324-252 |
| 17:35 | <TabAtkins> | yup. |
| 17:35 | <TabAtkins> | Okay, now, 411-451. |
| 17:35 | <JonathanNeal> | What about them? |
| 17:35 | <TabAtkins> | Well, first, 411-419 can be replaced with just ":any(menu, ol, ul) :any(dl, menu, ul)" |
| 17:36 | <TabAtkins> | (Is dl correct there?) |
| 17:36 | <JonathanNeal> | I just checked, that style is @ http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#the-css-user-agent-style-sheet-and-presentational-hints |
| 17:37 | <JonathanNeal> | so should I add dl? |
| 17:38 | <TabAtkins> | Hm, yeah. Okay. |
| 17:38 | <TabAtkins> | Ah, dir is missing. |
| 17:38 | <TabAtkins> | So ":any(dir, menu, ol, ul) :any(dl, menu, ul)" |
| 17:38 | <TabAtkins> | And then similar for the 3-deep version. |
| 17:39 | <JonathanNeal> | Can we back up one bit, so from 411-419 change that to :any(dir, menu, ol, ul) ? |
| 17:40 | <JonathanNeal> | Also, is "dir" an html5 valid element? |
| 17:44 | <TabAtkins> | It's obsolte, but yeah. |
| 17:45 | <MrWax> | how much exact new tags are there currently in the html5 spec? |
| 17:45 | <MrWax> | does anyone know where i can find this? |
| 17:45 | <TabAtkins> | MrWax: Check the element index in the spec. |
| 17:46 | <TabAtkins> | MrWax: http://www.whatwg.org/specs/web-apps/current-work/complete/section-index.html#elements-1 |
| 17:46 | <TabAtkins> | JonathanNeal: Use the line I gave for 411-419 - ":any(dir, menu, ol, ul) :any(dl, menu, ul)". |
| 17:47 | <MrWax> | TabAtkins: i dont have time to count all |
| 17:47 | <MrWax> | isnt there any other reference? |
| 17:47 | <TabAtkins> | MrWax: I don't have time to list them all. |
| 17:48 | <JonathanNeal> | TabAtkins, done (but if you don't mine with one alternate, the exclusion of dir as this list ignores removed elements from the html5 spec. |
| 17:49 | <TabAtkins> | JonathanNeal: k, now just use a similar rule for the 3-deep one ":any(menu, ol, ul) :any(menu, ol, ul) :any(dl, menu, ul)" |
| 17:50 | <JonathanNeal> | Done, the new lines are 411-417 |
| 17:51 | <TabAtkins> | You just replaced 411 with the 3-deep version for some reason. |
| 17:52 | <JonathanNeal> | foolishness, fixed. |
| 17:52 | <JonathanNeal> | Or, a typo rather. |
| 17:52 | <TabAtkins> | Okay, cool. |
| 17:52 | <JonathanNeal> | So this is the latest and greatest again? |
| 17:53 | <TabAtkins> | <img> and <video> can just stick with auto width and height. The 300px/150px initial size and the proper size negotiation are handled automatically by CSS. |
| 17:53 | jgraham | wonders how UndoManager is supposed to work |
| 17:54 | <JonathanNeal> | Would this be the same for canvas? |
| 17:54 | <TabAtkins> | Hmm. Yeah, probably. Are @width and @height covered by another rule elsewhere? |
| 17:55 | <JonathanNeal> | For some reason I thought 300px was defined by you guys. I guess just most browsers are deciding that, but it isn't expressed by whawg. |
| 17:56 | <TabAtkins> | Well, never mind, yes, CSS handles it. The width and height of the canvas are part of its natural size. |
| 17:56 | <TabAtkins> | Which is taken into account during the size negotiation in CSS. |
| 18:01 | <JonathanNeal> | To be clear, nowhere does it say that the presentation of canvas or video should be 300x150? |
| 18:01 | <TabAtkins> | That's implicit in the size negotiation algorithm in CSS now. |
| 18:01 | <TabAtkins> | http://dev.w3.org/csswg/css3-images/#sizing Check out the "default image sizing area" bit. |
| 18:02 | <JonathanNeal> | TabAtkins, sure, and what about for audio? |
| 18:02 | <JonathanNeal> | line 484 |
| 18:02 | <TabAtkins> | That one needs a special rule, yes, because it acts differently than other replaced elements. |
| 18:02 | <JonathanNeal> | Will the size negotiations take over for img:complete, video:poster, and video:metadata as well? |
| 18:02 | <TabAtkins> | Yes. |
| 18:03 | <TabAtkins> | Lemme check to see if html defines things correctly for that to work... |
| 18:03 | <JonathanNeal> | All right, I will strip them all out. For the remaining "audio[controls]" will the width: 300px be automatic? |
| 18:04 | <TabAtkins> | Yes, that falls out of the fact that audio only has a height and not a ratio. |
| 18:04 | <JonathanNeal> | Updated 484 - 490 |
| 18:04 | <JonathanNeal> | Might wanna fuse the "Media" section into other sections then. |
| 18:05 | <JonathanNeal> | I guess it's okay where it is. |
| 18:13 | <gsnedders> | annevk: I found the SNES to not be too painful when playing Donkey Kong for hours a few months back |
| 18:13 | <gsnedders> | (Obviously I'm too young to know about the original NES) |
| 18:14 | <JonathanNeal> | gsnedders, bummer, I loved the NES. |
| 18:15 | <JonathanNeal> | Would there be an intelligent name for the grouping of menu, ol, and ul? |
| 18:16 | <Dashiva> | list? |
| 18:16 | <JonathanNeal> | Dashiva, I thought so as well, but one that distincts those elements from "dl" |
| 18:17 | <Dashiva> | Array :P |
| 18:23 | <JonathanNeal> | Maybe I don't understand what the meaning is with http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#margins-and-padding |
| 18:24 | <JonathanNeal> | and http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#punctuation-and-decorations |
| 18:25 | <TabAtkins> | What are you confused about, precisely? I don't understand. |
| 18:26 | <JonathanNeal> | Specifically with list-style-type: disc, circle, and square, and why those combinations of elements should produce those styles. |
| 18:27 | <TabAtkins> | I don't know why "dl" is involved, but otherwise it's just all the types of lists that produce markers. |
| 18:27 | <TabAtkins> | Well, dl makes sense for the margins and padding section. |
| 18:29 | <JonathanNeal> | So IF there were a :list pseudo element THEN ":any(menu, ol, ul) :any(dl, menu, ul)" might read ":list :list" ? |
| 18:30 | <TabAtkins> | Sure, but why would we need :list? It's only purpose would be to simplify UA stylesheets, because normal people don't need to group lists almost ever. |
| 18:30 | <TabAtkins> | Also, :any() works pretty well by itself. |
| 18:30 | <JonathanNeal> | I know and I agree, but so that I understand what it is doing. |
| 18:30 | <TabAtkins> | Actually, that wouldnt' work anyway. |
| 18:30 | <TabAtkins> | You don't want to set list-style to "square" for ol. |
| 18:31 | <TabAtkins> | There's a reason the last :any() is different from the previous ones. |
| 18:36 | <JonathanNeal> | TabAtkins, that makes sense to me, thanks. |
| 18:37 | <JonathanNeal> | Haha. I have to be careful not ot accidently think I forgot something and add a quirksmode style. I almost added form { margin: 0 0 1em; } |
| 18:38 | <JonathanNeal> | *not to |
| 19:01 | <TabAtkins> | Hrm @ the <comment> suggestion. |
| 19:01 | <TabAtkins> | New sectioning element, semantics of a response to the nearest parent <article>? |
| 19:02 | <JonathanNeal> | @ me? |
| 19:02 | <TabAtkins> | No, at the mailing list. |
| 19:03 | <TabAtkins> | At you, I just confirmed that HTML does indeed define <video> correctly to let the CSS size negotiation work properly. |
| 19:07 | <hober> | I don't see what <comment> gets us that <article>...<article>...</article></article> doesn't |
| 19:07 | <TabAtkins> | The added semantic of user-generated content, as separate from the author-generated content from the parent article? |
| 19:08 | <TabAtkins> | Dunno if it's sufficiently useful to use for search engines and such to be worthwhile. |
| 19:08 | <TabAtkins> | Or if it would potentially help screen-readers do heading/section-based navigation. |
| 19:12 | <Philip`> | I thought IE already implemented <comment> |
| 19:12 | <hober> | I'm not sure about the user- v. author-generated distinction |
| 19:12 | <TabAtkins> | Aw, dammit. |
| 19:12 | <Philip`> | as a synonym for <!--...--> |
| 19:12 | <TabAtkins> | yeah, they did. |
| 19:12 | <gsnedders> | WTF? |
| 19:12 | <TabAtkins> | Only through 6, though. |
| 19:12 | <hober> | e.g., consider a Planet aggregator that displays comments from the blogs it aggregates |
| 19:13 | <TabAtkins> | So, probably can be ignored. I'll bring it up in the thread, though. |
| 19:13 | <TabAtkins> | hober: Yeah, I'm not sure about it either. I'd like to see if other people think there's a useful distinction to be made there. |
| 19:15 | <hober> | *nod* |
| 19:16 | <webr3> | not a fan of comment, can't keep adding new elements to HTML for every type of textual content (article, post, comment, wiki, news, micropost, message) etc etc, where do you stop? |
| 19:16 | <webr3> | better to have one element that can be augmented with a type |
| 19:17 | <TabAtkins> | Not a fan of one element that can be augmented with a type, can't keep adding new types to HTML for every type of textual content (article, post, comment, wiki, news, micropost, message) etc etc, where do you stop? |
| 19:18 | <webr3> | <article itemtype="<anything>"> you never need to stop, keeps HTML simple |
| 19:18 | <TabAtkins> | <anything> isn't helpful. |
| 19:19 | <TabAtkins> | The whole point of the semantic elements is to, you know, have semantics - a common public meaning that everyone knows about. |
| 19:19 | <webr3> | but that's an endless set.. |
| 19:19 | <TabAtkins> | Not really. |
| 19:20 | <TabAtkins> | The existing set covers everything. We can slice more finely if it's sufficiently useful (for example, by subclassing <article> into <comment>), but we don't have to jump down the rabbit-hole. |
| 19:20 | <webr3> | what's the point in microdata then? just keep adding new elements and attributes.. |
| 19:21 | <TabAtkins> | Microdata's for exposing visible data in a machine-readable way. It doesn't do anything semantically. |
| 19:23 | <webr3> | so what's the semantic distinction being made between an article and a comment? |
| 19:24 | <TabAtkins> | That it's an article, or a comment on the article. The latter is a user-generated response to the author-generated content. |
| 19:25 | <webr3> | and if the author comments? or the comment is on a comment? |
| 19:25 | <webr3> | or if the article is a comment on another article on another site? |
| 19:25 | <TabAtkins> | The former still carry the same basic semantics. The latter is probably too minor to distinguish - just call it an <article> like normal. |
| 19:26 | <hober> | both IE6 and IE7 treat <comment> as comments |
| 19:26 | <gsnedders> | IE8? |
| 19:26 | <TabAtkins> | IE8 doesn't. |
| 19:27 | <Philip`> | What about quirks mode? |
| 19:28 | <TabAtkins> | I think they actually use the old parser in their compat modes, so it'll probably work there. |
| 19:29 | <TabAtkins> | Oh wait, IE8 does. I was using IE9 beta accidentally. |
| 19:29 | <TabAtkins> | IE9 doesn't treat it as a comment. |
| 19:42 | <MrWax> | the fact that html5 is backwards compatible mainly points in the fact that all uses of html4 will still be interpretable using the new doctype right? |
| 19:43 | <TabAtkins> | Well, ignore the doctype. The HTML5 *parser* will indeed parse html4 and earlier documents in a compatible manner. |
| 22:49 | <karlcow> | http://developer.yahoo.com/blogs/ydn/posts/2010/12/pushing-beyond-gzipping/ |
| 22:58 | <MrWax> | Could anyone maybe give an example what the worker api could do/fix for a CMS ? |
| 23:00 | <Hixie> | you could make the CMS do all its network communication in the background and have it cache data locally to make it seem faster |
| 23:02 | <mgdm> | I use a CMS of sorts at work that does that sort of thing in Flash :| |
| 23:21 | <JonathanNeal> | Ahoy |
| 23:22 | <TabAtkins> | Yo. |
| 23:22 | TabAtkins | just had to school someone on proper password storage. |
| 23:23 | <bga_> | stickers? :) |
| 23:35 | <AryehGregor> | TabAtkins, as in, salted hashing? |
| 23:35 | <TabAtkins> | AryehGregor: Yes. |
| 23:35 | <AryehGregor> | I'm experimenting right now with using hash functions that are particularly resistant to brute-forcing. |
| 23:35 | <TabAtkins> | Someone was trying to claim that salts are unnecessary if you use a sufficiently expensive hashing algorithm. |
| 23:35 | <TabAtkins> | I pointed out that they're stupid. |
| 23:35 | <AryehGregor> | Salts are *less* useful if you use a very cheap hash. |
| 23:36 | <AryehGregor> | But using an expensive hash is a good idea anyway. |
| 23:36 | <AryehGregor> | I'm trying to make a hash that's expensive on GPUs as well as CPUs. |
| 23:36 | <bga_> | i use http://passwordsafe.sourceforge.net/ |
| 23:36 | <TabAtkins> | Sure, but doubling the size of your salt with a cheap hash is basically free for you but makes bruteforcing much more expensive. Using a more expensive hash is expensive for you and make bruteforcing much more expensive. |
| 23:37 | <AryehGregor> | Because you can just iterate a hash a few ten thousand times, PBKDF style. But you can still crack those very quickly on a GPU, at least compared to a CPU (>10x speedup). |
| 23:37 | <AryehGregor> | The size of your salt is practically irrelevant to brute-forcing attempts. If your attacker has the hash, they probably have the salt too. |
| 23:37 | <TabAtkins> | Combining the two can be good, but when you want the hash to not spin your server's cpu for extended periods of time, just use a longer salt. |
| 23:37 | <AryehGregor> | The point of salts is only to avoid rainbow table attacks. |
| 23:37 | <TabAtkins> | Yes? |
| 23:37 | <Hixie> | TabAtkins: if you're interested in publishing the specs on the TR/ page, what's the easiest way I can help you with that? |
| 23:37 | <Hixie> | easiest for you, i mean |
| 23:37 | <AryehGregor> | I.e., make the attack O(M*N) instead of O(M + N), where M is the number of passwords and N is the number of passwords you're trying. |
| 23:38 | <AryehGregor> | It doesn't matter how long or short your salts are, as long as they're all different. |
| 23:38 | <TabAtkins> | Hixie: I have no idea. I don't know what your tooling is, or how you currently push things to TR. |
| 23:38 | <Hixie> | at this point i don't |
| 23:38 | <AryehGregor> | Server CPU usage by hash functions is practically irrelevant, since you only have to run the algorithm on login and registration. As long as it takes less than a few hundred milliseconds, it's fine. |
| 23:38 | <Hixie> | previously i had a system whereby i would set up all the boilerplate and then hit a switch in my postprocessor |
| 23:39 | <Hixie> | and it would use the appropriate boilerplate and replace the dev.w3.org draft with the appropriate text |
| 23:39 | <TabAtkins> | AryehGregor: The dude I was reading was saying to use bcrypt set to really expensive, to it took a good half-second to hash anything. |
| 23:39 | <AryehGregor> | But iterating it a zillion times (or otherwise slowing it down) will seriously hamper an attacker. My GPU cracker went from 220 million passwords per second to about 10,000 per second when I just iterated the hash a bunch of times. |
| 23:39 | <AryehGregor> | But it was 120/second/core for a CPU. So I'm looking to limit the GPU further without hurting CPU users. |
| 23:39 | <AryehGregor> | TabAtkins, I can't parse that sentence. |
| 23:40 | <TabAtkins> | s/to/so/ |
| 23:40 | <AryehGregor> | " was saying to use bcrypt set to really expensive"? |
| 23:40 | <TabAtkins> | Apparently you can specify how expensive bcrypt should be? |
| 23:40 | <AryehGregor> | Probably just by iterating it lots of times. |
| 23:41 | <AryehGregor> | You should be able to tune it for your needs. |
| 23:41 | <TabAtkins> | kk |
| 23:41 | <AryehGregor> | Iterating 32,768 times seems to take some tens of milliseconds on a typical CPU for SHA1. |
| 23:41 | <AryehGregor> | Like maybe 100 ms. |
| 23:41 | <AryehGregor> | Which is fine for real-world uses, but messes up attackers quite a lot. |
| 23:42 | <JonathanNeal> | TabAtkins, who else might be a good resource here to review the whatwg css file? |
| 23:42 | <Hixie> | review the whatwg css file? |
| 23:43 | <Hixie> | hmm |
| 23:43 | <JonathanNeal> | It's a css file I've been working on and maintaining for a few months tracking the html5 ua stylesheet and presentational hints @ http://www.iecss.com/whatwg.css |
| 23:43 | <Hixie> | neat |
| 23:44 | <Hixie> | TabAtkins: here's what i'm thinking |
| 23:44 | <Hixie> | TabAtkins: i put the header files somewhere you can edit |
| 23:44 | <Hixie> | TabAtkins: and i make my tool grab the status and date of publication from those files somehow |
| 23:44 | <Hixie> | TabAtkins: then to do the publication stuff all you have to do is tweak the files accordingly, and then give me a heads-up and i'll regen the spec with those files |
| 23:46 | <TabAtkins> | If that's easy for you, it sounds easy to me. |
| 23:46 | <Hixie> | k |
| 23:46 | <Hixie> | let me figure out how to do the second bit, and then i'll find a place to put the files |
| 23:46 | <TabAtkins> | JonathanNeal: Not sure who else would be good. Maybe just send an email to whatwg? |
| 23:47 | <JonathanNeal> | Yea, I guess so. Cool, well, thank you. |
| 23:47 | <Philip`> | AryehGregor: How are you trying to make it worse on GPUs? |
| 23:48 | <AryehGregor> | Philip`, my current theory is to salt everything with a large fixed hash, say 1 MB, since GPUs don't have memory caches. The problem with this is that you could conceivably just do an ad hoc memory cache in shared contexts. Plus I think I heard that next-gen NVIDIA GPUs do have some memory cache. |
| 23:48 | <AryehGregor> | But it's worth a try. |
| 23:49 | <AryehGregor> | If I make it something like 8 or 16 MB, it will kill a naive CPU implementation's L2 cache also. But that can be worked around pretty easily. |
| 23:49 | <AryehGregor> | Just do a lot of hashes in parallel, reading in the salt a small amount at a time. |
| 23:50 | <AryehGregor> | I considered making the code very branchy, so that GPUs would run at 1/8 speed or so, but I didn't think of a good way to do that. |
| 23:50 | AryehGregor | is writing his OpenCL program to test all this out right now, and seriously wants to say impolite things to the people who wrote NVIDIA's OpenCL compiler. |
| 23:51 | <AryehGregor> | When compiling my OpenCL programs, I have so far had: segmentation faults (in compilation!), cryptic error messages, infinite loops, and one variable mysteriously just having the wrong value for no apparent reason. |
| 23:51 | <Philip`> | Maybe find some way to make it rely on random access to a very large buffer, so the cache used for one hash can't be used in parallel for another |
| 23:52 | <AryehGregor> | Interesting thought. |
| 23:52 | <Philip`> | (so you'll be bottlenecked by memory bandwidth before you can exploit the GPU's parallel computation power) |
| 23:52 | <AryehGregor> | Like use the last n bits of the last byte of the hash to index into the buffer. |
| 23:53 | <Philip`> | (whereas a normal CPU computing one hash at a time won't be disadvantaged much) |
| 23:53 | <AryehGregor> | The problem is that one constraint is this has to be fast enough when implemented in PHP. |
| 23:53 | <AryehGregor> | So there's a very sharp limit to how much custom execution logic I can have. |
| 23:54 | <Philip`> | So you need a PHP implementation to be fast and a GPU implementation to be slow? |
| 23:54 | <TabAtkins> | Note, the "fast" and "slow" are measured on different timescales. |
| 23:55 | <AryehGregor> | I need a PHP implementation to take under (roughly) 100 ms per hash. Given that constraint, I want cracking to be as slow as possible. |
| 23:55 | <AryehGregor> | On either CPU or GPU. |
| 23:55 | <AryehGregor> | Particularly GPU, since that's likely to be faster. |
| 23:57 | <Philip`> | You could force users to enter longer passwords, since it'll take no longer to compute the hash but exponentially longer to crack |
| 23:58 | <AryehGregor> | That's orthogonal, though. |
| 23:58 | <Philip`> | It solves your problem :-) |
| 23:58 | <bga_> | AryehGregor http://en.wikipedia.org/wiki/Comparison_of_cryptographic_hash_functions GOST hash is hardest |
| 23:58 | <Philip`> | No point worrying about GPUs being 10x faster if you find a way to make cracking half a million times slower without changing the algorithm |
| 23:58 | <AryehGregor> | bga_, "hardest"? |
| 23:59 | <AryehGregor> | Philip`, it's incompatible with our requirements. We want users to be able to input short passwords if they want. |
| 23:59 | <bga_> | 2^105 to find collision |