| 00:02 | <othermaciej_> | Hixie: hilarious |
| 00:04 | <jgraham__> | I really have no idea how one would respond to the TAG's finding that transmitting passwords in plain text is A Bad Idea... |
| 00:05 | <Philip`> | We should respond by deprecating <input type="password"> if the document has been served over HTTP |
| 00:06 | <jgraham__> | Philip`: That wouldn't help because it would just make people more likely to use something that didn't even do password masking |
| 00:08 | <jgraham__> | (or to roll their own solution, or to use javascript to set the input type to password) |
| 00:25 | <takkaria> | I would like to know why they spent so much time working out that transmitting passwords in the clear is bad |
| 00:33 | Philip` | has a site which just sends username=foo, password=whatever cookies on every request |
| 00:35 | <Philip`> | "When a password is transmitted in clear text, it is vulnerable in many ways:" "2. The password is available in browsing history. Most web browsers provide 'back' navigation to previous pages, with content locally cached for performance as well as ease of use for the user. These pages are stored in memory and are relatively easy to examine." - what has that point got to do with transmission? |
| 00:35 | <Philip`> | Caching of form field values seem orthogonal to any issues of clear/encrypted transmission |
| 00:35 | <Philip`> | *seems |
| 00:36 | <Philip`> | "It is estimated that between 1 and 2 percent of e-commerce transactions are related to fraud." [citation needed] |
| 00:38 | <Philip`> | It would be helpful if they defined what a password is |
| 00:39 | <Philip`> | If I'm typing my pet's name into a "forgot your password?" page, does that count as a password itself? |
| 00:39 | <Philip`> | What if it's a one-time password, and nobody could use it later even if they intercepted it? |
| 00:40 | <Philip`> | "There are no scenarios where it is possible to transmit passwords in the clear without risk." - how about connecting to my local router's web interface? |
| 00:41 | <Philip`> | The only machines involved are mine and the router, so nobody's going to be able to intercept anything during transmission |
| 01:00 | <Hixie> | yay http://www.google.nl/intl/nl/doodle4google/ |
| 01:00 | <Hixie> | (look at the source) |
| 01:01 | <Philip`> | It's non-conforming :-( |
| 01:02 | <Philip`> | <img src="images/logo.png" alt="Google"> needs to say alt="Doodle 4 Google - Mijn Nederland" to be equivalent to the image |
| 01:04 | <Philip`> | (Actually, HTML5 is too hard to read for me to work out whether that's what alt should be in that case, but it seems the only logical text for an image that contains words) |
| 01:05 | <Hixie> | The image only conveys "Google", imho, given that the rest of hte text in the image is already on the page elsewhere |
| 01:05 | <Hixie> | so actually i'd defend the page |
| 01:05 | <Hixie> | though both could probably be argued |
| 01:05 | <Philip`> | The image conveys "Doodle 4 Google - Mijn Nederland" to me, given that that's what it says :-p |
| 01:06 | <Hixie> | :-) |
| 01:06 | <Hixie> | I don't think it would be better for the page to say that twice when the image isn't shown |
| 01:07 | Hixie | slams into an html-koolade-vacuum on the ietf uri mailing list |
| 01:07 | <Philip`> | What "would be better" is not necessarily related in any way to what's conforming HTML5 |
| 01:07 | <Hixie> | html5-koolade-vacuum, i should say |
| 01:07 | <Hixie> | Philip`: yeah |
| 01:07 | <Hixie> | Philip`: not sure what the spec should say to handle this case |
| 01:08 | <Hixie> | "A client or browser MUST NOT transmit passwords in clear text." |
| 01:08 | <Hixie> | well |
| 01:08 | <Hixie> | that could be a problem |
| 01:08 | <Hixie> | someone please make a special build of firefox for the tag |
| 01:09 | <roc> | one without support for text inputs? |
| 01:09 | <Hixie> | one that refused to transmit type=password inputs over http |
| 01:10 | <Hixie> | refuses |
| 01:10 | <Hixie> | as in, won't include the contents of such form fields in unencrypted http requests |
| 01:11 | <Philip`> | I think the spec should just give guidelines like "if all images on the page are replaced with their alt text, then the page should make sense and not lose information" that people can read and understand and apply in every case they come across - the more the spec tightens its grip on specific cases with 'must' requirements, the more unhandled cases will slip through its metaphorical fingers (and the more people will say "tl;dr" and ignore it entirely |
| 01:11 | <Philip`> | ) |
| 01:11 | <roc> | I've sometimes thought it would be cool to figure out what your credit card number is and refuse to submit it over HTTP |
| 01:11 | <Philip`> | Well, maybe that's not a very good metaphor :-( |
| 01:12 | <Hixie> | Philip`: yeah, maybe |
| 01:15 | <Philip`> | roc: Web developers seem quite ingenious at working around arbitrary restrictions - I imagine someone would publish an article saying you just have to do <form onsubmit="ccnumber.value = ccnumber.value.split('').reverse().join('')"> and give some PHP code to undo the effects on the server, and then millions of people will start doing that |
| 01:15 | <roc> | yeah |
| 01:15 | <othermaciej> | dedicated attackers with fraudulent sites are probably more of a threat these days than developers making honest mistakes and information being leaked by sniffing |
| 01:15 | <roc> | especially phishers |
| 01:16 | <roc> | actually the goal would be to stop phishers |
| 01:16 | <roc> | so you'd have additional restrictions |
| 01:16 | <roc> | but it wouldn't really work |
| 01:16 | <roc> | because they'd do keystrokes + AJAX or have the user click on a keypad or something |
| 01:17 | Hixie | tries to reply to the tag politely |
| 01:18 | <Philip`> | There could be a special anti-phishing meta tag, that causes web browsers to take a screenshot of the page, and then whenever you visit a page on a different domain it compares against the original screenshot and if it looks too similar then the new page is probably a phishing attempt |
| 01:19 | <roc> | we could just do that always |
| 01:19 | <roc> | too bad if a site changes domains |
| 01:19 | <Hixie> | that would be awesome in so many ways |
| 01:19 | Hixie | objects in advance on behalf of google |
| 01:22 | <Philip`> | Perhaps what we should do is allow passwords in plain text, but require URLs to be encrypted |
| 01:22 | <Philip`> | Then an attacker would know your password but wouldn't know what sites they could use it on |
| 01:25 | <Hixie> | frank's advice about how to handle the uri mess: "stay out of trouble" |
| 01:47 | <Hixie> | http://www.w3.org/mid/g3s3s1$7jg$1⊙ggo is also pretty special |
| 01:47 | <Hixie> | "please don't complicate our standards process with reality" |
| 02:02 | <othermaciej> | what is a LEIRI? |
| 02:02 | <othermaciej> | why must *RIs be renamed every two years? |
| 02:03 | <Philip`> | Is it pronounced "lairy"? |
| 02:27 | jcranmer | celebrates the netsplit frequency on freenode |
| 04:53 | <MikeSmith> | Shyam Habarakada from Microsoft -- who's been posting to the Geolocation list -- seems to be an actual developer |
| 04:53 | <MikeSmith> | as opposed to PM or whatever |
| 04:53 | <MikeSmith> | http://www.linkedin.com/in/shyamhabarakada |
| 04:54 | <MikeSmith> | Sr. Development Lead at Microsoft |
| 04:54 | <MikeSmith> | cool to have an actual developer from MS participating in something |
| 05:08 | <MikeSmith> | looks like he's a Safari user also |
| 05:08 | <MikeSmith> | http://shyamh.spaces.live.com/blog/cns!D3D369DD6211F237!1168.entry |
| 05:13 | <othermaciej> | so mixed messages regarding his taste in browsers |
| 05:20 | <mcarter> | that post doesn't send a mixed message at all |
| 05:21 | <mcarter> | it says "safari won't use my favorite search engine, live search, but i managed to change the settings so that its just like my favorite browser, IE" |
| 05:22 | <othermaciej> | he doesn't really say IE is his favorite, just indirectly seems to favor its "search democracy" |
| 05:24 | <mcarter> | i suppose so |
| 05:25 | <mcarter> | has the IE team ever sent the webkit team a cake around the time of a major release? |
| 05:40 | <roc> | the downside of not doing webkit releases, eh |
| 06:00 | roc | wonders who was responsible for deciding that SVG gradients and patterns should be able to "inherit" attributes from other gradients and patterns referenced by ID |
| 07:46 | <takkaria> | hmm, is it really "resolve a URL" and "parse a URL"? |
| 07:47 | <takkaria> | I'd have thought it should be "an URL" |
| 07:47 | <takkaria> | I guess it depends if you spell out URL or not... we obvious need some of RB's abbr tag extensions here |
| 07:47 | <hsivonen> | takkaria: I think the expected pronunciation doesn't start with a vowel: you are ell |
| 07:51 | <takkaria> | everyone else has weird expectations. :) |
| 07:58 | <Dashiva> | When in doubt, rephrase the sentence to use definite articles |
| 07:59 | <Hixie> | i call them "you are ells" because "earl" is just silly |
| 08:00 | <Hixie> | but then i call it "ess queue ell" and not "sequel" so what do i know |
| 08:00 | <Hixie> | however, since i'm writing the spec... :-) |
| 08:01 | <takkaria> | I talk about earls and spell out SQL |
| 08:01 | <takkaria> | sequel is blatantly a lie |
| 08:02 | gavin_ | is in the "earl is silly" camp |
| 08:05 | <mcarter> | are Frode Børli or Philipp Serafin in this channel? |
| 08:06 | <mcarter> | I'm a little confused by their tcp connection discussion on th elist |
| 08:10 | <Hixie> | man at some point i need to go through the spec and make it more consistent about whether attributes are their value, contain their value, or have their value |
| 08:10 | <Hixie> | right now i use all three interchangeably and it sounds like three different people wrote the spec |
| 08:10 | <Hixie> | how embarassing |
| 08:13 | <takkaria> | I'm sure it can be forgiven given the size of the spec, really :) |
| 08:42 | <takkaria> | ah, all these "Act as if ... had been seen" bits are doing my head in |
| 08:44 | <Hixie> | oh? |
| 08:44 | <Hixie> | why? |
| 08:45 | <gDashiva> | Act as if you understand this part of the spec |
| 08:45 | <takkaria> | I think it's probably because I'm going about implementing it the wrong way but sometimes it just seems unnecessary |
| 08:47 | <takkaria> | in the "in table body" tree construction step, for example, for some cases it tells you to act as if an end tag with the same tag name as the current node had been seen |
| 08:47 | <takkaria> | when all that actually amounts to is popping the current node from the stack of open elements |
| 08:48 | <takkaria> | I understand that if you want to update things in the future, this makes it a bit easier, but it can get a little annoying |
| 08:49 | <takkaria> | I think I'm just best sorting out an easy to to call the tree construction phase from within itself to save all the faffing |
| 08:50 | <Hixie> | takkaria: when i implemented it myself i just called the tree constructor again with a fake token whenver the spec said that |
| 08:51 | <Hixie> | i'll probably optimise those calls away when the spec is more stable |
| 08:52 | <takkaria> | yeah, I'm going that route I think, but the data structures are set up such that it's a good ten lines of code to create a token and whatnot :) |
| 08:52 | takkaria | blames C |
| 08:52 | <Hixie> | write a macro :-) |
| 08:53 | <Hixie> | (or a function) |
| 08:53 | <takkaria> | macro is looking more likely |
| 08:53 | <Hixie> | hsivonen: the e-mail you sent to www-archive just now is pretty much exactly what i told the w3c legal team a few days ago independently when they said that they were scared of having the html5 spec mention that the whatwg version was under a more permissive license |
| 08:54 | <Hixie> | (the ultimate irony here, that html5 _itself_ proves that copyright doesn't stop forks, is apparently lost on them) |
| 08:55 | <Hixie> | (indeed, the copyright on html4 actually helped the fork, as it prevented us from going down the obvious, but flawed, route of starting from the html4 spec instead of a blank slate) |
| 09:06 | <hsivonen> | takkaria: I think the most non-obvious as ifs are that </p> and </br> may cause an implicit <p> or <br> which trigger breaking out of foreign content |
| 09:07 | <takkaria> | heh, I'm not up to there yet |
| 09:07 | <takkaria> | I look forward to it ^_^ |
| 09:07 | <Philip`> | takkaria: Just use goto |
| 09:07 | <takkaria> | goto Philip`; /* useful advice here */ |
| 09:09 | <takkaria> | mm, this code really isn't structured for emitting fake tokens |
| 09:09 | <hsivonen> | takkaria: I inlined as ifs |
| 09:11 | <hsivonen> | Hixie: as far as UI goes if there's an open source spec for SVG5 and a W3C Document License doc for SVG 1.1, chances are that I'd take UI strings from the SVG5 spec even if it was otherwise less successful |
| 09:11 | <takkaria> | is SVG in need of a SVG5? |
| 09:11 | <hsivonen> | takkaria: oh yes |
| 09:12 | <shepazu> | yeah, takkaria, anything these guys didn't invent, they need to control and call "xxx5" |
| 09:12 | <takkaria> | ah, there the whatwg goes again, destroying my faith in the ability of people to get things right |
| 09:13 | <Hixie> | believe me, i don't want to control svg |
| 09:13 | <shepazu> | hmmm... try again, this time with feeling |
| 09:14 | <hsivonen> | shepazu: my point was that if one spec lets me reuse content and another doesn't, chances are that I'd end up using the one that I'd be allowed to use and, hence, not licensing specs as open source may actually encourage people looking for alternative expressions of the content |
| 09:16 | <shepazu> | that is rather convoluted reasoning... if I release a software product, and someone creates a cracked key, you endorse using the cracked version rather than the legitimate one? |
| 09:16 | <shepazu> | I'm not sure that's ethical |
| 09:16 | <hsivonen> | shepazu: for example, validator.nu pulls UI string from whatwg.org and not w3.org, not because I wanted to favor WHATWG but because the WHATWG versions allows me to do that |
| 09:16 | <gDashiva> | shepazu: So you're saying you don't want people to use w3c specs unless they pay for a key? |
| 09:17 | <hsivonen> | shepazu: your analogy seems flawed |
| 09:17 | <shepazu> | but if the work is derivative, hsivonen, it amounts to the same thing, and actually promotes schisms in the implementations |
| 09:17 | <gDashiva> | No, forcing people to create dervative works is what promotes schisms |
| 09:18 | <hsivonen> | shepazu: no, incentivizing people to clean-room spec text creates schisms |
| 09:18 | <shepazu> | gDashiva: W3C specs are royalty free... nobody's forcing anyone to create derivative works |
| 09:18 | <shepazu> | "clean-room spec text"? |
| 09:19 | <hsivonen> | shepazu: If I want UI text for SVG elements, I can't extract text from the SVG spec and get the result in Debian |
| 09:19 | <hsivonen> | shepazu: HTML5 is not a derivative work of HTML 4.01. It is an independent creative expression. |
| 09:19 | <shepazu> | that's rather a stretch... |
| 09:19 | <hsivonen> | shepazu: what is? |
| 09:20 | <shepazu> | the latter |
| 09:20 | <Hixie> | i can vouch for the fact that not a single word from html4 was copied into html5 |
| 09:20 | <shepazu> | how about <h1> |
| 09:20 | <shepazu> | ? |
| 09:20 | <Hixie> | how about it? |
| 09:20 | <shepazu> | that's not derivative? |
| 09:21 | <Hixie> | not in the copyright sense |
| 09:21 | <shepazu> | probably true |
| 09:21 | <gDashiva> | They both use 'HTML' too. The nerve. |
| 09:21 | <hsivonen> | shepazu: IANAL, but I suggest looking up court cases where it was found that strings that have to be invariant for computer program interop are copyable |
| 09:21 | <shepazu> | and of course, TBL didn't create the initial syntax, it was derived from SGML |
| 09:26 | <gDashiva> | There goes the accountability |
| 09:26 | <gDashiva> | And it's back |
| 09:26 | <hsivonen> | shepazu: the email was primarily about companion documents for HTML5. What I said about SVG on this channel was an illustratory example. |
| 09:28 | <shepazu> | hsivonen: then maybe you should consider less controversial phrasing, so you don't cause unnecessary misunderstandings before starting a friendly dialog? |
| 09:28 | <takkaria> | I didn't have any problem understanding it... |
| 09:28 | <gDashiva> | Maybe people should read up on context before jumping into discussions with tempers flaring |
| 09:28 | <hsivonen> | shepazu: OK. I'll use FooML or MathML from now on for hypothetical non-HTML examples. |
| 09:29 | <shepazu> | takkaria: you aren't the only audience that this public channel attracts |
| 09:30 | <Philip`> | hsivonen: Are you insulting MathML by calling it hypothetical? |
| 09:30 | <hsivonen> | shepazu: fwiw, the context was Hixie's comment about the effect of not being allowed to reuse HTML 4.01 text |
| 09:30 | <takkaria> | shepazu: no, but I didn't think there an implicit threat in anything hsivonen said at all, it was about using UI strings and read in the context of the email he sent to www-archive, it was pretty clear |
| 09:31 | <hsivonen> | Philip`: "hypothetical" qualifies "example" |
| 09:32 | <shepazu> | takkaria: when I hear the term SVG5, I take that to mean, "a version of SVG that we have created as a competitor", and I am pretty intent on preventing a schism for SVG... and I don't believe that I'm far of in that assessment |
| 09:32 | <shepazu> | far off, rather |
| 09:33 | <takkaria> | shepazu: I'm pretty sure no-one here has active plans to create a competing SVG spec, even if they think someone should |
| 09:34 | <hsivonen> | shepazu: that's indeed what "SVG5" meant. But the *point* was that licensing W3C specs more permissively would eliminate a class of cases where a competitor would be favored due to copyright considerations. |
| 09:34 | <shepazu> | takkaria: I don't share your optimism |
| 09:34 | <shepazu> | hsivonen: that's reasonable |
| 09:35 | <Hixie> | the hypothetical SVG5 isn't a competitor -- ideally, the SVGWG would be the one to write it |
| 09:35 | <Hixie> | if they did, it would save everyone a lot of trouble |
| 09:35 | <hsivonen> | I agree |
| 09:35 | <Hixie> | (isn't necessarily a competitor, i should say) |
| 09:35 | <takkaria> | shepazu: I'm not sure it's optimism; if someone was working on SVG5, they would have mentioned it |
| 09:36 | <shepazu> | takkaria: they did... Hixie proposed it in HTML5 |
| 09:36 | <shepazu> | just not with that moniker |
| 09:36 | <takkaria> | that's not the same as "working on", though |
| 09:36 | <othermaciej> | he did? |
| 09:37 | <hsivonen> | shepazu: no, an "SVG5" would tweak the above-DOM parts |
| 09:37 | <shepazu> | hsivonen: by your definition, perhaps |
| 09:37 | <hsivonen> | shepazu: what Hixie proposed in the SVG spec and what I implemented in the Validator.nu parser is on the same level as XML 1.0 is to SVG |
| 09:37 | <shepazu> | but I don't agree with your definition |
| 09:37 | <Hixie> | surely hsivonen's definition is the one that matters if you're going to be offended by him using the term |
| 09:38 | <othermaciej> | I find the term SVG5 offensive to persons of Polish descent |
| 09:38 | <shepazu> | I'm actually more concerned about your definition, Hixie |
| 09:38 | <takkaria> | othermaciej: I don't find it offensive, and I'm of Polish descent |
| 09:38 | <othermaciej> | please stop use of this obvious racist slur |
| 09:38 | <takkaria> | though the Latvian bit of me isn't very happy with it |
| 09:39 | <othermaciej> | takkaria: maybe by your definition |
| 09:39 | <hsivonen> | s/what Hixie proposed in the SVG/what Hixie proposed in the HTML5/ |
| 09:39 | <shepazu> | yeah, mockery is a pretty effective way of deflecting truth |
| 09:40 | <othermaciej> | it tends to be more effective at deflecting self-important indignation |
| 09:40 | <gDashiva> | Sounds like SVG has a lot to be afraid of |
| 09:40 | <shepazu> | FWIW, I'm already on public record saying that SVG needs some major cleanup... I know I've talked to Hixie and Maciej, among others about it |
| 09:40 | <othermaciej> | truth holds up against mockery |
| 09:41 | <shepazu> | othermaciej: nah, in the right audience, mockery suffices for anything |
| 09:41 | <hsivonen> | shepazu: if the SVG WG is on the case, what's there to be threated or offended about? |
| 09:42 | <othermaciej> | this channel's audience is probably not one of those |
| 09:43 | <shepazu> | I never said I was offended... I just popped in to ask why you're so keen to make an incompatible version of SVG... you cited a reasonable concern about certain kinds of reuse, and that's something productive we can build on... |
| 09:43 | <othermaciej> | hsivonen's comments really weren't about SVG |
| 09:44 | <othermaciej> | they were about the W3C Document License and how it is problematic for free software projects |
| 09:44 | <shepazu> | and to suggest that the best way of being productive is not to threaten others without first trying to work with them |
| 09:44 | <hsivonen> | shepazu: first, the comment wasn't about SVG in particular but about a W3C spec foo and a more liberally licensed independent expression. |
| 09:44 | <shepazu> | yep, that's a legitmate concern, imo |
| 09:45 | <othermaciej> | (I think the W3C software license is similarly problematic and at least some specs claim it applies to the IDL interfaces they define) |
| 09:46 | <Hixie> | SVG5, by my definition at least, can't be non-backwards-compatible |
| 09:46 | <Hixie> | that would defeat the point |
| 09:46 | <hsivonen> | shepazu: the second "oh yes" comment to the need of an SVG5 was about SVG. In particular, a version of SVG that treated full-stack browsers as its compatibility target. (not previous SVG specs or non-full-stack mobile implementations) |
| 09:46 | <othermaciej> | Hixie: non-backwards-compatible with the spec, or with existing implementations/content? |
| 09:46 | <shepazu> | all of this is a way, however flawed, of trying to prevent incompatible derivatives that damage the technology, which is a good goal... it's possible the way it's being done needs work |
| 09:47 | <Hixie> | othermaciej: with Web content |
| 09:48 | hsivonen | leaves to get food |
| 09:48 | <othermaciej> | if the W3C document license is intended to prevent incompatible derivatives, then it has not worked very well |
| 09:48 | <shepazu> | society doesn't really have a good way of dealing with strange cases like this... it's more geared up, legally, to deal with physical products |
| 09:48 | <othermaciej> | Exhibit A: Web browsers |
| 09:49 | <shepazu> | othermaciej: but those aren't specs |
| 09:49 | <shepazu> | anyway, back to work |
| 09:49 | <Hixie> | the specs are somewhat empty of meaning if you discount their implementations as irrelevant... |
| 09:50 | <shepazu> | that's neither what I said nor meant, but I guess that is irrelevant to you ;) |
| 09:50 | <othermaciej> | an implementation is a spec, just an overconstrained one |
| 09:50 | <othermaciej> | implementations are where the rubber hits the road |
| 09:50 | Hixie | prefers to look at it the other way around -- that a spec is an implementation, just one with weird users |
| 09:51 | <othermaciej> | the important thing is for implementations to be interoperable, and it doesn't really matter if someone wrote down an incompatible spec |
| 09:52 | <takkaria> | except to the extent is stops people being able to interoperate successfully |
| 09:52 | <takkaria> | s/iss/it |
| 09:53 | <annevk> | this URL thread is long |
| 09:53 | <shepazu> | othermaciej: actually, it does... if different implementers code to different specs, it's pretty bad... the point of making a spec good enough that there aren't incompatibilities is a good one, but that doesn't negate the importance of a single point of reference |
| 09:53 | <shepazu> | copyright is just another of those inadequate social mechanisms to try to create interop |
| 09:53 | <shepazu> | oops |
| 09:54 | <shepazu> | that is being used to try to create interop, that is |
| 09:54 | <othermaciej> | it's not much consolation that there isn't a spec for the weird things IE6 does with CSS |
| 09:54 | <shepazu> | yup |
| 09:54 | <othermaciej> | in fact, the world might be a better place if there was |
| 09:55 | <jgraham__> | This sounds a lot like the argument that open source is bad because people can fork it whereas in practice forks turn out to be rare and, when hty happen, beneficial |
| 09:55 | <othermaciej> | so it would probably be better to allow making derivative works of the spec to document known implementation bugs |
| 09:55 | <shepazu> | one would think that with some of the CSS editors being from MS, that would help |
| 09:55 | <othermaciej> | I don't think any of them want to make the CSS spec require IE6 behavior |
| 09:56 | <shepazu> | othermaciej: only if there weren't multiple incompatible derivative specs |
| 09:56 | <othermaciej> | I don't follow |
| 09:56 | <gDashiva> | If someone wants to be incompatible, it's not like they need a competing spec as an excuse... |
| 09:57 | <shepazu> | gDashiva: actually, that is often the case |
| 09:57 | <shepazu> | it gives it credibility |
| 09:57 | <gDashiva> | Credibility is something you add on later, it's not necessary |
| 09:58 | <othermaciej> | if your goal is incompatibility as such, it's probably easier to achieve by not copying the spec text, so that there is more accidental incompatibility and so it's harder to tell what is different |
| 09:59 | <othermaciej> | but if your goal was to, say, document implementation bugs for the benefit of authors, quoting the spec text to indicate differences would be useful |
| 10:00 | <Hixie> | if your goal is being incompatible, simply doing a bad job at implementing the spec is far easier than anything else |
| 10:00 | <shepazu> | sure... and I agree that W3C should move in that direction, to some degree |
| 10:01 | <shepazu> | that is, documenting what's out there, and trying to make sure that there aren't incompatibilities in the first place by writing better specs |
| 10:06 | <annevk> | why HTML5 will never fly: "It tries to reinvent the Web, if not the Internet." |
| 10:06 | <annevk> | at which point I wonder, what Web? |
| 10:07 | <othermaciej> | annevk: quote from somewhere? |
| 10:08 | <annevk> | the URI mailing list |
| 10:08 | <annevk> | http://lists.w3.org/Archives/Public/uri/2008Jun/ |
| 10:08 | <annevk> | specifically, http://lists.w3.org/Archives/Public/uri/2008Jun/0052.html |
| 10:08 | <Hixie> | that thread is quite something |
| 10:08 | <Hixie> | a somewhat pure collision of the old guard and the whatwg ethos |
| 10:12 | <othermaciej> | come on Hixie, you should have known that "URIs are specified in RFC 3986, not in RFC 3987." |
| 10:12 | <Hixie> | it's not clear to me why he thinks i thought otherwise |
| 10:12 | <Hixie> | but anyway |
| 10:13 | <Hixie> | (87 is the iri spec) |
| 10:13 | <annevk> | allowing links with a space, how dare you! |
| 10:13 | <Hixie> | html5 doesn't allow links with space either :-P |
| 10:13 | <annevk> | next you're telling me I'm confusing UA and author requirements :D |
| 10:14 | <Hixie> | :-P |
| 10:20 | <othermaciej> | that's one heck of a long thread |
| 10:46 | <Hixie> | time to sleep |
| 10:46 | <Hixie> | nn |
| 10:47 | <annevk> | g'n |
| 10:51 | <MikeSmith> | http://sideshowbarker.net/2008/06/25/html5-uris/ |
| 10:55 | <annevk> | ah, I was planning on blogging about that too "Passing of the old Guard" |
| 10:57 | <MikeSmith> | "Pissing off the old Guard" |
| 10:57 | <hsivonen> | MikeSmith: that seems to be the case :-( |
| 11:33 | annevk | is confused by Charles Lindsey |
| 11:53 | <hsivonen> | I'm not sure it's worthwhile to allow xmlns talismans only on namespace boundaries. |
| 11:54 | <hsivonen> | I guess this comes down to how much useless and harmless cruft passes as valid and to what extent validity captures some aesthetic notion of source neatness |
| 12:04 | <hsivonen> | It's weird that the named character reference table is mostly lexicographically sorted but the trailing semicolon doesn't obey the sort. |
| 12:04 | <hsivonen> | (probably too trivial to file a spec bug about) |
| 12:36 | <hsivonen> | aargh! I try to add the MathML entities and the compiler tells me that the static initializer then exceeds the 65535-byte limit |
| 12:37 | <annevk> | not an argument to remove support for them! :p |
| 12:49 | <annevk> | DNS has interop issues too: https://bugzilla.mozilla.org/show_bug.cgi?id=196852 |
| 12:49 | <annevk> | awesome |
| 12:52 | <hsivonen> | wow |
| 12:52 | <annevk> | on the Web, everything that can go wrong, will go wrong |
| 12:53 | <gDashiva> | Especially when 'wrong' is some arbitrary behavior defined in a spec |
| 12:55 | <hsivonen> | at least the MathML entities didn't break any html5lib test cases |
| 12:55 | <annevk> | they're not part of html5lib yet |
| 12:56 | <hsivonen> | annevk: I mean: there weren't any test cases that expected MathML entities not to expand |
| 12:57 | <annevk> | ah |
| 12:57 | <takkaria> | it should be possible to generate a test suite for HTML entities directly from the entities list in SVN |
| 12:57 | <takkaria> | I was toying with the idea but wasn't sure it was worth it |
| 13:18 | <Philip`> | A test suite for entities ought to check to every string that isn't a recognised entity does not get expanded |
| 13:20 | <Philip`> | (I suppose that might be infinitely too many, but at least it should test ones that are implemented in some cases in practice, like &pdf; and whatever) |
| 13:24 | <Philip`> | Web browsers need error-handling for URLs in HTTP redirect responses, because lots of those have spaces or | characters - would that be covered by HTML5's specification of URL handling? |
| 13:25 | <annevk> | in theory it's an HTTP issue :/ |
| 13:26 | <Philip`> | Who cares about theory? :-p |
| 13:27 | <takkaria> | Philip`: practically, the only way you'll ever do that check for entities is with a test coverage tool and the source code for your implementation to hand |
| 13:31 | <gsnedders> | Philip`: That'll be defined in http-parsing |
| 13:32 | <gsnedders> | Philip`: But yes, it'll likely be very similar to HTML 5, if not identical |
| 13:32 | Philip` | wouldn't care except that his dmoz.org-scraping program using HttpClient results in dozens of error messages due to invalid URIs-or-whatever-they're-called-today |
| 13:32 | <gsnedders> | (I haven't had time to look at it yet) |
| 13:33 | <Philip`> | <error type="io" uri="http://maps.yahoo.com/py/maps.py?Pyt=Tmap&city=Hoffman&state=MN&slt=45.816101&sln=-95.800598&mlt=45.834900&mln=-95.786700&country=us&mag=7&cs=7&newmag=8"; message="Invalid redirect location: /map?q1=Hoffman MN us&mag=7&ard=1"/> |
| 13:33 | <hsivonen> | I like it how they are called URLs in the new spec text |
| 13:33 | <Philip`> | etc |
| 13:35 | <gsnedders> | Philip`: Yeah, the stuff in http-parsing will be more or less identical |
| 13:35 | <gsnedders> | I see ambiguity in what Hixie wrote, so I'll need to send mail about that |
| 13:39 | <annevk> | hsivonen, me too |
| 13:39 | <annevk> | +1 |
| 13:41 | <hsivonen> | Does Safari allow UTF-8 errors in feed parsing? |
| 13:42 | <Philip`> | http://www.ppqu.com/ |
| 13:42 | <Philip`> | In the links panel at the bottom, middle column, fifth row, "舞蹈" |
| 13:43 | <Philip`> | links to http://www.ppqu.com/search.php?search_input=%%CE%E8%B5%B8 |
| 13:43 | <Philip`> | which gives "Not Acceptable: An appropriate representation of the requested resource /search.php could not be found on this server. Microsoft-IIS/6.0 Server at www.ppqu.com Port 80" |
| 13:44 | <Philip`> | but it seems to give that in every browser (IE6/Firefox/Opera) so I guess it's not an interoperability problem |
| 13:44 | <hsivonen> | Philip`: which reminds me: wasn't there sume non-standard UTF-16-based query string escaping scheme? |
| 13:45 | <hsivonen> | s/sume/some/ |
| 13:47 | <Philip`> | hsivonen: %uXXXX |
| 13:48 | <hsivonen> | Philip`: looks like Hixie hasn't specced that yet |
| 13:49 | <Philip`> | hsivonen: http://10.pro.tok2.com/%7ehonetsugi408/ used to link to http://maps.live.com/default.aspx?v=2&ss=yp.%u3057%u304a%u3084%u6574%u9aa8%u9662~yp.%u3057%u304a%u3084%u63a5%u9aa8%u30fb%u6574%u9aa8%u9662&cp=35.790005~139.439234&style=r&lvl=18&tilt=-90&dir=0&alt=-1000 |
| 13:50 | <Philip`> | which doesn't work if you rewrite it like http://maps.live.com/default.aspx?v=2&ss=yp.%25u3057%25u304a%25u3084%25u6574%25u9aa8%25u9662~yp.%25u3057%25u304a%25u3084%25u63a5%25u9aa8%25u30fb%25u6574%25u9aa8%25u9662&cp=35.790005~139.439234&style=r&lvl=18&tilt=-90&dir=0&alt=-1000 |
| 13:51 | <hsivonen> | Philip`: have you found other instances? |
| 13:56 | <Philip`> | http://www.chnrailway.com |
| 13:56 | <Philip`> | <a href="/Product/Product_listS.aspx?keywords=%u6A21%u677F" target="_blank">Ä£°å</a> |
| 13:56 | <Philip`> | but it looks like they've changed their site now |
| 13:59 | <Philip`> | hsivonen: Those two are the only ones matching (?i)href=\S*%u |
| 13:59 | <hsivonen> | Philip`: ok. thanks |
| 14:00 | <hsivonen> | I trust that Hixie can check Google's cache to see if %uXXXX matters |
| 14:01 | <Philip`> | There might be others in other attributes but I didn't check for those |
| 14:02 | Philip` | still really needs to write some code so he can search attribute values nicely and quickly |
| 14:10 | <Lachy> | oh wow, rob's responses are becoming less coherent all the time. http://www.w3.org/Bugs/Public/show_bug.cgi?id=5772#c12 - I'm definitely not responding to that. |
| 14:13 | <gDashiva> | You're implying they are coherent? :) |
| 14:13 | <annevk> | I'm glad we have bugzilla |
| 14:13 | <jcranmer> | "I want to strengthen uniqueness by changing the scope of uniqueness" |
| 14:14 | <annevk> | and that I'm not on it :) |
| 14:15 | <jcranmer> | that to me implies "I'm going to make everyone pass by simply defining failure to be this specific score" |
| 14:17 | <gDashiva> | All ids are unique, but some are more unique than others. |
| 14:19 | <Lachy> | I didn't imply they were ever coherent, just that it's possible to go from incoherrent to even more incoherrent. |
| 14:20 | <jcranmer> | o_O I'm reading his last comment and it makes less and less sense |
| 14:20 | <jcranmer> | this is the gist of it: "unique IDs are a problem, so we should allow non-unique IDs and then pretend they're unique" |
| 14:20 | <takkaria> | he's doing a PhD in something related to politics, economics and Marx, he spends a lot of time arguing things which don't make sense |
| 14:21 | <gDashiva> | jcranmer: You left out the part about xml:ID being perfect and awesome |
| 14:21 | <jgraham_> | hsivonen: Re: testcases, I'm +1 on your idea but I would just use the full strings math and svg unless there is some good reason not to |
| 14:21 | Philip` | sees http://camendesign.com/ using HTML5 elements |
| 14:21 | <jcranmer> | gDashiva: ah, yes I did |
| 14:21 | <hsivonen> | jgraham_: like <svg foreignContent>? |
| 14:22 | <jgraham_> | yeah |
| 14:22 | <hsivonen> | jgraham_: ok. makes sense |
| 14:22 | <annevk> | wfm too |
| 14:23 | jcranmer | recommends RESO THISBUGISACONTRADICTION |
| 14:23 | <hsivonen> | takkaria: are you suggesting that Marxist economics don't make sense? |
| 14:24 | <jcranmer> | takkaria: that should explain it; politicians try to take every side of the issue |
| 14:24 | <takkaria> | hsivonen: I merely suggest that maybe they're not very practical and somewhat idealistic :) |
| 14:25 | <Lachy> | oh, look, now he's proposing an attribute with my name: "That could be “<element lachy='value'>” It is up to the document specification to determine where an element ID comes from." |
| 14:27 | <annevk> | it's tempting to reply to RB, but pointless |
| 14:27 | <jgraham_> | Philip`: I note that person complains about <figure><legend> |
| 14:27 | <Lachy> | annevk, I know it's tempting. I've failed to resist temptation before. But a really big waste of time. |
| 14:27 | <jgraham_> | and also seems to misuse <header> |
| 14:29 | <Philip`> | Lachy: Removing oneself from the CC list is quite effective |
| 14:29 | <gDashiva> | (unless you're also on the mailing list) |
| 14:29 | <annevk> | not having a W3C Bugzilla account is too |
| 14:29 | <Philip`> | (Then unsubscribe from the mailing list :-p ) |
| 14:30 | <Philip`> | (and when the new-bug-notification message is sent to public-html, CC yourself if you think it's going to be a worthwhile bug, instead of defaulting to following everything) |
| 14:30 | <Lachy> | Philip`, I'm subscribed to public-html-bugzilla, and I'm not on the CC list. |
| 14:30 | <Lachy> | Philip`, I'm too lazy for that. |
| 14:31 | <Philip`> | Lachy: Then unsubscribe to public-html-bugzilla, and don't CC yourself ever |
| 14:31 | <Philip`> | That's the best solution for lazy people :-) |
| 14:35 | <Lachy> | Philip`, I need a solution that lets me keep track of everything that goes on |
| 14:35 | <Philip`> | Lachy: That is incompatible with laziness |
| 14:48 | <takkaria> | Philip`: not if you redefine laziness such that it includes not being lazy |
| 14:49 | <Philip`> | takkaria: That kind of redefinition would take too much effort |
| 14:49 | <takkaria> | not under my definition :) |
| 14:52 | <takkaria> | parody of RB is far too easy... |
| 15:03 | <Lachy> | the XHTML2 WG are having another telcon. Apparently they didn't like the HTMLWG's response to there issue. |
| 15:04 | <Lachy> | but they will discuss it more over email and then follow up in next week's telcon. |
| 15:05 | <Lachy> | s/there issue/their issue/ |
| 15:19 | <gsnedders> | telecons ftl |
| 15:21 | <Philip`> | They appear to result in all actions and decisions taking a positive integer number of weeks, which seems bad if the group is active enough to work faster than that |
| 15:22 | <gsnedders> | Philip`: like a negative integer number of weeks? |
| 15:22 | <Lachy> | gsnedders, yes. Everything should be finished last week. |
| 15:22 | <Philip`> | Like a non-integer number of weeks :-p |
| 15:23 | <Philip`> | or a non-positive non-negative integer |
| 15:23 | <Lachy> | the only non-positive, non-negative integer is 0 |
| 15:23 | <Philip`> | Indeed |
| 15:24 | <gsnedders> | so it should be done NOW? |
| 15:24 | <Philip`> | Not everything, but some things should be |
| 15:25 | <Philip`> | particularly when it takes less time to just do it than it would take to add it to an agenda to agree next week to do it |
| 15:27 | <Philip`> | Hmm, I've forgotten what I was talking about now |
| 15:27 | <Philip`> | Oh well |
| 15:29 | gsnedders | passes Philip` some ROM for next time |
| 15:30 | <zcorpan> | Philip`: we should discuss what you were talking about at the next telecon |
| 16:31 | takkaria | reads the examples in the html5 spec for a laugh |
| 16:33 | <Philip`> | There are some fairly obscure references in some of them |
| 16:34 | <mpt> | In 100 years the HTML 5 spec will be the only remaining trace of Stargate SG-1 |
| 16:37 | <mpt> | (well, maybe 300 years) |
| 16:38 | gsnedders | laughs at one example which is obviously Hixie talking about himself |
| 16:45 | <Philip`> | Hixie: "<li value="8"><cite>A Bugs Life</cite>, 1998</li>" should say "A Bug's Life" |
| 16:54 | <mrbkap> | Hixie: http://www.hixie.ch/tests/adhoc/html/parsing/comments/004.html should show the text b-->c with your algorithm, right? |
| 16:55 | <Philip`> | mrbkap: HTML5 says it should be http://james.html5.org/cgi-bin/parsetree/parsetree.py?uri=http%3A%2F%2Fwww.hixie.ch%2Ftests%2Fadhoc%2Fhtml%2Fparsing%2Fcomments%2F004.html |
| 16:57 | <mrbkap> | Ah, I was wondering if something like that existed. |
| 16:57 | <mrbkap> | Cool, thanks. |
| 16:58 | <Philip`> | (Also see http://parsetree.validator.nu/ for an independent implementation that hopefully gives the same results) |
| 16:59 | <mrbkap> | I think I just implemented the comment parsing in Gecko. |
| 17:00 | <Philip`> | It'd be good to know if HTML5's comment parsing algorithm doesn't break the web :-) |
| 17:01 | <mrbkap> | Heh, I'm sort of worried about that! |
| 17:01 | <jgraham_> | I should update the html5lib on james.html5.org |
| 17:01 | <jgraham_> | Although I don't think it's all that old |
| 17:02 | <smedero> | it be nice if your tool had a little html5lib version # text in the footer... |
| 17:03 | <jgraham_> | Should be up to date now (although validator.nu is closer to the current state of the spec) |
| 17:03 | <jgraham_> | smedero: Yeah, I guess it could show the svn rev or something |
| 17:05 | jgraham_ | will investigate that this evening |
| 17:05 | <smedero> | cool, thanks! |
| 18:06 | <Philip`> | jcranmer: so it seems like scheduled maintenance, and presumably it's not scheduled frequently |
| 18:07 | <jcranmer> | Philip`: scheduled mainteance seems to happen frequently, though |
| 18:59 | <KevinMarks> | I'm trying to get an overview of datatemplate, rule, nest etc. Has anyone written this up with examples of use, rather than the pseudocode in the spec? |
| 19:00 | <mrbkap> | Is there any sort of test suite for comments? |
| 19:00 | <smedero> | KevinMarks: http://lists.w3.org/Archives/Public/public-html/2008Jun/0119.html |
| 19:00 | <smedero> | and also Ian's follow up: http://lists.w3.org/Archives/Public/public-html/2008Jun/0121.html |
| 19:00 | <smedero> | might be helpful to you |
| 19:02 | <Philip`> | mrbkap: html5lib has lots of test cases - http://html5lib.googlecode.com/svn/trunk/testdata/tokenizer/ and http://html5lib.googlecode.com/svn/trunk/testdata/tree-construction/ |
| 19:02 | <Philip`> | mrbkap: Someone set up something to run those tests in a web browser directly, which might be helpful if I could find it |
| 19:04 | <Philip`> | mrbkap: http://html5.org/parsing-tests/testrunner.htm though I'm not sure how recent that copy of the test cases is and I'm not sure how many comment-related tests it includes |
| 19:05 | <mrbkap> | If it includes test2, that'll work. |
| 19:05 | <mrbkap> | Thanks. |
| 19:06 | <KevinMarks> | thanks smedero |
| 19:06 | <KevinMarks> | the context is the OpenSocial template discussion, and FBML |
| 19:09 | <Philip`> | KevinMarks: It doesn't seem likely that the datatemplate stuff will stay in HTML5, given Hixie's comments, so it should probably considered as just another nonstandard templating proposal and not as a soon-to-be-natively-implemented browser feature |
| 19:10 | <Philip`> | (It's also somewhat incomplete, e.g. it doesn't define any way of inserting data values into the templated output) |
| 19:28 | <KevinMarks> | it looks much less complete than the opensocial proposal |
| 19:28 | <KevinMarks> | http://groups.google.com/group/opensocial-and-gadgets-spec/web/opensocial-templates |
| 19:36 | <Philip`> | KevinMarks: datatemplate lets you modify the data via the DOM and the template will automatically update to show the new data (while trying to not lose values users typed into form elements) - it looks like the OpenSocial proposal doesn't do that at all, and is just a one-time convert-some-data-into-some-HTML process |
| 21:15 | <mitsuhiko> | html5lib still doesn't work with lxml2 :( |
| 21:23 | <jgraham__> | mitsuhiko: ? WFM... |
| 21:23 | <jgraham__> | Although there might be some corner case issues on the lxml side |
| 21:24 | <mitsuhiko> | jgraham_ValueError: Invalid tag name u'<DOCUMENT_ROOT>' |
| 21:24 | <mitsuhiko> | that's latest html5lib trunk and lxml2.1beta3 |
| 21:26 | <jgraham__> | mitsuhiko: That's very surprising; I thought that wasn't possible with the latest html5lib trunk |
| 21:26 | jgraham__ | goes to look |
| 21:26 | <mitsuhiko> | i could swear it worked some time ago |
| 21:29 | <jgraham__> | Oh, maybe you're trying to use the etree TreeBuilder with lxml, which won't work anymore; you need to do getTreeBuilder("lxml") instead |
| 21:30 | <jgraham__> | (I had to fork the two cases as lxml has some important differences from standard ElementTree but I should try porting the ElementTree code to the lxml way) |
| 21:32 | <Hixie> | hm, it seems the URI spec defines "URL" already |
| 21:32 | <Hixie> | maybe we should use the word "address"? |
| 21:48 | <Philip`> | Hixie: That would make the <address> element very confusing |
| 21:48 | <Hixie> | yes |
| 21:48 | <Hixie> | but then again |
| 21:48 | <Hixie> | would it make it _more_ confusing? :-) |
| 21:50 | <Philip`> | It seems generally worthwhile to avoid overloading terminology, and "address" is already overloaded enough that it'd be harmful to rely on it as a technical term with a very specific meaning that readers are somehow expected to understand |
| 21:50 | <Dashiva> | What about location? |
| 21:50 | <Dashiva> | It matches with the location object :) |
| 21:51 | Hixie | just wontfixed a request to change the doctype syntax to help xslt users |
| 21:51 | <Philip`> | "URL" doesn't have that problem because nobody reads RFCs and everybody already knows that URLs are just the things like http://blah that you type into web browsers |
| 21:51 | <Hixie> | "URL" has so far confused one person |
| 21:51 | <Philip`> | which is a sufficiently specific meaning for most purposes |
| 21:52 | <Philip`> | That's a whole six billion people it hasn't confused yet - I think the one is outnumbered |
| 21:52 | <Dashiva> | What about... XRX |
| 21:52 | <Hixie> | well the six billion people haven't read the spec :-) |
| 21:52 | <Hixie> | Dashiva: dude. you invented a new term AND used two "x"s in it. disqualified! :-P |
| 21:53 | <Hixie> | w is the new x |
| 21:53 | <Dashiva> | [UI]R[IL] |
| 21:53 | <Hixie> | lord |
| 21:53 | <Hixie> | ok i'll stick to URL until someone comes up with something actually better |
| 21:53 | <Dashiva> | :( |
| 21:54 | <Dashiva> | Okay, last shot. EARL. |
| 21:54 | <Hixie> | something else that's confusing |
| 21:54 | <Hixie> | is that the spec uses the term "URL" when it talks about things that take URIs |
| 21:54 | <Hixie> | and uses the term data: URI when talking about the output of the method toDataURL |
| 21:55 | <Hixie> | maybe i should call them data: URL |
| 21:55 | <Hixie> | which would be ironic since while it's what the data: URL spec calls them, they're not actually URLs in the sense of the term as defined by 3986 |
| 21:55 | <Dashiva> | As I understand it, IRI is just a way to map fancy letters into URIs, but how does URLs figure into it? |
| 21:56 | <Hixie> | the uri spec defines uri space as being further subset into url and urn sapce |
| 21:56 | <Hixie> | space |
| 21:56 | Hixie | calls them data: URLs and moves on |
| 21:56 | <Philip`> | Who chose the name "toDataURL"? |
| 21:57 | <Dashiva> | Does anyone care about URNs in practice? |
| 21:57 | <Hixie> | Philip`: me |
| 21:57 | <Dashiva> | As in, can we just assume URL = URI? |
| 21:57 | <Hixie> | Dashiva: lots of people living in ivory towers do :-D |
| 21:57 | <Dashiva> | That was badly formulated. |
| 21:57 | <Dashiva> | I meant, will we ever encounter URIs that aren't URLs in real life? |
| 21:58 | <Philip`> | <html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns="http://www.w3.org/TR/REC-html40">; |
| 21:58 | <Dashiva> | namespaces are just opaque strings (to me) |
| 21:59 | <Lachy> | hmm. I don't like bug 5801 for adding xmlns to all elements. |
| 22:01 | <Hixie> | me either |
| 22:06 | <Philip`> | ('HTML URL' = HURL gives the right connotations) |
| 22:07 | <Dashiva> | what-url |
| 22:07 | <Philip`> | Dashiva: Hmm, I can't find anything that looks like a URN like \s(?!xmlns)\S+="urn:(?!schemas-microsoft-com) |
| 22:08 | <Philip`> | (except for example code in http://www.mozilla.org/docs/xul/xulnotes/template-primer.html which isn't what I was intending to look for) |
| 22:09 | <Dashiva> | So there's no practical difference between uri and url on the web |
| 22:11 | <Philip`> | s/the web/a tiny subset of the web/ |
| 22:13 | <Hixie> | like i said |
| 22:13 | <Hixie> | ivory towers |
| 22:36 | <jcranmer> | Hixie++ for his latest CVS comment |
| 22:39 | <Hixie> | someone should let www-html know that html5 defines innerHTML |
| 22:40 | <Lachy> | oh, geez. www-html has had a lot of traffic in the last day. |
| 22:42 | <Lachy> | grr, I hate my ISP. Experiencing crappy, intermittent connection problems and tech support didn't even respond to my email :-( |
| 22:42 | <Hixie> | we were having huge issues with comcast the other day |
| 22:42 | <Hixie> | it just dropped off at 2am |
| 22:43 | <gsnedders> | Hixie: This is why you sleep overnight :P |
| 22:43 | <Lachy> | that's not surprising. I don't think I've ever read anything positive about comcase. |
| 22:43 | <Lachy> | *comcast |
| 22:43 | <jcranmer> | Hixie: probably in revenge for closing the bar on the people there |
| 22:43 | <Hixie> | for various reasons we were testing the network with my ipod |
| 22:43 | <Hixie> | and when the guy on the other end told my girlfriend "i'm sorry we don't support ipods" i just yanked the phone and went balistic on them |
| 22:44 | <Hixie> | nobody blames my fucking IPOD for their screwup. |
| 22:44 | jcranmer | imagines Hixie going ballistic |
| 22:44 | <Hixie> | told them that either they sent a tech guy to fix it before the end of the weekend, or we canceled the account |
| 22:44 | <gsnedders> | s/ipod/iPod/ig |
| 22:44 | gsnedders | runs and hides |
| 22:45 | <Hixie> | the connection magically started working again ten minutes after we hung up |
| 22:45 | <Hixie> | (it was a 1h10 minute phone call) |
| 22:45 | <jcranmer> | gsnedders: you're forgetting the trademark! |
| 22:45 | <gsnedders> | BT isn't much more fun to deal with |
| 22:46 | <jcranmer> | Verizon's pretty good... until they've decided to drop 90% of Usenet because a few newsgroups have child pr0n on them... |
| 22:46 | <gsnedders> | They were constantly saying, "Call the third party router's helpline! It isn't our fault! The fact that two routers exhibit the same issue with not connecting isn't our fault!" |
| 22:46 | gsnedders | sends jcranmer a naked pic |
| 22:46 | gsnedders | waits for IRC to blocked on Verizon |
| 22:46 | <jcranmer> | ha-ha, I'm not connected from my home computer |
| 22:47 | <gsnedders> | (and no, ladies and gentlemen, I didn't actually) |
| 22:47 | <jcranmer> | besides, I keep my address nice and private |
| 22:48 | <jcranmer> | only people with access to my school's Intranet know it... |
| 22:48 | <jcranmer> | ... and most anywhere I post on Usenet :-) |
| 22:48 | <mitsuhiko> | jgraham_: indeed. that works |
| 22:48 | <mitsuhiko> | thanks a lot! |
| 22:49 | <mitsuhiko> | html5lib * lxml == awesome stuff |
| 23:03 | <technomancy> | hey, it looks like the gem version of html5lib that's been uploaded to rubyforge is rather out of date |
| 23:03 | <technomancy> | any chance 0.11 could be published? |
| 23:04 | <technomancy> | err--actually it looks like 0.10.1 is the latest for ruby |
| 23:05 | <Philip`> | technomancy: 0.11 is only Python - the Ruby port is currently in a slightly broken unmaintained state |
| 23:06 | <technomancy> | I see. Well 0.10 is too old to work with mars (the Planet port); it looks like trunk is better. |
| 23:08 | <jgraham__> | technomancy: Ryan King suggested he might try and update the Ruby port sometime but otherwise it's a case of patch it yourself if you need to match the current spec, I'm afraid |
| 23:08 | <kingryan> | hey. yeah, i'm hoping to have time to work on it soon, but don't hold your breath |
| 23:10 | <technomancy> | Hmm... I know next to nothing about HTML 5; I just want mars to be easy to install. |
| 23:12 | <technomancy> | is the version in trunk really that much worse than 0.10? |
| 23:13 | <jgraham__> | I think the trunk version is a little ahead of 0.10 but quite far behind 0.11. I guess it will fail a lot of the tests |
| 23:14 | <jgraham__> | It may be good enough for what you want to do, depending on what that is |
| 23:14 | <technomancy> | jgraham__: well Sam Ruby says to use trunk rather than the gem since it has a certain bug fix, but he didn't go into detail about what it was. |
| 23:15 | <technomancy> | yikes... it's been a long time since I've seen that many test failures. |
| 23:20 | <Philip`> | technomancy: Those test failures are probably caused by the tests changing (to follow more recent versions of HTML5), so it just indicates that the Ruby trunk is out of date rather than that it's buggier than in 0.10 |
| 23:21 | <kingryan> | Philip` is right, the tests have been updated since the ruby port was last touched, so its just out of date, but stable and pretty good at dealing with real-world content |
| 23:22 | <technomancy> | gotcha |
| 23:23 | <kingryan> | i actually tested it against a couple million random pages on the web (back when i was at technorati) and it at least didn't crash during that :) |
| 23:24 | <Philip`> | It's trivial to write a parser that doesn't crash, since you could just make it return an empty document - the only interesting thing is whether it parsed all those millions of pages correctly :-) |
| 23:27 | <Hixie> | what was the reason for not using "address" again? |
| 23:27 | <Hixie> | was it just <address>? |
| 23:29 | <Philip`> | http://www.answers.com/address - it has plenty of meanings already, so it'll cause much confusion if you try to force people to think of it instead as some specific technical concept you've defined |
| 23:31 | <Hixie> | yeah, fair enough |
| 23:33 | <Hixie> | bbl |