| 01:09 | <MikeSmith> | Hixie: in your description of the Web development model, I don't understand what the distinction is between event-based and stream-based |
| 01:10 | <MikeSmith> | wondering what is an example of something that's stream-based that's not also event-based |
| 01:10 | <Hixie> | TCP |
| 01:10 | <MikeSmith> | ah |
| 01:10 | <Hixie> | event-based may be the wrong terminology |
| 01:11 | <Hixie> | maybe poll vs push is more the right comparison? |
| 01:11 | <Hixie> | browsers use an event loop, so scripts get notified of things |
| 01:11 | <Hixie> | socket-based programming usually boils down to a select() loop somewhere |
| 01:12 | <Hixie> | i.e. the program waits for data to be ready |
| 01:12 | <Hixie> | now, we could just fire an event each time a packet comes in, i guess |
| 01:13 | <Hixie> | but that doesn't really fit the way the platform usually works |
| 01:13 | <MikeSmith> | yeah, let's do that |
| 01:14 | <Hixie> | it also makes it harder to handle binary data later when we introduce it |
| 01:14 | <Dashiva> | Let's fire an event every cycle, even if there isn't a packet |
| 01:16 | <MikeSmith> | Hixie: hey yeah, about that, it would seem like a good idea to have that on the agenda for joint f2f discussion with TC 39 folks at TPAC |
| 01:18 | <Hixie> | a higher priority would be to get them to stop introducing new modes |
| 01:18 | <Hixie> | but i'm not holding out much hope there either :-( |
| 01:23 | <othermaciej> | I need to write up some sort of rough proposal for binary data |
| 01:23 | <othermaciej> | also for how to allow WebKit/Opera-style objects that masquerade as undefined |
| 01:25 | <Dashiva> | Are there any plans (solid or not) for 3D SVG? |
| 01:25 | <MikeSmith> | othermaciej, Hixie: I wondering if we should open a bugzilla bug for tracking Alexey's entities-in-XHTML issue |
| 01:26 | <MikeSmith> | Dashiva: there was a related draft of some kind a while back |
| 01:26 | <othermaciej> | it should go in bugzilla, yes |
| 01:26 | MikeSmith | goes too look |
| 01:26 | <othermaciej> | I can suggest that to him |
| 01:26 | <MikeSmith> | OK |
| 01:26 | <Hixie> | MikeSmith: fine by me, i am just hoping we can get the people who are going to complain about this to complain before i make the change |
| 01:27 | <Hixie> | because i'm tired of people saying that we don't have discussion first |
| 01:27 | <MikeSmith> | complain early, complain often |
| 01:28 | <Dashiva> | I can imagine a complaint that you're trying to sidetrack complaints of acting unilaterally |
| 01:29 | <MikeSmith> | them song: Willie Mabon's "I Don't Know" .. "What should I say to make you mad this time?" |
| 01:29 | <MikeSmith> | *theme |
| 01:30 | <Dashiva> | Oh Mikey |
| 01:32 | <Dashiva> | Do you know why google translate would translate wtf into 博? |
| 01:38 | <MikeSmith> | Dashiva: no clue |
| 01:39 | <MikeSmith> | weird |
| 01:47 | <MikeSmith> | Dashiva: at least if you put a question mark it gets it right |
| 01:48 | <MikeSmith> | 一体何だ |
| 02:01 | <MikeSmith> | JoePeck: the Event Listeners pane is mighty cool |
| 02:02 | <JoePeck> | MikeSmith: yah, debugging event listeners should plague me a lot less now =) |
| 09:31 | <hsivonen> | Hixie: for entities in XML, the Gecko way can be implemented with any compliant XML parser without having to profile off-the-shelf parser software |
| 09:35 | <Philip`> | Dashiva: 3D SVG sounds like X3D |
| 09:36 | <hsivonen> | the entity thing is going to be "fun" |
| 09:37 | <hsivonen> | there will be a faction that'll complain that the WHATWG tries to kill XML by insisting on a pure XML parser (no entitites) |
| 09:38 | <hsivonen> | and there will be another faction that'll complain about the WHATWG changing/profiling XML |
| 09:39 | <hsivonen> | the real solution is that xml-core defines XML5 with HTML5-like tokenization including all the MathML 3 entitities hard-wired |
| 09:39 | <hsivonen> | the other real solution is to use text/html |
| 09:42 | <hsivonen> | for avoidance of ambiguity, above "by insisting" meant the WHATWG doing the insisting to use a pure XML parser |
| 09:47 | <Hixie> | so should innerHTML support the entities in XML? |
| 09:48 | <Hixie> | should it depend on whether there's a DOCTYPE present? |
| 09:48 | <Hixie> | what FPIs should be recognised? |
| 09:48 | <Hixie> | etc. |
| 09:48 | <Hixie> | however you cut it, it's a profile |
| 09:52 | <hsivonen> | Hixie: my general feeling is that the XML code path is a legacy thing. the XML Web that never came. I'd rather not spend time polishing it by adding entitities to innerHTML |
| 09:52 | <Hixie> | then you'd better remove it from firefox :-) |
| 09:53 | <hsivonen> | Hixie: however, you can add entity support withou profiling XML |
| 09:53 | <Hixie> | because the webkit guys are saying they need it for compat with firefox |
| 09:53 | <Hixie> | how? |
| 09:53 | <hsivonen> | Hixie: whoa! does Gecko support entities in innerHTML? |
| 09:53 | <Hixie> | it's what i'm told |
| 09:53 | <hsivonen> | eww |
| 09:54 | <hsivonen> | Hixie: by feeding a doctypeless XML document to the XML processor and expanding entities by intercepting the undeclared entity non-errors on the application layer |
| 09:55 | <Hixie> | i'd call that a profile, but ok |
| 09:55 | <hsivonen> | skippedEntity in SAX |
| 09:55 | <hsivonen> | Hixie: the skippedEntity callback flows directly from the XML spec |
| 09:55 | <hsivonen> | Hixie: it's totally spec-based |
| 09:55 | <Hixie> | sure but requiring that something be done based on it is a different matter |
| 09:55 | <Hixie> | i'm not against it |
| 09:55 | <Hixie> | i should clarify |
| 09:55 | <Hixie> | i'm quite happy to profile other specs |
| 09:56 | <Hixie> | i'm just expecting complaints |
| 09:56 | <hsivonen> | I've been agains making skippedEntity processing part of a spec for years |
| 09:56 | <hsivonen> | but now it seems it's a lesser evil than profiling XML itself |
| 09:57 | <hsivonen> | Hixie:like I said above, there will be at least two mutually-unpleasable factions |
| 09:57 | <Hixie> | as usual |
| 09:57 | <hsivonen> | I guess I should read the code to see what Gecko does for entities in innerHTML |
| 09:58 | <hsivonen> | I'm very surprised at the allegation that they'd get expanded |
| 09:58 | <jgraham> | to be fair as an author you would expect entities to work in innerHTML |
| 09:58 | <jgraham> | It would be highly surprising if they didn't |
| 09:59 | <hsivonen> | jgraham: only if you don't know the XML spec well |
| 09:59 | <jgraham> | hsivonen: How many authors know the XML spec well? |
| 09:59 | <hsivonen> | jgraham: are you suggesting there are people using XML without knowing what they've gotten themselves into? |
| 10:00 | <jgraham> | Heh |
| 10:00 | <jgraham> | But yeah, the right solution is to not use XML on the web |
| 10:03 | <Philip`> | Does innerHTML let you do stuff like <div xmlns:foo="..."></div> ... div.innerHTML = "<foo:bar/">? |
| 10:15 | <hsivonen> | Philip`: IIRC, yes |
| 10:22 | <Philip`> | If it does context-dependent parsing in that case, so it's mostly equivalent to writing the text into the original markup, I'd expect it to support entities in the same way |
| 10:22 | <Philip`> | (as an author) |
| 10:23 | <hsivonen> | I guess once you have a synthetic root element having a synthetic doctype isn't far away |
| 10:24 | <hsivonen> | aside: treating SVG and MahtML in text/html as precedent for X3D in text/html misses the point majorly |
| 10:24 | <hsivonen> | the above-DOM part of SVG and MathML existed already |
| 10:24 | <hsivonen> | not so for X3D |
| 10:34 | <Philip`> | It seems the first job would be to make the above-DOM part exist in browsers, and just use it in XHTML for now |
| 10:35 | <Philip`> | which seems to be what the X3D people are currently thinking about |
| 10:35 | <Philip`> | and that's probably enough to keep them busy for a few years |
| 10:36 | <hsivonen> | well, first one should make a use-case-based case for having a retained-mode 3D engine with a standard model serialization as part of the browser |
| 10:36 | <hsivonen> | as opposed to shipping your engine of choce as JS to the browser and the browser having WebGL |
| 10:36 | <hsivonen> | (totally violates the Rule of Least Power, of course) |
| 10:37 | <hsivonen> | s/choce/choice/ |
| 10:37 | <Philip`> | Doing it in JS doesn't remove any of the questions about how the markup should work and how it should be integrated into the document - that just seems like an implementation detail |
| 10:38 | <hsivonen> | Philip`: why does it need to be in the markup instead of being a separate HTTP resource retrieved via XHR? |
| 10:38 | <hsivonen> | if the engine is in JS, you've already lost declarativity |
| 10:40 | <Philip`> | hsivonen: I guess for the same reasons SVG needs to be in the markup |
| 10:42 | <hsivonen> | Philip`: does the analogy work with 3D? is 3D expected to integrate into the CSS formatter canvas on as low a level as SVG? |
| 10:42 | <hsivonen> | Philip`: also, the case for SVG itself is a bit shaky |
| 10:42 | <hsivonen> | Philip`: more like people want it rather than here's a good reason to want it |
| 10:47 | gsnedders | wonders whether to work on DOM Core or html5lib today |
| 10:47 | <gsnedders> | (I'll work on the other tomorrow) |
| 11:01 | gsnedders | thinks he's finished updating the html5lib tokenizer now |
| 11:02 | <hsivonen> | gsnedders: to new script text stuff? |
| 11:02 | <gsnedders> | yeah |
| 11:02 | <hsivonen> | cool |
| 11:02 | <hsivonen> | are test cases up-to-date, too? |
| 11:02 | <gsnedders> | No |
| 11:02 | <hsivonen> | not so cool |
| 11:02 | <gsnedders> | Indeed |
| 11:03 | <gsnedders> | Several of the contentModelFlags tests fail, unsurprisingly :P |
| 11:04 | <jgraham> | gsnedders: It sounds you are already working on hml5lib Given the implied exclusivity in your question I think we can leave the job of answering to lady logic |
| 11:04 | <gsnedders> | jgraham: Well, I hadn't started when I asked that question |
| 11:06 | <Mathias__> | Sup guys |
| 11:07 | <hsivonen> | jgraham: lady logic? |
| 11:07 | <Mathias__> | I was wondering why HTML5 doesn't introduce <link rel="script"> or something similar |
| 11:07 | <Mathias__> | A solution that doesn't require an unnecessary closing tag, like <script src="foo"> does at the moment |
| 11:07 | <hsivonen> | Mathias__: because <script src> already works |
| 11:09 | <Mathias__> | Yeah, but it requires a closing tag, even if it's just used to link to an external file |
| 11:09 | <Mathias__> | In which case the parser ignores anything in between the starting and closing tags anyway |
| 11:10 | <hsivonen> | Mathias__: it's backwards-compatible |
| 11:10 | <gsnedders> | Mathias__: $yourOtherSyntax doesn't work today. <script src> already does. What is gained by having a new syntax that doesn't already work? |
| 11:11 | <Mathias__> | hsivonen, gsnedders: It would be perfectly possible to make something like <link rel="script"> backwards compatible through JavaScript |
| 11:11 | <gsnedders> | Maurice: Requiring </script> is far from the ugliest thing in HTML. |
| 11:13 | <Mathias__> | The advantage would be not having to use </script> when you're just linking to another file anyway. Cleaner code. Linking JavaScript files would be more similar to linking stylesheets |
| 11:13 | <gsnedders> | Mathias__: <script> is exectued as soon as it is added to the document, that wouldn't be. |
| 11:13 | <Philip`> | Mathias__: "backwards compatible through script" - doesn't that defeat the point of having a cleaner syntax for including scripts? :-) |
| 11:13 | <gsnedders> | Mathias__: Which is internally inconsistent within HTML. (If you made it do consistent in the spec, you couldn't make it work through JS.) |
| 11:13 | <Philip`> | Now you've got to include the script, *and* the script that loads the script |
| 11:14 | <hsivonen> | Mathias__: <link rel="script" href=""> is 27 characters. <script src=""></script> is 24 characters. |
| 11:14 | <Mathias__> | The same thing can be said about any new HTML5 feature |
| 11:14 | <Mathias__> | hsivonen, I'm not saying it's shorter, I'm saying it would make more sense when compared to how stylesheets are inserted |
| 11:15 | <hsivonen> | Mathias__: see topic |
| 11:15 | <Mathias__> | hsivonen: You got me there :( |
| 11:15 | <krijnh> | \o/ |
| 11:16 | <Mathias__> | CSS inline: <style></style> |
| 11:16 | <Philip`> | Mathias__: Many new HTML5 features can't be properly implemented with scripts, since they're not just new syntax for old features, so you can't say the same about all of them |
| 11:16 | <Mathias__> | Linking to CSS: <link rel="stylesheet" src=""> |
| 11:17 | <Mathias__> | JS inline: <script></script> |
| 11:17 | <Mathias__> | Linking to JS: <script src=""></script> |
| 11:17 | <Philip`> | Mathias__: (You mean href in link) |
| 11:17 | <Mathias__> | Philip`: Whoops, I stand corrected :) |
| 11:18 | <Philip`> | Mathias__: The attribute names aren't that consistent :-) |
| 11:18 | <Mathias__> | But you get my point, right? It just seems like an anomaly to me |
| 11:18 | <Mathias__> | Philip`: My point exactly |
| 11:18 | <gsnedders> | It's no less an anomaly than half the other things in HTML |
| 11:18 | <Philip`> | That doesn't make it not an anomaly |
| 11:18 | <Philip`> | Just probably not one that's worth fixing |
| 11:18 | <gsnedders> | Philip`: I'm not saying it isn't one. |
| 11:18 | <Mathias__> | What Philip` said |
| 11:19 | <Mathias__> | gsnedders: You're saying this shouldn't be an issue because there are bigger / more important “problems” |
| 11:19 | <hsivonen> | Mathias__: compatibility trumps consistency |
| 11:19 | <gsnedders> | HTML is completely inconsistent, and the cost of fixing all of them would be prohibitively high. There just isn't that much gained by fixing them all, especially more minor ones such as this. |
| 11:20 | <krijnh> | XHTML2 fixes all of this Mathias__ |
| 11:22 | jgraham | still gets the </script> thing wong sometimes |
| 11:22 | <jgraham> | *wrong |
| 11:22 | <jgraham> | But i still isn't worth fixing |
| 11:22 | <jgraham> | it |
| 11:22 | <gsnedders> | Mathias__: If you came up with a version of HTML that fixed all the inconsistencies it would bear little resemblance to HTML 4.01. The cost of creating a new language is very high. HTML is a mess due to having things hacked on left, right, and centre by most vendors, but nothing short of a total redesign of the language will fix that. |
| 11:22 | <jgraham> | Gah |
| 11:23 | <Philip`> | At least HTML is quite consistently inconsistent |
| 11:23 | <Philip`> | If you cleaned up part of it then it's be inconsistently inconsistent |
| 11:23 | <gsnedders> | Mathias__: As XHTML proved, a fairly minor redesign of the language, only touching the syntax, just didn't get the uptake. HTML, and the whole mess of compatibility it brings with it, just isn't going to go away. |
| 11:25 | <Mathias__> | I don't understand… Even the simplest new features of HTML5 require JS to make them work in older browsers |
| 11:25 | <Mathias__> | Why would it be so bad to introduce one more new thing in HTML5 which could be backwards compatible in the very same way? |
| 11:26 | <gsnedders> | Mathias__: What new features are recreations of existing features? |
| 11:26 | <Philip`> | gsnedders: <meta charset> |
| 11:27 | <gsnedders> | Philip`: That don't already work in browsers. :) |
| 11:27 | <Philip`> | It don't? |
| 11:27 | <Philip`> | Did you mean the opposite? |
| 11:27 | <gsnedders> | Philip`: You know what I mean, dammit. |
| 11:28 | <Mathias__> | gsnedders: <header> is a recreation of <div id="header">. The same goes for other HTML5 elements |
| 11:28 | <krijnh> | (It is for <div class="header">, I hope) |
| 11:28 | <Mathias__> | krijnh: Oh shut it! You get my point :p |
| 11:28 | <gsnedders> | What new features are there in HTML 5 that are recreations of existing features that don't work in browsers today? |
| 11:29 | <gsnedders> | Mathias__: It's not, at all. One has semantic meaning and an effect on semantics, the other does not. |
| 11:29 | <Philip`> | <header> doesn't work in most browsers today |
| 11:29 | <jgraham> | Mathias__: Not really. At least for sectioning elements they are really a new concept |
| 11:29 | <Philip`> | if by "work" you mean "is stylable" |
| 11:29 | <jgraham> | Philip`: depends wht you mean by "most" |
| 11:30 | <krijnh> | gsnedders: Microdata? :] |
| 11:30 | <Philip`> | jgraham: Weighted by number of users |
| 11:32 | <Mathias__> | gsnedders: Ok, so it's not a recreation of existing features. My point exactly. This completely new feature can "work" in every single browser by using JavaScript |
| 11:33 | <Mathias__> | Why would it be so bad to introduce another new thing, that can be made backwards compatible in the same way? |
| 11:34 | <Philip`> | Mathias__: I don't think it could be implemented in JS in a way that is compatible with the behaviour it should have when implemented natively |
| 11:34 | <gsnedders> | If you want it to work the same as <script src>, how do you get: <link rel=script href=foo.js><script>alert(foo)</script> (where foo.js contains "var foo = 1") to work? |
| 11:34 | gsnedders | doesn't either |
| 11:34 | <Philip`> | e.g. document.write probably wouldn't work |
| 11:36 | <Mathias__> | Hmm, good point, I hadn't thought of that |
| 11:37 | <Mathias__> | Don't know if that's possible at all, or not |
| 11:37 | <krijnh> | I don't understand why you would even try all this mess |
| 11:37 | <krijnh> | Just so that we can ditch </script> in about 20 years |
| 11:40 | <krijnh> | So, next issue? :) |
| 11:40 | Philip` | really doesn't want to be using HTML in 20 years from now |
| 11:40 | <gsnedders> | The adoption agency algorithm is impossible to understand. |
| 11:41 | <Philip`> | gsnedders: At least you're using a language where you can transcribe the algorithm into code |
| 11:41 | <Philip`> | and you don't have to reverse-engineer it into a side-effect-free functional form :-p |
| 11:42 | <gsnedders> | Philip`: n00b :P |
| 11:45 | <Philip`> | http://canvex.lazyilluminati.com/svn/tokeniser/treeconstructor_interp.ml (the "let rec adoptionAgency name state =" bit) |
| 13:10 | <krijnh> | gsnedders: (when) will your outliner be integrated in the w3.org checker? |
| 13:10 | <krijnh> | Or in validator.nu |
| 13:19 | <gsnedders> | krijnh: I assume not, as Python is rather hard to integrate into Perl/Java :) |
| 13:21 | <Dashiva> | jpython? |
| 13:21 | <Dashiva> | Or jython or whatnot |
| 13:21 | <gsnedders> | Dashiva: I rely upon specific C extensions for CPython |
| 13:22 | <krijnh> | Then port it :) |
| 13:45 | <jgraham> | gsnedders: lxml? |
| 13:54 | <gsnedders> | jgraham: ya |
| 14:00 | <Dashiva> | Aren't there native python parsers available, though? |
| 14:01 | <jgraham> | Dashiva: Nothing so good |
| 14:01 | <jgraham> | But gsnedders could probably swap it for ElementTree with some efort |
| 14:02 | <jgraham> | (no parent pointers is rather a drag) |
| 14:04 | <Philip`> | Seems easier just to rewrite the algorithm in Java |
| 14:05 | <Philip`> | and far less hassle than trying to integrate Jython into validator.nu |
| 14:11 | <jgraham> | Yes |
| 14:12 | <hsivonen> | is the algorithm stable no? |
| 14:13 | <jgraham> | hsivonen: Well it is in LC... |
| 14:34 | <ment> | gsnedders: adoption agency is easy, if you rewrite it into one-pass forward form |
| 14:36 | jgraham | would like to see an "easy" version of the AAA |
| 14:44 | <jgraham> | http://james.html5.org/microdata/ microdata parser, halloween editon |
| 14:45 | <jgraham> | The RDF output seems o be somewhat broken |
| 14:45 | <Dashiva> | <type 'exceptions.AttributeError'> |
| 14:45 | <jgraham> | Amongst other things |
| 14:45 | <erlehmann> | ahaha oh wow |
| 14:46 | <jgraham> | (I have only tried the O'Reilly example from the spec, and that only enough to determine that it is m |
| 14:46 | <Dashiva> | 'Item' object has no attribute 'doc' |
| 14:46 | <jgraham> | s/m/n/ |
| 14:46 | <jgraham> | ot quite right |
| 14:46 | <jgraham> | Dashiva: url? |
| 14:46 | <Dashiva> | I just pressed submit on that page |
| 14:46 | <jgraham> | Oh I didn't try that yet :) |
| 15:02 | <jgraham> | Dashiva: It now does something if you press the button without changing anything |
| 15:03 | <jgraham> | It isn't the _right_ thing |
| 15:03 | <jgraham> | But it is something |
| 15:03 | <Dashiva> | Well, it did something earlier too |
| 15:03 | <jgraham> | OK something other than throw an error |
| 15:04 | <Dashiva> | At least the error was an obvious sign that the output was incorrect, rather than subtle bugs :P |
| 15:06 | <jgraham> | Good reason to get everyone else to tell me what all the subtle bugs are now so I don't have o find them all myself |
| 15:10 | <ment> | jgraham: http://codepad.org/F7SaXBiD that's the "easy" version of AAA algorithm (it does only two forward passes over the data) |
| 15:25 | <gsnedders> | Man, this flat is ridiculous in quite a few ways. |
| 15:32 | <TabAtkins> | Man, old JS is ridiculous in quite a few ways. |
| 15:33 | <Philip`> | New JS too |
| 15:33 | <TabAtkins> | I really can't believe that anyone, *ever*, thought it was a good idea to put elements with @name as variables in the global scope. |
| 15:34 | TabAtkins | is helping a newb with coding style. She has obviously been trained by js tutorials from 1995. |
| 15:34 | gsnedders | guesses it's more someone thought it was a good idea to put them on window and then they got into the global scope as a side-effect. |
| 15:34 | <TabAtkins> | Putting them on window is an equally bad idea. |
| 15:49 | <Philip`> | TabAtkins: You can't believe people thought <a href="contact.htm" onmouseover="contactbutton.src='contact-in.gif'" onmouseout="contactbutton.src='contact.gif'"><img src="contact.gif" name="contactbutton"></a> was a good idea? |
| 15:49 | <TabAtkins> | No. No I cannot. |
| 15:49 | <Philip`> | and they ought to write onmouseover="document.getElementsByName('contactbutton')[0].src='contact-in.gif'" etc? |
| 15:50 | <Philip`> | As far as I can remember, changing images was pretty much the only thing you could do with JS when it was introduced |
| 15:51 | <TabAtkins> | They ought to write <a href="contact.htm" id=foo>Contact Us</a><style>#foo { background: url(contact.gif); } #foo:hover { background: url(contact-in.gif); }</style> |
| 15:52 | <Dashiva> | You're funny |
| 15:54 | <TabAtkins> | The funny thing is that mine seems *ridiculously* easier to me. And yet we have people asking for presentational HTML because CSS is too hard. |
| 15:54 | <Philip`> | TabAtkins: Need to add width:150; height:50; too |
| 15:55 | <Philip`> | (Obviously you wouldn't put "px" on it) |
| 15:55 | <TabAtkins> | Philip`: True. That can be avoided if I use content instead of background. |
| 15:55 | <Dashiva> | And content support was added in 1997? |
| 15:55 | <Philip`> | TabAtkins: That doesn't even work in many current browsers, never mind Netscape 2 :-p |
| 15:55 | <Philip`> | (or 3 or whatever it was) |
| 15:56 | <TabAtkins> | Philip`: Indeed, which is why I didn't use it in my example. ^_^ |
| 15:56 | <TabAtkins> | Dashiva: Nope. I just hate all the tutorials originating from 1997 that are still on the web, and high on the google charts. |
| 15:56 | <Dashiva> | TabAtkins: It's the same with Java |
| 15:56 | <Dashiva> | "This issue you have is going to be fixed in Java 1.0" |
| 15:57 | <Dashiva> | First hit on google |
| 15:57 | <TabAtkins> | Anyway, just rewrote the newb's code to teach her proper style. |
| 15:59 | <Philip`> | Yeah, people should have to get a license before they're allowed to put tutorials on the web, with annual renewal |
| 15:59 | <hsivonen> | Philip`: how would you license the licensor? |
| 15:59 | <Dashiva> | Hixie would handle that |
| 15:59 | <Dashiva> | Duh |
| 15:59 | <hsivonen> | good point |
| 16:00 | <TabAtkins> | I approve of making Hixie our sole point of failure. |
| 16:00 | <Dashiva> | sole point of success |
| 16:00 | <Philip`> | If you concentrating all points of failure into one, there's less chance of failure |
| 16:00 | <Philip`> | s/concentrating/concentrate/ |
| 16:01 | <Dashiva> | If you only have one strong link, don't make a chain |
| 16:17 | <Dashiva> | Random question, anyone know how I can make eclipse stop focusing the currently open file in the package explorer? |
| 16:20 | <Philip`> | Dashiva: Doesn't seem to focus anything automatically for me |
| 16:20 | <Philip`> | unless I'm just looking in the wrong windows |
| 16:21 | <jgraham> | Philip`: since 'this' in an event handler attribute points to the element on which the attribute is locted you could make your example simpler without needing .getElementByWhatever |
| 16:21 | <jgraham> | like this.firstChild.src='whatever' |
| 16:23 | <Dashiva> | Philip`: I think it started happening in galileo, not present in ganymede |
| 16:23 | <Philip`> | jgraham: That sounds complicated, because it'd require you to view the document as a tree rather than as a series of tags |
| 16:25 | <jgraham> | Philip`: A more reasonable objection would be that no-one understand how the "this" object works |
| 16:27 | Philip` | can't remember how long it took him to realise the DOM concept existed |
| 16:27 | <jgraham> | Anyway the truth seems to be that 50% of the web platform was designed assuming that we had to throw out all experience on how to write good code in order to make things easy whilst the other 50% was designed assuming that everyone has a perfect understanding of all the specs |
| 16:27 | <jgraham> | and never makes errors |
| 16:28 | gsnedders | never does, and perfectly understands the this object |
| 16:34 | <Dashiva> | jgraham: I feel there should be a clause on the latter part like "and therefore didn't feel the need to make the specs perfect" |
| 17:23 | <TabAtkins_> | Of course, the day before I leave for TPAC my car develops a mysterious problem. |
| 17:38 | <Philip`> | Hmph, Google Code Search regexps don't support backrefs :-( |
| 17:50 | <rubys> | <i> Configuring ruby-1.9.1-head using , this may take a while depending on your cpu(s)... </i> |
| 17:50 | <rubys> | Note the missing text prior to the comma |
| 17:50 | <rubys> | oops, wrong window :-) |
| 17:51 | <Dashiva> | Also, it's missing an s in rubys-1.9.1 :P |
| 17:52 | <rubys> | :-) |
| 17:52 | <Philip`> | <i>? How unsemantic |
| 17:53 | <rubys> | Philip`: it is even worse: as near as I can tell, it isn't HTML |
| 17:53 | <rubys> | that is spit out to STDOUT by rvm |
| 18:49 | <Dashiva> | Oh look, a totally unexpected response to alexey's email about entities |
| 19:06 | <Mathias__> | Evening guys |
| 19:06 | <Mathias__> | I have a, HTML5-related question |
| 19:06 | <Mathias__> | an* |
| 19:07 | <Mathias__> | Does <nav> require a heading of some sort? |
| 19:08 | <Mathias__> | I ran my site through gsnedders's excellent HTML5 outliner, and got this: http://gsnedders.html5.org/outliner/process.py?url=http://adlebbeke.be/index |
| 19:08 | <Dashiva> | <nav> is a sectioning element, yes |
| 19:09 | <Mathias__> | <nav> is causing the 'Untitled Section' |
| 19:09 | <Dashiva> | But it doesn't _require_ a heading |
| 19:10 | <Mathias__> | I understand it doesn't require a heading (i.e. to validate as HTML5) |
| 19:11 | <Mathias__> | But should a heading be added, or not? Considering the only heading text I can think of is something like "Navigation", or "Menu" |
| 19:11 | webben1 | wonders whether the outline algorithm should include provision for generic sections like navigation |
| 19:11 | Mathias__ | isn't sure if that would add semantic value |
| 19:11 | <webben1> | Mathias__: The example in the spec uses <h1>Navigation</h1> |
| 19:11 | <webben1> | http://www.whatwg.org/specs/web-apps/current-work/multipage/sections.html#the-nav-element |
| 19:12 | <Mathias__> | Hmmm |
| 19:13 | <Mathias__> | Probably, it's useful to add a heading to <nav> when using more than one <nav> element in your document |
| 19:13 | <Mathias__> | When there's only one <nav> element, it's safe to assume it's the main site navigation, right? |
| 19:14 | <webben1> | "wonders whether the outline algorithm should include provision for generic sections like navigation" ... oh wait, it does |
| 19:14 | <webben1> | http://www.whatwg.org/specs/web-apps/current-work/multipage/sections.html#headings-and-sections |
| 19:14 | <webben1> | "User agents should provide default headings for sections that do not have explicit section headings." "These default headings ("Untitled document", "Navigation", "Sidebar") are not specified by this specification, and might vary with the user's language, the page's language, the user's preferences, the user agent implementor's preferences, etc." |
| 19:15 | <Dashiva> | gsnedders|work: Is this enough to be considered a bug report? |
| 19:17 | <webben1> | Mathias__: So the upshot is, no, you should not need a heading if you only have the one nav. |
| 19:18 | <webben1> | Mathias__: Although that's not the same as the heading between useless - e.g. might be useful in today's user agents. |
| 19:19 | <Mathias__> | Ok, thanks for the help! |
| 19:20 | <Mathias__> | I'd be interested to know if the HTML4 |
| 19:20 | <Mathias__> | I'd be interested to know if the HTML5* outliner will be updated in order to reflect what webben1 said |
| 21:22 | <ScoobyDoo> | Is it possible to automaticly click a button on a webpage via client side scripting? |
| 22:16 | <gsnedders> | Well duh, convenience is overrated. |
| 22:29 | <Philip`> | gsnedders: What would consider an acceptable rating for convenience, out of five stars? |
| 22:29 | gsnedders | shrugs |
| 22:30 | <gsnedders> | jgraham: yt? |
| 23:32 | <jgraham> | gsnedders: Breifly |
| 23:32 | <gsnedders> | jgraham: I can't remember now. |
| 23:32 | <jgraham> | gsnedders: Oh well in that case it can't be too important |