| 00:15 | <Hixie> | hober: ping https://www.w3.org/Bugs/Public/show_bug.cgi?id=25236 |
| 00:33 | <sangwhan> | Webkit/Blink is a mixture of LGPL and BSD |
| 00:34 | <SamB> | so it turns out I can't actually read DEP5 files very well; looks like LGPL-2+ / MPL-2.0+ would be a plausible license for the HTML spec that'd allow most browser implementors to paste pieces into their source? |
| 00:36 | <SamB> | s|;|; but looking at some relevant pages on wikipedia, <about:license> in FF 24, and <http://mozilla.org/MPL>;, it| |
| 00:57 | <Hixie> | SamB: MPL would be sufficient for w3c to keep forking, as far as i can tell |
| 01:01 | <tantek> | Hixie: re: "belief that w3c specs can't reference whatwg specs" - quite the opposite, I am an *advocate* for W3C specs referencing WHATWG specs. |
| 01:01 | <tantek> | not sure who/where you heard that belief from but it is laughable ;) |
| 01:01 | <Hixie> | oh ok, good |
| 01:02 | <tantek> | and like I said, I'm an advocate for editors of W3C specs to have the freedom to reference WHATWG specs as they see fit. |
| 01:02 | <tantek> | if you hear anything to the contrary, I appreciate the heads-up, as you did. |
| 01:03 | <Hixie> | roger |
| 01:04 | <tantek> | also if you hear from anyone that they are having difficulty doing so, I'm happy to help advocate for them inside W3C |
| 02:51 | SamB | isn't sure how he feels about the way http://dev.w3.org/fxtf/compositing-1/ keeps talking about HTML- or SVG-specific stuff; on the one hand it makes things easier to understand but on the other hand it seems kind of like stuff that should be in HTML or SVG specs ... |
| 03:04 | SamB | thinks you guys need to learn to spell times though |
| 03:05 | <SamB> | it's ×, not x |
| 03:05 | <SamB> | wow that renders bad in unifont though |
| 10:40 | <IZh> | Hi. |
| 20:45 | <MikeSmith> | is file:///abc|/foo/bar as valid URL per the rules for file URLs in the URL spec? |
| 20:46 | <MikeSmith> | is file:///9|/foo/bar a valid URL? |
| 20:46 | <MikeSmith> | and by valid I mean, does not cause a parse error |
| 20:48 | <MikeSmith> | and I mean the problem character being the bar character |
| 20:49 | <MikeSmith> | "|" |
| 20:51 | <MikeSmith> | which is not a "URL code point" so normally generates a parse error but is allowed if in file URLs under certain circumstances |
| 20:52 | <MikeSmith> | but I thought the only case where it was allowed was after a single ASCII alpha character |
| 20:52 | <MikeSmith> | and then only if that single ASCII alpha character is the first character after the scheme, with nothing else between |
| 21:07 | <IZh> | I don't know whether it is valid, but why don't use %xx for bar? |
| 21:22 | <MikeSmith> | IZh: because I'm writing test cases to check if an implementation treats stuff like "file:///abc|/foo/bar" as valid |
| 21:22 | <MikeSmith> | anyway I realize now that "|" seems be allowed in the host part |
| 21:25 | <MikeSmith> | ah oops I meant to say "file://abc|/foo/bar"; before |
| 21:27 | <MikeSmith> | anyway it seems what happens is that per the spec, "file://c|/foo/bar"; gets parsed as host=null path="/c:/foo/bar" |
| 21:28 | <MikeSmith> | whereas "file://abc|/foo/bar"; gets parsed as host="abc|" path="/foo/bar" |
| 22:07 | <MikeSmith> | Hixie: fwiw the w3c bugzilla instance was upgrade to v4.4.2 yesterday and I think there are some new search features |
| 22:07 | <MikeSmith> | http://www.bugzilla.org/releases/4.4.2/release-notes.html#v44_feat |
| 22:07 | <MikeSmith> | which may or may not be useful to you |
| 22:21 | <Hixie> | MikeSmith: cool, thanks for the heads-up |
| 22:36 | <annevk> | MikeSmith: file URLs might need some changes |
| 22:36 | <MikeSmith> | annevk: OK |
| 22:36 | <annevk> | Also, why we need the URL standard: https://bugzilla.mozilla.org/show_bug.cgi?id=241688 |
| 22:37 | <annevk> | Kind of sad really... |
| 22:37 | MikeSmith | looks |
| 22:40 | <MikeSmith> | gotta love backslashes |
| 22:41 | <MikeSmith> | annevk: btw I notice that the URL spec nowhere states what code points are allowed in domain labels |
| 22:42 | <annevk> | MikeSmith: yeah, I'm hoping UTS #46 will at some point provide guidance for that |
| 22:42 | <MikeSmith> | I assumed "|" wasn't allowed since it's not a URL code point but now I see the spec never says that only URL code points are allowed in domain labels |
| 22:42 | <annevk> | MikeSmith: not sure I successfully conveyed that to Mark though when I spoke to him |
| 22:43 | <MikeSmith> | OK |
| 22:43 | <annevk> | MikeSmith: he's fixing a bunch of other problems, might take another year to get syntax requirements sorted |
| 22:43 | <annevk> | MikeSmith: see http://www.unicode.org/reports/tr46/proposed.html for changes to ToASCII and ToUnicode that are being made, it's becoming much better |
| 22:44 | MikeSmith | looks |
| 22:49 | <MikeSmith> | annevk: OK is it worth me filing a bug against the URL spec about domain-label code points? As a reminder at least. Or should I not bother? |
| 22:49 | <MikeSmith> | or maybe you have a note in there already about it that I missed |
| 22:50 | <annevk> | MikeSmith: yeah you could file a bug |
| 22:50 | <MikeSmith> | k |
| 22:50 | <annevk> | MikeSmith: not sure how to fix it though :-) |
| 22:52 | <MikeSmith> | annevk: yeah I know. But at least if we file a bug it'll save the next somebody from filing a duplicate if they set out to report the same issue |
| 22:53 | <MikeSmith> | oh btw the w3c bugzilla now does the thing where it shows possible duplicates when you got to file a new bug |
| 22:53 | <MikeSmith> | based on the summary contents you type in |
| 22:53 | <MikeSmith> | or not really duplicates but existing bugs with a similar summary |
| 22:53 | <MikeSmith> | you know what I mean |
| 23:00 | <annevk> | nice |
| 23:01 | <MikeSmith> | annevk: maybe for the URL could at least give the list of characters that are definitely not allowed |
| 23:01 | <MikeSmith> | like "/" and "#" and "?" |
| 23:02 | <MikeSmith> | would it make any sense to do that? |
| 23:03 | <annevk> | I would prefer a more definitive definition |
| 23:03 | <annevk> | Do you need this intermediate hack for something? |
| 23:03 | <annevk> | I'm planning on reworking the parser a bit by the way to be more functional. Also allowing better reuse of parts of the parser |
| 23:04 | <MikeSmith> | annevk: no, don't need it for anything specific |
| 23:04 | <MikeSmith> | annevk: so it's not blocking anyting |
| 23:05 | <annevk> | MikeSmith: okay, then I think we should try to find something better |
| 23:05 | <MikeSmith> | yeah |
| 23:05 | <MikeSmith> | OK I'll just file the bug about it for now as a reminder |