| 00:12 | <cardona507> | jquery |
| 00:12 | <cardona507> | ooops - wrong room |
| 01:30 | <othermaciej> | do any Web Apps WG specs have an official test suite yet? |
| 01:33 | <othermaciej> | hmm I see ElementTraversal has one |
| 05:20 | <jtbandes> | Hi all... HTML5 semantics question. Should I do this: <html>...<body><header>...</header><nav>...</nav>...<section id="posts"><article><header><h1>Post title</h1></header><p>Post content</p></article></section>...</body></html> |
| 05:21 | <jtbandes> | Or this? ...<div id="posts"><article><header><h1>Title</h1></header><section class="post-body"><p>Content</p></section></article></div> |
| 05:21 | <Hixie> | both are fine, depending on what you want your document outline to look like |
| 05:22 | <jtbandes> | I'm just unclear on where <section> is to be used and where it should be <div> |
| 05:22 | <jtbandes> | Like, right now I have <section id="main"><aside>...</aside>..a bunch of <article>s |
| 05:23 | <jtbandes> | But I'm running into compatibility issues styling the <article>s' <p> tags, because not all browsers support CSS3 :first-of-type and :last-of-type at the moment |
| 05:23 | <jtbandes> | So I'm wondering if I should go with <article><header><h1>Title</h1></header><section class="post-body"><p>... instead |
| 05:23 | <jtbandes> | Or something entirely different. |
| 05:25 | <jtbandes> | The HTML5 draft spec seems a bit vague in its examples; it says "A general rule is that the section element is appropriate only if the element's contents would be listed explicitly in the document's outline." and "Examples of sections would be chapters, the various tabbed pages in a tabbed dialog box, or the numbered sections of a thesis. A Web site's home page could be split into sections for an introduction, news items, contact information." |
| 05:27 | <jtbandes> | Hixie: HTML5 may not be at the point for what's "right" or "wrong", but maybe just suggestions on semantics right now. I don't know |
| 05:34 | <jtbandes> | Any ideas? |
| 05:53 | <Hixie> | jtbandes: sorry, got distracted |
| 05:53 | <jtbandes> | np |
| 05:53 | <Hixie> | jtbandes: basically, use <section> for anything where you would feel ok giving a section title (<h1>) and including that section title in a table of contents |
| 05:54 | <Hixie> | jtbandes: and use <div> if the only reason you have the element is styling or scripting |
| 05:55 | <jtbandes> | Hixie: does <article>/<hgroup>/something start a new heading level like <section> does? |
| 05:57 | <Hixie> | <article>, <nav>, <section>, and <aside> are the same in that respect, yes |
| 05:59 | <jtbandes> | Would this make sense then? <section id="main"><h1>Posts</h1><article><header><h1>Title</h1></header><section class="post-body"><p>... |
| 06:00 | <Hixie> | no need for the post-body one |
| 06:00 | <Hixie> | other than that, yes |
| 06:01 | <jtbandes> | I feel like I should mark up the body of each <article> |
| 06:01 | <jtbandes> | If nothing else, to make styling the first <p> element easier |
| 06:07 | <Hixie> | jtbandes: use <div> for that |
| 06:07 | <jtbandes> | Hm |
| 06:07 | <Hixie> | (if tabatkins reads the archives... there's another example of why we should fix <di> in CSS/DOM rather than in markup) |
| 06:26 | <jtbandes> | Hixie: <di>? |
| 06:27 | <Hixie> | a long running discussion unrelated to what you're talking about, don't worry :-) |
| 06:27 | <jtbandes> | But I'm curious now :) |
| 06:28 | <Hixie> | it's hard to style grounps of <dt>/<dd>s |
| 06:28 | <Hixie> | (as well as groups of lots of other things, like the stuff after an <h1> in a <section>, as you mentioned) |
| 06:29 | <jtbandes> | Well, in that particular case it'd be p:first-of-type, but that's CSS3 and not widely supported |
| 06:29 | <Hixie> | so some people, instead of suggesting we fix CSS to make it possible to style these groups once and for all, think we should have authors who want to style those sections add <di> elements to their <dl>s to wrap the groups |
| 06:29 | <jtbandes> | o_O |
| 06:29 | <Hixie> | it's not as bad as i made it sound |
| 06:30 | <Hixie> | but these are the kinds of things we often talk about in #whatwg :-) |
| 06:30 | <Hixie> | afk, playing game |
| 06:30 | <jtbandes> | Is WhatWG responsible for CSS too? |
| 06:31 | <jtbandes> | Because I really want nested selectors... like #main { ...styles... p { line-height: 1.3em;... } } |
| 12:38 | <GPHemsley> | Yeah, I'd like to be able style elements based on what children they have.... |
| 12:39 | <GPHemsley> | (in response to jtbandes and Hixie from 6 hours ago) |
| 12:39 | <MikeSmith> | zcorpan: I think xml-stylesheet checking is now passing all test cases you've given so far |
| 12:40 | <zcorpan> | MikeSmith: cool |
| 12:40 | <zcorpan> | MikeSmith: did you remove the rest of the win1252 table? |
| 12:40 | <MikeSmith> | I'm sure there are some other bugs in there that we've not found so far |
| 12:41 | <MikeSmith> | zcorpan: no |
| 12:41 | <MikeSmith> | should I? |
| 12:41 | <MikeSmith> | I don't actually even know what that's for |
| 12:41 | <zcorpan> | MikeSmith: yes, xml charref has no fixups |
| 12:41 | <MikeSmith> | OK |
| 12:41 | <MikeSmith> | I'll remove it now |
| 12:43 | <zcorpan> | it's for € showing a eurosign instead of a control character in text/html |
| 12:43 | <MikeSmith> | OK |
| 12:44 | <MikeSmith> | so the whole of C1 controls range is allowed? |
| 12:44 | <MikeSmith> | or I should still emit an error for that |
| 12:44 | <MikeSmith> | ? |
| 12:45 | <zcorpan> | you should emit an err if the expanded character is not: |
| 12:45 | <zcorpan> | [2] Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF] /* any Unicode character, excluding the surrogate blocks, FFFE, and FFFF. */ |
| 12:45 | <zcorpan> | http://www.w3.org/TR/REC-xml/#NT-Char |
| 12:46 | <MikeSmith> | OK |
| 12:46 | <zcorpan> | (and possibly warn for control characters and undefined unicode characters) |
| 12:48 | <zcorpan> | (and "compatibility characters", whatever they are) |
| 12:52 | <MikeSmith> | zcorpan: OK, I ripped out the win1252 stuff and pushed an update to qa-dev |
| 12:52 | <MikeSmith> | I can add the other warnings later |
| 12:55 | <zcorpan> | great |
| 12:56 | <MikeSmith> | zcorpan: update patch is at http://bugzilla.validator.nu/attachment.cgi?id=136 |
| 12:56 | <MikeSmith> | that includes some other stuff I added recently |
| 12:56 | <MikeSmith> | charset checker |
| 12:58 | <MikeSmith> | but if you see anything remaining in the XmlStylesheetChecker code that looks wrong/suspicious, lemme know |
| 12:58 | <MikeSmith> | btw, I think will suggest to hsivonen that we change the name of that to LexicalChecker |
| 12:58 | <MikeSmith> | or something |
| 12:59 | <MikeSmith> | because due to the need to check if instancesd of xml-stylesheets PIs are in doctype declarations, it now has to be an implementation of SAX LexicalHandler |
| 13:00 | <MikeSmith> | so we could choose to turn it into a variety lexical checker that includes specific checking for xml-stylesheet PI content |
| 13:01 | <MikeSmith> | (though the xml-stylesheet checking is itself not lexical) |
| 13:03 | <MikeSmith> | but one other thing that comes to mind that it could potentially be used for is warning about CDATA secions |
| 13:03 | <MikeSmith> | *sections |
| 13:04 | <zcorpan> | why would you warn about cdata sections? |
| 13:04 | <MikeSmith> | for checking reverse-polygot document case -- people who have XHTML documents and want to test to make sure they can be parsed as text/html |
| 13:05 | <MikeSmith> | we can warn, "Document contains CDATA sections; can't be parsed as text/html." |
| 13:05 | <MikeSmith> | right? |
| 13:05 | <MikeSmith> | hmm |
| 13:05 | <MikeSmith> | I guess maybe the htmlparser already warns about that |
| 13:05 | MikeSmith | checks |
| 13:05 | <zcorpan> | ah, i thought polyglot checking would be code in the html parser checking for xml compat |
| 13:06 | <annevk> | you should prolly rename it also for XBL |
| 13:06 | <annevk> | though that depends on whether we'll still introduce <?xbl?> or not |
| 13:06 | <zcorpan> | you can have cdata sections in foreign lands |
| 13:07 | <MikeSmith> | well, we could check and report it only if it's not in foreign lands |
| 13:07 | <MikeSmith> | annevk: yeah |
| 13:08 | <MikeSmith> | maybe I can just rename the class VarietyChecker |
| 13:08 | <MikeSmith> | that makes it sound fun |
| 13:09 | <MikeSmith> | annevk: remind me, the idea of having a PI for CORS has been dropped? |
| 13:10 | <MikeSmith> | annevk, zcorpan : btw, I notice that v.nu checking for media-query values seems to fail for many examples in the current draft |
| 13:11 | <MikeSmith> | is it worth updating/fixing it at this point? |
| 13:12 | <zcorpan> | i'm not really up to speed with mq status, but i'm under the impressino that browsers are pretty aligned with the latest draft |
| 13:13 | <MikeSmith> | zcorpan: if that's the case, I guess I should look into updating it |
| 13:14 | <MikeSmith> | the fixes might be simple |
| 13:14 | <MikeSmith> | well, probably not simple |
| 13:14 | <MikeSmith> | but maybe not too difficult |
| 13:21 | <annevk> | MikeSmith, yes |
| 13:21 | <MikeSmith> | ok |
| 13:21 | <annevk> | MikeSmith, dunno about media queries |
| 13:21 | <annevk> | they'd require a full CSS parser to properly support |
| 13:22 | <MikeSmith> | hmm |
| 13:22 | <annevk> | you can use e.g. CSS escapes and all |
| 13:22 | <MikeSmith> | I wonder if there's a java CSS parsing library |
| 13:22 | <MikeSmith> | if so, we could just import and use that |
| 13:22 | <annevk> | well, there's the W3C CSS parser right? |
| 13:22 | <annevk> | isn't that in Java? |
| 13:23 | <annevk> | would be cool if it could be integrated so <style> style="" etc. can be checked too |
| 13:24 | <zcorpan> | you'd want to check external css too if you're checking css |
| 13:24 | <MikeSmith> | annevk: yeah, current w3c css validator is written in java |
| 13:24 | <annevk> | and feeds, etc. |
| 13:24 | <MikeSmith> | yeah |
| 13:24 | <annevk> | and images |
| 13:25 | <annevk> | should prolly have a checkbox for external resources |
| 13:26 | <MikeSmith> | BN |
| 13:26 | <annevk> | BN? |
| 13:26 | <MikeSmith> | if the css valididator exposes a rest interface, I guess I could maybe just use that |
| 13:27 | <zcorpan> | MikeSmith: <?xml-stylesheet HREF=""?> is invalid |
| 13:27 | <MikeSmith> | zcorpan: OK |
| 13:27 | MikeSmith | checks now |
| 13:28 | <MikeSmith> | ah crap |
| 13:28 | <MikeSmith> | css validator only has a soap interface, I guess |
| 13:30 | <MikeSmith> | zcorpan: I see now that's an side effect of the fact I'm using switch/case for checking the attribute names |
| 13:30 | <annevk> | switch/case is case-insensitive? |
| 13:31 | <zcorpan> | MikeSmith: i thought it was because of c += 0x20; in various places |
| 13:31 | <MikeSmith> | annevk: in java you can only use constants in case statements |
| 13:32 | <MikeSmith> | and I was just following the convention of using uppercase for constants |
| 13:32 | <MikeSmith> | the lowercasing to compare |
| 13:32 | <annevk> | Java is weird |
| 13:33 | <MikeSmith> | zcorpan: probably that too |
| 13:33 | <annevk> | though Python does not have case/switch at all, which is also somewhat weird |
| 13:33 | <zcorpan> | MikeSmith: your tokenizer normalizes pseudo-attributes to lowercase |
| 13:33 | <zcorpan> | MikeSmith: the constants' names shouldn't matter, should they? |
| 13:35 | <MikeSmith> | zcorpan: it matters in this case because I convert the name of the attribute and uppercase it and compare that to the constant name |
| 13:36 | <MikeSmith> | I can just make the constant names lowercase |
| 13:36 | <MikeSmith> | or just change it all to if |
| 13:36 | <zcorpan> | oh |
| 13:37 | <MikeSmith> | zcorpan: yeah, I can see I need to remove all that c += 0x20 stuff |
| 13:40 | <MikeSmith> | anyway, I gotta drop off for now |
| 16:27 | <annevk> | gsnedders, did you ever do header encoding tests with XHR? |
| 16:27 | <annevk> | gsnedders, the spec should be more explicit on the manner, but isn't currently |
| 16:40 | <annevk> | implementation code of this seems to be somewhat messy as well |
| 16:44 | <annevk> | I cannot even find where things are going from string to byte sequence |
| 16:44 | <annevk> | hack |
| 19:24 | <gsnedders> | annevk: no, I didn't get that far (I was always more concerned with the basic syntax, never got to semantics) |
| 19:25 | <gsnedders> | jgraham: k, it's just you having said all tests pass somewhere (in a bug?) |
| 19:25 | <gsnedders> | Hixie: heh. I didn't expect so much appreciation :) |
| 19:25 | <gsnedders> | Hixie: And you're engaged? congrats on taht |
| 19:25 | <gsnedders> | *that |
| 19:28 | <gsnedders> | Hixie: As for how do you use it, first thing to do is to wait for it to be finished, seeming I guess you want a TOC :) |
| 20:43 | <annevk> | gsnedders, too bad |
| 21:16 | <whiteinge> | Anyone familiar with an IRC channel more specifically focused on Canvas? |
| 22:41 | <foolip> | Would the WHATWG or public-iri@w3c be the best place to ask about IRI bis? |
| 22:58 | <annevk> | public-iri |
| 22:58 | <annevk> | what do you wanna ask foolip? |
| 23:03 | <foolip> | annevk: I want to ask if query string parsing should be a part of IRI bis, another IETF spec or maybe something else |
| 23:05 | <foolip> | IRI bis says "Specifications that define the syntax of any of the above components MAY divide them further and define smaller parts to be components according to this document." |
| 23:06 | <foolip> | I'm not really sure what exactly that means though |
| 23:07 | <foolip> | I've reverse engineered PHP, ASP (VBScript) and JSP a bit and they seem to work mostly in compatible ways, only interesting differences are in how they treat malformed %XX entities |
| 23:09 | <AryehGregor> | Doesn't Perl do some totally different thing involving semicolons? |
| 23:09 | <foolip> | AryehGregor: aha, might that be the source of the mysterious W3C suggestion that implementations handle both & and ; as a separator? |
| 23:10 | <AryehGregor> | I dunno, I just know that Perl apps tend to use semicolons where I'd expect ampersands. |
| 23:10 | <AryehGregor> | E.g.: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=6b7b284958d47b77d06745b36bc7f36dab769d9b |
| 23:10 | <foolip> | I know very little about Perl, is there even a standard module used for this kind of thing? |
| 23:11 | <AryehGregor> | Perl seems to have standard modules for everything. |
| 23:11 | <AryehGregor> | I don't do Perl either, though. |
| 23:11 | <foolip> | meh |
| 23:11 | <foolip> | sounds worthwhile investigating though |
| 23:17 | <Philip`> | foolip: The "CGI" module is the standard# |
| 23:17 | <Philip`> | s/#// |
| 23:18 | <Philip`> | The other standard is the regexps in whatever tutorials/examples people copy-and-paste argument-splitting code from |
| 23:18 | <foolip> | Philip`: learning about CGI feels like going back in time :) |
| 23:18 | <Philip`> | The other other standard is probably whatever mod_perl does |
| 23:19 | <Philip`> | foolip: Perl often uses the CGI module API even if the implementation is not actually based on CGI |
| 23:19 | <foolip> | Philip`: ok, thanks |
| 23:20 | <Philip`> | CGI.pm splits on /[&;]/ |
| 23:20 | <Philip`> | then it splits key/value on the first = |
| 23:20 | <Philip`> | (or puts everything in key if no value) |
| 23:21 | <Philip`> | (and sets value to "") |
| 23:21 | <Philip`> | then it unescapes key, and unescapes value |
| 23:21 | <foolip> | sounds like everyone else appart from the ; |
| 23:22 | <Philip`> | where unescape finds /%(?:([0-9a-fA-F]{2})|u([0-9a-fA-F]{4}))/ and decodes as hex |
| 23:22 | <annevk> | foolip, it seems you can parse it however you like |
| 23:22 | <annevk> | much like you can parse /foo/bar however you like on the server |
| 23:22 | <Philip`> | unless you're running on EBCDIC in which case it finds /%([0-9a-fA-F]{2})/ and decodes as ASCII hex |
| 23:23 | <AryehGregor> | :/ |
| 23:23 | <Philip`> | Oh, and unescape replaces '+' with ' ' before that |
| 23:23 | <foolip> | annevk: yes, but the problem is that the media fragments WG wants define something on top of something that looks like a query string |
| 23:24 | <annevk> | hmm |
| 23:24 | <foolip> | hmm, %u422A is actually a valid percent escape? |
| 23:24 | <foolip> | I've never seen that format actually |
| 23:24 | <annevk> | and they expect it to be processed client-side? |
| 23:25 | <AryehGregor> | Valid for Perl, I guess. |
| 23:25 | <foolip> | annevk: client side for #t=10 and server-side for ?t=10 |
| 23:25 | <annevk> | it seems to me they should stick to #syntax and define some kind of HTTP header |
| 23:25 | <AryehGregor> | Isn't there some standard for encoding GET form data in query strings? |
| 23:25 | <foolip> | there is |
| 23:25 | <foolip> | in HTML5 |
| 23:25 | <foolip> | but none for decoding |
| 23:25 | <AryehGregor> | Interesting. |
| 23:26 | <foolip> | that I have found anyway |
| 23:26 | <foolip> | #!/usr/bin/perl -w |
| 23:26 | <foolip> | print "Content-type: text/html\n\n"; |
| 23:26 | <foolip> | sorry :/ |
| 23:26 | <annevk> | it seems a very fragile approach to me |
| 23:26 | <AryehGregor> | If this is just for media fragments, can't you just require it to behave like HTML5 requires it gets output? Or is there some reason you want compatibility with major scripting languages? |
| 23:26 | <annevk> | how many implementors reviewed this? |
| 23:26 | annevk | can't really believe such a thing would get past basic review |
| 23:27 | <foolip> | the reason is that I'm meeting resistance when saying that the WG should define the processing requirements of this syntax, because presumably it belongs in another spec |
| 23:28 | <foolip> | annevk: I haven't seen any browser vendors apart from Opera (me) make significant noise since I joined |
| 23:28 | <annevk> | are they part of the group though? |
| 23:29 | <annevk> | I agree that some group should define processing requirements |
| 23:29 | <foolip> | I think some of the Apple guys are |
| 23:29 | <foolip> | annevk: UAs will of course just ignore the query string, but we need to know what to do for fragment URIs |
| 23:29 | <annevk> | if HTML5 keeps the definition of encoding it should also define how to decode imo |
| 23:29 | <foolip> | which part in particular do you think is fragile? |
| 23:30 | Hixie | looks in |
| 23:30 | <Hixie> | wassup |
| 23:30 | <annevk> | that one part is for the client and one part for the server |
| 23:30 | <annevk> | and that the server part might use names already in use |
| 23:30 | <foolip> | well HTML5 defines how to encode form data, what we are decoding isn't really form data, but I wouldn't mind if it's in HTML5 |
| 23:31 | <foolip> | annevk: it's not the intention that both be used at once, and in either case the server part is opaque to the client and vice versa |
| 23:32 | <foolip> | apparently the thinking is that in some cases doing the chopping on the server is faster, e.g. archive.org already implements this |
| 23:32 | <foolip> | annevk: what are "names already in use"? |
| 23:32 | <annevk> | what if I have a resource that's named /x?t=10 |
| 23:32 | <annevk> | (not sure if t is the right param name) |
| 23:32 | <foolip> | that's right |
| 23:33 | <annevk> | Hixie, discussing media fragments |
| 23:33 | <foolip> | annevk: well, I doubt anyone ever considered that |
| 23:33 | <annevk> | Hixie, oh, and whether HTML5 should define how to decode <form> GET URLs besides defining how to encode them |
| 23:34 | <foolip> | in my feedback I have pretended the query string part doesn't exist, because it is irrelevant to UAs |
| 23:34 | <annevk> | foolip, also, apart from maybe the fragment URIs are supposed to be opaque |
| 23:35 | <annevk> | the server assigns meaning to it for sure, but with this the client and server have some shared understanding of a part of the URI |
| 23:35 | <foolip> | annevk: I mean that the server doesn't get to see the fragment part |
| 23:35 | <annevk> | it feels somewhat wrong |
| 23:35 | <foolip> | there is no shared part |
| 23:35 | <annevk> | foolip, sure, the query part |
| 23:35 | <foolip> | the UA doesn't (shouldn't) care about that |
| 23:36 | <annevk> | the UA generates it and the server is expected to respond in a particular way |
| 23:36 | <annevk> | if the UA doesn't, how does the server ever get it? |
| 23:36 | <foolip> | no, the UA doesn't generate a query string |
| 23:36 | <foolip> | the UA can either be clever and seek to the right place with simple heuristics and range requests, or use the HTTP headers that the WG is defining |
| 23:37 | <annevk> | so why do we have the query string? |
| 23:37 | <annevk> | and who will be using it? |
| 23:37 | <foolip> | e.g. archive.org uses it, or something that looks like it |
| 23:38 | <foolip> | however, I would be happy if it wasn't in the spec at all |
| 23:38 | <annevk> | I'm not sure why it would need to be defined |
| 23:38 | <foolip> | presumably because it is convenient to use the same syntax for both, or something like that |
| 23:39 | <foolip> | and because server-side implementations actually exist |
| 23:39 | <Hixie> | why would we need to define how to decode the query component? What's the interoperability concern? |
| 23:39 | <AryehGregor> | But you don't need standards if it's done purely on the server side . . . |
| 23:39 | <Hixie> | Surely each URL can only be read by one server |
| 23:40 | <Hixie> | so there's nothing to interoperate with |
| 23:40 | <annevk> | I guess the idea is to standardize a common API for media resources |
| 23:40 | <foolip> | Hixie: I'm not really interested in decoding a query string, I'm interested in decoding a fragment component which uses the same syntax as a query string |
| 23:40 | <annevk> | but I'm not sure why that needs to be standardized... |
| 23:41 | <AryehGregor> | The fragment component decoding can be done on UAs, so that needs to be standardized. |
| 23:41 | <AryehGregor> | In fact, it has to be done on UAs. |
| 23:41 | <foolip> | AryehGregor: exactly |
| 23:41 | <Hixie> | well surely the fragment component decoding would be defined by the spec that defines the fragment? |
| 23:41 | <foolip> | Hixie: that's what I've been trying to argue for |
| 23:41 | <Hixie> | sounds good to me |
| 23:41 | <annevk> | Hixie, well, the idea would be to define how servers can get the data out of the URL |
| 23:42 | <foolip> | however, I've been a bit thrown off by the query string issue it seems |
| 23:42 | <annevk> | Hixie, if you define how that works presumably you can swap the software that gets data out of the URL |
| 23:42 | <AryehGregor> | Just define some subset of generally-used query string encoding. |
| 23:42 | <Hixie> | annevk: presumably that would be defined by the spec for that software |
| 23:42 | <Hixie> | annevk: different servers have different needs for how to parse query components |
| 23:43 | <annevk> | Hixie, it seems to me it's sort of an integral part of <form> submission |
| 23:43 | <Hixie> | e.g. http://example.com/?foo+bar vs http://example.com/?a=b&c=d vs http://example.com/a=b;c=d |
| 23:43 | <Hixie> | these are all valid query components |
| 23:43 | <Hixie> | but they need different parsing rules |
| 23:43 | <foolip> | it seems that one should do either (1) define how to parse a query string (probably in another spec) and reuse that definition for the fragment part in MF or (2) remove any mention of query strings from MF and just define how to parse the fragment component |
| 23:43 | <AryehGregor> | Hixie, I think you're missing a ? in the last. |
| 23:43 | <Hixie> | er yes |
| 23:44 | <AryehGregor> | foolip, (2) sounds more sensible. Just make up something simple. |
| 23:44 | <AryehGregor> | We don't define how to parse query strings for anything else, no reason to start for media fragments. |
| 23:45 | <foolip> | ok, I don't expect arguing this line is going to be easy though |
| 23:45 | <foolip> | I agree it makes the most sense however |
| 23:45 | <foolip> | will try writing an email suggesting as much tomorrow when my brain has slept |
| 23:48 | <foolip> | thanks all |