| 00:02 | <jsbell> | Replying to crockford on jslint mailing list: not sure if helping, or feeding the troll |
| 00:03 | <WeirdAl> | jsbell: that needs a meme pic :) |
| 00:09 | <GPHemsley> | Regular user registrations are now turned back on. Additional anti-spam measures have been put in place. If anyone sees any problems, let me know. |
| 00:10 | <GPHemsley> | Also, if there are features/extensions that people think would be useful on the wiki, let me know about that, too. :) |
| 00:17 | <tantek> | GPHemsley - I'm upgrading the anti-spam measures on the microformats wiki and am curious what you chose to add to the WHATWG wiki. |
| 00:17 | <tantek> | (also MediaWiki obv) |
| 00:17 | <GPHemsley> | tantek: For now, I've only added the reCAPTCHA setting for ConfirmEdit and SimpleAntiSpam. |
| 00:18 | <tantek> | ok cool |
| 00:18 | <GPHemsley> | I'll wait and see if it's sufficient. |
| 00:18 | <GPHemsley> | I used Wikipedia's installation as an inspiration. |
| 00:18 | <GPHemsley> | They have a lot of extensions for blocking and whatnot. |
| 00:18 | <tantek> | yeah |
| 00:18 | <GPHemsley> | But not too many general purpose extensions. |
| 00:18 | <GPHemsley> | So we'll see if that's enough. |
| 00:21 | <yuhong> | Just wrote a more detailed explaination of the origiin of legacy color parsing: http://stackoverflow.com/questions/8318911/why-does-html-think-chucknorris-is-a-color/12630675#12630675 |
| 03:38 | <MikeSmith> | http://lists.w3.org/Archives/Public/uri/2012Oct/thread.html#msg3 |
| 03:38 | <MikeSmith> | for those who missed it |
| 03:39 | <MikeSmith> | (I didn't even know the uri⊙wo list existed) |
| 03:52 | <othermaciej> | MikeSmith: wow, that's a big thread |
| 03:52 | <MikeSmith> | yeah |
| 03:52 | <MikeSmith> | there's a lot of repetition in it though |
| 03:55 | <MikeSmith> | some actually profanity in there too |
| 03:55 | <MikeSmith> | so that's a plus |
| 04:24 | <zewt> | MikeSmith: randomly clicking giving me such fascinating snippets |
| 04:25 | <zewt> | This is why any references to fixing or aligning URI syntax with reality is besides the point and not neccessary." |
| 04:25 | <zewt> | " |
| 04:26 | <othermaciej> | zewt: that quote hurt my eyebrows |
| 04:26 | <MikeSmith> | zewt: yeah there's a few more gems like that |
| 04:32 | <zewt> | definitely fascinating that this discussion is carefully taking place on a list nobody in the world has ever heard of, instead of one where the silliness might actually be observed |
| 04:32 | <MikeSmith> | right |
| 04:32 | <zewt> | haha holy shit |
| 04:32 | <zewt> | > Why not define (or reuse) a separate term for the input stream, and |
| 04:32 | <zewt> | > leave "URL" alone? |
| 04:32 | <MikeSmith> | yeah been there |
| 04:32 | <zewt> | URI URL URX URO URQ yeah let's come up with another word! |
| 04:32 | <zewt> | they're all URLs, get over it |
| 04:33 | <othermaciej> | how about Link Online Locator |
| 04:33 | <zewt> | people saying "URI" in discussions where everyone else is saying "URL" makes me want to poke them--"really, dude?" |
| 04:33 | <MikeSmith> | "hypertext reference" |
| 04:33 | <othermaciej> | because I'd love to have an "LOL" class in WebKit |
| 04:33 | <othermaciej> | also, it seems really appropriate in this case |
| 04:34 | <MikeSmith> | snort |
| 04:34 | <zewt> | people who say "URI" are in my same brain-bucket as people who say "FOSS" |
| 04:34 | <zewt> | well, for people who say them without irony |
| 04:35 | <zewt> | also "KiB", etc |
| 04:35 | <othermaciej> | some people say URI just because they have been trained that way, saying "IRI" is the truly extreme level |
| 04:35 | <othermaciej> | because no normal person has the slightest clue what that is |
| 04:36 | <othermaciej> | technically, saying "scheme" instead of "protocol" to name that particular part of the *R* is also pendatic |
| 04:36 | <MikeSmith> | but it's fewer letters |
| 04:37 | <zewt> | i'll forgive scheme only because it's broadly used in APIs |
| 04:37 | <zewt> | but it's definitely an extra hop in mental processing for me vs. protocol |
| 04:37 | <MikeSmith> | anyway is there currently a formal definition of "URL" anywhere? last time I remember checking, it seemed the intent of the URI/IRI specs was to obsolete the term URL and replace it with those |
| 04:38 | <zewt> | specs don't "get" to obsolete terms, heh |
| 04:38 | <zewt> | that's sort of the overall point of the above :P |
| 04:38 | <zewt> | oh yeah. "ecmascript" |
| 04:39 | <MikeSmith> | well my point is that nobody can reasonably claim there's a current spec for the term "URL" that this conflicts with |
| 04:39 | <othermaciej> | MikeSmith: URLs are URIs that are not URNs |
| 04:39 | <othermaciej> | (I think) |
| 04:39 | <othermaciej> | (per current official IETF canon) |
| 04:40 | <MikeSmith> | ok |
| 04:40 | <zewt> | othermaciej: is that a tonguetwister? |
| 04:40 | <MikeSmith> | .me reads http://tools.ietf.org/html/rfc3986#section-1.1.3 |
| 04:41 | <zewt> | heh another good one: |
| 04:41 | <zewt> | Um, true... but it's also the case that the implementation community hasn't over the years been doing as much as might be best to make reality match the specifications. The new specs we're writing now would like have been a lot thinner and cleaner if they had. |
| 04:41 | <zewt> | "new at this, are you?" |
| 04:41 | <zewt> | (and the answer presumably being "no", which is the unfortunate part) |
| 04:45 | <othermaciej> | many standards people believe that browsers have power to change reality just by being more strict |
| 04:46 | <zewt> | well, in a way they do--but they're not going to, since there are stronger forces acting on them than specs |
| 04:48 | <zewt> | if not to the point of changing reality (heh) there are plenty of things they could do that they're just not going to--and one thing the HTML spec (etc) have done is ... getting over it |
| 05:04 | <MikeSmith> | can somebody remind me what's supposed to be the processing behavior for the semicolon-less named character references in the "Named character references" table? |
| 05:05 | <MikeSmith> | UAs are supposed to use the corresponding character even though the character reference lacks the semicolon? |
| 05:05 | <MikeSmith> | this does not seem to be clear in the current spec |
| 05:09 | <MikeSmith> | hmm yeah matjas test cases seems to indicate that's in fact what's supposed to happen |
| 05:09 | <MikeSmith> | http://mathias.html5.org/tests/html/named-character-references/ |
| 05:09 | <MikeSmith> | (if you look at the script in the source) |
| 05:09 | <MikeSmith> | bah anyway the spec doesn't make that clear |
| 05:11 | <MikeSmith> | I guess this is case where it's a document-conformance error but the UA still has to process it |
| 05:39 | <zewt> | seems clear (if complicated) from 12.2.4.69 |
| 05:54 | <MikeSmith> | zewt: yeah true after reading more |
| 05:56 | <zewt> | html is Will It Blend? for old browser bugs |
| 06:10 | <othermaciej> | MikeSmith: reading the thread I'm amused at Hixie's unabashed bomb-throwing |
| 06:11 | <MikeSmith> | othermaciej: I guess he reckons he's speaking truth to power |
| 06:12 | <MikeSmith> | or something |
| 06:12 | <MikeSmith> | I like the part where he kinda chides mnot for saying "fuck" |
| 06:14 | <othermaciej> | does curl enforce url/uri validity in its parameter or is tbray describing how he wishes it worked? |
| 06:15 | <MikeSmith> | it doesn't as far as I can tell from using it |
| 06:15 | <MikeSmith> | so I'm not sure what he's talking about |
| 06:15 | <MikeSmith> | he or somebody in that thread even says something about "I consider that a bug in curl" |
| 06:16 | <Hixie> | othermaciej: curl does one thing with bad urls in its command line and another with bad urls in HTTP redirect Location: headers |
| 06:16 | <othermaciej> | Hixie: it seems indisputably better for it to always do the same thing with bad urls and for that to be the same as what browsers do with them |
| 06:16 | <Hixie> | you would think |
| 06:17 | <othermaciej> | apparently the word "indisputably" does not mean what I think it means |
| 06:18 | hsivonen | wonders what the context is |
| 06:18 | <Hixie> | hsivonen: recent threads in uri⊙wo |
| 06:18 | <hsivonen> | Hixie: thanks |
| 06:18 | <Hixie> | othermaciej: what's funny is the one thing they seem to think _should_ be specced is the one thing i think we can never spec, namely, how to handle user input in the url bar |
| 06:19 | <Hixie> | hsivonen: (context being IETF being offended by Anne's intention to obsolete STD66) |
| 06:19 | <othermaciej> | Hixie: in practice we will probably have to figure out how to convert Anne's parsed output of a URL into a URI sufficiently valid for our network library to accept, whether he specs that bit or not |
| 06:19 | <othermaciej> | (so I hope he specs it) |
| 06:19 | <othermaciej> | Hixie: I |
| 06:19 | <Hixie> | othermaciej: i think in practice the right eventual solution is to just replace the URL handling in the network library |
| 06:20 | <othermaciej> | I'd love to see someone try to spec what happens when you type "foo bar" in the address field of the browser ui |
| 06:20 | <othermaciej> | Hixie: we might end up doing that long-term eventually |
| 06:20 | <zewt> | hell, I have no idea what's going to happen when I type anything in a "modern" browser |
| 06:21 | <othermaciej> | Hixie: even in that case we'd probably want to pass them a string, not a struct representing the parsed components, but it could be a resolved-but-unparsed string |
| 06:21 | <zewt> | (when I type "foo bar" in Chrome I'd expect it to search for "foo bar", but odds are it'll search for "foo bar underpants" or something instead) |
| 06:21 | <hsivonen> | that the term LEIRI even shows up in that discussion is part of the problem and shows that Anne’s spec is needed. |
| 06:22 | <SamB_MacG5> | othermaciej: obviously, it looks for a bookmark with a keyword of "foo", and ... |
| 06:22 | <SamB_MacG5> | ... and then extensions get a chance to mess with things, and ... |
| 06:22 | <zewt> | 3. profit |
| 06:23 | <SamB_MacG5> | ... and then your mom ... |
| 06:23 | <Hixie> | othermaciej: yeah, he defines canonicalisation, i believe. or will. |
| 06:23 | <Hixie> | othermaciej: we need it for DOM APIs anyway |
| 06:23 | <othermaciej> | I think what's needed is resolution against a base incorporating canonicalization |
| 06:23 | <Hixie> | right |
| 06:24 | <othermaciej> | (I guess it is fine if those are defined as separate steps, but we'll likely want to code it as one pass for efficiency) |
| 06:24 | <Hixie> | pretty sure anne's on the ball on this |
| 06:24 | <SamB_MacG5> | othermaciej: at first I was wondering why you'd want to resolve not to have such a thing ... |
| 06:24 | <othermaciej> | I do not doubt his acumen |
| 06:25 | <tantek> | WTF is LEIRI? |
| 06:25 | <Hixie> | dude |
| 06:25 | <Hixie> | take my advice |
| 06:25 | <Hixie> | and back away |
| 06:25 | <Hixie> | retract your qusetion |
| 06:25 | <Hixie> | you will regret it otherwise |
| 06:25 | <SamB_MacG5> | ouch |
| 06:25 | SamB_MacG5 | decides to stop wondering, too |
| 06:25 | Hixie | runs away, lest he get caught in the fallout |
| 06:25 | <tantek> | wow - this? http://www.w3.org/TR/leiri/ |
| 06:25 | SamB_MacG5 | does not open that |
| 06:26 | <othermaciej> | tantek: I got Google to give me that link, but that didn't really answer what it is or why it exists |
| 06:26 | <tantek> | Legacy extended IRIs for XML - isn't that twice redundant? |
| 06:26 | <SamB_MacG5> | and why "for XML"? |
| 06:26 | tantek | checks the publication date to make sure it is not --04-01 |
| 06:26 | <SamB_MacG5> | I don't think the W3 does those |
| 06:28 | <othermaciej> | Reading this url@ thread, I can't really tell if it's just an argument about terminology or a substantive disagreement |
| 06:29 | <Hixie> | othermaciej: it's a power struggle pretending to be a technical discussion |
| 06:29 | <tantek> | Legacy / XML |
| 06:29 | <tantek> | extended / XML |
| 06:29 | <Hixie> | with me in the peanut gallery trying to seriously explain things while resisting (some times better than other times) the urge to troll. |
| 06:30 | <tantek> | Hixie, that's what IRC is for |
| 06:30 | <Hixie> | yeah, that's why i didn't troll more than i did :-) |
| 06:30 | <tantek> | What restraint! |
| 06:31 | <Hixie> | :-P |
| 06:35 | <hsivonen> | why is Roy insisting on not calling the things you put in href URLs? |
| 06:35 | <Hixie> | if you figure out the answer to that, let me know |
| 06:41 | <othermaciej> | uh-oh, mnot said he thinks the httpbis wg has addressed all feedback to the satisfaction of those raising it |
| 06:42 | <Hixie> | that's a bit like how the htmlwg has addressed all formal objections to the satisfaction of those raising them :-P |
| 06:43 | <othermaciej> | I don't think the html wg believes it has addressed any formal objections at all (since technically it is the Director's job to do so) |
| 06:43 | <othermaciej> | anyway, I posted the one obvious httpbis counter-example I know of to the list |
| 06:43 | <othermaciej> | am curious to see outcome |
| 06:44 | <Hixie> | othermaciej: the chairs asked me if my objection was satisfied, i said nothing had changed, they said "if you don't act like a jerk we'll assume you're satisfied then" |
| 06:44 | <Hixie> | that's basically the same tactic the http group uses - say no until the person gives up |
| 06:45 | <othermaciej> | Hixie: I'm not sure I would characterize your behavior in that exchange as *not* acting like a jerk... |
| 06:45 | <annevk> | Roy's answer fascinated me the most; it seemed to say STD 66 did not define parsing at all, just the object you'd get eventually. |
| 06:45 | <Hixie> | othermaciej: fair point, but still |
| 06:45 | <annevk> | I do wonder though what that regular expression does there then... |
| 06:45 | <Hixie> | othermaciej: "if you don't act like even more of a jerk" maybe? :-) |
| 06:46 | <Hixie> | othermaciej: anyway, the strategy of "just keep adding hurdles until they give up" is one that has been used a lot in the htmlwg since 2007 |
| 06:47 | <othermaciej> | Hixie: I think Sam drew his conclusion from the fact that you said you didn't want to be involved in threads regarding the w3c process - the only way to satisfy that request is to *not* process the Formal Objection, since doing so would cause you to get further email about w3c process |
| 06:48 | <othermaciej> | Hixie: if that was not your intent then you should have given a straight answer to my simple yes-or-no question (which was not a trick question or a false dilemma or anything) |
| 06:48 | <Hixie> | othermaciej: i'm not saying i wanted the FO kept (i couldn't care less either way), my point was just that it wasn't addressed |
| 06:48 | <Hixie> | othermaciej: having me no longer care doesn't mean the spec got fixed :-) |
| 06:49 | <annevk> | Okay, MIME bugs can be filed against http://mimesniff.spec.whatwg.org/ now |
| 06:49 | <annevk> | thanks MikeSmith! |
| 06:49 | <Hixie> | oh hey, anne's back |
| 06:49 | MikeSmith | opens a third breakfast beer in celebration |
| 06:50 | <MikeSmith> | othermaciej: if you posted a message to uri@ it didn't go |
| 06:50 | <othermaciej> | MikeSmith: no, I posted to ietf-http-wg |
| 06:50 | <MikeSmith> | ah ok |
| 06:50 | <othermaciej> | replying to myself from 2.5 years ago |
| 06:50 | <othermaciej> | http://lists.w3.org/Archives/Public/ietf-http-wg/2012OctDec/0150.html |
| 06:51 | <MikeSmith> | that's the way to show em how to do it man |
| 06:51 | <annevk> | othermaciej: haha, good luck with that |
| 06:51 | <othermaciej> | annevk: well, either they will fix it or the bluff is called |
| 06:51 | <annevk> | although I have to say, some of my feedback has been addressed, but only after I complained several times and mnot put a little bit of a defence up for my feedback |
| 06:52 | <annevk> | e.g. they somewhat addressed some of the Redirect stuff http://wiki.whatwg.org/wiki/HTTP |
| 06:52 | <annevk> | they undefined content-location |
| 06:52 | <Hixie> | content-base? |
| 06:52 | <annevk> | Hixie: it's the base URL yeah, but it's named -location |
| 06:53 | <Hixie> | i thought there was another one called content-base |
| 06:53 | <Hixie> | when you say "undefined", you mean what exactly? |
| 06:53 | <Hixie> | not saying what it should do is hardly a solution... |
| 06:53 | <annevk> | The main problem with the IETF is that they do not test implementations. They just assume a bunch of things about how things are implemented. Julian being a recent exception |
| 06:54 | <annevk> | And then when you point that out they ask you to do all the hard work only for them to reject most of it or water down stuff. Not actually make a useful spec for implementors, despite what they claim. |
| 06:56 | <annevk> | That's another reason why I'm extremely skeptical of helping them out with the URL work. The odds of getting the specification I think is useful for implementors are so small. |
| 06:56 | <hsivonen> | hmm. someone on an IETF list was “puzzled” by calling UTF-16 a legacy encoding |
| 06:58 | <annevk> | heh, you'd wonder why they still insist on publishing in ASCII then! |
| 06:58 | <Hixie> | annevk: they aren't willing to do hard work, and to get the simplest things done you have to argue for hours and days and weeks. what's the point of even trying. |
| 06:58 | <Hixie> | annevk: we get better quality feedback and get things done a zillion times faster by doing it at the whatwg. |
| 06:59 | <Hixie> | anyway. bed time. nn. |
| 06:59 | <annevk> | othermaciej: my URL parsing algorithm does exactly what you want btw |
| 06:59 | <othermaciej> | annevk: winning |
| 06:59 | <annevk> | othermaciej: it parses, resolves, and canonicalizes in one go (with a little bit of reparsing for domains) |
| 07:00 | <annevk> | so I think it could be ultra fast, but I'm not the guy to implement it in C and find out :) |
| 07:01 | <annevk> | Hixie: that's exactly it; nn |
| 07:06 | <othermaciej> | annevk: is there a form of the algorithm that outputs a string suitable to give to a network library (as opposed to parsed components) or is there an implied "paste the components together in the proper way" step at the end? |
| 07:06 | <othermaciej> | (I think the latter way is ok) |
| 07:06 | <annevk> | othermaciej: my idea was to have a separate "serialize" thing, indeed |
| 07:07 | <annevk> | othermaciej: but yeah, it's basically putting the components in order |
| 07:20 | <annevk> | GPHemsley: http://wiki.whatwg.org/wiki/Special:RecentChanges lots of spam users almost immediately :/ |
| 07:22 | <tantek> | damn that sucks (the spam users) |
| 07:34 | <annevk> | yeah, that's why we disabled it back then |
| 07:34 | <annevk> | I'll wait for GPHemsley to come back, maybe he has some more tricks |
| 07:36 | <tantek> | spam pages deleted and creators of those pages blocked. I'll leave the other random accounts alone for now. |
| 07:38 | <annevk> | tantek++ |
| 08:24 | <zjhxmjl> | join centos |
| 08:24 | <zjhxmjl> | join #centos |
| 08:35 | <annevk> | okay, could not resist http://lists.w3.org/Archives/Public/uri/2012Oct/0037.html |
| 08:38 | <tantek> | well written annevk |
| 08:39 | <tantek> | I am shocked, shocked to hear that there is stop energy is going on in IETF mailing lists! |
| 08:40 | <tantek> | http://www.youtube.com/watch?v=SjbPi00k_ME |
| 08:56 | <othermaciej> | annevk: looks like I actually got satisfaction |
| 08:56 | <othermaciej> | or will anyway |
| 09:01 | <annevk> | scumbag IETF: does not solve your problems; complaints when you solve them yourself |
| 09:02 | <annevk> | s/ts/s/ |
| 09:06 | <othermaciej> | will the resolve+canonicalize+parse algorithm followed by serialize always result in a valid URI per the RFC? (or valid IRI?) |
| 09:06 | <othermaciej> | or will it sometimes result in something not-rfc-valid? |
| 09:07 | <othermaciej> | cause you might actually be sort of doing what at least mnot has asked for, other than terminology |
| 09:09 | <annevk> | othermaciej: no it's not always valid |
| 09:09 | <annevk> | othermaciej: see my email |
| 09:09 | <annevk> | othermaciej: e.g. http://www.w3.org/% is not valid yet is transmitted as such |
| 09:09 | <othermaciej> | if invalid stuff sometimes gets over the wire as such, and in particular if servers may depend on that behavior, then there is no sensible way to build on STD66 |
| 09:09 | <annevk> | agreed |
| 10:10 | <annevk> | why is there no custom scumbag meme generator? |
| 10:10 | <annevk> | I guess I'll do some work instead |
| 10:17 | <hsivonen> | annevk: do you have a list of encodings supported by each browser? |
| 10:18 | <annevk> | hsivonen: http://wiki.whatwg.org/wiki/Web_Encodings has historical data |
| 10:19 | <annevk> | hsivonen: it's not been updated |
| 10:19 | <annevk> | hsivonen: http://coq.no/character-tables/mime/en is pretty good too |
| 10:19 | <annevk> | hsivonen: (but not in list form) |
| 10:21 | <hsivonen> | annevk: thanks |
| 10:22 | <hsivonen> | ok. enough replying to Glenn Adams about unsupported encodings. Back to code. |
| 10:23 | <annevk> | hsivonen: fwiw, the \ and Yen thing is supported in fonts |
| 10:24 | <annevk> | hsivonen: it's not part of the encoding layer and does not affect parsers and such, but Japanese fonts are "corrupted" |
| 10:24 | <hsivonen> | yeah. very sad. |
| 10:26 | <hsivonen> | It seems that the Nordic countries have been much better at recovering from that kind of bogosity. Why not Japan and Korea? |
| 10:26 | <hsivonen> | maybe because for the Nordic countries, the bogosity wasn’t carried over to Mac and Windows but in the Yen/Won case, it was? |
| 10:26 | <hsivonen> | and after it infected Windows, it was too late |
| 11:26 | <annevk> | :( |
| 11:26 | <annevk> | Posting to that thread on uri is now becoming a major time sink |
| 11:27 | <hsivonen> | annevk: walk away |
| 11:42 | <dbaron> | hsivonen, what platforms had said bogosity for Nordic countries? |
| 11:48 | <SimonSapin> | hsivonen: has the situation improved with PNG gamma? http://hsivonen.iki.fi/png-gamma/ |
| 11:59 | <annevk> | hsivonen: yeah, the point-by-point sniping is doing nobody any favors |
| 11:59 | <annevk> | except fans of 386 |
| 12:00 | <hsivonen> | dbaron: I’m not really sure what platforms. I think some pre-Linux Unix boxes had it. |
| 12:01 | <hsivonen> | dbaron: I experienced it briefly in 1995–1996 with email and telnet |
| 12:01 | <hsivonen> | SimonSapin: I haven’t tested recently |
| 12:01 | <SimonSapin> | ok, thanks |
| 12:11 | <Ms2ger> | Ooh, LEIRI |
| 12:11 | <Ms2ger> | Hadn't seen that for a while |
| 12:19 | <jgraham> | And didn't that make you sad |
| 12:28 | <annevk> | FYI: I created @xhrstandard, @urlstandard, @encodings, and @thedomstandard |
| 12:28 | <annevk> | They tweet for commits |
| 12:45 | <annevk> | http://encoding.spec.whatwg.org/ has a fun variant of the WHATWG logo thanks to Robbert; loving it |
| 12:54 | <SimonSapin> | annevk: goes with this: http://www.geekwear.de/produkte/scheiss-encoding-shirt.html |
| 13:42 | <annevk> | heh |
| 13:44 | <GPHemsley> | Well, that didn't take long. |
| 13:47 | <GPHemsley> | I've shut them off again. |
| 13:47 | <GPHemsley> | Kinda worrying, though, that they can get through a CAPTCHA and an additional layer of prevention. |
| 14:10 | <annevk> | I wonder how wikipedia itself does it |
| 14:11 | <annevk> | GPHemsley: can't we use twitter or google or something as identify provider? |
| 14:11 | <GPHemsley> | Wikipedia has a much more complex system, with a lot of blocks and filters and whatnot. |
| 14:11 | annevk | keeps making that typo :/ |
| 14:11 | GPHemsley | too |
| 14:12 | <GPHemsley> | right now I'm strengthening user permissions |
| 14:12 | <GPHemsley> | it's possible the upgrade may have made things a little too free by default :) |
| 14:12 | <zewt> | annevk: aren't you happy you joined that discussion? heh (@uri[sic]) |
| 14:12 | <annevk> | what would be nice if on the recent changes page you can just mark a bunch of stuff as spam and then let the wiki sort it out |
| 14:13 | <annevk> | zewt: I was happy with my first email, not so happy with the point-by-point sniping that followed |
| 14:14 | <annevk> | zewt: prolly not gonna post more |
| 14:14 | <zewt> | annevk: that's usually where i try to go "okay if you say so I'm going back to work", but yeah, that's hard to do, heh |
| 14:18 | <annevk> | GPHemsley: Anolified MIME Sniffing btw |
| 14:27 | <GPHemsley> | annevk: K, thanks. |
| 14:37 | <annevk> | I started sketching the Writing URLs section: http://url.spec.whatwg.org/#writing |
| 14:37 | <annevk> | any thoughts on it are welcome; wondering whether this is the approach to go in |
| 14:42 | <GPHemsley> | Are there any non-sysop wiki users here who could test something for me? |
| 15:19 | <annevk> | where is Ms2ger? |
| 15:19 | <annevk> | I don't like the name he minted for the URL registry page |
| 15:19 | <jgraham> | Belgium |
| 15:19 | <annevk> | I think URLExtensions would be more in line with what we have thus far |
| 15:50 | <annevk> | GPHemsley: fwiw, in the right bottom of the wiki the MIT thingie still weird |
| 15:51 | <GPHemsley> | annevk: If you have an image for me to put there, I can set it. |
| 15:53 | <annevk> | GPHemsley: http://commons.wikimedia.org/wiki/File:License_icon-mit.svg maybe? |
| 15:53 | <annevk> | GPHemsley: or maybe just nothing at all? |
| 15:53 | <annevk> | GPHemsley: it's already mentioned in text too after all |
| 15:54 | <annevk> | GPHemsley: Privacy policy and disclaimer links are prolly also best removed as we don't have either |
| 15:54 | <annevk> | GPHemsley: and the About WHATWG Wiki page is useless too |
| 15:54 | <GPHemsley> | Well, these are all standard parts of the skin. |
| 15:56 | <GPHemsley> | Oh, it's looking for an 88x31 image for the license. |
| 16:00 | <GPHemsley> | annevk: How about now? ^_^ |
| 16:00 | <annevk> | cool |
| 16:16 | <GPHemsley> | annevk: Incidentally, I can put any link and 88x31 image there, so if you want to put something else there, that's cool too. |
| 16:17 | <GPHemsley> | annevk: Or maybe this would be better: http://commons.wikimedia.org/wiki/File:License_icon-mit-88x31.svg |
| 16:19 | <GPHemsley> | annevk: Try it now. |
| 16:36 | <annevk> | also nice :) |
| 16:51 | <annevk> | GPHemsley: okay, added the disclaimer, no idea what to do with the privacy policy |
| 16:53 | <GPHemsley> | "To remove the Privacy policy or Disclaimers links at the bottom of each page, set the content of pages MediaWiki:Privacy or MediaWiki:Disclaimers respectively to a single hyphen (-)." |
| 16:54 | <[tm]> | the IETF is a business model |
| 16:54 | <annevk> | doesn't work for MediaWiki:About :/ |
| 16:57 | <GPHemsley> | annevk: Actually, for us, the prefix is 'WHATWG Wiki' |
| 16:58 | <annevk> | GPHemsley: works if I use MediaWiki |
| 16:58 | <GPHemsley> | yeah, IDK, weird things going on |
| 16:58 | <annevk> | ... |
| 16:59 | <annevk> | cannot remove it either by changing WHATWG Wiki:About to - |
| 16:59 | <annevk> | so I guess we'll keep it |
| 17:00 | <GPHemsley> | That's no big deal |
| 17:00 | <GPHemsley> | It's nice to have an about page |
| 17:03 | <annevk> | if you say so :) I added some text to make it more interesting |
| 17:03 | <GPHemsley> | hmm |
| 17:03 | <GPHemsley> | Apparently I was wrong |
| 17:04 | <GPHemsley> | the MediaWiki pages are the ones that disable the links |
| 17:04 | <GPHemsley> | but the WHATWG Wiki pages still exist |
| 17:04 | <annevk> | so we should remove those? |
| 17:05 | <annevk> | oh you clean it up now ;) |
| 17:06 | <GPHemsley> | :) |
| 17:06 | GPHemsley | made a mess all over the wiki. |
| 17:06 | <GPHemsley> | but I think it's fixed now |
| 17:07 | <shakesoda> | is anyone aware of any pen pressure APIs being proposed? (and is this even the right place to ask?) |
| 17:07 | <shakesoda> | I'm slightly surprised that the only way to get pen pressure in browsers appears to be wacom's plugin, which I can't use (linux) |
| 17:10 | <annevk> | it sounds like https://dvcs.w3.org/hg/gamepad/raw-file/tip/gamepad.html should address that somehow |
| 17:10 | <annevk> | but maybe not |
| 17:21 | <shakesoda> | looks like a suitable interface to me, would just need a sane (consistent) mapping of the axes. |
| 17:22 | <shakesoda> | e.g. axes[0] => pressure, axes[1] => tilt, axes[2] => rotation |
| 18:51 | <annevk> | I don't understand http://lists.w3.org/Archives/Public/uri/2012Oct/0053.html |
| 18:51 | <annevk> | I thought the IETF does not use the term URL anymore? |
| 18:52 | <annevk> | Ah, it has a non-normative note on them here: http://tools.ietf.org/html/rfc3986#section-1.1.3 |
| 18:56 | <tantek> | annevk - it's an interesting message from the perspective of a group telling an individual "why don't you come do the work in our group?" |
| 18:56 | <tantek> | WHATWG has had the same problem, telling individuals to come do the work at WHATWG |
| 18:56 | <tantek> | so it can happen to any group |
| 18:57 | <annevk> | what I think we told those people was that if you don't have actual implementors on board, you're gonna have a bad time |
| 18:57 | <tantek> | indeed |
| 18:57 | <tantek> | it's ironic since the motto of IETF is something like rough consensus and *running code* (emphasis added) |
| 18:58 | <annevk> | WHATWG is a great place to go for implementor feedback, as long as we manage to keep the signal/noise ratio somewhat sane |
| 18:58 | <tantek> | how did that latter part get lost? |
| 18:58 | <annevk> | running code, as long as it's within silos we work on? |
| 18:59 | <annevk> | (not entirely fair to jreschke, who hacks on Gecko now and then) |
| 18:59 | <tantek> | WHATWG *is* a great place to go for implementor feedback. That I agree with. I think the majority of actual bad friction (at/with WHATWG) has been when it involves innovating/designing for author-centric technologies - like all the responsive image stuff. |
| 18:59 | <annevk> | biab |
| 18:59 | <tantek> | but even there the results are decent to a first approximation, so, carry-on as they say. |
| 18:59 | <tantek> | re: the running code being lost |
| 19:00 | <tantek> | perhaps that's a pattern in the growth/expansion of any standards community/group? |
| 19:01 | <tantek> | they start out as primarily (or only?) implementors, then more and more others get involved, until the non-implementors vastly outnumber the implementors, and mistake their email participation in the group for actual productivity. |
| 19:01 | <tantek> | similar thing obviously happened at W3C. |
| 19:02 | <tantek> | theb non-implementors start to write "wish list" specs completely detached from implementability and wonder why no one is paying attention to them. |
| 19:02 | <tantek> | s/theb/then |
| 19:06 | <GPHemsley> | FYI: I've add a few extensions (and a bunch of gadgets) to the wiki. Check the list out here: http://wiki.whatwg.org/wiki/Special:Version |
| 19:06 | <GPHemsley> | Most of the gadgets are turned on by default, but there are a few that aren't (and you are welcome to turn the others off for yourself). |
| 19:07 | <GPHemsley> | If there's a gadget you want installed, let me know. |
| 19:09 | <tantek> | GPHemsley - we've found the SemanticHTML extensions quite handy on the #microformats wiki: https://github.com/BenWard/mediawiki-semantic-html |
| 19:09 | <annevk> | tantek: yeah, there's some bridge to be crossed between the jQuery people and where browsers are still at |
| 19:10 | <tantek> | BTW that's a nice list http://wiki.whatwg.org/wiki/Special:Version - will likely crib some of that for #microformats as well |
| 19:10 | <annevk> | tantek: I haven't really thought much about it, other than whenever I design a new API ask a bunch of them explicitly for feedback (or for the entire design of the API) |
| 19:10 | <annevk> | tantek: but most of my work is on upgrading fifteen-year-old standards |
| 19:11 | <tantek> | GPHemsley - this one too for code examples: http://www.mediawiki.org/wiki/Extension:SyntaxHighlight_GeSHi |
| 19:11 | <tantek> | annevk - WHATWG methodology seems quite good (produces good results) at upgrading/fixing old standards, that's for sure. |
| 19:12 | <annevk> | GPHemsley: sounds interesting |
| 19:16 | <Ms2ger> | annevk, I minted something? |
| 19:16 | <annevk> | Ms2ger: http://wiki.whatwg.org/wiki/Registry-URL-schemes |
| 19:17 | <Ms2ger> | Huh, I did do that |
| 19:19 | <Ms2ger> | No longer needed, I gues |
| 19:19 | <Ms2ger> | s |
| 19:19 | <annevk> | actually it is |
| 19:19 | <annevk> | unless we defer to IANA |
| 19:20 | <annevk> | conformance is going to be scheme-dependent |
| 19:20 | <Ms2ger> | Mm, and I guess you don't want all that in url.s.w.o |
| 19:22 | <annevk> | a) there's conformance rules; what syntax coms after tel:/fax:/skype:/data:/javascript:/ws:/... b) there's processing rules; after parsing the URL various schemes need post-processing |
| 19:23 | <annevk> | e.g. you can parse "tel:data" and then you'll want to process "data" and prolly mark that as an invalid resource |
| 19:24 | <annevk> | now given the enormous amount of URL schemes, I think not all of those should be in url.spec.whatwg.org |
| 19:24 | <annevk> | though I might include e.g. javascript: to illustrate how it works |
| 19:25 | <annevk> | MikeSmith: gonna need your thoughts on the above too at some point ^^ |
| 19:25 | <annevk> | MikeSmith: might be a lot of work to support URL validation |
| 19:29 | <GPHemsley> | tantek: OK, I've added both of those. |
| 19:29 | <GPHemsley> | (Syntax highlighting defaults to HTML5.) |
| 19:35 | <annevk> | guess I can't ++ GPHemsley more for fear of integer overflow |
| 19:35 | <GPHemsley> | :) |
| 19:42 | <tantek> | GPHemsley thanks! |
| 19:42 | <tantek> | GPHemsley++ |
| 19:46 | GPHemsley | feels like a slot machine. *cha-ching* |
| 19:52 | <annevk> | found a bug in Nightly |
| 19:52 | <annevk> | file:/// shows "Index of file:///" |
| 19:52 | <annevk> | (rather than "Index of file:/") |
| 19:59 | <hober> | Hixie: out of curiosity, what does <!--DEFER foo--> do in your toolchain? |
| 20:05 | <jgraham> | hober: Is that stuff that has been removed from the spec but hixie wants to keep around in case we ever decide to resurrect the idea? |
| 20:05 | <hober> | jgraham: i dunno; it only appears once in source |
| 20:06 | <hober> | <!--DEFER snapshot complete-->, line 32 |
| 20:09 | <Ms2ger> | You're trying to figure out something about his toolchain? |
| 20:09 | <Ms2ger> | Good luck :) |
| 20:10 | <hober> | heh |
| 20:12 | <jgraham> | hober: Oh, well my theory makes no sense in context. Maybe I just invented the idea that there was something like that |
| 20:16 | <annevk> | there is, he just uses comments like the rest of us for that ;) |
| 20:16 | GPHemsley | wonders if there's any chance the W3C Bugzilla instance will install the Component Watching extension |
| 20:16 | <annevk> | GPHemsley: sysreq⊙wo iirc |
| 20:16 | <annevk> | GPHemsley: maybe cc MikeSmith for superior lobbying powers |
| 20:16 | <TabAtkins> | Damn, annevk beat me. |
| 20:17 | <GPHemsley> | MikeSmith: ^^ |
| 20:17 | <GPHemsley> | ;) |
| 20:17 | <Ms2ger> | GPHemsley, is that an extension or just a new feature? |
| 20:17 | <Ms2ger> | The W3C bugzilla is ages out of date |
| 20:17 | <GPHemsley> | It's an extension, AFAIK. |
| 20:17 | <GPHemsley> | Though it would ideally be an integrated feature. |
| 20:17 | <GPHemsley> | BMO has it installed. |
| 20:26 | GPHemsley | thinks the W3C depends on e-mail too much. |
| 20:26 | <GPHemsley> | (Maybe if they used Bugzilla more, it'd be up to date.) |
| 20:26 | <Ms2ger> | E-mail is a support forum |
| 20:26 | Ms2ger | runs |
| 20:26 | GPHemsley | doesn't bother running after Ms2ger. |
| 20:29 | <annevk> | too bad a private repo costs money |
| 20:30 | <annevk> | would be nice to store twitter account details and such somewhere where more people had access to them |
| 20:30 | <annevk> | does WikiMedia have some concept of private pages? |
| 20:31 | <annevk> | though I guess we'd want to run the thing over https in that case |
| 20:31 | <annevk> | meh |
| 20:31 | <Ms2ger> | I don't think so |
| 20:31 | <GPHemsley> | hmm |
| 20:31 | <GPHemsley> | let me look |
| 20:32 | <GPHemsley> | "If you need per-page or partial page access restrictions, you are advised to install an appropriate content management package. MediaWiki was not written to provide per-page access restrictions, and almost all hacks or patches promising to add them will likely have flaws somewhere, which could lead to exposure of confidential data. We are not responsible for anything being leaked, leading to loss of funds or one's job." |
| 20:34 | <GPHemsley> | BTW, who has access to the web server interface? AryehGregor? Because PHP is really out of date. (I couldn't even find PHP5 on the command line, and I don't know how the command line differs from what is run on the server.) |
| 20:34 | <annevk> | GPHemsley: what is the PHP version? |
| 20:34 | <GPHemsley> | Also, the connection seems to time out in a way that prevents me from accessing the cursor. |
| 20:34 | <GPHemsley> | so I can't even Ctrl-C to kill it |
| 20:35 | <GPHemsley> | annevk: in the command line? PHP 4 something |
| 20:35 | <annevk> | GPHemsley: Hixie has the ability to change those settings |
| 20:35 | <GPHemsley> | though the wiki is somehow run by 5.2.17 or so |
| 20:35 | <annevk> | okay, that sounds like the latest version DreamHost runs |
| 20:35 | <annevk> | not sure about the command line option |
| 20:35 | <GPHemsley> | There are some scripts that are better run via command line that I couldn't run, because I couldn't find PHP5 |
| 20:36 | <annevk> | GPHemsley: PHP by default runs over CGI in DreamHost |
| 20:36 | <annevk> | GPHemsley: Hixie can enable mod_php I think as he has DreamHost PS, but I'm not sure if he's done that |
| 20:36 | <annevk> | dunno much about PHP on the command line |
| 20:37 | <annevk> | GPHemsley: https://discussion.dreamhost.com/thread-90033.html |
| 20:37 | <annevk> | GPHemsley: http://wiki.dreamhost.com/PHP#PHP-CLI_.28Using_PHP_from_the_Command_line.29 |
| 20:38 | <GPHemsley> | AFAICT, DreamHost also offers the option to use 5.3.x |
| 20:38 | <annevk> | correct, but the default is 5.2.x |
| 20:39 | <GPHemsley> | ah, I see |
| 20:39 | <GPHemsley> | weird |
| 20:39 | <GPHemsley> | is there a reason not to switch to 5.3.x? |
| 20:40 | <annevk> | I think you want to make the case the other way around, as it's some work for Hixie and potential breakage |
| 20:40 | <GPHemsley> | well, it's merely a flip of a drop-down |
| 20:41 | <GPHemsley> | and it seems that it can be set on a per-subdomain basis |
| 20:41 | <GPHemsley> | and AFAIK, only the wiki is run on this particular subdomain |
| 20:42 | <annevk> | all true |
| 20:43 | <GPHemsley> | and PHP 5.2.x is no longer maintained |
| 20:43 | <GPHemsley> | which is more a judgement on DreamHost than the WHATWG, but... |
| 20:43 | <annevk> | I guess my point is more that if there's nothing in 5.3 we need, we might as well wait for DreamHost to make the switch |
| 20:44 | <GPHemsley> | Well unmaintained potentially means insecure |
| 20:44 | <GPHemsley> | but again, that's on DreamHost |
| 20:45 | <GPHemsley> | so, ok |
| 20:45 | <GPHemsley> | it all depends on how the MediaWiki development goes, and whether we update it |
| 20:46 | <GPHemsley> | because I think we're at the bare minimum PHP version right now |
| 20:46 | <GPHemsley> | I'm surprised DreamHost hasn't spun up any 5.4.x options, though |
| 20:46 | <GPHemsley> | they're already at 5.4.7 |
| 20:47 | <GPHemsley> | though I suppose 5.4.0 was only released in March |
| 20:48 | <Hixie> | ok the logo for encoding.spec.whatwg.org is pretty damn funny |
| 20:48 | <Hixie> | hober: something about making one of the keywords work like an alias for the other, or something |
| 20:49 | <Hixie> | hober: i don't think it is used for any of the keywords you guys use |
| 20:55 | <hober> | ahh, ok. just curious, thanks |
| 20:56 | <hober> | annevk Hixie: yeah, the encoding logo is perfect |
| 20:59 | <Hixie> | annevk: please don't fall into the trap the XML guys fell into -- "valid URL" is a fine thing to define, but "URL" shouldn't be only things that are valid |
| 20:59 | <Hixie> | otherwise it gets really confusing and you have people saying "oh that's not a url" when you point them to invalid values of href="" attributes |
| 21:00 | <Ms2ger> | Hixie, well, that href value sure ain't XML... |
| 21:00 | <Hixie> | the equivalent in XML world is people saying "that's not XML" about resources sent as application/xml |
| 21:01 | <annevk> | Hixie: I guess that's fair |
| 21:01 | <annevk> | Hixie: but do we then also need valid relative URL etc. |
| 21:01 | <Hixie> | hey, tim thinks you guys are my "tribe" |
| 21:02 | <Hixie> | not sure what that means, but it's something |
| 21:02 | <annevk> | I thought we were a gang, with the gang sign and all |
| 21:02 | <annevk> | or a caball? |
| 21:02 | <annevk> | s/ll/l/ |
| 21:02 | <Hixie> | i always thought the gang sign thing was silly, personally :-P |
| 21:03 | <annevk> | well it's a gang sign :) |
| 21:04 | <annevk> | so in http://url.spec.whatwg.org/#writing should I have "A URL is a string that might identify a resource. A *valid URL* identifies a resource and is either a relative URL or an absolute URL." |
| 21:04 | <annevk> | Hixie: ^^ |
| 21:05 | <Hixie> | a valid URL might not identify a resource |
| 21:05 | <Hixie> | e.g. a relative URL without a base URL is valid, as is a urn: URL. |
| 21:06 | <annevk> | my definition of valid URL was going to be more restricted |
| 21:06 | <Hixie> | "A URL is a string that might identify a resource. A *valid URL* absolute URL." |
| 21:06 | <Hixie> | er |
| 21:06 | <Hixie> | mispaste |
| 21:06 | <Hixie> | you don't want urn:s to be valid? o_O |
| 21:07 | <Hixie> | if you define "valid URL" as something that "identifies a resource" you're going to have to define "resource" |
| 21:07 | <Hixie> | i don't recommend that rat hole |
| 21:07 | <Hixie> | it's not scenic |
| 21:07 | <Ms2ger> | 'The term "resource" is defined in HTML.' |
| 21:07 | <annevk> | I think I copied that bit from HTML actually |
| 21:07 | <Hixie> | (also, I wouldn't define valid URL as "either a relative URL or an absolute URL", I'd define it as "either a valid relative URL or a valid absolute URL" :-) |
| 21:08 | <Hixie> | HTML says "A URL is a string used to identify a resource. |
| 21:08 | <Hixie> | A URL is a valid URL if at least one of the following conditions holds: |
| 21:08 | <Hixie> | * [four links to STD 66]" |
| 21:08 | <annevk> | What I meant was that I wanted to outlaw "../" if the base URL is e.g. "about:blank" |
| 21:09 | <Hixie> | (and the term "resource" in HTML doesn't include things like mailto: targets, it's only things that could be HTTP bodies) |
| 21:09 | <Hixie> | annevk: that makes sense, i guess |
| 21:09 | <annevk> | Hixie: so you don't include "mailto:x@x" in your definition of URL?! |
| 21:09 | <Hixie> | i don't include "resource" in my definition of URL |
| 21:09 | <Hixie> | at least, not in a normative way |
| 21:10 | <Hixie> | "used to identify a resource" is fluff in that definition above |
| 21:10 | <annevk> | I think it's the same in mine |
| 21:10 | <annevk> | but do you really want the spec to both define "valid relative URL" and "relative URL" ? |
| 21:11 | <annevk> | Hixie: the way HTML defines documents also excludes invalid documents |
| 21:11 | <annevk> | Hixie: in http://www.whatwg.org/specs/web-apps/current-work/multipage/syntax.html#writing |
| 21:12 | <Hixie> | i dunno that it's useful to define "relative URL" really, no. I'm just worried people will say "that's not a relative URL!" when pointing at "%", and miss the point that it's a URL anyway. |
| 21:12 | <Hixie> | that section doesn't define documents |
| 21:12 | <Hixie> | it defines conformance criteria for documents |
| 21:13 | <Hixie> | that is, it doesn't say "documents are", it says "documents must" |
| 21:13 | <annevk> | right, this is conformance criteria for URLs |
| 21:13 | <Hixie> | well it's fine to say "URLs must ..." |
| 21:13 | <Hixie> | jsut not "URLs are [something that doesn't include all strigns]" |
| 21:13 | <Hixie> | woo, typos galore |
| 21:14 | <annevk> | okay, so I'll replace some are with must there |
| 21:14 | <annevk> | I guess I'm there if I say "a URL must be either a relative URL or an absolute URL" |
| 21:14 | <annevk> | because the rest is then required by virtue of that being required |
| 21:15 | <Hixie> | yes, that's fine |
| 21:15 | <Hixie> | though it would be convenient for HTML's sake if you just defined "URL" and "valid URL" instead. :-P |
| 21:15 | <Hixie> | but i'll live either way |
| 21:16 | annevk | takes a look at usage in HTML |
| 21:16 | <annevk> | ooh, only 218 hits |
| 21:18 | <annevk> | Hixie: I can define those non-empty URL / URL with spaces concepts for you without the word valid ;) |
| 21:19 | <Hixie> | my concern isn't those, it's more with being able to talk about things that are URLs without having people say "well it's not valid so it doesn't apply" |
| 21:20 | <Hixie> | the concern is greater with the concept of URLs because of the people who historically have worked with URLs |
| 21:20 | <annevk> | well, does HTML say the document "<x>" is HTML? |
| 21:21 | <Hixie> | whether something is HTML or not depends on how it's labeled |
| 21:21 | <Hixie> | per the spec |
| 21:21 | <Hixie> | and not on whether it's valid |
| 21:21 | <TabAtkins> | Every possible sequence of bytes is HTML if it's labelled correctly. |
| 21:22 | <Hixie> | right |
| 21:22 | <Hixie> | including no bytes |
| 21:22 | <annevk> | I think we should have the same for URLs |
| 21:22 | <Hixie> | i agree |
| 21:22 | <TabAtkins> | Yeah. Similarly, anything inside of @href is a URL, though maybe not a valid one. |
| 21:22 | <Hixie> | right |
| 21:22 | <Hixie> | the difference is that URLs tend not to be explicitly labeled the way documents are |
| 21:23 | <annevk> | The "Writing" section just defines URL conformance |
| 21:23 | <annevk> | well, how to write URLs |
| 21:23 | <jgraham> | Obviously they need a mime type! |
| 21:23 | <annevk> | jgraham: there's text/uri-list or some such... |
| 21:23 | <jgraham> | <a href="foo" type="text/url"> |
| 21:24 | <jgraham> | Then we could replace srcdoc with <iframe src="<p>foo" type="text/html"> |
| 21:24 | <jgraham> | And then we could replace all tags with <object> |
| 21:24 | <jgraham> | Then our work would be done |
| 21:24 | <annevk> | Hixie: maybe I need to move "A URL is a string to identify a resource" out of the writing section? |
| 21:27 | Ms2ger | tries to figure out what annevk did to the anolis repo |
| 21:28 | <annevk> | Hixie: a) I want to define conformance for URLs so validators can give useful messages to developers and we can maybe tie the parser into it somehow for people who want strict parsing (similar to HTML) b) I don't want to end up defining every term related to URL twice, once restricted and once unrestricted |
| 21:30 | <Hixie> | annevk: yeah! that sounds like a good plan (moving the definition of URL away from its authoring conformance criteria) |
| 21:30 | <Hixie> | annevk: agreed entirely with not defining things twice. |
| 21:30 | <Hixie> | annevk: different section should be enough |
| 21:33 | <Hixie> | annevk: ok i suggested replacing STD 66 with your spec once you're done, we'll see how that goes |
| 21:35 | <annevk> | oh that thread :) |
| 21:38 | <Hixie> | hm, no heycam |
| 21:43 | <Ms2ger> | Gone until the fifth, it seems |
| 21:53 | <TabAtkins> | Le sigh. People questioned the need for a state-machine parser for CSS. The grammar is enough to get convergence, they said. LIES. |
| 21:54 | <TabAtkins> | Every single browser does a different, uniquely stupid, thing with NULLs in stylesheets, with the treatment varying randomly depending on exactly where the NULL shows up. |
| 21:56 | <Ms2ger> | TabAtkins, and CSS isn't even at the IETF |
| 21:56 | <TabAtkins> | However, we do have Bert. That's almost as good. |
| 21:56 | <annevk> | heh |
| 21:57 | <Ms2ger> | And other Glenn! |
| 21:57 | <TabAtkins> | He's randomly okay. I dunno. |
| 21:57 | <annevk> | is there any grammar-based technology that is considered okay? |
| 21:57 | <annevk> | (parser being defined by grammar) |
| 21:58 | <TabAtkins> | As a first pass, man, I doubt it. |
| 21:58 | <Ms2ger> | JSON? |
| 21:58 | <TabAtkins> | Grammars are great *after* you've handled segmentation and error-handling. |
| 21:58 | <annevk> | Ms2ger: yeah, JSON and maybe JavaScript |
| 21:58 | <Ms2ger> | As long as you can just ignore anything that doesn't match your grammar, I guess it's fine |
| 21:58 | <TabAtkins> | Ms2ger: One would think so, except JSON accidentally included *one* character that valid JS can't have. |
| 21:59 | <annevk> | and forgot comments |
| 21:59 | <Ms2ger> | TabAtkins, can't really blame that on the grammar, though |
| 21:59 | <Ms2ger> | Well, comments weren't forgotten, but excluded deliberately to avoid extensions, AIUI |
| 21:59 | <TabAtkins> | Yes, it was deliberate, per Crock. |
| 22:00 | <Hixie> | defining parsing with a grammar makes sense so long as your grammar matches all input strings |
| 22:00 | <annevk> | i know i know |
| 22:00 | <Hixie> | but that's not easy |
| 22:00 | <Hixie> | (but then it's not trivial with prose or dedicated code, either) |
| 22:00 | <TabAtkins> | Total grammars are both hard to write and hard to read. |
| 22:00 | <Hixie> | iirc the event source parser might be defined that way? |
| 22:00 | <Hixie> | i forget |
| 22:01 | <annevk> | so Bert doesn't like css3-syntax? |
| 22:01 | Hixie | looks |
| 22:01 | <Ms2ger> | Getting everything defined is hard |
| 22:01 | <Ms2ger> | News at 11 |
| 22:01 | <annevk> | Hixie: I think it was defined that way |
| 22:01 | <Hixie> | ah, no, its conformance criteria are defined that way but the parsing is separate |
| 22:01 | <Hixie> | oh well |
| 22:01 | <TabAtkins> | annevk: He does not. But we don't have to care - the WG has gotten comfortable with overriding Bert with quick straw polls when necessary. |
| 22:02 | <annevk> | I'd assume most implementors prefer parsing being written out |
| 22:02 | <Hixie> | i'd assume most implementors would prefer the parsing being written as a grammar, if it works |
| 22:02 | <annevk> | can make much faster parsers that way too |
| 22:02 | <Hixie> | since then they can just copy and paste |
| 22:02 | <Hixie> | but if it doesn't work... yeah |
| 22:02 | <TabAtkins> | dbaron seems somewhat reluctant, strangely. But I think his reluctance is mostly a matter of wanting to ensure I don't introduce errors. |
| 22:06 | <annevk> | regression tests should help with that; but yeah, that's the risk with defining anything that already exists in a new way |
| 22:12 | <GPHemsley> | ICYMI: http://wiki.curatecamp.org/index.php/CURATEcamp_24_hour_worldwide_file_id_hackathon_Nov_16_2012 |
| 22:12 | <GPHemsley> | It seems like there should be some overlap of goals/effort with that project and the efforts of the WHATWG. |
| 22:14 | <annevk> | TabAtkins: any plans on defining the layout tree? |
| 22:14 | <hober> | or hit testing :) |
| 22:15 | <annevk> | if only the WG had given Leif free roam |
| 22:16 | <TabAtkins> | annevk: Yes, I plan to write the box tree spec at some point. |
| 22:16 | <TabAtkins> | Getting closer to it, now that I've written the first draft of Display, assuming the WG accepts the draft. |
| 22:17 | <TabAtkins> | Shit's impossible to do cleanly with the existing 'display' property. |
| 22:17 | <annevk> | i like |
| 22:18 | <TabAtkins> | This is cool - my wife and I did a playtest of a *very* early version of the new game Fuse. |
| 22:35 | <GPHemsley> | How does Web Storage related to Web (SQL) Database? |
| 22:36 | <GPHemsley> | -d |
| 22:37 | <GPHemsley> | Hixie: ^^ |
| 22:38 | <TabAtkins> | It doesn't. |
| 22:38 | <Hixie> | they were both part of HTML, but beyond that, it doesn't |
| 22:40 | <GPHemsley> | Hixie: It seems like Web (SQL) Database was removed in steps? |
| 22:41 | <Hixie> | it was commented out, then deleted, probably |
| 22:58 | <GPHemsley> | Hixie: I need an intermediary blame. How could I get that? |
| 22:58 | <GPHemsley> | (between 5000 and 4000) |
| 22:59 | <GPHemsley> | In particular, a blame for 4722 would be helpful |
| 23:03 | <TabAtkins> | Hixie can generate them, I think. He just doesn't do blames for arbitrary commits, because it's time-expensive to generate. |
| 23:07 | <GPHemsley> | (Incidentally, it's somewhat frustrating that the references were not added until very late in the development of the spec.) |
| 23:52 | <Hixie> | GPHemsley: sure, give me a few minutes |
| 23:52 | <Hixie> | GPHemsley: i wish i still hadn't added the refs, they're a pain to maintain :-) |
| 23:53 | <Hixie> | GPHemsley: check the obvious URL in a few minutes |
| 23:53 | <Hixie> | (dunno how long it takes) |
