| 00:25 | <gsnedders> | dbaron: XML 1.0 5th Ed seems an even better example than 1.1, though obvious enough I presume you've already mentioned it :) |
| 00:26 | <Hixie> | 1.1 is an example of versioning done wrongly, 1.0 e5 is an example of it done right(ish) |
| 00:26 | dbaron | agrees with Hixie there |
| 00:26 | <Hixie> | (ish because e.g. it still has a version pseudo-attribute, and still uses the TR/ page model, and...) |
| 00:34 | <gsnedders> | But XML 1.0 is still de-facto 4e, with no evidence of that changing. |
| 00:35 | <gsnedders> | Given nobody wants to rely on 5e being supported. |
| 00:40 | <Hixie> | oh what's teh difference between 4e and 5e? |
| 01:09 | <TabAtkins> | annevk-cloud: The way the Encoding Standard uses the term "fallback encoding" and the way you call the algorithm is somewhat confusing. It would be clearer if there was a hook for "needs a fallback encoding" which tests if the document has a BOM or not, and then the encoding algo calls its argument just "encoding". |
| 01:10 | <TabAtkins> | It seems to confuse people a lot if a spec goes through a lot of steps to determine an encoding, makes no mention of BOM, and then at the end BOM gets to override all the work the spec did anyway. |
| 01:12 | <TabAtkins> | Oh, hm, here's how I'd like to write it: |
| 01:13 | <TabAtkins> | "If the input stream /has a detectable encoding/, let /encoding/ be the result of /detecting the encoding/. Otherwise, let /encoding/ be .... /Decode the input stream/ with /encoding/." |
| 01:13 | <TabAtkins> | That reads well, but has the exact same effect. |
| 02:39 | <MikeSmith> | TabAtkins: what's ICB mean? |
| 02:50 | <MikeSmith> | initial containing block |
| 02:53 | <Hixie> | yeah |
| 02:55 | <MikeSmith> | Hixie: do you know what current CSS spec defines the equivalent of http://www.w3.org/TR/CSS2/visuren.html ? |
| 02:58 | <Hixie> | isn't that it? |
| 02:59 | <MikeSmith> | Is it? I was thinking their must be some CSS3 version. Or some Level N version, whatever numbering thing they using now |
| 02:59 | <Hixie> | dunno, i'm not up to date on css stuff :-( |
| 02:59 | <MikeSmith> | OK I'll keep looking |
| 03:03 | <MikeSmith> | TabAtkins: btw there's going to be a temporary outage of the http://dev.w3.org/csswg/ tree at some point soon, because that's being written to http://w3c-test.org/csswg/ and I'm going to be shutting down Apache on on port 80 there so we can run the w-p-t python server instead. I'm moving Apache to a different port and will update the rewrite after I do that. |
| 03:08 | <MikeSmith> | OK I see from http://dev.w3.org/csswg/cssom-view/ that "Viewport and initial containing block are defined by CSS 2.1." |
| 03:11 | <astearns> | MikeSmith: I believe http://dev.w3.org/csswg/css-box/ is the intended update, but it isn't near ready yet |
| 03:11 | <MikeSmith> | astearns: OK thanks |
| 03:32 | MikeSmith | files a bug against the CSS 2.1 Rec |
| 03:32 | <MikeSmith> | win 17 |
| 03:32 | <MikeSmith> | oofs |
| 03:39 | <MikeSmith> | hah https://twitter.com/JeniT/status/420638634610798592 "Web components + JS undermine the essential important feature of the web, that browser is not the only client" retweeted by "SEO Market Place" |
| 03:40 | <MikeSmith> | I love the web |
| 03:40 | <MikeSmith> | oops not that one but ""The only people who build for a search engine rather than a browser are spammers." |
| 03:45 | <Hixie> | wait what |
| 03:45 | <Hixie> | aren't those two mutually exclusive |
| 03:46 | <Hixie> | (and both wrong...) |
| 03:48 | <MikeSmith> | yeah |
| 04:56 | <MikeSmith> | hmm http://html5.org/tools/web-apps-tracker?from=8383&to=8384 validator support |
| 05:05 | <MikeSmith> | hsivonen: http://bugzilla.validator.nu/ is still requiring me to log back in on every page load; I have the IP-address checkbox thing unchecked and not getting any kind of error |
| 05:08 | <MikeSmith> | hsivonen: hmm it seems it has two Bugzilla_logincookie cookies set and two Bugzilla_login cookies set |
| 05:08 | <MikeSmith> | with one of each being what seems to be a stale cookie from a month ago |
| 05:09 | MikeSmith | tries removing the cookies and re-logging-in |
| 05:12 | <MikeSmith> | hsivonen: removing the old cookies seems to have fixed it |
| 05:13 | <MikeSmith> | Hixie: there's no spec prohibition against a UA storing two cookies with exactly the same name? |
| 05:16 | <Hixie> | not my spec, but, i would imagine it's keyed by name? |
| 05:17 | <Hixie> | surely if you set a cookie with name X to a value, and it already has one, it just updates the name |
| 05:17 | <Hixie> | er |
| 05:17 | <Hixie> | updates the value |
| 05:31 | <MikeSmith> | Hixie: that's what I would have thought too but Firefox and Chrome are both storing cookies with duplicate names for bugzilla.validator.nu cookies |
| 05:31 | <MikeSmith> | https://gist.github.com/sideshowbarker/8284404/raw/93e7508cb1393fee66fb0ed098f8f97b626d6086/vnu-ff.png |
| 05:31 | <MikeSmith> | https://gist.github.com/sideshowbarker/8284404/raw/d37f460a2b63057307a1dcbe3c006c7c2bef7b86/vnu.png |
| 05:31 | <Hixie> | check the paths |
| 05:31 | <MikeSmith> | ah |
| 05:31 | <Hixie> | i bet they'll be different |
| 05:32 | <MikeSmith> | yeah |
| 05:32 | <MikeSmith> | though not the path actually but the domain |
| 05:32 | <MikeSmith> | weird |
| 05:32 | <Hixie> | huh |
| 05:33 | <MikeSmith> | domain is ".bugzilla.validator.nu" |
| 05:33 | <MikeSmith> | that is, with a leading dot, for some reason |
| 05:34 | <Hixie> | weird |
| 05:34 | <Hixie> | sounds like a bug in bugzilla |
| 05:34 | <MikeSmith> | yeah must be |
| 06:42 | <hsivonen> | MikeSmith: good that there was a solution to the login problem |
| 06:42 | <hsivonen> | (I really should put bugzilla behind https, since it has login...) |
| 06:44 | <MikeSmith> | hsivonen: that'd be cool but not a big priority I guess |
| 09:05 | <annevk> | I just found out this exists: http://www.youtube.com/watch?v=DNCpBwJOadw |
| 09:31 | <annevk> | smola: the host lowercasing thing is interesting |
| 10:22 | <annevk> | TabAtkins: it's not really clear to me how your sentence would replace the current wording |
| 10:22 | <annevk> | TabAtkins: maybe file a bug? |
| 10:26 | <smola> | annevk: yep |
| 10:26 | <annevk> | smola: I outlined a strategy in the bug that I think is correct |
| 10:26 | <smola> | in my implementation I just added the lowercasing to domainToASCII, but it's quite different since that's private API for me and I'm not concerned with JavaScript API |
| 10:27 | <annevk> | smola: yeah, I think it should become a private API in the specification too |
| 10:27 | <annevk> | smola: and you only ever get there through the host parser |
| 10:27 | <smola> | right |
| 10:28 | <smola> | also, I'm not sure ToUnicode needs this |
| 10:28 | <annevk> | probably not, I think ToASCII always happens |
| 10:28 | <annevk> | because if ToASCII fails there's no host, and ToUnicode cannot fail |
| 10:29 | <smola> | that's definitely the case in my implementation |
| 10:29 | <annevk> | so yeah, maybe ToASCII is a better place |
| 10:33 | <smola> | I have yet to check if there're any strange behaviour with locale-dependent case mappings |
| 10:35 | <smola> | these things are well-known to break on conversion to upper case on the Turkish dotted/dotless i, I'll check if the same can happen in to lower case, and what are we supposed to do on IDN using these characters |
| 10:42 | <smola> | annevk: hm, an option is to perform the lowercasing *after* the ToASCII |
| 10:43 | <annevk> | My idea was to perform ASCII lowercase btw |
| 10:43 | <annevk> | which should be saf |
| 10:43 | <annevk> | e |
| 10:43 | <smola> | ToASCII seems to be lowercasing except when the original string is completely ASCII) |
| 10:43 | <annevk> | Yeah, another thing would be to completely inline the IDNA business |
| 10:44 | <annevk> | But I don't really like that |
| 10:44 | <annevk> | The other thing with space probably requires research as to what ASCII browsers reject there and what they accept |
| 10:44 | <annevk> | The host parser could just reject if there's a space, we don't want to reject for _ however |
| 10:45 | <smola> | right, _ is actually used; I've spent some time trying to look for a single real use case for a host with a space and I haven't found any so far |
| 10:47 | <smola> | btw, how do you these these things on each browser? |
| 10:48 | <smola> | do you enter the URL in the address bar? use any JS function? |
| 10:50 | <smola> | some kind of automation would allow to use a service like Sauce Labs and test on every browser/version quickly |
| 10:51 | <MikeSmith> | smola: about your parser I really like that you already have the mechanism in there for actually reporting the parse errors |
| 10:52 | <zcorpan> | smola: https://github.com/w3c/web-platform-tests/tree/master/url |
| 10:53 | <MikeSmith> | smola: I hope eventually we can replace the URL checker in the validator.nu backend with your code |
| 10:55 | <MikeSmith> | zcorpan: btw about the webkit-dev thread I meant the comments from Antti and a copule others who were critical, and TabAtkins responses |
| 10:58 | <zcorpan> | MikeSmith: k |
| 10:58 | <zcorpan> | i wonder what the critics think of new picture |
| 11:00 | <smola> | zcorpan: thank you :) |
| 11:00 | <annevk> | smola: I wrote tests, I also have http://dump.testsuite.org/url/inspect.html |
| 11:00 | <annevk> | smola: and I have access to IE, Safari, Chrome, and Firefox |
| 11:01 | <smola> | MikeSmith: I still have a lot of work to do on providing meaningful error messages, a lot of them are still just "PARSE ERROR" |
| 11:01 | <annevk> | smola: I end up mostly doing adhoc tests and adjusting as I go |
| 11:02 | <smola> | MikeSmith: it would be great to see it working on validator.nu, if you have any doubt/request just tell me here/GitHub/santi⊙mi ;) |
| 11:02 | <smola> | annevk: alright |
| 11:06 | <MikeSmith> | smola: as far as useful error messages for parse errors, looking through how hsivonen handled them for HTML parsing in http://hg.mozilla.org/projects/htmlparser/file/tip/src/nu/validator/htmlparser/impl might provide some inspiration |
| 11:11 | <MikeSmith> | smola: http://hg.mozilla.org/projects/htmlparser/file/tip/src/nu/validator/htmlparser/impl/ErrorReportingTokenizer.java mainly |
| 11:12 | <smola> | MikeSmith: great, I'll check that |
| 11:19 | <MikeSmith> | smola: once you're around to working on the error reporting more I'd be happy to contribute patches if/when you want them |
| 11:23 | <annevk> | MikeSmith: are you going to use his parser so Validator.nu validates URLs? |
| 11:26 | <smola> | MikeSmith: thanks! |
| 11:26 | <MikeSmith> | annevk: yeah that's the plan |
| 11:27 | <annevk> | Great! |
| 11:27 | <MikeSmith> | annevk: we're already validating URLs but we're using the Jena URI library |
| 11:28 | <MikeSmith> | which follows the legacy RFCs but not of course the current URL standard |
| 11:29 | <MikeSmith> | the Jena URI code is pretty old (and unmaintained now ) |
| 11:30 | <MikeSmith> | and to be clear the plan for replacing it depends on hsivonen OKing it |
| 11:41 | <smola> | it seems most Java stuff is stuck at RFC 2396 |
| 11:42 | <smola> | and lacks support for IDN |
| 11:49 | <MikeSmith> | yeah |
| 12:41 | <zcorpan> | annevk: any conclusion yet about utf-8 vs doc encoding for urls? |
| 12:43 | <annevk> | no |
| 13:35 | <annevk> | zcorpan: it's not entirely clear to me how to make a good decision here |
| 13:36 | <annevk> | zcorpan: I remember last time my final argument was that having to keep the document's encoding around in order how to know how to resolve a URL was bad news |
| 13:36 | <annevk> | zcorpan: so I think I would still prefer to use utf-8 whenever possible so having to keep that around is limited to a couple of things in HTML |
| 13:37 | <annevk> | zcorpan: e.g. requiring it for EventSource seems painful, as EventSource would otherwise not need it, same for XMLHttpRequest |
| 13:38 | <zcorpan> | annevk: but don't you need to keep it around anyway? |
| 13:38 | <annevk> | zcorpan: not in e.g. Workers |
| 13:39 | <zcorpan> | annevk: right, but outside workers |
| 13:40 | <annevk> | zcorpan: so you want to complicate the API implementation because of document environments it might be used in? |
| 13:40 | <annevk> | zcorpan: it seems better if the API implementation doesn't need that at all |
| 13:42 | <zcorpan> | er, no, i'm just saying that you need to store the document's encoding so it's not a big win that EventSource avoids using it |
| 13:43 | <zcorpan> | it's not clear to me that it complicates the impl since browsers seem to have used the document's encoding by accident in some places |
| 13:44 | <zcorpan> | as for CSS, it also needs to store its encoding because @import can use it as fallback encoding |
| 14:11 | <Ms2ger> | Here it's 2014 and we're still speccing <frame> |
| 14:11 | <darobin> | :) |
| 14:54 | <zcorpan> | Ms2ger: tests coming up? |
| 14:54 | <zcorpan> | for <frame> |
| 14:55 | <Ms2ger> | Not from me |
| 14:55 | <zcorpan> | aww |
| 14:55 | <zcorpan> | poor frame |
| 14:55 | <Ms2ger> | Maybe if you come and take my exam tomorrow? :) |
| 14:56 | <zcorpan> | i don't think you'd actually want me to |
| 14:57 | <Ms2ger> | I'm not sure I'd want myself to either :) |
| 14:57 | <Ms2ger> | Anyway |
| 14:57 | Ms2ger | revises |
| 14:58 | <ondras> | so, <embed> vs. <object> w.r.t. flash |
| 14:58 | <ondras> | what is the recommended way, forgetting IEs and so on? |
| 14:59 | <jgraham> | "don't use flash" |
| 15:02 | <ondras> | yeah, well, this option is a no-go apparently |
| 15:02 | <ondras> | judging from the percentage of my users that do not support a webgl-based solution |
| 15:12 | <annevk> | zcorpan: it complicates the impl of EventSource |
| 15:12 | <zcorpan> | ondras: do you need fallback content? |
| 15:12 | <annevk> | zcorpan: unless you're suggesting the URL parser should hook into some global state to figure out if there's an override encoding in scope... |
| 15:13 | <annevk> | which seems like poor design |
| 15:14 | <zcorpan> | annevk: yeah i agree that it complicates the impl of EventSource, at least in theory |
| 15:14 | <zcorpan> | annevk: but it seems marginal |
| 15:14 | <annevk> | it seems better if EventSource works the same across realms |
| 15:15 | <annevk> | hah, did you see that? I'm arguing for consistency! |
| 15:15 | <ondras> | zcorpan: no |
| 15:15 | <ondras> | zcorpan: I actually want to build that DOM via JS (createElement etc) |
| 15:16 | <zcorpan> | ondras: do you need it to be secure in case the linked content isn't actually flash? |
| 15:17 | <zcorpan> | annevk: yeah so it's either consistent with EventSource in different places or it's consistent with <a href> in the same doc |
| 15:19 | <ondras> | zcorpan: no, I host/author that content myself |
| 15:19 | <zcorpan> | ondras: then embed is probably simplest and most compatible |
| 15:20 | <annevk> | zcorpan: if you have a URL you're going to use for EventSource, it seems better if it's consistent across EventSource |
| 15:20 | <ondras> | zcorpan: and some differences beweetn embed and object, so I can see why to pick one and not the other? |
| 15:20 | <Ms2ger> | MikeSmith, so, did that monk actually work for MPAA? |
| 15:21 | <annevk> | zcorpan: the problem with <a> is that it's not even consistent with <a> in a nested browsing context |
| 15:23 | <zcorpan> | ondras: embed doesn't support fallback content, object does. object has an attribute called typemustmatch that protects against attacks where the linked content is of an unexpected type. embed is terser/easier to set params. embed has better interop i think |
| 15:24 | <ondras> | okay, thanks a lot! |
| 15:25 | <zcorpan> | np |
| 15:27 | <zcorpan> | annevk: i don't follow why that is a problem with <a> |
| 15:27 | <annevk> | zcorpan: I have a URL, I hand it to Google Maps or some such, and now it's a different URL |
| 15:28 | <annevk> | zcorpan: if I'm not careful anyway |
| 15:30 | <zcorpan> | annevk: ok, yeah |
| 15:31 | <zcorpan> | time for coffee. see you :-) |
| 15:39 | <gsnedders> | Is there any actually good list of problems with relying on reference implementations anywhere, or am I going to have to ad lib this? |
| 15:44 | <Ms2ger> | Write it, publish it |
| 15:50 | <gsnedders> | Is a reference implementation actually more likely to have bugs than a spec? |
| 15:52 | <jgraham> | Well usually people don't bother to finish it |
| 15:52 | <Ms2ger> | Do people usually finish specs? :) |
| 15:52 | <jgraham> | But I would imagine the need to run on a real machine makes bugs more likely |
| 15:52 | <Ms2ger> | I know I am bad at that, at least :) |
| 15:55 | <gsnedders> | https://gist.github.com/gsnedders/7e85c83e697e81c69432 |
| 15:56 | <gsnedders> | Comments, suggested other reasons why they suck, all welcome. |
| 16:00 | <annevk> | So from my experience reverse engineering features and writing down their details it's awesome to have an implementation |
| 16:00 | <annevk> | So I disagree with point 3 |
| 16:00 | <gsnedders> | Is it better than having a spec with multiple independent impls, though? |
| 16:01 | <gsnedders> | And why does that have to be a reference impl? |
| 16:01 | <jgraham> | Huh? Given that you have to create an implementation you would rather have an existing implementation than an existing spec (but no implementation)? |
| 16:02 | <gsnedders> | I can't even parse what jgraham just said. |
| 16:02 | <annevk> | gsnedders: I don't really care about what kind of implementation it is |
| 16:02 | <annevk> | gsnedders: html5lib was useful, some people labeled it reference, perhaps incorrectly |
| 16:02 | <annevk> | gsnedders: and the more the merrier, of course :-) |
| 16:02 | <gsnedders> | annevk: It's not normative in any sense. |
| 16:03 | <annevk> | gsnedders: a reference implementation is normative? |
| 16:03 | <annevk> | gsnedders: ew |
| 16:03 | <annevk> | gsnedders: are there even people arguing in favor of that? |
| 16:03 | <gsnedders> | Yes. |
| 16:03 | <Ms2ger> | ... |
| 16:03 | <jgraham> | It was useful, but given we wanted to create it I would have preferred to have the spec than, say, hsivonen's implementation to work from |
| 16:03 | <gsnedders> | annevk: I'd consider a "reference implementation" normative by definition. |
| 16:04 | <annevk> | I'm just saying I like to have a spec and an impl |
| 16:04 | <annevk> | Not either alone |
| 16:05 | <gsnedders> | I'm arguing the W3C's requirement of having two independent impls is better than having a single reference impl. |
| 16:05 | <Ms2ger> | Yay, someone making arguments for <rtc> on www-style |
| 16:05 | <gsnedders> | Essentially. |
| 16:05 | <annevk> | The other person in that argument is insane |
| 16:06 | <annevk> | "insane" but still |
| 16:06 | <Ms2ger> | Eh, so am I, so that doesn't say much ;) |
| 16:06 | <annevk> | Ms2ger: why not? ;) |
| 16:06 | <gsnedders> | :) |
| 16:10 | <darobin> | Ms2ger: where? I'm seeing an argument for <rbc> for not for <rtc> |
| 16:11 | <darobin> | no one is adding <rbc> :) |
| 16:11 | <Ms2ger> | For double-sided ruby, I think not <rbc>, but <rtc> is necessary, as |
| 16:12 | <Ms2ger> | follows. |
| 16:12 | <Ms2ger> | <ruby>Base<rtc>text A</rtc><rtc>text B</rtc></ruby> |
| 16:24 | <gsnedders> | https://gist.github.com/gsnedders/7e85c83e697e81c69432 — anything else I ought add before publishing it? |
| 16:48 | <astearns> | gsnedders: "different implementations likely have to interoperate" is true with a reference implementation as well. What about "each implementation has to match the spec" |
| 16:54 | <MikeSmith> | Ms2ger: dunno who that monk worked for. All we did was talk about smoke. I showed him how to make a pipe out of a coke can, which he thought was pretty cool |
| 16:54 | <smola> | gsnedders: I would say your second point is equivalent to a ambiguous wording on a spec ;) |
| 16:54 | <smola> | (i.e. specs can contain bugs too) |
| 16:54 | <gsnedders> | astearns: There is definitely the point that a reference implementation can easily become the only implementation, so they don't necessarily have to interoperate. |
| 16:55 | <gsnedders> | smola: Yeah, I was trying to pick something where if it occured in a spec it would just have totally undefined behaviour. Which null pointer dereferences are, really. |
| 16:55 | <smola> | gsnedders: fair enough |
| 16:56 | <astearns> | gsnedders: even if there's only one implementation, you get better review of that one implementation by expecting it to conform to an external spec |
| 16:57 | <gsnedders> | astearns: Yeah, I'm not questioning that |
| 16:57 | <gsnedders> | astearns: Just trying to justify the point I was trying to make :) |
| 17:01 | <gsnedders> | astearns: Better put now? |
| 17:02 | <astearns> | gsnedders: yep |
| 17:03 | <gsnedders> | On the other hand, I still feel like the conclusion has the obvious come back of, "but a reference impleemntation defines formally all behaviours, and hence the spec cannot have ambiguity". |
| 17:07 | <TabAtkins> | "defines formally all bugs that I wrote because I am a fallible human" |
| 17:09 | <gsnedders> | TabAtkins: *rewrites as the generic "author" and steals that* |
| 17:13 | <gsnedders> | TabAtkins: Comments on the conclusion now written based on that welcome :) |
| 17:41 | <smola> | MikeSmith: there you go: https://github.com/smola/galimatias/commit/6266c09c2ffe2961b4947554f6c38b33dad015ae |
| 17:41 | <smola> | everything has an actual meaningful error now |
| 17:45 | MikeSmith | looks |
| 17:46 | <MikeSmith> | wow man |
| 17:46 | <MikeSmith> | you work fast :-) |
| 17:46 | <MikeSmith> | very nice |
| 17:48 | <MikeSmith> | smola: I will try to get this integrated in local validator workspace soon, as a replacement for the Jena URI checker we're using now |
| 17:48 | <MikeSmith> | *in my local validator workspace |
| 17:50 | <smola> | MikeSmith: thanks! please, let me know if I can help |
| 17:51 | <smola> | btw, you'll need that latest SNAPSHOT: https://oss.sonatype.org/content/repositories/snapshots/io/mola/galimatias/galimatias/0.0.2-SNAPSHOT/ |
| 18:00 | <MikeSmith> | smola: OK will do |
| 18:02 | <TabAtkins> | gsnedders: I like the conclusion. |
| 19:15 | Hixie | ponders how best to make a list of all events mentioned in the HTML spec |
| 19:17 | <jory> | In a similar vein, does anyone have a good technique for registering a simple listener (just a logger) for all possible events? |
| 19:18 | <jory> | (i.e. just to get a better sense, while debugging, of the interactions between a series of events) |
| 19:18 | <Ms2ger> | No way to do that from a web page |
| 19:19 | <Ms2ger> | Fx has an API for chrome scripts iirc |
| 19:32 | <jory> | Does anyone know if Mobile Safari fires any particular event when it is changing the zoom level, or if there is a way to force a zoom to happen? |
| 20:03 | <TabAtkins> | Hixie: Mark them all up in a Bikeshed/Shepherd-compatible way, and we can auto-gen one for you. |
| 20:22 | <Hixie> | TabAtkins: it's the marking them up part that's the part i'm hoping to automagicate |
| 20:22 | <Hixie> | TabAtkins: once i have it in a computer-readable form, the rest is easy :-) |
| 20:22 | <TabAtkins> | Right, but if you do it *my* way, then it's easy for *me* as well. |
| 20:22 | <TabAtkins> | Because I can just say <a event>activate</a> or whatever and it works. |
| 20:23 | <Hixie> | i'm not sure we're trying to solve the same problem here |
| 20:23 | <Hixie> | the cross-referencing is already all done |
| 20:23 | <TabAtkins> | I'm trying to solve a problem vaguely related to yours that helps me more. |
| 20:23 | <Hixie> | hehe |
| 20:23 | <Hixie> | what's the problem you're trying to solve? |
| 20:24 | Hixie | briefly ponders whether there might be some value in having a single document that documents all the events of the web platform, but puts the bong down just in time |
| 20:24 | <TabAtkins> | MOAR LINK TARGETS IN A BIKESHEDDABLE FORM |
| 20:24 | <Hixie> | oh so you could cross-reference from CSS to HTML? |
| 20:24 | <TabAtkins> | (Which means, mainly, that Shepherd can parse them and know what the definition type is.) |
| 20:24 | <TabAtkins> | Bikeshed is for more than CSS! |
| 20:24 | <TabAtkins> | But yes. |
| 20:25 | <Hixie> | what's the format you need me to expose for that to be easy for you? |
| 20:25 | <Hixie> | maybe i can do that at the same time |
| 20:26 | <Hixie> | (is there documentation somewhere for bikeshed and shepherd?) |
| 20:26 | <Hixie> | (source code would do) |
| 20:26 | Hixie | is considering transitioning away from anolis, but mainly because anolis can't handle 5MB+ docs fast |
| 20:26 | <TabAtkins> | Yeah, docs are all at https://github.com/tabatkins/bikeshed |
| 20:26 | <TabAtkins> | I don't know if Bikeshed can handle 5MB fast either. probably not. |
| 20:27 | <jory> | TabAtkins: I really like your Github avatar. |
| 20:27 | <TabAtkins> | But I'd be willing to try. |
| 20:27 | <TabAtkins> | jory: Thanks! It's from Kate Beaton. |
| 20:27 | <Hixie> | (ideally i'd like a platform that's identical to anolis except not based on python or other slow ass interpreted languages...) |
| 20:27 | <TabAtkins> | Hixie: Welp, I've got you on the first, but not the second. |
| 20:27 | <Hixie> | yeah, wasn't suggesting bikeshed as solution |
| 20:28 | <TabAtkins> | So, to make things Shepherd-friendly, there are a few ways, depending on how explicit/unambiguous you wanna be. |
| 20:28 | <Hixie> | really i just need to put my fingers where my mouth is and implement an HTML parser and DOM in some compiled language |
| 20:28 | <TabAtkins> | 1. Add a data-dfn-type attribute to the <dfn> with one of the definition types: <https://github.com/tabatkins/bikeshed/blob/master/bikeshed/config.py>; (the values in the dfnClassToType object). |
| 20:29 | <TabAtkins> | 2. Make the id start with the dfn class and a dash, from the same link (the keys in the dfnClassToType object). |
| 20:29 | <TabAtkins> | 3. Give them a class equal to the right dfn class. |
| 20:29 | <TabAtkins> | Or, if it's a CSS term, just write in the right way, and Shepherd'll infer things (docs explain the right way). |
| 20:31 | <Hixie> | so like <dfn data-dfn-type="event" id="event-load" class="event"><code>load</code></dfn> ? |
| 20:32 | <TabAtkins> | id=eventdef-load class=eventdef, but otherwise yes. |
| 20:32 | <TabAtkins> | But you only have to do one. ^_^ |
| 20:32 | <Hixie> | oh those are various options, ok |
| 20:33 | <Hixie> | sorry, thought it was a list of steps |
| 20:33 | <Hixie> | my bad |
| 20:33 | <TabAtkins> | Oh jeez, that would be terrible. |
| 20:33 | <Hixie> | yeah :-) |
| 20:33 | <TabAtkins> | Nah, it's documentation of all the various ways existing specs we want to parse have done it. ^_^ |
| 20:34 | <Hixie> | so i expect HTML will use <dfn data-x="event-load"><code>load</code></dfn> or <dfn data-x="event-media-load"><code>load</code></dfn>, where the "media-" part is for grouping related events (e.g. all the media element events), which might duplicate the names of some of the non-grouped events |
| 20:34 | <Hixie> | if you want to add support for that |
| 20:35 | <TabAtkins> | When you decide on something, tell me and I'll ping plinss. He's the one running Shepherd. |
| 20:35 | <TabAtkins> | So the "media" term is arbitrary? |
| 20:35 | <Hixie> | assume i'm going with the above. it's what everything does now. |
| 20:35 | <Hixie> | yeah |
| 20:35 | <Hixie> | (everything in HTML i mean) |
| 20:36 | <Hixie> | looks like there's media, MediaController, input, appcache, socket, and worker |
| 20:36 | <Hixie> | currently |
| 20:37 | <Hixie> | not planning on adding any soon, but they are arbitrarily added as needed. |
| 20:37 | <Hixie> | basically it's just to prevent events in the worker section cross-referencing to events in the media section, etc. |
| 20:37 | <TabAtkins> | That's fine, just making sure they weren't a term that needs to be synced up against something else. |
| 20:38 | <TabAtkins> | Shepherd's data model supports definitions being "for" other definitions, to avoid collisions. |
| 20:38 | <Hixie> | generally i try to use the same term as in data-x="attr-foo-name" and data-x="dom-foo-name", which is the element name for elements, and the interface name (usually) for IDL stuff |
| 20:39 | <Hixie> | and concept-foo-name for non-concrete things like algorithms |
| 20:39 | <Hixie> | though when i can i just use longer names so i don't have to give a special cross-ref term at all |
| 20:39 | <TabAtkins> | Yeah, the shepherd way is <dfn data-dfn-type=attr data-dfn-for=foo>name</dfn> (or in Bikeshed's shorthand, <dfn attr for=foo>name</dfn>) |
| 20:39 | <TabAtkins> | So the relationship is machine-inferrable. |
| 20:39 | <Hixie> | right |
| 20:40 | <TabAtkins> | The Anolis way of giving everything a globally unique xref name is bad. :/ |
| 20:40 | <Hixie> | *shrug* |
| 20:40 | <Hixie> | it works ok |
| 20:41 | <TabAtkins> | Yeah, while you're the only one working on it, or are willing to pull up the document you want to reference regularly to remind yourself of the naming pattern that spec author used. |
| 20:41 | <Hixie> | it's acutally helped in a couple of places, by preventing me from naming something in a confusing ambiguous fashion |
| 20:41 | <Hixie> | yeah it's terrible for cross-doc stuff |
| 20:41 | <Hixie> | notice the lack of any cross-doc stuff in HTML :-( |
| 20:42 | <TabAtkins> | Yup, and xdoc was the primary reason I started Bikeshed. |
| 20:42 | <Hixie> | though i think the way i would want to do cross-doc references actually would be to just list the term as i use it and the term as the other spec uses it, in a single "dependencies" section |
| 20:42 | <Hixie> | the section actually exists in HTML now, just doesn't have the cross-refs |
| 20:43 | <Hixie> | but if i added them, it would allow for the preprocessor to automatically map from my terms to the other specs' terms |
| 20:43 | <Hixie> | without my having to keep looking up what the conventions were |
| 20:43 | <Hixie> | nor having to convert anyone else |
| 20:43 | <Ms2ger> | xref works fine in anolis |
| 20:43 | <TabAtkins> | Also doable in Bikeshed manually, but you haven't lived until you've written ''foo/auto'' and been auto-linked to the definition of the "auto" keyword for the "foo" property. |
| 20:43 | <Hixie> | and it would have the advantage of still being usable in print form |
| 20:43 | <TabAtkins> | Or even better, been informed that you typo'd something, because "foo" has no "auto" value. |
| 20:43 | <Hixie> | my HTML publishing pipeline catches broken xrefs |
| 20:44 | <Hixie> | (i don't always notice, but...) |
| 20:44 | <Hixie> | (that's why there's a lot of data-x="" (with no value) -- it's telling my system that this isn't supposed to cross-ref) |
| 20:45 | <TabAtkins> | Oh yeah, Anolis tries to cross-ref all inlines or something, right? |
| 20:45 | <Hixie> | not all of them, only the ones that make sense |
| 20:45 | <Hixie> | anyway. i think i need to pull out all occurences of the string (event-[^"]+), and somehow check if they're in <dfn> or not, and if they are... not sure what |
| 20:45 | <Hixie> | maybe just mark those that are, to start with |
| 20:45 | <Hixie> | little bit of perl should do nicely |
| 20:46 | <TabAtkins> | You crazy. |
| 21:44 | <jamesr__> | annevk-cloud: why do you want event timestamps defined in the web perf WG instead of in the dom events spec? |
| 21:44 | <jamesr__> | seems kind of crazy |
| 21:47 | <annevk> | jamesr__: I think it was some dependency thing |
| 21:47 | <jamesr__> | there's a typedef DOMHighResTimestamp, but that just means number in webidl |
| 21:47 | <jamesr__> | and the type is in a standalone spec that dom events could easily cite |
| 21:47 | <annevk> | doesn't it depend on navigate or fetch or some such? |
| 21:48 | <jamesr__> | the IDL is "typedef double DOMHighResTimeStamp;" |
| 21:49 | <jamesr__> | the window.performance.now() interface depends on navigation, but you wouldn't need to reference that normatively in dom events |
| 21:50 | <jamesr__> | dom events would need to expose an attribute of that type and then describe the timebase in a way that could be implemented to match up with window.performance.now() / webaudio / whatever else is using this clock |
| 21:51 | <jamesr__> | webaudio's language is probably too loose but it has the same idea |
| 22:04 | <jamesr__> | (i don't really see much value in typedeffing different things to double in WebIDL - the type itself doesn't have any interesting meaning. the value itself does, but the type doesn't help understand the value) |
| 22:15 | Domenic_ | shakes fist at WebIDL's number-types clusterfuck |
| 22:34 | <annevk> | jamesr__: file a bug? |
| 22:34 | <annevk> | jamesr__: can take a look tomorrow |
| 22:39 | <jamesr__> | annevk: last thread was http://lists.w3.org/Archives/Public/www-dom/2012OctDec/0028.html |
| 22:39 | <smola> | annevk: https://github.com/w3c/web-platform-tests/blob/master/url/urltestdata.txt issues with this should be reported to GitHub Issues or...? |
| 22:39 | <annevk> | smola: not sure, ask zcorpan / jgraham |
| 22:40 | <smola> | zcorpan: just in time |
| 22:40 | <smola> | 23:39 < smola> annevk: |
| 22:40 | <smola> | https://github.com/w3c/web-platform-tests/blob/master/url/urltestdata.txt issues with this should be reported to GitHub Issues or...? |
| 23:25 | <Hixie> | what spec is going to define 'scroll' and 'resize' events? |
| 23:55 | <Hixie> | behold: http://www.whatwg.org/specs/web-apps/current-work/#events-0 |
