| 00:15 | <Hixie> | i really wish Kristof could quote context |
| 00:15 | <Hixie> | i never have any idea wtf his e-mails are about |
| 05:14 | <Hixie> | heycam: yt? |
| 05:14 | <heycam> | Hixie, yep |
| 05:14 | <Hixie> | heycam: in webidl you have the following example: |
| 05:14 | <Hixie> | map[1] = false; |
| 05:14 | <Hixie> | ...which sets a property named "1" |
| 05:15 | <Hixie> | what happens if the indexed properties are automatically set from 0..length-1 |
| 05:15 | <Hixie> | and you set map[0] = true; |
| 05:15 | <Hixie> | and then fetch map[0] |
| 05:15 | <Hixie> | if you see what i mean |
| 05:15 | <Hixie> | sorry, i'm not expressing myself well |
| 05:16 | <heycam> | sorry i didn't understand :) |
| 05:16 | <Hixie> | heycam: the concern comes from the Storage object, where you can get the keys by index, and then index into the keys to get the values |
| 05:16 | <Hixie> | heycam: there is a clash if someone sets the key "0" and then fetches the property "0" -- it'll return "0" because that's the name of the key |
| 05:16 | <Hixie> | but then if you fetch the property "0", you'll still just get "0", not the value of the key "0" |
| 05:17 | <Hixie> | because the keys and the indexes are in the same namespace |
| 05:17 | <Hixie> | i'm wondering whether to ban numeric keys to get around this |
| 05:17 | <Hixie> | or to just say "tough" |
| 05:17 | <heycam> | Hixie, i see what you mean now |
| 05:17 | <heycam> | perhaps that isn't good design to have numeric values also be valid key names |
| 05:18 | <Hixie> | yeah |
| 05:18 | <heycam> | and to have the property getting be the way to access both key name and key value |
| 05:18 | <Hixie> | what syntax should i disallow? |
| 05:18 | <Hixie> | [1-9][0-9]* ? |
| 05:18 | <heycam> | um |
| 05:19 | <heycam> | i *think* |
| 05:19 | <Hixie> | as in, indexes matching that regexp |
| 05:19 | <heycam> | you mean keys? |
| 05:19 | <Hixie> | right sorry |
| 05:19 | <heycam> | whatever es232 says for how it distinguishes indexes vs names for Array objects |
| 05:20 | <heycam> | which i think works out to [1-9][0-9]*, where the value is < 2**32 - 1 |
| 05:20 | <heycam> | (and note the < there rather than <=) |
| 05:21 | <heycam> | that same distinguishing is done in the webidl [[Put]], to determine whether to invoke the index or name getters/setters |
| 05:21 | <heycam> | actually no that last statement is false |
| 05:21 | <heycam> | it uses the "names of named properties" etc. for that |
| 05:22 | <Hixie> | yeah i had looked there |
| 05:22 | <heycam> | er s/232/262/ earlier |
| 05:23 | <heycam> | http://bclary.com/2004/11/07/#a-15.4.5.1 |
| 05:23 | <heycam> | oh, it just says "If P is not an array index"... |
| 05:23 | <heycam> | http://bclary.com/2004/11/07/#a-15.4 |
| 05:23 | <heycam> | A property name P (in the form of a string value) is an array index if and only if ToString(ToUint32(P)) is equal to P and ToUint32(P) is not equal to 232 - 1. |
| 05:24 | <heycam> | (thats 2**32 - 1 at the end) |
| 05:24 | <heycam> | so i think that's equivalent to matching the string against [1-9][0-9]* and ensuring it's < 2**32 - 1 |
| 05:25 | <Hixie> | yeah i found that, i thought you had already seen it when you said the 2**32 - 1 thing :-) |
| 05:25 | <heycam> | yeah i had, but ages ago... |
| 05:25 | <heycam> | :) |
| 05:27 | heycam | brb coffee |
| 05:32 | <Hixie> | heycam: [[Put]] is broken, as far as i can tell. |
| 05:33 | <Hixie> | oh wait |
| 05:33 | <Hixie> | no it isn't |
| 05:33 | <Hixie> | i've just been really confused about how named properties should be defined |
| 05:34 | <Hixie> | maybe not |
| 05:34 | <heycam> | it's possible it's broken |
| 05:35 | <heycam> | i really should make it a structured algorithm instead of a big 40-step flat one! |
| 05:35 | <Hixie> | heycam: if i have an empty Storage object, are there any "names of the supported named properties"? |
| 05:35 | <heycam> | it is just up to how you define the "names of the supported named properties" |
| 05:35 | <heycam> | btw, if you can come up with better terminology for those things, i'm open to suggestions :) |
| 05:36 | <Hixie> | heycam: i don't understand "it is just up to how you define the "names of the supported named properties"" |
| 05:37 | <heycam> | got a pointer to the spec? |
| 05:37 | <Hixie> | which? |
| 05:37 | <heycam> | Storage? |
| 05:38 | <Hixie> | http://dev.w3.org/html5/webstorage/ but i'm more concerned about what the spec _should_ say |
| 05:38 | <heycam> | right, i just want to work out what it's trying to say first |
| 05:38 | <heycam> | so you have this statement in there at the moment: "The names of the supported named properties on a Storage object are the keys of each key/value pair currently present in the list associated with the object." |
| 05:38 | <heycam> | so if the list associated with the object is empty, then there'll be no named properties |
| 05:39 | <heycam> | oh sorry i think i misinterpreted your question earlier |
| 05:39 | <heycam> | i thought you were saying "how do you say that there are no names of the supported named properties" |
| 05:39 | <heycam> | so the answer to your actual question is: no |
| 05:40 | heycam | back in a couplea minutes, coffee is brewed! |
| 05:41 | <Hixie> | ok if the answer is no then: How do I ever get to [NameCreator] given the definition of [[Put]]? |
| 05:45 | <heycam> | the answer (it seems) is that you can't |
| 05:45 | <heycam> | so you're right, it's buggy |
| 05:45 | <Hixie> | woo, i win |
| 05:45 | <heycam> | ^_^ |
| 05:45 | <heycam> | similarly for indexes too |
| 05:46 | <heycam> | i'll make a note in the spec to fix later |
| 05:46 | <Hixie> | so the reason i was looking there is i was hoping that you would automatically dispatch to [NameCreator] or [IndexCreator] based on what we discussed earlier |
| 05:46 | <Hixie> | and _not_ have them fallback to each other |
| 05:46 | <heycam> | ah i see |
| 05:46 | <Hixie> | so that all i have to do to fix Storage is only add [NameCreator] and not add [IndexCreator] |
| 05:47 | <heycam> | ok. so that might be better, to distinguish between indexes and names like that. |
| 05:47 | <Hixie> | cool |
| 05:47 | <heycam> | i wonder about things like the data-* attribute interface tho |
| 05:47 | <heycam> | where there are only names, effectively |
| 05:47 | <Hixie> | i was about to add IndexCreator to that |
| 05:47 | <heycam> | and you want numbers to work there too |
| 05:47 | <heycam> | ok |
| 05:47 | <Hixie> | NameGetter and NameSetter can still work as now |
| 05:48 | <Hixie> | since they work from a fixed list |
| 05:48 | <heycam> | yeah you could just have both index properties and name properties defer to the same abstract list of items |
| 05:48 | <Hixie> | well as written now the spec already handles name properties that are numbers and already avoids clashes if you have both |
| 05:48 | <heycam> | ok i think that makes more sense, rather than making other spec writers worry about confusion of indexes/names |
| 05:49 | <Hixie> | so for DOMStringMap we're agreed that all I need is [NameCreator, IndexCreator, NameDeleter, NameGetter, NameSetter] interface DOMStringMap {} |
| 05:49 | <Hixie> | and some prose |
| 05:49 | <Hixie> | right? |
| 05:49 | <heycam> | hum, no |
| 05:50 | <heycam> | not if i changed it to distinguish between indexes and names more strongly |
| 05:50 | <Hixie> | i would only have it distinguish for creation |
| 05:50 | <heycam> | you mean, as written? |
| 05:50 | <heycam> | (assuming the bugs for getting to the creators were fixed?) |
| 05:50 | <Hixie> | yes |
| 05:50 | <heycam> | ok so you don't want to force indexes and names apart? |
| 05:51 | <heycam> | except for the creators? |
| 05:51 | <Hixie> | right |
| 05:51 | <Hixie> | exactly |
| 05:51 | <heycam> | ok |
| 05:51 | <Hixie> | i think that's what's easiest for spec authors, anyway |
| 05:51 | <Hixie> | probably easiest for you too :-) |
| 05:51 | <Hixie> | you already do the work of making sure that indexed properties win over named properties in case both are there |
| 05:51 | <Hixie> | so there's no clash other than with creation, which right now is buggy adn makes no sense |
| 05:51 | <heycam> | do i? |
| 05:51 | <heycam> | i thought it was the other way around |
| 05:51 | <Hixie> | yeah |
| 05:52 | <Hixie> | oh i didn't check which wins |
| 05:52 | <Hixie> | yeah i guess named wins |
| 05:52 | <heycam> | right, named wins |
| 05:52 | <heycam> | and i think i chose that because of how some html interfaces happened to work |
| 05:52 | <heycam> | collections or something |
| 05:53 | <Hixie> | hmmm |
| 05:54 | <Hixie> | i wonder whether i care for Storage |
| 05:54 | <Hixie> | because if it's that way, then it doesn't really matter if we distinguish namecreator and indexcreator |
| 05:54 | <Hixie> | we can just always have namecreator run, and i don't need to worry about preventing numeric keys being added |
| 05:54 | <Hixie> | since it'll still work |
| 05:55 | <heycam> | so: if there's no indexcreator, then a property named "1" would still invoke the namecreator? |
| 05:55 | <Hixie> | i guess |
| 05:55 | <Hixie> | yeah |
| 05:55 | <Hixie> | i guess you'd give numbers to the indexcreator if there is one |
| 05:55 | <heycam> | mm |
| 05:55 | <Hixie> | and if there isn't, just fall back to namecreator |
| 05:55 | <heycam> | i guess that'd work |
| 05:55 | <heycam> | it's not *too* confusing |
| 05:56 | <heycam> | *ahem* do you mind if you mail public-webapps with exactly what you want? |
| 05:57 | <Hixie> | sure |
| 05:57 | <heycam> | i fear i'll get confused and do something else, otherwise :) |
| 05:59 | <heycam> | thanks |
| 06:01 | <Hixie> | sent |
| 06:02 | <heycam> | cool |
| 06:58 | <Hixie> | Philip`: yt? |
| 08:09 | <Philip`> | Hixie: Yes |
| 08:10 | <Hixie> | it was about the shadows |
| 08:10 | <Hixie> | i sent e-mail instead |
| 08:20 | <annevk5> | Hixie, any chance you can get to my webstorage feedback soonish? |
| 08:30 | <Philip`> | Hixie: I hope there wasn't anything in that e-mail I was meant to respond to |
| 08:34 | <Hixie> | annevk5: i can reply to them now if you want |
| 08:34 | <Hixie> | annevk5: are they all [webstorage]? |
| 08:34 | <annevk5> | Hixie, yes |
| 08:47 | <Hixie> | annevk5: 'storage' doesn't really enable fork bombing any more than postMessage() does |
| 08:47 | <Hixie> | annevk5: it's just an amplification effect |
| 08:47 | <Hixie> | annevk5: you could do the same thing with, say, mutation events (do two mutations per event) |
| 08:47 | <Hixie> | unless i misunderstand something |
| 09:25 | <Hixie> | annevk2: done |
| 09:26 | <Hixie> | Philip`: not really |
| 09:29 | <Hixie> | zcorpan_: it seems like the best solution might be to get rid of MEDIA_ERR_NONE_SUPPORTED altogether and _only_ use the error events on the source elements |
| 09:35 | <annevk2> | Hixie, fair enough I suppose |
| 09:35 | <annevk2> | Hixie, and thanks |
| 09:39 | <zcorpan_> | Hixie: hmm. yeah, maybe. for src="" you would fire error on the <video>? |
| 09:39 | <Hixie> | yeah, seems reasonable |
| 09:39 | <zcorpan_> | Hixie: authors would then have to listen on error on the last <source>, which seems ok |
| 09:39 | <Hixie> | yeah |
| 09:40 | <zcorpan_> | ok. philipj agreed |
| 09:43 | <zcorpan_> | there'd be asymmetry with 'load', but maybe that's ok |
| 09:44 | <zcorpan_> | Hixie: should i send email? |
| 09:44 | <Hixie> | nah s'ok i got it |
| 09:44 | <zcorpan_> | ok |
| 10:02 | <Hixie> | zcorpan_: i'll do it tomorrow, getting too tired to work out how to solve the race condition problem he brought up in that other mail |
| 13:22 | <Philip`> | jgraham: Your recent email doesn't link to the right URL for data |
| 13:28 | <jgraham> | Philip`: Oh. Oops |
| 13:54 | Philip` | wonders if jgraham is planning to post an erratum for that issue |
| 14:30 | jgraham | didn't think that anyone would be interested enough but he can post an erratum if Philip` likes |
| 14:43 | <Philip`> | jgraham: Presumably you thought it was worthwhile including the link with your original mail, so I guess it would be similarly worthwhile to include the correct link in a followup |
| 14:45 | Philip` | discovers PGF/TikZ, which is surprisingly nice |
| 14:45 | <Philip`> | ...as a declarative way of constructing diagrams in LaTeX |
| 14:49 | <cryzed> | Hey |
| 14:49 | <cryzed> | I'm just here to ask if you could fix the following |
| 14:49 | <cryzed> | html5lib/inputstream.py:448: DeprecationWarning: object.__init__() takes no parameters |
| 14:49 | <cryzed> | str.__init__(self, value) |
| 14:49 | <cryzed> | Or would that brack compatibility with python 2.5.4? |
| 14:49 | <cryzed> | I'm using 2.6.2 |
| 14:59 | Philip` | isn't sure whether it's currently possible to fix anything in html5lib, or if its source repository is too much in flux to risk committing any changes |
| 15:13 | <jgraham> | cryzed: I remember fixing that for the python 3 branch. So I guess it would be good to fix it on trunk now :) |
| 15:13 | <jgraham> | Philip`: It should be stable now I think |
| 15:15 | <jgraham> | But I guess you should sithc to using hg |
| 15:15 | <jgraham> | *switch |
| 15:17 | <cryzed> | So basically |
| 15:17 | <cryzed> | a hg source grab |
| 15:17 | <cryzed> | should do the trick now? |
| 15:19 | <jgraham> | cryzed: In theory :) |
| 15:19 | <cryzed> | okay, thanks :) |
| 15:19 | <cryzed> | When are you going to make the next "official" release? |
| 15:20 | <cryzed> | And on the google-code-homepage the following is mentioned: Support for minidom, ElementTree (including cElementTree and lxml.etree), BeautifulSoup and custom simpletree output formats |
| 15:20 | <cryzed> | I don't know minidom, and simpletree |
| 15:20 | <cryzed> | Is there any info about them? |
| 15:22 | <ossud> | hi! if i write you guys an email everytime i find an error in the html5 page ... wouldn't that annoy you ? |
| 15:22 | <jgraham> | cryzed: minidom is the python stdlib implementation of DOM Core |
| 15:23 | <jgraham> | It kinda sucks |
| 15:23 | <jgraham> | simpletree was a throaway tree implemntation I wrote to test html5lib |
| 15:23 | <cryzed> | So it's shitty? :D |
| 15:23 | <ossud> | btw... is there a better way of letting you know about this ? |
| 15:23 | <cryzed> | ossud, you can report bugs |
| 15:23 | <cryzed> | ossud, @ the google code page |
| 15:23 | <cryzed> | ossud, the "Bug Tracker" |
| 15:24 | <cryzed> | jgraham, do you know what I would absolutetely love? :D |
| 15:24 | <cryzed> | jgraham, A mix of BeautifulSoup and lxml.html etree |
| 15:24 | <cryzed> | jgraham, Allowing you the flexibility of BeautifulSoup while Supporting more advanced stuff |
| 15:24 | <cryzed> | like XPath |
| 15:25 | <ossud> | there are only like 2 issues in html5 O_o |
| 15:25 | <ossud> | (on google code) |
| 15:29 | <ossud> | how can i get into html5.org/tools/web-apps-tracker ? |
| 15:44 | <jgraham> | cryzed: Yeah, you don't want to use simpletreee for anything. Even though it is the default tree type |
| 15:44 | <jgraham> | Dunno what to do about that though because you don't want to use minidom for anything either |
| 15:44 | <jgraham> | and nothing else comes with the stdlib |
| 15:45 | <jgraham> | Actually I guess I could make ElementTree the default. I wonder how many people would complain |
| 15:45 | <jgraham> | ossud: What bugs do you want to report? Bugs in the spec? |
| 15:48 | <ossud> | mostly typos ^^ |
| 15:49 | <ossud> | *in the spec |
| 15:50 | <jgraham> | ossud: You can either use the w3c.org bugzilla or use the mailing list. I guess one typo per email is not very friendly though :) |
| 15:51 | <ossud> | the w3c bugzilla?? how cool is that! :) |
| 15:51 | <cryzed> | jgraham, I really like the BeautifulSoup tree though :P |
| 15:52 | <cryzed> | jgraham, It's just very hard to correctly extract whole paragraphs of text out of webapges with the ElementTree API, while preserving the formatting and stripping the html tags |
| 15:55 | <gsnedders> | Oh stupid slow intarwebs! |
| 15:56 | <jgraham> | cryzed: html5lib really needs a maintainer for the BeautifulSoup api |
| 15:57 | <cryzed> | jgraham, I don't really have any clue how BS works internally |
| 15:57 | <cryzed> | jgraham, I just like to use it :D |
| 15:58 | <jgraham> | cryzed: So on a list of ideal candidates you score 1/2 whereas I score 0/2 and I wrote the treebuilder |
| 15:58 | <cryzed> | jgraham, haha ^^ |
| 15:58 | <jgraham> | (does BS support namespaces?) |
| 15:58 | <cryzed> | what do you mean exactly |
| 15:58 | <cryzed> | with namespaces? |
| 15:58 | <jgraham> | The ability to have elements in differnt namespaces |
| 16:01 | <jgraham> | like to put an element called svg in a namespace identified by the URI http://www.w3.org/2000/svg |
| 16:04 | <cryzed> | I've got no clue actually |
| 16:04 | <cryzed> | oO |
| 16:05 | <jgraham> | If not, it will be "fun" to get it to work with MathML/SVG. Can probably use Clarke notation and just live with the suckiness or something though |
| 16:06 | <cryzed> | jgraham, btw, I'm still getting |
| 16:06 | <cryzed> | the error |
| 16:06 | <cryzed> | with the newest hg checkout |
| 16:06 | <cryzed> | DeprecationWarning: object.__init__() takes no parameters |
| 16:06 | <cryzed> | str.__init__(self, value) |
| 16:06 | <cryzed> | Or rather warning |
| 16:06 | <jgraham> | cryzed: I didn't apply the patch yet |
| 16:07 | <cryzed> | oh |
| 16:07 | <cryzed> | shoot |
| 16:07 | <cryzed> | Could you? ;D? |
| 16:11 | <Philip`> | jgraham: http://www.crummy.com/2009/04/09/0 - "I'll be writing an html5lib tree builder and packaging it and the lxml builder in Beautiful Soup" - he's probably a good person to be maintainer |
| 16:13 | <Philip`> | gsnedders: Better than the intarwebs here, which are currently lacking all the normal intar functionality because of power cuts and not-very-good UPSes |
| 16:13 | <Philip`> | (unless they've fixed it already) |
| 16:14 | <Philip`> | (which I guess they have, since I can access the box sitting at my feet via London) |
| 16:15 | <jgraham> | cryzed: Try now |
| 16:16 | <cryzed> | kk |
| 16:16 | <Philip`> | The commit mail's subject line is horrid |
| 16:17 | <Philip`> | [html5lib push] 77f13a977be6f47a9724ee5dbfee756eaf12317e - Fix deprecation warning |
| 16:17 | <gsnedders> | Philip`: We had no network/internet at school yesterday because the other side of the split-site school had no power. |
| 16:17 | <Philip`> | I want to see the actual commit message in my mail client's little pop-up alert box, not forty hex digits |
| 16:18 | <gsnedders> | But how else will you know what revision it is!? |
| 16:18 | <Philip`> | It should make up a monotonically increasing integer and use that as the revision number |
| 16:19 | <jgraham> | Forty hex digits sitting on the wall, forty hex digits sitting on the wall, and if one hex digit should accidentially fall... |
| 16:20 | <gsnedders> | hg won't care. |
| 16:20 | <Philip`> | Hopefully the hex digit would pull its partner off the wall too |
| 16:21 | <Philip`> | because hex digits are aesthetically displeasing if they don't always come in pairs |
| 16:30 | <cryzed> | jgraham, works |
| 16:30 | <cryzed> | jgraham, thanks |
| 16:30 | <cryzed> | jgraham, It's probably fully 2.6.2 compatible now |
| 16:30 | <cryzed> | :D |
| 17:28 | Philip` | receives "508 messages from Google Code" |
| 17:29 | <Philip`> | It's quite nice that they handle that situation sensibly, not by sending 508 emails or dropping them all entirely |
| 19:36 | <Hixie> | ossud: send as much feedback as you like, one per e-mail or one big e-mail or anything in between, it doesn't matter it'll get treated the same in the end :-) |
| 21:03 | <Hixie> | hsivonen: any particular examples you want in the parser section? |
| 21:07 | <jgraham> | Unicode or Death? |
| 21:10 | <Philip`> | That's a tough choice |
| 22:31 | gsnedders | wonders what anne and Lachy are tweeting |
| 22:33 | <Lachy> | gsnedders, 010101110110100001100001011101000011111100100000010110010110111101110101001000000110010001101111011011100010011101110100001000000111001101110000011001010110000101101011001000000110001001101001011011100110000101110010011110010011111100100001 |
| 22:33 | <gsnedders> | Lachy: I got that. But why? |
| 22:39 | <Lachy> | gsnedders, you gotta be here with us in Oslo to understand why. |
| 22:39 | <jgraham> | That was much less funny than I had hoped. I guess I don't get the context |
| 22:39 | jgraham | really should be asleep |