| 00:00 | <annevk> | it was a rather hypothetical point, indeed |
| 00:06 | <Lachy> | othermaciej, would it make sense to have both queryScopedSelector and :context? |
| 00:06 | <Lachy> | oh, well, for scoped stylesheets in HTML5, yes. But for selectors api? |
| 00:07 | <othermaciej> | Lachy: I think so |
| 00:07 | <Lachy> | ok, fair enough |
| 00:07 | <othermaciej> | Lachy: the pseudo-class lets you do things that implicit scoping wouldn't |
| 00:07 | <Lachy> | I'll take another look at the idea over the next few days |
| 00:07 | <Lachy> | right |
| 00:07 | <othermaciej> | but implicit scoping is convenient and has evolved as a de facto standard in JS libraries |
| 00:08 | <othermaciej> | I think we should go along with it instead of fighting it, so long as the semantics can be defined soundly |
| 00:08 | <Lachy> | ok, fair enough. I"ll talk to our developers about whether or not its implementable |
| 00:08 | <othermaciej> | a while back I sent a fairly simple algorithm that could be used to translate a scoped selector to a selector using :scope/:context |
| 00:08 | <othermaciej> | to public-webapi |
| 00:09 | <Lachy> | and then there was that issue of effectively redefining the grammar of selectors, which would probably result in some complaints from the CSSWG |
| 00:09 | <othermaciej> | 1. Initialize nesting level to 0 |
| 00:09 | <othermaciej> | 2. Initialize the output string to the empty string |
| 00:09 | <othermaciej> | 3. While characters in the input string remain: |
| 00:09 | <othermaciej> | 3.a. read the current character |
| 00:09 | <othermaciej> | 3.b. if the current character is: |
| 00:09 | <othermaciej> | ",": if the nesting level is 0, append ", :scope " to the output string |
| 00:09 | <othermaciej> | "(": increase the nesting level by 1, and append "(" to the output string |
| 00:09 | <Lachy> | yeah, I remember that. |
| 00:09 | <othermaciej> | ")": decrease the nesting level by 1, and append ")" to the output string |
| 00:09 | <othermaciej> | anything else: append the current character to the output string |
| 00:09 | <Lachy> | oh, where is that mail? |
| 00:09 | <othermaciej> | 3.c. advance to the next character |
| 00:09 | <othermaciej> | 4. return the output string |
| 00:09 | <Lachy> | I was looking for it |
| 00:09 | <othermaciej> | (sorry for the large paste) |
| 00:09 | <othermaciej> | it's in the public-webapi archives |
| 00:09 | <annevk> | SVG in HTML: http://www.w3.org/2008/07/10-svg-minutes.html#action02 |
| 00:09 | <Lachy> | do you have a link handy |
| 00:10 | <othermaciej> | it doesn't redefine the grammar of selectors, just defines a new syntax for the related notion of scoped/contextual selector |
| 00:10 | <Lachy> | found it http://lists.w3.org/Archives/Public/public-webapi/2008May/0058.html |
| 00:10 | <annevk> | I'd suggest postponing that to Selectors API Level 2 |
| 00:11 | <Lachy> | yeah, that might be sensibe |
| 00:11 | <Lachy> | othermaciej, is there any reason to rush it through in v1? |
| 00:11 | <othermaciej> | http://lists.w3.org/Archives/Public/public-webapi/2008May/0058.html |
| 00:11 | <annevk> | unless :context is somehow fast tracked |
| 00:11 | <othermaciej> | Lachy: I don't think it is essential for v1 |
| 00:11 | <Lachy> | ok, good. |
| 00:11 | <othermaciej> | just seems like a good idea in general |
| 00:12 | <Lachy> | I'll write up a draft for v2 with it included and put it in CVS later |
| 00:12 | <othermaciej> | however, I do think <style scoped> + queryScopedSelector would lean towards the pseudo-class being :scope instead of :context |
| 00:12 | <othermaciej> | for consistency |
| 00:12 | <Lachy> | also have to add other requested features like NodeList.querySelector |
| 00:13 | <Lachy> | but first, I have to deal with those pesky NSResolver issues |
| 00:13 | <Lachy> | unfortunately, I didn't have tim to look at replacing it with one of the other proposals now, and since Mozilla has started implementing it, it's a bit late to turn back now :-( |
| 00:14 | <Lachy> | s/tim/time/ |
| 00:14 | <othermaciej> | Mozilla's implementation hasn't shipped yet |
| 00:14 | <othermaciej> | so I guess lack of your time would be the only problem |
| 00:14 | <othermaciej> | (afaik Mozilla's implementation has not even been checked in yet) |
| 00:15 | <Lachy> | yeah, and I'm pretty sure I can resolve the issues with the function approach anyway. Besides, they need to be solved for NSResolvers used elsewhere, so they may as well be solved here and adopted into the other places too |
| 00:16 | <Lachy> | since the other specs with NSResolvers leave a lot of this largely undefined |
| 00:16 | <othermaciej> | my problem with the function approach isn't really that it can do random things, but just that it is a bad idea in the first place to use a function instead of a data structure to represent namespace prefix mappings |
| 00:17 | <othermaciej> | requiring resolution of all prefixes in the selector up front should be enough to make behavior interoperable |
| 00:17 | <othermaciej> | I think the only reason we are using NSResolver is because XPath did, which doesn't seem like a particularly good reason to me |
| 00:18 | <Lachy> | yeah, that's a possibility |
| 00:19 | <Lachy> | how about I draft up the spec to replace it tomorrow and let the WG decide if we want to keep it as is, or adopt the newer approach. |
| 00:19 | <Lachy> | With a concrete proposal, it might make the decision process a lot easier |
| 00:19 | <Lachy> | since so far we've been arguing about what we've already spent a great deal of time on and is already quite mature, and something that isn't even specced yet |
| 00:20 | <Lachy> | It would have been easier if Mozilla had decided to ship without NSResolver support though, which is what I had hoped when I defined it to be optinal |
| 00:21 | <roc> | we haven't shipped anything so i don't see what the problem is |
| 00:22 | <Lachy> | the problem is that time is being spent implementing and testing a feature which could be dropped |
| 00:22 | <Lachy> | so I'd better hurry up and make a decision to not too much time is wasted |
| 00:22 | <Lachy> | but in any case, the implementation experience could help make the decision easier I guess |
| 00:22 | <roc> | I'm not sure if Boris has implemented the NSResolver stuff, but the whole thing only took him a week or less so not much effort has been wasted at worst |
| 00:22 | <roc> | on our side |
| 00:22 | <Lachy> | he started on it a couple of days ago |
| 00:23 | <Lachy> | they're already discussing issues with in in bugzilla |
| 00:23 | <roc> | er ok :-) |
| 00:23 | <Hixie> | othermaciej: your convertor fails on \escapes |
| 00:24 | <annevk> | introducing the second argument to querySelector was a mistake |
| 00:24 | <othermaciej> | Hixie: good point - should be patchable |
| 00:24 | <Lachy> | I think the best alternative solution was to make it a DOMString like "#default=http://www.w3.org/1999/xhtml svg=http://www.w3.org/2000/svg"; or something like that |
| 00:24 | <othermaciej> | Hixie: given how unrelated it is to normal parsing, I should probably try to write a proof that it will DTRT for all selector syntax |
| 00:24 | <annevk> | my apologies and 10.000 dollar (monopoly currency) to Ian Hickson for saying that from the beginning |
| 00:25 | <othermaciej> | should be easy to do inductively and should catch any other errors |
| 00:26 | <annevk> | as from a use case point of view namespace support is not at all needed at this point |
| 00:27 | <annevk> | even for SVG and MathML it would work fine without it |
| 00:35 | <Hixie> | othermaciej: (doesn't handle strings, either) |
| 00:36 | <othermaciej> | Hixie: acknowledged |
| 00:42 | annevk | -> bed |
| 00:43 | <Lachy> | grr. Why is it that I can't get a straight answer to my question about what Boris wants the spec to say? https://bugzilla.mozilla.org/show_bug.cgi?id=416317#c31 |
| 00:46 | <Hixie> | isn't he just saying "leave it up to webidl"? |
| 00:54 | <Lachy> | yeah, maybe. I posted another comment saying that |
| 00:57 | <Lachy> | ok, it seems :context for DocumentFragments isn't getting much support. Unless there are really convincing use cases for it, I'm going to drop it. But even if there are, there's probably better solutions. |
| 03:50 | <weinig> | JohnResig: ping |
| 03:53 | <weinig> | JohnResig: I am curious about verifyResolve method in your selectors test |
| 03:54 | <weinig> | JohnResig: I am getting a failure because null is being passed to it, but my reading of spec says that null should be passed to the resolver to get the default namespace |
| 10:59 | hendry | wonders if those messaging edits would help me in my "i want to tail logs via a web browser" use case |
| 13:43 | <JohnResig> | Lachy: the webkit guys are saying that in order to get the default namespace null has to be passed in to the namespace resolver - however in the examples in the spec it shows "" as representing the default namespace (and Opera does "" as well) |
| 13:45 | <annevk> | http://dev.w3.org/2006/webapi/selectors-api/#nsresolver says null... |
| 13:46 | <JohnResig> | annevk: so I think Opera's implementation is probably in the wrong here |
| 13:46 | <JohnResig> | annevk: we have gems like this, as well: "" :"http://www.w3.org/1999/xhtml";, // Default namespace |
| 13:46 | <JohnResig> | which is, apparently, completely wrong |
| 13:46 | <annevk> | can you do { null : "..." } ? |
| 13:46 | <annevk> | if not, changing to the empty string might make sense |
| 13:47 | <JohnResig> | null gets converted into a string representation of "null" (which means that you can no longer have a namespace named null) |
| 13:47 | <JohnResig> | yeah, that's why empty string made sense - since you can't have an empty namespace to begin with |
| 13:47 | <annevk> | you're confusing prefix and namespace |
| 13:47 | <annevk> | i agree that the empty string makes sense though |
| 13:50 | <Lachy> | oh dear. |
| 13:51 | <Lachy> | there was a reason this was changed. I believe it was because Node.lookupNamespaceResolver or maybe the XPath NSResolver expected null to be passed. |
| 13:51 | <annevk> | XPath doesn't do default namespace |
| 13:52 | <Lachy> | ok, it must have been the Node one then |
| 13:52 | <annevk> | why are we keeping NSResolver around again? :) |
| 13:53 | <Lachy> | annevk, I don't know :-) |
| 13:53 | <annevk> | yeah: http://www.w3.org/TR/DOM-Level-3-Core/core.html#Node3-lookupNamespaceURI |
| 13:54 | <JohnResig> | ok, that seems pretty conclusive, then |
| 13:54 | <JohnResig> | I'll change the test suite |
| 13:55 | <Lachy> | well, not entirely. It sucks for authors. |
| 13:56 | <JohnResig> | which authors? |
| 13:56 | <annevk> | we don't depend on lookupNamespaceURI so it makes no sense to be compatible with it |
| 13:56 | <annevk> | imo |
| 13:56 | <JohnResig> | oh |
| 13:58 | <annevk> | doing obj = { "" : "...", "prefix1" : "..." }; return obj[prefix] is much more convenient than if(prefix == null) { ... } else { return obj[prefix] } |
| 13:58 | <Lachy> | JohnResig, not being able to use the simple hash that I used in the example sucks for authors |
| 13:59 | <JohnResig> | ok! so yeah, I'm changing the test suite, then |
| 13:59 | <annevk> | though namespaces suck anyway and are hardly relevant for any use case I can imagine for this API, so it doesn't matter |
| 13:59 | <Lachy> | ok, fair enough |
| 13:59 | <Lachy> | maybe I really should focus on looking at the alternative proposals |
| 14:00 | <krijnh> | JohnResig: how is your new JS selector engine going? |
| 14:00 | <JohnResig> | krijnh: going good - haven't had time to work on it in a while |
| 14:01 | <krijnh> | I got ignored on jquery-dev, when asking about it :) |
| 14:02 | <JohnResig> | krijnh: I haven't announced it publicly |
| 14:04 | <krijnh> | Hmm, I thought I read about it somewhere |
| 14:04 | <JohnResig> | krijnh: were you at Kings of Code |
| 14:04 | <krijnh> | Yeah, I was, but apart from that |
| 14:05 | <krijnh> | I was the one not doing any talking :) |
| 14:18 | <Lachy> | JohnResig, regarding the queryScopedSelector idea, which would be able to accept combinator rooted queries like ">em, >strong", could you provide me with details sometime (via email) about how exactly JQuery goes about parsing them? |
| 14:18 | <Lachy> | if we're going to consider adding that to selectors api v2, it would be useful to know so we could ensure proper compatibility |
| 14:18 | <JohnResig> | ok! |
| 14:19 | <Lachy> | also, any experience you have with implementing :context and prepending that to queries that you will eventually pass to querySelector(); would help too |
| 14:20 | <Lachy> | do you want me to send you a mail about that, or will you just remember to do it? There's not rush though. |
| 14:20 | <JohnResig> | Lachy: feel free to pass me an email |
| 14:20 | <Lachy> | ok, I will do later |
| 15:01 | <takkaria> | hmm, html5lib has an odd test |
| 15:01 | <takkaria> | well, I think it has a wrong one anyway |
| 15:02 | <annevk> | patches accepted |
| 15:02 | <takkaria> | I'm just checking I'm right against the spec |
| 15:20 | <annevk> | I gave in and made a bugzilla account |
| 15:29 | <Lachy> | annevk, wow. |
| 15:29 | <Lachy> | what made you change your mind? |
| 15:30 | <annevk> | All the extra e-mail I will get |
| 15:46 | <codedread> | does anyone have any good reference docs on mousewheel handling cross-browser? |
| 15:48 | <codedread> | (obviously i'm talking about current support, not future perfect support of onmousewheel) |
| 15:48 | <annevk> | I don't think there's much documentation on such things |
| 15:49 | <codedread> | grumble |
| 15:49 | <codedread> | google does it cross-browser for google maps, so it must be in doctype right? right? :) |
| 15:57 | <takkaria> | jgraham: does the html5lib parse tree viewer use an up-to-date version of html5lib? |
| 16:04 | <jgraham> | takkaria: I think it's relatively up to date. It has the svn rev at the botom of the viewer page |
| 16:04 | <takkaria> | jgraham: ah, thanks |
| 16:21 | <JohnResig> | Lachy: I changed the suite to use null as the way to get the default prefix, made it so that doing querySelectorAll() (no arguments) only requires that an exception be thrown - not a particular one, I added some more default namespace tests, and added tests for disconnected DOM trees. Up to about 4200 tests now. |
| 16:42 | <tusho> | So using html5lib with Ruby, I want to do things with all tags h1-h6. |
| 16:42 | <tusho> | Preferably with the hpricot interface. |
| 16:42 | <tusho> | What's the simplest way? |
| 16:48 | <Lachy> | JohnResig_, yeah, I just saw your bugzilla comment about it. That's awesome |
| 16:49 | <weinig> | JohnResig_: thanks for fixing the test |
| 16:49 | <JohnResig_> | Lachy: it sounds like we're getting closer on our implementation - as is WebKit |
| 16:49 | <JohnResig_> | weinig: no problem, thanks for letting me know |
| 16:49 | <weinig> | np |
| 16:49 | <JohnResig_> | weinig: let me know if you spot any other weirdness/need help with test explanations |
| 16:49 | <weinig> | JohnResig_: will do |
| 16:53 | <Lachy> | wow, I think Bert Bos totally misunderstood the :context proposal http://lists.w3.org/Archives/Public/www-style/2008Jul/0214.html |
| 16:53 | <Lachy> | or at least the use cases it's trying to address |
| 16:53 | <weinig> | JohnResig_: I think I see one other issue |
| 16:53 | <weinig> | JohnResig_: xHTML|*#root3 xHTML|div svg *|circle is supposed to match circle1 as well |
| 16:54 | <weinig> | JohnResig_: since there is no default namespace provided by the resolver |
| 16:55 | <JohnResig_> | so you're saying that when no default namespace is provided "svg" becomes equivalent to "*|svg" |
| 16:55 | <JohnResig_> | sorry - when a resolver is provided - and no default namespace is given (returns null, undefined, etc.) |
| 16:55 | <tusho> | :\ |
| 16:56 | <weinig> | JohnResig_: yes |
| 16:56 | <jgraham> | tusho: Once you have a hpricot tree it should just work however hpricot normally works |
| 16:56 | weinig | checks the spec :) |
| 16:56 | JohnResig_ | does the same |
| 16:56 | <tusho> | jgraham: But I _can't get an hpricot tree_. |
| 16:56 | <tusho> | It gives me an array of Hpricot element objects. |
| 16:56 | <tusho> | That's not useful for just about anything. |
| 16:56 | <JohnResig_> | Lachy: thoughts on the above? |
| 16:57 | <jgraham> | Oh yeah I remeber now :) |
| 16:57 | <weinig> | To get the default namespace, if there was an NSResolver object provided, implementations must invoke the lookupNamespaceURI() method with null as the argument. If there is no NSResolver object provided, or if the method returns null, then there is no default namespace. Otherwise, the return value is the default namespace. |
| 16:57 | <weinig> | this is the case of the method returning null |
| 16:57 | <jgraham> | tusho: Er, well you want to talk to a ruby type really like kingryan |
| 16:57 | <JohnResig_> | interesting |
| 16:58 | <tusho> | jgraham: Well, I just asked to see if anyone knew :) |
| 16:58 | <weinig> | JohnResig_: since the method is actually returing undefined |
| 16:58 | <weinig> | JohnResig_: you have to take into account this sentance |
| 16:58 | <weinig> | "While resolving either a prefix or the default namespace, if the lookupNamespaceURI() method returns undefined or an empty string, the implementation must act as if null had been returned" |
| 16:58 | <JohnResig_> | so in all cases "svg" is equivalent to "*|svg" iff a resolver is provided that actually gives a default namespace response |
| 16:58 | <Lachy> | JohnResig_, yeah, "svg" is the same as "*|svg" when there is no default namespace |
| 16:58 | <JohnResig_> | ok! time to change some tests |
| 16:59 | <weinig> | reloads :D |
| 16:59 | <JohnResig_> | heh - eww... this will be tricky, considering that some tests will have different output |
| 16:59 | <JohnResig_> | ok, won't be a simple tweak |
| 17:01 | <JohnResig> | weinig: ok, it seems like t( "SVG", "xHTML|div svg *|circle", ["circle2","circle3"] ); is the only test that will be affected |
| 17:02 | <weinig> | JohnResig: yes |
| 17:05 | <tusho> | :\ |
| 17:12 | <jgraham> | tusho: Well sadly the best I can offer is a pointer in the direction of the code: http://code.google.com/p/html5lib/source/browse/trunk/ruby/lib/html5/treebuilders/hpricot.rb#220 is the line that gets called to get the object to return from .parse |
| 17:12 | <tusho> | ah, thanks |
| 17:13 | <tusho> | Beh, it does seem to use the hpricot element stuff. |
| 17:13 | <tusho> | Instead of the whole document. |
| 17:20 | <JohnResig> | weinig: ok - I think I've implemented it - it seems to be catching the right pass/fail in Opera, at least |
| 17:22 | <Lachy> | JohnResig, has anyone told Microsoft about your test suite? Did you get it to run in IE8? |
| 17:23 | <JohnResig> | Lachy: I can't get it to run in IE8 because it's served with the correct mimetype - it just tries to download it |
| 17:23 | <jgraham> | tusho: patches welcome I guess |
| 17:23 | <tusho> | indeed |
| 17:23 | <Lachy> | oh, ok. |
| 17:23 | jgraham | doesn't want to take reposnsibility if you break other people using ruby + hpricot |
| 17:23 | <Lachy> | Can you make an HTML only version without the namespace stuff for them to test with? |
| 17:24 | <Lachy> | and with additional tests to make sure they throw a NOT_SUPPORTED_ERR when an nsresolver is provided |
| 17:24 | <JohnResig> | have they said that that's what they're going to do? |
| 17:24 | <Lachy> | yes |
| 17:24 | <jgraham> | tusho: If you have an incompatible chnage to make I suggest you post to the mailing list first. If you have a compatible change I can check it in |
| 17:25 | <tusho> | it'd be quite complex to change jgraham |
| 17:25 | <jgraham> | (or give you commit access I guess) |
| 17:26 | <Lachy> | I don't think they support the namespace syntax either, so tests for "*|div" and "|div" will throw a SYNTAX_ERR, instead of automatically resolving even without an nsresolver |
| 17:26 | <JohnResig> | well, if they throw an exception, then it's a good bet that they'll fail all the tests that I provide |
| 17:26 | <Lachy> | sure, that's fine |
| 17:26 | <Lachy> | the spec actually requries full support for Selectors, so it's still a bug |
| 17:27 | <JohnResig> | yeah |
| 17:27 | <jgraham> | tusho: Well if you decide to pursue it let me kno and we'll work out a way to integrate the changes. The ruby port could really use some active maintainance :) |
| 17:27 | <tusho> | I will probably just serialize the tree after sanitization then run it through hpricot instead of combining it. :p |
| 17:27 | <tusho> | Ah, hacks! |
| 19:58 | <takkaria> | the SVG people weren't very clever with their tag naming |
| 19:58 | <takkaria> | "malignmark" sounds evil; why would I want that in my graphics? |
| 19:59 | <webben> | does sound like a hex doesn't it? ;) |
| 20:13 | <jgraham> | takkaria: How is your parser coming along? Is it close to usable yet? |
| 20:13 | <takkaria> | jgraham: I'm one test away from passing the html5lib tests |
| 20:14 | <takkaria> | so, probably fairly usable :) |
| 20:15 | <takkaria> | I'm currently fighting with scoping and the commented-out bits in the spec that deal with SVG |
| 20:18 | <jgraham> | cool |
| 20:18 | <jgraham> | I will have to take a look |
| 20:18 | jgraham | should find some time to work on html5lib as well |
| 20:19 | <takkaria> | I quite fancy doing some work on html5lib to learn python |
| 20:19 | <takkaria> | since I know html5-parsing fairly well know |
| 20:40 | <takkaria> | actually, the C html parser I've been working on is now passing all tests |
| 20:40 | <jgraham> | takkaria: Nice. Now if only I could get it to find libiconv :( |
| 20:44 | <takkaria> | jgraham: what OS are you using? |
| 20:44 | <jgraham> | OSX |
| 20:44 | <jgraham> | takkaria: Although I could probably find a linux box if that is likely to be easier |
| 20:44 | <jgraham> | s/find/log on to/ |
| 20:45 | <takkaria> | linux would be much easier, I think |
| 20:45 | <takkaria> | jmb (the other developer) has OS X, but I don't know what hoops he jumps through to compile |
| 20:46 | <takkaria> | I think tomorrow I'll take a break from coding and write up API docs |
| 20:48 | <jmb> | jgraham: depends where the problem is. if it's the test harnesses, then add -liconv to the LDFLAGS in test/Makefile |
| 20:50 | <jgraham> | jmb: Thanks, that helped a bit (I had added it in the wrong place apparently) now I get a different error :) |
| 20:51 | <jmb> | jgraham: feel free to pastebin it or somesuch :) |
| 20:53 | <jgraham> | jmb: http://pastebin.ca/1069420 (maybe I have an old version of the source? I used the "download tarball" link on the repo browser) |
| 20:54 | <jmb> | jgraham: aha. you'll need the json-c in trunk/json-c/json-c, too |
| 20:54 | <Philip`> | gsnedders: http://en.wikipedia.org/wiki/ISO_2145 is what I was thinking of |
| 20:54 | <jmb> | jgraham: there's a couple of patches we need to feed upstream (e.g. handling of \0 in input) |
| 20:56 | <takkaria> | jmb: have you emailed the fella about that? if not, might be worth setting up a google code project for it or something |
| 20:56 | <jgraham> | jmb: I put json-c 0.7 in json/json-c-0.7/ (and installed it) do I need to do something else, like change the directory names? |
| 20:56 | <jmb> | takkaria: no, I haven't. two reasons: a) laziness b) lack of response to the last set of patches I sent |
| 20:56 | <jgraham> | (and I applied the patches) |
| 20:58 | <takkaria> | jgraham: apply this patch too: http://source.netsurf-browser.org/trunk/json-c/json-c/json_object.c?r1=4383&r2=4385&view=patch |
| 20:58 | <takkaria> | actually, don't, that's just for one file |
| 20:58 | <jmb> | jgraham: the readme in hubbub/json is out of date. I need to fix that. please accept my apologies. if you build the version at svn://source.netsurf-browser.org/trunk/json-c/json-c, then you should have the stuff it needs |
| 20:59 | <jmb> | s/build/build and install/ |
| 21:04 | <jgraham> | jmb: That worked :) |
| 21:04 | <jmb> | jgraham: cool :) |
| 21:04 | <takkaria> | it's a shame the parser tests format doesn't have any comment syntax, it would help |
| 21:05 | <jgraham> | takkaria: Yeah. If hsivonen was here I would propose that we add one |
| 21:05 | jmb | runs off to find food |
| 21:05 | <takkaria> | jgraham: I'll send mail to whatwg-imps |
| 22:32 | <jgraham> | How is it that pretty much every single scientific journal I have used manages to create such an awful user experience for citations |
| 22:32 | <webben> | jgraham: talking about deadtree or online? |
| 22:33 | <jgraham> | webben: Journals that are primarilly deadtree but also have html versions |
| 22:33 | <webben> | lack of dedicated markup and UI I guess. |
| 22:33 | <jgraham> | (or primarilly PDF I guess) |
| 22:34 | <webben> | does Zotero help? |
| 22:34 | <jgraham> | webben: Given how bad they are at using the <a> element I don't see that more markup would improve the situation |
| 22:34 | <jgraham> | What is Zotero? |
| 22:34 | <webben> | http://www.zotero.org/ |
| 22:37 | <jgraham> | Yeah, that looks like it might be useful. Really I don't have complex needs; all I want is that when I come across an interesting-looking reference in an article I can get to the referenced article without having to search for it manually and/or have multiple popup windows, and without losing my place in the original article |
| 22:37 | <webben> | sure |
| 22:38 | <webben> | but browsers don't seem to have competed on the basis of what's useful for scholars. |
| 22:38 | <Philip`> | Browsers should have a 'back within current document' button, so you can scroll to the end and then jump back to where you were |
| 22:38 | <Philip`> | (It's pretty useful in KPDF) |
| 22:38 | <jgraham> | webben: I don't doubt that the browser could be better but the sites themselves are so so poor |
| 22:39 | <webben> | jgraham: Oh no disagreement. i've seen journal markup. it's dreadful. |
| 22:39 | <webben> | but it's also inconsistent from one journal to another, and dedicated markup /might/ have helped with that. |
| 22:41 | <webben> | Philip`: You mean rather than inserting fragments in the same history as pages? |
| 22:42 | <jgraham> | webben: Yeah, but even with what they have. I mean Wiley Interscience (which Monthly Notices of the Royal Astronomical Society just moved to) doesn't seem to have a link to the cited article _at all_ |
| 22:42 | <webben> | (Your typical modern Back button does let you jump back from fragments; it just doesn't let you jump back with one click to a previous page.) |
| 22:42 | <Philip`> | webben: I mean something like how browsers currently insert same-page fragments into the history, except for manual scrolling of the page (e.g. dragging the scrollbar or hitting the 'end' key) instead of clicking fragment links |
| 22:42 | <webben> | jgraham: has it got anything? like a doi? |
| 22:43 | <webben> | Philip`: I see what you mean. Interesting idea. |
| 22:44 | <webben> | a 'Step back to previous positions' button |
| 22:44 | <jgraham> | webben: Well it has the text and a link to something called SFX which doesn't seem to have anything in |
| 22:45 | <webben> | jgraham: http://www.exlibrisgroup.com/category/SFXOverview ... looks you need to have a library network with a SFX-based linking solution or something. |
| 22:45 | <webben> | jgraham: I guess the problem to be solved is dependent on your library, your route to an online version is different. |
| 22:45 | <webben> | (depending on whom your institution buys subscriptions from) |
| 22:46 | <Philip`> | Hixie: r1860 ("more typos") did what its commit message says and added more typos, particularly "insertUnrderedList" |
| 22:48 | <Hixie> | d'oh |
| 22:48 | <Hixie> | thanks |
| 22:48 | <jgraham> | webben: For astrophysics there is a NASA service called ADS which everyone uses for everything (it's smilar to PubMed I think). Anything else, especially anything that doesn't actually get me to the article, is not the right solution :) |
| 22:49 | webben | thinks doi works well. |
| 22:49 | <jgraham> | (the old MNRAS site linked to ADS in a way that was irritating in that it involved multiple popup windows but could be greasemonkied) |
| 22:50 | <webben> | well ... well enough |
| 22:50 | <jgraham> | webben: doi is just a numbering system right? |
| 22:50 | <webben> | jgraham: yeah, basically ; doi is a permanent digital object identifier ; |
| 22:51 | <webben> | jgraham: but it's human legible (can copy and paste it, or /print/ it, or scribble it down) and you can use it as a link by linking to a resolver. |
| 22:52 | <webben> | http://dx.doi.org/ |
| 22:52 | <webben> | or use a bookmarklet http://www.doi.org/resolver_button/doibutton.html |
| 22:55 | <jgraham> | webben: Right so the problem is that a) not all journals put the doi in text format (because it's not really any more human readable an an icq number for example) and b) copying and pasting is exactly what I'm trying to avoid. This is supposed to be hypertext and so the one thing I should be able to do is to link between resources |
| 22:55 | <webben> | jgraham: sure, every doi should be printed as a number and linked to a resolver |
| 22:56 | <webben> | ideally one would use the doi scheme I guess. |
| 22:57 | <webben> | doi:// whatever |
| 22:57 | <webben> | it's a question of whether it's more useful atm to just link to a resolver. |
| 22:59 | <webben> | jgraham: lots of tools can use them without copying/pasting: http://www.doi.org/tools.html |
| 23:00 | <jgraham> | webben: Well I can't imagine browsers ever supporting the doi scheme or researchers ever bothing to install extensions |
| 23:00 | webben | installed extensions as a student, so he easily can. |
| 23:02 | <webben> | also, if I was in the habit of patching browsers, it's probably a patch I'd submit. |
| 23:02 | <jgraham> | webben: Sure, I install extensions too. Indeed I even went so far as to write a custom extension for our research group and have it installed on all our systems But I can't see my supervisor installing an extension by himself |
| 23:03 | <webben> | that's old generation |
| 23:03 | <webben> | they don't get the interwebs |
| 23:03 | <webben> | hence ... failsome journal markup |
| 23:03 | <roc> | why wouldn't researchers install extensions? |
| 23:03 | <webben> | https://bugzilla.mozilla.org/show_bug.cgi?id=226648 |
| 23:04 | <roc> | university IT departments could preinstall them anyway |
| 23:04 | <webben> | (open bug to support DOI) |
| 23:04 | <jgraham> | roc: Because most of them are not power users |
| 23:04 | <roc> | ok |
| 23:04 | <roc> | but honestly extensions aren't just for power users anymore |
| 23:05 | <webben> | i think the researchers of the future are inevitably "power users" compared to the current generation |
| 23:05 | <jgraham> | The problem in this case is chicken/egg. Journals don't use doi:// links because no one could use them, no one bothers to install stuff to make them usable because they're not widely used |
| 23:05 | <webben> | jgraham: "journals don't use" ... actually lots do, from what I've seen. There may well be disciplinary gaps however. |
| 23:06 | <webben> | I found out about doi precisely because journals I was reading did use em |
| 23:06 | <annevk> | Hixie, postMessage v2 design looks good so far |
| 23:06 | <webben> | e.g. nature uses doi iirc |
| 23:06 | <jgraham> | roc: I'm not sure. Of the people in my office only the "power users" have extensions |
| 23:06 | <annevk> | Hixie, it addresses my concerns, anyway |
| 23:06 | <Hixie> | annevk: i haven't done anything yet :-) |
| 23:07 | <webben> | http://www.nature.com/bjc/journal/v99/n1/full/6604432a.html |
| 23:07 | <annevk> | Hixie, you're going to use a new section for the postMessage v2 method :) |
| 23:07 | <annevk> | or at least, a separate algorithm |
| 23:07 | <Philip`> | gsnedders: http://krijnhoetmer.nl/irc-logs/whatwg/20080711#l-478 |
| 23:07 | <Hixie> | i haven't worked out what to do with the postMessage(data, pipe, origin) case |
| 23:07 | <annevk> | oh ok |
| 23:07 | <Hixie> | but the Pipe stuff has its own section for sure |
| 23:08 | <Hixie> | i might just not specify postMessage(d,p,o) for a while |
| 23:08 | <Hixie> | until several postMessage()s ship, at least |
| 23:08 | <Hixie> | btw i changed eventsource a lot |
| 23:08 | <jgraham> | webben: That looks pretty good. Better than most journals I've encountered |
| 23:08 | <Hixie> | and websocket uses message now |
| 23:08 | <gsnedders> | Philip`: I guess I can do most of that |
| 23:09 | <webben> | jgraham: nature have a clue (not all the clues, but at least a clue ;) ) |
| 23:09 | <Philip`> | gsnedders: (found via http://lists.w3.org/Archives/Public/www-html-editor/2005JulSep/0003.html ) |
| 23:11 | <jgraham> | webben: The nature review article I want doesn't seem to have a HTML version at all (just PDF) |
| 23:11 | <gsnedders> | Now, do I bother keeping the pre-existing full-stop behaviour in w3c-compat? |
| 23:11 | <annevk> | Hixie, I noticed |
| 23:11 | <Hixie> | goo |
| 23:11 | <Hixie> | d |
| 23:11 | <annevk> | Hixie, though server sent events was already massively changed and we haven't updated yet |
| 23:11 | <jgraham> | and although it has the references online some are missing doi links and none have ADS links |
| 23:12 | <gsnedders> | Hixie, annevk, Lachy: thoughts on whether I should keep num as 1.2.4.5. in w3c-compat, or just always use 1.2.3.4.5 (per ISO 2145)? |
| 23:12 | <annevk> | I'm interested in other browsers showing some activity there first before taking a stab at it again |
| 23:12 | <gsnedders> | (i.e., do any of you care if that changes even in w3c-compat?) |
| 23:12 | <annevk> | (trying to get someone to update it, that is :) ) |
| 23:12 | <Hixie> | gsnedders: no opinion, just do whatever is prettiest. |
| 23:13 | <Philip`> | zcorpan: 2d.imageData.get.smallest was replaced with 2d.imageData.get.tiny (since the aim was to test the smallest non-zero source-rectangle) |
| 23:13 | <Hixie> | gsnedders: though for w3c-compat it should follow the pubrules document |
| 23:13 | <Hixie> | annevk: understood |
| 23:13 | <annevk> | gsnedders, depending on the spec, w3c-compat might be 2., but 2.3 |
| 23:13 | <annevk> | gsnedders, there's only a leading dot for the top level chapters |
| 23:13 | <gsnedders> | annevk: It's a dot after the final one for one level and for > 4 levels |
| 23:13 | <annevk> | I meant trailing |
| 23:14 | <gsnedders> | annevk: Once you get deep enough it comes back |
| 23:14 | <annevk> | I see |
| 23:14 | <gsnedders> | annevk: (see HTML 5) |
| 23:14 | <annevk> | ok |
| 23:14 | <Hixie> | that's fucked up |
| 23:14 | <annevk> | I don't think it matters though |
| 23:14 | <Lachy> | gsnedders, I'm not sure what exactly you're referring to? |
| 23:14 | <Hixie> | don't do that for non-w3c-compat :-) |
| 23:14 | <Philip`> | zcorpan: 2d.path.clip.unaffected should be using moveTo (thanks!) |
| 23:14 | <annevk> | pubrules doesn't require anything with regards to that |
| 23:14 | <gsnedders> | Hixie: Of course not — it breaks ISO 2145 anyway :P |
| 23:14 | <annevk> | (Bert actually changed the trailing dot stuff at some point) |
| 23:15 | <Hixie> | cool |
| 23:15 | <gsnedders> | ISO 2145:1978: Documentation -- Numbering of divisions and subdivisions in written documents |
| 23:15 | <gsnedders> | what a spec to have… |
| 23:16 | <Philip`> | Yours for only 34,00 CHF! |
| 23:16 | <Philip`> | s/34/36/ |
| 23:17 | <gsnedders> | Far less than ISO 8601, to be fair |
| 23:17 | <gsnedders> | (that was > 200 CHF last I looked) |
| 23:17 | <Philip`> | 126,00 now, apparently |
| 23:18 | <Philip`> | I wonder if they ever do BOGOF offers |
| 23:20 | <Lachy> | gsnedders, is the difference between the W3C numbering and ISO numbering only that the W3C includes the trailing full stop, and the ISO doesn't? |
| 23:20 | <gsnedders> | Lachy: yeah |
| 23:20 | <gsnedders> | Lachy: There is no W3C numbering per se — it's just what the CSS WG Postprocessor implements |
| 23:22 | <Lachy> | gsnedders, looking at the HTML5 spec, the use of the trailing . looks inconsistent |
| 23:23 | <gsnedders> | Lachy: there is a trailing full-stop character at the top level and at the fourth level and deeper |
| 23:23 | <gsnedders> | Lachy: That's the complexity of the rule |
| 23:23 | <Lachy> | yeah, why? |
| 23:23 | <gsnedders> | Lachy: Ask Bert Bos. |
| 23:23 | <Lachy> | that's silly. That's probably just a bug |
| 23:23 | <gsnedders> | It certainly changed quite noticeably. I highly doubt that., |
| 23:23 | <gsnedders> | s/,// |
| 23:24 | <Lachy> | when did it change? |
| 23:25 | <gsnedders> | Earlier this year? |
| 23:25 | <gsnedders> | Hixie, you remember? |
| 23:25 | <Hixie> | hm? |
| 23:25 | <Lachy> | looks like WF2 has all trailing dots |
| 23:25 | <gsnedders> | Hixie: when trailing full-stop in num changed? |
| 23:25 | <Hixie> | i don't pay attention to dots |
| 23:26 | <gsnedders> | You commented on it at the time, IIRC |
| 23:26 | <Philip`> | I remember it changed, and made one diff unexpectedly huge |
| 23:26 | <Lachy> | gsnedders, I really don't think it matters that much. It has to be a bug. Bert probably just made a change to the script and somehow managed to omit them |
| 23:27 | <annevk> | I think it was intentional |
| 23:27 | <Lachy> | annevk, why would it be? |
| 23:27 | <annevk> | but it doesn't matter |
| 23:27 | <annevk> | ask Bert |
| 23:27 | <jgraham> | Is there a reason not to pick the sane behaviour and go with it until someone complains? |
| 23:28 | <Lachy> | no-one will complain. I never even noticed it before gsnedders asked about it |
| 23:28 | <annevk> | othermaciej++ for pushing for ECMA exit criteria |
| 23:29 | <annevk> | Lachy, and the world centers around you, uhuh |
| 23:29 | <annevk> | ;) |
| 23:38 | <Philip`> | http://lists.whatwg.org/pipermail/commit-watchers-whatwg.org/2008/000397.html |
| 23:42 | <jgraham> | In case anyone was wondering which colour other people have paited the bikeshed, the LaTeX style I have to hand has no trailing dot |
| 23:42 | <jgraham> | painted |
| 23:44 | <othermaciej> | annevk: if you'd like to agree with me on the list feel free |
| 23:50 | <annevk> | done, though it seems one of the bigger players is already on board :) |