| 00:04 | <sayrer> | gsnedders, http://wiki.ecmascript.org/doku.php?id=es3.1:es3.1_proposal_working_draft |
| 00:12 | <sayrer> | Hixie, why do keep tearing down RDFa? Why do you Creative Commons so much? |
| 00:13 | <sayrer> | Why do you hate Creative Commons so much? |
| 00:13 | <Hixie> | sayrer: should i add rdfa to html5? |
| 00:14 | <sayrer> | Yahoo! supports it. So does Obama. |
| 00:14 | <Hixie> | that doesn't answer my question :-) |
| 00:15 | <sayrer> | My opinion is archived, let me dig up a hypertext reference |
| 00:17 | <sayrer> | Hixie, http://lists.w3.org/Archives/Public/www-tag/2009Feb/0328.html |
| 00:17 | <Hixie> | is that a "yes" or a "no"? i don't understand |
| 00:17 | <sayrer> | it's a "doesn't matter" |
| 00:18 | <sayrer> | which is different than "I don't care" |
| 00:18 | <sayrer> | even if I had an opinion, putting it in HTML5 would do nothing |
| 00:18 | <Hixie> | your opinions are very confusing |
| 00:18 | <Hixie> | much like rdfa itself :-) |
| 00:18 | <jcranmer> | RDF must burn in hell |
| 00:19 | <jcranmer> | RDFa sounds too much like RDF |
| 00:19 | <sayrer> | how about this: If it were my document, I wouldn't put it in |
| 00:19 | <sayrer> | Hixie, does that work? |
| 00:19 | <Hixie> | sayrer: so i should't add rdfa to html5? |
| 00:19 | Philip` | finds jcranmer's opinions refreshingly clear |
| 00:19 | <Hixie> | i thought you did have a document that was html5 now :-) |
| 00:19 | <sayrer> | mine is called HTML 2010, I think |
| 00:19 | <sayrer> | still trying not to be confusing |
| 00:20 | <Philip`> | C++0x should have taught the world not to put future dates in standard names |
| 00:20 | <jcranmer> | it should be released in late 2009 |
| 00:20 | <Philip`> | even if the resolution is limited to a decade |
| 00:20 | <sayrer> | I don't expect any title I pick will be the name of a standard |
| 00:20 | Hixie | still plans to reach last call in 2009 :-) |
| 00:21 | <Philip`> | jcranmer: Sounds like they're cutting it a bit close :-) |
| 00:21 | <jcranmer> | now, if only I could convince those arguing about whether or not <time> needs to support non-Gregorian calendars that 99.99% of users don't care |
| 00:22 | <Hixie> | jcranmer: have actual use cases been mentioned in that thread? |
| 00:22 | <Hixie> | i lost track a few days ago |
| 00:22 | <roc> | yes |
| 00:22 | <Hixie> | ok good |
| 00:22 | <sayrer> | In HTML 2010, there is no <time> |
| 00:22 | <sayrer> | eventually it will float |
| 00:22 | <Hixie> | sayrer: so what element should microformats use? |
| 00:22 | <jcranmer> | I think people were talking about something like mentioning dates for old Parliamentary records or something |
| 00:23 | <jcranmer> | Hixie: <doesitreallymatter> |
| 00:23 | <Hixie> | jcranmer: why won't plain text do for that use cases again? |
| 00:23 | <roc> | for example, a history of Central America written in the Mayan calendar |
| 00:23 | <sayrer> | microformats are a so far unsuccessful experiment |
| 00:23 | <Hixie> | wow, sayrer and i are two for two on agreeing on things today |
| 00:24 | <sayrer> | I like that SGML people idenitified them as "architectural forms" and said they wouldn't catch on |
| 00:30 | <Hixie> | i wonder what the benefit of marking a string in rdf as a particular type is |
| 00:31 | <Hixie> | and what the expected behaviour is when the type given -- e.g. ISO8601 date -- doesn't match the actual type -- e.g. RFC822 date |
| 00:32 | <sayrer> | no need to wonder, surely there are RSS 1.0 instances of that exact example |
| 00:33 | <sayrer> | answer: don't use and RDF parser |
| 00:33 | <Hixie> | 75% |
| 00:33 | <sayrer> | don't use an RDF parser |
| 00:33 | <Hixie> | i meant the theoretical answer of rdf types |
| 00:33 | <Hixie> | s/types/people/ |
| 00:34 | <sayrer> | oh they never answer stuff like that, afaik |
| 00:35 | sayrer | has Atom flashbacks |
| 00:35 | <Hixie> | maybe i should introduce a simple syntax for giving structured data that can be used by both the microformats and rdfa crowds, and we can drop <time> at the same time |
| 00:35 | <Philip`> | http://developer.search.yahoo.com/help/objectfinder?url=http%3A%2F%2Fphilip.html5.org%2Fdemos%2Frdfa%2Fmisc03.html |
| 00:35 | <Philip`> | See numbers 6 and 7 |
| 00:36 | <sayrer> | Hixie, if the syntax resulted in a rendering, that might work |
| 00:36 | <Philip`> | It looks like it's handling <b><i></b></i> like how HTML5 says |
| 00:36 | <Hixie> | Philip`: holy crap, i was about to say, that's an html5 parser |
| 00:38 | <Philip`> | "Mozilla/5.0 (compatible; Yahoo! SearchMonkey 1.0; http://developer.yahoo.com/searchmonkey/useragent)"; |
| 00:38 | <Philip`> | http://developer.yahoo.com/searchmonkey/useragent - "Sorry, the page you requested was not found." |
| 00:38 | <sayrer> | http://developer.yahoo.com/searchmonkey/smguide/overview.html |
| 00:39 | Philip` | wonders if SearchMonkey uses a different parser to the real Yahoo search |
| 00:39 | <Philip`> | ...e.g. html5lib |
| 00:39 | <sayrer> | http://developer.yahoo.com/searchmonkey/smguide/datarss.html |
| 00:39 | <sayrer> | what could be simpler? |
| 00:52 | <Hixie> | ooh, i did the whole Browsers section in a few hours |
| 00:52 | <Hixie> | time for a break |
| 01:06 | <Lachy> | Hixie, yt? |
| 02:18 | <Hixie> | Lachy: here |
| 08:16 | <hsivonen> | heh. yesterday I thought about writing tests to discover if Y! *really* implements RDFa. It seems now I don't need to. |
| 08:23 | <MikeSmith> | hsivonen: how come? |
| 08:30 | <hsivonen> | MikeSmith: according to IRC logs, Hixie and Philip` already did the testing |
| 08:31 | <MikeSmith> | hsivonen: ah, OK |
| 08:33 | <hsivonen> | interestingly, of the things I've blogged about on hacking Gecko code, the report on a patch that never got in has generated the largest number of interested email from the developers of other apps (the post about the OS X clipboard) |
| 08:43 | zcorpan | wonders whether someone has pointed out that firefox already has the feature that's being discussed in the 'view source' thread |
| 08:43 | <zcorpan> | it's called "view selection source" |
| 08:43 | <hsivonen> | zcorpan: it has been pointed out in previous threads on the topic, IIRC |
| 08:45 | <zcorpan> | hsivonen: doing safe "pretty"-printing will probably make it more ugly if the original source is already half-pritty-printed |
| 08:45 | <roc> | someone should point it out again |
| 08:45 | <roc> | "bags not" |
| 08:47 | <zcorpan> | hsivonen: a more useful pretty-printing is a tree view that hides whitespace-only text nodes |
| 08:48 | zcorpan | has played around with css transitions this morning and found that it was surprisingly hard to get a simple menu working acceptably |
| 08:48 | <zcorpan> | things i'd like to change |
| 08:49 | <zcorpan> | * make height:0 and height:0px both work |
| 08:49 | <zcorpan> | * make 'display' an animatable property (that just flips to the new value at the end of the transition) |
| 08:50 | <zcorpan> | * make height:auto work by using the computed value |
| 08:50 | <jgraham> | Didn't Mozilla used to implement "View Source" as "View DOM Tree" but changed because people complained? |
| 08:51 | <jgraham> | I think the whole idea of reccommending UA features to match some political goals of the W3C is slightly absurd |
| 08:51 | <zcorpan> | * make text-shadow not affect layout (unrelated to transitions but anyway) |
| 08:52 | <hsivonen> | zcorpan: a tree view doesn't solve the issue of wanting authors to copy and paste reseriazed markup |
| 08:53 | <hsivonen> | zcorpan: but I suppose a "clean" view could mess with text node contents and say "tough" to scripts that break |
| 08:54 | <MikeSmith> | jgraham: I would not at all be surprised if many people objected to "View DOM Tree" |
| 08:55 | <MikeSmith> | since many probably have no idea what it means |
| 08:55 | <jgraham> | MikeSmith: The point is that it was called "View Source" but implemented as a serialization of the DOM tree |
| 08:56 | <MikeSmith> | ah |
| 08:57 | <MikeSmith> | well, it definitely shouldn't be called "View Source" if it's not showing the actual source |
| 08:57 | <jgraham> | hsivonen: If you are going down this road, allowing authors to select anything other than a complete subtree is obviously wrong so you could just add a copy function to firebug/dragonfly/etc that copied a serialized view of the subtree under the node |
| 08:57 | <MikeSmith> | maybe it should be "View Raw" and "View Cooked" |
| 08:57 | zcorpan | remembers a moz bug where view source didn't match what came from the network, apparently an artifact of how source highlighting was implemented |
| 08:58 | <zcorpan> | maybe something like <foo<bar> showed up as <foo><bar> |
| 08:59 | <jgraham> | Maybe I am just remembering what zcorpan is talking about and it wasn't a total reserialization |
| 09:00 | <jgraham> | In any case View Source shoud do exactly what it says on the tin |
| 09:00 | <hsivonen> | zcorpan: I expect reimplementing source highlighting to be "fun" |
| 09:01 | <zcorpan> | hsivonen: will you highlight syntax errors? :) |
| 09:01 | <hsivonen> | zcorpan: very unlikely |
| 09:02 | <zcorpan> | too bad :( |
| 09:02 | <roc> | zcorpan: how does text-shadow affect layout? are you just talking about potentially adding scrollbars? |
| 09:03 | <zcorpan> | roc: yes |
| 09:03 | <roc> | why do you care? I'm curious |
| 09:03 | <roc> | (we have a plan to make text-shadow and other things not affect layout) |
| 09:04 | <roc> | jgraham: I don't think View Source ever did "View DOM Tree", but it did do "View Document Reloaded From Server" which a lot of people complained about |
| 09:04 | <zcorpan> | roc: in my case, i have overflow:hidden on submenus to make a css transition. when tabbing through the links, the menu moves because of text-shadow |
| 09:04 | <roc> | hmm |
| 09:04 | <zcorpan> | roc: i solved it with padding and negative margin, though |
| 09:05 | <roc> | I wouldn't have thought text-shadow would cause a layout change in conjunction with overflow:hidden |
| 09:05 | <hsivonen> | zcorpan: actually, since the plan is to generate a second tokenizer for view source, I suppose it would be OK to run additional code for highlighting parse errors |
| 09:05 | <hsivonen> | zcorpan: I just don't want that code in the tokenizer that runs when people browse the Web |
| 09:05 | <roc> | I think you'll want to highlight syntax errors, since we currently do and we wouldn't want to regress that |
| 09:06 | <hsivonen> | roc: what's highlighted except />? |
| 09:07 | <roc> | hmm, maybe nothing |
| 09:08 | <zcorpan> | hsivonen: <!doctype<, <foo<bar |
| 09:08 | <roc> | I assumed there was more than just that |
| 09:08 | <hsivonen> | ok |
| 09:08 | <roc> | I guess tokenizer errors are highlighted |
| 09:09 | <zcorpan> | <foo/bar> |
| 09:09 | <roc> | anyway it's useful :-) |
| 09:10 | <zcorpan> | or maybe <foo bar/baz> |
| 09:10 | <roc> | it would be really useful if you had different colors for hard errors and soft errors :-) |
| 09:10 | <hsivonen> | roc: for what definitions of hard and soft? |
| 09:10 | <zcorpan> | hsivonen: could you blink <blink> tags? :) |
| 09:11 | <roc> | no, he could not |
| 09:11 | <roc> | URI attributes should still be turned into links though |
| 09:12 | zcorpan | wonders whether <?xml-stylesheet href="..."?> is auto-linked |
| 09:13 | <zcorpan> | apparently not |
| 09:13 | <zcorpan> | hsivonen: what will be used for xml view source? |
| 09:14 | <hsivonen> | zcorpan: that's a hard question. one possibility is the HTML5 tokenizer with a bogo tree builder |
| 09:15 | <hsivonen> | zcorpan: as I understand it, currently the HTML tokenizer is used for XML view source |
| 09:15 | <zcorpan> | yeah |
| 09:16 | <hsivonen> | having an XML5 tokenizer would help :-) |
| 09:16 | <roc> | I thought HTML5 distinguished error types but I must be wrong |
| 09:16 | <hsivonen> | particularly, having one for which a second view source tokenizer can be autogenerated :-) |
| 09:17 | <hsivonen> | roc: there are parse errors, other machine-checkable conformance errors and non-machine-checkable conformance errors |
| 09:17 | <zcorpan> | roc: it did in the early days where hard erros were errors with undefined error recovery (i.e. before hixie figured out what to do with what is now AAA) |
| 09:17 | <hsivonen> | roc: I think parse errors is the only class of errors for which it makes sense to ship checking in Firefox |
| 09:18 | <hsivonen> | roc: I'd put other machine-checkable errors in an extension if it were up to me |
| 09:18 | <roc> | depends on what you mean by errors |
| 09:18 | <hsivonen> | roc: since that would basically be a GWT port of Validator.nu |
| 09:18 | <roc> | there are certain kinds of "errors" that you can only really catch in the layout engine |
| 09:19 | <roc> | if you want to catch the ones that arise due to script execution |
| 09:19 | <zcorpan> | hsivonen: it would be nice with tree-builder-level errors (in particular highlighting unexpected end tags) |
| 09:20 | <hsivonen> | zcorpan: that would require duplicating all the trickery Validator.nu used for highlighting those, but it would be possible |
| 09:20 | <hsivonen> | roc: do you mean checking validity at a user-chosen point in time or performing continuous validation as scripts run? |
| 09:25 | <roc> | the latter |
| 09:26 | <hsivonen> | roc: I see. on the face of it, it seems like a perf problem or at least a non-trivial feature implementation-wise |
| 09:26 | <roc> | it depends |
| 09:27 | <roc> | our CSS warnings are a bit of a perf problem sometimes |
| 09:29 | <hsivonen> | roc: I'm not even sure I'd want to validate as scripts run; only when spinning the event loop, and at that point one would need to remember the mutation points or pay the price of revalidating the whole DOM |
| 09:30 | <roc> | ah |
| 09:31 | <roc> | I'm thinking about places in the code where we already find things that are clearly errors and reject them |
| 09:31 | <roc> | not general DOM tree conformance rules |
| 09:31 | <hsivonen> | otherwise, authors would have to be careful to perform their tree mutations in the right order to keep things valid after each individual DOM operation |
| 09:31 | <hsivonen> | I see |
| 12:14 | <MikeSmith> | hsivonen: please ping me when you around |
| 12:15 | <hsivonen> | MikeSmith: ping |
| 12:16 | <MikeSmith> | hsivonen: so I've been invited to do a sort of speaking tour in a few cities in Australia in May |
| 12:17 | <MikeSmith> | to university audiences |
| 12:18 | <MikeSmith> | graduate/research-oriented folk |
| 12:18 | <MikeSmith> | I want to cover some of the work going on around HTML5 |
| 12:19 | <MikeSmith> | so was thinking to talk about your work on validator.nu |
| 12:19 | <MikeSmith> | by proxy |
| 12:20 | <hsivonen> | MikeSmith: would you like to remix my slides? |
| 12:21 | <MikeSmith> | yeah, that was what I was going to ask |
| 12:21 | <hsivonen> | I'll dig up my original files. all in proprietary formats, though... |
| 12:24 | <MikeSmith> | hsivonen: any format fine by me |
| 12:25 | <MikeSmith> | I might want to hit you up for some "lessons learned" info about your work on integrating an html5 parser in gecko |
| 12:25 | <MikeSmith> | also |
| 12:31 | <hsivonen> | MikeSmith: http://hsivonen.iki.fi/validator-nu-slides.zip |
| 12:31 | <hsivonen> | MikeSmith: in shiny Cocoa app lock-in formats |
| 12:33 | <hsivonen> | MikeSmith: the very short version of lessons learned is: |
| 12:33 | <hsivonen> | * Translating Java to C++ is the easy part |
| 12:34 | <hsivonen> | * Writing Java and translating it is a pretty nice way to write C++ |
| 12:34 | <hsivonen> | * There are more places in a browser that depend on the HTML parser than you'd think |
| 12:34 | <hsivonen> | * Nested scripts are hard |
| 12:35 | <hsivonen> | * HTML character encoding stuff is worse than it appears |
| 12:36 | <MikeSmith> | hsivonen: thanks |
| 12:36 | <hsivonen> | * Usual software project issues apply: goalposts move, polish takes time |
| 12:37 | <hsivonen> | * Learning about the internals of a huge system takes time; mxr necessary in the absence of Eclipse's code comprehension tools |
| 12:37 | <hsivonen> | * Valgrind rocks |
| 12:38 | <hsivonen> | those are my first thoughts |
| 12:38 | <hsivonen> | of course, garbage collectors rock, too, because with them you don't need Valgrind unless you are the person writing the collector |
| 12:39 | zcorpan | wonders what the second time means in transition:visibility 2s 1s; |
| 12:49 | <Lachy> | zcorpan, delay |
| 12:50 | <Lachy> | so the transition will begin 1s after the property is changed, and transition over a 2s duration |
| 12:58 | <zcorpan> | ah |
| 12:59 | <zcorpan> | ok but what does the second time mean in transition-duration:2s 1s? |
| 13:01 | <hsivonen> | Does Flash talk to AT anywhere other than Windows? |
| 13:01 | <Lachy> | zcorpan, the duration for the second property specified using transition-property. |
| 13:02 | <Lachy> | e.g. transition-property: color, background; transition-duration: 1s, 2s; |
| 13:03 | <zcorpan> | oh i missed the comma in the grammar |
| 13:08 | <zcorpan> | ok so if i have div { transition:visibility 1s } div:hover { visibility:hidden } |
| 13:08 | <zcorpan> | after how long should the div become hidden and visible when hovering and removing hover? |
| 13:09 | <Lachy> | then the visibility will transition from visible to hidden. But since there are only two states, it depends on the timing function and decimal rounding. |
| 13:10 | <Lachy> | so with linear timing function, it should be after about 0.5s, when the calculation starts round down to 0 instead of back up to 1 |
| 13:10 | <Lachy> | at least, that's how I understand it |
| 13:11 | <Lachy> | we have some test cases internally that you can take a look at to see it in action |
| 13:35 | MikeSmith | gets back from dinner |
| 13:47 | <MikeSmith> | hsivonen: I like the "Valgrind rocks" part especially |
| 13:48 | <MikeSmith> | and "Writing Java and translating it is a pretty nice way to write C++" is an interesting point too |
| 13:50 | <MikeSmith> | the fact that it's actually practical |
| 13:52 | <hsivonen> | It depends on what kind of Java the Java code is, though |
| 13:52 | <hsivonen> | this code is made with an eye towards translation to C++ and JS |
| 14:14 | <MikeSmith> | hsivonen: yeah, understood |
| 14:14 | <MikeSmith> | still, even given that, that fact that it's practical at all is notable |
| 14:54 | <rubys> | hisvonen: re: "an eye towards translation to C++", for some values of C++ perhaps. :-) |
| 14:54 | <rubys> | example: the code generated today depends heavily on the mozilla classes and on assumptions like utf-16. |
| 14:55 | <jgraham> | rubys: Is it the code generated that depends heavilly on those assumptions or the code generating? |
| 14:56 | <jgraham> | Because the former seems less of a problem than the latter |
| 14:56 | <rubys> | the former, but it makes it rather difficult for somebody else to pick up from there and take it in a different direction. |
| 14:56 | <rubys> | at least for this someone :-) |
| 14:56 | <annevk> | but you could hack the translator maybe? |
| 14:57 | <jgraham> | rubys: I would have thought that e.g. a notional v.nu -> python translation would en up depending a lot on python APIs and the Python string type in particular |
| 14:57 | <rubys> | I generally don't give up easily, and that was my thoughts, but it looked too difficult (read: more than a weekend project to get even small results) for me at the time. |
| 14:58 | <rubys> | jgraham: that's exactly what I want to be working on. |
| 14:58 | <jgraham> | rubys: I know :) |
| 14:58 | <jgraham> | (which would be really cool btw) |
| 14:59 | <rubys> | I was hoping that hsivonen was still around. Because a command line tokenizer that worked with the mozilla class libraries might be something smaller that, if I saw how that worked, I could start with. |
| 14:59 | <rubys> | by that I mean, just the tokenizer. The rest could be added in a second pass. |
| 15:00 | <rubys> | A third pass could be pythonic (elementtree, etc) |
| 15:01 | <jgraham> | You could probably hook a standalone tokenizer in to html5lib fairly easilly |
| 15:02 | Philip` | still kind of likes his OCaml tokeniser generator :-) |
| 15:02 | <jgraham> | s/n t/nt/ |
| 15:02 | <Philip`> | (though it doesn't currently generate Python, only C++ and JS and Perl) |
| 15:02 | <rubys> | Philip`: does it pass the HTML5 tests? |
| 15:02 | <Philip`> | rubys: Some versions have passed all the tokeniser tests at some point in the past |
| 15:03 | <rubys> | just the tokenizer tests? That's somewhat less interesting. |
| 15:03 | jgraham | wonders how it could pass other tests without implementing a treebuilder |
| 15:03 | <Philip`> | It's a tokeniser, so it's not going to run any non-tokeniser tests :-) |
| 15:04 | <rubys> | I'm interested in a tree builder. |
| 15:04 | <Philip`> | I have half of an OCaml tree builder generator, but that's not enough to actually be useful :-( |
| 15:05 | <jgraham> | Philip`: Generating C++ is more useful than generating python if you can make python run that C++ |
| 15:05 | <jgraham> | (unless the generated python is better than html5lib) |
| 15:06 | <rubys> | generating python may be useful for other implementations of python (jython, pypy, etc) |
| 15:06 | <Philip`> | (By "better", do you mean "faster"?) |
| 15:07 | <jgraham> | Philip`: Faster would be one criterion, yes |
| 15:07 | <rubys> | What appeals to me about Henri's is that it is likely to be maintained, so even if it isn't a better match technically, it appears to be the one to bet on. |
| 15:07 | <Philip`> | (If so, I'm not sure how to make it faster, since I've not seen any easily fixable bottlenecks in html5lib, and can't think of alternative ways of writing the code that would make it much faster) |
| 15:08 | Philip` | 's OCaml stuff is very much unmaintained, but he thinks it's a fun toy :-) |
| 15:09 | Philip` | hopes a pure-Python html5lib will always exist, because it's often a pain to use impure modules |
| 15:09 | <Philip`> | (e.g. in sandboxed environments where you can't use binary modules) |
| 15:09 | <annevk> | or they ship a native version with Python |
| 15:10 | <rubys> | annevk: +1 |
| 15:11 | <rubys> | to get it to ship with python, it might be helpful to move past "draft" stage at some point that's still useful. |
| 15:13 | <Philip`> | annevk: People still use Python 2.3 today, so having it added in Python 2.7 won't solve all the problems until many years in the future |
| 15:14 | <annevk> | in that case they might not care whether html5lib is still maintained |
| 15:14 | Philip` | is thinking of things like Google App Engine, which are likely to be frozen at a particular version for a long time |
| 15:14 | <zcorpan> | Lachy: the spec already defines how to mutate the dom to make it xml-compatible |
| 15:14 | <rubys> | This group seems to have some good contacts at Google. |
| 15:15 | <Philip`> | Has anyone pointed out that a document like <script>document.write('x')</script> is impossible to serialise to a DOM that will be parsed back into the same DOM? |
| 15:16 | <Philip`> | (Well, impossible for a generic algorithm to serialise) |
| 15:16 | <annevk> | or <script>document.body.appendChild(document.createElement("img"))</script> |
| 15:16 | <annevk> | not sure anyone did that yet |
| 15:20 | <zcorpan> | you could have a view source that does a parse and serialize with no scripting support |
| 15:21 | <Lachy> | zcorpan, http://www.whatwg.org/specs/web-apps/current-work/#xml-fragment-serialization-algorithm defines that for things that would cause well formedness errors, throw an INVALID_STATE_ERR exception |
| 15:22 | <Philip`> | zcorpan: That would break pages like <script>document.write('<table>')</script><tr><td>foo |
| 15:22 | <zcorpan> | Lachy: i was referring to http://www.whatwg.org/specs/web-apps/current-work/multipage/tree-construction.html#coercing-an-html-dom-into-an-infoset |
| 15:22 | <zcorpan> | Philip`: yes |
| 15:23 | <Lachy> | oh, I wasn't aware of that section |
| 15:30 | <sayrer> | maybe it should be written in RPython |
| 15:56 | <hsivonen> | rubys: the UTF-16 assumption is pretty contained |
| 15:56 | <hsivonen> | rubys: have you found issues where I assume the environment to be too Gecko-like not to be really pluggable? |
| 15:59 | <hsivonen> | I think by far the biggest deal with making the generator target a new environment is writing the IO driver |
| 16:00 | <hsivonen> | I like to think that my most Gecko-specific assumption so far is that namespaces are primitives that don't need releasing |
| 16:01 | <hsivonen> | and that assumption is easy to change. It's just a bridge I haven't had a need to cross with Gecko |
| 16:02 | <hsivonen> | Philip`: I assumed that a reserializing-based cleanup wouldn't run scripts but would parse in the scripting on mode and then set the innerHTML of each <noscript> element to its textContent |
| 16:03 | <zcorpan> | hsivonen: why the last step? |
| 16:04 | <hsivonen> | zcorpan: to get end tags and quoted attributes for stuff inside <noscript> without actually letting the contents leak into the outside tree building |
| 16:05 | <hsivonen> | zcorpan: it's quite possible that I'm missing something that I should have thought about regarding <noscript>... |
| 16:07 | <zcorpan> | doesn't the <noscript>.innerHTML setter set the content model flag to CDATA? |
| 16:07 | <hsivonen> | zcorpan: good point. that step would need to fake the context node for the purposes of the algorithm |
| 16:09 | <annevk> | "The response to the request can be found under a different URI and SHOULD be retrieved using a GET method on that resource." why SHOULD?! meh |
| 16:09 | <annevk> | -- http://www.ietf.org/rfc/rfc2616 |
| 16:10 | <zcorpan> | what about <noembed>, <iframe>, etc? |
| 16:10 | <Philip`> | annevk: Because you might have valid reasons for not retrieving the resource under that different URI |
| 16:11 | <annevk> | Philip`, true, but the SHOULD also applies to the type of method |
| 16:11 | <annevk> | Philip`, which is the part I don't like |
| 16:14 | <Philip`> | annevk: I'm kind of assuming it intends something like "you SHOULD retrieve the resource, and if you do then you MUST use GET" |
| 16:14 | <Philip`> | though that's not what it actually says |
| 16:14 | <annevk> | right |
| 16:14 | <hsivonen> | zcorpan: <noembed> might need the same treatment |
| 16:14 | <hsivonen> | zcorpan: <iframe> probably not |
| 16:14 | <zcorpan> | why not? |
| 16:14 | <annevk> | there is only a single parse mode for <iframe> |
| 16:15 | <zcorpan> | not in opera, but i fail to see how that matters |
| 16:23 | <zcorpan> | it can contain markup intended for browsers that don't support iframes |
| 16:23 | <annevk> | then <style> and <script> should be required to use <!-- and such |
| 16:23 | <annevk> | <iframe> should probably be required to be empty |
| 16:23 | <hsivonen> | zcorpan: the spec doesn't provide for user toggling iframes on and off |
| 16:23 | <zcorpan> | hsivonen: it doesn't for noembed, either |
| 18:53 | <Hixie> | http://www.reddit.com/r/technology/comments/85acf/microsoft_is_ignoring_web_standards_and_should/c08agbv |
| 18:59 | Philip` | wonders where the idea of an "obligation to promote competition" comes from |
| 19:03 | <Hixie> | not that anyone cares, but our cats are ridiculous. http://junkyard.damowmow.com/380 he's been lying there for about 10 minutes now. |
| 19:03 | <Hixie> | he's fine, in case anyone wonders. he just likes to lie down like that. |
| 19:04 | <rubys> | citing wikipedia always gives an air of truthiness to any statement. |
| 19:06 | <gsnedders> | Hixie: But is their ridiculousness news? |
| 19:07 | <gsnedders> | Hixie: Also, why do I think the guy who wrote that comment failed to realize you read reddit? |
| 19:07 | <zcorpan> | rubys: http://uncyclopedia.wikia.com/wiki/Proof#Proof_by_Wikipedia |
| 19:09 | <rubys> | bookmarked here: http://intertwingly.net/blog/2009/03/13/HTML5-Evolution#c1237317281 |
| 19:10 | <Philip`> | http://www.imdb.com/title/tt0751831/ - everyone trusts IMDB |
| 19:11 | <annevk2> | rubys, are you asserting Hixie edited Wikipedia to state that the episode "was first broadcast 13 February 1986"? :p |
| 19:12 | <Philip`> | "In stage one we say nothing is going to happen. Stage two, we say something may be about to happen, but we should do nothing about it. In stage three, we say that maybe we should do something about it, but there's nothing we *can* do. Stage four, we say maybe there was something we could have done, but it's too late now." |
| 19:12 | <Philip`> | (says http://www.imdb.com/title/tt0751831/quotes) |
| 19:12 | <rubys> | When I wrote that page, it never occurred to me that the value for x in 198x was the most important issue to be discussed. Go figure. |
| 19:14 | <Philip`> | Bikeshedding isn't about discussing "the most important issue", it's about discussing something that's easy to express a view on |
| 19:14 | <gsnedders> | (also, the least important issue) |
| 19:14 | <Philip`> | (No, there are many far less important issues) |
| 19:15 | <gsnedders> | (Also, we can conclude that nothing important is ever discussed in the HTML WG, because we only ever paint bikesheds) |
| 19:15 | <rubys> | (( O RLY? )) |
| 19:17 | <Philip`> | (I could argue that it's more a case of intelligent design than of evolution) |
| 19:17 | <Philip`> | (where 'intelligent design' means 'design by intelligent beings', not that it was actually designed intelligently) |
| 19:34 | <Hixie> | gotta love people saying that html5 isn't extensible given how many extension mechanisms we have |
| 19:35 | <sayrer> | I think you could just remove the stated purpose of data- |
| 19:35 | <sayrer> | then you have a CSS like mechanism |
| 19:36 | <Philip`> | But you don't have any way to prevent collisions |
| 19:36 | <Hixie> | i don't think that would work well. but when i get around to looking at the rdfa use cases next month i expect (based on what rdfa proponents have said) that there will be enough of an argument there to add something for the embedded data space, either rdfa or something like that |
| 19:36 | <gsnedders> | RDFa is really weird. |
| 19:36 | <Hixie> | (there are big differences between data-*'s use case, and the use case for rdfa, and i don't think it makes sense to use the same technology for both) |
| 19:36 | gsnedders | was reading up on it a few days ago, and it really is weird |
| 19:36 | <Philip`> | gsnedders: Data is really weird |
| 19:37 | <gsnedders> | RDFa is a lot weirder than RDF |
| 19:37 | <sayrer> | Hixie, what are the differences? |
| 19:37 | <gsnedders> | (or rather RDF/XML) |
| 19:37 | <rubys> | have you looked at RDF/XML ? |
| 19:37 | <rubys> | It is *very* weird. People (thankfully) only tend to use a small subset of it. |
| 19:37 | <gsnedders> | rubys: Who? |
| 19:37 | <gsnedders> | Me? |
| 19:37 | <rubys> | gsnedders: you |
| 19:38 | <sayrer> | http://www.imc.org/atom-syntax/mail-archive/msg11957.html |
| 19:38 | <gsnedders> | I have, and I have to agree that parts are weird, but that said, I think RDFa tends to be weirder than RDF/XML. |
| 19:38 | <Hixie> | sayrer: rdf-like data tends to form a graph, or at the very least, name/value pairs with duplicates, with names from multiple sources |
| 19:38 | <Philip`> | RDFa seems to be designed to represent the whole of RDF, not just the subset that people generally use |
| 19:39 | <sayrer> | Hixie, ok so it's an involved sort of data |
| 19:39 | <sayrer> | still don't see the problem |
| 19:39 | <Hixie> | sayrer: data-*'s use case is more about element-specific annotations |
| 19:39 | <annevk2> | Philip`, I think RDFa cannot express all either |
| 19:39 | <Hixie> | sayrer: i'm not saying that one couldn't be forced into fitting the other, i just don't think it makes sense |
| 19:39 | <sayrer> | it looks like RDFa is supposed to be element-specific annotations |
| 19:39 | <Hixie> | sayrer: just like you could use XML or JSON for similar purposes, but sometimes one is better |
| 19:40 | <annevk2> | Philip`, from memory I think either Mark Birbeck or Steven Pemberton said it hits about 80% |
| 19:40 | <Hixie> | RDFa isn't a particularly good fit for the annotation use cases either imho |
| 19:40 | <Hixie> | but it is better than data-* in that it isn't describing element-specific annotations, but url-specific annotations |
| 19:40 | <Hixie> | it doesn't matter what element the annotations are on |
| 19:40 | <sayrer> | I agree, I don't see what the problem with letting them use data- would be |
| 19:41 | <Hixie> | (<div about="#bar" property="x" content="y" id="bar"> is equivalent to <div id="bar"></div>...<div about="#bar" property="x" content="y"> for instance) |
| 19:42 | <Hixie> | sayrer: if we were trying to dismiss their use cases, "letting them" use data-* might be fine. but i want to address their use cases in good faith. |
| 19:43 | <sayrer> | ah, we're talking about different problems |
| 19:43 | <sayrer> | they clearly have a bad proposal |
| 19:43 | <sayrer> | I think data- is a fine way to let people try out bad proposals |
| 19:50 | <Philip`> | sayrer: If people tried out a proposal and found that actually it wasn't bad, would they be able to keep using the same syntax or have to transition to something else? |
| 19:51 | <sayrer> | both, as they do in CSS |
| 19:51 | <sayrer> | or maybe the standard would fix a few problems with the data- thing |
| 19:52 | <annevk2> | but then UAs will actually do something with data- attributes which might not be what script authors want (e.g. they'd have to start avoiding certain names, etc.) |
| 19:53 | <Philip`> | Hmm... I wonder if there's a difference in that markup needs widespread usage before it can be judged useful, and widespread usage makes it a pain to throw all that away and start with a new syntax, whereas CSS merely needs one page and one browser in order to give a full demonstration of its value |
| 20:10 | <Hixie> | what anne says is the main reason to avoid using data-* |
| 20:11 | <Hixie> | we don't want to ever end up in a position where data-* isn't safe for authors |
| 20:11 | <rubys> | what authors plan to use data-* today? |
| 20:12 | <Hixie> | i don't want to speak for anyone, but e.g. it would allow dojo to stop using non-standard attributes |
| 20:13 | <rubys> | providing something speculatively in the hopes that somebody else might do something that they show no inclination of doing is not something I think is wise. |
| 20:13 | <Philip`> | I plan to use data-*, because there's been at least two situations where I've added custom attributes (and not cared about validation) |
| 20:14 | <gsnedders> | It would equally allow Anolis to stop abusing @title |
| 20:14 | <gsnedders> | (indeed, it already supports data-anolis-xref in 1.1dev, but that'll change to data-xref) |
| 20:15 | <Philip`> | One of those was in SVG (so HTML's data-* doesn't technically apply) containing some data that would be displayed in a table when you clicked on a node in a graph, and another was to have a formatted tooltip on some images (separately from @title because that can't contain formatting) |
| 20:15 | <zcorpan> | http://www.sitepoint.com/forums/showthread.php?t=593627&highlight=custom+attributes |
| 20:16 | <Philip`> | There's already solutions like http://www.alistapart.com/articles/customdtd/ for adding custom attributes, so the demand seems clear |
| 20:17 | <Hixie> | rubys: there are a number of authors i know of that are using data-* already, i just don't want to speak for them here |
| 20:17 | <Hixie> | it's one of the most well-received features in html5 by web app authors |
| 20:18 | <Hixie> | (which is ironic given that it doesn't do anything!) |
| 20:18 | gsnedders | wonders how hard it'd be to make an html2rfc tool that was properly up-to-date |
| 20:18 | gsnedders | wonders how to implement double spacing after a "." at the end of a sentence |
| 20:19 | <Philip`> | and not after e.g. "e.g."? |
| 20:20 | <gsnedders> | Yeah |
| 20:20 | <gsnedders> | http://unicode.org/reports/tr29/#Sentence_Boundaries has relevance |
| 20:20 | Philip` | has trained himself to get annoyed when people accidentally have sentence-spacing after "e.g." in LaTeX documents |
| 20:20 | <gsnedders> | But RFCs must be US-ASCII |
| 20:20 | <Philip`> | (You have to write "e.g.\ foo" to make it a normal inter-word space instead) |
| 20:20 | <gsnedders> | So it should be a bit simpler |
| 20:20 | <roc> | the upside of not doing anything is that it's already implemented in all browsers |
| 20:21 | <roc> | fewer bugs too |
| 20:21 | <annevk2> | the DOM API is something that browsers would have to support at some point |
| 20:23 | <Philip`> | Hopefully people won't get too confused by trying to use the DOM API before it's supported in all browsers |
| 20:24 | <Philip`> | It seems that the formal blessing of data-* and its ability to avoid validation errors are sufficient reasons for people to be interested in the feature already |
| 21:33 | jgraham | points out that double spacing between sentences is weird typewriter legacy that is totally unneeded |
| 21:34 | gsnedders | points out RFC rules dictate it is required |
| 21:35 | <olliej> | jgraham: double spacing is much nicer to read imo |
| 21:35 | gsnedders | slaps self for speaking on IRC and not doing his computing project that is due in tomorrow |
| 21:35 | <jgraham> | olliej: With proportional fonts? |
| 21:35 | <gsnedders> | (Not that'll be in on time, obviously :D) |
| 21:35 | <olliej> | jgraham: yes |
| 21:36 | <jgraham> | gsnedders: Yeah well IETF takes all its formatting requirements from the typewriter age |
| 21:36 | <gsnedders> | (I mean, the teacher didn't say _when_ it had to be in tomorrow…) |
| 21:37 | <jgraham> | olliej: Curious. I have never found that, and some randomly selected books don't have it so it doesn't seem to be a publishing norm. |
| 21:38 | <gsnedders> | jgraham: Properly printed books shouldn't have double, but shouldn't have a normal space either |
| 21:38 | <gsnedders> | Normal spaces should be between 1/5 and 1/3 em-space, and end-of-sentence space should be nearer 1/2 em-space |
| 21:40 | <gsnedders> | WTF? Half my recent tweets have vanished |
| 21:40 | <jgraham> | Measuring suggests that they are less than 50% larger in my Everyman's Library Uylsses |
| 21:41 | <gsnedders> | I ought to read Ulysses |
| 21:41 | <gsnedders> | (which I assume is what you meant) |
| 21:41 | <john_fallows> | Hixie: the latest EventSource API for SSE looks great - question: is it now illegal to send "open" and "error" event types in an SSE stream because eventSource.addEventListener("open", ...) and eventSource.addEventListener("error", ...) would be ambiguous if this is permitted? |
| 21:42 | <jgraham> | it is a running joke in my house that I have only read the first 500 pages |
| 21:43 | <gsnedders> | Well, according to Wikipedia, some editions are only 644 pages :P |
| 21:43 | <jgraham> | This one is about 1000 |
| 21:43 | <sayrer> | I was sure that HTML5 would end up longer |
| 21:43 | <Philip`> | jgraham: Almost as large as Neal Stephenson's books! |
| 21:44 | <Philip`> | (Actually, Anathema only seems to be 937 pages) |
| 21:44 | <Philip`> | (*Anathem) |
| 21:44 | <Hixie> | john_fallows: it's actually been impossible to set the event name for some time now |
| 21:44 | <gsnedders> | jgraham: So, I take it you've never read Harry Potter? :P |
| 21:44 | <jgraham> | HTML5 is less confusing than Ulysses. But not so well written. |
| 21:44 | <john_fallows> | Hixie: okay, missed that removal from the spec, so we are locked down as message always? |
| 21:45 | <Hixie> | john_fallows: yeah, i believe so |
| 21:45 | <jgraham> | gsnedders: ? |
| 21:45 | <john_fallows> | ok, great - that allieviates any concern, thanks. :) |
| 21:45 | <gsnedders> | jgraham: Some of the Harry Potter books are longer than 500 pages |
| 21:45 | <jgraham> | gsnedders: I have read some books that are longer than 500 pages :-p |
| 21:45 | <jgraham> | (including all of Harry Potter several times over) |
| 21:46 | <gsnedders> | jgraham: In multiple languages? |
| 21:46 | <gsnedders> | (My step-cousin has read the whole thing three times, IIRC, twice in French and once in English) |
| 21:47 | <jgraham> | Not yetN |
| 21:47 | Philip` | only consumed the audio book versions |
| 21:47 | <john_fallows> | Hixie: am i missing something? http://dev.w3.org/html5/spec/Overview.html#processField seems to still have the ability to override the event name if the event field is present. |
| 21:47 | gsnedders | read the entire thing once, in English |
| 21:47 | <gsnedders> | (Admittedly I read most of the books within 48 hours of their release) |
| 21:49 | <olliej> | gsnedders: you read the entire html5 spec? |
| 21:49 | <gsnedders> | olliej: Oh, I've done that too |
| 21:49 | <olliej> | gsnedders: and it's not english man :D |
| 21:49 | <gsnedders> | olliej: We were discussing Harry Potter! Keep up, man! |
| 21:49 | <olliej> | gsnedders: ... |
| 21:50 | <olliej> | gsnedders: is there a <harry> tag now? |
| 21:50 | gsnedders | is blatantly meant to be doing his computing project |
| 21:50 | <gsnedders> | olliej: Only </sarcasm> |
| 21:50 | <olliej> | gsnedders: :D |
| 21:51 | gsnedders | wonders if olliej actually gets that joke |
| 21:52 | <olliej> | gsnedders: that you're meant to be working on a project or the </sarcasm> bit? |
| 21:52 | <gsnedders> | olliej: </sarcasm> |
| 21:52 | <olliej> | nope :D |
| 21:52 | <gsnedders> | olliej: It is actually referenced in the spec. |
| 21:52 | <gsnedders> | olliej: Search for "sarcasm" (with quotes) |
| 21:52 | <olliej> | oh no |
| 21:53 | gsnedders | will discuss almost anything to avoid doing work :P |
| 21:53 | <Hixie> | john_fallows: huh, go figure. |
| 21:54 | <Hixie> | john_fallows: i guess you _can_ send arbitrary events then |
| 21:54 | <Hixie> | john_fallows: i wonder why we still support that |
| 21:54 | <gsnedders> | Also: is it bad that when I got to maths yesterday that I was asked by the girl who I sit beside if I had chosen what dress to wear for the ball? |
| 21:55 | <john_fallows> | Hixie: IMHO this is probably no longer necessary, and as pointed out previously it is also ambiguous for "open" and "error" events. |
| 21:55 | <Hixie> | john_fallows: yeah |
| 21:55 | <Hixie> | john_fallows: can you send mail to the list saying that i should remove it? |
| 21:55 | <john_fallows> | Hixie: would you like me to send email to remind you to remove it? |
| 21:55 | <john_fallows> | :-) |
| 21:56 | <Hixie> | yes please :-) |
| 22:00 | <john_fallows> | Hixie: done. |
| 22:01 | <Hixie> | thanks! |
| 22:01 | <john_fallows> | np. |
| 22:09 | Philip` | sees that john_fallows sadly removed the Harry Potter discussion from the IRC extract he posted to public-html |
| 22:09 | <Philip`> | It might give people the false impression that we have useful, on-topic conversations here |
| 22:12 | <gsnedders> | A dangerous precedent indeed. |
| 22:26 | <Hixie> | 81%! |
| 22:28 | gsnedders | thinks we need a graph of time against % of spec annotated |
| 22:46 | <Hixie> | aaaaaaah |
| 22:46 | <Hixie> | pimpmyspec.net is down |
| 22:49 | <gsnedders> | Install anolis locally! |
| 22:49 | gsnedders | ducks |
| 22:49 | gsnedders | quacks |
| 22:49 | <Hixie> | didn't i try doing that once? |
| 22:49 | Philip` | is reminded of the idea "A distributed system is one in which the failure of a computer you didn't even know existed can render your own computer unusable." |
| 22:50 | <gsnedders> | Hixie: I think that was before I even tried to support Py2.3, which I should now |
| 22:50 | <Hixie> | gsnedders: cool, is there some way to install it easily without root? like some command i can run or something? |
| 22:50 | <Hixie> | Philip`: ironically, at this point the only computer that can fail without it being a fatal problem to me is the computer i own |
| 22:50 | <gsnedders> | python setup.py --prefix=install/here install |
| 22:51 | <Hixie> | i'm guessing there's at least one more line involved? |
| 22:51 | <Hixie> | :-) |
| 22:51 | <Hixie> | the wget line, that is :-) |
| 22:51 | <gsnedders> | And then the tar -zxf line |
| 22:51 | <Hixie> | curl ... | tar xvzf - |
| 22:51 | <Hixie> | what's the "..."? |
| 22:52 | <gsnedders> | Dunno |
| 22:52 | <gsnedders> | :) |
| 22:52 | <gsnedders> | You told me my school work was more important, so I don't have time to look it up |
| 22:52 | <Hixie> | oh well |
| 22:52 | <gsnedders> | hg.gsnedders.com/anolis/ |
| 22:52 | <gsnedders> | There's a gzip/bz2 link there |
| 22:52 | <gsnedders> | I think |
| 22:52 | <Hixie> | i'll just wait for the site to be up again |
| 22:54 | <gsnedders> | Speak of the devil, and he vanishes. |
| 22:56 | <Hixie> | i'm having a discussion with a disillusioned former html5 contributor on reddit |
| 22:56 | <gsnedders> | Linky! |
| 22:56 | gsnedders | changes virtual desktop back to work |
| 22:57 | <Hixie> | quite unlike some of the disillusioned people i deal with at the w3c, who think html5 is doomed because it pays too much attention to web browsers, this individual thinks that we don't listen _enough_ to browser vendors |
| 22:57 | <Hixie> | specifically, that there are too many places where microsoft, nokia, and other browser vendors don't agree with each other yet |
| 22:57 | <Hixie> | i'm going to take it as a good sign that the complaints i get about html5 are mostly mutually contradictory |
| 22:58 | <Hixie> | gsnedders: i pasted the link in earlier |
| 22:58 | <gsnedders> | I don't reload links you link earlier! |
| 22:59 | <Hixie> | you can also get to it by looking at my user page on reddit :-P |
| 22:59 | <gsnedders> | I don't look at that either! |
| 22:59 | <Hixie> | i thought you said you were good at procrastination! |
| 22:59 | <Hixie> | what happened! |
| 22:59 | <Hixie> | i had such high hopes for you |
| 22:59 | <gsnedders> | Oh, sure, but I don't procrastinate by stalking you |
| 22:59 | <gsnedders> | http://quotes.burntelectrons.org/4288 reveals who I do stalk |
| 22:59 | gsnedders | moves the bin a bit |
| 23:04 | gsnedders | yawns |
| 23:04 | gsnedders | slaps self |
| 23:09 | <Hixie> | damnit, i just spent the last 10 minutes looking at burntelectrons |
| 23:09 | <Hixie> | only your twitter stopped me |
| 23:09 | <gsnedders> | Touché. |
| 23:10 | <gsnedders> | I realized I had procrastinating from tweeting that, as I had it typed up on Twitter.com, but saw a link on someone else's tweet, followed that, and didn't submit it at the time. |
| 23:10 | <Hixie> | we have issues |
| 23:10 | <gsnedders> | Yeah, seriously. |
| 23:13 | <annevk2> | lol, that quote is funny |
| 23:13 | <annevk2> | must have been late when I posted that |
| 23:17 | gsnedders | yawns loudly |
| 23:18 | gsnedders | should go to bed |
| 23:18 | <gsnedders> | I procrastinate less in the morning |
| 23:18 | <gsnedders> | (less being the vital word) |
| 23:20 | <Philip`> | Mornings are for sleeping and for playing TF2 |
| 23:20 | <Philip`> | Afternoons are for procrastinating |
| 23:20 | <Philip`> | Evenings are for doing the work that I meant to do during the day |
| 23:20 | <Philip`> | Nights are for playing more TF2 and then sleeping |
| 23:21 | <Philip`> | At least that's how my life seems to work |
| 23:25 | <annevk2> | http://quotes.burntelectrons.org/3577 lol |
| 23:26 | <Hixie> | is there another instance of pimpmyspec.net anywhere, btw? |
| 23:26 | <Hixie> | if there were two instances i could use whichever one finished first |
| 23:26 | <annevk2> | the quuz.org one is not up to date |
| 23:27 | <gsnedders> | Not much has changed, though :P |
| 23:27 | <annevk2> | Hixie, if what gsnedders says is true you can try http://anolis.quuz.org/ |
| 23:28 | <Hixie> | i think there are enough changes that the output is notably different |
| 23:28 | <Hixie> | spacing and stuff like that |
| 23:28 | gsnedders | wonders how much effort it'd be to get pms running on gsnedders.html5.org |
| 23:29 | <annevk2> | I can update anolis.quuz.org if someone tells me what files to changes |
| 23:29 | <annevk2> | s/changes/change/ |
| 23:29 | gsnedders | finds PMS has a load of dependancies and decides not to |
| 23:42 | <gsnedders> | Hixie: What's the working-copy URL? |
| 23:42 | <gsnedders> | working-copy? |
| 23:43 | <gsnedders> | Or rather, the file to gen from? |
| 23:43 | <Philip`> | gsnedders: Do you not have anything more important to do than work on the spec-generation system? :-p |
| 23:43 | <gsnedders> | Philip`: No |
| 23:44 | Philip` | is currently busy failing to finish writing a paper before tomorrow |
| 23:45 | <gsnedders> | http://gsnedders.html5.org/pms/ throws errors when you try and gen a spec |
| 23:45 | <gsnedders> | oh well |
| 23:45 | <Hixie> | i concatenate header-whatwg and working-copy |
| 23:52 | gsnedders | has no idea why it is failing on html5, and gives up |
| 23:54 | gsnedders | gives up, and goes to bed |
| 23:54 | <gsnedders> | See you in a few hours |
| 23:56 | Hixie | tries to understand the videos microsoft put up of their speed tests |
| 23:56 | <Hixie> | i don't understand how they decide when to stop their stopwatch |
| 23:59 | Philip` | vaguely remembers reading that it was when the progress bar stopped |
| 23:59 | <Hixie> | it's demonstrably not the case |