| 01:39 | <jamesr_`> | zewt: you consider macbooks to be 'mobile' instead of 'desktop'? |
| 03:02 | <Yuhong> | Interestingly, Acid3 itself renders differently in real IE7 and IE8 in IE7 standards mode. |
| 03:06 | <Yuhong> | Interestingly, Acid3 itself renders differently between real IE7 and IE8 in IE7 standards mode. |
| 03:09 | <Yuhong> | Using IE developer toolbar in IE7 with Acid3 open I was able to easily crash IE7 with a null pointer. |
| 05:31 | <slartsa> | odinho: thanks, but I don't understand what you mean |
| 07:42 | <zcorpan> | annevk: ok i reviewed https://critic.hoppipolla.co.uk/r/300 |
| 08:22 | <MikeSmith> | zcorpan: I don't find a definition of "whitespace" in http://dev.w3.org/csswg/mediaqueries4/ |
| 08:22 | <MikeSmith> | SimonSapin: ↑ |
| 08:22 | <zcorpan> | MikeSmith: look in css-syntax |
| 08:23 | <MikeSmith> | zcorpan: ok |
| 08:23 | <zcorpan> | but media queries should probably define its whitespace since they don't always come from a css file |
| 08:24 | <MikeSmith> | well it should also normatively reference some definition of whatever it means by it |
| 08:24 | <MikeSmith> | so I find http://dev.w3.org/csswg/css-syntax/#whitespace-diagram |
| 08:25 | <MikeSmith> | and http://dev.w3.org/csswg/css-syntax/#newline-diagram |
| 08:25 | <MikeSmith> | space, tabl |
| 08:25 | <MikeSmith> | oops |
| 08:25 | <MikeSmith> | space, tab, \n, \r\n, \r, \f |
| 08:26 | <MikeSmith> | zcorpan: which matches the definition in the HTML spec of whitespace, right? |
| 08:27 | <MikeSmith> | I find that the current media-queries checker in the validator doesn't allow \f |
| 08:27 | <MikeSmith> | oh wait |
| 08:27 | <MikeSmith> | http://dev.w3.org/csswg/css-syntax/#whitespace |
| 08:27 | <MikeSmith> | ah that's the same |
| 08:27 | <MikeSmith> | A newline, U+0009 CHARACTER TABULATION, or U+0020 SPACE. |
| 08:28 | <MikeSmith> | hmm, sorta |
| 08:28 | <MikeSmith> | http://dev.w3.org/csswg/css-syntax/#newline |
| 08:28 | <MikeSmith> | "U+000A LINE FEED. Note that U+000D CARRIAGE RETURN and U+000C FORM FEED are not included in this definition, as they are converted to U+000A LINE FEED during preprocessing." |
| 08:28 | <zcorpan> | question is what should happen with \f when the string comes from CSSOM |
| 08:28 | <zcorpan> | i'll file a bug on MQ |
| 08:29 | <MikeSmith> | OK |
| 08:29 | <zcorpan> | MQ currently refers to CSS21 for its grammar |
| 08:29 | <MikeSmith> | oh |
| 08:30 | <zcorpan> | S [ \t\r\n\f]+ |
| 08:31 | <zcorpan> | so i guess that makes it unambiguous |
| 08:31 | <MikeSmith> | yeah I like that a lot better actually |
| 08:35 | <zcorpan> | but this is something to keep in mind when css specs move to being defined in terms of css-syntax |
| 08:37 | <SimonSapin> | MikeSmith: I suppose it could link to http://www.w3.org/TR/CSS21/syndata.html#whitespace directly |
| 08:37 | <SimonSapin> | zcorpan: css-syntax-3’s pre-processing also applies to strings that come from CSSOM |
| 08:44 | <zcorpan> | SimonSapin: cssom refers to MQ for parsing a MQ, which in turn doesn't mention css-syntax, so that's not clear |
| 08:44 | <zcorpan> | we also have the case of HTML's media="" attribute |
| 08:45 | <zcorpan> | http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#matches-the-environment also refers directly to MQ |
| 08:50 | <SimonSapin> | zcorpan: I mean if you’re using the tokenizer as defined in Level 3, the pre-processing always applies |
| 08:50 | <zcorpan> | yeah sure |
| 09:15 | <tantek> | hober, FYI https://wiki.mozilla.org/Standards/license |
| 09:23 | <TabAtkins> | Lots of things refer to 2.1 for grammar right now, because Syntax is just now hitting WD. |
| 09:23 | <odinho> | slartsa: It works in Opera 12. The presto-based line of Opera :) |
| 09:23 | <TabAtkins> | But you should interpret everything as if it was using Syntax, because that's what we're actually basing it all on. |
| 09:24 | <MikeSmith> | TabAtkins: ok, good to know |
| 09:29 | <MikeSmith> | zcorpan: so I have a minor issue in trying to automate testing of the validator, which is that if I test for U+000c being handled as whitespace, then we emit a warning saying, "This document is not mappable to XML 1.0 without data loss due to U+000c which is not a legal XML 1.0 character." |
| 09:30 | <MikeSmith> | and I can suppress that by telling my test runner to ignore warnings, but then it ignores all warnings |
| 09:30 | <MikeSmith> | and the warnings are something I want to test for too |
| 09:32 | <hsivonen> | MikeSmith: this is checkin-needed right? https://bugzilla.mozilla.org/show_bug.cgi?id=910588 |
| 09:34 | <MikeSmith> | I guess we need to add another class of test case, "has warning", along with "not valid" (has error) and "valid" (has no errors) |
| 09:34 | <MikeSmith> | hsivonen: yes , checkin needed |
| 09:36 | <hsivonen> | MikeSmith: ok |
| 09:47 | <annevk> | "Some comments I made a long time ago:" points to message between April and June this year :-) |
| 09:52 | <MikeSmith> | hsivonen: I had realized that was going to affect View Source. I guess I should have noted it in the bug report. I wonder if there's anybody actually testing the View Source behavior. |
| 10:40 | <hsivonen> | MikeSmith: OK to use your hg user line for the generated C++ patch? |
| 10:42 | <MikeSmith> | hsivonen: yep, fine by me |
| 10:42 | <hsivonen> | MikeSmith: ok |
| 11:12 | <annevk> | Hmm, should URL.username and URL.password actually be settable? |
| 11:13 | <annevk> | abarth: ^^ |
| 11:18 | <annevk> | I guess it's fine |
| 11:23 | <zcorpan> | MikeSmith: maybe the validator could be configured to not whine about XML-mappability? |
| 11:29 | <MikeSmith> | zcorpan: I thought I already had the test runner configured that way, actually. So I'm not sure why I'm seeing them. |
| 11:31 | <MikeSmith> | anyway, I guess I will probably make the change to have the test runner recognize some files as being expected to cause warnings to be emitted intead of errors. Because it's useful to distinguish the diference. |
| 12:29 | <annevk> | TabAtkins: you should really get some more sleep ;) |
| 12:29 | <annevk> | TabAtkins: oooh wait, you're in Paris |
| 12:38 | <annevk> | TabAtkins: I'm running into that problem you always seem to run into, how do I use http://dev.w3.org/csswg/selectors/ to do what I need? |
| 12:38 | <annevk> | TabAtkins: :-) |
| 12:39 | <SimonSapin> | annevk: which problem is that? |
| 12:40 | <annevk> | SimonSapin: I have a string, what parsing algorithm do I pass it to to get a selector object out? The algorithm needs to return failures for unresolved namespaces and other parsing errors. |
| 12:41 | <annevk> | SimonSapin: The next step is then using that selector object to match against a set of nodes. It's not clear what algorithm to use for that either, although the spec does seem to suggest to use "scope-filtered selectors" in that in some way because of the example I just read... |
| 12:42 | <annevk> | SimonSapin: that next step also needs to take the context object into account and discard it if it's not an Element, I guess |
| 12:42 | <SimonSapin> | there is no explicit algorithms |
| 12:42 | <annevk> | SimonSapin: so I just need to monkey patch my way out of this mess? |
| 12:42 | <SimonSapin> | but the first step is parse per the grammar http://dev.w3.org/csswg/selectors/#grammar and check that the result is not invalid http://dev.w3.org/csswg/selectors/#invalid |
| 12:43 | <hsivonen> | MikeSmith: what OS do you deploy the Nu Validator on? |
| 12:43 | <hsivonen> | MikeSmith: do you deploy on Java 7? |
| 12:43 | <annevk> | SimonSapin: how does that deal with namespaces? |
| 12:44 | <annevk> | SimonSapin: and why is there no algorithm for parsing? that's kinda fundamental, no? |
| 12:44 | <annevk> | SimonSapin: we have lots of contexts that need selector parsing... |
| 12:45 | <SimonSapin> | there is a grammar |
| 12:45 | <annevk> | orly? |
| 12:46 | <SimonSapin> | http://dev.w3.org/csswg/selectors/#grammar |
| 12:46 | <annevk> | yeah you already gave that link |
| 12:46 | <SimonSapin> | yeah |
| 12:46 | <annevk> | Again, that's not parsing, doesn't return anything, doesn't describe what it means what you get back when you follow it, etc. |
| 12:46 | <annevk> | Doesn't deal with resolving namespaces |
| 12:47 | <SimonSapin> | yes, the "invalid" concept includes undeclared namespace prefixes |
| 12:47 | <annevk> | You can't say "grammar" and expect magic |
| 12:48 | <SimonSapin> | not everything has to be written in imperative style |
| 12:48 | <annevk> | SimonSapin: yes, but it doesn't define if the namespace prefixes need to be declared ahead of parse time or not, etc. |
| 12:48 | <annevk> | SimonSapin: but you need clear hooks between specs, I don't really care how you define what gets implemented as an algorithm |
| 12:49 | <annevk> | SimonSapin: but if you don't define an algorithm, you need to be clear on how things work |
| 12:49 | <annevk> | SimonSapin: you can't just say, "there a grammar" and there's rules for "invalid" and you can derive the parsing algorithm from that |
| 12:49 | <SimonSapin> | yes, this spec should have better-defined hooks for other specs |
| 12:50 | <SimonSapin> | beyond that, I don’t see what’s the problem |
| 12:50 | <annevk> | Well, does parsing a selector fail if namespaces are not (yet) declared? |
| 12:51 | <annevk> | I.e. does parsing need a map of namespace declarations, or is that an after the fact thing on top of the output. That affects the implementation and affects designs around selectors. |
| 12:51 | <SimonSapin> | http://dev.w3.org/csswg/selectors/#namespaces says that you need a (possibly empty) set of namespace prefix declarations |
| 12:51 | <annevk> | Yes, but it doesn't say when. |
| 12:53 | <SimonSapin> | that depends on what uses selectors. For stylesheets, http://www.w3.org/TR/css3-namespace/ defines that @namespace rules must be before style rules |
| 12:53 | <SimonSapin> | because having to go back and change the meaning of previous rules would suck |
| 12:53 | <annevk> | So you're saying the parse operation itself is independent of namespaces? |
| 12:53 | <SimonSapin> | Selectors APIs defines that the set is always empty, I believe |
| 12:54 | <SimonSapin> | in practice, you get namespace prefix declarations before parsing |
| 12:54 | <annevk> | Well that depends on what API I design |
| 12:54 | <annevk> | The specification doesn't seem to constrain me either way |
| 12:54 | <SimonSapin> | I mean http://www.w3.org/TR/selectors-api/ |
| 12:55 | <annevk> | I don't |
| 12:55 | <SimonSapin> | ok, so if you’re making a new thing that uses selectors, you need to define what ns declarations apply to any given selector |
| 12:55 | <annevk> | Again, I could do that after parse has completed it seems... |
| 12:55 | <annevk> | Because you don't define what parsing means, it's up to me |
| 12:56 | <annevk> | And I think that would be a problem for implementations, which is why I bring this up... |
| 12:57 | <SimonSapin> | well, if you want to separate the parsing into a concrete syntax tree per the grammar and then replace ns prefixes with URLs in a later step, you could do that |
| 12:57 | <SimonSapin> | I believe that’s an implementation detail |
| 12:58 | <annevk> | :-( |
| 12:58 | <SimonSapin> | there is no model of "what you get" after parsing a selector because they’re basically black boxes. On the platform you can only observe their string serialization |
| 12:58 | <annevk> | That sounds like really bad systems design. I wonder if TabAtkins agrees with this... |
| 12:59 | <SimonSapin> | we’re in the middle in the F2F and he’s talking about gradient interpolation, but I’ll point him to this later |
| 13:01 | <annevk> | If you define a syntax, whether the result object is a black box you can do things with or not, defining "parse X using namespace map Y" seems like a good thing to do. |
| 13:01 | <annevk> | And then you can ask the opaque object to query /tree/ using /scope/ or some such... |
| 13:01 | <SimonSapin> | ok, we could do that |
| 13:03 | <annevk> | We might even want to expose a Selector as a thing in script at some point I suppose... Hmm |
| 13:03 | <SimonSapin> | maybe |
| 13:03 | <SimonSapin> | for now all you get is .selectorText |
| 13:04 | <SimonSapin> | In my experience when implementing Selectors, the data structure you want to represent them varies *a lot* based on the matching strategy |
| 13:05 | <TabAtkins> | annevk: I can add algo hooks for converting string to selector, and matching selector against a set of nodes in a tree. |
| 13:05 | <annevk> | TabAtkins: sweet |
| 13:05 | <annevk> | SimonSapin: interesting |
| 13:05 | <annevk> | SimonSapin: I wasn't thinking of exposing the data structure anymore than an opaque Selector object, perhaps with serialization |
| 13:06 | <annevk> | SimonSapin: but if it depends on matching, that might not be good |
| 13:07 | <annevk> | TabAtkins: I'll add something to the DOM standard for querySelector / querySelectorAll for now and then you can fill in the boxes I leave open and then we patch 'm up |
| 13:07 | <TabAtkins> | Yeah, all you need is a "selector" thinger, no internal structure. That's perfectly fine to expose. |
| 13:08 | <hsivonen> | If I set up a new VM for running Validator.nu, which Ubuntu version should I use? The latest are the LTS? |
| 13:08 | <TabAtkins> | But there is still an internal structure insofar as it's a complex selector list or whatever. |
| 13:08 | <SimonSapin> | well, exposing a Selector object that does do anything but its serialization is not very useful |
| 13:08 | <hsivonen> | The canonical supported version of OpenJDK in the LTS 6. in the latest, it's 7. |
| 13:09 | <TabAtkins> | SimonSapin: It's used by the "match a selector against some nodes" algo that Anne will be doing |
| 13:09 | <SimonSapin> | TabAtkins: do you mean a spec concept, or a JS object? |
| 13:10 | <TabAtkins> | It's just convenient to have a spec concept for "selector" rather than having to cart around a string and constantly say "interpret as a selector...". |
| 13:10 | <TabAtkins> | Spec concept only. |
| 13:10 | <TabAtkins> | I suspect. |
| 13:10 | <TabAtkins> | annevk: ? |
| 13:10 | <SimonSapin> | then yes, +1 on spec concepts |
| 13:10 | <annevk> | TabAtkins: spec concept for sure, I was thinking maybe a JS object at some point |
| 13:11 | <TabAtkins> | Yeah, if you can find a use for it, I'm not against a JS object for it. |
| 13:11 | <annevk> | TabAtkins: we've had requests for that too, but if as SimonSapin says you want different data structures that might not be good to have |
| 13:11 | <SimonSapin> | requests for what exactly? |
| 13:11 | <MikeSmith> | hsivonen: w3c vnu backends I deploy on are all running java7 |
| 13:11 | <annevk> | TabAtkins: but yeah, for most specs with a syntax having string -> object and object -> string is nice :) |
| 13:12 | <annevk> | SimonSapin: compile a string into a selector and then use it; similar to regular expressions |
| 13:12 | <annevk> | SimonSapin: selector.test(node) or some such |
| 13:12 | <hsivonen> | MikeSmith: ok. thanks |
| 13:12 | <annevk> | SimonSapin: we're adding the opposite now, which is okay I suppose, but somewhat ugly |
| 13:12 | <annevk> | (node.matches()) |
| 13:12 | <SimonSapin> | annevk: if that JS object can be used in Selectors APIs, then yes it’s useful |
| 13:13 | <annevk> | Selectors API is going away |
| 13:14 | <SimonSapin> | uh, ok |
| 13:14 | <annevk> | SimonSapin: but what about your point about wanting to parse it into different structures depending on usage? |
| 13:14 | <SimonSapin> | or whatever its replacement is |
| 13:15 | <jgraham> | (I would totally prefer selector.matches(node) to node.matches(selector) fwiw) |
| 13:15 | <annevk> | jgraham: noted |
| 13:15 | <MikeSmith> | hsivonen: OS on all is Debian stable, 64 bit Intel |
| 13:15 | <jgraham> | Only for aesthetic reasons though |
| 13:15 | <annevk> | jgraham: depending on SimonSapin's answer to that question I might propose that on public-webapps |
| 13:16 | <SimonSapin> | annevk: if you want to expose the parts of a selector such as combinators, pseudo-classes, etc |
| 13:17 | <SimonSapin> | there are many ways to organize these in data structures |
| 13:17 | <annevk> | SimonSapin: the point is that if you parse it into an object, you lose context of what it might be used for |
| 13:17 | <hsivonen> | MikeSmith: OK. |
| 13:18 | <hsivonen> | MikeSmith: does Debian already have OpenJDK 7 as a system package? |
| 13:18 | <annevk> | SimonSapin: in particular, you remark was "In my experience when implementing Selectors, the data structure you want to represent them varies *a lot* based on the matching strategy" |
| 13:18 | <SimonSapin> | yes |
| 13:18 | <annevk> | SimonSapin: if you have a single object without context, it seems that is still a problem |
| 13:18 | <SimonSapin> | when adding an optimization to make matching faster, you may want to change the internal representation of selectors to make that easier |
| 13:19 | <jgraham> | But is "strategy" a constant for a given implementation? |
| 13:19 | <annevk> | SimonSapin: that's a different comment |
| 13:19 | <jgraham> | Or is it something that varies between e.g. CSS and qSA |
| 13:19 | <SimonSapin> | that’s a more specific example of what you quoted |
| 13:19 | <annevk> | *sigh* |
| 13:20 | <jgraham> | I think annevk is worried about the latter but not the former |
| 13:20 | <jgraham> | Or, maybe that's not a good example of the latter |
| 13:20 | <annevk> | Changing the data structure overall is indeed fine. That's why you have it as opaque object. |
| 13:20 | <SimonSapin> | ok, so we agree on that much |
| 13:21 | <annevk> | But if the data structure needs to be different between sel.matches(node) and sel.matchAgainst(tree), there's a problem |
| 13:21 | <annevk> | doh |
| 13:21 | <SimonSapin> | but then if that object is opaque, why is it useful? |
| 13:21 | <annevk> | SimonSapin: regular expression objects are opaque too... |
| 13:21 | <SimonSapin> | ok, you have a matching API on it |
| 13:21 | <SimonSapin> | I was missing that part |
| 13:22 | <jgraham> | So I think the idea is that it would be like re.compile in python |
| 13:22 | <jgraham> | var s = new Selector(".foo > bar") |
| 13:22 | <annevk> | Why else would you have an object... |
| 13:22 | <jgraham> | s.matches(node) |
| 13:23 | <jgraham> | -> bool |
| 13:25 | <MikeSmith> | I believe Debian does have Java 7 as a package, but not sure. I did not do the Java installs on those hosts. I think Yves did, so I'll ask him. |
| 13:25 | <SimonSapin> | so, yeah, a matching API with "pre-compiled" objects would be good |
| 13:26 | <SimonSapin> | though I don’t know how much it really affects performance in practice |
| 13:31 | <hsivonen> | MikeSmith: no need. I'll go with the latest non-LTS Ubuntu |
| 13:32 | <jgraham> | SimonSapin: Well it's not just a performance thing |
| 13:33 | <jgraham> | I quite like the idea of inverting the API so that instead of everything hanging off node you have a selector that you can run against various objects |
| 13:33 | <SimonSapin> | jgraham: what’s the difference with using strings, other than perf? |
| 13:33 | <jgraham> | Others probably disagree though |
| 13:33 | <jgraham> | SimonSapin: YOu can't have the API this way around and strings |
| 13:34 | <annevk> | Domenic_: you're now my default-cc for a bunch of things, I'm gonna assume you'll let me know when it gets annoying |
| 13:34 | <jgraham> | ".foo > bar".matches(node) seems like all kind of wrong |
| 13:34 | <hober> | zcorpan: does cssom view define when an element establishes a scrolling box? |
| 13:35 | <annevk> | jgraham: making selectors first-class citizens makes a lot of sense to me |
| 13:35 | <zcorpan> | hober: no. known bug |
| 13:35 | <hober> | ok, thanks |
| 13:35 | <annevk> | jgraham: it's also less work for me :) |
| 13:35 | <annevk> | hober: zcorpan: CSS ought to define that... |
| 13:36 | <annevk> | hober: zcorpan: CSSOM is just there to expose the properties of the box and manipulate it, not to define when it exists |
| 13:37 | <hober> | yeah, i don't really care where the definition is so long as there's one i can xref |
| 13:37 | <annevk> | hober: dude, you're on the CSS WG, it's your job to care, and I shouldn't have to :) |
| 13:38 | <SimonSapin> | jgraham: Selector("foo").match(node) vs. Selector.match("foo", node), meh. |
| 13:38 | <hober> | i mean, i do care from a "specs should be well organized" perspective, but i care less about that than that it gets written down somewhere. we can always move the definition to somewhere more appropriate |
| 13:38 | <Lachy> | I once had a proposal to be able to construct new slectors like that, though it was being considered for some other reason. |
| 13:43 | <hober> | zcorpan: looks like you can reference "flow root" in css-box |
| 13:43 | <zcorpan> | hober: ? i don't edit css-box |
| 13:44 | <zcorpan> | oh do you mean for scrolling box? |
| 13:44 | <hober> | zcorpan: i mean the term "scrolling box" in cssom-view can reference that |
| 13:44 | <zcorpan> | ah |
| 13:44 | <hober> | although it looks like the definition could use a lot of love |
| 13:45 | <zcorpan> | it's not clear that it's the same as scrolling box |
| 13:46 | <zcorpan> | float:left causes flow root but not scrolling box |
| 13:46 | <zcorpan> | you need overflow:auto or something |
| 13:52 | <annevk> | Lachy: time to chat for a bit? |
| 13:52 | <Lachy> | in a few minutes |
| 13:53 | <annevk> | Lachy: element.querySelector(): tree is element's node document, subject is element; document.querySelector(); tree is document, subject is document; documentfragment.querySelector(); tree is documentfragment, subject is documentfragment? |
| 13:55 | <annevk> | Lachy: and where I said subject, I meant scoping root |
| 13:56 | <zcorpan> | hober: http://dev.w3.org/csswg/css-box/#scrolling-mechanism looks closer |
| 13:59 | <annevk> | Actually, element's node document is wrong if element's ancestor is not document. |
| 14:00 | <annevk> | Ah yeah, you want element's root |
| 14:00 | <annevk> | And root also works for Document and DocumentFragment |
| 14:00 | <annevk> | brilliant |
| 14:14 | <hober> | zcorpan: yeah, that doesn't handle overflow:hidden (which can be scrolled by script but has no scrolling mechanism) |
| 14:15 | <zcorpan> | hober: good point |
| 14:15 | <Lachy> | annevk, I'm back |
| 14:16 | <zcorpan> | hober: so has overflow and either overflow:hidden or has a scrolling mechanism |
| 14:18 | <annevk> | Lachy: TabAtkins: http://dom.spec.whatwg.org/#evaluate-a-selectors-string |
| 14:18 | <annevk> | ms^^ |
| 14:19 | <annevk> | oh, meant that for Ms2ger, who is MIA |
| 14:24 | <annevk> | Lachy: also question, the idea with find/select is that instead of the tree being the context object's root, it's the context object itself, and the selector is a relative selector, right? |
| 14:27 | <Lachy> | tree is always the root element. It has to be since find can match elements anywhere in the document. Find basically just has an implied :scope that matches the context object. |
| 14:28 | <annevk> | oh okay, so tree is still the same, it's just that parsing is different? |
| 14:29 | <Lachy> | From memory, I think it works like this. element.find("+p") implies :scope+p |
| 14:30 | <Lachy> | yes, parsing is different. I will review what I'd written in here. I can take a look later tonight. I have to leave in about 2 minutes. https://github.com/lachlanhunt/dom/blob/master/dom-core.html |
| 14:31 | <annevk> | Lachy: it's fine I guess, I'll figure it out, seems like a few things are gonna change anyway per public-webapps discussion |
| 14:32 | <Lachy> | ok |
| 14:32 | <Lachy> | I should catch up with that stuff. Feel free to do whatever you think is best. |
| 14:32 | <annevk> | ta |
| 14:39 | <Lachy> | annevk, btw, the name select isn't usable. It clashes with an existing method. I'll check which one it is later. |
| 14:39 | <Lachy> | bye |
| 14:58 | <TabAtkins> | annevk: Difference between find and querySelector is solely: |
| 14:58 | <TabAtkins> | a) find allows relative selectors (starts with a combinator) |
| 14:58 | <annevk> | right, that's parsing |
| 14:59 | <annevk> | I'd appreciate review of http://dom.spec.whatwg.org/#evaluate-a-selectors-string btw |
| 14:59 | <TabAtkins> | b) find doesn't do any scoping, while qSA does scope-filtering. (But the effect of relative selectors means that it kinda looks like scoping.) |
| 14:59 | <annevk> | Ah interesting. And c) has a much better return value... |
| 15:00 | <TabAtkins> | Yes. |
| 15:00 | <TabAtkins> | And yeah, i'll review in a bit. I'm still minuting... |
| 15:00 | <annevk> | poor TabAtkins |
| 15:01 | <Domenic_> | ugh these stream proposals are getting out of hand |
| 15:02 | <annevk> | Domenic_: a decade ago someone would have just shipped something and we'd be stuck with that |
| 15:03 | <annevk> | Domenic_: count your blessings |
| 15:03 | <jgraham> | Now we will spend a year iterating the design, someone will just ship something, it will turn out to be crappy, and we will be stuck with that |
| 15:04 | <Domenic_> | annevk: was more a comment on quality than quantity, but yeah, i know what you mean |
| 15:04 | <Domenic_> | going to have to just take isaacs's proposed minimal API, slap one or two promise-returning sugar methods on top of it, and see how that goes over |
| 15:04 | <Domenic_> | will write up after i finish these damn jsconf eu slides |
| 15:04 | <annevk> | Man, everyone is going to Berlin? |
| 15:05 | <annevk> | Maybe next year... |
| 15:06 | <annevk> | darobin: for some reason your matchesSelector email doesn't show up in my inbox, I guess there's delayed delivery for you too :/ |
| 15:06 | <annevk> | darobin: but seems like there'd be transition cost either way |
| 15:06 | <darobin> | annevk: yeah, it seems there's some weirdness |
| 15:06 | <darobin> | oh I'm not against the idea, I think I like it — I was just pointing out that there are implementations |
| 15:07 | <Domenic_> | while it seems cool conceptually, i am not sure I would ever use a Selectors object... |
| 15:08 | <darobin> | Domenic_: hence my "I think I like it" |
| 15:08 | <darobin> | I'm still thinking about which contexts I'd actually use it in |
| 15:12 | <annevk> | If you wouldn't use that, would you use matches()? |
| 15:12 | <annevk> | They're identical, except one has less parsing over time... |
| 15:12 | <annevk> | And puts less cruft on Element |
| 15:12 | <Domenic_> | yeah I use the jQuery equivalent (.is) all the time |
| 15:14 | <Domenic_> | I meant, in a world where both were available, I can never see myself doing `(new Selectors("x")).matches(el)` over `el.matches("x")`, so I need to think of cases where caching the selector is important, and I can't think of any right now. |
| 15:14 | <annevk> | Yeah understood. Hmm... |
| 15:16 | <annevk> | .matches() takes relative selectors too? |
| 15:27 | <annevk> | So <input> has select(), but it doesn't take an argument... |
| 15:27 | <Domenic_> | oh boy :P |
| 15:27 | <Domenic_> | i humbly put forth query/queryAll, which are not as good, but no such issues i would hope |
| 15:28 | <annevk> | That might work |
| 15:36 | <Domenic_> | Hmm did the ascii-art get dropped from grid layout? |
| 15:50 | <TabAtkins> | Domenic_: No, of course not. Why would you think so? |
| 15:51 | <Domenic_> | TabAtkins: was reading some links tweeted by @CSSWG and saw a different syntax being used. Probably additive then, not instead of. |
| 15:51 | <TabAtkins> | Yeah, grid-template-areas is the ascii-art property. |
| 15:56 | darobin | wishes it were just called "ascii-art" |
| 17:05 | <gsnedders> | jgraham: Can you rebase r/287? |
| 17:05 | <gsnedders> | jgraham: Should be in-place to ca4041f2e005748559189af27c92c1db73e76159 |
| 17:08 | <gsnedders> | jgraham: Okay, managed to do the rebase, now can't enable tracking |
| 17:09 | <gsnedders> | jgraham: And now it's working again suddenly. Weird. |
| 17:37 | <mounir> | Domenic_: in 'promises-unwrapping', the .race() method in inspired by what? A+? previous DOM spec? |
| 17:38 | <mounir> | Domenic_: ... I wonder why it is designed to reject if one of the promises is rejected |
| 18:38 | <Hixie_> | http://larry.masinter.net/1307multipart-form-data.pdf https://www.w3.org/Bugs/Public/show_bug.cgi?id=16909#c8 |
| 21:28 | <Hixie_> | do we really still not have a cross-browser mousewheel story? |
| 21:28 | <zcorpan> | Hixie_: my chrome passes http://www.hixie.ch/tests/adhoc/dom/level0/window/security/001.html |
| 21:29 | <Hixie_> | zcorpan: yes? are we expecting otherwise? |
| 21:30 | <zcorpan> | Hixie_: you claimed otherwise in https://www.w3.org/Bugs/Public/show_bug.cgi?id=23218#c1 |
| 21:31 | <zcorpan> | oh the pass condition is backwards |
| 21:32 | <Hixie_> | that test is checking something else |
| 21:32 | <Hixie_> | my bad |
| 21:32 | <Hixie_> | i changed it after filign the bug |
| 21:32 | <Hixie_> | forgot i'd mentioned it in the bug |
| 21:32 | <zcorpan> | ok |
| 21:33 | <jgraham> | gsnedders: Yeah, I think the caching gets screwed up or something |
| 21:35 | <zewt> | Hixie_: it's not even interoperable across browser versions, heh |
| 21:39 | <zewt> | (iirc event.detail is the amount of the scroll, and since mousewheels snap to lines it's some constant N times the number of lines--but that constant isn't very constant) |
| 21:40 | <Hixie_> | wheelDelta, not detail, but yeah |
| 21:42 | <zewt> | it's event.detail somewhere, or at least I have code that tries both |
| 21:45 | <zewt> | oh yeah it's .detail on DOMMouseScroll (firefox), .wheelDelta on mousewheel (webkit) |
| 21:46 | <zewt> | and for added fun, not only are their scales completely different--their signs are opposite |
| 21:48 | <jgraham> | Just call it "natural scrolling" and sell it as a feature |
| 21:50 | <zewt> | zing |
| 23:31 | <Hixie_> | annevk: i'm confused by "fetch" step 7, the one that queues tasks. what are the tasks? are these the same as the tasks to process the data as it is downloaded from HTML? |
| 23:31 | <Hixie_> | are they fired for incomplete headers? just data? |