| 03:24 | <Hixie> | what should valueAsDate/valueAsNumber do when used with type=text/password/hidden/checkbox/radio/button/etc ? |
| 03:24 | <Hixie> | nothing, or throw? |
| 03:25 | <Hixie> | i'm thinking return null/NaN on getting, and throw on setting. |
| 03:42 | <phroggy> | Is there an appropriate venue for asking the IE team to implement placeholder and/or <input type="search">? |
| 04:03 | <MikeSmith> | phroggy: IE team has a real-time chat thing scheduled once a month |
| 04:03 | <MikeSmith> | http://www.microsoft.com/windowsxp/expertzone/chats/default.mspx |
| 04:04 | <MikeSmith> | you might could join that and ask |
| 04:18 | <phroggy> | MikeSmith: thanks, I'll try that. |
| 06:58 | <erlehmann> | i wonder - what is the reason for not deprecating stuff that severely lacks semantics - like <b> or <i> or the target attribute ? |
| 06:59 | <Hixie> | we've given them semantics |
| 07:03 | <erlehmann> | well, i see that you tried - but say with <b>, we have "text to be stylistically offset from the normal prose without conveying any extra importance". and isn't exactly that totally non-semantic ? |
| 07:04 | <erlehmann> | i mean, a <span> + CSS can also be used to bolden text and has the same amount of "not conveying any extra importance" |
| 07:07 | <erlehmann> | and then there's a cognitive dissonance on my part - why mark something up, if it hasn't a special (semantic) role ? doesn't <b>stuff</b> imply that stuff is somehow important ? |
| 07:10 | <erlehmann> | and even if it has, IMO it's to shallow defined to contrast <em> or <strong>, which are often italized or boldened themselves. |
| 07:11 | <Hixie> | <b> is for like keywords and stuff |
| 07:11 | <Hixie> | which aren't important in the way that <strong> is |
| 07:11 | <Hixie> | it has nothing to do with bold really, nor does strong |
| 07:12 | <Hixie> | same with <em>, <i>, <var>, <cite>... they're all "italics" by default, but that's not really the point |
| 07:15 | <erlehmann> | i usually mark up my keywords with <em>. so what exactly, in HTML5 terms, differs from marking them up with <b> ? is it just that keywords by itself aren't important, ever ? |
| 07:16 | <Hixie> | <em> means stress emphasis |
| 07:16 | <erlehmann> | like in speaking ? |
| 07:16 | <Hixie> | yeah |
| 07:16 | <Hixie> | there are detailed examples in the spec |
| 07:16 | <erlehmann> | so would it help if i think of <b> as <keyword> ? |
| 07:16 | <erlehmann> | if so, thank you. |
| 07:18 | <Hixie> | yeah, though it's not just for keywords |
| 07:18 | <Hixie> | there's a couple of other examples in the spec |
| 07:19 | <erlehmann> | then i'd still suggest replacing "spans of text whose typical typographic presentation is boldened" with a more specific list - a mean, if that's possible, at all |
| 07:21 | <Hixie> | <b> is kind of the "fallback" element, which is why it's an open ended list |
| 07:22 | <hsivonen> | erlehmann: so what problem would be solved by not having <i> and <b>? |
| 07:22 | <erlehmann> | yeah, i see it. i'll try not to encounter the case where i'll have "exhausted" semantics, though. ;) |
| 07:23 | <erlehmann> | hsivonen: i got it. was just too fixated on the "spans of text whose typical typographic presentation" parts. |
| 07:25 | <erlehmann> | now my second question: the target attribute. wasn't that commonly listed as one of the worst (read: most annoying) design mishaps in web history ? |
| 07:25 | <hsivonen> | erlehmann: what authors would be instead is even worse |
| 07:26 | <hsivonen> | erlehmann: making bad stuff declarative makes it more detectable by UAs and easier to opt out of |
| 07:26 | <erlehmann> | synthax error. did you mean " what authors would USE instead" |
| 07:26 | <hsivonen> | s/be instead/be doing instead/ |
| 07:26 | <erlehmann> | ah okay. |
| 07:29 | <erlehmann> | so the reasoning for keeping it is that bad coders would do pop-ups and stuff with javascript ? |
| 07:30 | <hsivonen> | erlehmann: yeah |
| 07:32 | <erlehmann> | assuming a coder is so bad that he'd do that, wouldn't it be safer to just write into the spec why doing that is a very, very, very bad idea ? i mean, i've seen stuff like <a href="javascript: [...] "> but hell, those coders i've seen are still using <font> and frames. why would they even be interested in HTML5 ? |
| 07:33 | <hsivonen> | erlehmann: there have been people who've done window.open in order to cater for html 4.01 or xhtml 1.1 validation |
| 07:33 | <hsivonen> | erlehmann: the requirement to open windows may come from a client or boss or something |
| 07:34 | <erlehmann> | hsivonen: i hate people who do that with utmost dignity. |
| 07:36 | <erlehmann> | (i told the last client who wanted a song to play when the site loaded that i could, but wouldn't do and why) |
| 07:39 | <erlehmann> | i'll be back when i can coherently argument against catering to bad web designers. meanwhile, thank you for answering my questions. |
| 07:51 | <phroggy> | I use target="_blank" when I have a very specific reason for doing so. I do it very sparingly, and having to hack around it with JavaScript would annoy me. |
| 07:52 | <phroggy> | whether the browser chooses to implement it by opening in a new window or a new tab doesn't matter to me; that should be the user's preference. However, there are times when navigating away from the current page is undesirable. |
| 07:52 | <phroggy> | of course I've seen this abused - retarded marketing people who think users should never navigate away from their page under any circumstances. |
| 07:54 | <erlehmann> | phroggy: are you aware of the fact that almost every browser let's the user choose - by means of distinguishing left, and middle-click, for example ? |
| 07:55 | <phroggy> | yes, but many users aren't sophisticated enough to make that choice intelligently. |
| 07:55 | <erlehmann> | assuming you are, what are these "very specific reason[s]" ? that boss / client says so ? |
| 07:55 | <phroggy> | and, when I specify target="_blank", middle-click still works. |
| 07:55 | <erlehmann> | many users are confused when the context changes in unexpected ways, the back button breaks, and so on. |
| 07:56 | <erlehmann> | so tell me, phroggy, when do you use it ? |
| 07:57 | <phroggy> | I just built a directory that allows users to enter various contact information including their MySpace, Facebook and LiveJournal IDs, then on a confirmation page presents these as clickable links that the user can test before submitting the form to save the info in the database. I set those links to use target="_blank". |
| 07:58 | <phroggy> | I know there are some people who would prefer to navigate to those links within the same window, then click the Back button to get back to the confirmation page (which is the result of a POST form and therefore not cached very nicely by some browsers) |
| 07:58 | <phroggy> | but I'm betting that MOST of my users don't want that. |
| 07:59 | <erlehmann> | i see. i'd NEVER work with myspace users, though ;) |
| 08:00 | <phroggy> | yes, well, this is a contact directory for old friends from high school. I personally despise MySpace, but some of them use it. |
| 08:01 | <phroggy> | but there's also a field for an arbitrary "home page" URL |
| 08:01 | <erlehmann> | also i never assume that i'm smarter than my users - but that lies probably in my choice of mates / clients / users :) |
| 08:01 | <phroggy> | which behaves the same way. |
| 08:01 | <phroggy> | indeed. |
| 08:02 | <erlehmann> | why don't you just accept the info and let them edit later ? or parse myspace / livejournal for info ? |
| 08:02 | <phroggy> | they can edit it later, but they're more likely to catch mistakes if I immediately offer a clickable link they can try before submitting. |
| 08:03 | <phroggy> | the key to good design isn't necessarily being smarter than your users, but it is anticipating what your users will expect. |
| 08:04 | <phroggy> | you've heard of the Principle of Least Surprise? |
| 08:05 | <erlehmann> | links opening in the same window surprise me the least >:] |
| 08:06 | <phroggy> | yep, but I'm betting having the confirmation page go away will surprise my users more than having the links open in new windows. |
| 08:06 | <phroggy> | hmm, that's odd... |
| 08:06 | <phroggy> | I think my ISP just broke something. |
| 08:09 | <erlehmann> | phroggy: you are playing on the same level as garvin hicking - quote: "What I absolutely dislike about xhtml+xml content type is that at least the last time I tried in Firefox any validation error will kill to display the blog. Until [sic !] the validation of XML dies so hard on user input, it's IMHO useless." |
| 08:10 | <erlehmann> | TLDR - understandable, but severely annoying in the end |
| 08:11 | <phroggy> | I have yet to make a site that allows users to submit arbitrary HTML code. |
| 08:12 | <erlehmann> | i currently do - we just validate our input against a subset of the XHTML DTD. |
| 08:12 | <phroggy> | :-) |
| 08:13 | <erlehmann> | of course, complaints of the form "my input isn't accepted" are expected |
| 08:13 | <erlehmann> | but i say: those who can't do markup shall abstain from (X)HTML |
| 08:14 | <phroggy> | quite so. |
| 08:14 | <phroggy> | if I were to implement something like that from scratch myself without using anybody else's stuff, I would probably invent something like BBCode. |
| 08:15 | <erlehmann> | lotsa people use BB code. and it's crap. |
| 08:15 | <phroggy> | yes - if I had to do it myself, what I invented would most likely be crap. |
| 08:15 | <erlehmann> | like earlier versions of HTML, its purely presentational |
| 08:16 | <phroggy> | but BBCode is probably the direction I'd go. |
| 08:16 | <erlehmann> | BTW: where is the the XHTML5 DTD ? Hixie ? |
| 08:16 | <phroggy> | yes, that's because presentational markup is what users want. |
| 08:17 | <phroggy> | (well, it's what authors want when they're writing the code, not what users want when they're viewing the results.) |
| 08:17 | <erlehmann> | phroggy: do they ? if you press for it, users won't ever think "that's BOLD RED". |
| 08:17 | <erlehmann> | they say "it's all caps because it's IMPORTANT !!!!!111one1eleven" |
| 08:18 | <phroggy> | sure they will. If they're lazy they'll use caps, if they're less lazy they'll say "how can I make this bold and/or red?" |
| 08:18 | <phroggy> | not "how can I indicate that this has emphasis, which I can trust will be rendered appropriately later?" |
| 08:20 | <erlehmann> | then you do not press hard enough. or your users are retarded :þ |
| 08:20 | <phroggy> | most users are retarded, and they prefer it that way. |
| 08:21 | <erlehmann> | every one who complains about internet explorer rendering errors deserves a smacking. |
| 08:22 | <erlehmann> | likewise everyone who usese XHTML, but can't do well-formedness |
| 08:23 | <phroggy> | this is weird. Something is apparently broken at my ISP, but the only indication I have that there's a problem is, my IRC connection to irc.opera.com dropped and won't reconnect. A traceroute to that IP gets stuck in an infinite loop after the first hop past my LAN, but I haven't run into anything else similarly broken yet. |
| 08:24 | <phroggy> | never mind, it's fixed. |
| 08:26 | <Hixie> | erlehmann: there's no DTD for (X)HTML5 |
| 08:27 | <erlehmann> | Hixie: a schema perhaps ? or will that come only in 2009, when the spec is finished ? |
| 08:28 | <phroggy> | that's because DTD is an SGML and XML thing, right? And HTML 5 is neither? |
| 08:29 | <othermaciej> | XHTML5 is XML but does not use a DTD |
| 08:29 | <othermaciej> | DTD is optional for XML |
| 08:29 | <erlehmann> | well, how do i validate then ? |
| 08:30 | <othermaciej> | with an HTML5 validator |
| 08:30 | <othermaciej> | such as <http://validator.nu/>; |
| 08:30 | <erlehmann> | i want to validate input is part of my app. |
| 08:30 | <phroggy> | othermaciej: I think what he's looking for is, how to write one? |
| 08:31 | <erlehmann> | phroggy: exactly. if there's none, i'll make one. modularized, like XHTML 1.1 |
| 08:31 | <othermaciej> | ah, then the HTML5 spec says what a conformance checker is required to do |
| 08:31 | <othermaciej> | you can't implement correct HTML5 conformance checking with a DTD, unfortunately |
| 08:32 | <MikeSmith> | erlehmann: validator.nu has a REST API |
| 08:32 | <othermaciej> | at least, not solely with a DTD |
| 08:33 | <MikeSmith> | http://wiki.whatwg.org/wiki/Validator.nu_Common_Input_Parameters |
| 08:33 | <othermaciej> | other recent W3C markup languages are not defined by DTD either |
| 08:33 | <MikeSmith> | http://wiki.whatwg.org/wiki/Validator.nu_GNU_Output |
| 08:33 | <othermaciej> | for instance SVG 1.2 does not have a DTD |
| 08:35 | <othermaciej> | nor does XForms 1.1 |
| 08:36 | <othermaciej> | many people consider DTDs to be obsolete, or so I have heard |
| 08:36 | <erlehmann> | othermaciej: http://www.w3.org/Graphics/SVG/1.2/rng/ |
| 08:36 | <erlehmann> | HURR DURR |
| 08:37 | <othermaciej> | that is a RelaxNG schema, not a DTD |
| 08:37 | <phroggy> | othermaciej: I suppose the obvious question is, if DTDs are obsolete, what replaces them? |
| 08:37 | <othermaciej> | phroggy: that would be beyond my personal expertise |
| 08:37 | <phroggy> | :-) |
| 08:37 | <erlehmann> | schemas |
| 08:38 | <erlehmann> | so where's the HTML5 schema ? |
| 08:38 | <Hixie> | erlehmann: if you want to validate HTML5, you write a schema, or some C++ code, or whatever, to validate HTML5, following the rules in HTML5, the same as if you want to write an HTML5 editor, or an HTML5 web browser, or whatever |
| 08:38 | <Hixie> | erlehmann: there is no official schema, and will never be one |
| 08:39 | <erlehmann> | " there [...] will never be one" WAIT, WHAT ? why would you do that ? |
| 08:39 | <Hixie> | do what? |
| 08:39 | <Hixie> | we're not writing code, we're writing a spec |
| 08:39 | <MikeSmith> | erlehmann: the RNC schema files that validator.nu uses are here: http://svn.versiondude.net/whattf/syntax/trunk/relaxng |
| 08:39 | <erlehmann> | not doing a formal, machine-readable specification ? |
| 08:39 | <Hixie> | because that's an implementation, not a specification |
| 08:40 | <Hixie> | implementors should be free to compete on writing their own implementations |
| 08:40 | <Hixie> | having an official implementation results in no competition, which results in poor quality implementations |
| 08:40 | <phroggy> | I thought a schema was a spec, just in a machine-readable form instead of a human-readable form? |
| 08:40 | <erlehmann> | phroggy: it is. |
| 08:40 | <Hixie> | just look at how the html4 validators never really competed -- the html5 validator is already better than anything we ever got for html4 |
| 08:40 | <Hixie> | a schema is not a spec |
| 08:41 | <erlehmann> | wat |
| 08:41 | <Hixie> | it's an implementation of a spec for syntax checking |
| 08:41 | <phroggy> | hmm. |
| 08:41 | <Hixie> | we don't have any reference implementations |
| 08:41 | <othermaciej> | an implementation can be a spec |
| 08:41 | phroggy | remains unconvinced |
| 08:41 | <othermaciej> | just not clear if that is desirable |
| 08:41 | <othermaciej> | (Hixie apparently thinks not) |
| 08:42 | <Hixie> | an implementation of something simple can be a spec, but for something as complicated as html, that's a non-starter |
| 08:42 | <othermaciej> | as an implementor I like it when certain parts of specs are in a formal machine-readable notation |
| 08:42 | <othermaciej> | like IDL or BNF grammars |
| 08:42 | <othermaciej> | schemas or DTDs, not especially helpful for content display |
| 08:42 | <phroggy> | a schema would say e.g. <input type="date" name="date"> is part of the specification, but not say how to render it - that would be an implementation detail. |
| 08:43 | <erlehmann> | Hixie: i disagree strongly and would like to add that a formal schema is the only way to distinguish correct markup from incorrect one. |
| 08:44 | <phroggy> | erlehmann: I would disagree that a machine-readable schema is the only way. |
| 08:44 | <othermaciej> | I think the biggest problem with using a schema to define markup syntax is that you end up limiting yourself to what the schema language can express |
| 08:44 | <erlehmann> | a schema isn't an implementition, a validator is. |
| 08:44 | <phroggy> | it may be the only way to do it without human involvement... |
| 08:45 | <othermaciej> | it can also make the spec very hard to read |
| 08:45 | <phroggy> | othermaciej: yes, that would be my assumption as to why there won't be one |
| 08:45 | <othermaciej> | for instance reading the SVG spec (either 1.1 or 1.2), it is really hard for me to tell what attributes any given element supports |
| 08:45 | <phroggy> | and yes, that's something that I always hated about trying to read anything about HTML at W3C |
| 08:45 | <erlehmann> | othermaciej: that's why XHTML 1.0 has an appendix |
| 08:46 | <MikeSmith> | erlehmann: as othermaciej mentions, there are some constraints in the spec that are not expressible in any schema language; for those cases, validator.nu uses custom code to check those constraints |
| 08:46 | <phroggy> | ^^ THAT is a legit reason for not having a schema |
| 08:46 | <phroggy> | :-) |
| 08:46 | <othermaciej> | you could define your spec as "schema + extra constraints" |
| 08:46 | <MikeSmith> | yeah |
| 08:46 | <phroggy> | erlehmann: your task now is to invent a schema language in which HTML 5 can be fully described. |
| 08:47 | <othermaciej> | but then validators end up being tempted to just use the schema and ignore the extra constraints |
| 08:47 | <MikeSmith> | othermaciej: right |
| 08:47 | <erlehmann> | phroggy: i'll try. |
| 08:47 | <erlehmann> | but as XML schema is XML, it's extensible. |
| 08:48 | <erlehmann> | MikeSmith: you work on validator.nu ? what exactly are those corner cases ? |
| 08:48 | <MikeSmith> | erlehmann: hsivonen alone made validator.nu |
| 08:48 | <MikeSmith> | for details about the other cases, see http://about.validator.nu/ |
| 08:49 | <MikeSmith> | and they aren't just corner cases |
| 08:49 | <MikeSmith> | one thing is check the integrity of tables -- e.g., to make sure they have no overlapping cells |
| 08:50 | <MikeSmith> | http://hsivonen.iki.fi/table-integrity-checker/ |
| 08:51 | <MikeSmith> | erlehmann: also http://hsivonen.iki.fi/thesis/html5-conformance-checker.xhtml |
| 08:52 | <MikeSmith> | http://hsivonen.iki.fi/thesis/html5-conformance-checker.xhtml#non-schema |
| 08:52 | <Hixie> | using a schema language to express a specification requires adding another specification, written in english, to specify the schema language |
| 08:52 | <Hixie> | it just adds a level of indirection, massively increasing the overall complexity |
| 08:53 | <othermaciej> | or you could do like programming language weenies do, and define the schema language in itself |
| 08:53 | <Hixie> | then how do you know what any of it means? |
| 08:53 | <phroggy> | random guessing. :-) |
| 08:54 | <hsivonen> | erlehmann: html5.validator.nu uses RELAX NG for the easy stuff, a custom RELAX NG library and custom Java code |
| 08:54 | <othermaciej> | close your eyes and hope the axiom of foundation goes away? |
| 08:54 | <erlehmann> | Hixie: RELAX NG is already specified. |
| 08:54 | <Hixie> | but ok, that solves the problem quite nearly... let me define a schema language that can be used to express both all the rules of html5 and all the rules of its own schema language |
| 08:54 | othermaciej | wonders if he finally made a joke too nerdy for anyone on the channel to get |
| 08:54 | <erlehmann> | if it's XML, possible |
| 08:54 | <erlehmann> | othermaciej: bad joke. |
| 08:55 | <hsivonen> | erlehmann: schema languages aren't expressive enough to capture the conformance criteria of HTML5 |
| 08:55 | <Hixie> | this schema language has files that are exactly one bit long. If the bit is a 0, then it defines the schema of the schema language. if the bit is a 1, it defines the schema of html5. |
| 08:55 | <Hixie> | i now present you the complete schema for html5: 0x01. |
| 08:55 | <hsivonen> | DTDs weren't expressive enough for HTML4, and the result was that validators stopped at whatever the official DTD said instead of improving |
| 08:55 | <Hixie> | erlehmann: relax ng isn't powerful enough to express html5's validation requirements. |
| 08:56 | <erlehmann> | hsivonen, Hixie: so where are the problems ? |
| 08:56 | <Hixie> | erlehmann: e.g. table integrity in html5 |
| 08:57 | <erlehmann> | D: |
| 08:58 | <othermaciej> | Hixie: awesome, now I just have to write a processor for Hixie Schema Language |
| 08:58 | <erlehmann> | HSL is the future ! |
| 08:58 | <Hixie> | i suppose i should define error handling for my schema language |
| 08:59 | <Hixie> | if the file is shorter than 1 bit, then the user agent must report a fatal error |
| 08:59 | <hsivonen> | MikeSmith: I didn't make Validator.nu alone. fantasai started the schemas and there are lots of 3rd-party libs. |
| 08:59 | <Hixie> | if the file is longer than 1 bit, it must ignore all bits after the first one |
| 08:59 | <zcorpan_> | Hixie: doesn't the 0x00 schema define error handling? |
| 09:00 | <Hixie> | zcorpan_: no this schema language only defines validaity of input streams against schemas |
| 09:00 | <othermaciej> | I though schemata by their nature only define correct syntax, not erro rhandling |
| 09:00 | <Hixie> | zcorpan_: it doesn't define UA behaviour |
| 09:00 | <othermaciej> | *error |
| 09:00 | <zcorpan_> | Hixie: ah |
| 09:00 | <hsivonen> | erlehmann: RELAX NG sucks for ancestor-descendant constraints |
| 09:00 | <MikeSmith> | hsivonen: point taken |
| 09:00 | <Hixie> | othermaciej: right, but a schema language spec still has to define what to do with schemas that aren't themselves conforming |
| 09:00 | <hsivonen> | erlehmann: RELAX NG simply can't express table integrity 2D grid constraints |
| 09:00 | <erlehmann> | hsivonen: like <x> can or cannot be inside <y> ? |
| 09:00 | <erlehmann> | oh, bummer. |
| 09:01 | <hsivonen> | erlehmann: like <x> cannot be a descendant of <y> (with possibly <z> in between) |
| 09:02 | <hsivonen> | erlehmann: RELAX NG can express that, but it's extremely inconvenient |
| 09:02 | <othermaciej> | seems to me the question of validating against an invalid schema is ill-posed, but fair enough |
| 09:02 | <hsivonen> | erlehmann: to the point that it's just not worth it trying to express it in RELAX NG |
| 09:02 | <hsivonen> | erlehmann: it can be expressed in Schematron, though |
| 09:02 | <hsivonen> | but Schematron performance sucks |
| 09:03 | <erlehmann> | hsivonen: maybe one could generate that schema with XSL (chuckle) :D |
| 09:03 | <hsivonen> | so I optimized it away in Java |
| 09:03 | <Hixie> | othermaciej: how so? |
| 09:03 | <othermaciej> | well let's say validation is a function from ordered pairs (S, D) of a schema and a document to the set { true, false} |
| 09:04 | <Hixie> | othermaciej: if people are expected to use schemas with different implementations of the schema language, you can easily end up with people making mistakes and finding that different implementations handle those mistakes differently, if you don't define hwo to handle the mistakes |
| 09:04 | <hsivonen> | (Making Schematron performance not suck is a much harder implementation problem than making a naïve Schematron validator) |
| 09:05 | <othermaciej> | one would assume that if validate(M, S) == false where M is the metaschema (the schema for the sechema language) then vaidate(S, D) == false for any D |
| 09:05 | <othermaciej> | though I suppose one can define otherwise |
| 09:05 | <erlehmann> | away with that linguist jokery ! |
| 09:06 | <Hixie> | erlehmann: seriously though, the main reason we don't, and won't, have a schema is that in html4, having a schema caused the market to not innovate in the validation space, something which has almsot certainly contributed to the great mess that is html on the web |
| 09:06 | <hsivonen> | erlehmann: http://hsivonen.iki.fi/thesis/html5-conformance-checker#incorrect-rng-expectations |
| 09:06 | <Hixie> | erlehmann: with html5, not having a schema has caused at least one person (hsivonen) to actually focus on writing a better conformance checker |
| 09:06 | <Hixie> | erlehmann: and i expect there to be more over the years (including myself, hopefully) |
| 09:07 | <erlehmann> | Hixie: i though the problem was that UAs accepted HURR DURR braindead markup |
| 09:07 | <hsivonen> | erlehmann: that's a feature! |
| 09:07 | <erlehmann> | hsivonen: tag soup apologist ! |
| 09:08 | <Hixie> | othermaciej: one might well assume that, but i expect implementations will fail to catch all such errors (in the same way that html UAs in the early days didn't look for errors) |
| 09:08 | <Hixie> | erlehmann: there are many contributing factors |
| 09:08 | <othermaciej> | s/apologist/enthusiast/ |
| 11:43 | <phroggy> | other than onsearch, is there any other JavaScript event that fires every time the contents of a text field are modified without blurring? |
| 11:43 | <phroggy> | including using the mouse to paste/cut/clear from the Edit menu. |
| 11:52 | <Hixie> | phroggy: oninput |
| 12:03 | <hsivonen> | whoa. the tokenizer has a lot of fields |
| 12:04 | <hsivonen> | 52 (non-static) fields |
| 12:14 | <phroggy> | Hixie: alright, why do onsearch and incremental exist if we have oninput? |
| 12:15 | <phroggy> | is it because oninput didn't exist at the time? |
| 12:20 | <phroggy> | hmm, I notice a slight difference in behavior. |
| 12:39 | phroggy | submits a recommendation for <input type="search">, and finds that's a much harder case to argue than for placeholder support |
| 14:03 | <BenMillard> | gsnedders, using the Audi R8 (Le mans prototype, not road car) with Medium tyres in Arcade Time Attack mode, I did a 6:10.819, pitted (tyres only), then a 5:47.665 |
| 14:03 | <BenMillard> | so I'm guessing you used a different R8 or Super Hard tyres or just had a lot of crashes |
| 14:04 | BenMillard | hopes gsnedders reads the log. |
| 14:04 | <erlehmann> | BenMillard: this isn't CARWG |
| 14:05 | <erlehmann> | or was this a complex car analogy ? |
| 14:05 | <BenMillard> | I'm meeting him at W3C TPAC 2008 |
| 14:05 | <annevk2> | erlehmann, please see the topic :) |
| 14:05 | <erlehmann> | "Please leave your sense of logic at the door, thanks!" |
| 14:12 | <Philip`> | It is illogical to discuss off-topic issues such as racing games in a technical HTML channel, but the channel doesn't care much for logic and therefore it is perfectly on-topic and acceptable |
| 14:13 | <annevk2> | that statement violates the topic :p |
| 14:13 | <BenMillard> | we'll be playing the game at times during the TPAC, so we're figuring out each other's pace so we can spend more time having fun games and less times balancing the gameplay, therefore we'll be happier and more productive during the meeting time |
| 14:14 | <Philip`> | annevk2: How so? My statement was quite illogical |
| 14:15 | <Philip`> | BenMillard: You should just play Mario Kart instead, so if one of you is a worse player then they'll get all the red and blue shells and can easily catch up |
| 14:17 | <BenMillard> | Philip`, strangely enough I don't find Mario Kart to be quite as deeply engaging as Gran Turismo 4 :) |
| 14:19 | <Philip`> | BenMillard: Sure, but you can push Princess Peach into the path of a giant pinball, so it's clearly a better game |
| 14:20 | <BenMillard> | Philip`, then our tastes differ...and speaking of which, I'm off for lunch! |
| 14:51 | virtuelv | completely sucks at Mario Kart WII |
| 15:54 | <annevk2> | zcorpan, on http://simon.html5.org/html5-elements you need a space between spaces and title on <link> |
| 15:54 | <gsnedders> | jgraham: thx |
| 16:35 | <gsnedders> | BenMillard: (if you see this), I think I was on SSH, and crashed a fair bit too. |
| 16:36 | <gsnedders> | But hey, it was my first two laps on GT4 in a year |
| 16:37 | <gsnedders> | Probably only Hard, actually |
| 16:37 | <gsnedders> | s/SSH/RSH/ |
| 16:38 | <gsnedders> | I also think it wasn't crashing that much, it was just really big crashes |
| 16:38 | <gsnedders> | or just going off on a long straight costing me a lot of time |
| 16:47 | <Philip`> | How many pedestrians and/or zombies did you crush? |
| 17:01 | <gsnedders> | Down to 6:10.704 |
| 17:01 | <gsnedders> | Yeah, I can probably match your time given a week to get back in practice |
| 17:02 | <gsnedders> | Philip`: There are pedestrians and/or zombies in GT4? |
| 17:08 | <Philip`> | gsnedders: There should be |
| 17:09 | <gsnedders> | "All bright kids are depraved." |
| 17:09 | <Philip`> | gsnedders: Also, the cars should have giant meat grinders mounted to the front |
| 17:10 | <Philip`> | (U2XMP did - it was great fun to fire the rocket boosters and leap over the top of a hill and hit a jumping enemy player and cause them to explode gratifyingly) |
| 17:32 | <hsivonen> | http://www.symphonious.net/2008/10/01/why-do-we-have-same-host-restrictions/ |
| 17:34 | <Philip`> | Looking in IRC logs: http://gender.twitmarks.com/g.php?username=whatwg links to http://twitter.com/home?status=... - does that automatically change your Twitter status, or does it have an extra confirmation step to prevent the totally obvious CSRF attack? |
| 17:35 | MikeSmith | is away: Less talk, more pimp walk. |
| 17:35 | <Philip`> | hsivonen: Are you planning to reply to that? |
| 17:35 | <hsivonen> | Philip`: yes |
| 17:37 | Philip` | guess that `with (new XMLHttpRequest()) { open('POST', 'http://192.168.0.1/update_firewall_settings';); send(...) }` is one of the more obvious problems |
| 17:38 | <hsivonen> | Philip`: feel free to add more concrete threats |
| 17:40 | <hasather> | Philip`: that just sets the text in the textarea, it doesn't submit anything |
| 17:41 | <Philip`> | hasather: Ah, good |
| 17:42 | <Philip`> | (though of course you could load that page with the prefilled textarea into an iframe and then hide everything except the submit button, and trick someone into clicking on it, but hopefully nobody would be so cruel) |
| 18:42 | <Philip`> | phroggy: Saying "Nobody uses that" (on <isindex>) is dangerous, since people do use it :-) |
| 18:43 | <Philip`> | e.g. http://www.oasislasvegasrvresort.com/ (which oddly doesn't work in Opera) |
| 18:43 | <Philip`> | and http://www.sdsc.edu/~hutton/cgi-bin/tracert.cgi |
| 18:43 | <Philip`> | and I only had to search through a hundred thousand pages to find those |
| 18:43 | <phroggy> | alright |
| 18:43 | <Philip`> | Oh, and http://www.ijs.si/cgi-bin/rac-slovar |
| 18:45 | <phroggy> | I stand corrected. |
| 18:46 | <Philip`> | It's as common as the <centr> and <fontcolor=red> and <nyt_links_onsite> tags, in my set of pages |
| 18:49 | <phroggy> | as I said, it could be resurrected, but I don't see a compelling reason to do so. |
| 18:49 | <phroggy> | particularly because it's not a form element, and it's often useful for a search form to have other fields. |
| 18:50 | <Philip`> | I'm not disagreeing with your conclusions at all :-) |
| 18:50 | <Philip`> | <isindex> is not a feature I would want to encourage |
| 18:50 | <phroggy> | :-) |
| 18:50 | <Philip`> | because it's, like, totally crazy |
| 18:51 | <phroggy> | hehe |
| 18:51 | <phroggy> | indeed. I was unfamiliar with it until it was mentioned on the list and I looked it up. I suspect I was deliberately unfamiliar with it. |
| 18:52 | <phroggy> | one of those things I've seen before, but after glancing at, chose to ignore. |
| 18:53 | <Philip`> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cbody%20onload%3Ddocument.body.appendChild(document.createElement('isindex'))%3E%0A%3Cisindex%3E |
| 18:54 | <Philip`> | Hooray for interoperability |
| 18:55 | <phroggy> | uh, wait, what? |
| 18:55 | <Philip`> | IE and Opera show one labelled box; Safari shows one labelled and one unlabelled; Firefox shows two labelled |
| 18:55 | <phroggy> | ah.. |
| 18:55 | <phroggy> | I understand Safari's behavior... |
| 18:56 | <phroggy> | actually, no, I think I understand Firefox's behavior better. |
| 18:56 | <Philip`> | Firefox puts ISINDEX in the DOM, Opera puts ISINDEX containing text and HRs and stuff, Safari puts DIV containing text stuff and a ISINDEX type="khtml_isindex", IE did something different but it's crashed now and I can't be bothered to restart it |
| 18:56 | <phroggy> | fabulous. |
| 18:56 | <phroggy> | yeah, let's not support this tag. |
| 18:56 | <phroggy> | heh |
| 18:57 | <Philip`> | Well, we have to support it, because people still use it |
| 18:59 | Philip` | goes home |
| 18:59 | <phroggy> | browser developers have to support it, but HTML 5 doesn't. |
| 19:04 | <hsivonen> | Philip`: do people really insert it via the DOM and expect it to work? |
| 19:06 | <phroggy> | I'd guess many of the people using <isindex> began doing so before JavaScript existed... |
| 19:53 | <Philip`> | hsivonen: I really hope not |
| 19:54 | <Philip`> | and given how few people use it statically, and most of those seem to be ancient sites, I wouldn't expect anyone to ever insert one dynamically |
| 19:58 | <Philip`> | phroggy: HTML 5 is aiming to specify everything that browser developers need to support, so it has to support isindex in that sense (though it doesn't have to allow authors to ever use it, but I'm not sure whether that's what you mean) |
| 20:46 | <Hixie> | phroggy: onsearch and incremental don't exist in html5, only oninput |
| 20:47 | <phroggy> | Hixie: could they? |
| 20:47 | <Hixie> | why would they need to? |
| 20:48 | <phroggy> | why did Apple implement them? |
| 20:49 | <Hixie> | same reason we added oninput to the spec, i would posit |
| 20:50 | <phroggy> | did Apple implement onsearch before oninput existed? |
| 20:50 | <Hixie> | around the same time iirc |
| 20:51 | <phroggy> | onsearch (with incremental) has the advantage that it includes a built-in delay, so that doesn't have to be simulated (which is somewhat annoying to do well) |
| 20:54 | <Hixie> | oninput does too |
| 20:54 | <phroggy> | not according to my testing... |
| 20:54 | <phroggy> | it looks to me like oninput fires on every single keystroke |
| 20:55 | <Hixie> | that's an allowed implementation strategy (the delay is 0), but a delay is allowed |
| 20:59 | <phroggy> | hm. |
| 21:00 | <phroggy> | can I specify whether there should be a delay or not, or is that entirely up to the browser? |
| 21:01 | <Hixie> | browser |
| 21:01 | <phroggy> | there are times when I want something to fire on every keypress, and times when I want a delay. |
| 21:01 | <gavin> | do any browsers implement a delay? |
| 21:01 | <phroggy> | not that I saw. |
| 21:01 | <gavin> | seems to me like that might break a lot of pages |
| 21:02 | <phroggy> | indeed. |
| 21:04 | <Hixie> | why? |
| 21:04 | <phroggy> | if they expect it to fire on every keypress and it doesn't... |
| 21:04 | <Hixie> | how would it break them? |
| 21:04 | <Hixie> | they'd already be broken with copy and paste, presumably |
| 21:04 | <Hixie> | and drag and drop |
| 21:05 | <Hixie> | and IME |
| 21:05 | <Hixie> | and anything else taht doesn't have a 1:1 keypress -> input mapping |
| 21:05 | <Hixie> | incidentally the print versions of the spec are no longer being generated reliably, the document is so big that the PDF generator gets killed by the kernel |
| 21:06 | <phroggy> | let's see... how about a character count for a textarea; if you're a fast typist, it won't update while you're typing. |
| 21:06 | <Hixie> | if anyone wants to provide a web service that generates them, i can hook things up to them, but in the meantime, we have no print version |
| 21:06 | <Hixie> | phroggy: so? it'll update as soon as you stop typing, why isn't that ok? |
| 21:07 | <phroggy> | it's not expected behavior, it's not desirable behavior, it's not current behavior. |
| 21:07 | <Hixie> | seems like fine behaviour to me |
| 21:08 | <phroggy> | maybe not the best example, but the only one I could think of off the top of my head. |
| 21:08 | <phroggy> | there's other crazy JS stuff that manipulates your text while you type it... |
| 21:08 | <phroggy> | firing after a delay wouldn't necessarily "break" anything, but it's not always desirable behavior. |
| 21:09 | <Hixie> | seems like it's much better to fire any of those behaviorus after a delay rather than slow down the typing with computation on every keypress |
| 21:09 | <phroggy> | it is desirable when you're doing an AJAX query, or anything that requires massive processing. |
| 21:09 | <phroggy> | but if the processing required is minimal, it won't slow down the typing. |
| 21:10 | <phroggy> | e.g. updating a character count won't slow anything down. |
| 21:10 | <Hixie> | the UA can scale the delay based on how long the processing takes |
| 21:12 | <phroggy> | hmm, I'm not sure how that would work.... |
| 21:13 | <phroggy> | how is the UA supposed to know how long the processing will take, before doing the processing? |
| 21:14 | <Hixie> | do the processing once, time it |
| 21:15 | <Hixie> | jesus christ, these type=search and placeholder= threads have gotten huge |
| 21:16 | <gsnedders> | Hixie: Bigger is better. |
| 21:16 | <Hixie> | no, no it's not |
| 21:16 | <gsnedders> | But HTML 5 is big! |
| 21:17 | <gsnedders> | mmm… "Will you attend the reception on the evening of 22 October?" |
| 21:17 | <jcranmer> | Hixie: there's a thread on c.l.j.p that's a few K large |
| 21:17 | <jcranmer> | dominated by "shut up"\"no, you shut up" posts |
| 21:18 | <gsnedders> | Who actually goes to that? |
| 21:18 | <Hixie> | jcranmer: key difference being that i don't have to reply to all those e-mails |
| 21:18 | <phroggy> | Hixie: the processing isn't guaranteed to take the same amount of time for every execution, particularly since the value of the field the processing is probably being done on is (by definition) changing each time. |
| 21:18 | <phroggy> | (with some exceptions) |
| 21:19 | <gsnedders> | Hixie: You going to that? |
| 21:19 | gsnedders | has no idea |
| 21:19 | gsnedders | is n00b |
| 21:19 | <Hixie> | phroggy: sure, the UA can just scale the timeout based on how long recent calls have taken |
| 21:19 | <jcranmer> | Hixie: hell hath no fury like a web developer whose idea isn't implemented |
| 21:19 | <Hixie> | gsnedders: isn't that the AC thing? |
| 21:20 | <gsnedders> | Hixie: "This reception is open to W3C WG/IG/Incubator participants in good standing, AC reps, AB, TAG, Offices staff and Team." |
| 21:20 | <Hixie> | ah |
| 21:20 | <gsnedders> | i.e., no./ |
| 21:21 | <gsnedders> | s#/## |
| 21:21 | <Hixie> | no idea |
| 21:21 | <Hixie> | probably yes |
| 21:21 | <gsnedders> | It's one of the things on the registration form |
| 21:21 | <gsnedders> | Which I thought I probably better fill up now :) |
| 21:21 | <Hixie> | i don't pay much attention to the registration form :-) |
| 21:22 | gsnedders | wonders whether to observe PFWG |
| 21:26 | <eric_carlson> | Hixie: should a media element fire event(s) when it's document becomes inactive? |
| 21:26 | <eric_carlson> | Hixie: section 4.8.10.7 says "If the media element's owner Document stops being an active document, then the playback will stop until the document is active again" |
| 21:26 | <eric_carlson> | Hixie: but the section on media playback doesn't mention this case |
| 21:27 | <Hixie> | the word "Stop" links to the normative conformance criteria that defines that case |
| 21:28 | <eric_carlson> | reading it again... |
| 21:29 | <gsnedders> | Hixie: If you want, I can be beside you when you move to Anolis :P |
| 21:29 | <Hixie> | did the spec compliane issue get fixed? |
| 21:30 | <gsnedders> | Hixie: That's a bug in libxml2's serializer. Using html5lib it is fine |
| 21:31 | <Hixie> | well I need something that is fast and compliant |
| 21:31 | <Hixie> | (specifically, I need something that is fast, and the W3C needs something that is compliant) |
| 21:31 | <gsnedders> | Hopefully if I put it on my server it'll be quicker, and still reasonable using html5lib |
| 21:31 | <annevk2> | hmm, what goes wrong with libxml2 ? |
| 21:32 | <Hixie> | libxml2 presumably can't parse html to save its life |
| 21:32 | <gsnedders> | Hixie: It has an HTML mode which works kinda well |
| 21:32 | <Hixie> | apparently not |
| 21:32 | <gsnedders> | Hixie: The parsing works fine for HTML 5, the serializing doesn't |
| 21:32 | <gsnedders> | annevk2: http://html5.validator.nu/?=&doc=http%3A%2F%2Fwww.whatwg.org%2Fspecs%2Fweb-apps%2Fcurrent-work%2Findex-new |
| 21:33 | <hsivonen> | gsnedders: does serialization have the problems Julian raised about XSLT? |
| 21:33 | <Hixie> | you sure it's the serialisation that goes wrong? i thought it was the parsing. |
| 21:33 | <gsnedders> | hsivonen: Like losing the DTD, or what? |
| 21:34 | <gsnedders> | Hixie: No, it works fine if you use the parser and html5lib's serializer, IIRC |
| 21:34 | <Hixie> | i don't understand how the serialiser can have the bug i saw |
| 21:34 | <Hixie> | but ok |
| 21:34 | <gsnedders> | Hixie: What bug? |
| 21:34 | <Hixie> | the conformance issue |
| 21:34 | <gsnedders> | Hixie: That's a serializer issue, I'm pretty sure |
| 21:35 | <hsivonen> | gsnedders: I meant void elements |
| 21:35 | <Hixie> | the <dt> thing? |
| 21:35 | <hsivonen> | how can the dt thing happen? |
| 21:37 | <eric_carlson> | Hixie: I must be thick today, but I don't see which part describes what to do for the case of a document becoming inactive. |
| 21:37 | gsnedders | tries with lxml parser and html5lib serializer |
| 21:38 | <hsivonen> | what's the relationship of the backplane XG and PFWG? |
| 21:38 | <hsivonen> | is backplane ARIA-relevant? |
| 21:38 | <gsnedders> | the </dt> is the only issue with lxml's parser |
| 21:38 | <Hixie> | eric_carlson: "When a media element is actively playing and its owner Document is an active document, its current playback position must increase monotonically at playbackRate units of media time per unit time of wall clock time." is the only thing that actually makes the media "move" in time |
| 21:39 | <Hixie> | gsnedders: so it _is_ a parser issue? |
| 21:39 | <gsnedders> | That appears to be |
| 21:39 | <Hixie> | ok |
| 21:39 | <eric_carlson> | Hixie: Got that. |
| 21:39 | <gsnedders> | I think if we have a quick enough server html5lib shouldn't be that much of an issue |
| 21:39 | <Hixie> | eric_carlson: so where's the problem? |
| 21:40 | <gsnedders> | It should still be quicker than the CSS3 Module Postprocessor |
| 21:40 | <Hixie> | gsnedders: agreed. do we? even libxml2 was to slow when anne put it on his server |
| 21:40 | <annevk2> | maybe we can use validator.nu to serialize to XML first :) |
| 21:40 | <eric_carlson> | Hixie: my question is should fire an event when it stops playing because the document becomes inactive. |
| 21:40 | <gsnedders> | Hixie: I'll try setting it up on gsnedders.com this weekend |
| 21:41 | <eric_carlson> | Hixie: eg. as it does when pausing for user interaction, or because it runs out of data. |
| 21:41 | <Hixie> | eric_carlson: it's still "actively playing", so no. i mean, the spec doesn't say it should, right? |
| 21:41 | <gsnedders> | http://html5.validator.nu/?=&doc=http%3A%2F%2Fstuff.gsnedders.com%2Fspec-gen%2Fhtml5.html — that's an html5lib copy |
| 21:42 | <Hixie> | gsnedders: it was the w3c version that was causing me issues iirc |
| 21:42 | <Hixie> | header-w3c + source |
| 21:44 | <eric_carlson> | Hixie: are you saying that a media element that was playing continues to be "actively playing" when its owner document becomes inactive?? |
| 21:45 | <eric_carlson> | Hixie: even though it must stop playback |
| 21:45 | annevk2 | though there was agreement to add placeholder already |
| 21:46 | <Hixie> | eric_carlson: yes, the term "actively playing" doesn't mean it's, ah, actively playing, it means whatever the term is defined to mean. The condition that causes the playback to actually advice is when a media element is "actively playing and its owner Document is an active document", as per the quoted text above |
| 21:46 | <Hixie> | "A media element is said to be actively playing when its paused attribute is false, the readyState attribute is either CAN_PLAY or CAN_PLAY_THROUGH, the element has not ended playback, playback has not stopped due to errors, and the element has not paused for user interaction." |
| 21:46 | <Hixie> | nothing in that definition says it's actually playing |
| 21:47 | <eric_carlson> | Hixie: ah "actively playing != "actually playing" :) |
| 21:48 | <eric_carlson> | Hixie: so it stops playing but no other state changes so no events are fired. |
| 21:49 | <Hixie> | eric_carlson: right |
| 21:52 | <eric_carlson> | Hixie: Thanks. Now that I understand what you mean I get it, but "actively playing" is a confusing state because "playing" means something very specific for media (to me anyway). |
| 21:53 | <eric_carlson> | Hixie: not that I have anything better to suggest just yet. |
| 21:53 | <Hixie> | eric_carlson: yeah there's a lot of places in the spec where because of the way the text evolved, some of the terms used are poorly named |
| 21:54 | <Hixie> | eric_carlson: feel free to mail the list asking for terms to be renamed if you come across any (like this one) that are confusing |
| 21:54 | <eric_carlson> | Hixie: will do. |
| 21:54 | <Hixie> | eric_carlson: maybe "potentially playing" or "playing-enabled" or something would work here |
| 21:57 | <eric_carlson> | Hixie: "playable" ? |
| 22:07 | <Hixie> | that would probably be ok too |
| 22:20 | <gsnedders> | Hixie: http://html5.validator.nu/?=&doc=http%3A%2F%2Fstuff.gsnedders.com%2Fspec-gen%2Fhtml5.w3c.html |
| 22:23 | <gsnedders> | BenMillard: I should be able to get to around your time in the next week |
| 22:23 | <gsnedders> | BenMillard: Whether I'll be able to drive anywhere else in any other car will be interesting, though :) |
| 22:29 | <Hixie> | gsnedders: cool |
| 22:29 | <annevk2> | gsnedders, is that with html5lib? |
| 22:30 | <annevk2> | I can turn html5lib on on anolis.quuz.org, but I fear for awful performance |
| 22:30 | <Hixie> | http://html5.validator.nu/?=&doc=http%3A%2F%2Fwww.whatwg.org%2Fspecs%2Fweb-apps%2Fcurrent-work%2Findex-new is what i get today |
| 22:31 | <Hixie> | http://html5.validator.nu/?=&doc=http%3A%2F%2Fwww.whatwg.org%2Fspecs%2Fweb-apps%2Fcurrent-work%2F.w3c-new%2FOverview.html for the w3c version |
| 22:31 | <annevk2> | yeah, I agree that that's not good |
| 22:33 | <Hixie> | and that took 73 seconds to generate |
| 22:33 | <Hixie> | which is about 72 seconds more than i'd like |
| 22:33 | <Hixie> | :-) |
| 22:33 | <annevk2> | for EUR 100 a month I might be able to arrange something quicker :) |
| 22:33 | <Hixie> | :-) |
| 22:34 | <Hixie> | for 100 EUR a month, i'd have a new computer :-) |
| 22:36 | <annevk2> | it already takes like five seconds just to get the frontpage |
| 22:36 | <Hixie> | heycam: re svg and evt/event, my personal preference would be dropping <handler> altogether... |
| 22:36 | <Hixie> | hm? |
| 22:36 | <annevk2> | of anolis.quuz.org |
| 22:36 | <Hixie> | wow, yes |
| 22:36 | <Hixie> | why does it take so long |
| 22:37 | <BenMillard> | gsnedders, slow down and go faster. :) |
| 22:37 | <annevk2> | no idea |
| 22:37 | <annevk2> | it's the way python is installed I think, annevankesteren.nl responds quickly |
| 22:37 | <Philip`> | Is it Python CGI and loading a zillion modules just to render the front page? |
| 22:37 | <annevk2> | (though runs on PHP) |
| 22:38 | <annevk2> | Philip`, pretty much |
| 22:38 | <Philip`> | annevk2: I'd guess that might be the problem, then :-) |
| 22:41 | <annevk2> | <input> is such a mess it's almost nice |
| 22:43 | <Hixie> | hm? |
| 22:43 | <Hixie> | annevk2: i recommend running a profiler and fixing the bugs :-) |
| 22:43 | <Hixie> | (that make it slow) |
| 22:44 | <Hixie> | the front page of that site shouldn't need any scripting at all as far as i can tell |
| 22:47 | <annevk2> | Hixie, the processor and frontpage is a single file |
| 22:47 | <Hixie> | ah |
| 22:47 | <Hixie> | well then |
| 22:47 | <annevk2> | Hixie, I should look into FastCGI or something though |
| 22:47 | <Hixie> | you definitely need to optimise something :-) |
| 22:47 | <Hixie> | what on earth is it doing that takes five seconds? |
| 22:47 | <Hixie> | that's just silly |
| 22:48 | <annevk2> | ask Guido? :p |
| 22:48 | <Hixie> | emacs loads in less than five seconds |
| 22:48 | <Hixie> | i'm thinking he would say the script was badly written :-) |
| 22:48 | <gsnedders> | It was the first large thing I ever wrote in Python |
| 22:48 | <gsnedders> | Where large = > 10 lines |
| 22:50 | <Hixie> | that's one more than i've ever written :-) |
| 22:51 | <gsnedders> | :P |
| 22:54 | <jgraham> | Would it help if I tried setting up anolis on hoppipolla.co.uk (running on web faction)? Might be easier to get a more complex setup working there since they are selling themselves on being designed for python |
| 22:55 | <gsnedders> | jgraham: If you want to try, sure |
| 22:55 | <phroggy> | http://phroggy.com/ is something like 3,000 lines of perl (I kept adding features every time I got bored, for YEARS) and it executes fast enough that you don't really notice it, especially after waiting for all the graphics to load. |
| 22:55 | jgraham | finally has some time since he has finished moving out of his house |
| 22:56 | <Philip`> | phroggy: Using mod_perl? |
| 22:56 | <phroggy> | nope. |
| 22:57 | <phroggy> | not even FastCGI, just plain old regular CGI. |
| 22:57 | <jgraham> | where is the source to anolis.quuz.org? |
| 22:57 | <Philip`> | phroggy: Ah, okay |
| 22:57 | <gsnedders> | jgraham: /source |
| 22:58 | <phroggy> | wc -l *.pm says 3156 total |
| 22:58 | <jgraham> | Ah, I tried /src/ /src /source/ but not /source |
| 22:58 | <phroggy> | for... good lord, 15 modules |
| 22:59 | <phroggy> | 5 of which are object classes |
| 23:17 | <hallvors> | load https://www.vyke.com/js/common.js and search for "zzz". :-p |
| 23:18 | <hallvors> | I particularly like the exclamation mark |