| 00:00 | <MikeSmith> | hendry: you there? |
| 00:00 | <MikeSmith> | I wanted to ask about the sed expression in your vim validator script |
| 00:00 | <MikeSmith> | what the purpose of it is |
| 00:30 | <annevk2> | Hixie, do you know anyone that looked at http://www.w3.org/2005/Incubator/MashSSL/charter ? |
| 00:50 | <annevk2> | hmm, I still don't see how http://sites.google.com/site/guestxhr/maciej-challenge works |
| 00:51 | <abarth> | Hixie: there isn't an allow-plugins for @sandbox? |
| 00:51 | <annevk2> | oh, hmm |
| 01:50 | <ojan> | anyone know the state of the css3 paged media spec? |
| 01:50 | <ojan> | are the editors still working on it? |
| 01:52 | <annevk2> | to some extent, I think |
| 01:52 | <MikeSmith> | https://bug-21288-attachments.webkit.org/attachment.cgi?id=42473 |
| 01:52 | <MikeSmith> | https://bugs.webkit.org/show_bug.cgi?id=21288 |
| 01:57 | <AryehGregor> | Isn't the web lovely, where you have to have a separate domain for every attachment to get any kind of security. |
| 01:58 | <GPHemsley> | :P |
| 02:05 | <ojan> | annevk2: thx. we're getting requests to implement parts of it and trying to evaluate which parts make sense to move forward with |
| 02:08 | ojan | still gets confused which mailing lists, etc to use for what specs. |
| 02:11 | <annevk2> | ojan, www-style |
| 02:11 | <ojan> | annevk2: heh. that seems obvious in retrospect |
| 02:12 | <othermaciej> | annevk2: I think CORS should document the "Don't Be a Deputy" programming discipline in the Security Considerations section |
| 02:12 | <othermaciej> | annevk2: (maybe after people have had a chance to review it to see if it is sound) |
| 02:13 | <annevk2> | I agree |
| 02:13 | <annevk2> | we should have some of your diagrams as well to introduce the problem space |
| 02:15 | <abarth> | i don't understand the allow-same-origin directive of the sandbox attribute |
| 02:16 | <abarth> | if we allow-same-origin, can't the frame just remove the sandbox attribute altogether? |
| 02:16 | <abarth> | Hixie: ^^^ |
| 02:17 | <abarth> | oh, i see |
| 02:17 | <abarth> | scripting will be disabled |
| 02:17 | <abarth> | i'm not used to thinking about a world without script..... ignore me :) |
| 02:18 | <othermaciej> | abarth: did you see Mike+Tyler's GuestXHR-based cross-site access proposal, and my comments on it? |
| 02:18 | <abarth> | not yet, but i'll look at it now |
| 02:18 | <othermaciej> | abarth: would appreciate sanity check on the latter and analysis on the former |
| 02:18 | <abarth> | i got excited by the sandbox attribute patch for webkit |
| 02:18 | <othermaciej> | there's a sandbox attribute patch for WebKit? |
| 02:18 | <othermaciej> | hot! |
| 02:19 | <othermaciej> | pointer? |
| 02:19 | <abarth> | othermaciej: https://bugs.webkit.org/show_bug.cgi?id=21288 |
| 02:19 | <abarth> | i don't know the contributor |
| 02:19 | <abarth> | the patch is quite good |
| 02:19 | <abarth> | although some details can be improved |
| 02:28 | <abarth> | othermaciej: i like point 6 of your argument |
| 02:29 | <abarth> | his argue is basically that by providing developers less rope, we hope they'll build bridges out of steel instead of hanging themselves |
| 02:29 | <othermaciej> | abarth: it was more a series of comments than an argument, but thanks |
| 02:30 | <othermaciej> | abarth: another thing I thought of - if you have CORS it's easier to make the shared secret be time-limited or use-limited without violating the "AJAX UI" requirement, thus further mitigating the risk of revealing it |
| 02:31 | <abarth> | i don't think guest XHR handles the basic use case of "almost public" data, like timely stock ticker information that might be licensed for use only for certain sites |
| 02:32 | <abarth> | e.g., if Google Finance lets Acme Finance CORS+XHR for timely stock ticker data by checking the Origin |
| 02:32 | <abarth> | in a guest XHR world, ACME needs to either proxy |
| 02:32 | <abarth> | or talk to Google on the back end |
| 02:33 | <abarth> | this scenario is interesting because it doesn't fit our usual notions of confidentiality because |
| 02:33 | <abarth> | an attacker can always proxy the information from the main Google Finance site |
| 02:34 | <abarth> | but that's different than access the data directly from the user's browser |
| 02:35 | <othermaciej> | GuesXHR could handle that by having a pre-arranged shared secret between Google Finance and Acme Finance |
| 02:36 | <othermaciej> | actually I guess not, since to avoid revealing it you need to use server-to-server communication either to actually get the data or to generate a one-time token for the client side |
| 02:36 | <abarth> | yes |
| 02:36 | <abarth> | you can do it with crypto |
| 02:36 | <abarth> | by using the long-lived key to mac a sequence number or something |
| 02:37 | <othermaciej> | true |
| 02:37 | <abarth> | ok, let me think about his protocol |
| 02:38 | <othermaciej> | his protocol does have a flaw which I'm not sure can be easily fixed, which is putting the shared secret in a URL |
| 02:38 | <abarth> | in earlier designs, he's used the fragment identifier for that |
| 02:38 | <abarth> | and cleared the fragment using javascript |
| 02:39 | <othermaciej> | I'm not sure that prevents all the ways the secret-bearing URL might get leaked |
| 02:39 | <othermaciej> | (e.g. browser history sync) |
| 02:39 | <abarth> | http://w2spconf.com/2008/papers/s4p2.pdf |
| 02:40 | <abarth> | the /grant URL in this protocol |
| 02:40 | <abarth> | needs to be protected from CSRF |
| 02:40 | <abarth> | otherwise the attacker can cause A to grant to whatever B he likes |
| 02:41 | <othermaciej> | abarth: the "got" URL needs to be protected from CSRF too |
| 02:41 | <othermaciej> | or an attacker can overwrite A's valid key |
| 02:41 | <othermaciej> | and since the "got" URL is actually accessed cross-site, that requires an Origin check or a pre-arranged shared secret |
| 02:42 | <othermaciej> | er, an attacker can overwrite *B*'s valid key (to A) |
| 02:42 | <abarth> | i don't understand how to prevent that |
| 02:42 | <abarth> | how does B distinguish A from the attacker? |
| 02:43 | <othermaciej> | it can distinguish A from an attacker by looking at the Cookie (indicating a valid A user in an actual browser) and the Origin header |
| 02:43 | <othermaciej> | or by having a pre-arranged shared secret with B that must be included with all "got" requests |
| 02:43 | <abarth> | i don't see how the cookie helps |
| 02:43 | <abarth> | B gets B's cookies, not A's |
| 02:44 | <abarth> | we're imagining a world without Origin |
| 02:44 | <othermaciej> | the user would have to be logged into B for this to work |
| 02:44 | <abarth> | so we can't use that |
| 02:44 | <othermaciej> | right, that's why I dismiss the Origin-based defense |
| 02:44 | <othermaciej> | which leaves only a pre-arranged shared secret |
| 02:44 | <abarth> | so, that means this isn't the whole protocol |
| 02:45 | <abarth> | presumably you can't use a long-lived secret |
| 02:45 | <abarth> | because it bounces to the client |
| 02:45 | <othermaciej> | well, the protocol as specified appears to have a CSRF vulnerability |
| 02:45 | <abarth> | and the attacker can learn it by being the client in one instance |
| 02:45 | <abarth> | he'll say that grant is protected |
| 02:45 | <abarth> | because of the s=.... |
| 02:45 | <abarth> | part |
| 02:45 | <abarth> | but I don't see how got is protected based on the diagram |
| 02:46 | <abarth> | also, the protocol violates the HTTP spec |
| 02:46 | <othermaciej> | true, it can't be a long-lived secret, it would have to be arranged between A and B on demand |
| 02:46 | <abarth> | because a GET request is changing state on server B |
| 02:46 | <abarth> | so that would have to be a POST |
| 02:46 | <othermaciej> | true |
| 02:46 | <abarth> | which means the redirect would have to be a 307 |
| 02:46 | <abarth> | which means a dialog in Firefox |
| 02:47 | <abarth> | and that |
| 02:47 | <abarth> | it doesn't work at all in Safari |
| 02:47 | <othermaciej> | and that would reveal the contents of the form submitted to B |
| 02:47 | <othermaciej> | 307 does work in Safari at least with WebKit ToT |
| 02:47 | <othermaciej> | (not sure if it does in shipping) |
| 02:47 | <abarth> | oh, nice |
| 02:47 | <othermaciej> | you should send any comments to the list that I didn't already send in one of my many emails |
| 02:47 | <abarth> | ok, will do |
| 02:47 | <abarth> | collin is here, i'll ask him to look at it too |
| 02:48 | <othermaciej> | in particular I claimed the CSRF vulnerability on "got" is patchable with a pre-arranged shared secret, but as you pointed out, you can't use a long-lived shared secret |
| 02:48 | <abarth> | then why not transfer secret123 on the back end? |
| 02:49 | <othermaciej> | the requirements he's trying to satisfy include "no server-to-server communication required" |
| 02:50 | <othermaciej> | (and also "no bilateral prior arrangement between the servers such as a pre-arranged shared secret") |
| 02:50 | <othermaciej> | I'm not sure this protocol can be patched to fix the CSRF and still meet those requirements, without using Origin somewhere |
| 02:51 | <abarth> | You probably can do it by bouncing requests back to A to make sure it wanted to send the got request |
| 02:51 | <abarth> | you need something like the 4-way handshake in 802.11i |
| 02:51 | <abarth> | or NSL with a final confirmation message |
| 02:52 | <abarth> | is probably the better way to think about it |
| 02:52 | <othermaciej> | I'm not familiar with the protocols you refer to but it sounds plausible |
| 02:53 | <othermaciej> | all right, I'm gonna head out for now but I'll be back online later |
| 02:53 | <abarth> | i'll send an email to the list with citations |
| 02:53 | <abarth> | ttyl |
| 03:52 | <othermaciej> | hi all |
| 03:58 | <gsnedders> | Because I couldn't quite resist: http://thereshouldbenored.com/ |
| 04:01 | <othermaciej> | ? |
| 04:02 | <gsnedders> | Just look at the page. If there's one thing I had to do with that domain, at least temporarily, that is it. |
| 04:03 | <othermaciej> | I can see that the page is red |
| 04:03 | <othermaciej> | but I don't get it |
| 04:03 | <othermaciej> | oh |
| 04:03 | <othermaciej> | CSS test case joke? |
| 04:03 | <gsnedders> | Not really |
| 04:03 | <gsnedders> | Well, yeah |
| 04:03 | <gsnedders> | But not really specifically CSS |
| 04:44 | <cedricv> | gsnedders: hehe funny, but there should be no title either no? |
| 06:06 | <JonathanNeal> | Hi everybody \o/ |
| 08:27 | <zcorpan> | is the plan for mathml to drop support for xlink:href at some point? |
| 13:44 | <Philip`> | Dashiva: You know it's an automatic namespace file because you load it as part of the automatic namespace file loading process |
| 13:44 | <Philip`> | so it's the same as how you know an image is an image when loading it in <img> |
| 13:45 | <Dashiva> | But it could contain other contents |
| 13:45 | <Dashiva> | Images require sniffing, after all |
| 13:46 | <Philip`> | So you sniff it based on the element names |
| 13:46 | <Dashiva> | But surely a new technology shouldn't require sniffing |
| 13:46 | <Dashiva> | Especially not one based on XML |
| 13:46 | <Philip`> | If it's got <ns><element><name>... then you process it, otherwise you ignore unexpected elements |
| 13:48 | <zcorpan_> | you don't need to sniff, you can just try to apply it and if it fails (because it contains something else), ignore it (or whatever error handling is defined) |
| 13:48 | <Philip`> | Dashiva: So you're advocating in favour of using namespaces everywhere, even when they're not needed for their practical benefits like mixing independently-developed vocabularies? |
| 13:49 | <Dashiva> | The contents might be XML that happens to use <ns> and <element> and such without being a ns file |
| 13:49 | <Philip`> | (or for benefits like backward compatibility with existing content and specs etc) |
| 13:50 | <Philip`> | Dashiva: Why is that a problem, other than being a security risk? |
| 13:50 | <Dashiva> | Isn't that problem enough in itself? |
| 13:50 | <Philip`> | No |
| 13:51 | <Philip`> | It's no more of a problem than a text file that happens to be a valid PNG, and I might use it in <img> on my page and it could display something unintentionally rude |
| 13:51 | <Dashiva> | It would also be problematic to handle those files with generic XML tools, when you don't access the file via an explicit reference as a ns file |
| 13:51 | <Dashiva> | Philip`: No, it's worse |
| 13:51 | <Dashiva> | It might turn a bogus:script element into xhtml:script |
| 13:52 | <Philip`> | If I don't want it to be processed in that way, and/or don't trust the server it's hosted on, then I don't include an explicit link to it from my page |
| 13:52 | <Dashiva> | And maybe bogus:script is just example code, not intended to actually be run |
| 13:53 | <Dashiva> | Philip`: But the proposal practically begs people to link other people's ns files, to avoid recreating everything themselves |
| 13:53 | <Philip`> | Dashiva: Extensibility is centralized in practice, so they'd just link to w3.org, and everyone trusts the W3C already |
| 13:54 | <Dashiva> | But if everyone's going to use the same file we should just skip the file completely |
| 13:54 | <Philip`> | unless you're IBM and you host a copy yourself |
| 13:55 | <Philip`> | Dashiva: http://www.w3.org/2009/Talks/08-quin-balisage-namespaces/ does suggest skipping the file and having a default be supplied by the application |
| 13:57 | <Dashiva> | And then we're just one step away from letting the default be supplied by the specification |
| 13:57 | <Dashiva> | Coming full circle to <svg> in HTML5 |
| 13:58 | <Philip`> | Indeed, except it's in XML not HTML |
| 13:58 | <Philip`> | and there's a syntax for expressing the <svg> etc rules, which generic XML processors could use |
| 14:00 | <Philip`> | (and the rules just get applied when parsing, so there's no need to complicate the internals of applications so they handle context-sensitive semantics of elements, since it just sees the normal namespaceURI/localName that everyone loves) |
| 14:00 | <Dashiva> | Although we skipped this part: <Dashiva> It would also be problematic to handle those files with generic XML tools, when you don't access the file via an explicit reference as a ns file |
| 14:01 | <Philip`> | You pass a reference to the ns file as an extra argument to the parser |
| 14:01 | <Dashiva> | No, the ns file itself |
| 14:01 | <Philip`> | You pass a reference to the ns file as an extra argument to the parser and it downloads the file itself |
| 14:02 | <Philip`> | or you pass the file itself to it |
| 14:02 | <Philip`> | although I'm probably confused |
| 14:02 | <Dashiva> | Just processing ns file as a standalone XML file, for editing or XSLT presentation or whatnot. |
| 14:02 | jgraham | isn't reading but solutions that rely on extra files, particularly ones that have to be fetched across the network, for interpretation are bad |
| 14:02 | <Philip`> | Do you mean processing the ns files in isolation, just as plain standalone XML files? |
| 14:03 | <jgraham> | So browsers would have to use the built-in file approach |
| 14:03 | <Philip`> | There's zillions of unnamespaced XML formats in the world and tools must work fine with them |
| 14:03 | <Dashiva> | jgraham: We covered that part, apparently the files won't really exist in practice |
| 14:03 | <Dashiva> | Oh, they work, but you lose the knowledge of what the file is |
| 14:03 | <Philip`> | X3D made a whole ISO standard without bothering with a namespace |
| 14:04 | <jgraham> | Dashiva: The proposal explicitly says that they will exist at some level as it vaugely mentions browsers updating them once a year |
| 14:04 | <Dashiva> | jgraham: Even those files are purely internal, so they'll probably be optimized away |
| 14:05 | <AryehGregor> | The proposal looks to me like "Okay, let's basically do what HTML5 is doing with namespaces, except in a way that lets non-browsers be told how to handle stuff in a standard fashion without needing to know about HTML specifically." |
| 14:05 | <Philip`> | Perhaps you could view it as a way of encoding http://whatwg.org/html5#parsing-main-inforeign and related rules in an easily-understandable easily-modifiable declarative format |
| 14:05 | <jgraham> | Right so the file "exists" insofar as it is expected to be an independently modifiable part of the browser |
| 14:06 | <Philip`> | so it can be extended without having to dive into the huge complexity of the HTML5 parsing algorithm |
| 14:06 | <AryehGregor> | Incidentally, I like how this page has all the visual annoyance of framesets without the ability to right-click and open the actual content in its own page. |
| 14:06 | <Dashiva> | It kinda ruins the extensibility part, though |
| 14:06 | <jgraham> | But I haven't yet worked out whether that is actually a sensible idea or not. Say html6 invents some new elements. Is it good or necessary to update existing browsers |
| 14:06 | Philip` | needs to be very careful when talking about parsing because his 'p' key intermittently fails to work |
| 14:06 | <jgraham> | ? |
| 14:06 | <Dashiva> | Since it has to hardcode every element name and attribute name |
| 14:06 | <AryehGregor> | No, because for extensibility you provide an explicit file. |
| 14:07 | <Philip`> | AryehGregor: I just disabled stylesheets on that page |
| 14:07 | <AryehGregor> | I mean, for distributed extensibility. |
| 14:07 | <AryehGregor> | For centralized extensibility it can be hardcoded, avoiding exposure of namespaces to authors. |
| 14:07 | <Dashiva> | AryehGregor: So in practice a certain fraction of authors will have to deal with two kinds of namespaces at once |
| 14:07 | <jgraham> | (or alternatively let's assume that HTML6 allows direct embedding of some fictional Midi Markup Language) |
| 14:08 | <AryehGregor> | Dashiva, no, because no one will actually use decentralized extensibility. |
| 14:08 | <Dashiva> | AryehGregor: We don't actually say that out loud |
| 14:08 | <jgraham> | What are the advantages of putting MML elements in the right namespace in some fraction of existing browsers where MML doesn't work anyway |
| 14:08 | <AryehGregor> | I thought we can in the #whatwg cabal, we only have to be diplomatic on public-html. |
| 14:09 | AryehGregor | reads the proposal |
| 14:09 | <Dashiva> | AryehGregor: lastweek is watching! |
| 14:09 | <gsnedders|work> | AryehGregor: AFAIK MLW hasn't added you to the cabal |
| 14:09 | <AryehGregor> | :( |
| 14:09 | <Dashiva> | You can have my spot, AryehGregor |
| 14:09 | <Dashiva> | I'm really too much of an outsider to be part anyhow |
| 14:10 | <gsnedders|work> | Dashiva just lurks around here and distracts us |
| 14:10 | <Dashiva> | I'm not even employed by a browser maker |
| 14:10 | <Philip`> | "it has to hardcode every element name and attribute name" - which "it" do you mean? (I might have lost track of the conversation) |
| 14:11 | <gsnedders|work> | (any more) |
| 14:11 | <Dashiva> | Philip`: The ns file |
| 14:12 | <Dashiva> | Related question, how does it handle having both xhtml:href and xlink:href in the same document? |
| 14:13 | <Philip`> | Dashiva: I think it only has to encode the root elements of differently-namespaced subtrees, like <html> and <svg> and <foreignObject> |
| 14:14 | <Philip`> | and it's rare that that list of elements will change |
| 14:15 | <AryehGregor> | "Once HTML 5 becomes a W3C Recommendation one might reasonably expect to see implementations" I guess they haven't looked at the timetables? |
| 14:15 | <Philip`> | Don't ask me how <foreignObject> would actually be encoded in the ns proposal |
| 14:16 | <Philip`> | (I guess it should not change its own namespace, but make its children default to the HTML namespace, and then you could use a <math> root if you want embedded maths instead of HTML?) |
| 14:16 | <Dashiva> | What about the hrefs? :) |
| 14:16 | <Philip`> | xhtml:href doesn't exist so that's not a problem |
| 14:16 | <Philip`> | and nobody should invent new attributes in namespaces |
| 14:17 | <Dashiva> | null:href, then |
| 14:18 | <Dashiva> | That is, what does <xhtml:a href="" xlink:href=""> look like with ns files? |
| 14:18 | <jgraham> | Doesn't MathML 3 have href and xlink:href on the same elements? |
| 14:18 | <AryehGregor> | This proposal actually seems extremely practical and reasonable. |
| 14:18 | <AryehGregor> | "in fact, the restriction is that the browser must not claim such a resource to be a well-formed XML document, but, once it is not XML it is outside the scope of the XML specification, and error recovery is perfectly acceptable, as long as no claim is made that the original document is itself XML." |
| 14:18 | <Philip`> | Dashiva: Don't allow both in the same vocabulary |
| 14:18 | <AryehGregor> | O RLY? |
| 14:19 | <Dashiva> | The extensibility is centralizing :) |
| 14:19 | <Philip`> | Dashiva: Anyway, replacing xlink:href with automatic href would break copy-and-paste of existing SVG XML so that's not going to be accepted |
| 14:19 | <AryehGregor> | http://www.w3.org/TR/2008/REC-xml-20081126/#dt-fatal |
| 14:20 | <AryehGregor> | Any XML processor that can handle errors sanely is not conforming. |
| 14:21 | <Philip`> | AryehGregor: I'd be interested in what they propose browsers should do instead of rejecting the document |
| 14:21 | <AryehGregor> | "They" who? |
| 14:21 | <Philip`> | Anybody |
| 14:21 | <AryehGregor> | This Liam Quin guy seems to think it would be fine for browsers to just implement HTML5-style error handling for XML. |
| 14:21 | <Philip`> | or anybody who says draconian error handling isn't a problem with XML, it's just browser developers being stupid |
| 14:22 | <Philip`> | and stupidly following the spec instead of doing something else |
| 14:22 | <Philip`> | and I'm wondering what the something else is |
| 14:22 | <AryehGregor> | Which seems to be totally contrary to the XML spec, but hey, he's XML Activity Lead and I'm some guy who to whom "robustness, accuracy, error detection and correctness are relatively unimportant". |
| 14:22 | <Philip`> | (and I'm assuming the something else must be clearly specified somewhere so it can be interoperably implementable) |
| 14:23 | <Dashiva> | AryehGregor: This proposal decentralizedly extends XML in a new and bold manner |
| 14:23 | <AryehGregor> | That's the tricky part. |
| 14:23 | <AryehGregor> | That's why XML says "fail horribly", AFAICT, so that you have consistent behavior. |
| 14:24 | <AryehGregor> | If you say "Well, it's no longer XML, so feel free to do whatever you want with it", you've just completely lost interoperability. |
| 14:24 | <Dashiva> | But if it isn't well-formed, then it isn't an XML document, by definition |
| 14:24 | <Philip`> | In any case, the proposal is about modifying XML and therefore largely irrelevant, because nobody uses XHTML |
| 14:25 | AryehGregor | votes for HTML5 syntax to be generalized a bit, called "Robust Markup Language" or something, moved to its own spec, and pushed as an XML successor |
| 14:25 | <Philip`> | AryehGregor: Please don't |
| 14:25 | <Philip`> | AryehGregor: HTML5 is horrid syntax |
| 14:25 | <Dashiva> | AryehGregor: Sounds like it could be taken under the mantle of XML5 |
| 14:25 | <Philip`> | and shouldn't be pushed beyond where it's currently required |
| 14:25 | <AryehGregor> | Philip`, right, except we might be able to shut up the namespace partisans. |
| 14:25 | <AryehGregor> | I mean, with respect to no one using XHTML. |
| 14:26 | <jcranmer> | so basically we replace XML with a mixed-XML-and-SGML successor? |
| 14:26 | <jcranmer> | yuck |
| 14:26 | <Philip`> | unless by "generalized" you mean removing basically all of it and just leaving some simple consistent error-handling behaviour |
| 14:26 | <AryehGregor> | With respect to an HTML5-based syntax, okay, granted. But something that has well-defined error handling should replace XML. |
| 14:26 | <Philip`> | XML has well-defined error handling |
| 14:26 | <jcranmer> | I prefer the "you messed up, screw you" error handling |
| 14:26 | <Philip`> | (Well, as long as you're not one of the XML proponents who pretends it doesn't) |
| 14:26 | <AryehGregor> | Well-defined and *sane* error handling, fine. |
| 14:27 | <Philip`> | (and claims that as an advantage) |
| 14:27 | <gsnedders|work> | Philip`: No, it doesn't have well-defined error handling. Just look at handling of unknown entities in non-validating parsers. |
| 14:27 | <jgraham> | There is a vauge idea for XML5 |
| 14:27 | <AryehGregor> | XML was designed to be easily machine-readable. It's not, you need a slow and bloated library to use it anyway. So we may as well make it more human-friendly at the expense of more implementation complexity. |
| 14:28 | <Philip`> | jcranmer: The problem is that in practice it's commonly "somebody involved in the development of this site which you're trying to look at messed up, screw you" |
| 14:28 | <gsnedders|work> | jgraham: Vague idea? annevk has prototype spec and impl |
| 14:28 | <AryehGregor> | Although I grant that HTML5's baroque error handling is way too web-specific to sanely saddle anyone with. |
| 14:28 | <gsnedders|work> | http://code.google.com/p/xml5/ |
| 14:28 | <AryehGregor> | CSS is maybe a better model for good error handling. |
| 14:28 | <jgraham> | gsnedders|work: Yeah but no real traction. |
| 14:28 | <gsnedders|work> | Last commit: |
| 14:28 | <gsnedders|work> | Oct 21, 2007 |
| 14:29 | <AryehGregor> | Did anyone else notice that the XML proposal by the XML Activity Lead contains malformed XML in an example? <element src="eacml.ns /> |
| 14:29 | <Philip`> | AryehGregor: That's not malformed XML |
| 14:30 | <Philip`> | It's not well-formed XML, so it's not XML at all |
| 14:30 | <Dashiva> | No true scotsman |
| 14:30 | <AryehGregor> | Draconian error handling is fine for things that are basically always written by hand. Like programming languages. |
| 14:30 | <AryehGregor> | For data formats it's completely unreasonable. |
| 14:30 | <Dashiva> | It's fine for cases where the error can be detected _at authoring time_ |
| 14:31 | <AryehGregor> | Which it can't if the markup is built by a script. |
| 14:31 | <Philip`> | I think it's fine for data formats as long as it's easy to generate non-erroneous output |
| 14:31 | <AryehGregor> | Which any general-purpose data markup language has to handle. |
| 14:31 | <AryehGregor> | Yes, I'll agree with that too. |
| 14:31 | <AryehGregor> | Draconian error handling for JSON is fine because it's so simple. |
| 14:32 | <Dashiva> | Eh? |
| 14:32 | <AryehGregor> | (although I don't know what JSON's error handling is actually like) |
| 14:32 | <AryehGregor> | Eh what? |
| 14:32 | <Dashiva> | Have you seen all the broken JSON out there? |
| 14:32 | <Philip`> | and the problem with XML as a data format is not that it's draconian, but that the draconianness applies in lots of weird complex ways, like certain forbidden characters and certain forbidden element and attribute names and attribute values |
| 14:32 | <Dashiva> | There's a lot of JSON that isn't actually JSON, it's serialized javascript source |
| 14:32 | <AryehGregor> | So what happens to it? |
| 14:32 | <Dashiva> | It works because you use Javascript eval() to parse it |
| 14:33 | <Dashiva> | But it isn't JSON |
| 14:33 | <Philip`> | It's pretty trivial to get correctly nested tags and quotes around attribute values, so I think it's fine for a format to require that |
| 14:33 | <AryehGregor> | Interesting. |
| 14:33 | <AryehGregor> | Philip`, well, I don't want my site to die unnecessarily because of a typo that would be reasonably correctable by the client. |
| 14:34 | <AryehGregor> | Fail-fast isn't a good idea except if you'd prefer death to unknown errors. |
| 14:34 | <Philip`> | but it's really hard to avoid problems like how http://www.rddl.org/rddl2rdf.xsl applied to http://www.w3.org/XML/1998/namespace gives non-well-formed output |
| 14:34 | <Philip`> | and so it's bad for that kind of unexpected situation to cause death |
| 14:35 | <AryehGregor> | I'd argue that misnesting tags isn't as trivial to avoid as you think. |
| 14:35 | <Dashiva> | Remember, well-formed XML runs our national security infrastructure |
| 14:35 | <Dashiva> | One error and the nukes fly |
| 14:35 | <AryehGregor> | MediaWiki has some known tag misnesting bugs that have sat around for years because they'd require a remarkable amount of effort to fix. |
| 14:36 | <AryehGregor> | It depends on how you're generating your output. |
| 14:36 | zcorpan_ | notes that othermaciej and julian have gotten the xhtml namespace wrong |
| 14:36 | <Philip`> | I'd argue that I've seen lots of XML sites and serializers that break because of funny characters or incorrect namespace declarations, and none that break because user input can cause them to emit misnested tags |
| 14:36 | <AryehGregor> | I don't think any syntax error should be fatal in remotely complicated data formats. If in any data formats at all. |
| 14:37 | <AryehGregor> | Philip`, counterexample: MediaWiki serving an XML MIME type. :) |
| 14:37 | <AryehGregor> | I doubt it's unique, either. |
| 14:37 | <AryehGregor> | Although maybe not typical. |
| 14:37 | <Philip`> | ...except for all the sites that display unescaped user input directly, but they're just as broken and insecure with text/html |
| 14:37 | <AryehGregor> | Philip`, with text/html they're vulnerable only to malice. With an XML MIME type the site could be taken down by ignorance. |
| 14:38 | <AryehGregor> | Ignorance is a lot more prevalent than malice. |
| 14:38 | <AryehGregor> | Especially since even XML gurus are liable to typo sometimes. |
| 14:38 | <AryehGregor> | Oops, guess you can't reach the edit button for your post (if there is one). |
| 14:39 | <Dashiva> | Edit another page, modify the URL :) |
| 14:41 | <Philip`> | Just stick an XML5 parser/serializer in there, to correct the nesting |
| 14:41 | <Philip`> | (and other typos) |
| 14:42 | <Philip`> | That's hard to do nowadays with XML, because XML is too complex and so serializers have bugs and produce ill-formed output |
| 14:43 | <Philip`> | (I think I remember getting ill-formed output out of Xalan and the validator.nu serializer and GenX) |
| 14:44 | <AryehGregor> | So you clean up bad markup on the server side rather than the client? What's the point? That just moves the complexity to a place that's less likely to implement it correctly. |
| 14:45 | <zcorpan_> | if it's well-formed, it can be parsed *really fast* |
| 14:45 | <zcorpan_> | unlike html tag soup which takes ages to parse because error correction is slow |
| 14:47 | <Philip`> | (Sadly Tim Bray (of Genx) seems to have forgotten his "$500 reward for each significant bug reported that would allow someone to use the API as documented but produce non-well-formed output." :-( ) |
| 14:56 | <Dashiva> | zcorpan_: Can it really? |
| 14:57 | <Dashiva> | I'm guessing you were sarcastic, but still |
| 14:57 | <Dashiva> | Even an XML processor has to detect invalid input, so all the checks happen even if the input is valid |
| 14:59 | <gsnedders|work> | Dashiva: Yeah, it makes absolutely no difference |
| 14:59 | <Philip`> | It makes a difference to code size |
| 14:59 | <Philip`> | which will have a non-zero effect on performance |
| 15:00 | <Philip`> | (Potentially a huge effect if it makes your methods too big for HotSpot) |
| 15:00 | <Dashiva> | Can't that be handled by just making more methods? |
| 15:01 | <Philip`> | I assume HTML parsers also have to carry around and update some state that wouldn't be needed if there wasn't any complex error correction |
| 15:02 | <Philip`> | But the differences are probably negligible compared to the cost of I/O |
| 15:03 | zcorpan_ | was being sarcastic, but notes he has heard that argument several times |
| 15:03 | <gsnedders|work> | running git svn clone is fairly slow on the webapps repo |
| 15:04 | <gsnedders|work> | (Sorry, but I want to run blame, to see when stuff changed, so I can dig up the commit message) |
| 15:13 | <gsnedders|work> | <atom:link rel="self" href=""/> fulfils the SHOULD requirement in Atom for atom:link@rel='self', right? |
| 15:15 | <zcorpan_> | isn't the point of rel='self' to include the absolute url? |
| 15:15 | <zcorpan_> | in case the feed's url gets lost somewhere in the chain of whatever is done with the feed |
| 15:15 | <gsnedders|work> | Yeah, basically. But I'm wondering how I can deal with a feed that doesn't really have a URL |
| 15:17 | <zcorpan_> | if it doesn't have a URL, that seems like a valid reason to violate the SHOULD |
| 15:17 | <gsnedders|work> | Yeah, it does. But it seems fun to do weird things to comply with the spec as much as possible. |
| 15:18 | gsnedders|work | has plans for thereshouldbenored.com |
| 15:19 | <zcorpan_> | will you make it html/js/css/atom polyglot? |
| 15:19 | zcorpan_ | should patent the technique |
| 15:20 | <gsnedders|work> | Nah |
| 15:20 | <gsnedders|work> | Though that is an idea |
| 15:21 | gsnedders|work | wonders how to pull off HTML/Atom |
| 15:21 | <zcorpan_> | http://simon.html5.org/dump/html+js+css+atom.html |
| 15:22 | <gsnedders|work> | No DOCTYPE :( |
| 15:22 | <zcorpan_> | need quirks mode |
| 15:22 | <zcorpan_> | for css |
| 15:22 | <Philip`> | Why should there be nored? |
| 15:22 | <gsnedders|work> | That sux. |
| 15:22 | <zcorpan_> | also it wouldn't validate as html5 anyway because it uses bogus comments |
| 15:22 | Philip` | is incapable of reading that URL as having a space after "no" |
| 15:23 | <gsnedders|work> | Philip`: Why? |
| 15:23 | <Philip`> | gsnedders|work: I don't know - it's just how I read it, given the lack of punctuation |
| 15:24 | <zcorpan_> | there.should.be.no.red |
| 15:24 | gsnedders|work | should have blatantly tried for there.should.be.no.red |
| 15:24 | <Philip`> | I think red.com might already be registered |
| 15:24 | <zcorpan_> | but not no.red |
| 15:24 | <gsnedders|work> | .ed doesn't exist :( |
| 15:24 | <Philip`> | Oh |
| 15:24 | <gsnedders|work> | there.should.be.red.no |
| 15:25 | <Philip`> | red.there.should.be.no then it'll sound like Yoda |
| 15:25 | <zcorpan_> | you can mint new TLDs nowadays, no? |
| 15:25 | <zcorpan_> | be.no is taken |
| 15:26 | <gsnedders|work> | No, you can't |
| 15:26 | <zcorpan_> | bummer |
| 15:26 | <gsnedders|work> | there.should.be.no.red.info |
| 15:27 | <gsnedders|work> | dammit, red.info taken |
| 15:27 | <Philip`> | red.there.shouldnt.be is taken too |
| 15:27 | <Philip`> | and shouldn’t.be is apparently not allowed |
| 15:27 | <Philip`> | (though shouldn’t.eu claims to be allowed) |
| 15:28 | <Dashiva> | your.tests.are.totally.inaccessible.info |
| 15:28 | <gsnedders|work> | taken |
| 15:33 | tantek | prefers PHP/JS biglot: http://cassisproject.com/ |
| 15:37 | zcorpan_ | wrote a js file that was polyglot helper function for a web worker and a helper function for normal <script> inclusion last night |
| 15:38 | <zcorpan_> | sadly i ended up commenting out the web worker code path because the web worker implementations suck too much |
| 15:39 | Philip` | isn't particularly attracted by the idea of a language subset in which you can't even declare variables |
| 15:42 | <Dashiva> | Philip`: Don't you do haskell? |
| 15:42 | <jgraham> | Hmm? Haskell lets you declare variables |
| 15:43 | <jgraham> | For some meaning of variables |
| 15:43 | <Dashiva> | Some meaning, yes |
| 15:43 | <Philip`> | Dashiva: No, but anyway that's different because all variables have local scope |
| 15:43 | <Philip`> | whereas JS without 'var' means every variable is global |
| 15:44 | jgraham | doesn't really understand the point of hacking javascript and php into the same file |
| 15:44 | <zcorpan_> | if it can be done, someone will do it |
| 15:45 | <jgraham> | It seems like anything you gain from code reuse will be lost in the fact that it is an enormous hack |
| 15:45 | <jgraham> | zcorpan_: That's not really a point. At least not a point of suggesting it as a sensible approach |
| 15:48 | <hsivonen> | Philip`: whoa! Did Tim Bray have a $500 bounty on WF bugs in GenX and didn't pay you? |
| 15:48 | hsivonen | sensibly doesn't have the confidence to promise money bounties to Philip` |
| 15:49 | <Dashiva> | hsivonen: Promise bounties redeemable in person only, and stop going to TPAC |
| 15:50 | <hsivonen> | I may have promised a drink bounty before the previous TPAC, but I forget if I did but at least there was no one to claim it |
| 15:51 | <Philip`> | hsivonen: He said in http://www.tbray.org/ongoing/When/200x/2004/01/11/PostelPilgrim that he would have a bounty, and later said he'd start it once he thought Genx was reasonably stable |
| 15:52 | <Philip`> | but that was in 2004 and then I don't think he ever said he'd start offering bounties at a particular point in time |
| 15:52 | <hsivonen> | Philip`: I conclude genx isn't reasonably stable |
| 15:52 | <jgraham> | Did he actually know you broke it> |
| 15:53 | <jgraham> | s/>/?/ |
| 15:54 | <Philip`> | jgraham: Yes |
| 15:54 | <Philip`> | http://lists.w3.org/Archives/Public/www-archive/2009Mar/0060.html (and he replied saying he'd look into it) |
| 15:55 | <Philip`> | http://www.tbray.org/ongoing/When/200x/2004/02/20/GenxStatus - "2004/07/25 ... I think we’re close. If someone sends me one more story about Genx being in real production somewhere, I’ll take the “beta” stamp off and announce the rewards-for-bugs program." |
| 15:56 | <jgraham> | So you just need to prove that someone did that ;) |
| 15:56 | <hsivonen> | I guess I should have sent a story of Genx in "production" if a hobby script counts as production |
| 15:57 | <hsivonen> | later, though, I've regretted using Genx, because there's no Ubuntu package for it, so I've been unable to migrate the script to a host that doesn't have gcc |
| 15:57 | <hsivonen> | and all the -dev packages |
| 15:57 | <hsivonen> | and I haven't bothered setting up another box just for compiling pygenx |
| 15:57 | <jgraham> | Has the bug been fixed? |
| 15:58 | <hsivonen> | speaking of pygenx, is there a pure python substitute these days? |
| 15:59 | <jgraham> | (If the bug hasn't been fixed I suggest you put gnex into production somewhere and email with the notice of production at the top and the repeated bug report at the bottom ;) |
| 16:00 | <Philip`> | jgraham: http://www.tbray.org/ongoing/genx/ indicates no updates released since 2004 |
| 16:00 | <Philip`> | jgraham: But that would require me to put known-buggy software into production, which would be terribly irresponsible |
| 16:01 | <jgraham> | You could patch the bug locally |
| 16:03 | <Philip`> | How can I trust that it's not riddled with other bugs? |
| 16:03 | <Philip`> | (other than knowing that I spent a while looking through the source code and didn't see any other bugs) |
| 16:49 | <JonathanNeal> | Goodmorning Everyone! \o/ |
| 16:49 | <daedb> | Good evening |
| 16:50 | <cardona507> | good morning |
| 17:55 | <Dashiva> | I wonder what happened here: http://twitter.com/marcosc/status/5435533789 |
| 18:39 | <othermaciej> | abarth: I think you may have overstated your case about the issue with Tyler's protocol |
| 19:22 | <Hixie> | is toby inkster here? |
| 19:23 | <gsnedders|work> | No, maybe in #microformats though? |
| 19:23 | <tantek> | alias: tobyink |
| 19:31 | gsnedders|work | could remember it was something similar to his name, just not the exact string |
| 19:32 | <jgraham> | hsivonen: I agree with the observation that requiring an extra HTTP request to get namespace bindings is a non-starter (and was considering saying as much) |
| 19:50 | <nessy1> | hsivonen: are you around? |
| 19:50 | <hsivonen> | nessy: yes |
| 19:51 | <nessy> | we're currently discussion aria role usage and the influence on validating a html5 document in #aapi |
| 19:51 | <nessy> | I was looking for you thoughts |
| 19:51 | <Hixie> | #aapi on irc.w3.org |
| 19:55 | <hsivonen> | nessy: I'm going to hit time zone barriers soon :-( |
| 19:55 | <nessy> | bummer - just thought it would be good to get your input |
| 19:55 | <nessy> | of course you can always contribute more later |
| 19:56 | <nessy> | just discussing your statement now :) |
| 20:29 | <JonathanNeal> | Happy Afternoon!!! \o/ |
| 20:59 | <Philip`> | http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Nov/0013.html - "We don't trust [XML] 5th Edition." |
| 21:00 | <Philip`> | Is anybody adopting it yet? |
| 21:02 | <gsnedders> | libxml 2.7 |
| 21:08 | <Philip`> | Does it have a 4th Edition option? |
| 21:08 | <gsnedders> | dunno |
| 21:09 | <Philip`> | If not, I guess it's impossible to implement a conforming XHTML or RDFa processor with libxml 2.7 |
| 21:09 | <Philip`> | Hooray for redefining well-formedness |
| 21:09 | <gsnedders> | How come? |
| 21:09 | <gsnedders> | Because it won't properly refuse not well-formed content |
| 21:10 | <gsnedders> | ? |
| 21:10 | <Philip`> | Yes |
| 21:10 | <Philip`> | so it will extract data that it shouldn't extract |
| 21:14 | <gsnedders> | Philip`: Know of any good Python XML serializer? |
| 21:14 | <Philip`> | gsnedders: print |
| 21:15 | <gsnedders> | Philip`: That I can rely upon to output well-formed XML? |
| 21:15 | <Philip`> | That's easy |
| 21:15 | <Philip`> | print "<example/>" |
| 21:15 | <gsnedders> | Philip`: :P |
| 21:15 | <Philip`> | That's always going to output well-formed XML |
| 21:15 | <gsnedders> | Philip`: With arbitrary content? |
| 21:16 | <Philip`> | Like you give it a tree containing arbitrary strings and it corrects errors and outputs XML? |
| 21:16 | <gsnedders> | Yeah |
| 21:16 | <Philip`> | No |
| 21:16 | <gsnedders> | Oh. Oh well then. |
| 21:52 | gsnedders | adds some JS to http://thereshouldbenored.com/ so it could be green |
| 21:55 | <Lachy> | Hixie, ping |
| 21:56 | <Dashiva> | Can Math.random() * 100 actually be 42... |
| 21:56 | <gsnedders> | When rounded, yes |
| 21:56 | <Philip`> | How is it rounded? |
| 21:57 | <gsnedders> | Math.round(Math.random() * 100) |
| 21:57 | <Dashiva> | True |
| 21:57 | <Dashiva> | I for some reason ignored the round |
| 21:57 | <Dashiva> | So let's deal with that question instead |
| 21:57 | <gsnedders> | (even when not rounded it could be 42, it's just quite unlikely) |
| 21:58 | <Dashiva> | To the last floating point bit? |
| 21:58 | <jgraham> | It could be 42 in Javascript |
| 22:02 | <JonathanNeal> | Definitely maybe. |
| 22:04 | <gsnedders> | Definitely. |
| 22:04 | <Philip`> | Dashiva: Looks like it can be exactly 42 |
| 22:04 | <Philip`> | but only if you use double-precision numbers |
| 22:04 | <jgraham> | Javascript only has a single numbe type |
| 22:05 | <Dashiva> | But that one type is double |
| 22:05 | <Hixie> | Lachy: pong |
| 22:05 | <Dashiva> | So I guess it's possible |
| 22:05 | <Philip`> | Compare perl -le'print 100*(unpack f => pack f => 42/100)-42' vs perl -le'print 100*(unpack F => pack F => 42/100)-42' |
| 22:05 | <Philip`> | (First (single precision) says -1.31130218505859e-06, second (double precision) says 0) |
| 22:05 | <Lachy> | Hixie, nevermind. Was just wondering whether you were going to be coming to this meeting |
| 22:05 | <jgraham> | Dashiva: Right, I mean there is only one type, not that it is single precision |
| 22:06 | <jgraham> | Oh wait my argument is wrong |
| 22:06 | <jgraham> | listen to Philip` |
| 22:07 | <gsnedders> | jgraham: Well, of course, Philip`'s argument is inevitably better. |
| 22:09 | <Philip`> | It could be wrong, though |
| 22:10 | <gsnedders> | Indeed |
| 22:11 | <Dashiva> | Nobody will notice, though. That's how good your argument is. |
| 22:12 | <Philip`> | I just like using Perl's fat comma |
| 22:21 | <Philip`> | http://www.google.co.uk/search?q=%22your+comma%27s+so+fat%22 - hmm, a sadly missed opportunity for Perl syntax related humour |
| 22:46 | <remysharp> | quick daft question, if I want to quote my attributes, is it <video controls="controls"> or <video controls="true"> |
| 22:46 | <remysharp> | or it doesn't make any difference? |
| 22:49 | <Dashiva> | remysharp: The attribute works just by being present |
| 22:49 | <remysharp> | that's what I figured |
| 22:49 | <remysharp> | is there a "best practise" for quoted attribs - |
| 22:49 | <Dashiva> | I think that's using the attribute name |
| 22:49 | <remysharp> | I thought it was to repeat the key in the value |
| 22:50 | <remysharp> | or "xhtml" type sytnax |
| 22:53 | <Philip`> | remysharp: <video controls=""> |
| 22:53 | <remysharp> | really? that doesn't look very "xhtml"ly |
| 22:53 | <Philip`> | is equivalent to <video controls> and therefore works and is allowed |
| 22:53 | <remysharp> | sure |
| 22:54 | <Philip`> | http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#boolean-attributes |
| 22:54 | <TabAtkins> | remysharp: If you're doing HTML syntax, just do the plain name. It's the easiest and works great. |
| 22:54 | <remysharp> | I'm looking for the syntax that matches the <option selected="selected"> type of syntax from xhtml |
| 22:54 | remysharp | checking your link |
| 22:54 | <TabAtkins> | <option selected> |
| 22:54 | <Philip`> | "If the attribute is present, its value must either be the empty string or a value that is an ASCII case-insensitive match for the attribute's canonical name, with no leading or trailing whitespace." |
| 22:54 | <remysharp> | cool |
| 22:54 | <remysharp> | thanks for that |
| 22:55 | <remysharp> | so it's either "" or controls="controls" |
| 22:55 | <Philip`> | Yep |
| 22:55 | <remysharp> | ta :) |
| 22:55 | <TabAtkins> | If you need a value, yeah. |
| 22:55 | <Philip`> | or controls="CoNtRoLs" if you fancy |
| 22:55 | <nessy> | lol |
| 22:56 | <TabAtkins> | <p leettext="lEeTtExT"> |
| 22:58 | <annevk2> | note that you can write selected="" in XHTML too |
| 22:58 | <annevk2> | way shorter |
| 23:34 | <j^> | hi, why does the html sanitizer from http://code.google.com/p/html5lib/source/browse/python/src/html5lib/sanitizer.py |
| 23:34 | <j^> | not include html5 tags |
| 23:35 | <j^> | like video and audio |