| 00:00 | <ezyang> | Hixie: ping? |
| 00:16 | <Hixie> | ezyang: here |
| 00:17 | <ezyang> | Hixie: Can you comment on what IN_FOREIGN_CONTENT is supposed to do when we are processing an HTML element as "in body", and that element wants us to change the mode? |
| 00:18 | <Hixie> | um |
| 00:18 | <Hixie> | nothing beyond what the spec says as far as i can tell |
| 00:18 | <Hixie> | how do you mean? |
| 00:19 | <ezyang> | As far as I can tell, the spec doesn't record that you were originally in "in foreign content" when it hops to another mode, so when you pop out of that, you stay in "in body", and don't go back to "in foreign content" |
| 00:19 | <ezyang> | I just wanted to verify that this was true before sending mail |
| 00:32 | <theMadness> | Augh, damn user agents. |
| 00:32 | <theMadness> | They create a plethora of <a> nodes when I wrap some block item inside an <a> tag. |
| 00:33 | <theMadness> | I guess I have overestimated the current support of html5. |
| 00:34 | <Hixie> | ezyang: minimal testcase? do you mean like <svg><table> ? |
| 00:41 | <ezyang> | <svg><foreignObject><table></table></foreignObject></svg> |
| 00:42 | <ezyang> | Uhh, make that <svg><foreignObject><table></table></foreignObject><g/></svg> |
| 00:43 | <Hixie> | ezyang: wouldn't you switch back to foreign content when you reset after the </table>? |
| 00:44 | <ezyang> | Possibly. Let me check that part of the spec again |
| 00:45 | <ezyang> | Yep, looks like it. |
| 00:49 | <Hixie> | anyone here understand RDF/XML? |
| 00:53 | <Dashiva> | I figured RDF/XML would be mostly self-explanatory, but if you're asking that question, I guess not |
| 01:08 | <ezyang> | Is there any good way of just getting messages about changes to the html5lib spec that are w.r.t. tokenization/tree-building? |
| 01:08 | <ezyang> | erm, s/html5lib/html5/ |
| 01:09 | <Hixie> | yeah, look for 't' in the first field |
| 01:09 | <ezyang> | Hm... so I still have to sign up for html5-commits, and just filter out things w/o t in the first field? |
| 01:10 | <Hixie> | or you can use the tracker |
| 01:10 | <Hixie> | it has little check boxes that filter out everything else |
| 01:10 | <Hixie> | note that i often screw up |
| 01:10 | <Hixie> | so don't rely on it too much :-) |
| 01:10 | <ezyang> | So, "Affects Tools" is what I want? |
| 01:11 | <ezyang> | Man, I wish this had an RSS feed |
| 01:11 | <ezyang> | (and an easier way of unchecking everything) |
| 01:12 | <Hixie> | yeah |
| 01:12 | <Hixie> | you can provide patches, i believe |
| 01:13 | <Hixie> | the code is in code.google.com/html5 |
| 01:13 | <ezyang> | Sweet. |
| 01:13 | <ezyang> | Assuming it's not too grody, I'll take a stab |
| 01:13 | <ezyang> | ftr, it's http://code.google.com/p/html5/ |
| 01:13 | <ezyang> | Aw, it's still svn |
| 01:14 | <ezyang> | Can I get commit access? |
| 01:16 | <Hixie> | sure |
| 01:17 | <Hixie> | what's your account? |
| 01:17 | <ezyang> | edwardzyang⊙tc |
| 01:17 | <ezyang> | (same as html5lib) |
| 01:18 | <Hixie> | i'm not an html5lib admin :-) |
| 01:19 | <Hixie> | done |
| 01:19 | <Hixie> | don't break anything :-) |
| 01:19 | <ezyang> | Aye-aye, captain! |
| 01:28 | <ezyang> | Uh oh... html5 is using a svn:externals of testdata, which means it's old. |
| 01:29 | <Hixie> | i think most of the stuff in there is stale |
| 01:29 | <ezyang> | Heh. |
| 01:29 | <Hixie> | it's just a place for us to throw stuff related to html5 |
| 01:29 | <ezyang> | Ok. |
| 01:29 | <Hixie> | if it's useful it usually moves on to live elsewhere |
| 01:38 | <ezyang> | Meh, after looking at the Python code I decided I don't care enough |
| 01:39 | <Hixie> | hah |
| 01:45 | <jwalden> | Hixie: seems to me that "Basic d2FsbGU6ZXZl" is missing some caps and a hyphen, no? :-) |
| 01:45 | jwalden | pat-pats window.atob |
| 01:46 | jwalden | runs the other authstrs through atob for entertainment |
| 01:46 | <jwalden> | guess that's just stylistic :-) |
| 01:49 | <ezyang> | Hmm... should I setup some require_once's, or setup the entire HTML Purifier style autoloader shish-kebab |
| 02:07 | <ezyang> | Barring any objections, I'd like to release 0.1.0. |
| 02:07 | <ezyang> | (of the php html5lib) |
| 02:10 | <Hixie> | jwalden: :-) |
| 02:16 | <ezyang> | Uploaded |
| 02:16 | <ezyang> | I can't figure out how to update the project summary |
| 03:45 | <MikeSmith> | irc.mozilla.org down? |
| 03:46 | <Hixie> | wfm |
| 03:49 | <boblet> | Hey all, I’d like to ask about the id attribute ‘opaque strings’ comment (3.3.3.1); what is meant by ‘Particular meanings should not be derived from the value of the id attribute’? Is this intended for browser makers? |
| 03:49 | <Hixie> | yes |
| 03:49 | <Hixie> | it means that id="header" doesn't mean the element is a header |
| 03:50 | <Hixie> | it could just as easily be a footer, or a link, or a duck |
| 03:51 | <boblet> | aah, that makes sense. So as authors we’d be encouraged to use meaningful names (as the class attribute spec specifically states), but that meaning shouldn’t affect how the browser treats the element with the id huh |
| 03:52 | <Hixie> | yeah |
| 03:52 | <Hixie> | if you can come up with a better way for the spec to say that, drop me a line :-) |
| 03:54 | <boblet> | How would this sit with eg microformats? eg if the text specifically said “User agents should not derive particular meanings from the value of the id attribute” (which would remove the ambiguity for me), wouldn’t this also be problematic for eg Operator, Optimus et al? |
| 03:55 | <boblet> | Hrm, perhaps adding your example “eg id="header" should not be interpreted as <header>” is clearest? |
| 03:58 | <Hixie> | do they use id="" attribute values? |
| 03:58 | <Hixie> | i'd rather not define things by examples, though i could certainly _add_ examples if you want |
| 03:59 | <Hixie> | drop me a mail if you do |
| 04:01 | <boblet> | Microformats plugins/bookmarklets just look for the matching value, which could be class="vcard" or id="vcard". Using class="" is most common, but it’s possible an author might use id="". I’ll email you these comments. Thanks for the clarification |
| 04:06 | <Hixie> | k |
| 04:13 | <othermaciej> | I think the justification I just sent for the Design Principles may be longer than the actual Design Principles |
| 04:14 | <othermaciej> | not sure how to feel about this |
| 04:16 | ezyang | turns on obnoxious flag |
| 04:16 | <ezyang> | Anyone want to update the html5lib status page? |
| 04:16 | ezyang | turns off obnoxious flag |
| 04:26 | <othermaciej> | aaaand I self-replied twice |
| 04:26 | <othermaciej> | should have planned more before sending |
| 06:29 | <Hixie> | othermaciej_: you should just put your e-mail into the design principles |
| 06:30 | <othermaciej_> | all of it? |
| 06:30 | <Hixie> | more or less |
| 06:30 | <Hixie> | i mean it'll need editing |
| 06:30 | <othermaciej> | yeah |
| 06:30 | <Hixie> | but it would give the context people are asking for |
| 06:30 | <Hixie> | even if they don't agree with it |
| 06:30 | <othermaciej> | obviously the part where I say which principles are better or worse shouldn't be pasted in |
| 06:30 | <Hixie> | sure |
| 06:30 | <Hixie> | i'd just drop the ones that didn't work |
| 06:31 | <Hixie> | or fix them so they can |
| 06:31 | <othermaciej> | sections 1 and 2 seem like the best fits |
| 06:31 | <othermaciej> | though they are awfully long |
| 06:32 | <othermaciej> | anyway, I guess that seems like a good idea |
| 06:32 | <othermaciej> | or at the very least I could write an introductory section that addresses the same points |
| 06:34 | <othermaciej> | by the way, the prediction that "you can't please everyone" would draw objections was fulfilled |
| 06:34 | <othermaciej> | though I was surprised that the objection came from Sam |
| 07:37 | <heycam> | if i read the spec correctly, the load event dispatched once a document is loaded does not bubble. (same for most (all?) other "fire a simple event" things.) |
| 07:37 | <hsivonen> | the HTML5 version indictor is charset=utf-8, mmkay? |
| 07:39 | <heycam> | but event handler attributes (including onload="") are listeners for bubbling |
| 07:39 | <heycam> | unless: bubbling listeners get AT_TARGET phase events, and events that don't bubble are still dispatched AT_TARGET |
| 07:39 | <heycam> | which i think is true |
| 07:40 | <heycam> | so never mind |
| 07:52 | <othermaciej> | seems so quiet here tonight |
| 08:00 | <hsivonen> | could a html5lib admin add my hsivonen⊙if account to the project in addition to or in place of the @gmail.com account? |
| 08:16 | <annevk42> | heycam, that's true |
| 08:17 | <annevk42> | hsivonen, done |
| 08:17 | <hsivonen> | annevk42: thank you |
| 08:22 | <hsivonen> | $ hg outgoingabort: Python support for SSL and HTTPS is not installed |
| 08:22 | <hsivonen> | what macports incantation do I need? |
| 08:24 | <hsivonen> | how do I make hg tell me which python interpreter it is using? |
| 08:25 | <Hixie> | use lsof :-) |
| 08:29 | <hsivonen> | is there a way to leave lsof waiting so that I can first start lsof and then start hg? |
| 08:33 | <jgraham> | hsivonen: Does less `which hg` followed by reading the line at the top not answer your question? |
| 08:34 | <hsivonen> | jgraham: yes. thanks |
| 08:34 | <hsivonen> | for the log: the incantation is sudo port install py25-socket-ssl |
| 08:35 | <hsivonen> | but now I get a 404 for hg outgoing |
| 08:35 | <hsivonen> | hg outgoing https://hsivonen⊙if@html5lib.googlecode.com/hg/abort: HTTP Error 404: Not Found |
| 08:36 | hsivonen | wonders if Google's hg support has a bug with non-Gmail accounts |
| 08:36 | <hsivonen> | with the two @ signs |
| 08:37 | <zcorpan> | Hixie: "CSS properties respectively" is marked up as a dfn |
| 08:37 | <jgraham> | hsivonen: s/@/%40/ |
| 08:37 | <jgraham> | hsivonen: They do have a bug |
| 08:37 | <hsivonen> | jgraham: thanks |
| 08:38 | <jgraham> | (only the first @) |
| 08:38 | <Hixie> | zcorpan: thanks |
| 08:39 | <hsivonen> | jgraham: how should I escape % in hgrc? Python interprets % as something magic |
| 08:39 | <hsivonen> | %%? |
| 08:39 | <hsivonen> | yes, %% |
| 08:40 | <hsivonen> | yay for overlapping escapes |
| 08:49 | <Hixie> | holy crap, shelley managed to write an entire blog post about html5 without saying i was wrong about anything |
| 08:49 | <othermaciej> | no wai |
| 08:50 | <Hixie> | i really don't understand why people have so much trouble with the design principles |
| 08:50 | <Hixie> | are people really that desperate for black-and-white rules? |
| 08:50 | <Hixie> | language design isn't something you do by following a flowchart |
| 08:50 | <Hixie> | you have to weigh all the various goals, etc |
| 08:51 | <othermaciej> | haha, she hates the Design Principles because they are against RDFa |
| 08:51 | <Hixie> | i just don't get why every time we find the need to create new technologies, someone says "you're ignoring the don't reinvent the wheel principle", especially when we documented why we were doing so for that feature |
| 08:52 | <Hixie> | or why every time any one principle is overriden by some other concern, people assume that means we should always ignore that principle |
| 08:52 | <Hixie> | e.g. i mention that the design principles are merely guidelines, and shelley's response is to tell hsivonen that he's wrong about caring about dom consistency |
| 08:52 | <Hixie> | but that's just stupid |
| 08:52 | <Hixie> | because you have to care about dom consistency |
| 08:53 | <Hixie> | just like you have to care about everything else |
| 08:53 | <Hixie> | why do these people find this so challenging to grasp? |
| 08:54 | <othermaciej> | I am not sure |
| 08:56 | <ojan> | where is this thread going on? |
| 08:57 | <othermaciej> | I don't know how to explain it any further without getting repetitive |
| 08:57 | <othermaciej> | but yeah |
| 08:57 | <Hixie> | ojan: public-html is where most of it is, shelley's blog was what most recently triggered by confusion though |
| 08:57 | <othermaciej> | there could be valid reasons to override the DOM Consistency principle |
| 08:58 | <Hixie> | sure |
| 08:58 | <Hixie> | just look at the xml:lang disaster |
| 08:58 | <othermaciej> | for example, the need to Support Existing Content leads to some differences already |
| 08:58 | <Hixie> | we had to override it for that |
| 08:58 | <othermaciej> | right, like xml:lang vs lang |
| 08:58 | <Hixie> | xml:lang is the main reason we HAVE the principle, in fact :-P |
| 08:58 | <Hixie> | so we never have to repeat that disaster |
| 08:58 | <zcorpan> | would be nice to drop xml:lang and make lang equivalent to xml:lang for all elements |
| 08:59 | <zcorpan> | likewise with id |
| 08:59 | <othermaciej> | but just because you feel like it is not a good reason to override it |
| 08:59 | <Hixie> | holy crap! windows 7 just launched in a vm in the background and played its startup sound at full volume in stereo, sounded like a spaceship had landed in my hall or something! |
| 08:59 | <othermaciej> | and I would even say your counter-argument doesn't have to be based on any Design Principle |
| 08:59 | <othermaciej> | but you have more odds of being convincing if it is |
| 08:59 | Philip` | tried to explain HTML5's lang vs xml:lang rules to someone implementing an RDFa parser, and they didn't seem to entirely think it was a lovely elegant idea |
| 09:00 | <Hixie> | well people have clearly failed to notice that i never refer to the design principles explicitly |
| 09:00 | <Hixie> | and that i've been applying them completely independent of whether we have the design principles doc or not |
| 09:00 | <Philip`> | (I think the spec is probably less confusing now than it was a few days ago, though) |
| 09:01 | <Hixie> | the spec doesn't mention the string "xml:lang" any more (with a couple of exceptions) |
| 09:01 | <Hixie> | which might make it clearer |
| 09:01 | <othermaciej> | I think the Design Principles are more useful for those who disagree with the direction of the spec than those who largely agree |
| 09:02 | <zcorpan> | Hixie: i guess now you can remove the part in terminology starting "When an XML name, such as an attribute or element name, is referred to in the form prefix:localName" |
| 09:02 | <Hixie> | zcorpan: really? there's none left? |
| 09:02 | <Hixie> | othermaciej: yeah, but i don't think they see it that way :-) |
| 09:02 | <zcorpan> | Hixie: i think xml:lang was all there ever was (ignoring examples in that section) but i might be wrong |
| 09:03 | <Hixie> | i'm sure there are others |
| 09:03 | <zcorpan> | xml:base maybe |
| 09:06 | <zcorpan> | "Similarly, if the newly created element has an xmlns:xlink attribute in the XMLNS namespace whose value is not the XLink Namespace, that is a parse error." |
| 09:06 | <zcorpan> | is "xmlns:xlink" the local name or qualified name? |
| 09:06 | <Hixie> | qalified |
| 09:07 | <Hixie> | qualified, even |
| 09:07 | <Hixie> | it gets complicated with xmlns: attributes |
| 09:07 | <Hixie> | e.g. xmlns="" is in the XMLNS namespace iirc |
| 09:07 | <annevk42> | yes it is |
| 09:07 | <hsivonen> | Hixie: WCAG, unlike design principles, have litigable precision for exceptions |
| 09:08 | <hsivonen> | WCAG 2.0 that is |
| 09:08 | <Hixie> | WCAG 2.0 has precision? |
| 09:08 | <Hixie> | of any kind? |
| 09:08 | <hsivonen> | except where WCAG is incomprehensible without informative supporting materials |
| 09:08 | <Hixie> | good to know |
| 09:08 | <annevk42> | you can make things somewhat confusing too |
| 09:08 | <annevk42> | data:text/xml,<test x:xmlns="x" xmlns:x="x"/> |
| 09:08 | <Hixie> | that's only confusing because the order of the attributes is backwards :-P |
| 09:09 | <zcorpan> | "PS: Interestingly, this behavior could be used to send xhtml (and get it shown on IE) without sending different headers to each browser: Content-Type: text/html Content-Type: application/xhtml+xml" |
| 09:09 | <zcorpan> | why hasn't anyone thought of that before? |
| 09:10 | <annevk42> | violates HTTP? |
| 09:10 | <Philip`> | Because it's insane? |
| 09:10 | <Hixie> | does apache even let you do that? |
| 09:10 | <othermaciej> | I was thinking if there continues to be debate on whether the principles should be absolute, I could cite some examples from other domains |
| 09:10 | <zcorpan> | the PHP content negotiation scripts also violate HTTP and are insane |
| 09:10 | <hsivonen> | zcorpan: I see a new meme for all the cool people coming up |
| 09:10 | <Philip`> | and perhaps unlikely to survive proxies |
| 09:10 | <othermaciej> | Math: Every natural number is either prime or composite - except 1. |
| 09:11 | <zcorpan> | Hixie: i guess not in a simple way |
| 09:11 | <othermaciej> | Perl: There's more than one way to do it. -- but sometimes there is only one way, does this undermine the very foundations of Perl? |
| 09:11 | <Hixie> | when is there only one way?! |
| 09:11 | <Hixie> | that i want to see |
| 09:11 | <othermaciej> | Python: none of the principles are absolute, all are extremely vague: http://www.python.org/dev/peps/pep-0020/ |
| 09:12 | <othermaciej> | Hixie: I guess it would depend on what the definition of "one" is |
| 09:12 | <Philip`> | If there's one way to do it, call that way X; then you can do eval("X") and now there's two ways to do it |
| 09:12 | <Hixie> | even by a reasonable definition such that Philip`'s two things are considered the same |
| 09:12 | <othermaciej> | I think there's only one way to add two numbers, short of adding no-op layers of wrapping |
| 09:12 | <jgraham> | I think the difference between the python "design principles" and the HTML ones is rather telling |
| 09:12 | <Hixie> | adding two numbers... hmm |
| 09:12 | <philipj> | Hixie, where do keep that list of mails you have on your backlog where one can vote for important issues (but doesn't)? Google fails me. |
| 09:13 | <Philip`> | You can add two numbers with a lookup table |
| 09:13 | <Hixie> | philipj: whatwg.org/issues |
| 09:13 | <othermaciej> | jgraham: telling in what way? |
| 09:13 | <philipj> | thanks |
| 09:13 | <Hixie> | philipj: but if you have a specific request, just let me know :-) |
| 09:13 | <Hixie> | philipj: it'll be quicker for you :-) |
| 09:13 | <othermaciej> | jgraham: I wish we had enough community consensus that our design principles could be one-liners |
| 09:13 | <philipj> | just wondering if you forgot about the media resource selection algorithm feedback |
| 09:13 | <othermaciej> | but with a higher level of dissent, it's more useful to add some explanation |
| 09:14 | <jgraham> | othermaciej: e.g. the line "Although that way may not be obvious at first unless you're Dutch. |
| 09:14 | <Hixie> | philipj: "In the search loop, step 6 can never be reached because step 5 either goes to 1 or aborts the task. Simply removing "Otherwise, abort the task." should |
| 09:14 | <Hixie> | do the trick." |
| 09:14 | <Hixie> | philipj: ? |
| 09:14 | <Hixie> | philipj: or something else? |
| 09:14 | <hsivonen> | Hixie: example of WCAG 2.0 precision: zooming has a precise percent requirement: 200% |
| 09:14 | <othermaciej> | jgraham: you mean the fact that readers are expected to have a sense of humor? |
| 09:15 | <philipj> | not only that, but the part about async/sync inconsistencies with when src attr or <source> element is selected |
| 09:15 | <annevk42> | "Although that way may not be obvious at first unless you're Dutch." |
| 09:15 | <hsivonen> | Hixie: example of WCAG 2.0 imprecision: you can't tell without supporting materials if browser-native zoom satisfies the req |
| 09:15 | <annevk42> | Python is nice |
| 09:15 | <Hixie> | philipj: i thought i fixed that |
| 09:15 | <philipj> | let me have a look |
| 09:15 | <Hixie> | philipj: oh you mean src vs <source> |
| 09:15 | <Hixie> | philipj: i don't know of a way to fix that |
| 09:15 | <othermaciej> | annevk2: do you find it obvious? |
| 09:16 | <Hixie> | philipj: i have an e-mail from you starting "This is an improvement in predictability" |
| 09:16 | <philipj> | Hixie, is there a problem with the solution I suggested? |
| 09:16 | <jgraham> | othermaciej: The fact the community accepts humour and the fact that one of the design principles points out that perfect design is ulikely to happen |
| 09:16 | <hsivonen> | Hixie: my favorite is "Interruptions can be postponed or suppressed by the user, except interruptions involving an emergency." |
| 09:16 | <annevk42> | That I always make the right design decisions when writing Python because I'm Dutch seems very obvious and logical to me :) |
| 09:16 | <othermaciej> | heh |
| 09:17 | <Hixie> | philipj: i guess it might work, i'll have to look closer |
| 09:18 | <philipj> | I've implemented basically by ignoring step 5 "let src equal the first value that was assigned" and some minor changes |
| 09:18 | <Hixie> | philipj: k. i expect we can make that work. i'll get to it probably before the end of the month (unless you need the spec updated before then) |
| 09:19 | <philipj> | well as I said it's all in my mail, I just wanted to check if you had it in your backlog |
| 09:19 | <philipj> | there's no big rush as far as I'm concerned |
| 09:20 | <Hixie> | othermaciej: lol "Namespaces are one honking great idea -- let's do more of those!" |
| 09:20 | <Hixie> | philipj: yup, definitely got it |
| 09:21 | <othermaciej> | Hixie: not applicable in our context! |
| 09:23 | <jgraham> | With that exception (and a few others), I actually think that a lot of the Python design principles are things that we should be striving for |
| 09:25 | <annevk42> | just due to sheer complexity of the Web platform we sort of fail on "If the implementation is hard to explain, it's a bad idea." |
| 09:25 | <jgraham> | annevk42: But we should aim for that in new features |
| 09:25 | <jgraham> | At least at a high level |
| 09:26 | <jgraham> | I mean details of web security and so on will always be hard to explain so the details of new features will never be obvious |
| 09:26 | Philip` | wonders if there is a principle like "ignore principles that seem inconveniently contrary to our view of the world (e.g. ones that promote namespaces)" |
| 09:27 | <annevk42> | Philip`, I guess that principle is that not all programming principles apply to those of markup languages |
| 09:28 | <Philip`> | How does one decide which ones do apply? |
| 09:29 | <jgraham> | Philip`: Given an arbitary set of possibe principles? |
| 09:30 | <jgraham> | The ones that make sense based on experience, etc. If you get it wrong then it just means that the result will likely be bad |
| 09:30 | <annevk42> | Philip`, somewhat informed judgment? |
| 09:30 | <othermaciej> | jgraham: many of the new features fail |
| 09:30 | <othermaciej> | jgraham: for instance Workers - no way any implementation is going to be easy to explain |
| 09:31 | <othermaciej> | but hopefully the *interface* can remain easy to explain |
| 09:32 | <annevk42> | the difference is that Python is just a programming language, not so much an API to all kinds of features |
| 09:32 | <Philip`> | It's an API to an interpreter |
| 09:33 | <annevk42> | (and Python is also going to violate that principle once they get further with JIT'ing) |
| 09:33 | <jgraham> | othermaciej: Possibly that means that workers is too complex. Possibly it just means that the complexity is inevitable if you want that feature. |
| 09:33 | <jgraham> | But if we had a principle like that we would at least look to minimise internal complexity whereever possible |
| 09:33 | <jgraham> | (DOM consistency is rather similar) |
| 09:34 | <jgraham> | (but obviously more specific) |
| 09:34 | <Hixie> | i wonder if julian realises that complaining that i haven't replied to his e-mail is delaying my replying to his e-mail because i end up reading and responding to his e-mails complaining about it... |
| 09:38 | <othermaciej> | jgraham: I think there is inherent implementation to concurrency |
| 09:39 | <othermaciej> | but also, the message-passing model should have the least implementation complexity of various concurrency models |
| 09:40 | <othermaciej> | however I think Workers / MessagePorts may have more complexity than expected, as we are learning in the course of implementing in WebKit |
| 09:40 | <othermaciej> | jgraham: there is Avoid Needless Complexity |
| 09:41 | <othermaciej> | jgraham: but in general, I think it's more important to avoid interface complexity than implementation complexity |
| 09:41 | <Hixie> | i should go to bed |
| 09:41 | <othermaciej> | unless the implementation complexity required is truly excessive, and beyond what is reasonable for the feature in question |
| 09:43 | <hsivonen> | I should try to invoke Avoid Needless Complexity and Solve Real Problems against table taint |
| 09:44 | <hsivonen> | having a writable datum in stack nodes means speculative parsing needs to copy the nodes instead of holding references to the nodes from different speculations |
| 09:45 | <hsivonen> | woohoo! <datagrid> content model got sane |
| 09:45 | <zcorpan> | hsivonen: hmm i can't reopen your bug, but now it has more info |
| 09:46 | <hsivonen> | zcorpan: which bug? |
| 09:46 | <zcorpan> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=6978 |
| 09:47 | <zcorpan> | maybe it should be a per-document flag so that when it gets set, all further </script> tags are omitted in the serialization |
| 09:48 | <zcorpan> | but you could still make it run by inserting <style></script></style> |
| 09:48 | <zcorpan> | so not worth it i guess |
| 09:48 | <zcorpan> | maybe the whole script should be omitted instead |
| 09:49 | <zcorpan> | i.e. instead of serializing <script>contents, serialize <script></script> (or nothing) |
| 09:49 | <zcorpan> | i guess nothing is better considering <script src> |
| 09:50 | <zcorpan> | maybe script elements shouldn't be inserted in the dom until the end tag is seen? |
| 09:50 | <zcorpan> | during parsing |
| 09:52 | <hsivonen> | zcorpan: Deferring insertion would be annoying |
| 09:52 | <zcorpan> | yeah |
| 09:54 | <Hixie> | what is this solving, anyway |
| 09:56 | <zcorpan> | does IE do it? |
| 09:59 | <zcorpan> | nope |
| 09:59 | <zcorpan> | that opera does it might be a side-effect of wanting to be ie-compatible |
| 10:00 | <zcorpan> | though we emit more tags than ie does at the moment |
| 10:01 | <Hixie> | ok well i'm going to bed. |
| 10:01 | <Hixie> | nn. |
| 10:08 | <hsivonen> | Hixie: nn |
| 10:08 | <othermaciej> | gnight Hixie |
| 10:21 | annevk42 | thought Hixie was going to bed |
| 10:21 | <annevk42> | LIES! |
| 10:23 | othermaciej | wonders if chaals will eventually conclude that he's not saving any time by repeatedly making his same argument that getting rid of the design principles would save time |
| 10:24 | <annevk42> | time will tell -- harharhar |
| 10:35 | <othermaciej> | did my explanation/justification of the document make sense btw? |
| 10:35 | <othermaciej> | I know it ended up a bit close to TL;DR territory |
| 10:40 | <annevk42> | ok, let that be the last thing I read before I start packing for the CSS meeting |
| 10:40 | annevk42 | has a flight in 3 hours |
| 10:44 | <othermaciej> | ah, wouldn't want to miss that |
| 10:45 | <zcorpan> | Hixie: <a href="©="> is equivalent to <a href="©="> |
| 10:46 | <annevk42> | othermaciej, looks good |
| 10:46 | <annevk42> | othermaciej, I agree with Hixie that some of that should probably go into the introduction |
| 10:46 | <othermaciej> | annevk42: yeah, that suggestion made sense to me |
| 10:46 | <annevk42> | othermaciej, I also I agree with removing and adding principles as suggested in the end |
| 10:46 | <othermaciej> | annevk42: I will see what happens in the email discussion for a day or two before I do that |
| 10:47 | <othermaciej> | (either of those things) |
| 10:47 | <annevk42> | cool |
| 12:10 | <zcorpan> | my browsers have less spacing for <isindex> than what the spec gives (with implying <p>) |
| 12:16 | <zcorpan> | <isindex type=checkbox> |
| 12:21 | <zcorpan> | the spec matches ie at least |
| 12:22 | <zcorpan> | except for the p and the label |
| 12:25 | <Mrmil> | mmm coffee... |
| 12:51 | <gsnedders> | ezyang: http://stuff.gsnedders.com/phphtml5lib/ |
| 13:22 | <Philip`> | gsnedders: Why JPEG? |
| 13:24 | <Philip`> | Also, how did it spend 101.70% of its time inside {main}? |
| 13:31 | <gsnedders> | Philip`: Because it's sanely small :P |
| 13:31 | <gsnedders> | Philip`: Because it's not 100% reliable :P |
| 13:40 | <zcorpan> | is it 101.70% reliable? |
| 13:40 | <gsnedders> | zcorpan: Totally. |
| 13:44 | <Dashiva> | Well, ponder that statement. Is something that is 101.70% reliable a) more than 100% reliable, b) the same as 100% reliable, it makes no sense to speak of more, or c) less than 100% reliable, because it makes no sense to speak of more |
| 13:48 | <Lachy> | Dashiva, it means it performed better than expected or possible |
| 13:56 | <Lachy> | I'm a little confused about the changes regarding conformance of unescaped ampersands that are being discussed on the list. AFAICT, the spec still says that unescaped ampersands in attribute values are still ambiguous |
| 13:56 | <Lachy> | is it only the parsing section that has been changed to not emit a parse error? |
| 13:57 | <zcorpan> | Lachy: "or, if the character is in an attribute value, one or more characters in the ranges U+0030 DIGIT ZERO .. U+0039 DIGIT NINE, U+0041 LATIN CAPITAL LETTER A .. U+005A LATIN CAPITAL LETTER Z, and U+0061 LATIN SMALL LETTER A .. U+007A LATIN SMALL LETTER Z, followed by a U+003D EQUALS SIGN character (=)." |
| 13:57 | <hsivonen> | now I'm confused whether "RT" on twitter means re-tweet or reply to |
| 13:57 | <hsivonen> | I thought it was the former, but I see usage that looks like the latter |
| 13:57 | <Lachy> | hsivonen, it's supposed to mean re-tweet |
| 13:58 | <hsivonen> | ok. good |
| 13:58 | <Lachy> | some people must be misusing it |
| 14:00 | <Lachy> | that part zcorpan just quoted is what confused me. It's quite difficult to comprehend |
| 14:02 | Philip` | has non-fun trying to get Perl and Python implementations of YAML to interoperate |
| 14:02 | <Lachy> | and, after rereading it, I think it means that href="foo&bar=" not ambiguous, but href="foo&bar" is because it explicitly says it needs to be followed by an equals sign |
| 14:02 | <Philip`> | (particularly for handling Unicode characters) |
| 14:02 | <Lachy> | (though, I would'nt be surprised if I still got that wrong, since the paragraph is so badly written) |
| 14:12 | gsnedders | blames Hixie |
| 14:16 | <Philip`> | Doesn't it just mean an ampersand is ambiguous if it doesn't match /&(\s|<|&|[0-9A-Za-z]+=)/? |
| 14:16 | <Philip`> | (which would be odd because & would be defined as ambiguous, I guess) |
| 14:19 | <jgraham> | Philip`: Do they interoperate on non-Unicode characters? |
| 14:20 | <Philip`> | jgraham: Not quite |
| 14:20 | gsnedders | wonders how long `git blame -L '/>Tokeni/,/>Tree construct/' source` will take to run |
| 14:20 | <Philip`> | One library outputs strings like "foo \ |
| 14:20 | <Philip`> | bar" |
| 14:20 | <Philip`> | (using the slash to escape the newline because it's just there for pretty wrapping) |
| 14:20 | <Philip`> | and a different library parses that as a literal \ in the string |
| 14:21 | <Philip`> | I should probably use a different interchange format, like JSON |
| 14:21 | <Philip`> | but I think it works now so I'm not going to change it |
| 14:27 | <jgraham> | http://blog.digitalbazaar.com/2009/05/31/admitting-that-javascript-was-a-mistake/ makes the exciting claim that Javascript was a mistake because it is a functional programming language |
| 14:36 | <Philip`> | jgraham: and that we should use a procedural language like Python instead |
| 14:37 | <Lachy> | "Debugging in general (which would be impossible without Firebug)." -- clearly, that's not true. Venkman was a great debugger well before firebug |
| 14:44 | <Lachy> | using python in browsers instead of JavaScript would be an even bigger mistake, cause then we'd have to deal with the insane, unintuitive design of python |
| 14:54 | <Philip`> | Lachy: Why is that worse than the insane, unintuitive design of JavaScript? |
| 14:54 | <jgraham> | Lachy: There is really nothing wrong with Python |
| 14:54 | <jgraham> | It's not really designed to go in browsers though |
| 14:54 | <Philip`> | I imagine one serious problem would be either the language would fork, or the language in one environment (in-browser vs out-of-browser) would have to make huge sacrifices for the other |
| 14:55 | <Philip`> | where nobody sensible uses JS outside of browsers, so there aren't widely-diverging demands on it |
| 14:55 | <jgraham> | Philip`: Indeed. JS-as-a-language has basically taken success in the browser at the expense of no success outside the browser |
| 14:56 | <Lachy> | Philip`, the design of javascript is more intuitive than python, though I admit it does have some concepts like closures and prototype chains that can be difficult to grasp |
| 14:57 | <jgraham> | Lachy: I would toatlly love evidence backing up that statement |
| 14:57 | <Lachy> | jgraham, which part of the statement? The complexity of closures and prototype chains, or that it's more intuitive than python? |
| 14:58 | <jgraham> | Because I think basically exactly the opposite; python has a few tough features but is basically sane whereas js is basically complex all the way through |
| 14:58 | <jgraham> | Lachy: The intuitivemenss part |
| 14:59 | <Philip`> | I think Perl is sane, so I don't have problems with either JS or Python |
| 15:01 | <jgraham> | As a random example javascript will allow you to do Constructor() (without "new") to execute a constructor function and not only will you not get the Object you were expecting back you will probably mess up the global namespace |
| 15:02 | <Lachy> | calling Constructor() without "new" is just a regular function call |
| 15:02 | <jgraham> | Lachy_: That's the point |
| 15:02 | <jgraham> | function Construct() {this.a = 2}; b = Construct() |
| 15:02 | <jgraham> | Sets a global variable a to 2 |
| 15:04 | <Lachy> | as an example of a completely backwards and unintuitive feature in python, to join an array of strings with some delimiter, instead of calling array.join(delim), you have to call "delim".join(array) |
| 15:05 | <Lachy> | and they use weird names like lists and dictionaries instead of array |
| 15:06 | <jgraham> | Lachy: I thought that was crazy untill I realised that doing an operation on a string and getting a string back is more consistent than doing an operation on an array and getting a string back |
| 15:07 | <Lachy> | no, doing an operation on the object itself (an array in this case) to obtain some output makes much more sense from an object oriented programming perspective |
| 15:07 | <jgraham> | Lachy: They are actually rather good names. "array" implies things that aren't necessarily true |
| 15:07 | <Lachy> | like what? |
| 15:07 | <jgraham> | (moreso in js than in python even) |
| 15:08 | <Philip`> | Like O(1) access time |
| 15:08 | <jgraham> | Lachy: a = new Array(); a[Math.pow(2,32)-1] = 1; |
| 15:09 | <jgraham> | Lachy: Ho much memory does that use and how fast would it be enumerated? |
| 15:09 | <jgraham> | s/Ho/How/ |
| 15:09 | <Dashiva> | -2, surely |
| 15:10 | <jgraham> | Dashiva: Oh yeah, sorry |
| 15:11 | <Philip`> | Why -2? |
| 15:11 | <Dashiva> | Otherwise .length can overflow |
| 15:12 | <Philip`> | Ah |
| 15:12 | <jgraham> | Philip`: Array index properties have to be < 2^32 -1 |
| 15:12 | <Lachy> | indeed, it does overflow. a.length returns 0 in the first case |
| 15:12 | <jgraham> | Lachy: That's a bug |
| 15:13 | <jgraham> | Or maybe I'm wrong. |
| 15:13 | <Lachy> | Both Opera and Firefox do the same thing |
| 15:14 | <jgraham> | Yeah it is common behaviour. I thought it was a bug specwise but maybe something that has been adopted as common behaviour |
| 15:15 | <Dashiva> | It's a bug specwise, yes. But what does that matter :P |
| 15:15 | <Lachy> | jgraham, anyway, in answer to your question, if you created a list of the same length in python, how much memory would it use and how fast would it be enumerated? |
| 15:16 | <Philip`> | You can't assign to random indexes, without allocating the space first |
| 15:16 | <Philip`> | (using append, extend, etc) |
| 15:19 | <Lachy> | Philip`, sure, I'm not concerned about the specific method used to create the list of that length. My question was just pointing that the the performance question also applies to python under the same circumstances |
| 15:20 | <Dashiva> | I think his point is that in Python some of the things implicit in JS are made explicit |
| 15:20 | <Lachy> | the implicit features in JS are a nice feature to have |
| 15:21 | <Philip`> | Lachy: The same circumstances don't exist in Python |
| 15:21 | <Lachy> | Philip`, surely you can create a list of that length in some way though |
| 15:22 | <Philip`> | Lachy: Only if you fill in all the intermediate values |
| 15:22 | <Philip`> | Lachy: which is different to what the JS example is doing |
| 15:23 | <Lachy> | well, than that's a point to JS then cause being able to create arrays of that length without needing to fill in all the intermediate values explicitly, at least until they need a non-undefined value, is a feature |
| 15:25 | <Philip`> | I think jgraham's point was that that feature in JS clearly can't be implemented with the data structure that's typically called an array |
| 15:26 | <jgraham> | Lachy: It is not at all obvious that something called an "Array" would actually be a hashtable, or something similar under the hood |
| 15:26 | <Philip`> | and so it's misleading to call it "Array" in JS |
| 15:28 | <Lachy> | the underlying technical implementation is really irrelevant to whether or not it's an array |
| 15:30 | <Lachy> | the fact that it can be used as a stack, queue, hash table or array may be a reason to not call it just an array though, but that's a very minor issue |
| 15:30 | <Philip`> | The underlying technical implementation is critical to the distinction between arrays and lists and hashtables and hybrids |
| 15:31 | <Philip`> | and people should understand the distinctions, so they don't write silly code that has terrible performance |
| 15:31 | <jgraham> | Lachy: Also there are plenty of thother things; var a = {}; a[1]="a"; a["1"] = "b"; //oops I overwrote my key |
| 15:32 | <jgraham> | The fact the assignment creates globals |
| 15:32 | <jgraham> | The with statement |
| 15:33 | <Philip`> | Optional semicolons |
| 15:33 | <Lachy> | yes, the with statement is a mistake, just like the goto and break statements in other languages |
| 15:33 | <jgraham> | eval |
| 15:33 | <jgraham> | (Yes I know Python has eval but it is almost never used) |
| 15:34 | <jgraham> | (and it is much worse in a web context) |
| 15:34 | <Lachy> | people who use eval in javascript are usually clueless programmers (or they're using it for JSON parsing, despite the security problems) |
| 15:36 | <Philip`> | I know someone who used eval("a."+b) because they weren't aware that a[b] was equivalent |
| 15:36 | <jgraham> | the way that enumeration works |
| 15:36 | <jgraham> | A bunch of stuff that should get better in ES5 wrt defining object properties |
| 15:37 | <Rik|work> | Philip`: I believe it's one of the most reason people use eval |
| 15:37 | <jgraham> | the fact that strings, booleans and numbers have two different representations |
| 15:37 | <Philip`> | The use of '+' for both string concatenation and addition |
| 15:37 | <jgraham> | One of which is totally useless except for spec-internal algorithms |
| 15:37 | <gsnedders> | How many parse errors should "<!DOCTYPE" produce? I, and the PHP impl., think 1 (as of the change in spec of 2009-05-26). The test case says 2. |
| 15:37 | <gsnedders> | (Likely answer: test case is unchanged.) |
| 15:38 | <gsnedders> | s/26/24/ |
| 15:38 | <jgraham> | Philip`: Never had a problem with that but the implicit type shifiting is odd |
| 15:39 | <jgraham> | also == vs === |
| 15:39 | <jgraham> | Object equality |
| 15:39 | <jgraham> | [1,2,3] != [1,2,3] |
| 15:42 | <gsnedders> | What should "<a a=a&>" output? |
| 15:42 | <gsnedders> | (From the tokenizer) |
| 15:47 | <gsnedders> | "If no match can be made, then no characters are consumed, and nothing is returned. If the current state is not the character reference in attribute value state, or the U+0026 AMPERSAND character is not followed by one or more characters in the ranges U+0030 DIGIT ZERO to U+0039 DIGIT NINE, U+0041 LATIN CAPITAL LETTER A to U+005A LATIN CAPITAL LETTER Z, and U+0061 LATIN SMALL LETTER A to U+007A LATIN SMALL LETTER Z, fo |
| 15:47 | <gsnedders> | by a U+003D EQUALS SIGN character (=), then this is also a parse error." |
| 15:47 | <gsnedders> | That really doesn't read well. |
| 15:49 | <gsnedders> | So in the character reference in attribute value state then "&foo=" is a parse error, but "&foo" is not, right? |
| 15:49 | <gsnedders> | Wrong way round. |
| 15:50 | <gsnedders> | "&foo=" is not a parse error, "&foo>" is. |
| 15:52 | <gsnedders> | "<a a=a&>" is right in the test, my impl. is not. |
| 15:54 | <Lachy> | http://www.molly.com/2009/06/02/why-xhtml2/ |
| 15:56 | <beowulf> | the listed advantages are not familiar to me as an html author |
| 15:57 | <beowulf> | actually, i want to smash things now |
| 15:57 | <Lachy> | http://twitter.com/mollydotcom/status/2004173388 |
| 15:57 | <Lachy> | apparently, there's a new version of that article coming |
| 15:58 | <Lachy> | "Search engines are ‘user agents’ that don’t support frames!" - I've never once seen any evidence to support that claim |
| 15:59 | <Lachy> | in fact, the first result returned is a framed page: http://www.google.com/search?q=Java+docs |
| 15:59 | <Lachy> | so it's a bogus claim |
| 16:00 | <beowulf> | an advantage of xhtml2 to an html author is "CSS gives more presentational possibilities than plain HTML" |
| 16:00 | <beowulf> | i know you all think html authors are stupid, but that's insulting |
| 16:01 | <Lachy> | yeah, I read that and wondered why a general advantage of using CSS was listed as one specifically benefiting XHTML2 |
| 16:02 | <beowulf> | "Visible on more devices" # gah |
| 16:03 | <Lachy> | of course, that claim is based in a theoretical future world in which support for XHTML2 has been added to devices and the number outweighs the number of devices that support HTML today |
| 16:04 | <jgraham> | The claim is based on the erronous assumption that it is not possible to parse HTML on small devices |
| 16:05 | <jgraham> | WWhich is just crazy given that there are small devices shipping with HTML parsers today and even smaller devices that render html content using e.g. mini |
| 16:05 | <beowulf> | that claim is based on never having written anything for a small device |
| 16:06 | <beowulf> | and most of those claims are based on never having worked on html more complicated than a w3c page |
| 16:06 | <Lachy> | later tonight, after Molly posts the proper version of that post, I will blog a detailed rebuttal of all his bogus points |
| 16:09 | <beowulf> | i find that whole 'less presentation, more structure' section insulting |
| 16:11 | <Lachy> | LOL. I missed this one the first time through: "Advantages: All the ones that you can imagine, because XML is a Good Thing" |
| 16:12 | <beowulf> | fair enough, i don't mind if it's xml or text, but some of those points are written by someone who's guessing what most people do, or so it would seem to my dumb html author mind |
| 16:15 | <Lachy> | beowulf, it's written by Steven Pemberton |
| 16:16 | <beowulf> | Lachy: who's he? |
| 16:17 | <Lachy> | XHTML2 WG chair |
| 16:17 | <Lachy> | or, at least member, if he's not the chair, but I'm pretty sure he is |
| 16:19 | <Lachy> | http://www.molly.com/2009/06/02/the-real-why-xhtml-discussion/ |
| 16:21 | <Lachy> | "Now, if HTML had never had a lax parser, but had always been strict, there wouldn’t be an incorrect (syntax-wise) HTML page in the planet, because everyone uses a ’suck it and see’ approach" |
| 16:22 | <Lachy> | I wonder how he explains the presense of non-well-formed XHTML and SVG on the web |
| 16:29 | <takkaria> | "HTML is just not addressing the use cases of the real world any more." hmm |
| 16:31 | <Philip`> | Lachy_: That viewpoint seems to be limited to the case where people write a small number of static pages and look at them all to see that they're correct |
| 16:31 | <Philip`> | which was perhaps a valid viewpoint in 1995 |
| 16:32 | <Philip`> | but now everything is dynamic and mashed up, so your site's visitor is the first person in the world to see a particular page and encounter any errors on it |
| 16:34 | Philip` | reads the blog post |
| 16:35 | <jgraham> | Philip`: Despite which there are a lot of conversations around HTML which revolve around the 1995 model being a good approximation to the truth |
| 16:35 | <Philip`> | "2. Look at it in the browser, if there is a problem, fix it, and look again." - ah, that seems to be where the problem is, because most sites contain an infinite number of pages and you can't look at them all in your browser when developing the site |
| 16:36 | <Philip`> | "I want the browsers to tell me when my pages are wrong" - sounds like a job for a validator |
| 16:37 | <jgraham> | What's the URL to the number of outstanding emails that Hixie has? |
| 16:37 | <Philip`> | (possibly a validator that's built in to the browser as an extension) |
| 16:37 | <jgraham> | (the really slow canvas graph one) |
| 16:40 | <Philip`> | jgraham: http://www.whatwg.org/issues/data.html ? |
| 16:40 | <jgraham> | Philip`: Yes |
| 16:40 | <jgraham> | Thanks |
| 16:58 | <gsnedders> | And we're back in 2010 for the due date |
| 17:09 | <gsnedders> | Hixie: Can you add an id to the NCR table? |
| 17:30 | <gsnedders> | "<!DOCTYPE" should return one parse error now, right? |
| 17:33 | gsnedders | commits it seeming nobody argues otherwise :P |
| 17:33 | <gsnedders> | (And it was the specific aim of the spec change to make it only return one parse error) |
| 17:34 | <shepazu> | Lachy_: there is little or no non-well-formed SVG on the web, fwiw |
| 17:35 | <shepazu> | there is some SVG that is invalid because Adobe's viewer allowed magic namespaces |
| 17:36 | <jgraham> | shepazu: Ho much SVG is created by automatic tools? |
| 17:36 | <jgraham> | (Other than e.g. inkscape) |
| 17:36 | <shepazu> | as far as XHTML, I seriously doubt there is much non-well-formed XHTML that is served exclusively as XHTML, and not text/html |
| 17:37 | <shepazu> | jgraham: I have no way of knowing that... |
| 17:37 | <shepazu> | but there was a lot of hand-generated SVG back in the early days, the majority, perhaps |
| 17:37 | <shepazu> | before Inkscape, definitely the vast majority |
| 17:38 | <shepazu> | there was also script-generated SVG, which will of course be non-WF |
| 17:38 | <shepazu> | unless it's generated as strings, I suppose |
| 17:39 | <shepazu> | but it didn't make it to the web, because it would have been corrected when it didn't work |
| 17:41 | <shepazu> | so, Lachy_'s premise doesn't seem to be borne out by reality |
| 17:41 | <gsnedders> | How does <x x=1 x=2 X=3> give two parse errors? |
| 17:41 | <jgraham> | gsnedders: How many did you expect? |
| 17:41 | <gsnedders> | jgraham: One. |
| 17:42 | <gsnedders> | One for each duplicated attribute? |
| 17:42 | <shepazu> | no, one could argue that this prevented or slowed the uptake of SVG, but that's another matter (and I think it's far less critical than that it was not supported by browsers and people had to download the Adobe viewer) |
| 17:42 | <jgraham> | gsnedders: Don't you lowercase the attribute name in the tokenizer? |
| 17:42 | <gsnedders> | jgraham: Yes. |
| 17:42 | <shepazu> | bbl |
| 17:43 | <jgraham> | gsnedders: So you end up with 3 x attributes, giving two parse errors, no? |
| 17:43 | <gsnedders> | jgraham: I didn't know whether the spec gave one parse error when it hit the first dupe or for all |
| 17:44 | <jgraham> | gsnedders: I'm not reading the spec of anything. But I would expect 2 in some naive way |
| 17:44 | <gsnedders> | The spec says 2 |
| 17:44 | <gsnedders> | I was being naïve and assuming the other logical option :P |
| 17:47 | <Philip`> | shepazu: "I seriously doubt there is much non-well-formed XHTML that is served exclusively as XHTML, and not text/html" - I agree with that doubt, but that's because I doubt there is much XHTML (regardless of well-formedness) that is served exclusively as XHTML |
| 18:46 | <gsnedders> | "<x x x" should output two parse errors, right? One for dupe attr, and one for EOF? |
| 19:31 | <jgraham> | gsnedders: It seems bad to point to RFC2119 and say "oh we can't have a must requirement about that because browsers will interoperate" |
| 19:33 | <jgraham> | Because RFC2119 is clearly not written to deal with the situation that HTML is in where most authors are unaware of the specs and all implementations have to be error correcting |
| 19:34 | jgraham | wonders what the bad side effects of saying "HTML documents must be UTF8 encoded" would be |
| 19:34 | <jgraham> | Apart from the fact that it wouldn't match the default |
| 19:35 | <jgraham> | I gues you could say "HTML documents must be UTF8 encoded and must have <meta charset=utf8>" |
| 19:36 | <jgraham> | I can't see people going fo this though |
| 19:36 | <tantek> | jgraham you would simply have to define the processing model for when an HTML processor encountered an HTML document that was not encoded in UTF8. |
| 19:36 | <jgraham> | tantek: Of course the actual processing would have to work like it does today |
| 19:37 | <jgraham> | This would purely be an author requirement |
| 19:38 | <jgraham> | At the very least it seems sensible to remove the ASCII loophole for declaring encodings |
| 19:38 | <tantek> | by "remove" do you mean "must ignore"? |
| 19:39 | <tantek> | you can't really "remove" anything from the author's array of options, you can only make it "do nothing" or have some other minimal effect. |
| 19:39 | <jgraham> | tantek: I mean make it mandatory to declare ascii documents wither in <meta> or through headers |
| 19:40 | <jgraham> | at the moment non-ascii has to be declared to be conforming, ascii does not |
| 19:40 | <tantek> | I'm not sure what that means unless you define what happens when authors don't do it. |
| 19:40 | <jgraham> | tantek: In terms of implementation requirements it doesn't mean anything |
| 19:41 | <jgraham> | Implementations still have to look at HTTP headers, <meta> elements, use heuristics or fall back to win-1252 |
| 19:41 | <jwalden> | Lachy_: that's not overflow; 2**32-1 is not an array index property, so setting it has no effect on the length property |
| 19:41 | <jgraham> | jwalden: You would have thought so |
| 19:42 | <jgraham> | If you, say, read the spec. But the real world disagrees |
| 19:42 | <jwalden> | jgraham: no, that's exactly how the browsers work |
| 19:43 | <jwalden> | arrays-as-objects with all the concomitant baggage was a flaw, but the real world does pretty well with them anyway |
| 19:43 | <jgraham> | Oh wait a second my test earlier was totally wrong |
| 19:44 | <jgraham> | jwalden: Yes you are quite right. Apolologies for doubting you :) |
| 19:45 | <jgraham> | s/lo// |
| 19:45 | <jwalden> | no worries :-) |
| 19:45 | <jwalden> | I've stared long and hard at the array-index-property parts of es3 |
| 19:46 | <jwalden> | frankly, arrays-as-objects is probably a bigger problem for implementations than for developers, since the convert-to-sparse determination is unspecified but necessary for performance and constraining memory use |
| 19:49 | <jwalden> | it's also a compatibility concern: SpiderMonkey has specifically tweaked its thresholds to perform better on certain JS benchmarks promulgated by the authors of engines which have different thresholds that don't fall over on said tests |
| 19:49 | <jwalden> | I do so love benchmarketing |
| 19:51 | <jwalden> | (threshold for sparsifying, to be clear, although I would be surprised if others haven't been similarly tweaked) |
| 19:51 | <Hixie> | heycam: yt? i was wondering if you'd done anything on http://mcc.id.au/2009/01/string-handling/string-handling recently or had any plans to do more |
| 19:52 | <jgraham> | jwalden: It is pretty surprising for authors if things that are instantaneous in one browser take an excessive amount of time in others |
| 19:53 | <jwalden> | this wasn't "excessive" amounts of time, though, it was time measured in dozens of milliseconds |
| 19:53 | <jwalden> | efficiently storing array properties is faster than doing a generic property-hash-storage system, but it's not order-of-magnitude slower, not enough for authors to get confused about it |
| 19:54 | <jgraham> | jwalden: Yeah I agree about a few milliseconds on typical microbenchmarks not being so important |
| 19:57 | <jwalden> | this is what benchmarketing drives you to do :-\ |
| 20:09 | gsnedders | wonders if there is any nice way to fix the horridness of PHP html5lib without making it slower |
| 20:10 | <ezyang> | Reimplement it in C |
| 20:11 | <Hixie> | jwalden: just make a benchmark that needs the optimisation you think is better for real world pages |
| 20:12 | <gsnedders> | ezyang: yeah, without doing that? :P |
| 20:12 | <ezyang> | I mean, to a certain extent it would be smart |
| 20:12 | <ezyang> | At the very least, tokenization is something that probably should be in C |
| 20:13 | <gsnedders> | ezyang: I think any any extent it would be smart :P |
| 20:13 | <gsnedders> | s/any/to/ |
| 20:13 | gsnedders | has the tokenizer working as an iterator now |
| 20:13 | <gsnedders> | we're talking 50% slower. |
| 20:13 | <ezyang> | Not surprising |
| 20:14 | <ezyang> | Turning it into an iterator means you get all of those function calls we oh so cleverly removed back |
| 20:14 | <ezyang> | And more |
| 20:14 | <gsnedders> | Yup |
| 20:15 | <gsnedders> | It's interesting that it is actually slower than having all the function calls within the tokenizer |
| 20:15 | <gsnedders> | I mean, there are probably around the same number as I have it now. |
| 20:15 | <ezyang> | That's because iterator generates a bunch more calls |
| 20:15 | <ezyang> | Like, it checks if you're at the end() on every round |
| 20:15 | <gsnedders> | ezyang: I know, but I mean including those |
| 20:15 | <ezyang> | Hmm, unclear. |
| 20:16 | gsnedders | wonders if it the calls to array_shift |
| 20:16 | <gsnedders> | (as that is O(n) |
| 20:16 | gsnedders | profiles |
| 20:16 | <ezyang> | array_shift() shouldn't be O(n)... |
| 20:17 | <ezyang> | But I suppose PHP's array implementation would make it so. |
| 20:17 | <gsnedders> | It is. It re-indexes everything. |
| 20:17 | <gsnedders> | There's an SPL queue in 5.3… |
| 20:17 | gsnedders | sighs |
| 20:18 | <ezyang> | If you want, you can branch and work on PHP5.3 only |
| 20:18 | <gsnedders> | No point |
| 20:18 | <gsnedders> | What we could do if create a class which implements the queue like bit of the weird SPL queue structure and use arrays internally there |
| 20:18 | <gsnedders> | array_shift isn't that bad actually |
| 20:19 | <ezyang> | Don't boher with that, then |
| 20:19 | <gsnedders> | It's the same culprits as before |
| 20:19 | <gsnedders> | It's all function call overhead more or less… |
| 20:19 | <gsnedders> | Did I say how much I love PHP yet? |
| 20:19 | <ezyang> | Maybe you're interpreting the results wrong? |
| 20:20 | <gsnedders> | I reckon 15% of the cost to be the function calls foreach creates. |
| 20:22 | ezyang | puts html5lib performance on his queue of things to do after work |
| 20:23 | <Philip`> | Please feel free to optimise the Python html5lib too |
| 20:23 | gsnedders | was really trying to do this to get the final few test cases to pass |
| 20:24 | <gsnedders> | I guess we could do the not-so-nice way the Python impl does it |
| 20:24 | <Philip`> | What's not-so-nice about it? |
| 20:24 | <gsnedders> | Philip`: Just think about who wrote it :P |
| 20:24 | <Philip`> | Uh... annevk2? |
| 20:25 | <ezyang> | What really needs to happen is the core string manipulation stuff needs to be written out in C |
| 20:25 | <ezyang> | And then we make wrappers around it in all the appropriate languages |
| 20:25 | <Philip`> | or jgraham? |
| 20:25 | <gsnedders> | ezyang: That's not the problem. The most expensive thing is the tree construction. |
| 20:25 | <gsnedders> | ezyang: http://stuff.gsnedders.com/phphtml5lib/ |
| 20:25 | <ezyang> | Oh, well, then you should factor out the tree-specific stuff, and then make the SimpleTree impl. |
| 20:25 | <gsnedders> | Well, that isn't always true |
| 20:26 | <gsnedders> | That's never true :P |
| 20:26 | <gsnedders> | Oh well. |
| 20:26 | <gsnedders> | Ignore me. |
| 20:26 | <gsnedders> | :P |
| 20:26 | <gsnedders> | With the spec the most expensive thing is DOMNode->appendChild :P |
| 20:26 | <ezyang> | gsnedders: Screens don't do anything for me. The great thing about *CacheGrind is you can reframe the data and look further |
| 20:26 | <gsnedders> | ezyang: Indeed. But some people wanted to see |
| 20:27 | <jgraham> | gsnedders: Did you have an actual point about python html5lib or are you just casting aspersions? |
| 20:27 | <annevk2> | gsnedders, hey, I read that! |
| 20:27 | <gsnedders> | jgraham: Just insofar as it diverges from the spec. |
| 20:27 | <gsnedders> | annevk2: :D |
| 20:27 | gsnedders | buys annevk2 a beer… next year. |
| 20:27 | <Philip`> | gsnedders: The spec is meant to be diverged from |
| 20:27 | <jgraham> | gsnedders: In what way? |
| 20:28 | <Philip`> | gsnedders: (That's why it says that any algorithm which produces equivalent output to the specified one is acceptable) |
| 20:28 | <jgraham> | Apart from known issues with failing tests? |
| 20:28 | <ezyang> | Philip`: You have to admit, though; it's a lot easier (w.r.t. to maintainability) to do that once the spec is stable. |
| 20:28 | <gsnedders> | Philip`: I know :P |
| 20:29 | gsnedders | would quite like to write an impl. that uses something like Parsec |
| 20:29 | <Philip`> | ezyang: Indeed, but hopefully there are enough test cases and enough independent implementations that any problems caused by spec changes can be found relatively easily |
| 20:29 | <jgraham> | Somehow the headline "Microsoft unveils new controller" sounds rather sinister |
| 20:30 | <roc> | One Microsoft Way! |
| 20:31 | <ezyang> | It takes me on average about thirty minutes to resolve a spec-code impedance. Maybe towards the end it was 15 minutes, after I got good at figuring out what was different. |
| 20:34 | <gsnedders> | ezyang: Practice! :P |
| 20:35 | <ezyang> | My point, though, is that even when the code is ~ the spec, it's nontrivial to resolve bugs. |
| 20:35 | <ezyang> | And it can onl get worse |
| 20:35 | <gsnedders> | ezyang: Solution: read all diffs with spec :P |
| 20:36 | <gsnedders> | ezyang: I brought the tokenizer up to date with the spec, FWIW |
| 20:36 | <jgraham> | gsnedders: That's not a very practical solution |
| 20:36 | <ezyang> | gsnedders: Awesome |
| 20:37 | <gsnedders> | ezyang: (and had to update a few test cases which means probably everything else fails now) |
| 20:37 | <gsnedders> | ezyang: I rewrote the entire NCR handling so we don't consume so much |
| 20:38 | <ezyang> | About 80% I thought I had to update a test-case, it was actually my fault |
| 20:38 | <ezyang> | You should probably double check. |
| 20:39 | <gsnedders> | ezyang: The aim of the commit in the spec was to reduce to one parse error from two. I just did that in the test :P |
| 20:41 | <ezyang> | Oh, that was the only change |
| 20:41 | <ezyang> | Yeah, that sounds legit |
| 20:42 | <gsnedders> | The other thing I did to test suite was add one test that I broke in uncommitted code locally |
| 20:48 | gsnedders | wonders about getting hsivonen's parser working as a PHP ext |
| 20:48 | <ezyang> | Nonono! |
| 20:48 | <ezyang> | It has to be C. |
| 20:48 | <gsnedders> | ezyang: Uh, surely we can get C++ to work? |
| 20:48 | <ezyang> | C++ is not acceptable |
| 20:48 | <ezyang> | It has a horrid time integrating back to C |
| 20:49 | <ezyang> | And most bindings work better with C code than C++ |
| 20:49 | <jgraham> | gsnedders: Write a parser in brainfuck and then write a brainfuck to C compiler |
| 20:49 | <jgraham> | No need to write C |
| 20:51 | <gsnedders> | ezyang: That's more work :P |
| 20:54 | <jgraham> | ezyang: Attributes like xlink:href in <body> should have local name "xlink:href" and be in no namespace, unless that changed recently |
| 20:54 | jgraham | sees no evidence for such a change |
| 20:55 | <ezyang> | jgraham: Oh? |
| 20:55 | <ezyang> | Where in the spec does it say that? |
| 20:56 | <jgraham> | ezyang: Where in the spec does it say otherwise :) |
| 20:56 | <jgraham> | The only time that you insert attributes in a namespace is when you adjust foreign attributes for a token |
| 20:56 | <jgraham> | Which only happens for foreigncontent |
| 20:56 | <jgraham> | afaik |
| 20:57 | <gsnedders> | Hmm… "When an end tag token is emitted with attributes, that is a parse error." is hard to implement when once you've hit attributes you still don't know it'll actually be emitted |
| 20:57 | <ezyang> | Ah. That's probably right. |
| 20:57 | <gsnedders> | ezyang: Also, why are there things related to foreign content commented out in tokenizer? |
| 20:57 | <ezyang> | You should revert those changes (or I can revert them) |
| 20:57 | <ezyang> | gsnedders: Not sure what you're talking about |
| 20:57 | <gsnedders> | ezyang: seee // XXX not implemented |
| 20:57 | <ezyang> | jgraham: I know exactly why I thought that was otherwise the case |
| 20:58 | <jgraham> | ezyang: I can revert them if you like |
| 20:58 | <ezyang> | gsnedders: Oh, I never implemented that |
| 20:59 | <ezyang> | Please do so. |
| 20:59 | gsnedders | wonders why test cases don't test that |
| 20:59 | <ezyang> | jgraham: That would be loverly. Also, update the wiki page to mention the difference between "xlink href" and "xlink:href" |
| 20:59 | <ezyang> | It's very subtle |
| 21:00 | <jgraham> | ezyang: If you have the wiki page can you update it? I would need to find it... |
| 21:01 | <ezyang> | http://wiki.whatwg.org/wiki/Parser_tests |
| 21:01 | <ezyang> | I lost my account info |
| 21:22 | <jwalden> | Hixie: it's not that I don't think the optimization is bad, it's that the dividing point between when and when not to optimize is not being determined by real-world scripts but rather by artificial use in benchmarks |
| 21:22 | <jwalden> | heycam: fyi, http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0720.html |
| 21:22 | gsnedders | never ceases to be amazed by how bad RSS/Atom are created |
| 21:23 | <Dashiva> | hehe |
| 21:24 | <Dashiva> | JF linking to his blog reminded me about "small and narrow minds" |
| 21:24 | <Dashiva> | We haven't really come far from back there... |
| 22:35 | <zcorpan> | "Wow, cool! There’s been a rip in the space/time continuum and this article has slipped through from 1998!" - http://www.molly.com/2009/06/02/the-real-why-xhtml-discussion/ |
| 22:40 | <arun__> | zcorpan, hah :) |
| 22:41 | <arun__> | He had me at "books are dead." |
| 23:35 | <Dashiva> | "XML parsing is really easy. It is rather trivial to write an XML parser." |