| 00:12 | <gsnedders> | Lachy: I now have <!--begin-link-->http://example.com<!--end-link-->; working |
| 00:14 | <Lachy> | is there some more abbreviated syntax you could use insted? Perhaps wiki style: [http://example.com/] |
| 00:14 | <Philip`> | I suggest <a href="http://example.com">; |
| 00:15 | <gsnedders> | Philip`: Heh. The entire point is to _AVOID_ that. |
| 00:15 | <gsnedders> | We want something to become the content of a link |
| 00:15 | <Lachy> | Philip`, we want to avoid using that because it's for the situations where the link text is the URL itself |
| 00:15 | <gsnedders> | i.e., that above example becomes <a href=http://example.com>http://example.com</a>; |
| 00:16 | <Philip`> | Ah, I can see how it's a terrible burden to have to copy-and-paste a bit of text onto the same line |
| 00:16 | <gsnedders> | Lachy: Is [DATE] a relative URL, or is it wanting the current date? |
| 00:16 | <Lachy> | maybe it would have to be [URL http://.../] |
| 00:18 | <Lachy> | gsnedders, it's just the current date |
| 00:18 | <Lachy> | that's why [URL ...] would work |
| 00:18 | <gsnedders> | Yeah, sure |
| 00:19 | <gsnedders> | I'd suggest [[]], but then we hit issues with biblio |
| 00:19 | <Lachy> | yep, that's why I didn't suggest it |
| 00:19 | <Lachy> | the W3C processor seems to accept random crap within "[DATE ... ]" |
| 00:20 | <gsnedders> | It needs a colon, does it not? |
| 00:20 | <gsnedders> | (at least it does if you believe the docs) |
| 00:20 | <Lachy> | dunno, will test |
| 00:20 | <Lachy> | no colon needed |
| 00:30 | <Hixie> | man, this preprocessor does way more than i use it for :-) |
| 00:31 | <gsnedders> | Yeah, you barely use it :) |
| 00:31 | <gsnedders> | It also does all kinds of stuff that people rely upon that aren't in the docs |
| 00:31 | <gsnedders> | like [LONGSTATUS] |
| 00:31 | <Hixie> | wtf is longstatus |
| 00:32 | <gsnedders> | "W3C Working Draft", for example |
| 00:32 | <Hixie> | i remember trying to use that stuff and it would never work |
| 00:32 | <Hixie> | i actually have to escape one of the stylesheet URLs to prevent it from screwing it up |
| 00:32 | <gsnedders> | (opposed to [STATUS] which would give "WD") |
| 00:32 | <gsnedders> | Hixie: Because it changes it? Yeah, it's weird. |
| 00:32 | <Hixie> | maybe that was before ED was supported |
| 00:33 | <Hixie> | anyway WHATWG drafts don't have that problem |
| 00:33 | <Hixie> | :-) |
| 00:33 | <gsnedders> | Hixie: I can tell you how it gets the status, after several hours of trying to work that out :P |
| 00:34 | <Hixie> | :-) |
| 00:34 | <gsnedders> | Hint: Everything the docs says about [STATUS] is wrong. |
| 00:34 | <Hixie> | i take it it is a completely different way than the way the pubrules checker gets it? |
| 00:34 | <Hixie> | there are docs? |
| 00:34 | <gsnedders> | dunno. Haven't tried :) |
| 00:35 | <gsnedders> | insofar as http://www.w3.org/Style/Group/css3-src/bin/README.html is a doc, yes |
| 00:35 | <Hixie> | oh hey what was it you wanted me to change in html5? |
| 00:35 | <gsnedders> | Not that I have a copy of that, obviously |
| 00:35 | <gsnedders> | Hixie: I can't remember. |
| 00:35 | <Hixie> | k |
| 00:35 | <gsnedders> | Hixie: We can try and work that out once it's done: run the spec through in w3c-compat and not, then diff it |
| 00:37 | <Hixie> | ok well just let me know when you know :-) |
| 00:37 | <gsnedders> | Hixie: Ah, it was that you rely on "setInterval(...)" being the same as "setInterval" for xref |
| 00:37 | <Hixie> | oh that's gonna be all over the place |
| 00:38 | <gsnedders> | I was guessing that :P |
| 00:38 | <gsnedders> | I don't like that behaviour, so it's w3c-compat only :D |
| 00:39 | <gsnedders> | Lachy: I could just check that [foo] was an absolute URL |
| 00:40 | <Hixie> | oh actually that doesn't happen as much as i expected |
| 00:40 | <gsnedders> | I can give you something that will show everywhere where it does :P |
| 00:40 | <Hixie> | fixed those i could find |
| 00:40 | <Hixie> | sure |
| 00:44 | <gsnedders> | Wow. that's a lot. |
| 00:46 | <gsnedders> | Actually, no, that's me being stupid. |
| 00:47 | <gsnedders> | http://pastebin.ca/1074875 — these are all the terms that are changed by the aggressive normalisation |
| 00:48 | <Lachy> | gsnedders, I don't mind how you do it. Just make it simple to use. |
| 00:50 | <gsnedders> | Hixie: cleartimeout and clearinterval and setinterval |
| 00:52 | <gsnedders> | Hixie: those are the only ones used in such a way that breaks without the normalisation |
| 00:55 | <gsnedders> | Hixie: Actually, no, that's still wrong |
| 01:00 | <gsnedders> | No, I think that's right. |
| 01:00 | gsnedders | shuts up |
| 01:00 | gsnedders | goes to sleep |
| 01:18 | <Hixie> | gsnedders: couldn't find any occurances of cleartimeout and clearinterval and setinterval that didn't have a title="" attribute |
| 01:35 | <Hixie> | i am minting URL_MISMATCH_ERR exception code 19 |
| 01:59 | <Hixie> | holy crap this is going to be complicated |
| 01:59 | <Hixie> | what happens if you create a worker, but the script takes a long time to download |
| 01:59 | <Hixie> | and in the meantime, the user has navigated the window |
| 02:00 | <Hixie> | but the user agent hasn't expired the document, merely suspended it and its global object and scripts in session history |
| 02:00 | <Hixie> | and then you go back |
| 02:16 | <Hixie> | heycam: yt? |
| 02:17 | <Hixie> | heycam: i got a problem with workes and webidl |
| 02:17 | <heycam> | hi Hixie |
| 02:17 | <Hixie> | heycam: WebIDL 4.3 Interfaces says "For every interface that is not declared with the [NoInterfaceObject] extended attribute, a corresponding property must exist on the ECMAScript global object whose name is the identifier of the interface." |
| 02:17 | <Hixie> | heycam: but now there are two types of global objects, those that implement WindowBrowsingContext and those that implement WindowWorker |
| 02:18 | <Hixie> | (and those that implement neither, e.g. as the global object of the script in <img src="javascript:...">) |
| 02:18 | <Hixie> | we need a way to say which global objects these things end up visible in |
| 02:19 | <heycam> | hmm, so you need to scope a bunch of IDL to cause interfaces to exist on a particular global object |
| 02:19 | <Hixie> | or multiple objects |
| 02:20 | <heycam> | pointer to the WindowBrowsingContext / WindowWorker stuff? |
| 02:20 | <Hixie> | e.g. new WebSocket() needs to be in both WindowWorker and WindowBrowsingContext global objects, but not the null global object |
| 02:20 | <Hixie> | http://www.whatwg.org/specs/web-workers/current-work/#windowworker and http://www.whatwg.org/specs/web-apps/current-work/#windowbrowsingcontext |
| 02:21 | <Hixie> | http://www.whatwg.org/specs/web-workers/current-work/#apis-available shows how this is getting complicated in other senses too |
| 02:22 | <Hixie> | i need to go get food, but i'll be back online later. feel free to mention any ideas you may have and i'll read them when i get back. |
| 02:22 | <heycam> | ok |
| 02:35 | <heycam> | Hixie, is the main case that interface objects should appear on all global objects? |
| 02:35 | <heycam> | i'm wondering whether putting [GlobalObject=<identifier-list>] on those you want to restrict would be too onerous |
| 02:36 | <heycam> | and then in your specs you'd say how those identifiers map to the different global objects you have |
| 05:52 | <MikeSmith> | "the Window object's browsing context's active document's effective script origin" is quite a mouthful |
| 05:54 | <MikeSmith> | though it conveniently forms a pronounceable acronym |
| 05:54 | <MikeSmith> | the WOBCADESO |
| 06:32 | <Hixie> | heycam: actually no, the common case is that the interfaces are only visible to global objects that implement WindowBrowsingContext |
| 06:33 | <Hixie> | pretty much nothing (only ECMA262-defined types) are visible to the "empty" global object, for instance |
| 06:33 | <heycam> | where's this empty one defined? i tried searching for "null global object" but didn't get anywhere. |
| 06:35 | <Hixie> | http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#script0 |
| 06:36 | <Hixie> | and http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#the-javascript paragraph 3 |
| 06:37 | <heycam> | so "script browsing context" means the global script object? |
| 06:38 | <Hixie> | there's an open bug on figuring out what it means exactly |
| 06:38 | <Hixie> | global objects are very complex |
| 06:38 | <Hixie> | since the global object has to change when you navigate, but there's only one Window object per window |
| 06:39 | <Hixie> | so you get pschyzophrenic code |
| 06:42 | <heycam> | so is it possible for script to be running, the page navigates to something else, but that same script is running, and its global object is now a different object? |
| 06:43 | <Hixie> | the global object is the same, but the 'window' attribute on that global object no longer points to the global object, even though the value it used to have is === the value that it had when it _was_ equal to the global object |
| 06:44 | <heycam> | ah, interesting |
| 06:44 | <heycam> | i never realised they could be different |
| 06:44 | <Hixie> | the web is a crazy crazy platform |
| 06:45 | <Hixie> | basically the Window object reflects the properties of the global object of the active document |
| 06:45 | <Hixie> | and you can never get a pointer to the actual global object |
| 06:45 | <Hixie> | as i understand it |
| 06:46 | <heycam> | huh? |
| 06:46 | <heycam> | so you don't consider the Window object to be the actual global object? |
| 06:48 | <Hixie> | well right now none of this is defined |
| 06:48 | <Hixie> | but yeah |
| 06:49 | <heycam> | that's kind of strange |
| 06:49 | <heycam> | i mean, always though the Window object was exactly the same object that 'this' refers to at the top level of your script |
| 06:49 | <heycam> | s/always though/i &t/ |
| 06:50 | <Hixie> | it is |
| 06:50 | <Hixie> | the 'this' is not the actual global object, it turns out |
| 06:50 | <Hixie> | but an object pretending to be it |
| 06:50 | <Hixie> | as i understand it |
| 06:51 | <heycam> | then i resign |
| 06:51 | <Hixie> | see also http://www.w3.org/Bugs/Public/show_bug.cgi?id=5850 |
| 06:51 | <heycam> | :) |
| 06:51 | <Hixie> | q.v. topic :-) |
| 06:55 | <heycam> | so html5 will says something like: "when you go to run a script, instead of evaluating it with the ecma-262 global object as the 'this' value, evaluate it with this strange Window object that mostly reflects the ecma-262 global object as the 'this' value"? |
| 06:56 | <Hixie> | dunno, haven't figured it out yet |
| 06:58 | <heycam> | let me know when you do :) |
| 06:58 | <heycam> | (well, i'll see the mails from the bug anyway) |
| 06:59 | <heycam> | then i'll think more about idl support for this stuff |
| 06:59 | heycam | out |
| 07:00 | <Hixie> | thanks |
| 07:00 | <Hixie> | later |
| 08:34 | <Lachy> | damn, Andrew is really quite annoying to deal with on www-style. He's so damn persistent, and fails to understand problems I clearly describe to him. |
| 08:35 | <Lachy> | though, unfortunately, he does have a point about the use cases. I can't think of any compelling ones that need to have a selector evaluated against the whole documet; only technical problems with what he needs, that need to be solved. |
| 08:41 | <Hixie> | what's the question? |
| 08:42 | <Lachy> | what question? |
| 08:44 | <Lachy> | this is the mail I was talking about http://lists.w3.org/Archives/Public/www-style/2008Jul/0419.html |
| 08:45 | <Hixie> | i mean, what's the thing you need a use case for? |
| 08:46 | <Hixie> | i don't read www-style these days unless html5 or acid3 is in the body :-) |
| 08:46 | <Hixie> | yay for keyword filtering |
| 08:47 | <Lachy> | oh, with the way querySelector() is defined div.querySelector("body p") would still match, even though body is an ancestor of the div. I need a use case for when that would actually be necessary, rather than just restricting all selectors to match descendants of the element itself. |
| 08:48 | <Lachy> | the solution that is actually needed is a way to say things like querySelector(">p");, but that requries changes to selector parsing and for an implicit :scope to be prepended to the beginning. |
| 08:49 | <Lachy> | and for querySelector("+p"); to work, it needs to match the element's siblings as well. |
| 08:51 | <Lachy> | if Andrew is right (which would be a huge surprise), I wonder if it's too late to change it now. |
| 08:55 | <gDashiva> | Regular querySelector evaluates against entire document and only returns matches inside scope, right? |
| 08:56 | <Lachy> | yes |
| 08:56 | <gDashiva> | If there's an implicit :scope in the scopedQuerySelector the result filtering wouldn't need to happen |
| 08:57 | <gDashiva> | Since it would limit itself to matching descendants and siblings anyhow |
| 08:57 | <Lachy> | yeah, the problem is how to get the implicit :scope there in cases like this: ">em, >strong" |
| 08:57 | <Lachy> | it's possible, I wrote up a proposed pre-parse algorithm to do it, but not sure how reliable it is in all cases yet |
| 08:57 | <gDashiva> | But assuming the parser manages to insert :scope properly, it's all in the green? |
| 08:58 | <Lachy> | the other issue is that querySelector is only defined to check its descendant elements. It would also need to be changed to check its sibling elements |
| 08:59 | <Lachy> | but they would only ever match in the case of :scope+p |
| 08:59 | <Lachy> | or ~p |
| 08:59 | <gDashiva> | Couldn't you just remove the restriction entirely? Surely when the browser itself prepends :scope it also knows where to avoid matching :) |
| 09:00 | <Lachy> | I guess it could just be left up to browser's own optimisations |
| 09:01 | <Lachy> | so then document.querySelector() and element.querySelector() would be handled very differently from each other. |
| 09:01 | <gDashiva> | Scope is applied in both cases. For regular querySelector it limits the return, for scoped querySelect it limits the match. |
| 09:01 | <gDashiva> | (Although it might be necessary to give them separate names, for clarity) |
| 09:02 | <Lachy> | gDashiva, but what are the use cases for keeping the current querySelector around? |
| 09:02 | <Lachy> | the only somewhat compelling reason I have at the moment is that implementations are getting ready to ship, and such a huge change could delay things |
| 09:03 | <Lachy> | though, perhaps that's not a huge problem, since IE8 is still only beta 1, Firefox 3 only just shipped and probably won't ship with support in a final product for months |
| 09:03 | <Lachy> | same for Opera |
| 09:04 | <Lachy> | dunno, will need to check with implementers and re-evaluate the whole situation |
| 09:04 | <gDashiva> | Hmm... the old one is the scoped one on document + filtering, since scoping to document on the match is no scoping. So it's document.scoedQuerySelector().removeNonDescendantOf(element). And the question is a use case for the filtering. |
| 09:05 | <Lachy> | what? |
| 09:05 | <gDashiva> | The old element.querySelector matches against the whole document, but only returns results inside the element's scope, right? |
| 09:06 | <Lachy> | it evaluates elements in the context of the whole document, but only returns descendant elements. So it doesn't bother checking for matches outside |
| 09:07 | <gDashiva> | True, using separate filtering would be a performance problem |
| 09:08 | <Hixie> | Lachy: the use case is going through a CSS style sheet and making sure you match all the nodes that the style sheet matches |
| 09:08 | <Hixie> | Lachy: or the use case is if you want to do something to <h2> elements that are inside <aside> elements, it doesn't matter if the <aside> is in the scope or not |
| 09:08 | <Lachy> | Hixie, when would anyone ever do that? |
| 09:09 | <Hixie> | Lachy: i'm not really sure when anyone would do any of this |
| 09:09 | <Lachy> | in that case, you could do document.querySelector("aside h2") |
| 09:09 | <Lachy> | which is the same problem I'm having. |
| 09:09 | <Hixie> | no i mean for the entire feature |
| 09:09 | <Hixie> | i don't know why people ever want to select multiple elements |
| 09:10 | <Lachy> | oh, well, people do it with JS libraries, so they must have a reason |
| 09:10 | <Hixie> | or do anything scoped |
| 09:10 | <Hixie> | so, look at those reasons |
| 09:10 | <Hixie> | you can't write a spec without knowing what the spec will be used for |
| 09:10 | <Lachy> | yeah, but those all work the way queryScopedSelector() would work, rather than how querySelector() works now. |
| 09:11 | <Hixie> | so i guess that's what we should have |
| 09:11 | <Lachy> | which is why I need to know if things should stay as they are, or be changed to match what Andrew, and what JohnResig had asked for earlier. |
| 09:11 | <gDashiva> | Lachy: Well, apart from some unquantified performance loss, you can emulate querySelector using queryScopedSelector and filtering |
| 09:12 | <gDashiva> | So the use cases would still be satisfied |
| 09:12 | <Hixie> | if everyone is asking for X, and you can't find any reasons for Y, then it seems likely X is the way to go |
| 09:12 | <Lachy> | I know. I just don't know if it's too late to change things |
| 09:12 | <Hixie> | why would it be too late? |
| 09:12 | <Lachy> | because back when all this was discussed previously, we didn't have solutions to the technical problems |
| 09:12 | <Hixie> | ? |
| 09:13 | <gDashiva> | The :scope prepending |
| 09:13 | <Lachy> | because implementers are already working on getting the current spec implemented and could be close to shipping. But if they're willing to change at this stage, it won't be too late |
| 09:13 | <Lachy> | I will write up a proposal for how it could be redefined and ask |
| 09:14 | <Hixie> | well you already have four methods, right? just add two more and be done with it |
| 09:14 | <Hixie> | it's trivial to define |
| 09:14 | <Hixie> | you just don't ever match any simple selectors on nodes outside the scope |
| 09:15 | <Lachy> | that simple approach doesn't solve the use cases though. That's described in solution 3 or 4 in http://lists.w3.org/Archives/Public/public-webapi/2008May/0057.html |
| 09:15 | <Hixie> | wait do you even have queryScopedSelector and queryScopedSelectorAll in the draft at all? i can't find them |
| 09:15 | <Lachy> | not yet |
| 09:16 | <Lachy> | we're just discussing whether to add them, or whether to redefine querySelector to be what they would have been |
| 09:17 | <Hixie> | well it can't be too late if they don't exist yet :-) |
| 09:17 | <Hixie> | oh i see, because you have the element and document ones on the same interface |
| 09:17 | <Lachy> | yes |
| 09:18 | <Hixie> | seems like for these use cases what you want is a non-scoped variant that sets the context node, actually |
| 09:18 | <Lachy> | what do you mean? |
| 09:19 | <Hixie> | someRandomElement.queryContextSelector(":context + p") |
| 09:19 | <Hixie> | matching someRandomElement.nextSibling if that's a <p> |
| 09:19 | <Hixie> | i.e. scope is Document, context node is someRandomElement |
| 09:20 | <Lachy> | oh, yeah, but to do what JS libraries do, we would need to make the :context (or :scope now) implicit |
| 09:20 | <Hixie> | screw that |
| 09:20 | <Hixie> | people can put in a pseudo-class, that's not a big deal. |
| 09:21 | <Hixie> | for a few versions the libraries can have a shim, they already have CSS parsers after all |
| 09:22 | <Lachy> | othermaciej argued that we should do it with implicit scope because: |
| 09:22 | <Lachy> | <othermaciej> Lachy: I think there are two reasons we may still want it: |
| 09:22 | <Lachy> | <othermaciej> 1) otherwise JS libraries have to do rewriting of their incoming |
| 09:22 | <Lachy> | selectors, which is both slower and more error-prone in JS code than in native |
| 09:22 | <Lachy> | code |
| 09:22 | <Lachy> | <othermaciej> 2) without a way to access those syntax features directly, it |
| 09:22 | <Lachy> | becomes harder for authors to ever switch off the library wrappers to the |
| 09:22 | <Lachy> | native version, even once all browsers support it |
| 09:23 | <Lachy> | currently, JQuery and other libraries have to change jquery(">div, >p") into ":scope>div, :scope>p" by themselves. The proposal is to make the browser to that in a standardised way |
| 09:24 | <Hixie> | the existing pages will keep using the existing libraries. new pages can use new libraries. it's not like there's a massive number of people who have existing code who will upgrade their libraries without upgrading their code to use new APIs in those libraries. |
| 09:24 | <Hixie> | so i call bs on othermaciej's reasons |
| 09:25 | <Lachy> | also, with your suggestion, would element.queryContextSelector("p"); only match descendant p elements, or all elements in the whole document? |
| 09:25 | <Hixie> | it would match the first <p> in the document |
| 09:25 | <Lachy> | that is unintuitive |
| 09:25 | <Hixie> | if you want the first in the subtree, use the filtered version (Element.querySelector()) |
| 09:25 | <Hixie> | it's queryContextSelector() because it's for using :context |
| 09:25 | <Lachy> | which is worse than we have now, and authors are already complaining we did it wrong |
| 09:27 | <Hixie> | i'd have six methods, two each of Document.querySelector, Element.querySelector, and Element.queryContextSelector, with those three being document-wide selector matching, with the second one being filtered to the element, and the last two having the element as the :context node |
| 09:27 | <Hixie> | that handles all the use cases pretty simply |
| 09:28 | <Hixie> | and doesn't require any silly breaking of Selector rules like scoping what simple selectors can match on |
| 09:28 | <Hixie> | nor redefining what selectors mean by adding pseudo-classes in or whatever |
| 09:30 | <Lachy> | so element.querySelector(":scope p"); would match the same as element.queryContextSelector(":scope p"); but they would differ in their handling of ":scope+p". Is that right? |
| 09:31 | <Hixie> | i wouldn't call it :scope if you do this, but yes |
| 09:31 | <Lachy> | queryContextSelector() might be more intuitive as document.querySelector(":scope p", contextNode); |
| 09:31 | <Hixie> | that would be fine too |
| 09:31 | <Hixie> | (i still wouldn't call it :scope though) |
| 09:31 | <Lachy> | fine, the name isn't important. |
| 09:33 | <Lachy> | so your proposal is to keep exactly what we have now and add queryContextSelector or equivalent. But that doesn't help me deal with the problems people are having with querySelector now. |
| 09:34 | <Hixie> | sure, just tell them to give a contextNode |
| 09:44 | <othermaciej> | Hixie: why is your rebuttal relevant to my reasons? |
| 09:45 | <othermaciej> | Hixie: both library authors and web developers appear to like the scoped semantics (in some case, to the degree of apoplectic rage at the suggestion of anything else) |
| 09:45 | <othermaciej> | I would call it queryScopedSelector not queryContextSelector btw |
| 09:45 | <Hixie> | for 1, because i'm saying there's no rewriting needed, and for 2, because i'm saying we should offer those features (albeit not with a compatible syntax). |
| 09:46 | <othermaciej> | "context selector" doesn't make sense |
| 09:46 | <Hixie> | it's not scoped |
| 09:46 | <othermaciej> | I guess it depends on what you mean by it |
| 09:46 | <Hixie> | if ":context + p" matches something, then clearly you're not scoped to :context |
| 09:46 | <Hixie> | since a node's sibling is outside the node |
| 09:46 | <Hixie> | this would become even more relevant with something like :has() or, worse, :matches(). |
| 09:47 | <othermaciej> | that's true, the + version would in fact be unscoped relative to the normal version |
| 09:47 | <othermaciej> | I hadn't imagined catering to the + exception |
| 09:47 | <Hixie> | it was in lachy's list of what people do/need |
| 09:47 | <Hixie> | if we're not worrying about what they need, then we should screw the whole scoped thing and keep the spec as is :-) |
| 09:48 | <othermaciej> | I recall from past discussions that people were less fervent about that than "div span" only matching if the div is the element queried on or inside it, and not if the whole thing happens to be contained in a div |
| 09:49 | <othermaciej> | (in fact I recall at least one JS library author conceding that "+ p" didn't entirely make sense) |
| 09:49 | <Lachy> | othermaciej, which JS author? |
| 09:50 | <Hixie> | if we give them "div:context span" then that use case is handled fine |
| 09:50 | <othermaciej> | I can't remember |
| 09:50 | <othermaciej> | Hixie: I am sure JS libraries will rewrite their current pseudo-selector syntax into that, and their clients will continue to just write "div span" |
| 09:51 | <Lachy> | Hixie, sure, :context as currently defined can handle every use case except the +p case. |
| 09:51 | <othermaciej> | incidentally "div:context span" would not mean the same thing |
| 09:51 | <othermaciej> | ":context div span" would |
| 09:51 | <Hixie> | othermaciej: why would they? |
| 09:52 | <othermaciej> | Hixie: at least some library authors have said they feel obligated to (and in some cases deeply enthusiastic about) maintaining their current syntax |
| 09:52 | <Hixie> | sure but that doesn't preclude them providing new APIs |
| 09:52 | <othermaciej> | presumably they are in touch with their clients |
| 09:52 | <Hixie> | basically the way i see it the current installed base pales in comparison to the future uses |
| 09:53 | <Hixie> | it's not like we're breaking back compat, we're just not making the back compat faster. |
| 09:53 | <othermaciej> | sure, but why not give them what they want? |
| 09:53 | <othermaciej> | is there a downside? |
| 09:53 | <Lachy> | Hixie, what future uses are we addressing by failing to directly meet their needs, instead of indirectly via :context as we are now? |
| 09:53 | <othermaciej> | one more method plus one more selector parser or preprocessor is not a big deal implementation-wise |
| 09:53 | <othermaciej> | the only reason not to do it as far as I can tell is a sense of purity |
| 09:54 | <Lachy> | othermaciej, should we keep querySelector() as defined, or just redefine it to what queryScopedSelector() would have been? |
| 09:54 | <Hixie> | what they want is a new selector syntax |
| 09:54 | <Lachy> | yes, which has been my argument against them till now |
| 09:54 | <Hixie> | that's a whole ton more speccing, developing, and testing work than what i think we want to do |
| 09:55 | <othermaciej> | Lachy: I think querySelector may already be used enough to preclude completely redefining it |
| 09:55 | <Hixie> | so that's the reason for not doing what they are asking for |
| 09:55 | <gsnedders> | Something is going oddly wrong in my spec-gen |
| 09:55 | <Hixie> | we can cater for the exact same use cases with a much cleaner mechanism |
| 09:55 | <othermaciej> | the cost seems low compared to the benefit of making them happy |
| 09:56 | <othermaciej> | and the cost will be borne mostly by Lachy and by implementors |
| 09:56 | <Hixie> | well, it's not me who has to pay the cost, so if you can get the css group to define a new syntax for selectors, along with creating a new test suite, and implementors are up for it, go for it |
| 09:57 | <Hixie> | personally i think that's a high cost for making people feel happy when we could address their same use cases in a much cleaner and simpler way that, once they realised it addressed their use cases, would likely make them just as happy |
| 09:57 | <Hixie> | (not to mention it's more powerful going forward) |
| 09:57 | <othermaciej> | if the new syntax is defined by translation to the canonical selector syntax then I see no need to involve the CSS WG |
| 09:57 | <Lachy> | Hixie, the proposed solution addresses it with a pre-parse that inserts :context (or whatever) in the appropriate places before parsing as a normal selector |
| 09:57 | <othermaciej> | I do like :scope/:context and I think it should probably be done first |
| 09:58 | <othermaciej> | that will give us more information on whether JS library authors or Web developers in general are inclined to switch |
| 09:58 | <Lachy> | othermaciej, can you respond to Andrew on www-style or public-webapps and help me explain to him why the current solution is good? |
| 09:58 | <gsnedders> | Ah! I've found teh bug! |
| 09:58 | Hixie | has a low opinion of specs that define things in terms of transforming one syntax into another |
| 09:58 | <Hixie> | seems like a hack to me |
| 09:59 | <Hixie> | but it's not my problem :-) |
| 09:59 | <Lachy> | Hixie, sure, it is a hack |
| 09:59 | <Hixie> | the platform has enough hackiness without adding more |
| 10:00 | <Hixie> | it's not like any sane implementor will actually implement it as a preparse |
| 10:00 | <Hixie> | parsing selectors is slow enough as it is |
| 10:00 | <Hixie> | without having to do it twice each time |
| 10:00 | <Hixie> | given that these methods are likely to be called in tight loops |
| 10:00 | <othermaciej> | I would guess parsing is a trivial fraction of the cost of querySelector |
| 10:00 | <Hixie> | so whether the csswg is involved or not, it's still a new syntax |
| 10:00 | <Lachy> | Hixie, the other solution was to slightly modify the grammar of selectors as described here http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0181.html |
| 10:00 | <othermaciej> | (that's a pretty well educated guess) |
| 10:01 | <Hixie> | othermaciej: on scoped trees with caching? i'm surprised. |
| 10:02 | <othermaciej> | Shark don't lie |
| 10:02 | <othermaciej> | we only use caching for the most trivial of selectors (otherwise maintaining correctness of the cache would be too complicated to be worth the benefit in the unlikely case that you redo the identical query on the same subtree) |
| 10:03 | <gsnedders> | teh webs are teh weirdness. |
| 10:10 | <gsnedders> | Hixie: I think title=">HTML documents" is a bug |
| 10:10 | <Hixie> | fixed |
| 10:12 | <gsnedders> | Hixie: http://pastebin.ca/1075314 — That's a diff of everything going from the aggressive normalisation to next to none |
| 10:12 | <gsnedders> | (obviously the top change isn't to do with that) |
| 10:16 | <Hixie> | fixed |
| 10:27 | <Hixie> | othermaciej: btw i ended up using "attach" instead of "join" -- but that's not much better. do you have any better ideas for terminology for what to call it when a new client registers with a worker? |
| 10:27 | <Hixie> | http://www.whatwg.org/specs/web-workers/current-work/ is mostly ready now, though it's missing some of the APIs it should have |
| 10:27 | <Hixie> | like database APIs |
| 10:53 | <MikeSmith> | Hixie: fwiw, "attach" doesn't seem so bad to me. |
| 10:53 | <MikeSmith> | since it's used in other ways to describe interactions with processes |
| 10:54 | <Hixie> | attaching to a thread somewhat implies a debugger actually monitoring the thread |
| 10:54 | <MikeSmith> | ah |
| 10:54 | <Hixie> | which is not what this is |
| 10:54 | <MikeSmith> | right, I see |
| 10:54 | <Hixie> | but in the absence of a better term... |
| 10:55 | <MikeSmith> | hmm, only other word I can think of is "tether", and that probably sucks more |
| 10:55 | <Hixie> | heh |
| 10:56 | <Hixie> | i used join, but joining a thread means waiting for it to complete, which isn't the same thing at all :-) |
| 10:56 | <Hixie> | so attach is a step in the right direction |
| 10:56 | <Hixie> | but merely a small step |
| 10:56 | <Philip`> | "connect"? |
| 10:57 | <Hixie> | could work |
| 10:58 | <MikeSmith> | hook, tie, bind, pin, fasten, harness |
| 10:58 | <MikeSmith> | and "hog tie" |
| 10:59 | <Hixie> | connect is winning so far |
| 11:00 | <Philip`> | "tether" |
| 11:01 | <Philip`> | "tractor beam" |
| 11:02 | <MikeSmith> | bear hug |
| 11:02 | <gDashiva> | assimilate |
| 11:03 | gDashiva | ponders <p><label>Text <input></p> |
| 11:04 | <othermaciej> | connect is best, since what you get back is a message port |
| 11:04 | <othermaciej> | connectToNamedWorker |
| 11:05 | <Hixie> | it's still createNamedWorker() for consistency with createWorker() |
| 11:05 | <Hixie> | the name 'connect' is the event name |
| 11:06 | <gDashiva> | How about assign? |
| 11:06 | <Hixie> | unless you think it should be connectToNamedWorker() and connectToWorker(), or connectToNamedWorker() and createWorker() ? |
| 11:07 | <Hixie> | why assign? |
| 11:08 | <gDashiva> | connect makes me think of connections and pipes and such |
| 11:08 | <Hixie> | well the message ports did used to be called pipes |
| 11:10 | <gDashiva> | But that's for inter-worker communication, isn't it? Not for task-to-worker |
| 11:14 | <Hixie> | i don't understand what you mean |
| 11:14 | <Hixie> | message ports are how any two things communicate |
| 11:14 | <Hixie> | whether they be in different workers, same worker, different frames, whatever |
| 11:17 | <gDashiva> | Just me being confused, then. |
| 11:19 | <gsnedders> | gDashiva: Like normal. |
| 11:20 | <gDashiva> | I should add it to my OKRs |
| 11:23 | <Hixie> | something else we could use <browserbutton> for is the ability to move a page into the background completely |
| 11:23 | <Hixie> | so e.g. you could hide google calendar and it could still be doing toast notifications of your events |
| 12:02 | gsnedders | wants a copy of ISO 2145 |
| 12:03 | <Hixie> | which is that one> |
| 12:03 | <Hixie> | ? |
| 12:04 | <gsnedders> | Hixie: numbering of divisions and subdivisions in written documents |
| 12:04 | <Hixie> | aah |
| 12:04 | <gsnedders> | It's an entire two pages long :P |
| 12:04 | <gsnedders> | And I bet the first is just the cover page. |
| 12:05 | <Hixie> | http://www.w3.org/mid/E906BBE0-6737-4C8D-9D7F-D3ADF99BFE5D⊙bc -- wouldn't it make more sense to just teach peopel to read? |
| 12:05 | <gsnedders> | Wikipedia claims to give the definition, but is it "can" or must it be? |
| 12:06 | <gsnedders> | Hixie: Peh! Standards are more fun than school anyway! |
| 12:06 | <gsnedders> | </sarcasm> |
| 12:06 | <Hixie> | ok, <browserbutton> or .makeStandalone() or whatever we decide to do is what i'm working on tomorrow |
| 12:08 | <gsnedders> | Lachy: I can't really get any other syntax that doesn't become really rather complex to parse |
| 12:08 | <gsnedders> | Lachy: [URL: http://exam<em>ple</em>.com] would be complete hell to parse |
| 12:09 | <jgraham> | Hixie: Why are workers JS only? And which version of JS? |
| 12:10 | <jgraham> | I presume ECMAScript 4 still requires an out of band indicator that the file is ECMAScript4? |
| 12:10 | <Hixie> | the js folk need to realise that out of band versioning is a bad idea |
| 12:11 | <Hixie> | anyway bed time |
| 12:11 | <gsnedders> | g'nite |
| 12:11 | <gsnedders> | I'll try and have nicer generated IDs by when you awaken |
| 12:12 | <Lachy> | gsnedders, just find /\[URL:?\s([^\])]\]/ |
| 12:12 | <jgraham> | Hixie: Sure, but I still don't understand why they are, in principle, JS only |
| 12:12 | <Lachy> | then escape special characters in the result |
| 12:12 | <gsnedders> | Lachy: That's hard when you have an XML document, and I don't want therefore to be a bozo |
| 12:13 | <jgraham> | (and it seems like trying to force the hand of the ECMA people this way is bad) |
| 12:13 | <Lachy> | oh, right |
| 12:13 | <Hixie> | jgraham: they're JS only because i didn't write the bit that says how to handle the content-type headers |
| 12:14 | <Lachy> | gsnedders, but no-one is going to put markup in the middle of a URL like this. Remember, it's not random stupid people using your tool, it's spec writers who at least have basic understanding of what they're doing. |
| 12:14 | <gsnedders> | Lachy: Robustness ftw. |
| 12:14 | <gsnedders> | :P |
| 12:14 | <Lachy> | so just require that the whole [URL: ...] this is in a single text node |
| 12:14 | <Lachy> | if it's not, output it as plain text |
| 12:14 | <gsnedders> | Yeah, I could do that |
| 12:14 | <Philip`> | Preprocess the document with regular expressions |
| 12:15 | <gsnedders> | Philip`: No. :P |
| 12:15 | <gDashiva> | Use sed |
| 12:15 | <Hixie> | just make people use <a href="...">...</a> |
| 12:15 | <Hixie> | require that the ... bits be equal, to confirm that they did actually intend it |
| 12:15 | <gsnedders> | Hixie: But people are lazy! |
| 12:15 | <Hixie> | if they're not equal, then just leave it unchanged |
| 12:15 | <gsnedders> | Hixie: huh? |
| 12:15 | <Philip`> | gsnedders: Lazy people don't write specs |
| 12:16 | <Hixie> | and if they're equal, then output <a href="...">...</a> |
| 12:16 | <gsnedders> | Philip`: No, we do, just slowly :) |
| 12:16 | <Hixie> | should be pretty easy to implement! |
| 12:16 | <Philip`> | gsnedders: That just means you're insufficiently lazy |
| 12:16 | <Lachy> | Hixie, there are other links in the spec where they shouldn't be equal, so how would you distinguish between those cases? |
| 12:16 | <gsnedders> | Hixie: So what? Just require an ellipsis in one place, or what do you mena? |
| 12:16 | <gsnedders> | *mean |
| 12:17 | Hixie | wishes lachy would fix http://www.w3.org/Bugs/Public/show_bug.cgi?id=5852 so it wasn't on his list :-) |
| 12:17 | <gDashiva> | I could picture a lazy person writing a spec because they're too lazy to implement themselves, but writing some text is okay |
| 12:17 | Hixie | is too lazy to fix his search query |
| 12:17 | <Hixie> | Lachy, gsnedders: i was saying "do nothing" basically |
| 12:17 | <Philip`> | Lachy: If the link text is equal to the href, then you treat it as the equal case; and if it isn't, you treat it as the unequal case |
| 12:17 | <gsnedders> | Hixie: ah :P |
| 12:17 | Hixie | just wants spec gen 1.2 :-P |
| 12:18 | <gsnedders> | :D |
| 12:18 | <Hixie> | look at all the big green thick underlines in http://whatwg.org/ww |
| 12:18 | <Lachy> | Hixie, we're trying to solve the cases where the URL is the same URL is used in both the href and link text to avoid the duplication. |
| 12:18 | <Hixie> | all of those would go away if i had 1.2! |
| 12:18 | <Hixie> | Lachy: i know, i'm just not convinced it's a problem :-) |
| 12:19 | <Lachy> | Hixie, it's just a minor problem when updating the header of the document where the Previous Version links are. When I copy and paste, I want to make it easier to avoid forgetting to change one of the links when I copy and paste |
| 12:19 | gsnedders | hugs Hixie. It'll be all right! |
| 12:20 | <Lachy> | I also wanted an easier, markup free syntax to make that whole spec header easier to fill out and generate |
| 12:20 | <Lachy> | but gsnedders said no to that |
| 12:20 | <Hixie> | heh |
| 12:20 | <gsnedders> | (because he's an asshole) |
| 12:20 | <Lachy> | gsnedders, who? me or you? |
| 12:20 | Hixie | spends very little time on the header of his specs |
| 12:20 | <gsnedders> | Lachy: Me :P |
| 12:21 | <Lachy> | ok, good |
| 12:21 | gsnedders | is listening to Look At Your Son Now by The F-Ups from The F-Ups |
| 12:21 | <Lachy> | maybe I could solve the problem by making a template generator where I can fill out that info in a form and have it all generated for me |
| 12:21 | <gsnedders> | I love how we're writing code so we can _then_ be lazy. |
| 12:22 | <gsnedders> | It'd probably be quicker to just not be lazy in the first place. |
| 12:22 | <Philip`> | Lachy: You could do it all with XSLT |
| 12:22 | <Lachy> | Hixie, re bug 5852, I suppose I could work on it. Any suggestions for how to mark it up and present it in a user friendly way? |
| 12:22 | <Lachy> | Philip`, I'd rather not do anything with XSLT |
| 12:23 | <Hixie> | Lachy: no idea |
| 12:23 | <Hixie> | Lachy: i generate the table automatically though |
| 12:23 | <Hixie> | Lachy: so something that does the same is probably best :-) |
| 12:23 | <Hixie> | anyway |
| 12:23 | <Lachy> | Hixie, I know. I already got the script to do that from you |
| 12:23 | <Hixie> | bed time now |
| 12:23 | <Hixie> | nn |
| 12:24 | <Philip`> | You should make the table user friendlier by deleting most of it |
| 12:24 | <Philip`> | (The full table just has too much data for anyone to ever make sense of) |
| 12:25 | <Philip`> | Approximately nobody uses MathML entities, so just get rid of them and tell people to use &#n; instead |
| 12:25 | <Philip`> | (*get rid of them in the author-oriented version of the table, even if they're still supported by UAs) |
| 12:25 | <gsnedders> | I thought we only needed to address 80% of use-cases, so why do we need them at all? |
| 12:26 | <richardigel> | hello! how good is the web forms 2.0 support of current browsers? |
| 12:27 | <Philip`> | richardigel: http://en.wikipedia.org/wiki/Comparison_of_layout_engines_(HTML_5)#Web_Forms_2.0 might be relevant and might be roughly correct |
| 12:30 | <richardigel> | Philip`: hmm. pretty much nothing is implemented. |
| 12:30 | <jgraham> | MathML entities are very useful if you are trying to enter maths |
| 12:31 | <gsnedders> | LaTeX ftw. |
| 12:32 | <Philip`> | jgraham: Why not just copy-and-paste the Unicode symbols directly? |
| 12:32 | <jgraham> | Philip`: For the same reason that's inconvenient when when entering LaTeX |
| 12:33 | <Philip`> | jgraham: It's inconvenient when entering LaTeX because LaTeX doesn't support Unicode properly, whereas HTML and HTML editors do |
| 12:34 | <jgraham> | \Phi is easier than finding gnome character map, typing ctrl+f (or whatever it is) entering capital phi copying the result switching back to the editor and pasting |
| 12:34 | <jgraham> | the unicode support of LaTeX has very little to do with it |
| 12:36 | <Philip`> | \Phi is not much easier than finding the place where you used Φ on the previous line of equation or a few paragraphs earlier and then copying-and-pasting it |
| 12:39 | <Lachy> | Omitting entity refs just because they're silly isn't an option. The intention is to cover everything that authors would ever need to know about HTML5, including all useless features |
| 12:39 | <jgraham> | Philip`: It really is |
| 12:40 | <gsnedders> | Philip`: You're just a silly comp.sci. student. Anyone who does real maths knows it is easier. |
| 12:40 | <jgraham> | Having to scan back through stuff breaks your concentration on what you're actually trying to do |
| 12:40 | <gsnedders> | (and that'll probably be my only comment today with my physics hat on) |
| 12:40 | <jgraham> | Which (in the case of Latex) is try not to end up with the wrong number of \lefts compared to your \rights |
| 12:41 | <Lachy> | This is really nice, but I don't want to just copy it http://www.digitalmediaminute.com/reference/entity/index.php |
| 12:41 | <Philip`> | Lachy: That seems a worse intention than trying to make something that is as useful as possible to authors (and hence has to be as easy to read as possible) |
| 12:42 | <Lachy> | Philip`, making it as thorough as possible and being useful and easy to read aren't mutually exclusive goals |
| 12:43 | <Philip`> | The HTML 5 spec already has everything authors could ever need to know, and is unreadable to authors because of it |
| 12:44 | Philip` | often uses the HTML 4 spec when trying to look up how some element works |
| 12:45 | <Philip`> | Lachy: But they are not absolutely compatible goals, so you'll have to make some tradeoffs between them |
| 12:45 | <Lachy> | the HTML5 spec is not very readable by authors because it's targetted at implementers |
| 12:46 | <Philip`> | Look at e.g. the <img alt> definition - that's targetted at authors, with lots of examples and stuff, and it covers everything in excruciating detail, and so no author is going to bother reading it all and if they do then they're not going to understand it all properly |
| 13:05 | <gsnedders> | Hmm, anyone got a clue why re.compile(u"[\U0001FFFF-\U0002FFFF]") causes an exception |
| 13:06 | <Philip`> | >>> import re |
| 13:06 | <Philip`> | >>> re.compile(u"[\U0001FFFF-\U0002FFFF]") |
| 13:06 | <Philip`> | <_sre.SRE_Pattern object at 0xb7c43640> |
| 13:21 | <gsnedders> | hmm. |
| 13:21 | <Philip`> | Maybe it causes an exception because you didn't import re? :-p |
| 13:22 | <gsnedders> | sre_constants.error: bad character range |
| 13:24 | <Philip`> | What version of Python? |
| 13:24 | <Philip`> | Is len(u"[\U0001FFFF-\U0002FFFF]") == 5? |
| 13:25 | <Philip`> | (Is it a UCS-2 build of Python?) |
| 13:25 | <Philip`> | etc |
| 13:26 | <gsnedders> | 2.5.1 |
| 13:26 | <gsnedders> | No, it isn't. len() = 7 |
| 13:30 | <Philip`> | That sounds like it's doing something silly |
| 13:30 | Philip` | has UCS-4 Python, and len() == 5 |
| 13:32 | <gDashiva> | Works in my 2.4.3, len=5 |
| 13:47 | <Lachy> | JohnResig, I've just got a few issues to sort out with selectors api |
| 13:48 | <Lachy> | I just gotta find the link... |
| 13:48 | <Lachy> | http://lists.w3.org/Archives/Public/www-style/2008Jul/0419.html and ... |
| 13:49 | <Lachy> | http://krijnhoetmer.nl/irc-logs/whatwg/20080718#l-225 |
| 13:50 | <Lachy> | basically, I need to sort out whether going with the more flexible :context/:scope was the right approach, and work out how to deal with the complaints |
| 13:51 | <Lachy> | skim the IRC logs to catch up first though |
| 13:53 | <Lachy> | the thing is, document.querySelector(":context+p", contextNode); would address all the use cases that JQuery handles, but it does require an explicit :context/:scope pseudo-class |
| 13:54 | <Lachy> | whereas, element.queryScopedSelector("+p"); which would be defined to imply :context at the beginning, and do a document wide search for all matching elements (which would be effectively limited to descendants and siblings anyway) |
| 13:55 | <Lachy> | the latter requires hacking the Selector parser in browsers, the former is easier to define and implement, but places a small burdon on authors/js libraries |
| 13:56 | <Lachy> | JohnResig, any thoughts? |
| 13:57 | <JohnResig> | Lachy: I'm reading through the log at the moment... |
| 13:57 | <Lachy> | ok |
| 13:57 | <JohnResig> | Lachy: I'm fine with the :root proposal, as well - just changing its meaning when it's within a context |
| 13:57 | <JohnResig> | taht may be easier to spec out? |
| 13:57 | <JohnResig> | *that |
| 13:59 | <Lachy> | there are problems with the :root proposal that I'm not comfortable with |
| 14:00 | <Lachy> | since it's defined to be the root of the document, and div.querySelector("body :root p") would then work, which is silly. |
| 14:00 | <Lachy> | but :context/:scope is the same as what people have asked to do with :root, just a different name. |
| 14:03 | <Philip`> | Lachy: The priority of constituencies says that spec writers and implementors should be burdened instead of authors, so that seems like an easy answer to your concern :-) |
| 14:03 | <Lachy> | hmm, if we had document.querySelector(":context+p", contextNode); then element.queryScopedSelector("+p"); could be defined to automatically imply :context and then behave as if the former had been called instead. |
| 14:03 | <Lachy> | Philip`, I know. |
| 14:04 | <JohnResig> | phew... this is a lot of logs - still reading |
| 14:04 | <Lachy> | Philip`, but I don't think adding an extra pseudo-class is that much of a problem |
| 14:05 | <Lachy> | wow, it went for over an hour :-) |
| 14:21 | <JohnResig> | Lachy: you keep mentioning a document.querySelector("...", contextNode) - I'm not sure where this is coming from |
| 14:22 | <Lachy> | JohnResig, it's just one of the possible solutions |
| 14:22 | <Lachy> | not specced yet |
| 14:23 | <Lachy> | it was originally mentioned as a possible alternative at the end of this email http://lists.w3.org/Archives/Public/public-webapi/2008May/0057.html |
| 14:23 | <Lachy> | and it is an alternative method to do what Hixie's proposed queryContextSelector() did. |
| 14:27 | <Lachy> | this is where it was first mentioned in the logs http://krijnhoetmer.nl/irc-logs/whatwg/20080718#l-329 |
| 14:36 | <JohnResig> | Lachy: it seems like there's two issues at play here |
| 14:37 | <JohnResig> | hmm, wait |
| 14:37 | <Lachy> | yeah, there could be a few |
| 14:39 | <Lachy> | the big issue is that I see both sides of the issue and I'm indecisive :-( |
| 15:24 | <Philip`> | Are there mail readers that handle deeply nested threads less stupidly than Thunderbird (which indents the subject line by more than the width of the column it's in, hence making it disappear entirely)? |
| 15:25 | <Lachy> | Philip`, Mail.app has a broken threading implementation that doesn't indent like Thunderbird. |
| 15:26 | <Lachy> | but it's threading is more like a list, just grouped together |
| 15:28 | <Philip`> | I have a thread with maybe two hundred messages, including big chunks that are mostly-independent forks from the main thread, and it'd be nice if those were handled sensibly instead of all being mushed together |
| 15:30 | <Lachy> | describe what you would consider sensible? |
| 15:32 | <Philip`> | Maybe it could let me select a certain message and say that I want it (and all its descendants) to be displayed as if they were a new thread, instead of being nested under its parent |
| 15:58 | <gsnedders> | Yeah, my build must be a UCS-2 of Python |
| 16:00 | <gsnedders> | or a UTF-16 one rather |
| 16:00 | <gsnedders> | hmm |
| 16:18 | <gsnedders> | <em<b>foo creates a different result in html5lib than it does in any browser, as far as I can see |
| 16:31 | <gsnedders> | Philip`: What do you get for len(u"\U0001FFFF")? |
| 16:33 | <Philip`> | gsnedders: 1 |
| 16:33 | <gsnedders> | Philip`: Yeah, it's a UTF-16 copy I have |
| 16:43 | <MikeSmith> | Philip`: mutt |
| 19:22 | <gsnedders> | Does anyone care enough about the postprocessor's stupid ID generation enough to want me to copy it? |
| 19:22 | <gsnedders> | (in w3c-compat, at least) |
| 19:33 | <Dashiva> | If you care enough to make a compat mode, it should be compatible |
| 19:44 | <gsnedders> | Dashiva: It never will be completely compatible, because what I do is too logical. |
| 19:44 | <gsnedders> | Dashiva: It just needs to be compatible enough in the real world |
| 19:44 | <gsnedders> | And as with the postprocessor the IDs change half the time because the ID gen is so bad… |
| 19:53 | <gsnedders> | /text()[contains(normalize-space(translate(., 'AEILNORSTV', 'aeilnorstv')), 'latest version') or contains(., 'http://www.w3.org/TR/';)] — lovely xpath! |
| 19:58 | <Dashiva> | Isn't there a lower()? |
| 19:59 | <gsnedders> | Nope. |
| 19:59 | <gsnedders> | In XPath 2.0 there is lower-case, but next to nothing actually implements 2.0 |
| 19:59 | <Dashiva> | How wonderful |
| 19:59 | <gsnedders> | Yeah, it really is. |
| 20:00 | <gsnedders> | But when dealing with something as large as HTML 5, it tends to be quicker if you can get away with a single XPath statement than doing a whole iter of the tree |
| 20:00 | <gsnedders> | Especially when looking at text nodes |
| 20:01 | <Dashiva> | Gee. No case changing, but they have starts-with, substring-before and substring-after |
| 20:01 | <jcranmer> | XPath is so wonderful, it's a shame that more people don't implement more of it |
| 20:02 | <jcranmer> | although the spec could be made a little easier to digest for people trying to use it |
| 20:02 | <gsnedders> | Yeah, the spec is rather horrible |
| 20:03 | <gsnedders> | You have to be careful how much you use it when performance matters though |
| 20:03 | <jcranmer> | it's more useful (IMHO) than SAX or DOM when you're trying to scrape information from something with varying structure |
| 20:04 | <gsnedders> | Easier? I'd say so. Useful? No more so. |
| 20:05 | <Dashiva> | More convenient, but not really easier than DOM |
| 20:05 | <jcranmer> | Dashiva: what if you have something that can either be a dl, ul, ol, or table? |
| 20:06 | <Dashiva> | That's the convenient part |
| 20:06 | <jcranmer> | or, to be more precise, a specific row or item of any of those |
| 20:06 | <Dashiva> | tableref.rows[i].cols[j] |
| 20:06 | <Dashiva> | *cells |
| 20:06 | <jcranmer> | yes, but I have to store whether or not I'm querying the list or table |
| 20:07 | <Dashiva> | Yes, we already agreed it's more convenient with xpath |
| 20:08 | <Dashiva> | But the basic DOM functions are lot easier to learn than all the xpath incantations |
| 20:08 | <jcranmer> | I have to use a reference either way, but I guess I don't do enough HTML/XML-based development to matter |
| 20:09 | <gsnedders> | http://hg.gsnedders.com/spec-gen/file/tip/specGen/processes/sub.py#l101 — yay :\ |
| 20:09 | <gsnedders> | I'm probably better at dealing with XPath, but mainly because I don't use the DOM much at all |
| 20:22 | <gsnedders> | WTH is the point of <!--status-->? |
| 20:23 | <gsnedders> | It only outputs anything apart from "[Sorry, the postprocessor doesn't yet have the boilerplate text for this status]" when the status is ED. |
| 20:23 | <gsnedders> | Lachy, Hixie? |
| 20:28 | <Lachy> | gsnedders |
| 20:28 | <gsnedders> | Yes, that's me |
| 20:28 | <Lachy> | you called? |
| 20:28 | <gsnedders> | See the above question |
| 20:29 | <Lachy> | hmm, let me see... |
| 20:29 | <takkaria> | Philip`: how did you go about obtaining your corpus of dmoz data? did you write a script to download the files, and if so, any chance I could have it? (for performance benchmarking reasons) |
| 20:32 | <gsnedders> | It seems to be the same thing in every status apart from ED de-facto anyway |
| 20:33 | <gsnedders> | I dunno if MOs are the same, as I can't see any, though |
| 20:34 | <Lachy> | gsnedders, I get "This is a public copy of the editors' draft. It is provided for discussion only and may change at any moment. It probably contains errors. Its publication here does not imply endorsement of its contents by W3C" |
| 20:34 | <gsnedders> | Lachy: Yeah, that's what I get. It's just that no other status gives anything (apart from the note that there is no boilerplate text) |
| 20:35 | <Lachy> | oh, ok. let me try other ones... |
| 20:35 | gsnedders | has already tried them all |
| 20:35 | <Lachy> | ok |
| 20:36 | <gsnedders> | Lachy: What use is it when it doesn't give anything normally? |
| 20:36 | <gsnedders> | That's what I want to know. |
| 20:36 | <Lachy> | it's probably because other statuses need custom status text |
| 20:36 | <gsnedders> | They don't. They all always have the same. |
| 20:36 | <gsnedders> | This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/. |
| 20:39 | <smedero> | for whatever reason the geo api spec differs, but not by much.... |
| 20:39 | <smedero> | "This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the most recently formally published revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/."; |
| 20:40 | <smedero> | "recently formally published" |
| 20:40 | <smedero> | http://dev.w3.org/geo/api/spec-source.html |
| 20:40 | <gsnedders> | Ahah! |
| 20:41 | <gsnedders> | You get status text if you set the WG to "CSS WG" |
| 20:41 | gsnedders | refuses to copy that |
| 20:42 | <gsnedders> | I am _NOT_ adding WG specific stuff. |
| 20:43 | <Lachy> | gsnedders, have you checked the pubrules document to find out the requirements? |
| 20:48 | <gsnedders> | Lachy: It changes for almost every status, and I don't want to do any more than the postprocessor does here. I'm not adding any W3C specific stuff without good reason |
| 20:52 | <Lachy> | gsnedders, if it's boiler plate text that is standard for each status level, then it should be included to make it easier for spec writers |
| 20:52 | <gsnedders> | Lachy: But it's non-backwards-compatible |
| 20:52 | <Lachy> | what do you mean? |
| 20:53 | <gsnedders> | Lachy: Documents designed for the postprocessor have it in them themselves |
| 20:53 | <Lachy> | so? Documents designed for the post processor also typically omit <!--status-->, and if that isn't there, then don't include it. |
| 20:54 | <gsnedders> | Lachy: it ought to be compatible in the compat. mode, within reason, so I can't do that. |
| 20:55 | <Lachy> | sure you can. |
| 20:55 | <Lachy> | I don't see how updating a feature that wasn't properly implemented in the old processor will break anything. |
| 21:15 | <Philip`> | takkaria: I just downloaded dmoz's RDF site listing, used Perl regexps to extract the URLs and to s/&/&/ etc, then passed it through 'sort' and 'uniq', and then 'sort -R' to randomise it, and then took the first n from that list |
| 21:16 | <Philip`> | takkaria: and then used a Java program to download and analyse the pages (using HttpClient, and around a hundred simultaneous threads) |
| 21:17 | <Philip`> | takkaria: and the Java program cached the downloaded headers/content to disk so it wouldn't have to download them when I ran it a second time |
| 21:18 | <Philip`> | takkaria: I could upload the Java thing somewhere, but it's big and ugly, and if you just want a collection of page bodies then it'd probably be easier to just pass the page list into wget or curl |
| 21:19 | Philip` | goes away for a bit |
| 21:20 | <Philip`> | (Oh, I also limited the downloads to something like 256K per page, because there was at least one infinitely long radio stream and I didn't want all of it) |
| 21:20 | <Philip`> | *256KB |
| 21:20 | <smedero> | heh |
| 21:27 | gsnedders | implements something he really doesn't want to |
| 21:32 | <gsnedders> | http://hg.gsnedders.com/spec-gen/rev/f10347e98d3c |
| 21:35 | <gsnedders> | time to upload a few files from the latest spec-gen |
| 21:37 | <gsnedders> | http://stuff.gsnedders.com/spec-gen/ — find bugs in those files, plz. |
| 21:39 | <takkaria> | Philip`: ah, thanks. I'll just grab the RDF and curl it |
| 21:41 | gsnedders | is tempted to add a --w3c-compat-crazy-subsitutions option |
| 21:43 | <Lachy> | gsnedders, for which features? |
| 21:43 | <gsnedders> | Lachy: rewriting http://www.w3.org/StyleSheets/TR/W3C-(MO|ED|WD|CR|PR|REC|PER|NOTE|RSCND|Member-SUBM) |
| 21:49 | <MikeSmith> | gsnedders: fwiw, I don't like the automated ID generation |
| 21:49 | <MikeSmith> | I don't like the fact that the IDs can change |
| 21:50 | <gsnedders> | MikeSmith: in the existing postprocessor? |
| 21:50 | <MikeSmith> | I mean in general |
| 21:50 | <MikeSmith> | It doesn't seem like much of hardship to me for editors to manually maintain IDs |
| 21:52 | <gsnedders> | MikeSmith: ah |
| 21:53 | <MikeSmith> | having stable IDs is a much more valuable feature in a spec |
| 21:53 | <MikeSmith> | the ID-generation feature is the wrong kind of optimization |
| 21:54 | <takkaria> | I guess that isssue only shows up when the spec is going to take a long time to finish and is being written in public |
| 21:54 | <MikeSmith> | of marginal and questionable value to editors, of zero value to readers and other consumers of the doc |
| 21:55 | <MikeSmith> | takkaria: true |
| 21:57 | <Hixie> | i don't want the ids in the source document if i can help it, but i'm certainly in agreement in principle and would love to see the generator keep state or something to not change IDs |
| 21:58 | <Hixie> | generally if you use the title="" attribute to generate the IDs you should be fine i think |
| 21:59 | <gsnedders> | (which the postprocessor doesn't) |
| 21:59 | <Hixie> | i don't mind if the IDs change as a one time thing when we're switching generators |
| 22:00 | <Hixie> | if that means more stability going forward |
| 22:02 | <gsnedders> | Yeah, the way I generate IDs should be far more stable |
| 22:02 | <Hixie> | how do you do it? |
| 22:04 | <gsnedders> | from @title or the textContent, lowercase it, strip leading/trailing whitespace, replace internal whitespace with - |
| 22:05 | <gsnedders> | (the postprocessor does all kinds of crazy stuff, but basically stops after it gets to the first space after taking five characters) |
| 22:05 | <gsnedders> | and a longer ID should make it more stable |
| 22:06 | <Hixie> | cool |
| 22:14 | gsnedders | never knew ID gen could be cool |
| 22:14 | <Hixie> | i'm not a good benchmark for determining objective coolness. |
| 22:16 | <Philip`> | I hate the crunching noise made by interaction of shoe and snail |
| 22:17 | <Philip`> | If you can create a file mapping from old IDs to new IDs, it could be added into the multipage spec's magical redirection thingy so that old links get redirected to the right place |
| 22:18 | <Hixie> | good idea |
| 22:18 | <takkaria> | Hixie: oh, btw, any chance of getting the tokeniser states upgraded to TOC-visible headers? would make linking to states easier |
| 22:21 | <Hixie> | file a bug |
| 22:21 | <takkaria> | k |
| 22:21 | <Hixie> | or send e-mail if it's not urgent |
| 22:21 | <Hixie> | either way |
| 22:23 | <kangax> | html tidy complains that canvas tag is not recognized |
| 22:24 | <kangax> | interesting... |
| 22:25 | <Philip`> | kangax: I expect it only understands elements from HTML4, so it won't include any HTML5 ones like <canvas> |
| 22:25 | <kangax> | that makes sense |