| 00:00 | <Hixie> | should you be able to hold the entire industry hostage when others independently come up with the same idea? |
| 00:00 | <jcranmer> | well, compressing movie pictures shouldn't be patentable |
| 00:00 | <Hixie> | anyway |
| 00:00 | <jcranmer> | since you're essentially taking one number and making it another number |
| 00:00 | <gsnedders> | patents suck, kthxbai |
| 00:01 | <roc> | Stephen Wolfram would argue that everything that happens in the universe boils down to that too |
| 00:01 | <zcorpan> | Hixie: did you change anything to the live forums.whatwg.org? |
| 00:01 | <Hixie> | zcorpan: upgraded to 3.0 and added the text confirmation thing |
| 00:01 | <gsnedders> | roc: More dangerously, so would I :) |
| 00:01 | <Hixie> | zcorpan: did i break something? |
| 00:02 | <gsnedders> | (dangerously insofar as that I'm hre) |
| 00:02 | <gsnedders> | *here |
| 00:02 | <jcranmer> | well, there's one potential ramification if everything flies |
| 00:03 | <jcranmer> | no one can have any qualms about MP3 being patent-protected :-) |
| 00:03 | <roc> | it would solve a ton of problems |
| 00:03 | <roc> | it would greatly simplify the issue of choosing standard codecs for <video> and <audio> |
| 00:04 | roc | brings the thread back on topic |
| 00:04 | <zcorpan> | Hixie: doesn't look like 3.0 and the admin panel says it's 2.0.22 like before |
| 00:04 | <jcranmer> | yep |
| 00:04 | <roc> | but I'm not holding my breath, to be honest. too good to be true |
| 00:04 | <gsnedders> | Hixie, zcorpan: Yeah, that's certainly 2.0: even 3.0's subSilver looks different |
| 00:04 | <jcranmer> | roc: all we have to do is hope that the justices are sufficiently computer-literate to understand why software patents are bad |
| 00:05 | <zcorpan> | Hixie: got a PM from BearState saying that he got promted for his password when posting, so it looks like someone has messed up our phpbb |
| 00:05 | <roc> | that's actually the best hope --- the current US Supreme Court is very skeptical about patents |
| 00:06 | <roc> | putting Roberts in charge is the best thing the Bush administration ever did |
| 00:06 | <roc> | which isn't saying much |
| 00:06 | <jcranmer> | well, my day is made if |
| 00:06 | <jcranmer> | a) Supreme Court goes back to the Betamax decision |
| 00:06 | <jcranmer> | b) Diamond v. Diehr is overturned |
| 00:09 | <jcranmer> | sorry, not necessarily Diehr's decision, but the State Street decision |
| 00:10 | <zcorpan> | Hixie: i think i'll edit the permissions so people can't post at all for now |
| 00:14 | <Hixie> | odd that it would not be 3.0 |
| 00:33 | Philip` | sees http://openwebfoundation.org/ |
| 00:35 | <jruderman> | that page's copyright is apparently owned by the year 2008 |
| 00:37 | <jruderman> | i like that. i think i'm going to assign my next copyright to whitespace (not any particular whitespace, but the general concept of whitespace). |
| 00:37 | <Philip`> | The W in their logo font is a bit ugly |
| 00:37 | <jruderman> | eww. yes, it is. |
| 00:38 | <gavin_> | I like it |
| 01:20 | <kangax> | Why does shape produced by strokeRect has some kind of an implicit min-width? |
| 01:20 | <kangax> | strokeRect(1,1,1,100); // => draws a rectangle that is ~5px wide |
| 01:24 | <Philip`> | kangax: It might be caused by drawing lines along the edges between pixels, so the pixels on both sides of that edge get painted |
| 01:25 | <Philip`> | strokeRect(1.5, 1.5, 1, 100) should draw a sharper rectangle, because then it's drawing its lines through a single row/column of pixels instead of between the rows/columns |
| 01:26 | <kangax> | actually, I think I got it - second/third args are width/height, not coordinates of bottom right corner |
| 01:26 | <Philip`> | Ah, that might affect it too :-) |
| 01:26 | <kangax> | : ) thanks |
| 02:03 | <Hixie> | zcorpan: patched |
| 03:24 | <heycam> | "The term activation behavior is used as defined in the DOM3 Events specification. At the time of writing, DOM3 Events hadn't yet been updated to define that phrase." :) |
| 03:29 | <Hixie> | i think DOM3 Events has changed editors at least once since i came to an agreement with the editor of dom3 events to define that |
| 03:31 | <heycam> | aha |
| 03:32 | <heycam> | http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#events-Events-flow-cancelation says "This section is currently being rewritten", though it does mention activation behaviour |
| 05:12 | <Mook> | anybody bored and want to talk xbl2? I just have a relatively simple question... |
| 05:14 | <Mook> | For an element bound via CSS, does moving the node (via a single appendChild call, for example) involve unbinding it first? (would script properties persist across the move) |
| 05:24 | <heycam> | Mook, i would say that it would involve unbinding |
| 05:25 | <heycam> | because appendChild() will have to remove the element from the document and then reinsert it |
| 05:25 | <Mook> | even though it will end up still bound after the move? |
| 05:25 | <Mook> | right |
| 05:25 | <heycam> | by my reading, yeah |
| 05:25 | <Mook> | :( That'd mean we'll still end up losing state, which kinda sucks |
| 05:25 | <heycam> | it does kinda |
| 05:26 | <heycam> | esp if you're just moving elements around for z-order or something (which probably is more of an issue for svg than html) |
| 05:26 | <Mook> | (can't be worse than moz-xbl, though - in that case, the constructor gets called, but not the destructor, and all <field/>s are reset, but existing random properties are not) |
| 05:27 | <heycam> | that doesn't sound useful |
| 05:28 | <Mook> | it's perfectly useful for introducing bugs into your app :p Hitting this, again, today was what prompted me to look at xbl2 behaviour. |
| 05:28 | <heycam> | heh |
| 05:35 | <roc> | SVG should just bite the bullet and adopt CSS z-index |
| 05:36 | <heycam> | perhaps |
| 05:36 | <Mook> | well, my use case was tab reordering in a tab strip |
| 05:36 | <Mook> | so unless CSS can magically display a series of DOM nodes in arbitrary order... |
| 05:36 | <heycam> | Mook, but xbl can do that, no? :) |
| 05:36 | <roc> | XUL flexbox CSS can |
| 05:37 | <roc> | I don't think XBL can |
| 05:37 | Mook | tries to figure out how to make <tabs><tab label="A"/><tab label="B"/><tab label="C"/></tabs> display "C A B" |
| 05:38 | <Mook> | ... and scaling to > 3, of course, so #c{float: left} doesn't help :p |
| 05:38 | <heycam> | couldn't xbl do that with <content> elements? |
| 05:40 | <heycam> | http://www.cs.washington.edu/education/courses/190m/08sp/exams/final/student_art.pdf |
| 05:40 | <roc> | You can't do arbitrary content permutations that way |
| 05:40 | <heycam> | no, not arbitrary |
| 05:45 | <Mook> | setInsertionPoint says "The order of nodes assigned to a content element is always be the same as the relative order of those nodes in the original core DOM" explicitly. So I guess that doesn't help. |
| 05:47 | <roc> | no |
| 05:47 | <roc> | it does help |
| 05:47 | <roc> | because you can use multiple insertion points |
| 05:47 | <Mook> | hmm, I wonder if I'd be able to dynamically create insertion points |
| 05:48 | <Mook> | and if I do, I wonder if they'll end up applying to all instances of the binding. reading time. |
| 05:55 | <Mook> | okay, so the shadow tree is cloned from the shadow tree template (sec 4), and can be manipulated (4.6). so yay. |
| 07:25 | <Hixie> | this test shows that IE uses compatibility case folding for usemap: |
| 07:25 | <Hixie> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cmap%20name%3D%22T%26eacute%3B%26%23x01F1%3B%26%23x2075%3B%22%3E%3Carea%20href%3D%22%2F%22%20shape%3Drect%20coords%3D0%2C0%2C200%2C200%3E%3C%2Fmap%3E%0A%3Cimg%20usemap%3D%22%23t%26Eacute%3BDZ5%22%20src%3Dimage%3E |
| 07:26 | <Hixie> | but given that, why doesn't it find a match with this test?: |
| 07:26 | <Hixie> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cmap%20name%3D%22T%26eacute%3B%26%23x01F1%3B%26%23x2075%3B%26%23xFB01%3B%22%3E%3Carea%20href%3D%22%2F%22%20shape%3Drect%20coords%3D0%2C0%2C200%2C200%3E%3C%2Fmap%3E%0A%3Cimg%20usemap%3D%22%23t%26Eacute%3BDZ5F%26%23x0131%3B%26%23x0307%3B%22%20src%3Dimage%3E |
| 07:27 | <Hixie> | maybe it doesn't know that dotless i + combining dot above is the same as an i? |
| 07:27 | <Hixie> | i wonder how they'd get that kind of bug |
| 07:28 | <zcorpan> | i'd rather it was ascii case insensitive unless there are pages relying on it |
| 07:36 | <zcorpan> | i've allowed posting on the forums again |
| 08:32 | <zcorpan> | if somone here wants to be a mod on forums.whatwg.org to help delete spam, let me know |
| 08:32 | <zcorpan> | if someone here anytime spots spam on the forums, also let me know |
| 08:42 | zcorpan | tries activating admin account activation |
| 09:36 | <zcorpan> | Hixie: btw, there's no need to upgrade to 3.0 at this point, doing so might mean we have to redo some changes |
| 09:36 | <Hixie> | good cos i have no idea how to do that :-) |
| 09:37 | <Lachy> | Can someone who understands CSS well, take a look at this test case. As it is now, Firefox passes and Opera and WebKit fail, but I'm told the test is invalid, but I can't figure out why. http://html5.lachy.id.au/output?data=%3C!DOCTYPE+html%3E%0D%0A%3Ctitle%3Emin-height+of+body+when+child+has+bottom+margin%3C%2Ftitle%3E%0D%0A%3Cstyle%3E%0D%0Ahtml+{+background%3A+red%3B+margin%3A+0%3B+padding%3A+0%3B+height%3A+100%25%3B+}%0D%0Abody+{++background%3A+whit |
| 09:37 | <Lachy> | e%3B+margin%3A+0%3B+padding%3A+0%3B+min-height%3A+100%25%3B+}%0D%0Adiv+{+margin-bottom%3A+100px%3B+}%0D%0A%3C%2Fstyle%3E%0D%0A%3Cdiv%3EThis+page+should+not+be+able+to+scroll+and+there+should+be+no+red.%3C%2Fdiv%3E&type=text%2Fhtml%3B+charset%3DUTF-8 |
| 09:37 | <Lachy> | here's a tiny URL for it http://tinyurl.com/5dha3q |
| 09:38 | <Hixie> | the test assumes viewport is > 100px |
| 09:38 | <Lachy> | yes, which is reasonable |
| 09:39 | <Hixie> | otehr than that it seems valid to me... |
| 09:39 | <Lachy> | cool, that's what I thought |
| 09:39 | <Hixie> | who told you it was invalid? |
| 09:39 | <Lachy> | Moose did |
| 09:40 | <Hixie> | ah |
| 09:40 | <Hixie> | ask him for chapter and verse |
| 09:40 | <Hixie> | generally speaking though in my experience moose's understanding of the css specs is often at odds with my own |
| 09:40 | <Hixie> | (even in cases where i wrote the relevant parts of css) |
| 09:41 | <MikeSmith> | Moose is bigger than Lachy, maybe Lachy's afraid |
| 09:41 | <Hixie> | if you want me to comment on a bug, let me know the # :-) |
| 09:41 | <Lachy> | I pointed him to the exact part of the specification that backs me up. I'm waiting for him to respond to the bug report again |
| 09:41 | <Lachy> | Hixie, do you still have access to Opera's bug tracker? |
| 09:41 | <Hixie> | i have a bts account, yes |
| 09:41 | <Hixie> | (and am under nda with opera) |
| 09:41 | <MikeSmith> | Lachy: you need to grow a beard so that you can be more intimidating.. a beer gut helps too |
| 09:42 | <Lachy> | MikeSmith, no chance of me growing a beard. A friend of my tried to get me to grow one for a week. I couldn't last more than 3 days without shaving. |
| 09:43 | <Philip`> | You could grow one in a flower pot, then put it on for special occasions |
| 09:43 | <Lachy> | LOL |
| 09:44 | <MikeSmith> | OK, you can buy one from a makeup show and wear that. But it needs to be a big-ass, Grizzly Adams /Old Testament prophet kind of beard -- especially in Norway |
| 09:45 | <MikeSmith> | beard cred |
| 09:47 | <Lachy> | MikeSmith, did you have a beard while you were in Oslo? |
| 09:48 | <MikeSmith> | yeah, but more a boozer beard -- Yasser Arafat type of beard |
| 09:53 | <virtuelv> | Lachy: go ask moose why |
| 09:54 | <virtuelv> | (re test case) |
| 09:54 | <Lachy> | virtuelv, yeah, he wasn't in his office when I checked earlier |
| 09:55 | <virtuelv> | ah, that's right, he's off for the weekend |
| 10:04 | <zcorpan> | Hixie: should noscript be display:none!important in the ua style sheet when scripting is enabled? |
| 10:04 | <Hixie> | not !important |
| 10:04 | <Hixie> | imho |
| 10:17 | <Lachy> | I can't figure out why this is giving an internal server error now. The code used to work on my old web host. http://html5.lachy.id.au/clipboard - source code here: http://html5.lachy.id.au/clipboard-source |
| 10:19 | <Hixie> | what's the error? |
| 10:23 | Hixie | removes about 40 XXXs from the spec |
| 10:23 | <Hixie> | aw man, that's hardly even a dent in the line |
| 10:23 | <MikeSmith> | Lachy: that script seems to work OK if I run it from command line |
| 10:24 | <MikeSmith> | i.e., with CONTENT_TYPE=text/html REQUEST_METHOD=POST python clipboard-source |
| 10:25 | <Lachy> | Hixie, other than an Internal Server Error of some kind, I have no idea. I just know it's being caused by when I try to send a 204 No Content response |
| 10:25 | <Hixie> | no message in the logs? |
| 10:25 | <Hixie> | apache's error.log in particular? |
| 10:25 | <Lachy> | where would I find the error log? |
| 10:26 | <Lachy> | [Fri Jul 25 11:26:49 2008] [error] [client ::1] Premature end of script headers: clipboard.py |
| 10:27 | <MikeSmith> | /var/log/apache2/error.log |
| 10:27 | <MikeSmith> | maybe |
| 10:27 | <Lachy> | found it in /Applications/MAMP/logs/apache_error_log |
| 10:28 | <Lachy> | on my localhost server |
| 10:28 | <Hixie> | try outputting an extra blank line |
| 10:28 | <MikeSmith> | it's not sending any Content-Type header.. should it be? |
| 10:29 | <Hixie> | not for a 204 |
| 10:29 | <Hixie> | but i think it needs a blank line |
| 10:29 | <hsivonen> | eww. compatibility caselessness :-( |
| 10:30 | <Hixie> | yeah i was shocked to see IE do that |
| 10:30 | <Lachy> | changing it to print "Status: 204 No Content\r\n" has no effect |
| 10:30 | <Hixie> | mind you none of the other browsers do so maybe we can change it |
| 10:30 | <Hixie> | Lachy: does python's "print" output a newline automatically? does it still do that if the string ends in a newline? |
| 10:31 | <Lachy> | I don't know |
| 10:31 | <Lachy> | I think it does, but I'll have to check the docs |
| 10:31 | <MikeSmith> | python "print" prints out a newline automatically, I'm purty sure |
| 10:32 | <Lachy> | "A "\n" character is written at the end, unless the print statement ends with a comma. This is the only action if the statement contains just the keyword print." |
| 10:33 | <Hixie> | dunno then |
| 10:33 | <Hixie> | try sending a body |
| 10:34 | <Lachy> | already tried that, had no effect |
| 10:35 | <Lachy> | but if I change it to print 200 OK instead, it works fine. So it just doesn't like sending 204 |
| 10:36 | <Hixie> | weird |
| 10:37 | <Hixie> | heycam: there's no special WebIDL-fu to handle https://bugzilla.mozilla.org/show_bug.cgi?id=214574#c8 yet, right? Is that on your list? |
| 10:38 | <MikeSmith> | Lachy: you tried just: |
| 10:38 | <MikeSmith> | print "Status: 204 No Content" |
| 10:39 | <MikeSmith> | |
| 10:39 | <MikeSmith> | just and empty "print" I mean |
| 10:39 | <MikeSmith> | instead of "print .. \r\n" |
| 10:40 | <Lachy> | ah, I found my problem. It was sending 204 properly when I added \r\n, but the browser kept displaying the error message because it had nothing to replace it with. |
| 10:41 | <Lachy> | now it works |
| 10:44 | <Hixie> | hah |
| 10:45 | <Hixie> | that's funny |
| 10:49 | <Hixie> | ok bed time |
| 10:49 | <Hixie> | nn |
| 11:20 | <hsivonen> | It seems that machine translation isn't quite there yet. http://translate.google.com/translate?u=http%3A%2F%2Fweb.g.hatena.ne.jp%2Fvantguarde%2F20080707%2F1215437094 |
| 11:24 | <Philip`> | Babel Fish doesn't seem any better |
| 11:36 | hsivonen | wonders how many bytes would be saved daily in bandwidth if WP didn't have the silly profile attribute... |
| 11:37 | <hsivonen> | http://trac.wordpress.org/ticket/6918 |
| 11:38 | <zcorpan> | hsivonen: is that basically saying "switch to html5"? |
| 11:39 | <hsivonen> | zcorpan: it could also be saying: "create an XHTML 1.0 plus ARIA validatation target" |
| 11:41 | <zcorpan> | i don't want another XHTML PFI :( |
| 11:41 | <hsivonen> | zcorpan: one cannot be coined without triggering the standards mode |
| 11:42 | <hsivonen> | zcorpan: however, the W3C validator could trigger on the system id and keep an existing public id |
| 11:42 | <hsivonen> | which would be totally wrong in theory, of course |
| 11:43 | <tommorris> | the profile attribute isn't silly. it is actually useful, if used correctly. |
| 11:43 | <hsivonen> | tommorris: what is it useful for? |
| 11:44 | <tommorris> | GRDDL |
| 11:44 | <hsivonen> | tommorris: in a loosely coupled distributed environment, it totally sucks if the publisher needs to cooperate in order to make a specific scraping solution work |
| 11:45 | <tommorris> | that's not how it's designed. |
| 11:47 | <tommorris> | I still don't see why it has been removed from HTML 5. Nobody is asking the editors to like GRDDL. Just not break it. |
| 11:49 | <MikeSmith> | hsivonen: vantguarde is the same as myakura |
| 11:50 | <MikeSmith> | so you can ask him to translate it for you :) |
| 11:50 | <hsivonen> | MikeSmith: I was unaware. |
| 11:50 | <hsivonen> | MikeSmith: nah. translation is too much trouble. |
| 12:04 | <hsivonen> | tommorris: I think it is about a duty to protect Web authors against the trouble of dealing with requests to add profile on their pages. or something like that. |
| 12:04 | <tommorris> | srsly, how often does *that* happen |
| 12:05 | <tommorris> | I guess, you are also protecting the authors who want to use it from the same fate |
| 12:08 | <hsivonen> | I don't know. Way back in 2000 I ended up wasting my time on putting Dublin Core metadata on my pages. |
| 12:09 | <hsivonen> | zcorpan: I fixed the http://dev.w3.org/html5/html-author/charref crash. thanks |
| 12:10 | <zcorpan> | hsivonen: cool |
| 12:10 | <hsivonen> | the highligting in errors 5 and 6 in unintuitive now... |
| 12:11 | <hsivonen> | (caused by tag inference) |
| 12:12 | <hsivonen> | Lachy: you could avoid errors 1-4 by putting a space before the combining char |
| 12:12 | <Lachy> | hsivonen, ok, I'll do that now |
| 12:13 | <hsivonen> | Hixie: it seems theoretically impure to have entities that expand to non-NFC (OHM SIGN and ANGSTROM SIGN) |
| 12:14 | <gsnedders> | hsivonen: Since when did we care about theoretical pureness? We're a long way from it already. |
| 12:14 | hsivonen | is inclined to think OHM SIGN and ANGSTROM SIGN should never have gotten their own code points |
| 12:15 | <hsivonen> | (DC metadata in HTML was a waste of time, because it duplicated metadata that HTML and HTTP support natively.) |
| 12:16 | <Lachy> | hsivonen, done. |
| 12:16 | <zcorpan> | gsnedders: at least you should be able to use allowed entities and not get validation errors |
| 12:16 | <Lachy> | what about the last 2 errors? |
| 12:16 | <hsivonen> | Lachy: thanks |
| 12:16 | <hsivonen> | Lachy: I think you can't conform to charmod-norm and use OHM SIGN and ANGSTROM SIGN. |
| 12:18 | <Lachy> | really? why? |
| 12:19 | <hsivonen> | Lachy: they expand to code points that are prohibited in NFC |
| 12:19 | <hsivonen> | NFC normalizes them to upper case omega and a with ring above |
| 12:19 | <Lachy> | oh, that seems a bit odd |
| 12:20 | <tommorris> | hsivonen: GRDDL+profile is a way to dramatically reduce the need for duplication of metadata... |
| 12:20 | <hsivonen> | Lachy: it seems to me it's a bug in Unicode that they tried to mitigate when defining NFC |
| 12:20 | <Lachy> | if that's the case, then should we make them non-conforming? |
| 12:21 | <hsivonen> | tommorris: my point is that you shouldn't need any incantation to tell a scraper that HTML <title> is the title. The scraper should know that in text/html, <title> is the title. |
| 12:21 | <zcorpan> | hsivonen: or make the entities expand to the NFC equivalents |
| 12:21 | <zcorpan> | s/hsivonen/Lachy/ |
| 12:21 | <hsivonen> | zcorpan: good point |
| 12:21 | <hsivonen> | Hixie: what zcorpan said merits considering |
| 12:22 | zcorpan | files a bug |
| 12:22 | <hsivonen> | Lachy: at some point I had some reason to guess that charmod-norm would become part of HTML5 conformance criteria |
| 12:23 | <Lachy> | so do you mean that #ohm; and Å will be expanded to U+03A9 and U+00C5 instead? |
| 12:23 | <Lachy> | making them the same as ω and å? |
| 12:23 | <tommorris> | hsivonen: nobody is suggesting that one *needs* that. just that it's quite useful to be able to provide a way for a parser to follow it's nose and find more information about how to parse a document. |
| 12:23 | <hsivonen> | though by the time HTML5 becomes a REC, the installed base of browsers will deal with NFD |
| 12:23 | <hsivonen> | or, rather, stuff that NFC hides |
| 12:24 | <hsivonen> | Lachy: Ω and Å |
| 12:24 | <Lachy> | right, that's what I meant |
| 12:24 | <hsivonen> | tommorris: the parser can't do that unless someone troubles the page authors |
| 12:24 | <Lachy> | I gave the right codepoints, just capitalised wrongly |
| 12:25 | <tommorris> | hsivonen: I still don't get this point. If they want to put an hCard in, they will be "troubled". If they want to put a <time> in, they'll be "troubled". What's so different about putting in a @profile? |
| 12:25 | <hsivonen> | tommorris: the value it provides compared to an alternative solution |
| 12:26 | <tommorris> | if the aim is to not trouble page authors, just tell them to not put any thing up on the web. or stick to text/plain |
| 12:27 | <tommorris> | so, the alternative solution is <link rel="profile">. only that breaks existing grddl implementations... |
| 12:28 | <zcorpan> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=5897 |
| 12:28 | <hsivonen> | tommorris: what I see as the alternative solution is the scraper having programmed knowledge about well-known vocabularies and the ability to recognize microformat gestalts |
| 12:29 | <tommorris> | hsivonen: how does that solve the problem of a web author who wants to publish a whole bunch of HTML pages that have a custom set of metadata? Wait, don't tell me: "Go Pareto Principle!" |
| 12:30 | <hsivonen> | tommorris: who's going to consume the custom metadata? |
| 12:30 | <tommorris> | anyone who wants to. |
| 12:31 | <hsivonen> | tommorris: how does the agreement on meaning form between the loosely coupled parties? how is one person's homegrown metadata vocabulary interesting enough for someone to write software for it? |
| 12:32 | <tommorris> | well, you know, all the usual ways stuff like that happens. |
| 12:33 | <tommorris> | we can't expect everyone to do that on whatwg.org or microformats.org |
| 12:33 | <zcorpan> | Hixie: "+ string or a value that is a, <span>ASCII case-insensitive</span>" s/a,/an/ |
| 12:34 | <hsivonen> | tommorris: even if a microformat-like format isn't tantek-approved, the non-loose parties can agree on meaning |
| 12:35 | <tommorris> | eg. a bunch of geneticists are working on ways of marking that, say, a web document refers to specific genes. part of the way they do that is to start publishing documents, and GRDDL provides an easy way for them to map that to existing RDF and XML-based metadata formats |
| 12:36 | <hsivonen> | tommorris: what I don't understand is this: if you are out to scrape a genetic microformat with GRDDL, why wouldn't you make the scraper default to that GRDDL transformation so that you can catch cases where the profile is missing |
| 12:37 | <tommorris> | yes, but the idea is that authors should be able to declare the microformats (etc.) that they use. |
| 12:38 | <hsivonen> | I guess I just don't see the value in declaring them, because consumers are better off trying to look for the gestalt instead of failing when the declaration is missing |
| 12:39 | <tommorris> | I can think of certain instances where one should not do that |
| 12:39 | <tommorris> | the "not-hCard" scenarios are an academic example of that. |
| 12:42 | <hsivonen> | tommorris: I think academic examples aren't interesting. Real coincidences are. |
| 12:45 | <tommorris> | well, the thing is that the argument you are making is against GRDDL. but all that will happen is that if @profile isn't in HTML 5, we'll probably have to just change the GRDDL spec so that parsers look in both @profile and link[@rel='profile'], and change the various parsers so they do that. |
| 12:48 | <tommorris> | either way people will want to use it (not many people, but that doesn't matter to anyone who is not a Pareto fundamentalist), and they'll find a way. it just seems silly not to have it in the spec. |
| 12:54 | <zcorpan> | tommorris: i don't know anything about grddl but would it hurt to ignore profile and just assume it's there? |
| 12:55 | <tommorris> | zcorpan: what do you mean? when writing HTML 5 documents, just include @profile? |
| 12:55 | <tommorris> | that's what DanC is doing, btw |
| 12:55 | <tommorris> | view source on http://www.w3.org/People/Connolly/ ;) |
| 12:56 | <zcorpan> | tommorris: i mean, when doing grddl processing, don't look for profile but act as if it was there |
| 12:56 | <hsivonen> | tommorris: when you are extracting genetic data, behaving as if every page had a profile for the genetic data GRDDL transformation |
| 12:56 | <hsivonen> | tommorris: and when looking for contact info, behaving as if every page had an hCard profile |
| 12:57 | <tommorris> | well, yes, but that doesn't solve the problem |
| 12:57 | <tommorris> | that still means that for every use case you have to write a new parser. |
| 12:58 | <hsivonen> | tommorris: no, you don't need to write a new parser, you just need to give a GRDDL transformation appropriate for the use case as an input argument |
| 12:59 | <tommorris> | again, yes, you can do that - and many implementations will do that - but it doesn't solve the problem |
| 13:00 | <hsivonen> | tommorris: what's "the problem"? |
| 13:00 | <tommorris> | the problem is that authors should be able to declare in a machine-readable way the data schemas they are using, rather than having to insert magic into every parser |
| 13:01 | <hsivonen> | that doesn't look like a problem statement. It looks like a solution statement. |
| 13:01 | <gsnedders> | tommorris: In the case of things like µf, parsers already have to behave as if there is a @profile there even when it is missing, because it isn't there so often |
| 13:02 | <gsnedders> | tommorris: They're going to have to have this to be compatible with the real world regardless of whether @profile exists in HTML 5. |
| 13:02 | <tommorris> | Yes, but that's discretionary. |
| 13:03 | <gsnedders> | tommorris: Only really discretionary insofar as an option of: a) be compatible with real websites; b) be theoretically correct |
| 13:04 | <tommorris> | The problem with this is that it presumes that there is a universal microformat mapping. |
| 13:04 | <hsivonen> | tommorris: not universal. just one that your next processing step expects |
| 13:05 | <hsivonen> | tommorris: if you are scraping for hCard data, surely you need something that groks hCard/vCard-like data as a further step |
| 13:05 | <hsivonen> | assuming that the process *does* something with the data after scraping it |
| 13:58 | <Philip`> | hsivonen: That sounds like a violation of layering - just like how your HTTP processor shouldn't have to care whether you're expecting HTML or CSS or PNG data, your RDF/GRDDL/something processor shouldn't have to care whether you're expecting hCard or hCal or XFN data |
| 14:22 | <Lachy> | I've fixed all known bugs with http://html5.lachy.id.au/ - Now the clipboard, validation feature and html5lib viewer features work properly |
| 14:22 | <Lachy> | also added a default template to the text box |
| 14:23 | <zcorpan> | Hixie: actually the svg wg's proposal is pretty much based on my suggestions as well :) not that i personally like the svg wg's proposal though |
| 14:31 | <hsivonen> | Philip`: when you load a PNG image over HTTP, the image doesn't come with a URI pointing to a PNG decoder |
| 15:20 | <Philip`> | hsivonen: That unfortunately missing feature is impossible in HTTP, since there's no way to write a PNG decoder that's portable and fast and not hundreds of kilobytes, built on a framework that also let you implement decoders for all other useful types of content (JPEG, SVG, HTML, etc) |
| 15:21 | <Philip`> | so we have to live with the disadvantages that come from that, like never using anything other than three bitmap image formats |
| 15:22 | <Philip`> | GRDDL stuff doesn't have that problem, since the associated XSLT files are small and portable, so there's much more possibility of being able to implement something like that |
| 15:23 | <tommorris> | yep, and GRDDL is not-just-RDF: I can imagine some great uses to do Atom, KML and other XML syntaxes |
| 15:51 | <zcorpan> | the forums now have 11 moderators, i hope that'll scare spammers away |
| 15:52 | <Philip`> | Not when they realise all the moderators are inactive :-) |
| 15:52 | <zcorpan> | we'll see |
| 15:52 | <zcorpan> | at least we haven't got any spam so far! |
| 16:00 | <zcorpan> | hmm, shouldn't <meta ... content="TEXT/HTML; CHARSET=UTF-8"> be allowed? (with uppercase "charset") |
| 17:26 | <gsnedders> | http://hg.gsnedders.com/spec-gen/raw-file/tip/README.html |
| 17:27 | <Philip`> | s/enviroments/environments/ |
| 17:28 | <Philip`> | When you talk about abbr, etc elements, is that limited to the HTML namespace? |
| 18:09 | <gsnedders> | Philip`: either in no namespace or the HTML namespace |
| 18:16 | <hsivonen> | 3 |
| 18:16 | <gsnedders> | 4 |
| 18:16 | <hsivonen> | 6Oops |
| 18:17 | <gsnedders> | Hmm… |
| 18:17 | <gsnedders> | It'd be interesting to have the spec-gen implemented in ECMAScript |
| 18:18 | <gsnedders> | Philip`: Is the updated copy clear enough? |
| 19:14 | <Hixie> | tommorris: profile="" isn't in HTML5 because it's a dumb feature, it has nothing to do with my opinion of GRDDL :-) |
| 19:14 | <Hixie> | tommorris: (and it wasn't taken out, we started HTML5 from a blank slate -- I literally wrote every word in the spec from scratch) |
| 19:15 | <tommorris> | Okay. How then can we progress to get an amiable situation? Basically, I want to be able to have HTML 5 with working GRDDL. I don't really mind who changes their spec. |
| 19:16 | <Hixie> | GRDDL should just support the microformats it supports without being prompted to support them |
| 19:17 | <tommorris> | Yes, but there is layering at work here. |
| 19:18 | <Hixie> | layering? |
| 19:18 | <tommorris> | If I'm implementing GRDDL, generally one will make it work as to the spec. |
| 19:18 | <tommorris> | Then you can leave a big option field open so that the user can pop in a list of all the default microformats it wants to look for. |
| 19:19 | <Hixie> | GRDDL should always look for all microformats it supports, if it requires a flag in the document before looking for a microformat, that's a bug in GRDDL |
| 19:19 | <hober> | Couldn't GRDDL use link@rel="profile" instead of head@profile? RelExtensions lists link@rel="profile" |
| 19:19 | <Hixie> | link rel="profile" is as stupid as head profile="" |
| 19:20 | <tommorris> | Stupid it may be. Ugly it may be. But there are plenty of people - like myself - who have to implement it |
| 19:21 | <hober> | Hixie: indeed, but rel values are less obtrusive than a custom attribute like head@profile. So if they insist, I'd just assume they use @rel="profile" over head@profile. |
| 19:21 | <tommorris> | And if it's just a microformats scraper, that's not the point of GRDDL. It's about letting authors explicitly declare the data inside their page. |
| 19:21 | <tommorris> | I don't really care either way. I just have to write the damn code. ;) |
| 19:21 | <hober> | tommorris: But simply by saying <div class="vcard">, I've already explicitly declared the data on my page... |
| 19:22 | <tommorris> | Yes, unless in outer Mongolia or somewhere, class="vcard" means something different. |
| 19:22 | <jgraham> | The problem is that @profile is a long way in metadata space from the actual data so it's quite likely to be wrong or missing |
| 19:22 | <jgraham> | See also: content-type |
| 19:22 | <Hixie> | tommorris, hober: I have no interest in supporting people who are doing stupid things |
| 19:22 | <tommorris> | Again, my preferred solution is to actually look through the whole document for *[@rel='profile']/@href |
| 19:23 | <Hixie> | tommorris, hober: no offense :-) |
| 19:23 | <hober> | None taken. :) I don't want @profile in HTML. |
| 19:23 | <Hixie> | tommorris: i recommend making your code pretend that all profiles are always declared |
| 19:23 | <tommorris> | But there is an infinite number of profiles. That's the beauty of them. Distributed extensibility. |
| 19:24 | <Hixie> | tommorris: does your GRDDL support all infinite number of them? |
| 19:24 | <tommorris> | Yes, it is a generic implementation at a library language level. |
| 19:24 | <tommorris> | What people choose to do with it is up to them. |
| 19:24 | <Hixie> | wait what? |
| 19:25 | <Hixie> | tell you what why don't you give me a rundown of what your code does |
| 19:25 | <Hixie> | pretend i know nothing about GRDDL |
| 19:25 | <Hixie> | since apparently i might not |
| 19:25 | <Hixie> | :-) |
| 19:25 | gsnedders | gives Hixie a newbie badge |
| 19:25 | <tommorris> | It takes a URI, it loads the URI, takes a rough stab to see what it is (and makes a decision of either HTML/XHTML or 'generic XML' or 'dunno, I give up') |
| 19:26 | <tommorris> | then if it's XML, it follows the XML parsing rules |
| 19:26 | <tommorris> | if it's HTML/XHTML, it follows the HTML/XHTML parsing rules (basically, runs it through Tidy and loads it in as an XML document) |
| 19:27 | <tommorris> | then it checks to have a look at the @profile attribute, loads each of the URIs listed in the profile attribute and extracts from those URIs the location of an XSLT document |
| 19:28 | <tommorris> | It then runs all the XSLTs found across the document, takes all the outputs and loads them in to an RDF graph and returns a Graph object to the user to do with as they like |
| 19:28 | <Hixie> | ok so there are two problems with that |
| 19:28 | <Hixie> | one is that your output is RDF, so in practice it really doesn't matter what you do :-) |
| 19:28 | <Hixie> | the other is that the target of the profile="" attribute typically doesn't include a link to an XSLT sheet |
| 19:29 | <Hixie> | and it's unlikely that most authors of microformats will include the link to a page that mentions XSLT |
| 19:29 | <Hixie> | (indeed it's unlikely that they'll include any profile links at all) |
| 19:29 | <Hixie> | a better mechanism would be for the user of the GRDDL mechanism to provide all the XSLTs himself |
| 19:29 | <Hixie> | instead of relying on the page's author getting the link right |
| 19:30 | <tommorris> | Most existing GRDDL implementations have a method you can call which allows you to specify some existing XSLTs (or shortcuts thereto) |
| 19:31 | <Hixie> | problem solved then, no need for a profile="" mechanism |
| 19:31 | <tommorris> | Not at all. |
| 19:32 | <tommorris> | That not many people use it properly is not an argument for not letting those who do use it be able to. |
| 19:32 | <Hixie> | actually, for html5, it is |
| 19:33 | <tommorris> | I don't exactly see why. |
| 19:33 | <Hixie> | if most people do something wrong, then we assume the spec is stupid, and fix it. |
| 19:33 | <Hixie> | but anyway here the point is that the grddl user isn't the web page author, presumably, because if he was, then he wouldn't need to have the indirection through the page to declare the profiles |
| 19:34 | <Hixie> | and if it's not the same author, then using profile="" is going to be unreliable by definition |
| 19:34 | <tommorris> | Ah, but often he does because he doesn't want to repeat himself |
| 19:34 | <Hixie> | the use case you are putting forward is fundamentally non-sensical |
| 19:34 | <Hixie> | there no reason to repeat oneself -- only say it once, to the grddl, instead of once in every page (which would be repetition indeed!) |
| 19:35 | <tommorris> | If I want to publish some data on the web and have it parseable in an RDFish kind of way, I can either put it all up in, say, RDF/XML for computers *and* HTML for people - or I can put it up as HTML, with a little "hey, go here and find out how to parse it" instruction at the top and half the amount of data I have to publish |
| 19:35 | <gsnedders> | Hixie: Most people use non-conforming HTML. Can't we fix the spec for that? |
| 19:36 | <Hixie> | gsnedders: we did. we made a massive effort to define how to parse broken html. |
| 19:36 | <Hixie> | gsnedders: and made a number of previously disallowed things allowed. |
| 19:36 | <Hixie> | (where they were harmless) |
| 19:36 | <gsnedders> | Hixie: Then most people will still do something wrong, so we will assume HTML 5 is stupid, and fix it. :P |
| 19:36 | gsnedders | runs away |
| 19:37 | <Hixie> | tommorris: the rdf spec says how to parse rdf right? the html spec says how to parse html? you don't need to declare how to parse them in the file itself? so why do you do that with microformats? |
| 19:38 | <Hixie> | tommorris: the point though is that most people don't include the "how to parse it" instructions, and so any actual use of the data has to know how to parse it anyway, making the instructions moot |
| 19:38 | <tommorris> | in the more common circumstances. |
| 19:38 | <tommorris> | the point is that in niche circumstances, it is quite useful |
| 19:38 | <Hixie> | html5 isn't targetting niche circumstances |
| 19:38 | <tommorris> | and, yes, I've heard the Pareto principle guff, which is a justification to make it only work 80% of the time. ;) |
| 19:38 | <Hixie> | we are explicitly cutting off at 80% |
| 19:39 | <Hixie> | if we didn't, we'd end up with a disaster like docbook. or rdf. |
| 19:39 | <gsnedders> | Hixie: In May, myself, jgraham, and Philip` ended up concluding we'd get rid of the numbers 0 and 9, as we only need to address 80% of use-cases. |
| 19:39 | <Hixie> | gsnedders: then your study of use cases was likely severely flawed |
| 19:40 | gsnedders | blames jgraham |
| 19:40 | <Hixie> | since most people don't use octal |
| 19:41 | <gsnedders> | BTW, http://hg.gsnedders.com/spec-gen/raw-file/tip/README.html — OMG docs! |
| 19:41 | <tommorris> | again, I'm not asking people to use or like GRDDL - just not break our implementations |
| 19:41 | <Hixie> | i'm not breaking your implementations any more than they are already broken |
| 19:41 | <Hixie> | they rely on something that is fundamentally not going to happen regardless of what the spec says |
| 19:41 | <Hixie> | all i'm doing is showing you reality |
| 19:42 | <Hixie> | pulling your head out of the sand, as it were |
| 19:42 | <Hixie> | sorry for being so blunt |
| 19:42 | <tommorris> | it's not a case of "do we make it go away or not?", it's a case of "do we make it work as it does already or do we make it so we have to rewrite them to treat HTML 5 differently from how they do HTML 4/XHTML 1?" |
| 19:43 | <Hixie> | you're missing the best option, which is "do we make it so we have to rewrite them to actually handle all of HTML5/HTML4/XHTML1 in a way that actually works" |
| 19:46 | <Philip`> | gsnedders: In Introduction, "consquently" |
| 19:46 | <Philip`> | gsnedders: Also the colon seems like inappropriate punctuation there |
| 19:46 | <gsnedders> | Philip`: Stop wanting me to spell things correctly! |
| 19:46 | <gsnedders> | :P |
| 19:46 | <gsnedders> | But thanks. |
| 19:47 | <Philip`> | gsnedders: Computers are good at finding such errors :-) |
| 19:47 | <Philip`> | gsnedders: although actually I've never quite worked out how to spell-check sensibly on Linux so I just do it manually :-( |
| 19:48 | gsnedders | lives on spell checking existing on any and every text-field |
| 19:48 | <gsnedders> | But the problem is it breaks badly on HTML source, so I have to turn it off there :( |
| 19:48 | Philip` | likes how Visual Assist does spell-checking of C++ code, by looking in strings and comments |
| 20:00 | gsnedders | is defining the useful stuff to know that the CSS3 module postprocessor doesn't define |
| 20:00 | <gsnedders> | Which is going to end up with the interesting situation of my docs documenting what I implement in compat. mode better than the original docs do. |
| 20:08 | <Hixie> | oops, apologies about the double post just now |
| 20:12 | <gsnedders> | Hixie: What text editor do you use to edit the huge spec.? Do you do the text-wrapping by hand, or by using…? |
| 20:12 | <Hixie> | emacs |
| 20:12 | <gsnedders> | For both? |
| 20:12 | <hsivonen> | looks like emacs isn't deterministic |
| 20:12 | <hsivonen> | sometimes commits rewrap lines for no good reason |
| 20:13 | <Hixie> | i do the line wrapping semi-manually |
| 20:13 | <Hixie> | i have f7 bound to "wrap this paragraph" |
| 20:13 | <Hixie> | so when i do regexp search/replaces, the paragraphs don't get rewrapped unless i explicitly request it |
| 20:14 | <Hixie> | thus what you're seeing |
| 20:15 | <gsnedders> | Hixie: See, I'm always scared when documentation is a 3MB HTML file :) |
| 20:15 | <hsivonen> | ok. makes sense |
| 20:15 | <Hixie> | gsnedders: emacs is a terrible text editor. it can do pretty much anything and is horribly hard to use out of the box. |
| 20:16 | <gsnedders> | The problem is there are no good text editors that can do pretty much anything :( |
| 20:16 | <Hixie> | gsnedders: it also happens to handle multimegabyte files fine (though it chokes once they get into the hundreds of mb) and does very good search/replace and a few other things i need. |
| 20:16 | <hsivonen> | has anyone embedded Gecko inside emacs yet? |
| 20:16 | <Hixie> | i use emacs under screen over ssh |
| 20:16 | <Hixie> | so i wouldn't know |
| 20:16 | <gsnedders> | Hixie: nano deals with all that fine :P |
| 20:16 | <hsivonen> | Emacs W3 isn't that good for browsing the web |
| 20:16 | <hsivonen> | so there are limits to the kitchen sink |
| 20:17 | <Hixie> | hsivonen: i said it could do anything, not that it could do anything well. |
| 20:17 | <Hixie> | gsnedders: nano is ok for little jobs |
| 20:17 | <Hixie> | gsnedders: i couldn't use it to edit the spec tohugh |
| 20:17 | <Hixie> | nano is what i use for config files, etc |
| 20:18 | <gsnedders> | I dunno. Once you set it up right, it's surprisingly powerful. |
| 20:18 | <Hixie> | does it have a shell? |
| 20:18 | <Hixie> | multiple buffers? |
| 20:18 | <gsnedders> | A shell to do what? |
| 20:18 | <Hixie> | a clipboard list? |
| 20:18 | <gsnedders> | Yes |
| 20:18 | <gsnedders> | No |
| 20:18 | <franksalim> | tetris? |
| 20:18 | <gsnedders> | No |
| 20:18 | <gsnedders> | Pong? |
| 20:18 | <gsnedders> | No |
| 20:18 | <hsivonen> | hrm. the multipage sections keep moving |
| 20:19 | <Hixie> | one of the features of emacs i use the most is that you can open a bash shell as a file |
| 20:19 | <gsnedders> | Hixie: Is Tetris the real reason you use emacs? |
| 20:19 | <Hixie> | you can edit the shell just like a file |
| 20:19 | <Hixie> | but it runs commands when you hit enter |
| 20:19 | <Hixie> | i hate tetris :-) |
| 20:19 | <gsnedders> | Hixie: Then pong? |
| 20:19 | <Hixie> | nope |
| 20:20 | <Hixie> | I use M-x count-matches and M-x list-matching-lines a lot too |
| 20:20 | <Hixie> | if i had the time i'd write my own editor |
| 20:20 | <Hixie> | now that i know what i want from it |
| 20:21 | <Hixie> | but it wouldn't be useful for anyone else :-) |
| 20:21 | <Hixie> | Should we come up with an alternative to textContent that handles dir="", <bdo>, <img alt="">, etc? |
| 20:21 | <gsnedders> | Hixie: Yes. |
| 20:22 | <gsnedders> | Actually, no. |
| 20:22 | <gsnedders> | Hixie: You should. |
| 20:22 | <gsnedders> | :D |
| 20:22 | <hsivonen> | aaargh. the spec splitter no longer spits the tokenization section into a standalone file |
| 20:22 | <jcranmer> | vim works better IHMO, but I'm not going to ignite an editor war |
| 20:22 | <Hixie> | hsivonen: speak to Philip` |
| 20:22 | <gsnedders> | jcranmer: That wasn't humble enough. |
| 20:22 | <jcranmer> | er, IMHO |
| 20:22 | <Hixie> | jcranmer: i think both suck, but i could never get into the "mode" mindset that vi uses |
| 20:23 | <hsivonen> | also, something changed about the structure so that Lynx breaks the lines differently |
| 20:23 | <hsivonen> | making diff useless |
| 20:24 | <Philip`> | hsivonen: It's Hixie's fault for changing the section names |
| 20:24 | <Philip`> | Hixie: You need to stop modifying the spec, it messes everything up :-( |
| 20:24 | <Hixie> | hsivonen: i moved the tokenisation section so that each state is its own subsection |
| 20:25 | <Hixie> | so it shows up in the ToC |
| 20:25 | <hsivonen> | Hixie: :-( |
| 20:25 | <Philip`> | It was renamed to "tokenization" which broke the splitter |
| 20:25 | <hsivonen> | Hixie: is there a way to recover the spec plitter output for the tokenizer section from immediately before that change? |
| 20:26 | <Hixie> | rerun the spec splitter on that version i guess |
| 20:26 | <Hixie> | i dunno |
| 20:26 | <Hixie> | i just use Philip`'s web service |
| 20:26 | <hsivonen> | are there docs for the service? |
| 20:27 | <Philip`> | hsivonen: There aren't |
| 20:27 | <hsivonen> | Philip`: any guidance on how to use it? |
| 20:28 | <Philip`> | hsivonen: If you have suitable bits of Python and lxml and html5lib installed, you could hopefully just run <some URL which I'll find in a minute since my internet connection is really slow> |
| 20:28 | <Philip`> | hsivonen: http://html5.googlecode.com/svn/trunk/spec-splitter/spec-splitter.py |
| 20:29 | <hsivonen> | Philip`: thanks. I guess I don't have the deps. I'll have to investigate |
| 20:29 | <gsnedders> | Philip`: It'd be quick to use iter than use findall for things like making refs absolute |
| 20:30 | <hsivonen> | do I need to also run spec gen first to get compatible results? |
| 20:30 | <Philip`> | gsnedders: It takes about a minute to parse the input, so it's already slow enough that minor optimisations will have no practical effect :-) |
| 20:31 | <hsivonen> | zcorpan: I fixed the two parsetree.v.nu issues |
| 20:31 | <gsnedders> | Philip`: IIRC it was a fair difference doing stuff like that |
| 20:31 | <Philip`> | hsivonen: You need to run it on the post-spec-gen "index" file (which should be in SVN) |
| 20:31 | <hsivonen> | Philip`: ok. |
| 20:31 | <gsnedders> | Or you can help find bugs in my spec-gen :P |
| 20:32 | <Philip`> | hsivonen: If you don't have the relevant dependencies, but you know what revision number you're interested in, I could convert it manually |
| 20:33 | <hsivonen> | Philip`: I'm interested in rev 1905 and 1906 |
| 20:34 | <Hixie> | those changed nothing of substance |
| 20:34 | <Hixie> | for r1906, i did the diff locally using -w |
| 20:35 | <Hixie> | and there was nothing except the <dt>s turning into <h5>s |
| 20:35 | <Hixie> | (and i missed one, which got fixed later) |
| 20:35 | <hsivonen> | Hixie: right, so first I need to diff my baseline against 1905. then I need to make 1906 my baseline and diff it agaist the latest version |
| 20:36 | <Hixie> | ah, makes sense |
| 20:37 | <gsnedders> | Is http://hg.gsnedders.com/spec-gen/raw-file/tip/README.html#cross-referencing-0 good enough docs? |
| 20:37 | <Philip`> | (I've updated the online spec-splitter so it should split on "tokenization" correctly now) |
| 20:37 | <gsnedders> | (for that section, for xref) |
| 20:39 | <Hixie> | thanks Philip` |
| 20:40 | <Philip`> | hsivonen: Downloading those revisions now |
| 20:41 | <Hixie> | gsnedders: looks good to me |
| 20:41 | <hsivonen> | Philip`: thanks |
| 20:41 | <Hixie> | not sure about the white-on-red styling though :-) |
| 20:41 | <Hixie> | or white-on-blue :-) |
| 20:42 | <gsnedders> | Hixie: The white-on-red and white-on-blue is all editorial :) |
| 20:42 | Hixie | sees the make install step and prays it doesn't require him to be root |
| 20:43 | <gsnedders> | (white-on-red is span:not([title=""]):not(.secno) and white-on-blue is a:not([href])) |
| 20:43 | <Philip`> | hsivonen: http://philip.html5.org/misc/tokenization-r1905.html http://philip.html5.org/misc/tokenization-r1906.html |
| 20:43 | <gsnedders> | Hixie: The only thing that might require perms. is to install the spec-gen application, by default in /usr/local/bin |
| 20:44 | <Philip`> | gsnedders: "An instance is only used if it does not have a a, dfn, or datagrid element as either a parent or a child." - s/a a/an a/ |
| 20:44 | <hsivonen> | Philip`: thank you |
| 20:45 | <Philip`> | gsnedders: s/dependant/dependent/ |
| 20:45 | <Hixie> | gsnedders: k, i hope i can install it elsewhere :-) |
| 20:46 | <gsnedders> | Hixie: where ever you want :) |
| 20:46 | <Hixie> | :-D |
| 20:46 | <gsnedders> | Hixie: (or at least anywhere you have write perms for :P) |
| 20:47 | <gsnedders> | Philip`: Is dependent preferred in the OED? dependant is the en-gb norm. |
| 20:50 | <Philip`> | gsnedders: If I'm not mistaken, "dependant" is always a noun (like a person who depends on someone), and "dependent" is always the adjective or whatever it is |
| 20:51 | gsnedders | looks up |
| 20:51 | <gsnedders> | Philip`: It's an obsolete spelling of the adjective :P |
| 20:51 | <gsnedders> | Philip`: -ant is obs. adj, and en-gb noun; -ent is adj., an en-us noun |
| 20:57 | <Philip`> | gsnedders: Ah, so I'm right, if you ignore obsolete and American usage, and you should ignore them :-) |
| 20:58 | <hsivonen> | so now Jetty docs say I should be using HTTP and mod_proxy instead of AJP13 and mod_jk starting with Apache 2.2 |
| 20:59 | <hsivonen> | stuff keeps changing all the time |
| 21:00 | <Philip`> | The obsolete versions won't keep changing, so you could stick with them |
| 21:01 | <hsivonen> | at least AJP13 still works even though Jetty docs say it is less performant |
| 21:01 | <hsivonen> | (but the bottle neck is Schematron anyway) |
| 21:02 | <hsivonen> | and I only need standard HTTP methods, so AJP13 doesn't limit me that way |
| 21:03 | <hsivonen> | nn |
| 21:30 | <gsnedders> | Hmm. |
| 21:30 | <gsnedders> | Should program options be in a code element? |
| 21:30 | gsnedders | thinks so |