| 01:03 | <Hixie> | well, i see my e-mail wasn't clear enough |
| 01:03 | <Hixie> | sigh |
| 01:03 | <TabAtkins> | On the other hand, I found the response pretty amusing. |
| 01:05 | <Hixie> | yes :-) |
| 01:17 | <Hixie> | hsivonen: yt? |
| 01:48 | <TabAtkins> | Oh wow, really? A legacy D-Link router? That's crazy. |
| 01:52 | <Hixie> | eseidel: i've begun changing the parser |
| 01:52 | <Hixie> | you can track changes at http://html5.org/tools/web-apps-tracker |
| 02:20 | <eseidel> | Hixie: thank you. I'll start implemnting your fixes tomorrow. I still need to talk to hsivonen, but he's been AWOL :p |
| 02:21 | <eseidel> | hsivonen: we should really sync up our test cases. We've written a bunch more for your fancy harness |
| 02:25 | <eseidel> | Hixie: I do not understand the mental model behind foreign content |
| 02:25 | <eseidel> | it was not clear to me from the spec |
| 02:25 | <eseidel> | sec |
| 02:26 | <Hixie> | mental model? |
| 02:28 | <eseidel> | Hixie: sorry, got a phoen call right as I was starting to explain |
| 02:28 | <eseidel> | it's unclear what to do with misnested tags in forieng content mode |
| 02:28 | <Hixie> | misnested how precisely? |
| 02:29 | <eseidel> | <div><svg></div></svg> |
| 02:29 | <Hixie> | (my usual answer is "just do what the spec says", but i'll wait until the spec bugs are fixed before saying that again :-) ) |
| 02:29 | <eseidel> | is the idea that any non-foreign tag, breaks out of fo? |
| 02:29 | <eseidel> | fc, rather |
| 02:29 | <Hixie> | that should be treated as <div><svg></svg></div></bogus>, iirc |
| 02:29 | <eseidel> | interesting |
| 02:30 | <Hixie> | (is that what the spec now says?) |
| 02:30 | <Hixie> | basically the idea was that we wanted to add svg and mathml parsing with minimum impact on existing documents |
| 02:30 | <Hixie> | including documents that already contained bogus <svg> elements |
| 02:30 | <eseidel> | Hixie: I think I'll wait until you're done editing |
| 02:30 | <Hixie> | k |
| 02:30 | <eseidel> | since I don't feel i'm explaining myself well |
| 02:31 | <eseidel> | likely due to distractions |
| 02:31 | <Hixie> | k |
| 02:34 | <eseidel> | Hixie: one related confusion. If you see a mis-nested close tag in foreign content, right now the spec has you just pop all the way back until that tag makes sense. Which can ahve you popping through other insertion modes where the tag would be ignored. Another way to handle that would be any time you see a mis-nested close tag, to break out of FC immediately and re-process. |
| 02:34 | <Hixie> | do you have an example of popping through other inserting modes? |
| 02:35 | <eseidel> | <body><svg></html></svg> would be one example I think. |
| 02:35 | <eseidel> | I need to find an example where we ignore close tags, setc. |
| 02:35 | <Hixie> | you don't pop through other insertion modes where it would be ignored in that example do you? |
| 02:36 | <Hixie> | i mean, <body></html> won't ignore anything |
| 02:36 | <Hixie> | not sure what you mean |
| 02:36 | <eseidel> | <body><svg><col>Foo</svg> |
| 02:36 | <eseidel> | normally the "col" would be ignored, but since it's in the SVG, it causes it to break out of the SVG. |
| 02:36 | eseidel | looks for a better example |
| 02:37 | <Hixie> | no, that results in a <col> element in the SVG namespace |
| 02:37 | <eseidel> | Hixie: ah, <body><svg></foo><circle></svg> |
| 02:38 | <eseidel> | currently that would crash, if I remember the spec correctly (you'd walk off the bottom lookcing for <foo> |
| 02:38 | <Hixie> | i just fixed that one |
| 02:38 | <eseidel> | ok |
| 02:38 | <eseidel> | but </foo> woudl be ignored in body, so seems we shoudl ignore in in svg |
| 02:38 | <Hixie> | (not sure if i fixed it right) |
| 02:38 | <Hixie> | (let's see) |
| 02:38 | <eseidel> | Hixie: I'll implement whatever you wrote tomorrow, and then I can pick on you more then :) |
| 02:38 | <eseidel> | I'll leave you to work now |
| 02:38 | <Hixie> | k |
| 02:38 | <Hixie> | later |
| 02:41 | <Hixie> | (ok, looks like the </foo> in the example above just gets ignored now) |
| 02:43 | <eseidel> | (that's our current behavior too) |
| 02:43 | <Hixie> | (but in the case like <body><svg><g><foreignContent><b></g>, the </g> is not ignored, because the in body mode closes it) |
| 02:44 | <Hixie> | (not sure that this is completely coherent, but we'll have to try various examples and see if they all make sense now) |
| 02:44 | <eseidel> | k |
| 02:44 | <eseidel> | would like to find some way for hsivonen and I to better share test cases so we can implement these same things here |
| 02:44 | <eseidel> | our code is wildly different :) |
| 02:44 | <eseidel> | which is a good thing, I think |
| 02:45 | <Hixie> | yes |
| 02:47 | <eseidel> | <b id="1"><p><script>document.getElementById("1").id = "2"</script></p>TEXT</b> may turn into a spec bug... It's nice (mentally) to re-use the token, but "expensive" from an implementation perspective |
| 02:48 | <Hixie> | eseidel: as opposed to what? |
| 02:48 | <Hixie> | the spec used to clone the actual elements, but hsivonen asked me to use the token instead so he didn't need to keep a hold of the actual DOM since he's doing it off-thread |
| 02:49 | <eseidel> | ha. |
| 02:49 | <eseidel> | I think mozilla is crazy to do the parser off-thread. :) |
| 02:49 | <Hixie> | no disagreement here, but they get a minor advantage since they took the plunge and implemented it first :-) |
| 02:49 | <eseidel> | old WK clones the element, new one does too. I haven't checke IE |
| 02:50 | <Hixie> | IE doesn't clone |
| 02:50 | <Hixie> | it uses the same element |
| 02:50 | <Hixie> | you get non-tree DOMs |
| 02:50 | <Hixie> | it's quite special |
| 02:50 | <eseidel> | oh goodie :) |
| 02:50 | <Hixie> | at least old IEs did |
| 02:50 | <Hixie> | dunno what the recent ones do |
| 02:50 | <roc> | what's crazy about doing the parser off-thread? |
| 02:50 | <eseidel> | Hixie: I mean, we can store off the tokens (or the attributes from the tokens). its just more mallocs we'd probably like to avoid |
| 02:51 | <eseidel> | I'm not sure you want to pay all the sychronization cost. |
| 02:51 | <eseidel> | I mean, I liek the idea of using more threads in the engine, given the way hardware is going |
| 02:51 | <eseidel> | but doing all the dom access, which has to pretend to be single theaded, seems ouchy |
| 02:51 | <Hixie> | eseidel: why is it any more mallocs? |
| 02:51 | <roc> | the synchronization costs are low |
| 02:51 | <Hixie> | eseidel: the way they implemented it they have minimal synchronisation |
| 02:52 | <roc> | the DOM is not accessed directly from the parser thread |
| 02:52 | <eseidel> | Hixie: cause we have to copy the attributes array in case you change it in script |
| 02:52 | <Hixie> | (it's pretty cleverly done actually) |
| 02:52 | <Hixie> | eseidel: oh i see |
| 02:52 | <roc> | the parser generates a list of "tree operations" which are posted to the main thread |
| 02:52 | <eseidel> | i see. |
| 02:52 | <Hixie> | eseidel: can't you do a copy-on-write or something? i guess that'd be a performance hit too. |
| 02:52 | <eseidel> | Hixie: I'm not sure this will end up being a big deal. but for now we're not going to implement that quirk. |
| 02:53 | <eseidel> | Hixie: I have a test for it and a big FIXME so we won't forget :) |
| 02:53 | <Hixie> | cool |
| 02:53 | <eseidel> | hsivonen still owes me a response to my "<a>1<button>2</a>3</button>" test case |
| 02:53 | <eseidel> | I think minefield builds the wrong tree for that |
| 02:54 | <eseidel> | somehow </a> is breaking out of the <button> in minefield, which makes no sense to me |
| 02:55 | <Hixie> | there's some weird rules around </a> iirc |
| 02:56 | <Hixie> | oh that's for the <a><button><a> case, nevermind |
| 02:56 | <Hixie> | not <a><button</a> |
| 02:57 | <eseidel> | I filed https://bugzilla.mozilla.org/show_bug.cgi?id=578568 |
| 02:57 | <Hixie> | ok i'm done for the day, will continue with these fixes tomorrow |
| 03:07 | <boblet> | hixie: for links.html#examples-1 you should combine George Washington’s itemprop="fn" and itemprop="n" to itemprop="fn n" |
| 03:09 | <boblet> | also having Jack Bauer’s given-/family-names in meta seems odd since they’re already in content |
| 03:35 | <MikeSmith> | http://www.boston.com/bostonglobe/ideas/articles/2010/07/11/how_facts_backfire/ |
| 03:36 | <MikeSmith> | "when misinformed people, particularly political partisans, were exposed to corrected facts in news stories, they rarely changed their minds." |
| 03:36 | <MikeSmith> | "In fact, they often became even more strongly set in their beliefs." |
| 03:37 | <othermaciej> | I totally disagree with that story |
| 03:37 | <othermaciej> | cause I heard somewhere that people can change their minds |
| 03:38 | <boblet> | heh |
| 03:39 | <MikeSmith> | " the ones who were the most confident they were right were by and large the ones who knew the least about the topic" |
| 03:39 | <MikeSmith> | “It implies not only that most people will resist correcting their factual beliefs,” he wrote, “but also that the very people who most need to correct them will be least likely to do so.” |
| 03:40 | <boblet> | MikeSmith: so that explains … America then, huh |
| 03:40 | boblet | ducks |
| 03:48 | <MikeSmith> | boblet: explains quite a lot of things |
| 03:49 | <boblet> | MikeSmith: sadly, yes |
| 04:27 | <variable> | anyone here want a hope ticket for saterday/sunday for a cheaper price? I found out that I likely won't be able to stay the entire time ? |
| 04:27 | <variable> | woops |
| 04:27 | <variable> | wrong channel |
| 04:47 | <Hixie> | boblet: please file bugs for those (use the box at the bottom to do it automatically into the right component) |
| 05:12 | <variable> | Hixie, do you remember of any statments by you that about about direct client side includes? |
| 07:42 | <annevk> | we won't get to Last Call this year in the HTML WG? |
| 07:42 | <annevk> | geez |
| 07:43 | <annevk> | was'nt |
| 07:43 | <boblet> | Hixie: will do |
| 07:43 | <annevk> | wasn't Paul Cotton specifically assigned to help us get through this quicker or something? |
| 07:43 | <annevk> | oh well |
| 07:43 | <Hixie> | annevk: why wouldn't we get to LC this year? |
| 07:44 | <Hixie> | (if we don't get to LC this year, we surely can't make REC this quarter as per our charter!) |
| 07:44 | <Hixie> | i guess we can still make CR by 2012 like i predicted though |
| 07:46 | <zcorpan_> | Hixie: you mean WHATWG CR? |
| 07:46 | <Hixie> | i meant htmlwg CR |
| 07:46 | <Slaanesh> | It seems the longer the W3C process is dragged out, the more likely any given feature will become a victim of cross-browser implementations |
| 07:47 | <Hixie> | yup |
| 07:49 | <zcorpan_> | Slaanesh: i don't think the w3c process really affect browser implementations one way or the other |
| 07:51 | <annevk> | Hixie, that's what Sam said in his reply to Jonas |
| 07:51 | <Hixie> | ah |
| 07:51 | <annevk> | "unless we split the draft" .... |
| 07:54 | <mhausenblas> | MikeSmith around? re "Microdata/Microformat/RDF community should collaboratively write a document explaining about machine-readibility using non-RDF terms" |
| 07:55 | <mhausenblas> | it totally agree and would happily contribute to such an effort, MikeSmith |
| 07:56 | <MikeSmith> | mhausenblas: cool |
| 07:56 | <MikeSmith> | I'm happy to let anybody drive it |
| 07:56 | <mhausenblas> | maybe you want to take a quick look at http://linkeddata.deri.ie/node/58 |
| 07:56 | <mhausenblas> | MikeSmith, I know who should not drive it ... /me :D |
| 07:57 | <mhausenblas> | link above was one of my earlier attempts (yes, restricted to RDF, I know, I know) |
| 07:57 | <mhausenblas> | but you get the idea? |
| 07:57 | MikeSmith | takes a look at the link |
| 07:57 | <mhausenblas> | tx |
| 07:57 | <MikeSmith> | mhausenblas: well, we now know at least two people who should not drive it :) |
| 07:57 | <mhausenblas> | hehe |
| 07:58 | <mhausenblas> | seriously, I guess someone rather neutral would be ideal |
| 07:58 | <MikeSmith> | yeah |
| 07:58 | <mhausenblas> | just fire up an etherpad and spread the word (here?) |
| 08:02 | <Slaanesh> | zcorpan_: Not the current one, perhaps. But if w3c wants to be involved in UA conformance later, they risk being too late |
| 08:03 | <annevk> | fwiw, "the w3c" includes UAs |
| 08:04 | <Slaanesh> | "The subset of w3c left after removing the intersection with whatwg" maybe? |
| 08:04 | <annevk> | something like that, yeah |
| 08:05 | <Slaanesh> | I wonder, if the suggestion to drop all author conformance had passed, where would be we now? CR? |
| 08:05 | <annevk> | I was just saying it since some people seem to have the impression the W3C is some kind of standalone entity, while it's mostly just a collection of lots of companies |
| 08:06 | <Hixie> | Slaanesh: dropping all authoring conformance criteria would have made very little difference so far |
| 08:06 | <Hixie> | Slaanesh: most of the issues have been over editorial text |
| 08:07 | <Slaanesh> | But isn't much of the text about author conformance? |
| 08:07 | <Hixie> | no |
| 08:07 | <Hixie> | most of it is implementation rules |
| 08:07 | <Hixie> | (i.e. UA conformance criteria) |
| 08:08 | <Slaanesh> | Selective memory on my part, I guess |
| 08:08 | <Slaanesh> | ... why do the church bells ring at 09:10 every day in Zurich? |
| 08:09 | <Hixie> | Slaanesh: calling the faithful to church |
| 08:10 | <Hixie> | (at a guess based on other churches in switzerland) |
| 08:11 | <MikeSmith> | mhausenblas: not sure what would be the best way to jump start it.. comes back to the usual problem of needing somebody who has the time and motivation to make it happen |
| 08:12 | <Slaanesh> | Hixie: I thought all the faithful were at work already ;) |
| 08:12 | <mhausenblas> | MikeSmith, I'm happy to *take* time for it (and I certainly have the motivation) ... BUT |
| 08:13 | <mhausenblas> | I also know that if I propose it the typical reaction here and in some other place would be a more or less friendly fck off |
| 08:13 | <MikeSmith> | Slaanesh: it seems like churches should be trying to call the faithless, anyway |
| 08:14 | <mhausenblas> | so, you see my problem, MikeSmith? ;) |
| 08:14 | <MikeSmith> | mhausenblas: random idea: maybe a Wikipedia article |
| 08:14 | <mhausenblas> | hm |
| 08:14 | <MikeSmith> | I realize that the Wikipedia editor community is as dysfunctional or worse than any |
| 08:15 | mhausenblas | has rather bad experiences with this ... and also seems a bit like misusing Wikipedia |
| 08:15 | <mhausenblas> | well, I think it's clearly against their policy (re using it as a discussion forum) |
| 08:15 | <Hixie> | wikipedia book? :-) |
| 08:15 | <mhausenblas> | hehe |
| 08:15 | <mhausenblas> | whatz your hunch Hixie? |
| 08:15 | <Hixie> | no idea what the topic is :-) |
| 08:15 | <mhausenblas> | I mean, assuming you'd be interested ;) |
| 08:16 | <mhausenblas> | ah |
| 08:16 | <mhausenblas> | re "Microdata/Microformat/RDF community should collaboratively write a document explaining about machine-readibility using non-RDF terms" |
| 08:16 | <jgraham> | eseidel: If you have testcases, please check them in to the html5lib repository |
| 08:16 | <mhausenblas> | MikeSmith and I are discussing how to kick this off |
| 08:16 | <jgraham> | eseidel: I can give you commit access if you need it |
| 08:16 | <Slaanesh> | A vcs repository? |
| 08:17 | <eseidel> | jgraham: I did not know there was a repository. b ut yes, we have lots of tests |
| 08:17 | <jgraham> | eseidel: Also, hsivonen already knows about the <button> weirdness I think. The conclusion is that the spec is probably broken |
| 08:17 | <eseidel> | jgraham: see http://trac.webkit.org/browser/trunk/LayoutTests/html5lib/resources/ |
| 08:18 | <eseidel> | jgraham: yeah, I got CC'd on the right bugs |
| 08:18 | <Hixie> | mhausenblas: what does that mean? |
| 08:18 | <eseidel> | after the fact |
| 08:18 | <mhausenblas> | (MikeSmith I think we should also ask mamund on board - he's doing great stuff at http://amundsen.com/hypermedia/ |
| 08:18 | <jgraham> | eseidel: http://code.google.com/p/html5lib/source/checkout |
| 08:18 | <mhausenblas> | Hixie, an attempt to overcome the silly low-level, syntax-driven fights |
| 08:18 | <mhausenblas> | for a greater, Webish data idea |
| 08:19 | <eseidel> | jgraham: crazy |
| 08:19 | <Hixie> | ah well i'm not your man |
| 08:19 | <Hixie> | i think webish data is a lost cause |
| 08:19 | <mhausenblas> | fair enough |
| 08:19 | <Hixie> | at least machine-readable data |
| 08:19 | <mhausenblas> | interesting. care to explain why? |
| 08:19 | <Hixie> | natural language interpretation is where the real solutions are going to lie |
| 08:19 | <mhausenblas> | ah, right, I see |
| 08:19 | <eseidel> | jgraham: I'll talk with abarth about it, and figure out how we'll go about syncing up |
| 08:19 | <Hixie> | we'll never get a critical mass of authors writing data in common vocabularies using any of the syntaxes discussed, microformats, microdata, rdf*, whatever |
| 08:20 | <Hixie> | i mean, we have enough trouble getting them to use even basic HTML semantics |
| 08:20 | <mhausenblas> | ok, yeah, these are the two fundamental directions I sense as well |
| 08:20 | <mhausenblas> | I agree that it's hard to achieve it, yes |
| 08:20 | <jgraham> | eseidel: OK. I can obviously sync up the tests that are already there if you like |
| 08:20 | <mhausenblas> | true (re "getting them to use even basic HTML semantics") |
| 08:20 | <Hixie> | i think it would require such a fundamental change in the way people are educated throughout the planet that it is for all intents and purposes impossible |
| 08:20 | <jgraham> | eseidel: (although I guess there might be licensing issues?) |
| 08:21 | <Hixie> | i mean, i seriously think that getting this done would require massive investment in education in every computer-literate country |
| 08:21 | <mhausenblas> | hehe Hixie, this is the only (main) difference where I seriously disagree with you ;) |
| 08:21 | <eseidel> | jgraham: abarth and I have written all the tests. as far as I'm concerned, they're public domain |
| 08:21 | <Hixie> | we're talking trillions of dollars, and serious political upheaval |
| 08:21 | <eseidel> | jgraham: I'm 100% certain abarth feels the same |
| 08:21 | <mhausenblas> | but it's happening (see data.gov.uk and data.gov, just to mention a few) |
| 08:22 | <eseidel> | jgraham: note, we don't pass quite all of them yet: http://trac.webkit.org/browser/trunk/LayoutTests/html5lib/runner-expected-html5.txt |
| 08:22 | <Hixie> | mhausenblas: oh individual places will provide data in structured form, sure |
| 08:22 | <mhausenblas> | and I'm not talking so much about the individuals producing structured data |
| 08:22 | <mhausenblas> | hehe |
| 08:22 | <jgraham> | eseidel: Sure :) It might be better for you to add them yourselves to the html5lib repository for the avoidance of doubt though |
| 08:22 | <mhausenblas> | my reasoning is very simple: |
| 08:22 | <eseidel> | jgraham: https://spreadsheets.google.com/ccc?key=0AlC4tS7Ao1fIdEo0SFdLaVpiclBHMVNQcHlTenV5TEE&hl=en is our status |
| 08:22 | <Hixie> | mhausenblas: but they will be rare enough that it's easier to write per-site hard-coded interpreters, and thus it's easier to use dedicated database formats for each one, than to try to embed the data in HTML each time |
| 08:22 | <jgraham> | eseidel: Also, I added some more tests to the html5lib repo recently |
| 08:23 | <jgraham> | So you might want to pull |
| 08:23 | <Hixie> | mhausenblas: trying to crawl the data out of the HTML only makes sense if the vast majority of the web is using this, which is what i don't think will happen |
| 08:23 | <eseidel> | jgraham: good! we would love to pass them! |
| 08:23 | <mhausenblas> | if you (== company, gov agency, whatever) already have HTML out there, why not putting a bit more structure into it (+links) |
| 08:23 | <mhausenblas> | right |
| 08:23 | <Hixie> | mhausenblas: if you (== company, gov agency, whatever) already have data, why not just put it out there in its native form? (e.g. a SQL database) |
| 08:23 | <mhausenblas> | true |
| 08:23 | <Hixie> | that'd be a bazillion times easier to deal with in practice |
| 08:24 | <Hixie> | it's not like these sites are all using the same useful vocabularies |
| 08:24 | <mhausenblas> | but then you're putting it on the Web, not in the Web |
| 08:24 | <Hixie> | sure but who cares |
| 08:24 | <mhausenblas> | well, it's not utilising the most important feature of the Web |
| 08:24 | <mhausenblas> | the links |
| 08:24 | <mhausenblas> | :D |
| 08:24 | <mhausenblas> | (and for the record: I do care ;) |
| 08:24 | <Hixie> | what matters is what the end user benefit is, not whether we're doing things theoretically correctly or in architecturally correct ways |
| 08:24 | <mhausenblas> | exactly |
| 08:25 | <mhausenblas> | Hixie, whatz your take on OData? |
| 08:25 | <Hixie> | better to have a bunch of dedicated sql queries than to try to reuse HTML because it's "in the web not on the web" |
| 08:25 | <Hixie> | OData? |
| 08:25 | <Hixie> | whatz? |
| 08:25 | <mhausenblas> | come on ... |
| 08:25 | <mhausenblas> | you do know MS OData? based on Atom? |
| 08:26 | <jgraham> | eseidel: Just send me the google account email addresses that you and abarth use and I will add you to the committers list |
| 08:26 | <mhausenblas> | s/whatz/what's |
| 08:26 | <Hixie> | one quick google search later, and i have a vague idea |
| 08:26 | <mhausenblas> | right |
| 08:26 | <Hixie> | no opinion, not sure what the point is though |
| 08:26 | <Hixie> | what's wrong with mysql dumps? |
| 08:26 | <mhausenblas> | nothing wrong |
| 08:26 | <mhausenblas> | just requires a lot of manual work to intregrate |
| 08:26 | <Hixie> | i mean, atom is hardly the best format for transferring a terabyte of climate data |
| 08:26 | <mhausenblas> | good point |
| 08:26 | <Hixie> | this is the argument i have a problem with |
| 08:26 | <mhausenblas> | neither is RDF ;) |
| 08:27 | <Hixie> | sql "just requires a lot of manual work to intregrate" |
| 08:27 | <Hixie> | so does everythinge lse |
| 08:27 | <mhausenblas> | no |
| 08:27 | <Hixie> | because nobody is using the same vocabulary as everyone else |
| 08:27 | <mhausenblas> | Webish formats don't |
| 08:27 | <Hixie> | you still have to hardcode everything |
| 08:27 | <Hixie> | well anyway |
| 08:27 | <Hixie> | i have no problem with people trying to solve this problem |
| 08:27 | <Hixie> | i just don't think it's worth my time :-) |
| 08:27 | <mhausenblas> | hehe, fair enough |
| 08:27 | <Hixie> | better to spend the time making computers be able to do this via natural language processing, imho |
| 08:27 | <mhausenblas> | just an aside: even Google is going into this business |
| 08:28 | <mhausenblas> | (see Fusion Tables) |
| 08:28 | <Hixie> | yes, i'm friends with the program manager of the fusion tables team |
| 08:28 | <mhausenblas> | interesting |
| 08:28 | <mhausenblas> | and? |
| 08:28 | <Hixie> | and nothing :-) |
| 08:28 | mhausenblas | was waiting for some dirty background stories |
| 08:28 | <Hixie> | google does many things |
| 08:28 | <mhausenblas> | indeed |
| 08:29 | <mhausenblas> | anyway, thanks for your time Hixie - hope to proof you wrong in some 5-10y :D |
| 08:29 | <Hixie> | good luck :-) |
| 08:29 | <mhausenblas> | hehe, thanks, will need it |
| 08:30 | <mhausenblas> | and, MikeSmith if you find someone to drive this, plz lemme know |
| 08:30 | <MikeSmith> | will do |
| 08:30 | <mhausenblas> | tx! |
| 08:30 | <MikeSmith> | maybe kennyluck will have some ideas |
| 08:30 | <kennyluck> | What was the discussion? |
| 08:32 | <MikeSmith> | kennyluck: see the logs |
| 08:32 | kennyluck | is reading. |
| 08:33 | kennyluck | has the feeling that he spends too much time in the IRC world. :) |
| 08:57 | <kennyluck> | I have to say I am super surprised by the fact that Hixie is not that into the "machine-readible" idea. |
| 08:57 | <kennyluck> | Then what is Microdata for, I wonder. |
| 08:57 | <kennyluck> | Anyway, I go for a fundamental change to computer-science education. |
| 08:57 | <Hixie> | lots of people disagree with me |
| 08:57 | <Hixie> | microdata is for them, in case i'm wrong |
| 08:58 | <kennyluck> | A class on HTML should be required for every collegue student. :) |
| 08:58 | <kennyluck> | Hmm... who are they? Hixie? In this channel? |
| 08:58 | <Hixie> | kennyluck: mhausenblas, for one |
| 08:59 | <Hixie> | tantek is another |
| 08:59 | <Hixie> | all the people who sent in use cases for microdata |
| 08:59 | <Hixie> | microdata is one of the areas of the spec for which i was the most explicit in terms of writing the use cases i was aiming for |
| 08:59 | <Hixie> | (mostly because it was so hard to get anyone to give me actual use cases) |
| 09:00 | <kennyluck> | Ah ha. |
| 09:01 | <Hixie> | see http://lists.w3.org/Archives/Public/public-html/2009May/0207.html |
| 09:01 | <kennyluck> | I am just very interested in the origin of Microdata, I guess. |
| 09:02 | <Hixie> | that e-mail is the index to the e-mails that are the origin of microdata |
| 09:02 | <kennyluck> | Thank you, Hixie. |
| 09:02 | <Hixie> | it's interesting to note that most of the use cases for which microdata is designed are not the use cases that people are always trying to say RDF and co will save the world for |
| 09:03 | <Hixie> | but that's another story |
| 09:03 | <kennyluck> | I guess #swig people should have joined the discussion at the beginning with #whatwg, and we might have had some consesus or something. |
| 09:03 | <kennyluck> | Sure |
| 09:03 | <Hixie> | i invited -- begged for, even -- feedback for like a year on the whatwg list |
| 09:03 | <Hixie> | before doing anything |
| 09:04 | <Hixie> | it was like pulling teeth |
| 09:04 | <Hixie> | i've never had so much trouble getting people to tell me what they wanted |
| 09:04 | <kennyluck> | OK. I feel sorry, really. |
| 09:04 | <Hixie> | it was like everyone thought it was obvious that RDF would solve the world's problems and bring world peace, but nobody could articulate a single concrete use case |
| 09:04 | <Hixie> | anyway |
| 09:05 | <kennyluck> | I noticed that #swig consists of almost academics, so. |
| 09:05 | <kennyluck> | Well, anyway. |
| 09:07 | <kennyluck> | FYI, the RDB2RDF effort aligned with your SQL dump idea, I think, Hixie. |
| 09:07 | <kennyluck> | We need a standardized format for dumping, anyway. |
| 09:07 | <Hixie> | why? |
| 09:08 | <kennyluck> | Although ofcourse RDF might be a poor choice. |
| 09:08 | <kennyluck> | standardized format for dumping? |
| 09:08 | <Hixie> | yeah |
| 09:08 | <kennyluck> | Well, this is what standardization is for, isn't it? |
| 09:08 | <Hixie> | what's the use case for which you need a standardised format for dumping... what? any relational database? |
| 09:09 | <kennyluck> | Yeah. |
| 09:09 | <Hixie> | why are you going to need the same format for 2GB of climate data and 1PB of mars imagery and 100MB of number station logs? |
| 09:10 | <kennyluck> | Hmm.. to save time for processing? |
| 09:10 | <kennyluck> | Becuase we really like "mashups" to happen. |
| 09:10 | <Hixie> | you think the format part of this is going to be where the complexity lies? |
| 09:10 | <kennyluck> | In a large scale, so saving processing time is a good thing to do. |
| 09:10 | <Hixie> | this is what gets me about the whole semantic web |
| 09:11 | <Hixie> | it's solving one problem -- the syntax the data should be in -- despite that being the single simplest part of the entire problem |
| 09:11 | <Hixie> | it's trivial to write a custom parser for each format you want to mash up |
| 09:11 | <Hixie> | the hard part is the UI and the data processing once you've parsed the data |
| 09:11 | <kennyluck> | But since you are not likely to give the parser to other people, so... |
| 09:11 | <Hixie> | who cares what the format is -- that's at most an hour or two to parse the incoming data, and in all likelihood less since most data sources will already have libraries to parse their data formats |
| 09:12 | <Hixie> | that is, to write the parser to parse |
| 09:12 | <kennyluck> | This is arguable, I am not very sure. |
| 09:13 | <Hixie> | it's like looking at the problem of how to solve world hunger, and doing it by standardising the seat belts in the trucks that will be used to carry the food |
| 09:13 | <Hixie> | and then saying that the problem is not essentially solved |
| 09:13 | <Hixie> | s/not/now/ |
| 09:13 | <kennyluck> | The Google Official Blog has an article explaining "machine-readability" |
| 09:13 | <kennyluck> | It's the data provider who understands the data well. |
| 09:13 | <Hixie> | yeah, not everyone at google agrees with me either :-) |
| 09:14 | <kennyluck> | So the data provider ought to convert the data to something that everyone can parse easiliy. |
| 09:14 | <Hixie> | sure, but that doesn't have to be anything standard |
| 09:14 | <Hixie> | they can just provide the data in a MySQL IASM data table for all i care |
| 09:14 | <Hixie> | then all you have to do is install MySQL and use that locally |
| 09:14 | <Hixie> | 30 minutes of work assuming MySQL is already installed |
| 09:15 | <Hixie> | anyway |
| 09:15 | <kennyluck> | Maybe. |
| 09:15 | <kennyluck> | Anyway, thanks for your links. |
| 09:15 | <Hixie> | my point is just that that seems like such a trivial part of the problem space that i don't understand why it's the main thing everyone is always talking about |
| 09:17 | <kennyluck> | This is quite fundamental. Even with NLP, you still need a regular data structure to store your processed data. |
| 09:17 | <kennyluck> | The Semantic Web effort basiclly asks you to provide your NLP result, I guess. |
| 09:17 | <Hixie> | yes, but what is useful for one NLP system isn't going to be useful for another |
| 09:18 | <Hixie> | to put it in an obvious form: RDF isn't the ideal format for bitmaps, for example |
| 09:18 | <kennyluck> | Google's NLP system is certainly useful for everyone. :) |
| 09:18 | <Hixie> | so if your NLP system outputs a bitmap, then RDF isn't going to help |
| 09:18 | <Hixie> | if your NLP system happens to output a quad graph, then sure, it might help |
| 09:18 | <Hixie> | if it outputs a tree, then JSON might be better |
| 09:18 | <kennyluck> | Hixie, this is not likely to be the truth. (ref. NLP system outputs bitmaps) |
| 09:19 | <Hixie> | it's just an extreme example |
| 09:19 | <Hixie> | but it's not that unlikely, consider e.g. google image search |
| 09:19 | <Hixie> | or google goggles, whose input is a bitmap |
| 09:19 | <kennyluck> | Hmm... |
| 09:20 | <Hixie> | or even moving video |
| 09:20 | <kennyluck> | We are talking about outputs. |
| 09:20 | <Hixie> | or youtube's autotranscription -- input is audio, output is timed track data |
| 09:20 | <Hixie> | neither side of which is optimally represented by RDF |
| 09:21 | <Hixie> | different problems have different ideal formats |
| 09:21 | <kennyluck> | Sure. But timed track data could be serialized into RDF. |
| 09:21 | <Hixie> | sure |
| 09:21 | <Hixie> | so could a bitmap |
| 09:21 | <kennyluck> | Ofcourse, audios can not. |
| 09:21 | <Hixie> | but it's not the optimal form |
| 09:21 | <kennyluck> | Come on. |
| 09:21 | <Hixie> | and why would you use a suboptimal form? |
| 09:21 | <kennyluck> | Why do you use HTML when docx is better? |
| 09:22 | <Hixie> | i disagree with the premise of the question |
| 09:22 | <kennyluck> | Sorry. |
| 09:22 | <Hixie> | (a) that one should always use HTML, and (b) that DOCX is always better |
| 09:22 | <Hixie> | when you're writing a document in a word processor, HTML is not the ideal format, and using it would imho be a bad idea |
| 09:22 | <kennyluck> | I mean, this is what standardization is, isn't it? |
| 09:22 | <kennyluck> | Sure. |
| 09:22 | <Hixie> | what is what standardization is? |
| 09:23 | <kennyluck> | But Semantic Web is about asking people to build mashups. |
| 09:23 | <kennyluck> | Like HTML is about asking everyone in the world to view it. |
| 09:24 | <kennyluck> | If you don't want people to view it, you don't output HTML. If you don't want people to do mashup based on your data, you don't output RDF. |
| 09:24 | <Hixie> | I don't think RDF is useful for creating mashups personally |
| 09:24 | <Hixie> | and i don't know what "HTML is about asking everyone in the world to view it" means |
| 09:24 | <kennyluck> | Anyway, I welcome JSON as well. |
| 09:25 | <Hixie> | there's nothing special or useful about JSON compared to RDF |
| 09:25 | <Hixie> | they're both just formats, which may or may not be useful in any given scenario |
| 09:25 | <Hixie> | the difference is that JSON advocates don't sell JSON as the solution to humanity's woes |
| 09:25 | <kennyluck> | JSON is better than HTML for building mashups. |
| 09:25 | <Hixie> | i have no idea what that means |
| 09:26 | <Hixie> | that's like saying pears are better than shoes for drawing maps |
| 09:27 | <Smylers2> | Boots are even better if it's a map of Italy you're drawing — you could lay it flat and trace round it. |
| 09:28 | <kennyluck> | I just want to mention we benefit a lot from the fact that HTML is so universal. |
| 09:28 | <Hixie> | Smylers2: and pears are good if you're drawing a map of hungary |
| 09:28 | <Hixie> | Smylers2: since you can eat pears |
| 09:29 | <Hixie> | kennyluck: sure, but HTML is a vocabulary, not a data model |
| 09:29 | <kennyluck> | It's of course not an optimal format for lots of things. |
| 09:29 | <Hixie> | kennyluck: HTML is to XML what Foaf is to RDF |
| 09:29 | <kennyluck> | But I still write my presentation in HTML. |
| 09:29 | <Hixie> | kennyluck: Foaf has clear use cases |
| 09:29 | <Hixie> | kennyluck: just like RDF has clear use cases |
| 09:29 | <Hixie> | er |
| 09:29 | <Hixie> | kennyluck: just like HTML has clear use cases |
| 09:30 | <Hixie> | RDF and XML, however, are metaformats |
| 09:30 | <Hixie> | and alone are just tools |
| 09:30 | <Hixie> | like JSON |
| 09:30 | <Hixie> | or MySQL IASM |
| 09:31 | <Hixie> | advocating that everyone should use Foaf for the specific use cases that Foaf addresses makes a lot more sense than advocating that everyone should use RDF |
| 09:31 | <kennyluck> | Alright. |
| 09:32 | <kennyluck> | I always prefer this approach, actullay. |
| 09:32 | <kennyluck> | FOAF and then RDF. |
| 09:32 | <Hixie> | not FOAF and then RDF |
| 09:32 | <Hixie> | just FOAF |
| 09:32 | <Hixie> | that FOAF uses RDF is an implementation detail |
| 09:32 | <Hixie> | you can't generalise from "use XHTML" to "use XML" |
| 09:33 | <Hixie> | you can't generalise from "use FOAF" to "use RDF" |
| 09:33 | <kennyluck> | Probably. |
| 09:33 | <kennyluck> | Microdata also allows mixing namespaces. So it indeed meets these use cases. |
| 09:34 | <Hixie> | microdata is just another RDF serialisation |
| 09:34 | <Hixie> | (amongst other things) |
| 09:35 | <kennyluck> | Anyway, use cases are important, that I agree with you. |
| 10:46 | <phrearch> | morning |
| 10:47 | <phrearch> | i wondered if there is some sort of an agreed standard how to do routing in jsonrpc websockets? |
| 10:48 | <phrearch> | i could add uri data like /path/to/handler, but i thought there may be better ways to do this |
| 10:50 | <annevk> | jsonrpc websockets? |
| 10:50 | <annevk> | websockets is not even an agreed upon standard :) |
| 10:51 | <phrearch> | annevk: just thinking how to handle this. i like the django approach of handling urls. maybe i can use something simular for jsonrpc dispatching |
| 10:52 | <phrearch> | like calling functions like /path/to/function, and let the jsonrpc handler dispatch to the right function |
| 10:53 | <Rik`> | phrearch: http://substack.net/posts/85e1bd/DNode-Asynchronous-Remote-Method-Invocation-for-Node-js-and-the-Browser ? |
| 10:55 | <phrearch> | Rik`: thanks, ill take a look how they do things |
| 10:58 | <phrearch> | hm interesting stuff about RMI |
| 10:59 | <phrearch> | i still need some way to call a function from the server on the client |
| 11:05 | <Rik`> | isn't that what DNode provides ? |
| 11:06 | <phrearch> | sure, but i'm writing a python/twisted app |
| 11:07 | <phrearch> | i like the way they call remote functions in js |
| 11:17 | <MikeSmith> | annevk: thanks for the tweaks to the Media Queries spec |
| 11:26 | <MikeSmith> | I've been reading up on node.js |
| 11:26 | <MikeSmith> | seems like it's really turning into something very useful |
| 11:26 | <MikeSmith> | with a big and growing community around it |
| 11:27 | <Rik`> | MikeSmith: I find it very useful for my websockets demo :) |
| 11:27 | <MikeSmith> | :) |
| 11:27 | <Rik`> | (thanks to micheil btw) |
| 11:28 | <MikeSmith> | yeah |
| 11:36 | <annevk> | is ms2ger on IRC? |
| 11:36 | annevk | would like some rationale behind http://www.w3.org/Bugs/Public/show_bug.cgi?id=10164 |
| 11:41 | <MikeSmith> | I've never seen ms2ger on IRC |
| 11:41 | <MikeSmith> | not under that name at least |
| 11:41 | <MikeSmith> | the identity of ms2ger seems to be a mystery |
| 11:42 | <MikeSmith> | maybe he/she is somebody who doesn't like realtime communication so much |
| 11:56 | <annevk> | hmm, does document.domain make sense in a document created through createDocument() ? |
| 11:57 | <annevk> | there's a concept of cookie-free Document objects but maybe that should be generalized |
| 11:57 | <annevk> | now document.cookie has that concept and document.domain specifically mentions XMLHttpRequest |
| 11:57 | <annevk> | seems somewhat wrong |
| 12:28 | <oal> | How would I create a modern, simple, wysiwyg editor for a website? Is an iframe with designMode and execCommand out dated? |
| 13:15 | <kennyluck> | Oh, Ms2ger just logged off. |
| 13:44 | <annevk> | getComputedStyle defined: http://dev.w3.org/csswg/cssom/#extensions-to-the-window-interface |
| 13:45 | <annevk> | finally, took like 3 years or so |
| 13:45 | <annevk> | where "3 years" is more like a week spread out over a long time with lots of learning in between, but still |
| 13:46 | <Philip`> | "the style rules associated with d." - s/d/doc/ ? |
| 13:47 | <annevk> | hmm, I should rename in all places at once |
| 13:47 | <annevk> | thanks |
| 13:48 | <annevk> | you're not in the acknowledgment list |
| 13:48 | <annevk> | weird |
| 13:48 | <annevk> | fixed |
| 13:48 | <Philip`> | I don't remember commenting on it before |
| 13:49 | <annevk> | yeah, it's not really too weird |
| 13:49 | <annevk> | there has not been much review at all |
| 14:19 | Ms2ger | waves at annevk |
| 14:20 | <annevk> | hey man |
| 14:21 | <annevk> | I see you added a comment :) |
| 14:22 | <Ms2ger> | Yeah, I'm just too lazy to file bugs through bugzilla |
| 14:22 | <annevk> | fair enough |
| 14:23 | <annevk> | you're patching Gecko these days? |
| 14:23 | <Ms2ger> | Yes |
| 14:24 | <Ms2ger> | And a bit of testing |
| 14:25 | <annevk> | nice |
| 14:25 | <annevk> | converging is taking quite some time, but it's actually happening these days, which is a nice change |
| 14:26 | <pleb1985> | I have tried googling but I gave up after 10 minutes and thought I could ask here instead: is video+audio live upstream possible with proposed html5-related technologies? |
| 14:27 | <annevk> | with proposed technologies yes |
| 14:27 | <annevk> | but nothing is actually implemented or done with respect to that |
| 14:27 | <pleb1985> | which should I be looking at? |
| 14:28 | <annevk> | I think you want to start by reading this email: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027129.html |
| 14:28 | <pleb1985> | presumably there's lots of butthurt going on around codecs etc? |
| 14:29 | <annevk> | no discussion yet actually |
| 14:29 | <pleb1985> | i'd use more mature terminology but I'm not sure that's really necessary/appropriate |
| 14:29 | <pleb1985> | ;) |
| 14:29 | <annevk> | heh |
| 14:29 | <pleb1985> | is it likely there will be wg for that? |
| 14:29 | <annevk> | I hope we can just use VP8 but dunno |
| 14:30 | <annevk> | the other problem is network protocols |
| 14:30 | <pleb1985> | Ian is the web equivalent of neo from the matrix so wrt VP8: |
| 14:30 | <pleb1985> | I believe. |
| 14:30 | <annevk> | well, for your scenario I guess WebSocket+VP8+<device> is enough |
| 14:30 | <annevk> | so not much network protocol trouble |
| 14:31 | <annevk> | but P2P... |
| 14:31 | <pleb1985> | client server is fine :)} |
| 14:32 | <zcorpan_> | annevk: websockets does messages, not streams |
| 14:32 | <annevk> | zcorpan_, streams are just message blocks, no? |
| 14:33 | <zcorpan_> | annevk: on the network, yeah i guess, but the current api for websockets is not appropriate for sending streams |
| 14:34 | <annevk> | hmm |
| 14:34 | <annevk> | socket.send(Stream) |
| 14:34 | <annevk> | i think it'll work fine |
| 14:34 | <zcorpan_> | not with how it's currently defined :) |
| 14:35 | <annevk> | well it's not defined yet for Stream objects |
| 14:35 | <annevk> | but I'm pretty sure that is how it's going to work |
| 14:36 | <zcorpan_> | would you abort sending a stream if you invoke send() again? |
| 14:36 | <annevk> | I'm not sure it's worth to discuss the specifics now :) |
| 14:38 | <annevk> | And I suppose we could define a new API as well if that turns out to make more sense |
| 14:39 | <pleb1985> | socket's a bad name then eh? :) |
| 14:53 | <pleb1985> | annevk: i assume there's a lot of enthusiasm for <device> .. ? |
| 14:53 | <pleb1985> | well, everyone other than the flash camp ;) |
| 14:55 | <annevk> | pleb1985, people certainly want a feature like that, yes |
| 14:55 | <pleb1985> | .. and the UA guys? |
| 14:56 | <annevk> | I think we do too, but there's plenty of other stuff that requires attention too |
| 14:56 | <pleb1985> | for sure, I think you'll get more mileage from that than web sockets |
| 14:57 | <annevk> | I guess there are some uses for just having camera input and no dedicated network integration, but you really want network integration for most use cases |
| 14:58 | <pleb1985> | mmm, what sort of timescales would you expect on something like that? |
| 14:58 | <pleb1985> | year? |
| 14:59 | <annevk> | dunno really |
| 14:59 | <pleb1985> | fair enough :) |
| 15:00 | <annevk> | if we had a few implementors and a set of people hashing out the network protocol that would be likely, but so far there's not much of that |
| 15:05 | <pleb1985> | implementors on the server side? |
| 15:06 | <pleb1985> | or you mean UA side and by 'we' you mean whatwg |
| 15:06 | <pleb1985> | it's confusing. ;) |
| 15:11 | <annevk> | on the user agent side |
| 15:12 | <pleb1985> | fwiw, I'd like to see something happen there :) |
| 15:14 | <foolip> | I'm not sure I understand why <device> needs to be an element, is it expected to have any rendering or do anything useful without scripts involved? |
| 15:15 | <pleb1985> | I guess to ease detection ? |
| 15:16 | <foolip> | detection of what, by whom? |
| 15:16 | <pleb1985> | of the requirement for device connectivity |
| 15:16 | <pleb1985> | to the user |
| 15:17 | <annevk> | foolip, see the email |
| 15:17 | <foolip> | annevk, I read the email, after which I asked myself above question |
| 15:17 | <annevk> | foolip, Ian thinks this way you can design the best "interactive UI" |
| 15:17 | <pleb1985> | foolip: you're saying you would sink that type of GUI into the browser instead, similar to http auth? |
| 15:18 | <annevk> | foolip, i.e. that the user actually knows what he just did |
| 15:18 | <jgraham> | foolip: I thought the idea was to have some UI for accessing the device associated with the element |
| 15:18 | <foolip> | ok, so browser-specific (probably ugly) rendering of <device> ? |
| 15:18 | <annevk> | foolip, yes, like <input type=file> |
| 15:18 | <jgraham> | foolip: Something like input type="file" |
| 15:19 | <jgraham> | Well at least our story is consistent :) |
| 15:19 | <annevk> | where is this mercurial w3c thing? |
| 15:19 | <annevk> | plh wants me to create a XHR placeholder file |
| 15:20 | <annevk> | I wonder if I have an account there |
| 15:20 | <annevk> | if not this sounds like way too much work |
| 15:20 | <foolip> | If one is going to do video conferencing then surely one doesn't want an unstylable chunk of <device> ruining the design? |
| 15:20 | <foolip> | of course <input type=file> has the same problem |
| 15:20 | <annevk> | an infobar too |
| 15:20 | <annevk> | doesn't seem like such a big deal |
| 15:22 | <MikeSmith> | list of w3c mercurial repos is here: |
| 15:22 | <MikeSmith> | http://dvcs.w3.org/hg |
| 15:22 | <MikeSmith> | push access is by normal w3c username+password |
| 15:23 | <MikeSmith> | auth on that is per-WG, done by checking the w3c user groups db |
| 15:23 | <annevk> | oh |
| 15:23 | annevk | tried dcvs :) |
| 15:24 | <annevk> | now I have to learn hg |
| 15:24 | <annevk> | crap |
| 15:24 | <annevk> | quite a bit of make work imo |
| 15:24 | <jgraham> | http://hginit.com/ |
| 15:25 | <jgraham> | It is _so_much_ better than CVS |
| 15:25 | annevk | installs mercurial |
| 15:25 | <Philip`> | jgraham: You could say that about pretty much anything |
| 15:25 | <jgraham> | Well worth it as soon as you have even the barest glimmer of understanding |
| 15:25 | <annevk> | I only use CVS as changelog |
| 15:25 | <jgraham> | Philip`: I do :) |
| 15:25 | <annevk> | and offsite storage facility |
| 15:26 | <MikeSmith> | here's the tutorial: hg clone, .. make changes.., hg commit, hg push ... then hg pull, .. make changes.. repeat |
| 15:26 | <MikeSmith> | oh, with some hg merge thrown in |
| 15:26 | <Philip`> | Unless someone else changes the repository, then you need to pull and up and merge if you already committed? |
| 15:27 | <jgraham> | It is pretty good about telling you what you need to do |
| 15:27 | <jgraham> | It might just take a while to get the mental model |
| 15:27 | <MikeSmith> | Philip`: no, not if nobody's changed anything |
| 15:27 | <annevk> | oh god |
| 15:27 | <jgraham> | annevk: What's the problem |
| 15:28 | <annevk> | complexity |
| 15:28 | <annevk> | so I created w3c-hg, I run hg-init in there? |
| 15:28 | <jgraham> | It's not that bad |
| 15:28 | <annevk> | euh, without the dash? |
| 15:28 | <jgraham> | You are cloning an existing repository |
| 15:28 | <jgraham> | You just run hg clone http://url/of/repo |
| 15:29 | <jgraham> | hg init is only needed to create one from scratch |
| 15:29 | <annevk> | so within w3c-hg I run hg clone http://dvcs.w3.org/hg/webapps/ ? |
| 15:29 | <annevk> | or should I create a folder webapps first? |
| 15:29 | <annevk> | I guess I should |
| 15:29 | <jgraham> | No need to create the folder first |
| 15:29 | <annevk> | ok |
| 15:30 | <annevk> | how do I add a folder via hg? |
| 15:30 | <jgraham> | Just do hg clone |
| 15:30 | <MikeSmith> | annevk: you can't create top-level folders |
| 15:30 | <jgraham> | You mean add a folder to the repository? |
| 15:30 | <annevk> | yes |
| 15:30 | <MikeSmith> | we have to ask systems team to add one |
| 15:30 | <annevk> | MikeSmith, inside webapps |
| 15:30 | <jgraham> | MikeSmith: Really? |
| 15:30 | <MikeSmith> | annevk: oh |
| 15:31 | <jgraham> | annevk: Just create a folder and do hg add /path/to/folder |
| 15:31 | <MikeSmith> | didn't knwo PLH had added that |
| 15:31 | <MikeSmith> | jgraham: can't create them there at least |
| 15:31 | <MikeSmith> | but any webapps WG member can create within the webapps folder |
| 15:31 | <Philip`> | Or just hg add /path/to/folder/file and it'll automatically add the folder if needed |
| 15:31 | <jgraham> | MikeSmith: That's creating whole repositories isn't it? |
| 15:32 | <MikeSmith> | jgraham: yeah |
| 15:32 | <jgraham> | MikeSmith: Right, I would imagine that is harder :) |
| 15:33 | <variable> | http://hginit.com/ --> a decent hg tutorial |
| 15:34 | <annevk> | I did hg commit but hg push doesn't work |
| 15:34 | <annevk> | method not allowed |
| 15:35 | <Philip`> | Has it asked for a username/password yet? |
| 15:35 | <annevk> | at one point during commit and I provided my W3C username |
| 15:35 | <annevk> | didn't ask for anything since |
| 15:35 | <annevk> | password it might pull out of .ssh? |
| 15:35 | <jgraham> | Commit shouldn't have asked for username |
| 15:35 | <annevk> | just like it does for CVS? |
| 15:36 | <jgraham> | Since it only changes things in your local repository |
| 15:36 | <annevk> | well, it did the first time |
| 15:36 | <Philip`> | I've got it set up with ~/.hgrc containing: |
| 15:36 | <Philip`> | [auth] |
| 15:36 | <Philip`> | w3c.prefix = dvcs.w3.org/hg/ |
| 15:36 | <Philip`> | w3c.username = blahblah |
| 15:36 | <Philip`> | w3c.password = blahblah |
| 15:36 | <jgraham> | That is very surprising, no? |
| 15:36 | <MikeSmith> | annevk: it doesn't use ssh at all |
| 15:36 | <annevk> | i have no idea |
| 15:36 | <annevk> | i don't know how this works |
| 15:37 | <annevk> | but i'm learning slowly |
| 15:37 | <jgraham> | annevk: You have a copy of the whole repository and all the history locally |
| 15:37 | <jgraham> | Making a checkin changes your local copy of the repository |
| 15:38 | <annevk> | sure sure |
| 15:38 | <annevk> | i'm just saying what happened |
| 15:38 | <jgraham> | Later you push the changes to the remote |
| 15:39 | <annevk> | Philip`, added that file, still failing in the same way |
| 15:40 | <Philip`> | It might be that you need the https:// URL |
| 15:40 | <Philip`> | rather than http:// |
| 15:41 | <annevk> | hmm |
| 15:41 | <Philip`> | You can just edit .hg/hgrc in the checkout directory |
| 15:41 | <Philip`> | (I think) |
| 15:41 | <Philip`> | to change to https |
| 15:41 | <jgraham> | You can |
| 15:42 | <Philip`> | (Unlike SVN, which needs some crazy --relocate thing that rewrites your whole working copy) |
| 15:42 | <annevk> | it asks for username again... |
| 15:43 | <annevk> | (I started over) |
| 15:43 | <annevk> | but now it worked |
| 15:43 | <annevk> | is there a version where all this is checked out? |
| 15:44 | <annevk> | hg serve? |
| 15:44 | annevk | finds http://test.w3.org/webapps/ |
| 15:44 | <MikeSmith> | http://dvcs.w3.org/hg/webapps/file/eda29ce012e3/XMLHttpRequest/ |
| 15:44 | <MikeSmith> | http://dvcs.w3.org/hg/webapps/raw-file/eda29ce012e3/XMLHttpRequest/info.htm |
| 15:45 | <annevk> | but that's a static link no? |
| 15:45 | <annevk> | where's the latest version? |
| 15:45 | <Philip`> | http://dvcs.w3.org/hg/webapps/file/tip/XMLHttpRequest/ if you want the latest |
| 15:45 | <annevk> | so what's test.w3.org/webapps/ ? |
| 15:46 | <annevk> | so http://dvcs.w3.org/hg/webapps/raw-file/tip/XMLHttpRequest/info.htm |
| 15:46 | <annevk> | hmm |
| 15:48 | <annevk> | how do you move files? |
| 15:48 | <Philip`> | hg mv |
| 15:51 | <annevk> | god it requests my username for each commit |
| 15:51 | <annevk> | but not for hg push |
| 15:51 | <annevk> | silly as hell |
| 15:55 | <Philip`> | You probably want to edit ~/.hgrc again, to say |
| 15:55 | <Philip`> | [ui] |
| 15:55 | <Philip`> | username = Blah Blah <blah⊙bb> |
| 15:55 | <Philip`> | so it knows what name to give you in the commit logs |
| 15:56 | <annevk> | can be a different username? |
| 15:56 | annevk | tries |
| 15:56 | <Philip`> | It can be anything |
| 15:56 | <Philip`> | I don't know if it has to be an email address but that seems conventional |
| 15:57 | <annevk> | you win the interwebs |
| 15:57 | <annevk> | i did annevk <annevk⊙oc> |
| 15:58 | <Philip`> | You can put other people's names in commits to your local repository, and when you push to the W3C repository it'll just trust the commits that you're pushing |
| 15:59 | Philip` | doesn't know whether there's anywhere that records who actually pushed a change |
| 17:18 | <oal> | I asked this earlier, but I didn't get any response: If I want to make a simple wysiwyg/rich editor with html5-ish technology, where should I start? Are iframes and execCommand out dated? |
| 17:36 | <boblet> | oal: things should pick up in ~4 hours, maybe try asking again in a bit |
| 17:37 | <oal> | boblet, ok thank you :) |
| 17:37 | <oal> | At least it was a reply ;) |
| 17:37 | <boblet> | sorry I can’t help |
| 17:37 | <boblet> | heh |
| 17:41 | <AryehGregor> | oal, I'm not an expert, but contenteditable, designMode, execCommand, this is what you should be looking at, yes. |
| 17:42 | <AryehGregor> | (you can do much more complicated stuff using canvas, but you'd have to implement it all from scratch; this is what Bespin does) |
| 17:42 | <AryehGregor> | Hah, Google thinks the contents of Bespin's website is "Loading...": http://www.google.com/search?q=bespin |
| 17:42 | <AryehGregor> | That's what you get for not having fallback. |
| 17:42 | <oal> | AryehGregor, I've been experimenting with a div+contenteditable, but I'm unable to get selecting/applying effects correctly |
| 17:43 | <AryehGregor> | I don't know how interoperably implemented all this stuff is in practice. |
| 17:43 | <AryehGregor> | I do know that it's what people generally use for this. |
| 17:43 | <AryehGregor> | If you had a specific question, maybe you could ask that, someone might know the answer. |
| 17:44 | <Philip`> | oal: Why do you not want to reuse one of the existing WYSIWYG HTML editors? |
| 17:45 | <oal> | Philip`, because I need something that can "float" on an existing page, not with static, locked toolbars etc |
| 17:46 | <oal> | And I don't need all the features of CKeditor and the "big" ones |
| 18:03 | <oal> | Should I use <strong> or <b> in html5? |
| 18:04 | <Philip`> | Depends on the semantics of your content |
| 18:05 | <oal> | Philip`, in which ways? |
| 18:05 | <Philip`> | They mean different things, as defined by the spec |
| 18:05 | <oal> | Ok, I'll look it up |
| 18:15 | <boblet> | oal: http://html5doctor.com/i-b-em-strong-element |
| 18:16 | <boblet> | Philip`: “Why do you not want to reuse one of the existing WYSIWYG HTML editors?” because they’re all unmitigated shite? |
| 18:16 | <blue_oak> | Does anyone know why the string to number and number to string conversion algorithms are written as they are when the input element is in the Date and time state? |
| 18:16 | <boblet> | well partially mitigated by trying to support older browsers |
| 18:17 | <boblet> | but anything using Word as a UI metaphor to emulate should be put down (mercy killing) |
| 18:17 | <oal> | boblet, thanks. :) |
| 18:17 | <boblet> | oal: heh, np. always easy to recommend your own stuff ;-) |
| 18:18 | <oal> | bobchao, is that your site? |
| 18:18 | <bobchao> | oal: boblet I think? :) |
| 18:18 | <boblet> | oal: I’m one of the authors yep |
| 18:18 | <boblet> | bobchao: namespace collision! |
| 18:18 | <oal> | bobchao, sorry mate. Tab doesn't always react the way I want :P |
| 18:19 | <TabAtkins> | xmlns=http://www.example.com/names#bob |
| 18:19 | <bobchao> | boblet: true, haha actually this is the second time :P |
| 18:19 | <oal> | boblet, looks like a good source for html5 stuff. thank you |
| 18:19 | <boblet> | heh. I have the same problem with mike][inq and MikeSmith |
| 18:20 | <boblet> | oal: it’s a superlative resource! and I don’t only say that because some of the articles are mine ;-) |
| 18:20 | <boblet> | honest! |
| 18:20 | <oal> | Yes, I'll definitely use it again :) |
| 18:24 | <boblet> | oal:if you can make something that’s not |
| 18:24 | <boblet> | woops |
| 18:24 | <oal> | Wrong channel? |
| 18:25 | <boblet> | oal: if you can make something that outputs decent code and doesn’t look as ugly as a MS product, I’ll use it too |
| 18:25 | <boblet> | fat-fingered |
| 18:26 | <oal> | If I only knew how I should solve all the issues I stumble upon, I might get a decent result, but now things are going sloow... |
| 18:27 | <boblet> | oal: hopefully you’ll choose to only support modern browsers, as I’m sure the millstone of ahem older ones doesn’t help current projects any |
| 18:28 | <boblet> | oal: one I liked was wmd http://wmd-editor.com/ |
| 18:28 | <oal> | boblet, definitely will focus most on newer browsers |
| 18:29 | <boblet> | oal: regardless I think you’ll need lots of luck (it’d be a touch project) so good luck! |
| 18:29 | <boblet> | :) |
| 18:29 | <oal> | I know. If I get things going, the goal is to make a simple editor, not anything fancy |
| 18:34 | <dandaman> | im trying to set a thing border that will surround my content on my site automatically(so it will depend on the viewer's resolution) is there a way to do that? |
| 18:34 | <dandaman> | <body style="border:thin solid #003366;width: 150px"> |
| 18:34 | <dandaman> | kinda like that |
| 18:34 | <dandaman> | except the width not being set |
| 18:35 | <TabAtkins> | body { border: thin solid #036; margin: 0 20px; } ? |
| 18:35 | <dandaman> | in css |
| 18:35 | <dandaman> | ? |
| 18:35 | <TabAtkins> | Yes. It's all CSS. |
| 18:36 | <dandaman> | it doesnt hug it perfectly |
| 18:36 | <dandaman> | but oh well, it works |
| 18:36 | <TabAtkins> | I dunno quite what you're exactly asking for. |
| 18:37 | <dandaman> | well im doing this for a mobile app |
| 18:37 | <dandaman> | so the screen size makes it work |
| 18:37 | <dandaman> | thanks |
| 18:37 | <TabAtkins> | O...k? |
| 18:38 | <AryehGregor> | Why margin: 0 2px; instead of margin: 0;? |
| 18:39 | <TabAtkins> | I had no idea what he was asking for, so I went with some margins. |
| 18:39 | <TabAtkins> | If he just wanted a literal border on the edges, then yeah, margin:0;. |
| 18:40 | <dandaman> | on the edges of the text |
| 18:40 | <dandaman> | not on the edges of the browser |
| 18:40 | <TabAtkins> | Oh, you want it to wrap whatever you've got? |
| 18:40 | <TabAtkins> | Then margin:0 auto; |
| 18:43 | <dandaman> | thanks |
| 18:44 | <dandaman> | auto did not work :\ |
| 18:44 | <TabAtkins> | No, it works. You may be doing something preventing it from working. |
| 18:44 | <TabAtkins> | Can you provide a live site and a description of what precisely you're looking for? |
| 18:46 | <dandaman> | let me try.... |
| 18:46 | <dandaman> | http://www.w3.org/TR/REC-CSS1/ |
| 18:46 | <dandaman> | i guess see how the note is being bordered |
| 18:46 | <dandaman> | by that red |
| 18:46 | <TabAtkins> | (Also, for future reference, #css is a better channel for these sorts of things.) |
| 18:46 | <dandaman> | i want basically that |
| 18:46 | <dandaman> | except a border all over everything |
| 18:46 | <dandaman> | that fits snugly |
| 18:46 | <dandaman> | currently i have all my text centered |
| 18:46 | <dandaman> | and the border reaches accross the entire screen |
| 18:47 | <TabAtkins> | Yes. |
| 18:47 | <dandaman> | which i dont want |
| 18:47 | <dandaman> | i want it only close to the text |
| 18:47 | <TabAtkins> | Set display:table-cell on the body as well. |
| 18:48 | <TabAtkins> | Or rather, display:table, since you still want the margin:0 auto; to apply. |
| 18:48 | <dandaman> | AWESOME |
| 18:48 | <dandaman> | THANKS |
| 18:48 | <dandaman> | sorry caps |
| 18:48 | <dandaman> | but you win |
| 18:48 | <TabAtkins> | (Eventually you'll be able to use width:fit-content;, but for now you can only do it in FF with width:-moz-fit-content;.) |
| 18:49 | <TabAtkins> | Note: won't work on IE7 or earlier. |
| 18:50 | <dandaman> | hmm, is there a way to have a different background color within the border and a different bg color outside of the border? |
| 18:50 | <TabAtkins> | Set one background on <body>, and one on <html>. |
| 18:51 | <dandaman> | good call |
| 18:56 | <dandaman> | when i go <html background="#FFFFFF"> it doesnt work, the body style= background takes over the whole page and <html style= "background: #FFFFFF"> makes the page go blank (and when i hit view source there is nothing there) |
| 18:56 | <dandaman> | I am using grails to run the server btw |
| 18:56 | <dandaman> | dunno if that makes a difference |
| 18:57 | <TabAtkins> | Oh, right, sorry. The <body>'s background is hoisted to the entire viewport, so that won't work. |
| 18:57 | <TabAtkins> | In that case, you'll have to create a wrapper, move your current body styling to it, then set the "back" background on <body>. |
| 18:58 | <TabAtkins> | Well, hum. Actually, setting backgrounds on <html> and <body> work fine for me in Chrome. |
| 18:58 | <dandaman> | just throw a <div> around everything? |
| 18:58 | <TabAtkins> | Worst case, yeah. |
| 18:58 | <dandaman> | yeah im doing this on chrome |
| 18:59 | <TabAtkins> | Hmm, then. If I explicitly set a background through <html @style> and <body @style>, they both take effect exactly as expected. |
| 18:59 | <dandaman> | div worked |
| 19:00 | <dandaman> | might just be grails |
| 19:00 | <TabAtkins> | That would be... bizarre. A server-side framework shouldn't have any effect on how client-side CSS works, unless it's inserting additional CSS without you knowing. |
| 19:01 | <TabAtkins> | And when I say "shouldn't" I mean "actually can't, because it's physically impossible". |
| 19:01 | <AryehGregor> | My website sets separate backgrounds on <html> and <body>. |
| 19:02 | <TabAtkins> | Yeah, I'd messed up. <body>'s background gets hoisted to the viewport *if* <html> doesn't have a background. |
| 19:16 | TabAtkins | just typed </meh> instead of </em>. |
| 19:16 | <TabAtkins> | I think that's the exact opposite semantic. |
| 19:18 | <Workshiva> | </meh> could complement </sarcasm> |
| 19:43 | boblet | is <meh> |
| 19:43 | <boblet> | nn all |
| 19:48 | <hsivonen> | gsnedders: I saw Avenue Q. It was fun, but it didn't quite live up to the expectations (the best songs were before the intermission and it kinda flattened out from there) |
| 20:48 | <hober> | anyone going to oscon this year? |
| 21:01 | <zcorpan_> | Hixie: r5162, i think it also affected <option> |
| 21:32 | <AryehGregor> | Blast Opera's nonsensical treatment of # in data URLs. |
| 21:40 | <zcorpan_> | not supporting fragments in data urls is what's nonsensical |
| 21:41 | <cardona507> | saying Opera Mini loads quicker than the stock android browser is whats nonsensical. :P |
| 21:42 | <AryehGregor> | zcorpan_, I have so far had documents in data URLs randomly break several times in Opera and Opera only because of its fragment treatment. I have never wanted to actually use a fragment in a data URI that I can recall. |
| 21:44 | <AryehGregor> | Okay, I just tried drawing shadows with canvas, and got three significantly different results in three different browsers. |
| 21:44 | <AryehGregor> | I have no idea who's actually right, or if the spec is just vague. |
| 21:45 | <AryehGregor> | It doesn't look vague to me, unless Gaussian blurs aren't well-defined. |
| 21:45 | <cardona507> | different results in different browser?! I am shocked :) |
| 21:45 | <TabAtkins> | The spec for <canvas>'s shadows is basically just "whatever Safari did", so it should be fine. |
| 21:45 | <cardona507> | *browsers |
| 21:45 | <AryehGregor> | TabAtkins, http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#shadows |
| 21:46 | <AryehGregor> | <!doctype html> <canvas height="300" width="300"></canvas> <script> window.addEventListener('load', function () { context = document.getElementsByTagName("canvas")[0].getContext("2d"); context.shadowBlur = 50; context.shadowColor = 'black'; context.fillRect(100, 100, 100, 100); }, false); </script> |
| 21:46 | <TabAtkins> | AryehGregor: No, that's well-defined. Any problem with it is a browser bug. |
| 21:46 | <AryehGregor> | In which browser, and how do I tell? |
| 21:46 | <AryehGregor> | I'm guessing they implemented this feature before it was specced. |
| 21:46 | <arosenberg> | I'll retry posting my thought from the other day. |
| 21:47 | <TabAtkins> | Calculate the gaussian matrix yourself from the appropriate stdev, run it manually, then diff against the browser? |
| 21:47 | <AryehGregor> | IIRC, the algorithm follows WebKit, so maybe I should assume everyone but them is wrong. |
| 21:47 | <TabAtkins> | That's probably correct. |
| 21:47 | <arosenberg> | There seems to be no way to get the response code or headers from an injected script tag. |
| 21:48 | <AryehGregor> | The treatment of the blur parameter is at least slightly insane. Maybe it should be cleaned up in the spec, since clearly there's no interop here anyway. |
| 21:48 | <arosenberg> | And yet the twitter API returns results in the headers with a 400 response for rate limiting. |
| 21:48 | <TabAtkins> | It is immensely insane, in fact. |
| 21:48 | <arosenberg> | XHR has provisions for this info, and I think it should be addressed for script tags as well. |
| 21:49 | <arosenberg> | (BTW, I'm thrilled that onerror now gets called for a script tag.) |
| 21:49 | <TabAtkins> | AryehGregor: Since we're discussing what precisely a "blur value" means in CSS right now (since every single browser treats it differently), it should sync up with whatever we decide for that. |
| 21:49 | <AryehGregor> | TabAtkins, this is in the context of a post I was making there. |
| 21:49 | <AryehGregor> | (Violently disagreeing with you, as it happens.) |
| 21:49 | <TabAtkins> | Ah, haven't read the thread yet today. |
| 21:49 | <TabAtkins> | I'm saving it for last. |
| 21:50 | <AryehGregor> | arosenberg, try posting to the whatwg list, it's a better way to get a response. |
| 21:50 | <zcorpan_> | arosenberg: xhr has same-origin policy, script doesn't |
| 21:51 | <TabAtkins> | AryehGregor: Ah, you haven't actually sent the post yet. |
| 21:51 | <AryehGregor> | No. |
| 21:51 | <zcorpan_> | arosenberg: so being able to read headers from arbitrary sources cross-origin would be a new security problem |
| 21:52 | <zcorpan_> | arosenberg: i guess it could be exposed for same-origin only, but what's the use case? |
| 21:52 | <Philip`> | AryehGregor: It doesn't follow WebKit, it follows CoreGraphics |
| 21:53 | <Philip`> | i.e. what Safari does |
| 21:53 | <Philip`> | not (necessarily) any other WebKit ports |
| 21:53 | <AryehGregor> | Oh, I see. |
| 21:53 | <AryehGregor> | So Chrome won't match WebKit here. |
| 21:53 | <AryehGregor> | Er. |
| 21:53 | <TabAtkins> | Mac/Safari, to be precise. |
| 21:53 | <AryehGregor> | Won't match Safari |
| 21:53 | <AryehGregor> | . |
| 21:53 | <Philip`> | since WebKit just defers to the graphics layer for almost all of this |
| 21:53 | <Philip`> | TabAtkins: Win/Safari too, since that uses CG |
| 21:53 | <TabAtkins> | Oh, CG is one Win too? |
| 21:53 | TabAtkins | knows nothing. |
| 21:54 | <TabAtkins> | AryehGregor: What's the gist of your violent disagreement? |
| 21:54 | <AryehGregor> | TabAtkins, the spec should say something pixel-perfect even if that means it's author-incomprehensible. Authors can figure out what values they like quickly by trial and error. |
| 21:55 | <AryehGregor> | They have to do that anyway, reading the spec won't tell them by itself. |
| 21:55 | <AryehGregor> | (even if it gives a general idea of how much blur to expect) |
| 21:57 | <TabAtkins> | AryehGregor: I am *potentially* okay with pixel-perfect spec descriptions. What I'm *not* okay with is the actual component value provided by the author being an opaque number, when we can just as easily make it sensical. |
| 21:57 | <AryehGregor> | If anyone has the latest IE9 handy, I'd be interested to hear what that canvas looks like. |
| 21:58 | <AryehGregor> | Does it match the SVG here? http://www.w3.org/Bugs/Public/show_bug.cgi?id=10169#c1 |
| 21:58 | <Philip`> | http://test.w3.org/html/tests/submission/PhilipTaylor/canvas/index.2d.shadow.blur.html |
| 21:58 | <Philip`> | Opera (on Linux) looks correct, I assume Safari is still correct, Firefox (3.6 on Linux) looks all wrong |
| 21:59 | <AryehGregor> | On Linux, Opera looks correct on both, Chrome looks wrong on both, Firefox 4 looks wrong on small blurs but okay on big blurs. |
| 21:59 | <AryehGregor> | Actually, it looks wrong on big blurs too, but not so drastically. |
| 21:59 | <AryehGregor> | What does IE9 look like? I'm betting it's correct. |
| 22:00 | <arosenberg> | zcorpan_: I haven't carefully considered the security implications, but I don't see the differences between a script tag's arbitrary source ability and the headers from same. |
| 22:00 | <Philip`> | (Search for "sigma" in http://test.w3.org/html/tests/submission/PhilipTaylor/tools/canvas/tests2d.yaml which is how the bottom images in my tests are generated) |
| 22:00 | <Philip`> | (which hopefully matches the spec's requirement) |
| 22:02 | <AryehGregor> | Philip`, do you think my markup in these two cases is supposed to display the same? http://www.w3.org/Bugs/Public/show_bug.cgi?id=10169#c1 |
| 22:02 | <AryehGregor> | As far as I can tell, it's supposed to be a 100x100px black box offset 100x100px with five sigmas of blur in both cases. |
| 22:02 | <AryehGregor> | Hmm, no, I miscalculated for canvas? |
| 22:02 | <AryehGregor> | sqrt(100) = 10, not 5. |
| 22:02 | AryehGregor | tries again |
| 22:02 | <Hixie> | zcorpan_: how? |
| 22:04 | <zcorpan_> | Hixie: <body><option></option> |
| 22:04 | <Philip`> | AryehGregor: The canvas one is a solid box on top of a blurred box, the SVG one looks like simply a blurred box |
| 22:04 | <Hixie> | oh right because we made </option> not so special after all |
| 22:04 | <Hixie> | hmm |
| 22:04 | <Hixie> | damn |
| 22:04 | <Hixie> | i shouldn't have put it in the list of special tags then |
| 22:04 | <AryehGregor> | Hmm. |
| 22:04 | <Philip`> | (where by "looks" I mean from the source code, not the rendering) |
| 22:05 | <Philip`> | You could draw the canvas's box at x=-200 with shadowOffsetX=200 |
| 22:05 | <Philip`> | Uh, 300 |
| 22:05 | <Philip`> | or whatever |
| 22:05 | <Philip`> | to get just the shadow rendered |
| 22:06 | <AryehGregor> | Hmm, good idea. |
| 22:06 | <Hixie> | i would really appreciate it if someone could check http://html5.org/tools/web-apps-tracker?from=5163&to=5164 with a fine tooth comb to make sure i didn't screw up anything |
| 22:07 | <AryehGregor> | Philip`, nice, that works perfectly. Thanks! |
| 22:08 | <AryehGregor> | Pixel-perfect. |
| 22:13 | <AryehGregor> | Should I file a bug against Firefox? |
| 22:13 | AryehGregor | doesn't see an existing one, unless it's: https://bugzilla.mozilla.org/show_bug.cgi?id=478459 |
| 22:15 | <eseidel> | Hixie: you are a machine |
| 22:15 | <eseidel> | zomg it's a hsivonen! |
| 22:16 | <eseidel> | hsivonen: and here I thought you were avoiding me :p |
| 22:16 | <annevk> | oh god |
| 22:16 | <annevk> | tyler close wtf |
| 22:16 | <annevk> | guess it's time for bed |
| 22:17 | <annevk> | eseidel, lol |
| 22:17 | <eseidel> | nah, hsivonen is still avoiding me :p |
| 22:19 | <Hixie> | eseidel: once i get started on bugs i can crank through them easily yeah :-) |
| 22:20 | <Hixie> | eseidel: check out my downhill gradients on http://www.whatwg.org/issues/data.html :-) |
| 22:20 | <Hixie> | (blue line is bugs) |
| 22:22 | <Philip`> | AryehGregor: Filing bugs is good :-) |
| 22:22 | <Philip`> | AryehGregor: unless you want browsers to converge on a behaviour that's different to what's currently specced |
| 22:23 | <AryehGregor> | Philip`, I already filed an HTML5 bug for that. :) |
| 22:24 | <eseidel> | Hixie: I was just commenting to abarth that it would be nice if there was a version of the spec which showed diffs since a revision/date. I'm curious if such exists already? Basically I want a version of the spec with red/green in it to show me what has changed since I implemented it (i.e. at a specific date or revision). |
| 22:24 | <eseidel> | a diff sorta gives me that, but I want full context of the spec |
| 22:24 | <eseidel> | I'm sure I could generate such a thing myself from svn, but perhaps it already exists? |
| 22:28 | <Hixie> | eseidel: the spec is >5 MB, I'm not aware of any HTML diffing tool that can handle it |
| 22:28 | <eseidel> | ha |
| 22:28 | <Hixie> | eseidel: the tracker page lets you see diffs in the source between two arbitrary revisions, though |
| 22:29 | <zcorpan_> | you could generate an html diff for the a multipage page |
| 22:29 | <zcorpan_> | s/the// |
| 22:31 | <Hixie> | i think it would be really cool if someone could make a version of the spec that let you see diffs between versions and let you see inline blame annotations for everything so you could navigate the spec's history and changes |
| 22:31 | <Hixie> | but i'm not gonna do it myself :-) |
| 22:32 | <variable> | Hixie, the spec is stored via svn? |
| 22:32 | <annevk> | yeah, svn.whatwg.org/webapps/source |
| 22:32 | <Hixie> | what anne said |
| 22:32 | <variable> | then I know there is already a program that does that |
| 22:32 | <variable> | svn has a native command line version and I know I've seen a web version |
| 22:33 | <variable> | right - WebSVN |
| 22:37 | <Slaanesh> | Man, chrome is such a pain... clearing the location bar after each javascript command |
| 22:38 | <zcorpan_> | Slaanesh: yeah, what's up with that |
| 22:38 | <Slaanesh> | Let's blame Hixie |
| 22:39 | <TabAtkins> | Slaanesh: Hit F12, then Esc if the console isn't up yet. |
| 22:39 | <Hixie> | variable: i meant some sort of dynamic "web 2.0" "ajax" app version of the spec, not the spec source, but websvn would certainly be a step in the right direction |
| 22:40 | <zcorpan_> | s/"web 2.0" "ajax"/html5/ |
| 22:40 | <Slaanesh> | TabAtkins: I assume you're trying to enable the jsconsole, but that doesn't work here, since it has superpermissions |
| 22:41 | TabAtkins | didn't realize that permissions mattered in any way here. |
| 22:41 | <variable> | I always "web 2.0" to mean "user content" |
| 22:41 | <variable> | Hixie, what particular features did you want fancy animations when the user clicks "diff"? |
| 22:42 | <Slaanesh> | Well, F12 also doesn't open it :P |
| 22:42 | <Hixie> | i meant something where you would be reading the spec and as you hovered over the spec it would highlight each fragment that had been updated, and in the margin would just the most recent revision that had that change, or something, and you could click on it to switch to that revision, or to see the diff, or something |
| 22:42 | <Slaanesh> | shift-ctrl-j, apparently |
| 22:42 | <Hixie> | i really have no concrete idea here :-) |
| 22:42 | <eseidel> | Hixie: it seems minefield and webkit both blindly coalesce text into the previous node, ignoring the "if it was the last node inserted by the parser" check for character token insertion |
| 22:42 | <eseidel> | example: <table>A<td>B</td>C</table> |
| 22:42 | <eseidel> | the spec says that should be two separate notes "A" and "B" |
| 22:42 | <variable> | Hixie, ah, like built into the current spec with the fancy commenting and such |
| 22:43 | <eseidel> | both minefield and WK make "AC" |
| 22:43 | <eseidel> | sorry "A" and "C" not "A" and "B" |
| 22:44 | <Hixie> | variable: yeah something |
| 22:45 | <eseidel> | Hixie: I'm attempting to test IE now. |
| 22:45 | <Hixie> | eseidel: you mean with hsivonen's parser or the old one? |
| 22:45 | <eseidel> | minefield, so new parser |
| 22:46 | <Hixie> | eseidel: i seem to recall there were pretty important performance reasons for not doing that, but ok |
| 22:46 | eseidel | wonders if there is a version of live dom viewer or plexode which works in IE |
| 22:47 | <eseidel> | hmm, maybe |
| 22:50 | <Hixie> | e.g. it lets you reuse your buffers in your parser without having to worry about being compatible with the buffers your CreateTextNode() implementation uses |
| 22:50 | <Hixie> | and it means you only have to have one "active" buffer at a time |
| 22:51 | <Hixie> | so you don't run the risk of having to increase the length of your buffer and finding that you can't just allocate more RAM, you have to move the entire buffer around first |
| 22:52 | <eseidel> | Hixie: I'm not sure I understand |
| 22:52 | <Hixie> | which bit? |
| 22:52 | <eseidel> | once you've create a text node, it can't be using parser buffers |
| 22:52 | <eseidel> | you might have to make the text node's buffers bigger if you append to it, yes. |
| 22:53 | <eseidel> | Hixie: I mena, there are some nice things about the way the spec is worded. prevnets strange things when scripts start inserting text nodes |
| 22:53 | <eseidel> | it won't be hard to implement |
| 22:53 | <eseidel> | Hixie: just noting that both WK and minefield fail that example atm |
| 22:53 | <eseidel> | Hixie: but I'm not against implementing it that way |
| 22:53 | <Hixie> | ah ok |
| 22:53 | <Hixie> | i misunderstood, sorry :-) |
| 22:54 | <Hixie> | usually when people tell me the browsers don't match the spec it's a passive aggressive way of telling me the spec is wrong :-) |
| 22:54 | <abarth> | svn.whatwg.org is slow... |
| 22:55 | <abarth> | soon i will have my own clone of the HTML5 repo and there will be no stopping me :) |
| 22:58 | <Hixie> | who is eric⊙wo? is that eseidel? |
| 23:00 | <jgraham> | I thought hsivonen was one of the people asking for the multiple-test-nodes thing before |
| 23:00 | <jgraham> | But I could be wrong. I recall having a conversation with Philip` about it |
| 23:00 | <abarth> | Hixie: yes |
| 23:00 | <eseidel> | Hixie: there can be only one! |
| 23:01 | <abarth> | we're looking at the details of text node coalessing |
| 23:01 | <abarth> | looks like the new Firefox doesn't quite follow the spec |
| 23:01 | <abarth> | in crazy foster parenting cases |
| 23:01 | <Hixie> | eseidel: i couldn't understand one of your bugs, so i marked it NEEDSINFO |
| 23:02 | <zcorpan_> | eseidel: try the zombie dom viewer for ie |
| 23:02 | <Hixie> | eseidel, abarth, hsivonen, zcorpan_, jgraham: I've resolved every parser bug I could find and every bug marked P1/crit; if I missed any please mark them P1/crit and let me know |
| 23:03 | <abarth> | Hixie: thanks. that's super helpful |
| 23:03 | <Hixie> | np |
| 23:03 | <Hixie> | sorry it took so long |
| 23:03 | <jgraham> | Hixie: Awesome |
| 23:03 | <abarth> | Hixie: did you look at the script@onload bug after you closed it? |
| 23:03 | <abarth> | Hixie: i'm not sure whether i'm misunderstanding the spec or whether your rationale is backwards |
| 23:04 | <abarth> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=9984 |
| 23:04 | <jgraham> | I verified that the end tag in foreign content fixes worked the way I expected in the html5lib test cases |
| 23:04 | <jgraham> | I mean I verified that html5lib with the new spec passed the tests |
| 23:05 | <Hixie> | jgraham: cool, i wasn't sure if what i did there made sense, thanks |
| 23:05 | <Hixie> | abarth: looking |
| 23:05 | <jgraham> | Hixie: Did hsivonen file a bug about <button>? I forget |
| 23:05 | <Hixie> | didn't see one |
| 23:05 | <jgraham> | Hixie: I think it was more-or-less equivalent to my ad-hoc fixes, but expressed in a slightly simpler way |
| 23:06 | <jgraham> | Hixie: The list of bugs that I know about is http://wiki.whatwg.org/index.php?title=ParserIssues |
| 23:06 | <Hixie> | abarth: hm, no, you're right, i forgot how the spec was written |
| 23:06 | <Hixie> | abarth: i don't understand the bug then |
| 23:06 | <Hixie> | abarth: what do you want changed? |
| 23:06 | <Hixie> | jgraham: looking... |
| 23:07 | <jgraham> | Hixie: It seems that you did change <button> somewhat |
| 23:07 | <Hixie> | abarth: (btw feel free to reopen bugs -- i don't see changes unless the bug is reopened) |
| 23:07 | <Hixie> | jgraham: all those bugs are resolved |
| 23:07 | <abarth> | Hixie: it's a place where FF and the spec are different. i don't particularly care about the behavior, but we either need to change the spec or get henri to agree to do what the spec says |
| 23:08 | <Hixie> | jgraham: and the e-mail had a bug for it too so that's dealt with now also |
| 23:08 | <Hixie> | abarth: ah ok |
| 23:08 | <abarth> | there's some subtly involving the requirements of an off-the-main-thread parser, which I don't quite grasp |
| 23:09 | <Hixie> | i'm not sure how we would change things to have it happen the other way around to be honest, looking at the spec more closely now |
| 23:10 | <Hixie> | short of just making the insertion pointer or whatever it's called undefined just for the event |
| 23:11 | <abarth> | ok |
| 23:12 | <abarth> | in the code, it's just a matter of switching the order of two lines of code |
| 23:12 | <abarth> | so we can do whichever |
| 23:12 | <daedb_> | heh, IE9 is really funny... <!doctype html><canvas></canvas> puts the canvas inside the body, but <!doctype html><style></style><canvas></canvas> puts canvas inside the head :) |
| 23:12 | <abarth> | Hixie: one more thing: https://bugs.webkit.org/show_bug.cgi?id=42112 |
| 23:12 | <jgraham> | abarth: Thanks for the reply about the cross-domain stuff. That looks like exactly what I was hoping for :) |
| 23:12 | <AryehGregor> | daedb_, yeah . . . HTML5 parser plz :( |
| 23:12 | <abarth> | Hixie: ap is worried about the null character's replacements looking ugly |
| 23:13 | <abarth> | Hixie: that bug has a link to some chinese site that looks pretty bad |
| 23:13 | <cardona507> | daedb_: yeah - IE9 is wacky |
| 23:13 | <daedb_> | AryehGregor: I found that with your test case :p |
| 23:13 | <abarth> | jgraham: glad it was helpful |
| 23:13 | <abarth> | Hixie: the old webkit behavior was to strip nulls in text nodes, but not in tag names, etc |
| 23:13 | <jgraham> | abarth: (I haven't actually read it in detail yet) |
| 23:16 | <sicking> | if I change something in browser/components/feeds , where do I need to rebuild to pick that up? |
| 23:16 | <abarth> | sicking: wrong channel? |
| 23:16 | <sicking> | abarth: hah, yes indeed :) |
| 23:17 | <sicking> | chatzilla doesn't have optimal focus management :) |
| 23:19 | <Hixie> | abarth: yeah, it's basically intentional |
| 23:19 | <Hixie> | abarth: there shouldn't be NULs there at all and they're likely to be triggering all kinds of security problems |
| 23:19 | <Hixie> | abarth: making it ugly is one way to draw attention to it |
| 23:21 | <abarth> | as brendan would say, i don't have a dog in this hunt. I've forwarded your comments to ap. |
| 23:22 | <ap> | Hixie: I doubt there is actually a security aspect to null handling in DOM |
| 23:22 | <Hixie> | there have been _many_ |
| 23:22 | <ap> | Hixie: maybe in 199x |
| 23:23 | <ap> | Hixie: there were more recent "security" issues about stripping nulls from tags, but those were very remotely related to security, in my opinion |
| 23:23 | <jgraham> | Hmm, Opera typically doesn't render past embedded nulls, so we are presumably badly broken with any site that has lots of them |
| 23:24 | <jgraham> | So a link would be appreciated :) |
| 23:24 | <ap> | jgraham: https://bugs.webkit.org/show_bug.cgi?id=42112 |
| 23:25 | <ap> | Hixie: and by the way, the more recent "security" issues were caused exactly by the attempts to give null some magical meaning, so some software might have potentially gotten it differently than other |
| 23:26 | <jgraham> | abarth: So are the security problems with the "subspace" design considered acceptable because it is too hard to inject code into an unwilling site this way, only one that specifically uses the design? |
| 23:26 | <zcorpan_> | jgraham: opera renders past nulls but not in view source |
| 23:27 | <abarth> | jgraham: the security problems arise from using these document.domain tricks. the recommended course of action is to ignore document.domain and use postMessage instead |
| 23:27 | <abarth> | jgraham: document.domain is very complex and best ignored |
| 23:28 | <jgraham> | abarth: From the point of view of a browser implementor though |
| 23:29 | <jgraham> | Obviously we have to support document.domain |
| 23:29 | <jgraham> | (I agree that *sites* shouldn't use it) |
| 23:30 | <jgraham> | (the rough context is that I want to be sure that implementing the HTML5 spec in Opera won't open up any significant security vunerabilities or privacy leaks or whatever compared to what we currently do) |
| 23:31 | <jgraham> | zcorpan_: Oh. |
| 23:31 | <abarth> | jgraham: yep |
| 23:31 | <abarth> | there's a deeper issue is opera |
| 23:31 | <abarth> | last time i checked |
| 23:31 | <abarth> | opera used dynamic instead of lexical authorization |
| 23:31 | <abarth> | which makes the document.domain attacks easier to pull off |
| 23:32 | <abarth> | HTML5 requires lexical authorization |
| 23:32 | <abarth> | and opera might have switched since i tested it last |
| 23:32 | <abarth> | http://www.adambarth.com/papers/2009/barth-jackson-li.pdf |
| 23:32 | <jgraham> | I am not sure I understand the difference |
| 23:32 | <abarth> | Section 2.1 |
| 23:32 | <jgraham> | But I will read the paper :) |
| 23:33 | <abarth> | in the spec |
| 23:33 | <abarth> | it's the difference between the active script |
| 23:33 | <abarth> | and the "first script" |
| 23:33 | <jgraham> | Ah |
| 23:33 | <abarth> | if you're able to run the webkit security layout tests |
| 23:33 | <jgraham> | OK. I remember that being "fun" |
| 23:33 | <abarth> | there's a bunch of stuff in there about that |
| 23:34 | <jgraham> | We can probably find a way to run those |
| 23:34 | <jgraham> | and really should be if we are not already |
| 23:34 | <Hixie> | ap: that has not been my experience, but i guess our experiences can differ :-) |
| 23:34 | <ap> | Hixie: can you point me to some bugs caused by null terminated strings used in DOM? |
| 23:35 | <Hixie> | not off-hand |
| 23:35 | <jgraham> | abarth: Thanks |
| 23:35 | jgraham | decides it is time for slep |
| 23:35 | <jgraham> | *sleep |
| 23:35 | <ap> | Hixie: and that wouldn't happen if nulls were inserted via DOM manipulation (nulls are still allowed there, correct?) |
| 23:36 | <Hixie> | abarth: "first script" was renamed at some point btw (i forget to what) |
| 23:37 | <Hixie> | ap: most of the kinds of bugs i've seen reently have been with server-side tools treating NULLs differently than browsers, and failing to properly filter content |
| 23:37 | <Hixie> | ap: but NULLs in general are frequently the source of random bugs, and I really would rather never have to worry about it, hence why I always try to write specs to get rid of them as soon as possible |
| 23:37 | <ap> | Hixie: yes, that's the kind I referred to as "security" |
| 23:38 | <Hixie> | ap: i see no harm in doing so, especially considering how rare NULLs are in "real" content |
| 23:38 | <ap> | Hixie: that's not the first time I say that I disagree with this general principle :) |
| 23:38 | <Hixie> | ap: i know |
| 23:39 | <ap> | Hixie: you may be giving some a false sense of security - they'll write code expecting that the parser gets rid of nulls for them, and then a Dom manipulation will insert a null |
| 23:39 | <ap> | Hixie: also, these new requirements are breaking existing content, and slow down decoding/tokenizing slightly |
| 23:40 | <Hixie> | ap: there are pros and cons on both sides |
| 23:40 | <Hixie> | ap: such is life |
| 23:40 | <ap> | Hixie: I suggest that we don't make changes that are not for the better then |
| 23:41 | <Hixie> | ap: i disagree that it's not for the better. |
| 23:41 | <ap> | Hixie: at this point, I struggle to find a use case that's improved by converting nulls to u+fffd |
| 23:41 | <Hixie> | ap: i think it improves security for most users of the HTML parser (who don't have a DOM to worry about), and it doesn't break enough content to be an issue, and the performance impact is minimal. |
| 23:42 | <Hixie> | ap: but as you say, we've had this discussion before |
| 23:42 | <Hixie> | ap: we're not covering new ground here |
| 23:42 | <ap> | Hixie: ah, the eternal "HTML is not for browsers" argument |
| 23:42 | <ap> | Hixie: well, previously we were talking about new specs, not about changing HTML in incompatible ways |
| 23:42 | <Hixie> | if you're just going to misrepresent what i'm arguing then there's not much point me arguing |
| 23:43 | <ap> | Hixie: I didn't intend to misinterpret. did I misunderstand you? |
| 23:43 | <Hixie> | i didn't say HTML was not for browsers |
| 23:44 | <ap> | Hixie: well, you said that most users of HTML parser don't have the DOM to worry about |
| 23:44 | <Hixie> | indeed |
| 23:44 | <Hixie> | only five users of the HTML parser have a DOM to worry about |
| 23:44 | <Hixie> | out of all the people who parse HTML, that's not the majority |
| 23:44 | <Hixie> | it also happens to the be most competent at writing and using HTML arasers |
| 23:44 | <Hixie> | parsers, even |
| 23:45 | <Hixie> | and thus not the most important when it comes to making sure that it's easy to not screw up |
| 23:45 | <Hixie> | s/to the be/to be the/ |
| 23:45 | <ap> | Hixie: it seems to be the primary target of security attacks though |
| 23:45 | <ap> | Hixie: btw, my understanding is that some Web spiders are now interpreting JS already - is that not true? |
| 23:46 | <abarth> | ap: that's correct |
| 23:47 | <Hixie> | are you saying that abarth and eseidel are so incompetent that what I do with NULLs in the HTML5 spec will affect the number of security bugs in their code? give me a break |
| 23:47 | <abarth> | ap: they tend to take a browser and hack it up to get it to crawl nicely |
| 23:49 | <ap> | Hixie: it sounds like the only case that's helped by this change is code that incorporates a full HTML5 tokenizer, and then does something truly naive with it |
| 23:49 | <ap> | Hixie: since otherwise, they will happily convert null to null, not knowing that there is a spec saying it should be turned into FFFD |
| 23:49 | <Hixie> | you've just described a large portion of future HTML parsing software |
| 23:51 | <ap> | Hixie: are you saying that it will be easier to incorporate an HTML5 library than to use whatever scripting language mechanism there is to convert a result of a curl/wget download to a native string? |
| 23:52 | <Hixie> | do you think that's what i'm saying? |
| 23:52 | <ap> | Hixie: yes |
| 23:52 | <Hixie> | could you please at least assume i'm not an idiot? |
| 23:52 | <Hixie> | seriously |
| 23:53 | <ap> | Hixie: you're probably moving too fast for me to follow |
| 23:53 | <Hixie> | it will obviously not be easier to wget a file, turn it into a string, and then pass it to a parser than it will be to wget a file, and turn it into a string. |
| 23:54 | <ap> | Hixie: you said that a "large portion of future HTML parsing software" will do something, and I'm trying to imagine how I would write a piece of software that would fit the picture |
| 23:54 | <Hixie> | to parse HTML, you can either hack it using regexps, or you can use an HTML parser |
| 23:54 | <Hixie> | few people will write their own HTML parsers, since it's a non-trivial task |
| 23:55 | <ap> | Hixie: yes, if the software doesn't need a DOM, they'll probably just regex parts of wget output |
| 23:55 | <Hixie> | there's nothing we can ever do to make regexp parsers do anything, since they ignore the spec by definition |
| 23:55 | <Hixie> | so all we can affect are the people using the libraries, which presumably follow the spec |
| 23:55 | <ap> | Hixie: and if there is a DOM, they can shoot themselves in the foot even if they don't execute JS from the documents |
| 23:56 | <Hixie> | dude, they can shoot themselves in the foot without any help from us |
| 23:56 | <Hixie> | the idea is to reduce the likelihood of that |
| 23:56 | <Hixie> | we can never make it impossible |
| 23:56 | <ap> | Hixie: what I'm saying is that it's not reducing the likelihood, but giving a false expectation |
| 23:56 | <Hixie> | and i disagree |
| 23:56 | <Hixie> | i don't think it's giving anyone any expectation |
| 23:57 | <Hixie> | since these people aren't going to know about this at all |
| 23:57 | <Hixie> | anyway i really have to do work |
| 23:57 | <Hixie> | if you want this changed, please file a bug or send mail |
| 23:59 | <ap> | there is a WebKit bug, that's my form of feedback |