| 00:00 | <Philip`> | and if you don't poke at the edges too hard then they all interoperate |
| 00:00 | <Philip`> | (Best not to poke in the middle either, or it might fall apart) |
| 00:00 | <Hixie> | Lachy: http://www.w3.org/TR/SVGTiny12/ is a REC. That's all I have to say, really. |
| 00:01 | <Lachy> | haha |
| 00:01 | <zcorpan_> | but it has a huuge testsuite! like 800 tests! |
| 00:02 | <Lachy> | woah! |
| 00:04 | <nessy> | http://www.bitflash.com/prod_playerSVGT.html <- google tells me that is a svgtiny 1.2 implementation |
| 00:05 | <nessy> | so is this http://www.tinyline.com/products.html |
| 00:05 | <zcorpan_> | it seems two experimental builds of opera were used for the implementation report |
| 00:05 | <nessy> | so they seem to have a reason to have svgtiny1.2 at REC, no? |
| 00:06 | <Lachy> | In other news, my US work visa application is finally seeing some progress. It has now been received by the USCIS and will soon begin going through the review process. |
| 00:06 | <Lachy> | I should hear more in 15 days |
| 00:06 | <nessy> | congrats! |
| 00:10 | <Hixie> | nessy: about the same level of reason to have html5 at a REC :-) |
| 00:10 | <Hixie> | with a test suite of 8000 tests you really can't learn much about interoperability of a spec as large as svg |
| 00:11 | <Hixie> | i'd estimate you need 20,000 or more, and that's counting things like checking hundreds of different colour values for 'color' as one test |
| 00:11 | <nessy> | if all the products pass these tests, shouldn't they be highly interoperable? |
| 00:11 | <nessy> | ah I see |
| 00:12 | <nessy> | is there a test suite for html5? |
| 00:12 | <Hixie> | not that i know of |
| 00:12 | <nessy> | that would be … millions of tests? |
| 00:12 | <Hixie> | hopefully at least tens of thousands, yes |
| 00:12 | <nessy> | it'd be really difficult I would imagine |
| 00:12 | <Hixie> | hence my i estimate it'll take a decade |
| 00:12 | <nessy> | better to have a validator! |
| 00:13 | <nessy> | yeah, I've always agreed with that estimate - at least for getting it into a "finished" stated |
| 00:13 | <nessy> | which doesn't mean it's not usable beforehand |
| 00:13 | <nessy> | plenty of products are in beta for a long time :) |
| 00:15 | <Hixie> | indeed |
| 00:17 | <zcorpan_> | woot, html5 says "behavior is undefined" |
| 00:17 | <Hixie> | html5 doesn't! websocket protocol does! |
| 00:17 | <zcorpan_> | same thing |
| 00:17 | <Hixie> | hah |
| 00:17 | <Hixie> | it actually says that the next layer protocol spec is responsible for it |
| 00:28 | <zcorpan_> | "I favor microdata, but I would much prefer that microdata be dropped and (some version of) RDFa be in the main spec than that both exist indefinitely in parallel." - same reasoning about html5 and xhtml2 (a few years ago)? |
| 00:28 | <Hixie> | microdata _is_ "some version of RDFa" |
| 00:29 | <Hixie> | i just took rdfa and tweaked it until it didn't have the problems that made it inappropriate for the use cases that people asked for |
| 00:29 | <Hixie> | (that's why it shared the same attribute names initially) |
| 00:29 | <zcorpan_> | just like with wf2? |
| 00:30 | <Hixie> | yeah, very similar to how WF2 was an attempt to make XForms work in HTML |
| 00:31 | <Lachy> | Has there been much interest from the microformats community to start looking into defining formats utilising microdata? |
| 00:33 | <TabAtkins> | Lachy: tantek worked on the Microdata vocabs, which are straight from microformats. |
| 00:35 | <Lachy> | yeah, I meant other than those in the vocabs spec, which are just based on older microformats |
| 00:35 | <TabAtkins> | You don't really have to do much of anything to use a microformat with the microdata syntax. They already have the tree-structure defined. |
| 00:35 | <Lachy> | that's good. |
| 00:36 | <Hixie> | you have to do _some_ work to define it properly |
| 00:36 | <Hixie> | but then that's work you'd have to do to define them properly for class=""/rel="" too |
| 00:38 | <Lachy> | Is the plan to one day encourage people to phase out the older class-based hCard, in favour of the microdata version? |
| 00:38 | <Lachy> | in fact, is there some problem being solved by mapping hCard into microdata? |
| 00:39 | <zcorpan_> | "It seems you can access contentWindow, but trying to access contentWindow.document (for IE's "special" 404 pages) raises an "access denied" exception, so it's not exactly a restriction on document.cookie, but on document itself..." |
| 00:40 | <TabAtkins> | Lachy: Yeah. The class/rel syntax used by microformats atm requires custom parsing rules for every microformat, and still has a few notable failures (like the inability to nest vcards, frex). Microdata gives you a single consistent parsing model to use, and solves nesting problems. |
| 00:41 | <Hixie> | i expect the class/rel-based microformats will continue to exist -- they do work, and are deployed |
| 00:41 | <hober> | Lachy: there are some notes here: http://microformats.org/wiki/html5 |
| 00:41 | <Lachy> | Hixie, yeah, I don't expect support will ever be dropped entirely. |
| 00:45 | <Lachy> | hober, the wiki still mentions the <itemref> element, which was dropped. |
| 00:46 | <webben> | Lachy: "yeah, I meant other than those in the vocabs spec, which are just based on older microformats" ... it's worth noting that new microformats are actually pretty rare. |
| 00:46 | <webben> | so I wouldn't necessarily expect to see lots of new formats expressed in microdata in a short space of time. |
| 00:47 | <Lachy> | webben, yeah, I'm aware of how frequently they create new formats |
| 00:48 | <hober> | Lachy: wikis are for updating :) |
| 00:48 | <Lachy> | hober, I would do it, but that would require me to remember what my microformats wiki username and password was |
| 00:56 | <erlehmann> | did someone say microdata ? can it be appropriate to add RDFa stuff to my cc-figure-generator so both is contained in the generated HTML fragments ? |
| 00:59 | <Lachy> | erlehmann, what is your cc-figure-generator? |
| 00:59 | <Lachy> | also, I think wasting time on adding RDFa to anything is not useful, especially if it already uses microdata |
| 01:00 | <erlehmann> | Lachy, a wordpress plugin for embedding cc-licensing microdata http://github.com/erlehmann/cc-figure/ |
| 01:00 | <erlehmann> | but i plan to make a stand-alone generator page |
| 01:01 | <erlehmann> | that just displays the code. actually, its simple to make this change. |
| 01:01 | <Lachy> | do you have a working demo so I can see the result? |
| 01:09 | <erlehmann> | Lachy, give me 15 minutes and i'll make a new commit containing a self-contained xhtml demo page. |
| 01:10 | <zcorpan_> | having both rdfa and microdata for the same data seems likely to confuse consumers that support both |
| 01:10 | <zcorpan_> | if there are such consumers |
| 01:11 | <erlehmann> | zcorpan_, confuse ? could it ? |
| 01:11 | <zcorpan_> | well, it would probably generate two sets of the same data |
| 01:15 | <zcorpan_> | also, the markup would be ridiculously verbose if it used both microdata and rdfa :) |
| 01:15 | <zcorpan_> | (just one of them is too verbose for my taste) |
| 01:18 | <mikekelly> | is there going to be a way of using HTTP Authorization that doesn't suck? |
| 01:19 | <Hixie> | you'd have to ask the http working group |
| 01:21 | <mikekelly> | I'm sorry can you rephrase that, I don't speak emo |
| 01:22 | Hixie | gives mikekelly a hug |
| 01:22 | <mikekelly> | :D |
| 01:22 | <mikekelly> | seriously though I have no idea what you're getting at |
| 01:24 | <mikekelly> | oh wait hold on |
| 01:24 | <mikekelly> | no actually please can you explain what it is you think needs to be done to make that work? |
| 01:24 | <mikekelly> | the only real problem is that there's no way to persist the Authorization header |
| 01:25 | <mikekelly> | so if you push an XHR request through with the Authorization header set |
| 01:25 | <mikekelly> | it'll work once and then get dropped |
| 01:25 | <mikekelly> | + you can't wipe the header either so you can't logout |
| 01:25 | <Hixie> | this channel is mostly where we discuss HTML, not HTTP, I'm afraid |
| 01:25 | <Hixie> | well that and such things as unicorns |
| 01:25 | <Hixie> | and narwhals |
| 01:25 | <mikekelly> | I like them |
| 01:25 | <Hixie> | and the lack of logic in the land |
| 01:26 | <mikekelly> | Ian you fucking ROCK |
| 01:26 | <Hixie> | why thank you |
| 01:26 | <Hixie> | wait, are you saying i DO rock, or that i AM a rock |
| 01:26 | <Hixie> | because the latter seems less awesome |
| 01:27 | <mikekelly> | it was actually a question I don't punctuate, well |
| 01:27 | <mikekelly> | see what I did there? |
| 01:27 | <Hixie> | are you asking if i perform reproductive activities with minerals?? |
| 01:28 | <mikekelly> | possibly |
| 01:28 | <Hixie> | that seems less appropriate even than saying i am a rock! |
| 01:28 | <Hixie> | though i will give you points for lack of logic |
| 01:28 | <mikekelly> | you're the expert. |
| 01:28 | <Hixie> | in lack of logic? sadly yes. :-( |
| 01:29 | <mikekelly> | cheer up |
| 01:29 | <Hixie> | so what brings you to our fair channel at such random intervals? |
| 01:30 | <Hixie> | do you grace us with your presence as a way to alleviate your boredom? |
| 01:30 | <mikekelly> | preeetty much |
| 01:31 | <erlehmann> | Lachy, http://github.com/erlehmann/cc-figure/blob/master/cc-figure-generator-standalone.xhtml |
| 01:32 | <erlehmann> | since the raw version is served with the wrong mime type, just download it http://github.com/erlehmann/cc-figure/raw/master/cc-figure-generator-standalone.xhtml |
| 01:32 | <mikekelly> | Hixie: so.. in your humble opinion.. |
| 01:32 | <mikekelly> | what do you think will happen wrt HTTP Auth |
| 01:33 | <Hixie> | i don't think about such things |
| 01:34 | <mikekelly> | whats the word on the street |
| 01:34 | <mikekelly> | I want the down lo Ian |
| 01:35 | <GarethAdams|Home> | the word on the street is "SLOW" |
| 01:35 | <Hixie> | i would have thought you would be more knowledgable about the word on the street... after all, i'm stuck up here in this ivory tower |
| 01:35 | <GarethAdams|Home> | at least on my street |
| 01:35 | <Hixie> | GarethAdams|Home: not "PED XING"? |
| 01:35 | <GarethAdams|Home> | not in the UK |
| 01:35 | <mikekelly> | yeah but I get it man |
| 01:35 | <mikekelly> | it's a nice tower |
| 01:35 | <mikekelly> | good for you |
| 01:35 | <Hixie> | GarethAdams|Home: ah, yeah, the UK has FAR saner typographical conventions for roads |
| 01:36 | <GarethAdams|Home> | http://www.saferroadsderbyshire.org.uk/images/roadSlow_tcm28-110980.jpg |
| 01:36 | <Hixie> | GarethAdams|Home: you should see road signs in the US, it's a dog-gone _disaster_ |
| 01:36 | <erlehmann> | "WHATWG", "typographical conventions for roads" — DOES NOT COMPUTE |
| 01:36 | <GarethAdams|Home> | (that;s not my road, just an example) |
| 01:36 | <Hixie> | GarethAdams|Home: they have individuals road signs with more than 4 fonts on them for less than one sentence! |
| 01:36 | <GarethAdams|Home> | lol |
| 01:36 | <foolip> | erlehmann: is assuming that something without an extension is for download great? |
| 01:36 | <mikekelly> | you're wasting my time here. do you mind? |
| 01:36 | <foolip> | erlehmann: also, showing the markup live while typing would be nice :) |
| 01:36 | <Hixie> | GarethAdams|Home: and they misspell words like "through" on purpose, even when not necessary |
| 01:37 | <Hixie> | GarethAdams|Home: it's quite the zoo |
| 01:37 | <GarethAdams|Home> | thru? |
| 01:37 | <Hixie> | "thru" "xing" "ped" |
| 01:37 | <GarethAdams|Home> | lol |
| 01:37 | <GarethAdams|Home> | "sidewalk" |
| 01:37 | <Hixie> | i like how the "slow" on your road is too big to fit the lane it's in |
| 01:37 | <GarethAdams|Home> | maybe that one's actually sensible, actually |
| 01:37 | <erlehmann> | foolip, if you can tell me a quick way to get th MIME type from the HTTP headers in javascript, go one. commit code or something. |
| 01:37 | <mikekelly> | Hixie |
| 01:37 | <mikekelly> | we need you to be on the case for this Auth thing |
| 01:38 | <mikekelly> | the fate of the world is in your hands |
| 01:38 | <Hixie> | you mean i get to decide what to do with http auth? |
| 01:38 | <Hixie> | sweet |
| 01:38 | <Hixie> | can we dump it altogether? |
| 01:38 | <foolip> | erlehmann: I cannot |
| 01:38 | <erlehmann> | i smell a new CSSquirrel comic |
| 01:39 | <erlehmann> | foolip, that is actually the one thing (besides more css files) i am missing here |
| 01:39 | <foolip> | erlehmann: I would just assume it's an img, or possible have a radio button for choosing? |
| 01:39 | <mikekelly> | Hixie: why would you suggest that was a good idea? |
| 01:40 | <mikekelly> | actually you know what don't even bother |
| 01:40 | <foolip> | erlehmann: but <img> certainly seems a sane default, no? |
| 01:40 | <erlehmann> | foolip, no un-necessary switches and bolts. |
| 01:40 | <erlehmann> | foolip, what if i want to present a torrent ? |
| 01:40 | <foolip> | erlehmann: as a figure? |
| 01:40 | <erlehmann> | got me there :p |
| 01:41 | <erlehmann> | yes, img may be a sane default. as you can see i am not even handling SVG in <img> |
| 01:41 | <mikekelly> | have a super evening chaps |
| 01:41 | <erlehmann> | if you fix it, i'll commit it. but now i'm gonna make a new, simple stylesheet |
| 01:41 | <erlehmann> | i like css |
| 01:43 | <Hixie> | mikekelly: oh noes, you're not leaving us are you? |
| 01:50 | <foolip> | erlehmann: http://pastebin.com/d20904a86 |
| 01:51 | <foolip> | don't have time to figure out how to do a git merge request, I'm heading to the airport |
| 01:51 | <erlehmann> | foolip, this is MADNESS |
| 01:51 | <erlehmann> | i'll sleep a night about thit |
| 01:52 | <erlehmann> | but thanks |
| 01:52 | <erlehmann> | i can attribute it to you nonetheless |
| 01:52 | <foolip> | erlehmann: ok, I don't mind much, just a suggestion |
| 01:52 | <erlehmann> | i'd prefer mime type detection via http request |
| 01:53 | <erlehmann> | that would also protect against typos |
| 01:53 | <foolip> | you'd need the php for that |
| 01:53 | <erlehmann> | because 4xx codes etc. would be DETECTED |
| 01:53 | <erlehmann> | :/ |
| 01:53 | <erlehmann> | can't the javascript just pull the headers ? ;_; |
| 01:53 | <foolip> | javascript can't do cross-origin and even if it were I don't know how to get the mimetype |
| 01:54 | <foolip> | so server-side is the only way right now |
| 01:54 | <foolip> | but I shall be off now |
| 01:54 | <foolip> | good luck :) |
| 01:56 | <erlehmann> | foolip, a php origin-redirecting-script would be a lot hackish for a small corner case |
| 01:57 | <erlehmann> | good traveling |
| 01:57 | <erlehmann> | or what you say there |
| 02:01 | <Hixie> | othermaciej: http://www.w3.org/mid/4d2fac900912031743q23ced9d7nd2e44b63a9706191⊙mgc |
| 02:01 | <othermaciej> | Hixie: that URL's not working for me |
| 02:01 | <Hixie> | latest e-mail from mark miller to the new security list |
| 02:02 | <Hixie> | /mid/ usually has some lag, it'll work in a bit |
| 02:03 | <othermaciej> | I think I just replied to it, if it's what I think it is |
| 02:03 | <Hixie> | k |
| 02:04 | <erlehmann> | Hixie, this raises the issue of a 4xx code for content that will be there in the future ;( |
| 02:04 | <erlehmann> | i meant ;) |
| 02:04 | <othermaciej> | Hixie: Mark Miller sure hates origin-based security, eh? |
| 02:04 | othermaciej | wonders if Mark will also object to postMessage() |
| 02:06 | <Hixie> | mark probably doesn't hate origin-based security any more than i do, he's just less willing to keep extending it |
| 02:06 | <Hixie> | personally i don't see an alternative, i don't think we can retrofit caps onto the web |
| 02:08 | <othermaciej> | I don't think it's a very good design, but I think it's more sensible to do the best we can with it than to try to fight it |
| 02:09 | <othermaciej> | since we can't entirely remove the concept of origin without badly breaking the web |
| 02:10 | <Hixie> | indeed |
| 02:10 | <Hixie> | i can certainly identify with his views; there's something to be said for not encouraging people to fight CSRF the way that Origin: suggests we fight it |
| 02:11 | <othermaciej> | Hixie: if you meant this message then I replied: <http://lists.w3.org/Archives/Public/public-web-security/2009Dec/0040.html>; |
| 02:11 | <Hixie> | but imho the alternatives are just too complicated given the way the web works |
| 02:11 | <othermaciej> | well, a secret token defense is potentially more sound, but you have to pretty much build it yourself, and you have to ensure that your secret tokens are actually unpredictable, not replayable, etc |
| 02:11 | <Hixie> | and so the decision facing authors is not just origin-based csrf protection vs caps-based security, but between no security, weak security, and complicated security |
| 02:12 | <Hixie> | and the latter is too expensive in practice for many authors |
| 02:12 | <othermaciej> | deploying both an Origin defense and a secret-token defense is better than either alone |
| 02:12 | <Hixie> | indeed |
| 02:12 | <othermaciej> | and Origin is extremely cheap to add when you discover you forgot to protect a resource against CSRF, since it can be tacked on by an application firewall |
| 02:12 | <Hixie> | but i expect he fears that people will pick "weak" over "complicated" if offered both |
| 02:12 | <Hixie> | and that people will pick "complicated" over "none" if offered those choices only |
| 02:13 | <Hixie> | i fear they'll pick "none", personally |
| 02:13 | <Hixie> | which is why i'm ok with "weak" |
| 02:13 | <othermaciej> | well, at present "complicated" vs "none" is exactly the choice you get |
| 02:13 | <Hixie> | indeed |
| 02:13 | <othermaciej> | and we see some people in each bucket |
| 02:13 | <othermaciej> | I'm not even sure of the scenarios where Origin fails as a CSRF defense |
| 02:14 | <othermaciej> | I'm pretty sure it works for the basic scenario of a Cookie-authenticated form, even if backed by nothing else |
| 02:14 | <othermaciej> | secret token CSRF defense has its own risks, precisely because of being complicated (in that it's easy to get it wrong) |
| 02:15 | <Hixie> | origin's failures aren't as a csrf defense but as a generic defense -- i.e. the danger is that it'll be misused to do other things |
| 02:15 | <othermaciej> | so I don't even entirely agree with the framing, let alone the conclusion |
| 02:16 | <othermaciej> | I'm not sure what else you'd use it as a defense for (other than opening a hole to allow limited cross-site XHR, but that use is totally orthogonal to the use in the HTML5 spec) |
| 02:17 | <othermaciej> | I know his worry about Origin-for-CORS is about the possibility of mistakenly using Origin as the sole defense in cases where it is not sound to use it that way |
| 02:17 | <Hixie> | right |
| 02:17 | <othermaciej> | not sure about Origin-as-CSRF-defense |
| 02:17 | <Hixie> | well it's the same feature, effectively |
| 02:17 | <Hixie> | so presumably if it can be misused, it can be misused, regardless of which spec mentions it |
| 02:18 | <Hixie> | btw, the htmlwg process document says that "without prejudice" means the issue can't be reopened, not that it can't block LC, as far as I can tell |
| 02:18 | <othermaciej> | if CORS did not exist and you had only AnonXHR, then even if HTML5 still used it for CSRF defense there would be no way to abuse it without the same way |
| 02:18 | <Hixie> | (though the latter is indeed implied by the former, obviously) |
| 02:18 | <Hixie> | othermaciej: true |
| 02:18 | <Hixie> | i guess |
| 02:19 | <othermaciej> | Hixie: "An issue that is closed without prejudice in this way can only be re-raised with approval of the Chairs." |
| 02:19 | <Hixie> | right |
| 02:19 | <othermaciej> | so it's not that it can't be reopened, but I did forget to mention that approval of the chairs is needed |
| 02:25 | <othermaciej> | I corrected that technicality |
| 03:29 | <Heimidal> | is anyone aware of a CDN/datastore that supports the Access-Control-Allow-Origin header? S3 (and therefore CF) doesn't seem to... |
| 03:54 | <doublec> | Heimidal, I'm not aware of any |
| 04:38 | <erlehmann> | anyone here has tips on figure styling ? |
| 05:08 | <TabAtkins> | erlehmann: In what way? |
| 05:09 | <erlehmann> | TabAtkins, just hints. i'm somewhat restless, eager to produce CSS while the world sleeps till it is time to attend university. |
| 05:10 | <erlehmann> | and media wiki figure styling is somewhat lacking |
| 05:11 | <TabAtkins> | I was gonna offer tips, but then I realized I only have tips on <details> styling. |
| 05:12 | <TabAtkins> | Anyway, I recommend figure{display:table} figure>[caption]{display:table-caption;caption-side:bottom;} figure>[caption]:first-child{caption-side:top;} |
| 05:12 | <TabAtkins> | And then a border and a light background. |
| 05:16 | <erlehmann> | pretty generic idea ;) |
| 05:17 | <TabAtkins> | Indeed! |
| 05:17 | <TabAtkins> | My <details> ideas are better. |
| 05:19 | <erlehmann> | tellme |
| 05:20 | <erlehmann> | and tell me they aren't :focus tricks ;) |
| 05:20 | <TabAtkins> | http://www.xanthir.com/etc/details |
| 05:20 | <TabAtkins> | No, they're not. |
| 05:20 | <TabAtkins> | They're css polygon tricks |
| 05:23 | <erlehmann> | not remotely stimulating |
| 05:24 | <TabAtkins> | Bah! |
| 05:26 | <TabAtkins> | Okay, fine, I just came up with this. I find it decent: |
| 05:26 | <TabAtkins> | figure{ |
| 05:26 | <TabAtkins> | float: left; |
| 05:26 | <TabAtkins> | border: 2px solid black; |
| 05:26 | <TabAtkins> | -moz-border-radius: 8px; |
| 05:26 | <TabAtkins> | -webkit-border-radius: 8px; |
| 05:26 | <TabAtkins> | background: #c00; |
| 05:26 | <TabAtkins> | margin: 1em; |
| 05:26 | <TabAtkins> | padding: 2em 1em 1em; |
| 05:26 | <TabAtkins> | position: relative; |
| 05:26 | <TabAtkins> | } |
| 05:27 | <TabAtkins> | figure > [caption] { |
| 05:27 | <TabAtkins> | position: absolute; |
| 05:27 | <TabAtkins> | width: 80%; |
| 05:27 | <TabAtkins> | top: -20px; |
| 05:27 | <TabAtkins> | left: -10px; |
| 05:27 | <TabAtkins> | font-size: smaller; |
| 05:27 | <TabAtkins> | border: 3px outset gray; |
| 05:27 | <TabAtkins> | background: white; |
| 05:27 | <TabAtkins> | color: black; |
| 05:27 | <TabAtkins> | padding: 2px; |
| 05:27 | <TabAtkins> | } |
| 05:27 | <TabAtkins> | Use <img src="http://www.xanthir.com/etc/FAT_PONY.gif>; as the figure contents, obviously. |
| 05:27 | GPHemsley | points at PasteBin and glares in TabAtkins' direction. |
| 05:28 | <TabAtkins> | Bah again. |
| 09:59 | <gsnedders> | Hixie: hixie.ch is down |
| 09:59 | <Hixie> | that's odd, i'm ssh'ed into it and it's working fine |
| 09:59 | <Hixie> | hm, so it is |
| 10:00 | <Hixie> | btw on a totally unrelated note will someone please explain to me why apache needs 20MB per thread to do NOTHING? |
| 10:02 | <zcorpan_> | 20MB is always nice to have, just in case |
| 10:02 | <Philip`> | Does "nothing" include e.g. running a whole Perl interpreter inside each thread via mod_perl? |
| 10:03 | <Hixie> | no |
| 10:03 | <jgraham> | Is it actually 20Mb per thread or is it one of those things where it is really 20Mb that is mostly shared? |
| 10:04 | Philip` | never quite understands where all the memory goes |
| 10:04 | <gsnedders> | /dev/null? |
| 10:04 | <Hixie> | i never know how to work it out |
| 10:04 | <Hixie> | so dunno |
| 10:04 | <Hixie> | (^jgraham) |
| 10:04 | <jgraham> | Hixie: Me neither |
| 10:05 | <zcorpan_> | Philip`: it's natural to forget things |
| 10:05 | Hixie | wonders wtf is going on on his server |
| 10:05 | <Hixie> | there's nothing apparently doing anything unusual, but my memory usage is through the roof |
| 10:06 | <Hixie> | based on the memory usage and the number of apache servers, i'm thinking that this is 20MB per-thread |
| 10:06 | <zcorpan_> | http://microdata.freebaseapps.com/ looks nice |
| 10:06 | <Philip`> | (Memory usage per-thread doesn't make much sense, since all threads in a process share a single address space) |
| 10:07 | <Hixie> | per forked process, i mean |
| 10:07 | <Hixie> | zcorpan_: they were involved in the usability study, iirc |
| 10:08 | <Philip`> | I get values like VIRT=35532 RES=15m SHR=3212 SWAP=18m CODE=332 DATA=13m for my Apaches |
| 10:08 | <Philip`> | Don't know what that translates to in real memory usage, though |
| 10:08 | <Hixie> | RES=20m is more normal for me |
| 10:09 | <Hixie> | i wonder how badly the wiki and blog and so on would be affected if i turned off mod_php |
| 10:09 | <Philip`> | You could always reduce the number of Apache processes |
| 10:09 | <zcorpan_> | Hixie: btw i think the forums don't cache images |
| 10:09 | <gsnedders> | Hixie: Totally broken? |
| 10:10 | <Hixie> | Philip`: unfortunately, that's out of my control |
| 10:10 | <Philip`> | (unless there's such heavy load that it really needs more than a handful) |
| 10:10 | <Philip`> | Oh, oka |
| 10:10 | <Philip`> | y |
| 10:11 | <Hixie> | i tried turning off mod_php, so i expect things to break |
| 10:11 | <Hixie> | i'll turn it back on after i see what it does |
| 10:11 | Philip` | likes Cacti since it draws pretty graphs and makes it obvious when something unusual is happening like heavy memory usage or load average |
| 10:11 | <Hixie> | i figure things can't break worse than they are right now (not doing anything at all) |
| 10:11 | <Hixie> | Philip`: dreamhost has pretty graphs too, but i can't work out why the memory graph is through the roof, so it doesn't help that much :-) |
| 10:12 | Hixie | increases his memory allocation to 4GB to see if that helps |
| 10:13 | <gsnedders> | Hixie: Because PHP is evil? |
| 10:13 | <Hixie> | no reason to think it's php |
| 10:13 | <Philip`> | It helps because you can look at the pretty graphs instead of worrying about the problem |
| 10:13 | Philip` | wonders why anyone would ever need 4GB on a server, unless they've got zillions of scripts and databases |
| 10:14 | <Hixie> | to debug memory overallocation bugs :-) |
| 10:14 | <Philip`> | Oh, right, good point |
| 10:16 | <Hixie> | oh, hm, i can't update the spec if the server's down, heh |
| 10:17 | <Hixie> | ok that didn't help, let's see what happens if i disable apache altogether |
| 10:17 | <Hixie> | can't make it worse than now... |
| 10:22 | <Hixie> | ok that closed apache but then it didn't come back up |
| 10:22 | <Hixie> | time to reboot the server |
| 10:26 | <mikekelly> | I'm back now |
| 10:26 | <mikekelly> | hi Ian |
| 10:27 | <mikekelly> | I meant to ask you |
| 10:27 | <mikekelly> | are you planning on bringing out Hixie action figures? |
| 10:28 | <mikekelly> | that would be pretty sweet. |
| 10:31 | <timz> | finally some progress :-) http://www.spiegel.de/netzwelt/web/0,1518,664475,00.html |
| 11:42 | <zcorpan_> | does resolving a url drop the fragment? that seems wrong, no? |
| 11:43 | <gsnedders> | Resolving a URL according to what? |
| 11:44 | <zcorpan_> | > It seems "Resolving Web addresses" |
| 11:44 | <zcorpan_> | > will drop fragment component according to |
| 11:44 | <zcorpan_> | > http://www.w3.org/html/wg/href/draft.html |
| 11:46 | <gsnedders> | How? What drops it? As far as I can see it shouldn't. |
| 11:46 | <zcorpan_> | ok |
| 11:47 | <Hixie> | why would it drop the fragment? |
| 11:47 | <Hixie> | wouldn't that mean we could never use fragments...? |
| 11:49 | <Philip`> | It does drop the base URL's fragment |
| 11:49 | <Philip`> | but that's not too exciting |
| 11:50 | <gsnedders> | Well, if you resolve "" to the base URL it shouldn't |
| 11:51 | <Philip`> | Why shouldn't it? |
| 11:52 | <Philip`> | RFC 3986 always uses the non-base URL's fragment |
| 11:53 | <gsnedders> | Oh, my memory is just wrong. |
| 11:53 | <zcorpan_> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/328 - firefox drops the fragment, opera doesn't, and chrome ignores the base altogether...? |
| 11:55 | zcorpan_ | sees Hixie's server works again |
| 11:56 | <Hixie> | oh the fragment in the base should be dropped, sure |
| 11:56 | <Hixie> | i thought you meant in the url being resolved |
| 11:56 | <Hixie> | the resolving algorithm is defined in the uri drafts, iirc |
| 11:58 | <zcorpan_> | i did, since that's what 鵜飼文敏 was talking about in the email about Web Sockets URL |
| 11:59 | <Hixie> | your test is not testing whether the url being resolved should lose its fragment identifier |
| 12:00 | <Hixie> | but maybe you're just talking about several things and i'm not keeping up :-) |
| 12:00 | <zcorpan_> | indeed :) |
| 12:03 | <zcorpan_> | Hixie: just don't make fragment in Worker constructor throw; it's useful for having different code paths |
| 12:03 | <Hixie> | how do you mean? |
| 12:04 | <zcorpan_> | page a does new Worker('worker.js#a') and page b does new Worker('worker.js#b'), and worker.js uses switch(location.search) { ... } |
| 12:04 | <zcorpan_> | er |
| 12:04 | <zcorpan_> | location.hash |
| 12:11 | <Hixie> | oh, workers |
| 12:12 | <Hixie> | nothing's changed for workes |
| 12:12 | <Hixie> | workers |
| 12:13 | <zcorpan_> | good |
| 12:16 | <zcorpan_> | http://www.w3.org/mid/Pine.LNX.4.62.0912041218080.5629⊙hdc - any hints of which specs those might be? :) |
| 12:17 | <Hixie> | depends what people want |
| 12:17 | <zcorpan_> | rdfa? |
| 12:17 | <annevk> | range |
| 12:17 | <annevk> | dom * |
| 12:17 | <annevk> | basically :) |
| 12:18 | <zcorpan_> | you could take over dom core |
| 12:18 | <annevk> | where * is range, events, core |
| 12:18 | <annevk> | a rewrite of CSS would be even more awesome, but so much work :/ |
| 12:19 | <Hixie> | things on my list include stream api, filesystem, execcommand, push notifications, push storage updates, range, dom core, html6, some css3 things, traversal, user interaction events |
| 12:19 | <Hixie> | not dom events, shepazu is doing that |
| 12:19 | <Hixie> | not cssom, anne is doing that |
| 12:20 | <zcorpan_> | oh yes, would be great with a better spec for execcommand |
| 12:20 | <annevk> | tbh a stream api would be sweet too |
| 12:21 | <Hixie> | annevk: not css2.2, css2.1 is one of the best specs we have right now and so at the bottom of the list of specs that need rewriting :-P |
| 12:21 | <Hixie> | oh websql also should be on that list |
| 12:22 | <zcorpan_> | will html6 be generated from the same source as html5? |
| 12:22 | <Hixie> | whatever i work on will almost certainly be from the whatwg source document, yeah |
| 12:22 | <Hixie> | my workflow is so highly optimised at this point that it'd be stupid for me to try to do anything else |
| 12:22 | <Hixie> | (i tried with workers, and it was a huge mistake) |
| 12:24 | <annevk> | Hixie, "best spec" I say :) |
| 12:26 | <Hixie> | aw |
| 12:26 | Hixie | sad |
| 12:27 | <annevk> | heh |
| 12:27 | <annevk> | the problem is that there's very little hook for specs that work on top of it |
| 12:27 | <annevk> | such as CSSOM View and CSSOM |
| 12:27 | <annevk> | e.g. take getPropertyPriority ... |
| 12:28 | <Hixie> | it has issues, sure |
| 12:28 | <zcorpan_> | but that's just an issue for annevk |
| 12:29 | <Hixie> | i've run into that one too actually |
| 12:29 | <Hixie> | for canvas in particular |
| 12:37 | <hsivonen> | Hixie: will all HTML6 edits be #ifdefed like all Trident bug fixes? |
| 12:42 | <Hixie> | bug fixes won't be, new features would be |
| 12:42 | <Hixie> | if i do html6 |
| 12:42 | <Hixie> | which i don't think i will |
| 12:42 | <Hixie> | though it is an option |
| 12:43 | jgraham | wonders whether Hixie means "someone else will edit HTML6" or "HTML will move away from version numbers" |
| 12:43 | <jgraham> | (or both) |
| 12:43 | <Hixie> | neither |
| 12:43 | <Hixie> | i meant, "if new features get added to html in the next couple of quarters" |
| 12:43 | <jgraham> | Yes, I guess that was option 4 |
| 12:43 | <Hixie> | (and not added to html5) |
| 12:44 | <annevk> | oh man |
| 12:44 | <annevk> | getComputedStyle is fucked |
| 12:44 | <gsnedders> | Are you just realizing this? |
| 12:44 | <annevk> | for 'width' it returns the used value unless the element is not rendered (different from not in the DOM) in which case it returns the computed value |
| 12:45 | <annevk> | though not quite the computed value, since all non-percentages and non-keywords are normalized to pixels, which is not an absolute unit |
| 12:47 | <annevk> | gsnedders, not really, I realized it two years ago, which is why I postponed working on this |
| 12:49 | <annevk> | also, it's not consistent, e.g. for background-position you always get the computed value, normalized to pixels |
| 12:49 | <annevk> | so percentages for a rendered document do not get converted to pixels |
| 12:50 | <annevk> | the result of all this is http://dev.w3.org/csswg/cssom/#resolved-values |
| 12:50 | <annevk> | i now have to reverse engineer every CSS property... |
| 12:54 | <annevk> | heh, hsivonen sure is on top of the DOCTYPE discussion :) |
| 12:55 | <Dashiva> | Spec design would be so much easier with a time machine |
| 12:56 | <annevk> | would be kind of boring to use it for that |
| 12:56 | <Dashiva> | Well, you wouldn\t need a complete time machine |
| 12:56 | <gsnedders> | Blatantly a better use would be to go to multiple classes at the same time |
| 12:57 | <Dashiva> | Like, say, a box where you insert a spec, and it outputs the most updated version of the spec from e.g. 10 years later |
| 12:57 | <annevk> | that would leave me with just travelling... |
| 12:57 | <annevk> | now you mention it... :p |
| 13:02 | <adactio> | Can I get a quick sanity check in case I go posting something stupid to the list/bug tracker? In this table: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#input-type-attr-summary |
| 13:02 | <adactio> | Shouldn't it include the "number" type? |
| 13:02 | <adactio> | (probably in the same column as "range") |
| 13:04 | <annevk> | number is included |
| 13:05 | <annevk> | column before |
| 13:05 | <annevk> | difference is that you can require a number and a number can be readonly |
| 13:05 | <Philip`> | gsnedders: Sorry, Harry Potter references are not permitted in here |
| 13:10 | <virtuelv> | Philip`: you missed the memo |
| 13:10 | <virtuelv> | only one entertainment item may be disallowed at any gien time |
| 13:11 | <virtuelv> | and from now until eternity, it's twilight |
| 13:11 | <annevk> | omg that movie was terrible |
| 13:11 | <annevk> | still can't believe I went |
| 13:11 | <gsnedders> | Philip`: Sorry, it's jgraham's influance on me |
| 13:11 | <annevk> | though I fell asleep during Harry Potter too (the more recent movies) |
| 13:11 | <adactio> | annevk: thank you for the sanity check. Curse these eyes. |
| 13:12 | <annevk> | ah, it's still early :) |
| 13:12 | <gsnedders> | Twilight is good if you're a teenage girl who still has some semblance of romantic ideals |
| 13:12 | <jgraham> | gsnedders: So ideal for you then? |
| 13:12 | <gsnedders> | Indeed. |
| 13:19 | <Lachy> | I'm having a hard time figuring out what benefits Jirka perceives in Larry's DOCTYPE proposal, given he agrees that about:legacy-compat already addresses the use case he seems concerned about. |
| 13:19 | <Philip`> | Maybe he was unaware of about:legacy-compat |
| 13:20 | <Lachy> | I thought he was one of the main proponents pushing for us to add it, so I'm sure he knew about it |
| 13:29 | <hsivonen> | annevk: I'm not on top of the doctype discussion in the sense that I don't understand what the expected utility of the proposed change is |
| 13:40 | <Lachy> | I don't think anyone really understand what the expected utility of the change is |
| 13:41 | <Lachy> | I think we're just getting pro-versioning people jumping up in support, without actually thinking about what they want it for or whether this actually addresses their needs. |
| 13:43 | <annevk> | argh, it's even more complicated |
| 13:43 | <annevk> | it also depends on the type of box |
| 13:43 | <annevk> | though the results are not quite consistent there |
| 14:04 | <annevk> | if at least Firefox/WebKit did the same thing it might be somewhat easier:/ |
| 14:05 | <Philip`> | Isn't it usually easier when they differ, since it indicates a lack of compatibility requirements? |
| 14:08 | <annevk> | maybe... |
| 14:11 | <Dashiva> | It's good for showing there isn't a lot of content depending on it, but it's still bad if you want to introduce a new feature depending on it, since you have to wait for old browsers to fade away |
| 14:13 | <annevk> | the annoying thing is when you reach a solution that means every impl has to change |
| 14:40 | <Hixie> | 7am really is WAY past my bedtime... |
| 14:43 | <TabAtkins> | Dude, Hixie, gtfo. |
| 14:43 | <murr4y> | maybe you need to redefine your bedtime ;p |
| 14:44 | <TabAtkins> | He lives in california. 7am is ridiculous for him. ^_^ |
| 14:54 | <TabAtkins> | My dilemna: Should I (a) point out how many things Shelley wants us to stop talking about, despite never 'quashing' conversation, (b) desperately argue that going this meta signals that we have nothing better to talk about, or (c) ignore the whole lot. |
| 14:54 | <TabAtkins> | I'm thinking (c) is the best choice. Meta breeds meta. |
| 14:55 | <AryehGregor> | This is why dictatorship is a good idea for things like specs. |
| 14:55 | <AryehGregor> | Otherwise people will talk forever about nothing. |
| 14:56 | <jgraham> | TabAtkins: d) employ the "one post per day per thread" rule |
| 14:56 | <TabAtkins> | jgraham: Sounds like a plan. |
| 14:56 | <TabAtkins> | Sounds like the type of plan I would have come up with yesterday, in fact. |
| 14:56 | <jgraham> | Happily I used my post to that thread already today |
| 14:58 | <TabAtkins> | Well, I'm talking about the ubermeta "HTML6" thread that just started. But I think I'll widen my rule to "per topic" rather than "per thread". Meta is meta is meta. |
| 14:58 | zcorpan_ | employs the "zero post per day per thread" rule for threads that have too much indentation in m2 |
| 14:59 | jgraham | actually had to stop using an indented view of mail for that reason |
| 15:00 | <zcorpan_> | indented threads are great because you can determine from the indentation pattern whether it's worth reading |
| 15:05 | <tobyink> | I can't seem to find an answer to this in the HTML5 draft - how to determine the language of an element if xml:lang or lang are set, but to an invalid language code? |
| 15:06 | <tobyink> | Do I treat this as lang="" i.e. language has been set to null? |
| 15:06 | <tobyink> | Or do I treat it as a missing attribute and take the language from the parent element? |
| 15:06 | <gsnedders> | "If the resulting value is not a recognized language code, then it must be treated as an unknown language (as if the value was the empty string)." |
| 15:07 | <tobyink> | Ah - well spotted - thanks. |
| 17:23 | <AryehGregor> | Is there any point in "If your download does not start automatically, click here" pages? |
| 17:26 | <TabAtkins> | It may just be an artefact at this point. They all use an <iframe> loading the content, which should work everywhere. At least it gives you something to look at while your browser decodes what the download is supposed to be. |
| 17:26 | <AryehGregor> | I thought they're pointless, but opera.com does it too. |
| 17:26 | <AryehGregor> | Well, pointless and/or attempts to expose you to more advertising. |
| 17:27 | <Dashiva> | Well, sometimes the connection itself fails |
| 17:27 | <Dashiva> | Then it's nice to have a link to click for a second try |
| 17:28 | <AryehGregor> | You can just click whatever link would have gotten you to the "If your download does not start automatically" page. |
| 17:36 | <Dashiva> | Yeah, but that's less obvious to the user |
| 17:45 | <Dashiva> | It always hurts a little when people mention separate DOM and HTML specs as a good idea |
| 18:50 | <karlushi> | http://confoo.ca/en/session#Web%20Standard |
| 18:51 | <karlushi> | mpilgrim will be presenting html5 in montreal |
| 18:53 | <mpilgrim> | indeed |
| 18:53 | <mpilgrim> | for some definition of "html5" |
| 18:58 | <karlushi> | I'll try to be there |
| 18:59 | <mpilgrim> | me too |
| 19:01 | <karlushi> | it really depends on the snow storm |
| 19:01 | <mpilgrim> | why don't i ever get invited to canada in august |
| 19:02 | <karlushi> | it's too hot ;) |
| 19:32 | <AryehGregor> | http://www.mediawiki.org/wiki/Special:Code/MediaWiki/59741 |
| 19:32 | <AryehGregor> | Maybe we can try switching to HTML5 again within a couple of months. |
| 19:32 | <AryehGregor> | Albeit with an XHTML 1.0 Strict doctype. |
| 19:35 | AryehGregor | goes to read his standards-list mail . . . putting it in a separate inbox is awesome |
| 20:16 | <AryehGregor> | "I don't see broad implementation of HTML5 in user agents or the community." |
| 20:16 | <AryehGregor> | Um, really? |
| 20:38 | AryehGregor | abides by the "one post per thread per day" rule |
| 22:55 | <jgraham> | AryehGregor: FWIW I think I almost entirely disagree with all the points that you made by email |
| 22:56 | <jgraham> | But I am loathe to reply there because I don't think having a long drawn out discussion of this is helping anyone |
| 22:58 | <jgraham> | I don't think that standards organisations should be compelled to produce a unique tehnology for each use case; that was the thinking that led to HTML being abandoned in the first place |
| 22:59 | <Dashiva> | And there are factual errors too |
| 22:59 | <Dashiva> | XHTML2 wasn't shut down until quite a while after HTML was resumed |
| 22:59 | <jgraham> | I don't think it is possible to go from where RDFa is today and make it "good" by my criteria without making it "bad" from the point of view of the people who currently like it |
| 23:00 | <Dashiva> | This "one technology for one thing" issue also completely misses the fact that RDFa was made only for XHTML2 |
| 23:00 | <Dashiva> | It's like saying don't make jet engines, we'll just put car engines on our planes, they do the same thing |
| 23:01 | <jgraham> | the fact that multiple competing standards leads to uncertianty is bad but I expect it to go away over time once it becomes clear whether a technology has real traction |
| 23:02 | <jgraham> | I don't think competition is a waste of resources if it leads to a better end result |
| 23:03 | <TabAtkins> | jgraham: Agreed, but only up to the point that it's clear that one result is better. At that point spending resources on the lesser branches is a waste. |
| 23:04 | <jgraham> | and I think that given the choice today between using RDFa and using nothing, many people would chose to use nothing i.e. RDFa would not win by default |
| 23:04 | <jgraham> | TabAtkins: We are far far away from that point |
| 23:05 | <TabAtkins> | We're far away from knowing whether RDFa or Microdata is better for HTML? |
| 23:05 | <TabAtkins> | I'd strongly disagree with that. |
| 23:06 | <TabAtkins> | Since Microdata is "RDFa, but with better names and some tuneups based on actual use-cases". |
| 23:06 | <Dashiva> | And less horrible ideas |
| 23:06 | <othermaciej> | we're far away from having agreement in the HTML Working Group that it's clear that one technology is better (even though many individual WG members feel one or the other is clearly better) |
| 23:07 | <TabAtkins> | True, agreement in the HTMLWG is still far off. |
| 23:07 | <TabAtkins> | On the other hand, I'm somewhat pessimistic of either group actually shifting. |
| 23:07 | <jgraham> | TabAtkins: I agree that it is better. But we're far from being able to show that it is better by being more successful |
| 23:07 | <othermaciej> | if Microdata had significant deployment success that outpaced RDFa, it would be easier to make the case |
| 23:08 | <othermaciej> | or likewise if RDFa had a lot more deployment success and use by data mining tools than it does now, while Microdata failed to get traction |
| 23:08 | <othermaciej> | I don't expect either of those things to happen in time for Last Call though |
| 23:08 | <Dashiva> | Besides, it seems all parites have acknowledged that RDFa 1.0 is lacking |
| 23:09 | <Dashiva> | So we can't even make a valid comparison until they hash out 1.1 |
| 23:11 | jgraham | is still of the opinion that nothing should happen before LC |
| 23:11 | <TabAtkins> | I am interested in what they come out with for 1.1. What I've heard of so far isn't addressing any of my concerns. |
| 23:11 | <TabAtkins> | jgraham: I'd be fine with that. It's the issue-raising people that are trying to force decisions now. I'm on record as being fine with "wait until it's obvious". |
| 23:12 | <Dashiva> | Well, we can't reach LC until the issues are resolved... |
| 23:15 | <mpilgrim> | othermaciej: yt? |
| 23:16 | <mpilgrim> | any plans to support <input type=color> beyond https://bugs.webkit.org/show_bug.cgi?id=28966 ? |
| 23:23 | <othermaciej> | mpilgrim: I'm here |
| 23:24 | <othermaciej> | mpilgrim: I think we'd want to use a proper color picker control at some point |
| 23:24 | <othermaciej> | mpilgrim: no specific timeline for that, but definitely we do plan to do it in general |
| 23:26 | <mpilgrim> | thanks |
| 23:27 | <mpilgrim> | one thing i do miss about mac os x is the awesome crayon color picker :) |
| 23:28 | <mpilgrim> | btw, the iphone's dynamic keyboard-in-response-to-html5-input-types features heavily in the upcoming "web forms" chapter of dive into html5 |
| 23:28 | <Dashiva> | My main requirement for a color picker is that it doesn't make it near impossible to get pure colors (in the corners and edges) |
| 23:29 | <mpilgrim> | dunno if you had anything to do with that, but please pass along my gratitude to whoever thought of it |
| 23:29 | <mpilgrim> | it's far and away the coolest thing i've learned about html5 forms so far |
| 23:32 | <othermaciej> | mpilgrim: yeah, that's a neat use of it for sure |
| 23:34 | <othermaciej> | Dashiva: I'm not sure what you mean |
| 23:35 | <Dashiva> | The color picker in Aion Online only reacted to clicks, you couldn't click and drag to the edge, so it was really hard to hit edge/corner values like pure black |
| 23:35 | <othermaciej> | Dashiva: but the OS X color picker dialog gives you a wide range of ways to pick colors, including by RGB clides, CMYK sliders, hue/saturation wheel plus luminosity slider, picking from an image, or selecting one of a number of predefined colors from a box of crayons |
| 23:36 | <othermaciej> | (also you can drag a color onto the color well control w/o even popping up a dialog) |
