| 00:46 | <zewt> | do browsers ever actually encode *to* legacy encodings? (eg. does the encoding spec actually need to spec all that) |
| 00:46 | <zewt> | do browsers ever actually encode *to* legacy encodings? (eg. does the encoding spec actually need to spec all that) |
| 00:56 | <TabAtkins> | No. No they don't. |
| 00:56 | <TabAtkins> | No. No they don't. |
| 00:58 | smaug____ | had forgotten how horrible insertAdjacentHTML is |
| 00:59 | smaug____ | had forgotten how horrible insertAdjacentHTML is |
| 01:19 | <sicking> | smaug____: horrible in what way? |
| 01:19 | <sicking> | smaug____: horrible in what way? |
| 01:20 | <sicking> | hmm.. shouldn't it throw HIERARCHY_ERROR rather than NO_MODIFICATION_ALLOWED? |
| 01:20 | <sicking> | hmm.. shouldn't it throw HIERARCHY_ERROR rather than NO_MODIFICATION_ALLOWED? |
| 01:23 | <sicking> | oh, and it's case insensitive :( |
| 01:23 | <sicking> | oh, and it's case insensitive :( |
| 02:23 | <Hixie> | TabAtkins, zewt: form submission? |
| 02:24 | <Hixie> | TabAtkins, zewt: form submission? |
| 02:55 | <zewt> | Hixie: tested that, but broken HTTP caching decided to break the test |
| 02:55 | <zewt> | Hixie: tested that, but broken HTTP caching decided to break the test |
| 02:56 | <zewt> | (apparently it's 2012 and apache still doesn't include the content-type as part of etag generation, or at least that seems like the likely culprit) |
| 02:56 | <zewt> | (apparently it's 2012 and apache still doesn't include the content-type as part of etag generation, or at least that seems like the likely culprit) |
| 03:00 | <zewt> | jesus. amazon spamming tons of requests in background tabs I havn't touched in days |
| 03:01 | <zewt> | jesus. amazon spamming tons of requests in background tabs I havn't touched in days |
| 03:02 | <zewt> | always nice when high-profile sites set nice, low standards for everyone else to meet |
| 03:02 | <zewt> | always nice when high-profile sites set nice, low standards for everyone else to meet |
| 03:55 | <MikeSmith> | Hixie: thanks |
| 03:55 | <MikeSmith> | Hixie: thanks |
| 05:46 | <MikeSmith> | amazing. http://my.opera.com/hallvors/blog/2012/03/20/debugging-maps-google-maps |
| 05:47 | <MikeSmith> | amazing. http://my.opera.com/hallvors/blog/2012/03/20/debugging-maps-google-maps |
| 05:54 | <heycam> | who knows how Selection and Ranges work? |
| 05:54 | <heycam> | who knows how Selection and Ranges work? |
| 05:54 | <heycam> | wondering if my usage of range.setStart/setEnd is correct: http://pastebin.mozilla.org/1527442 |
| 05:55 | <heycam> | wondering if my usage of range.setStart/setEnd is correct: http://pastebin.mozilla.org/1527442 |
| 05:55 | <heycam> | I thought that would select the "e" from "hello ", but when I try in Firefox and Chrome I get the "there" selected |
| 05:55 | <heycam> | I thought that would select the "e" from "hello ", but when I try in Firefox and Chrome I get the "there" selected |
| 05:56 | <heycam> | same thing if I translate it to html instead of svg, so I guess I am not understanding how ranges/selection work |
| 05:56 | <heycam> | same thing if I translate it to html instead of svg, so I guess I am not understanding how ranges/selection work |
| 05:57 | <heycam> | oh, since I've selected the <text> element, my indexes are child node indexes, not character offsets |
| 05:57 | <heycam> | what a straightforward API ;) |
| 05:58 | <heycam> | oh, since I've selected the <text> element, my indexes are child node indexes, not character offsets |
| 05:58 | <heycam> | what a straightforward API ;) |
| 05:59 | <heycam> | today's instalment of rubber duck / teddy bear debugging brought to you by heycam |
| 05:59 | <heycam> | today's instalment of rubber duck / teddy bear debugging brought to you by heycam |
| 06:06 | <MikeSmith> | heh |
| 06:06 | <MikeSmith> | heh |
| 06:07 | <MikeSmith> | heycam: I think AryehGregor |
| 06:07 | <MikeSmith> | heycam: I think AryehGregor |
| 06:07 | <MikeSmith> | and rniwa some |
| 06:07 | <heycam> | yeah |
| 06:07 | <MikeSmith> | and maybe also Ms2ger |
| 06:07 | <heycam> | oh well, problem solved |
| 06:08 | <MikeSmith> | and rniwa some |
| 06:08 | <heycam> | yeah |
| 06:08 | <MikeSmith> | and maybe also Ms2ger |
| 06:08 | <heycam> | oh well, problem solved |
| 06:08 | <MikeSmith> | that's a nice phrase to hear |
| 06:08 | <heycam> | ga |
| 06:08 | <heycam> | *ha |
| 06:08 | <MikeSmith> | that's a nice phrase to hear |
| 06:08 | <heycam> | ga |
| 06:08 | <heycam> | *ha |
| 08:00 | <MikeSmith> | Hixie: can you point me at the JS code that does the "Loading slowly?" popup |
| 08:01 | <MikeSmith> | Hixie: can you point me at the JS code that does the "Loading slowly?" popup |
| 08:01 | <MikeSmith> | hmm |
| 08:01 | <MikeSmith> | I can't add it myself to the Overview.html pages |
| 08:01 | <MikeSmith> | *page |
| 08:01 | <MikeSmith> | hmm |
| 08:01 | <MikeSmith> | I can't add it myself to the Overview.html pages |
| 08:01 | <MikeSmith> | *page |
| 08:01 | <MikeSmith> | ah wait |
| 08:01 | <MikeSmith> | yeah I can now |
| 08:02 | <MikeSmith> | ah wait |
| 08:02 | <MikeSmith> | yeah I can now |
| 08:02 | <MikeSmith> | Hixie: this is in the context of https://www.w3.org/Bugs/Public/show_bug.cgi?id=16442 |
| 08:02 | <MikeSmith> | Hixie: this is in the context of https://www.w3.org/Bugs/Public/show_bug.cgi?id=16442 |
| 08:03 | <Ms2ger> | Morning Mike |
| 08:03 | <MikeSmith> | Ms2ger: hej |
| 08:03 | <MikeSmith> | Ms2ger: hej |
| 08:05 | <Ms2ger> | I was looking for a component to dump https://www.w3.org/Bugs/Public/show_bug.cgi?id=14600 into earlier |
| 08:05 | <Ms2ger> | I was looking for a component to dump https://www.w3.org/Bugs/Public/show_bug.cgi?id=14600 into earlier |
| 08:05 | <MikeSmith> | hmm |
| 08:05 | <MikeSmith> | no brilliant ideas from me |
| 08:06 | <MikeSmith> | hmm |
| 08:06 | <MikeSmith> | no brilliant ideas from me |
| 08:06 | <MikeSmith> | I can create a new component if we need one |
| 08:06 | <MikeSmith> | "Orphaned" |
| 08:06 | <MikeSmith> | I can create a new component if we need one |
| 08:06 | <MikeSmith> | "Orphaned" |
| 08:07 | <MikeSmith> | "Friendless" |
| 08:07 | <MikeSmith> | "Unwelcome" |
| 08:07 | <MikeSmith> | "Unappreciated" |
| 08:07 | <Ms2ger> | Oh, I like "unwelcome" |
| 08:07 | <MikeSmith> | "Friendless" |
| 08:07 | <MikeSmith> | "Unwelcome" |
| 08:07 | <MikeSmith> | "Unappreciated" |
| 08:07 | <Ms2ger> | Oh, I like "unwelcome" |
| 08:09 | <MikeSmith> | OK, now we need to decide on which WG |
| 08:09 | <MikeSmith> | WebApps? |
| 08:10 | <MikeSmith> | OK, now we need to decide on which WG |
| 08:10 | <MikeSmith> | WebApps? |
| 08:13 | <Ms2ger> | Web Platform (other)? |
| 08:14 | <Ms2ger> | Web Platform (other)? |
| 08:15 | <MikeSmith> | OK |
| 08:15 | <MikeSmith> | OK |
| 08:18 | <MikeSmith> | Ms2ger: OK, added |
| 08:18 | <Ms2ger> | Thanks |
| 08:18 | <MikeSmith> | with Description, "Features for which we have no specs whose editors are willing to give them a home." |
| 08:18 | <MikeSmith> | Ms2ger: OK, added |
| 08:18 | <Ms2ger> | Thanks |
| 08:18 | <MikeSmith> | with Description, "Features for which we have no specs whose editors are willing to give them a home." |
| 08:20 | <Ms2ger> | :) |
| 08:20 | <Ms2ger> | :) |
| 08:22 | MikeSmith | steps away for a bit |
| 08:23 | MikeSmith | steps away for a bit |
| 08:23 | <Ms2ger> | See you |
| 08:23 | <Ms2ger> | See you |
| 08:26 | <Ms2ger> | Also, I've only owned the spec for Range/Selection, that doesn't mean I know anything about it |
| 08:27 | <Ms2ger> | Also, I've only owned the spec for Range/Selection, that doesn't mean I know anything about it |
| 08:58 | <annevk> | zewt: both URLs and form submission need encode |
| 08:58 | <annevk> | zewt: both URLs and form submission need encode |
| 08:59 | <annevk> | zewt: e.g. create a page containing <meta charset=gbk><a href=?€>test</a> and see what it points to |
| 08:59 | <annevk> | might not be the most interoperable example, but you get the idea |
| 08:59 | <annevk> | zewt: e.g. create a page containing <meta charset=gbk><a href=?€>test</a> and see what it points to |
| 08:59 | <annevk> | might not be the most interoperable example, but you get the idea |
| 09:08 | <kennyluck> | Why not just "Proprietary" :p |
| 09:08 | <kennyluck> | Why not just "Proprietary" :p |
| 09:17 | <jgraham> | MikeSmith: Yeah Hallvord is a bit scary |
| 09:17 | <jgraham> | Not to mention Google Maps |
| 09:18 | <jgraham> | MikeSmith: Yeah Hallvord is a bit scary |
| 09:18 | <jgraham> | Not to mention Google Maps |
| 09:25 | <zcorpan> | MikeSmith: you could add a noindex meta to the single-page version |
| 09:25 | <zcorpan> | MikeSmith: you could add a noindex meta to the single-page version |
| 09:26 | <zcorpan> | MikeSmith: maybe the april date will be accurate after all... |
| 09:26 | <zcorpan> | MikeSmith: maybe the april date will be accurate after all... |
| 09:32 | <jgraham> | We should rewrite the charter so we can only publish on April 1st |
| 09:32 | <jgraham> | We should rewrite the charter so we can only publish on April 1st |
| 10:06 | <MikeSmith> | zcorpan: hadn't consider noindex yet |
| 10:07 | <MikeSmith> | zcorpan: hadn't consider noindex yet |
| 10:07 | <MikeSmith> | will try to set up the JS thing now |
| 10:07 | <MikeSmith> | will try to set up the JS thing now |
| 10:10 | <MikeSmith> | jgraham, zcorpan : btw, I'm sure who "a colleague who has often enough beaten me to the goal post in analysis if we happened to look at the same issue" is |
| 10:10 | <MikeSmith> | jgraham, zcorpan : btw, I'm sure who "a colleague who has often enough beaten me to the goal post in analysis if we happened to look at the same issue" is |
| 10:12 | <jgraham> | You are? |
| 10:12 | <jgraham> | You are? |
| 10:14 | <MikeSmith> | s/sure/curious/ |
| 10:14 | <MikeSmith> | I meant |
| 10:14 | <MikeSmith> | no idea why that came out "sure" |
| 10:15 | <MikeSmith> | s/sure/curious/ |
| 10:15 | <MikeSmith> | I meant |
| 10:15 | <MikeSmith> | no idea why that came out "sure" |
| 10:18 | <hasather> | MikeSmith: Kåre Byberg |
| 10:18 | <hasather> | MikeSmith: Kåre Byberg |
| 10:19 | <jgraham> | Yeah, not that surprising if you are familiar with the people involved |
| 10:19 | <jgraham> | Yeah, not that surprising if you are familiar with the people involved |
| 10:21 | <MikeSmith> | hasather: thanks |
| 10:21 | <MikeSmith> | I don't think I ever met Kåre |
| 10:22 | <MikeSmith> | hasather: thanks |
| 10:22 | <MikeSmith> | I don't think I ever met Kåre |
| 10:23 | <hasather> | MikeSmith: started working after you left I think (and he works from home) |
| 10:23 | <hasather> | MikeSmith: started working after you left I think (and he works from home) |
| 10:24 | <MikeSmith> | ah |
| 10:24 | <MikeSmith> | ah |
| 10:26 | <annevk> | lol pub is deferred again |
| 10:26 | <annevk> | circus is in town |
| 10:26 | <annevk> | lol pub is deferred again |
| 10:26 | <annevk> | circus is in town |
| 11:37 | <MikeSmith> | OK fwiw I added the fugly "Too slow? Try reading the multipage copy of the spec instead" thing to the W3C version of the single-page spec |
| 11:37 | <MikeSmith> | http://dev.w3.org/html5/spec/single-page.html |
| 11:37 | <MikeSmith> | OK fwiw I added the fugly "Too slow? Try reading the multipage copy of the spec instead" thing to the W3C version of the single-page spec |
| 11:37 | <MikeSmith> | http://dev.w3.org/html5/spec/single-page.html |
| 12:15 | <smaug____> | hmm, perhaps I wasn't connected |
| 12:15 | <smaug____> | krijn: you said at some point that you may not be able to log this channel for long |
| 12:15 | <smaug____> | hmm, perhaps I wasn't connected |
| 12:15 | <smaug____> | krijn: you said at some point that you may not be able to log this channel for long |
| 12:15 | <smaug____> | krijn: there is now a backup http://logbot.glob.com.au/ |
| 12:16 | <smaug____> | krijn: there is now a backup http://logbot.glob.com.au/ |
| 12:18 | <kennyluck> | yay! |
| 12:18 | <kennyluck> | yay! |
| 12:20 | <charlvn> | smaug____: cool, is that a custom implementation? |
| 12:21 | <charlvn> | smaug____: cool, is that a custom implementation? |
| 12:22 | <smaug____> | charlvn: of what? I don't know |
| 12:22 | <smaug____> | I don't maintain it |
| 12:22 | <smaug____> | charlvn: of what? I don't know |
| 12:22 | <smaug____> | I don't maintain it |
| 12:23 | <annevk> | smaug____: so when you insert a DocumentFragment that fragment always gets a single record too right? |
| 12:23 | <krijn> | smaug____: nice! |
| 12:23 | <annevk> | smaug____: so when you insert a DocumentFragment that fragment always gets a single record too right? |
| 12:23 | <krijn> | smaug____: nice! |
| 12:23 | <smaug____> | I just knew that glob had logs for some moznet channels and when krijn mentioned that he may not be able keep the logs working here, I asked glob .. |
| 12:24 | <smaug____> | I just knew that glob had logs for some moznet channels and when krijn mentioned that he may not be able keep the logs working here, I asked glob .. |
| 12:24 | <smaug____> | annevk: yes |
| 12:24 | <smaug____> | annevk: nodes are removed from it |
| 12:24 | <smaug____> | annevk: nodes are removed from it |
| 12:25 | <annevk> | I guess DocumentFragment needs a whole special path |
| 12:25 | <smaug____> | probably yes |
| 12:25 | <smaug____> | that is what I have in implementation |
| 12:25 | <smaug____> | like there is special thingie for innerHTML |
| 12:25 | <smaug____> | probably yes |
| 12:25 | <smaug____> | that is what I have in implementation |
| 12:25 | <smaug____> | like there is special thingie for innerHTML |
| 12:25 | <smaug____> | and textContent |
| 12:26 | <smaug____> | and textContent |
| 12:30 | <annevk> | hmm |
| 12:30 | <annevk> | hmm |
| 12:30 | <annevk> | so concept-node-insert needs to queue that if node is a DocumentFragment |
| 12:30 | <annevk> | and it should probably use word different from append to move nodes around |
| 12:31 | <annevk> | so concept-node-insert needs to queue that if node is a DocumentFragment |
| 12:31 | <annevk> | and it should probably use word different from append to move nodes around |
| 12:31 | <annevk> | then pre-insert/insert/remove need a flag to suppress record queuing |
| 12:32 | <annevk> | then pre-insert/insert/remove need a flag to suppress record queuing |
| 12:32 | <annevk> | and then replace/replace all need to use that |
| 12:32 | <annevk> | and then replace/replace all need to use that |
| 12:32 | <annevk> | and queue their own stuff |
| 12:32 | <smaug____> | in the implementation I have "MutationBatch" stack object around the document fragment insertion |
| 12:33 | <annevk> | and queue their own stuff |
| 12:33 | <smaug____> | in the implementation I have "MutationBatch" stack object around the document fragment insertion |
| 12:33 | <smaug____> | the batch ends up creating just one record per observer |
| 12:33 | <smaug____> | the batch ends up creating just one record per observer |
| 12:33 | <annevk> | and replace/replace all also need to take special care again of DocumentFragment |
| 12:33 | <smaug____> | er, there is one batch for removal, and one for adding nodes to the new parent |
| 12:34 | <annevk> | and replace/replace all also need to take special care again of DocumentFragment |
| 12:34 | <smaug____> | er, there is one batch for removal, and one for adding nodes to the new parent |
| 12:34 | <annevk> | I thought you wanted them combined for replace? |
| 12:34 | <annevk> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=16373 |
| 12:34 | <smaug____> | ah, that can't be done in general cas |
| 12:34 | <smaug____> | e |
| 12:34 | <smaug____> | invalid but |
| 12:34 | <annevk> | I thought you wanted them combined for replace? |
| 12:34 | <annevk> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=16373 |
| 12:34 | <smaug____> | ah, that can't be done in general cas |
| 12:34 | <smaug____> | e |
| 12:34 | <smaug____> | invalid but |
| 12:34 | <smaug____> | bug even |
| 12:34 | <annevk> | hmm |
| 12:35 | <smaug____> | bug even |
| 12:35 | <annevk> | hmm |
| 12:35 | <annevk> | why can it not be done? |
| 12:35 | <smaug____> | because previousSibling/nextSibling could be wrong |
| 12:35 | <smaug____> | er, hmm |
| 12:35 | <smaug____> | am I wrong here. |
| 12:35 | <annevk> | why can it not be done? |
| 12:35 | <smaug____> | because previousSibling/nextSibling could be wrong |
| 12:35 | <smaug____> | er, hmm |
| 12:35 | <smaug____> | am I wrong here. |
| 12:36 | <annevk> | not sure why they would be wrong |
| 12:36 | <annevk> | not sure why they would be wrong |
| 12:37 | <smaug____> | nm, I was thinking different case, when one is inserting a node which has already parent |
| 12:37 | <smaug____> | that needs to create two records |
| 12:37 | <annevk> | yes |
| 12:37 | <smaug____> | nm, I was thinking different case, when one is inserting a node which has already parent |
| 12:37 | <smaug____> | that needs to create two records |
| 12:37 | <annevk> | yes |
| 12:39 | <annevk> | okay, lets try to make these edits one by one |
| 12:39 | <annevk> | okay, lets try to make these edits one by one |
| 12:39 | <annevk> | already feeling pain |
| 12:40 | <annevk> | already feeling pain |
| 12:41 | <smaug____> | annevk: sorry |
| 12:41 | <smaug____> | annevk: sorry |
| 12:42 | <smaug____> | after writing some tests for MutationObserver, if feels pretty neat API (if I dare to say that :) ) , and fast. |
| 12:43 | <smaug____> | after writing some tests for MutationObserver, if feels pretty neat API (if I dare to say that :) ) , and fast. |
| 12:43 | <annevk> | smaug____: so if you remove everything from a DF, what are previous and nextsibling? |
| 12:43 | <annevk> | null? |
| 12:43 | <annevk> | smaug____: so if you remove everything from a DF, what are previous and nextsibling? |
| 12:43 | <annevk> | null? |
| 12:44 | <smaug____> | yes |
| 12:44 | <smaug____> | yes |
| 12:47 | <Workmon> | Hey annevk, you worked on CSSOM before. Do you know if element.style.foo is supposed to support !important as part of a value? |
| 12:48 | <Workmon> | Hey annevk, you worked on CSSOM before. Do you know if element.style.foo is supposed to support !important as part of a value? |
| 12:49 | <annevk> | that was not entirely clear I remember |
| 12:49 | <annevk> | we were not sure whether setting it should map to style.setProperty or not |
| 12:49 | <annevk> | and how |
| 12:49 | <annevk> | that was not entirely clear I remember |
| 12:49 | <annevk> | we were not sure whether setting it should map to style.setProperty or not |
| 12:49 | <annevk> | and how |
| 12:51 | <Workmon> | I was surprised to find that .style is overriden by author !important rules |
| 12:51 | <Workmon> | I was surprised to find that .style is overriden by author !important rules |
| 13:03 | <zcorpan> | .style is also author-level, just higher specificity |
| 13:03 | <zcorpan> | .style is also author-level, just higher specificity |
| 13:06 | <annevk> | so nobody missed thus far that the spec does not describe MutationRecord queing of attributeNamespace? |
| 13:06 | <annevk> | so nobody missed thus far that the spec does not describe MutationRecord queing of attributeNamespace? |
| 13:06 | <smaug____> | annevk: :) |
| 13:06 | <smaug____> | hey, spec reviewing is hard |
| 13:07 | <smaug____> | annevk: :) |
| 13:07 | <smaug____> | hey, spec reviewing is hard |
| 13:07 | <annevk> | turns out |
| 13:07 | <zcorpan> | so you wouldn't get notified about namespaced attributes? |
| 13:07 | <smaug____> | per spec |
| 13:07 | <annevk> | turns out |
| 13:07 | <zcorpan> | so you wouldn't get notified about namespaced attributes? |
| 13:07 | <smaug____> | per spec |
| 13:07 | <zcorpan> | that's a feature! :-P |
| 13:07 | <smaug____> | implementations do support it |
| 13:08 | <zcorpan> | that's a feature! :-P |
| 13:08 | <smaug____> | implementations do support it |
| 13:11 | <annevk> | ah nice, it's not too hard |
| 13:11 | <annevk> | there's no namespace-based filtering |
| 13:11 | <annevk> | ah nice, it's not too hard |
| 13:11 | <annevk> | there's no namespace-based filtering |
| 13:11 | <annevk> | it just needs to be set on the object |
| 13:11 | <annevk> | piece of cake |
| 13:12 | <annevk> | it just needs to be set on the object |
| 13:12 | <annevk> | piece of cake |
| 13:12 | <smaug____> | I was thinking to add support for prefix:localName filters |
| 13:12 | <smaug____> | but not sure if that is important enough |
| 13:12 | <smaug____> | I was thinking to add support for prefix:localName filters |
| 13:12 | <smaug____> | but not sure if that is important enough |
| 13:18 | <annevk> | given that people want to deprecate everything but name/value attributes, lets not |
| 13:18 | <annevk> | given that people want to deprecate everything but name/value attributes, lets not |
| 13:18 | <zcorpan> | can you currently filter for localName or qualifiedName? |
| 13:19 | <zcorpan> | can you currently filter for localName or qualifiedName? |
| 13:19 | <annevk> | qualified |
| 13:19 | <zcorpan> | ok |
| 13:19 | <annevk> | qualified |
| 13:19 | <zcorpan> | ok |
| 13:20 | <annevk> | attribute's name is the new qualified name |
| 13:20 | <annevk> | attribute's name is the new qualified name |
| 13:30 | <annevk> | ugh |
| 13:30 | <annevk> | ugh |
| 13:30 | <annevk> | maybe I should unsubscribe from the w3c process thingie |
| 13:31 | <annevk> | maybe I should unsubscribe from the w3c process thingie |
| 13:32 | <annevk> | anyway |
| 13:32 | <annevk> | can pre-insert and insert be merged? |
| 13:32 | <annevk> | and pre-remove / remove |
| 13:33 | <annevk> | i guess it's kind of nice for replace |
| 13:34 | <annevk> | anyway |
| 13:34 | <annevk> | can pre-insert and insert be merged? |
| 13:34 | <annevk> | and pre-remove / remove |
| 13:34 | <annevk> | i guess it's kind of nice for replace |
| 13:47 | <annevk> | pre-insert does not need suppress |
| 13:47 | <annevk> | not sure why I thought it did |
| 13:48 | <annevk> | pre-insert does not need suppress |
| 13:48 | <annevk> | not sure why I thought it did |
| 13:50 | <charlvn> | smaug____: ah ok, sorry was in a meeting just now |
| 13:51 | <charlvn> | smaug____: ah ok, sorry was in a meeting just now |
| 14:07 | <smaug____> | does webkit have anything similar to gecko's window.dump() ? |
| 14:08 | <smaug____> | does webkit have anything similar to gecko's window.dump() ? |
| 14:08 | <hsivonen> | smaug____: console.log() maybe? |
| 14:09 | <hsivonen> | smaug____: console.log() maybe? |
| 14:09 | <smaug____> | nope, that is annoying |
| 14:09 | <smaug____> | nope, that is annoying |
| 14:10 | <charlvn> | never used window.dump but why is that less annoying than console.log ? |
| 14:10 | <charlvn> | never used window.dump but why is that less annoying than console.log ? |
| 14:11 | <smaug____> | charlvn: because it prints out to the terminal (if a pref is enabled) |
| 14:11 | <smaug____> | it is easier to process that data |
| 14:11 | <charlvn> | ah i see, ok |
| 14:11 | <smaug____> | charlvn: because it prints out to the terminal (if a pref is enabled) |
| 14:11 | <smaug____> | it is easier to process that data |
| 14:11 | <charlvn> | ah i see, ok |
| 14:12 | <charlvn> | i like firebug's handling of that (it allows you to neatly expand objects, etc) but that is only handy for certain types of debugging |
| 14:12 | <annevk> | man complex mutations to mutation algorithms are complex |
| 14:12 | <charlvn> | i like firebug's handling of that (it allows you to neatly expand objects, etc) but that is only handy for certain types of debugging |
| 14:12 | <annevk> | man complex mutations to mutation algorithms are complex |
| 14:12 | <smaug____> | aren't they |
| 14:13 | <smaug____> | aren't they |
| 14:13 | <smaug____> | implementing that all isn't quite trivial either |
| 14:21 | <annevk> | ok I checked something in |
| 14:21 | <annevk> | see e.g. http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-node-replace-all |
| 14:22 | <annevk> | ok I checked something in |
| 14:22 | <annevk> | see e.g. http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-node-replace-all |
| 14:22 | <annevk> | the only thing that might be wrong is transient observers because I still have no clue |
| 14:22 | <annevk> | (did not bother getting a clue either) |
| 14:23 | <annevk> | the only thing that might be wrong is transient observers because I still have no clue |
| 14:23 | <annevk> | (did not bother getting a clue either) |
| 14:23 | <smaug____> | I'll review after lunc |
| 14:24 | <smaug____> | h |
| 14:26 | <annevk> | hmm food |
| 14:28 | <annevk> | is innerHTML defined in terms of http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-node-replace-all yet? |
| 14:28 | <annevk> | is innerHTML defined in terms of http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-node-replace-all yet? |
| 14:59 | <Ms2ger> | annevk, yes |
| 15:00 | <Ms2ger> | annevk, yes |
| 15:10 | <hsivonen> | too bad mpilgrim doesn't blog anymore. it would have been interesting to see his comments on Mozilla's latest codec direction |
| 15:11 | <hsivonen> | too bad mpilgrim doesn't blog anymore. it would have been interesting to see his comments on Mozilla's latest codec direction |
| 15:19 | <annevk> | sweet, so everything should be good |
| 15:19 | <annevk> | although I guess I should go through the spec again checking everything that invokes mutations |
| 15:20 | <annevk> | sweet, so everything should be good |
| 15:20 | <annevk> | although I guess I should go through the spec again checking everything that invokes mutations |
| 15:43 | <zcorpan> | annevk: why is it "node document" rather than "owner document"? |
| 15:43 | <zcorpan> | annevk: why is it "node document" rather than "owner document"? |
| 15:48 | <smaug____> | is jarred ever here? |
| 15:48 | <smaug____> | jarred nicholls |
| 15:48 | <smaug____> | is jarred ever here? |
| 15:48 | <smaug____> | jarred nicholls |
| 16:44 | <zcorpan> | should we add onfullscreen* event handlers? |
| 16:44 | <zcorpan> | should we add onfullscreen* event handlers? |
| 16:49 | <smaug____> | dglazkov: I don't understand why templates need to be hacked in via components stuff? |
| 16:49 | <smaug____> | dglazkov: I don't understand why templates need to be hacked in via components stuff? |
| 17:12 | <annevk> | zcorpan: it's also XMLHttpRequest document |
| 17:13 | <annevk> | zcorpan: it's also XMLHttpRequest document |
| 17:16 | <zcorpan> | annevk: i don't follow |
| 17:16 | <zcorpan> | annevk: i don't follow |
| 17:17 | <annevk> | aklein: did you pay attention to transient observers when reviewing? |
| 17:18 | <annevk> | aklein: did you pay attention to transient observers when reviewing? |
| 17:19 | <annevk> | zcorpan: that's mostly the reason |
| 17:20 | <annevk> | zcorpan: that's mostly the reason |
| 17:20 | <zcorpan> | annevk: node document and XMLHttpRequest document seem to have different definitions |
| 17:20 | <zcorpan> | annevk: i don't see why that makes node document be called node document instead of owner document |
| 17:20 | <zcorpan> | annevk: node document and XMLHttpRequest document seem to have different definitions |
| 17:20 | <zcorpan> | annevk: i don't see why that makes node document be called node document instead of owner document |
| 17:21 | <zcorpan> | but maybe i'm missing something |
| 17:21 | <zcorpan> | but maybe i'm missing something |
| 17:21 | <annevk> | they do? |
| 17:22 | <annevk> | they do? |
| 17:22 | <annevk> | both are x document where a given document is associated with x in some way |
| 17:22 | <annevk> | I don't really feel strongly about this, but that's the reason they are named similarly |
| 17:22 | <annevk> | both are x document where a given document is associated with x in some way |
| 17:22 | <annevk> | I don't really feel strongly about this, but that's the reason they are named similarly |
| 17:23 | <zcorpan> | ah, ok, i see what you mean |
| 17:23 | <zcorpan> | ah, ok, i see what you mean |
| 17:24 | <zcorpan> | i think that "node document" is still a weird name, and it's used in various specs (e.g. fullscreen) |
| 17:25 | <zcorpan> | i think that "node document" is still a weird name, and it's used in various specs (e.g. fullscreen) |
| 17:25 | <zcorpan> | maybe "XMLHttpRequest document" is also a weird name, but i don't have a better suggestion for that one |
| 17:25 | <zcorpan> | maybe "XMLHttpRequest document" is also a weird name, but i don't have a better suggestion for that one |
| 17:27 | <zcorpan> | should i file a bug to rename node document? |
| 17:27 | <annevk> | I kind of like it personally and renaming it is going to be pain, but I suppose we could do it at some point |
| 17:27 | <zcorpan> | should i file a bug to rename node document? |
| 17:27 | <annevk> | I kind of like it personally and renaming it is going to be pain, but I suppose we could do it at some point |
| 17:27 | <annevk> | pain being make work, it's probably not that much effort overall |
| 17:28 | <annevk> | pain being make work, it's probably not that much effort overall |
| 17:28 | <dglazkov> | good morning, Whatwg! |
| 17:28 | <dglazkov> | good morning, Whatwg! |
| 17:28 | <dglazkov> | smaug____: does http://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html help a little bit? |
| 17:29 | <dglazkov> | smaug____: does http://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html help a little bit? |
| 17:29 | <smaug____> | looking |
| 17:30 | <smaug____> | dglazkov: well, why not get one thing done first |
| 17:30 | <smaug____> | like shadow dom |
| 17:30 | <smaug____> | dglazkov: well, why not get one thing done first |
| 17:30 | <smaug____> | like shadow dom |
| 17:31 | <dglazkov> | smaug____: what's the harm in having multiple tracks? |
| 17:31 | <dglazkov> | smaug____: what's the harm in having multiple tracks? |
| 17:31 | <smaug____> | dglazkov: well, makes reviewing harder |
| 17:31 | <smaug____> | dglazkov: well, makes reviewing harder |
| 17:31 | <smaug____> | no idea what parts of web components are in which stability level |
| 17:31 | <dglazkov> | smaug____: how? you can review sequentially :) |
| 17:32 | <smaug____> | no idea what parts of web components are in which stability level |
| 17:32 | <dglazkov> | smaug____: how? you can review sequentially :) |
| 17:32 | <smaug____> | and why they are all under web components |
| 17:32 | <dglazkov> | smaug____: well, that's why in my update, I mention that shadow DOM is in the bug fix long tail mode. And that templates is just a first draft. |
| 17:32 | <dglazkov> | smaug____: well, that's why in my update, I mention that shadow DOM is in the bug fix long tail mode. And that templates is just a first draft. |
| 17:32 | <dglazkov> | smaug____: that's what the explainer doc explains, hopefully |
| 17:32 | <TabAtkins> | Workmon: There was a discussion about !important in @style. I don't think we came to a firm conclusion (I can't find the discussion now) but I believe the consensus was not to allow it. (Or, perhaps, to allow it syntactically but have it do nothing.) |
| 17:32 | <smaug____> | but why aren't they just very much separate drafts? |
| 17:33 | <dglazkov> | smaug____: that's what the explainer doc explains, hopefully |
| 17:33 | <TabAtkins> | Workmon: There was a discussion about !important in @style. I don't think we came to a firm conclusion (I can't find the discussion now) but I believe the consensus was not to allow it. (Or, perhaps, to allow it syntactically but have it do nothing.) |
| 17:33 | <smaug____> | but why aren't they just very much separate drafts? |
| 17:33 | <annevk> | http://lists.w3.org/Archives/Public/public-w3process/2012Mar/0076.html hmm |
| 17:33 | <dglazkov> | smaug____: that's why they are. I am not sure how much more separate they should be? |
| 17:34 | <annevk> | http://lists.w3.org/Archives/Public/public-w3process/2012Mar/0076.html hmm |
| 17:34 | <annevk> | I wonder how to explain that CSS is not working that great... |
| 17:34 | <dglazkov> | smaug____: that's why they are. I am not sure how much more separate they should be? |
| 17:34 | <annevk> | I wonder how to explain that CSS is not working that great... |
| 17:34 | <annevk> | maybe just not bother is better |
| 17:34 | <smaug____> | dglazkov: just remove the whole concept of "web components" :) |
| 17:34 | <annevk> | maybe just not bother is better |
| 17:34 | <smaug____> | dglazkov: just remove the whole concept of "web components" :) |
| 17:34 | <dglazkov> | smaug____: no :) |
| 17:34 | <smaug____> | there are just separate proposals, which have little to do with each other |
| 17:35 | <dglazkov> | smaug____: no :) |
| 17:35 | <smaug____> | there are just separate proposals, which have little to do with each other |
| 17:35 | <annevk> | smaug____: that's the opposite argument others made a while back... |
| 17:35 | <dglazkov> | smaug____: sure. why is that bothering you? |
| 17:35 | <annevk> | smaug____: then people were complaining the whole picture was not clear |
| 17:36 | <annevk> | smaug____: that's the opposite argument others made a while back... |
| 17:36 | <dglazkov> | smaug____: sure. why is that bothering you? |
| 17:36 | <annevk> | smaug____: then people were complaining the whole picture was not clear |
| 17:36 | <annevk> | circles! |
| 17:36 | <smaug____> | annevk: the whole picture is still not at all clear |
| 17:36 | <annevk> | circles! |
| 17:36 | <smaug____> | I don't understand how templates are related to shadow dom |
| 17:36 | <smaug____> | annevk: the whole picture is still not at all clear |
| 17:36 | <smaug____> | I don't understand how templates are related to shadow dom |
| 17:37 | <dglazkov> | smaug____: they aren't related directly. If you'd read the explainer, you'd know that both templates and shadow DOM are used by custom elements |
| 17:37 | <dglazkov> | smaug____: they are building blocks |
| 17:37 | <dglazkov> | smaug____: they aren't related directly. If you'd read the explainer, you'd know that both templates and shadow DOM are used by custom elements |
| 17:37 | <dglazkov> | smaug____: they are building blocks |
| 17:38 | <dglazkov> | smaug____: spec-wise, it will start coming together nicely when the custom elements spec is in place |
| 17:38 | <dglazkov> | smaug____: I am ramping up to do that |
| 17:38 | <dglazkov> | smaug____: spec-wise, it will start coming together nicely when the custom elements spec is in place |
| 17:38 | <dglazkov> | smaug____: I am ramping up to do that |
| 17:38 | <smaug____> | ok |
| 17:38 | <dglazkov> | smaug____: but first, I wrote a polyfill to try and play with what's already there: https://github.com/dglazkov/Web-Components-Polyfill |
| 17:39 | <smaug____> | ok |
| 17:39 | <dglazkov> | smaug____: but first, I wrote a polyfill to try and play with what's already there: https://github.com/dglazkov/Web-Components-Polyfill |
| 17:39 | <aklein> | annevk: just got in, catching up on the scrollback now... |
| 17:39 | <dglazkov> | smaug____: it's essentially using the shadow DOM impl in WebKit and some minor js hackery to emulate templates |
| 17:39 | <aklein> | annevk: just got in, catching up on the scrollback now... |
| 17:39 | <dglazkov> | smaug____: it's essentially using the shadow DOM impl in WebKit and some minor js hackery to emulate templates |
| 17:39 | <annevk> | aklein: kk, there's no rush, I'll look at this again tomorrow if there's any need to follow up |
| 17:40 | <annevk> | aklein: kk, there's no rush, I'll look at this again tomorrow if there's any need to follow up |
| 17:40 | <dglazkov> | smaug____: still working on that, but once it's solid, I'll try to write the whole thing as a spec draft |
| 17:40 | <rniwa> | AryehGregor: yt? |
| 17:40 | <AryehGregor> | rniwa, yes. |
| 17:40 | <rniwa> | AryehGregor: yt? |
| 17:40 | <AryehGregor> | rniwa, yes. |
| 17:40 | <TabAtkins> | smaug____: Dimitri's example shows off how annoying building the HTML for components is in pure JS. ^_^ |
| 17:40 | <rniwa> | AryehGregor: https://bugs.webkit.org/show_bug.cgi?id=81661 |
| 17:40 | <rniwa> | AryehGregor: for this bug, what's the correct behavior per spec? |
| 17:40 | <rniwa> | AryehGregor: or rather, where is this behavior spec'ed? |
| 17:40 | <dglazkov> | TabAtkins: the tab manager one? yep. That's crazy stuff |
| 17:41 | <TabAtkins> | smaug____: Dimitri's example shows off how annoying building the HTML for components is in pure JS. ^_^ |
| 17:41 | <rniwa> | AryehGregor: https://bugs.webkit.org/show_bug.cgi?id=81661 |
| 17:41 | <rniwa> | AryehGregor: for this bug, what's the correct behavior per spec? |
| 17:41 | <rniwa> | AryehGregor: or rather, where is this behavior spec'ed? |
| 17:41 | <dglazkov> | TabAtkins: the tab manager one? yep. That's crazy stuff |
| 17:41 | <TabAtkins> | Yup. Btw, thanks for reformatting it to look like HTML. I had to do that myself earlier just to see what it was doing. ^_^ |
| 17:41 | <dglazkov> | TabAtkins: that's this code by the way: https://github.com/dglazkov/Tabs |
| 17:41 | <TabAtkins> | Yup. Btw, thanks for reformatting it to look like HTML. I had to do that myself earlier just to see what it was doing. ^_^ |
| 17:41 | <dglazkov> | TabAtkins: that's this code by the way: https://github.com/dglazkov/Tabs |
| 17:42 | <AryehGregor> | rniwa, AFAIK, keypress isn't specced anywhere in reasonable detail. I guess here is technically where it's specced: http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#event-type-keypress |
| 17:42 | <dglazkov> | before scoped styles, it was even more awful: https://github.com/dglazkov/Tabs/blob/c14c3e58a2cf0d0cce5aaa7d11ae48be1b25fbc3/tabs-control.js |
| 17:43 | <rniwa> | AryehGregor: yeah but that doesn't tell us anything :( |
| 17:43 | <AryehGregor> | Yeah, that's the problem. :) |
| 17:43 | <AryehGregor> | There's no good spec for key or mouse events AFAIK, where "good" means "actually tells you exactly what to do". |
| 17:43 | <rniwa> | AryehGregor: alright, I'm gonna start a thread on public-webapps then |
| 17:43 | <rniwa> | AryehGregor: yeah |
| 17:43 | <rniwa> | AryehGregor: we need that. |
| 17:43 | <rniwa> | AryehGregor: UA behaviors don't agree at all in this area |
| 17:44 | <AryehGregor> | rniwa, AFAIK, keypress isn't specced anywhere in reasonable detail. I guess here is technically where it's specced: http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#event-type-keypress |
| 17:44 | <dglazkov> | before scoped styles, it was even more awful: https://github.com/dglazkov/Tabs/blob/c14c3e58a2cf0d0cce5aaa7d11ae48be1b25fbc3/tabs-control.js |
| 17:44 | <rniwa> | AryehGregor: yeah but that doesn't tell us anything :( |
| 17:44 | <AryehGregor> | Yeah, that's the problem. :) |
| 17:44 | <AryehGregor> | There's no good spec for key or mouse events AFAIK, where "good" means "actually tells you exactly what to do". |
| 17:44 | <rniwa> | AryehGregor: alright, I'm gonna start a thread on public-webapps then |
| 17:44 | <rniwa> | AryehGregor: yeah |
| 17:44 | <rniwa> | AryehGregor: we need that. |
| 17:44 | <rniwa> | AryehGregor: UA behaviors don't agree at all in this area |
| 18:13 | <dglazkov> | smaug____: reminder -- review shadow DOM spec! :P |
| 18:13 | <dglazkov> | smaug____: reminder -- review shadow DOM spec! :P |
| 18:14 | <smaug____> | I should I should! |
| 18:14 | <smaug____> | please give me some more hours per day |
| 18:14 | <zcorpan> | just neglect sleep |
| 18:14 | <smaug____> | please give me some more hours per day |
| 18:14 | <zcorpan> | just neglect sleep |
| 18:14 | <smaug____> | aklein: ping |
| 18:15 | <smaug____> | aklein: ping |
| 18:17 | <aklein> | smaug____: pong |
| 18:17 | <dglazkov> | aklein: can you give smaug____ more hours per day? |
| 18:17 | <aklein> | smaug____: pong |
| 18:17 | <dglazkov> | aklein: can you give smaug____ more hours per day? |
| 18:17 | <smaug____> | aklein: about delivery order |
| 18:18 | <smaug____> | aklein: about delivery order |
| 18:18 | <rniwa> | TabAtkins: what do you feel if I proposed to add "auto" value to direction property? |
| 18:18 | <smaug____> | aklein: I kind of like what you proposed |
| 18:18 | <rniwa> | TabAtkins: what do you feel if I proposed to add "auto" value to direction property? |
| 18:18 | <smaug____> | aklein: I kind of like what you proposed |
| 18:18 | <smaug____> | but the problem is that it adds a special case for microtask handling |
| 18:18 | <smaug____> | kind of |
| 18:19 | <smaug____> | but the problem is that it adds a special case for microtask handling |
| 18:19 | <smaug____> | kind of |
| 18:19 | <smaug____> | handling a callback should be a microtask |
| 18:19 | <smaug____> | handling a callback should be a microtask |
| 18:20 | <aklein> | smaug____: and you say "should be" because it avoids special-casing? |
| 18:21 | <aklein> | smaug____: and you say "should be" because it avoids special-casing? |
| 18:21 | <smaug____> | well, I don't like special cases. I prefer consistency |
| 18:21 | <smaug____> | well, I don't like special cases. I prefer consistency |
| 18:23 | <smaug____> | aklein: is there some case where the original behavior is really bad ? |
| 18:23 | <aklein> | I'm trying to recall exactly where the special-casing of mutation callbacks came from |
| 18:24 | <smaug____> | aklein: is there some case where the original behavior is really bad ? |
| 18:24 | <aklein> | I'm trying to recall exactly where the special-casing of mutation callbacks came from |
| 18:24 | <aklein> | the first thing that comes to mind is a sense of "fairness", sort of round-robin scheduling of callbacks |
| 18:24 | <smaug____> | aklein: native calling JS is a microtask |
| 18:24 | <aklein> | the first thing that comes to mind is a sense of "fairness", sort of round-robin scheduling of callbacks |
| 18:24 | <smaug____> | aklein: native calling JS is a microtask |
| 18:25 | <smaug____> | so if there are observers A and B, and A's callback is called, end of microtask is when the callback has just been handled |
| 18:25 | <smaug____> | the new behavior kind of make end of microtask to be after B's callback |
| 18:25 | <smaug____> | so if there are observers A and B, and A's callback is called, end of microtask is when the callback has just been handled |
| 18:25 | <smaug____> | the new behavior kind of make end of microtask to be after B's callback |
| 18:27 | <aklein> | I think the issue is that you're thinking about the mutation observer invocation as the only thing that might happen at end of microtask |
| 18:27 | <TabAtkins> | rniwa: What would it do? |
| 18:27 | <aklein> | but really the whole algorithm is just one thing that runs at the end of microtask |
| 18:27 | <aklein> | I think the issue is that you're thinking about the mutation observer invocation as the only thing that might happen at end of microtask |
| 18:27 | <TabAtkins> | rniwa: What would it do? |
| 18:27 | <aklein> | but really the whole algorithm is just one thing that runs at the end of microtask |
| 18:27 | <aklein> | and should be thought of handling the case when it is called from within a callback invoked by itself |
| 18:28 | <aklein> | and should be thought of handling the case when it is called from within a callback invoked by itself |
| 18:29 | <smaug____> | that is one way to think about it. But it isn't consistent how microtask works elsewhere |
| 18:29 | <smaug____> | that is one way to think about it. But it isn't consistent how microtask works elsewhere |
| 18:30 | <smaug____> | ok, html spec has that inconsistent behavior |
| 18:30 | <smaug____> | aklein: I don't care too much about this though |
| 18:30 | <smaug____> | ok, html spec has that inconsistent behavior |
| 18:30 | <smaug____> | aklein: I don't care too much about this though |
| 18:30 | <smaug____> | I care a tiny bit more about case-sensitiveness of filter values ;) |
| 18:31 | <smaug____> | I care a tiny bit more about case-sensitiveness of filter values ;) |
| 18:32 | <smaug____> | ah, HTML spec is buggy here |
| 18:32 | <smaug____> | ah, HTML spec is buggy here |
| 18:33 | <smaug____> | or do I need to read DOM4... |
| 18:33 | <smaug____> | or do I need to read DOM4... |
| 18:39 | <rniwa> | TabAtkins: it would behave like dir="auto" |
| 18:40 | <rniwa> | TabAtkins: it would behave like dir="auto" |
| 18:41 | <rniwa> | TabAtkins: right now, dir=auto is a weird beast that doesn't have a css equivalent |
| 18:41 | <rniwa> | TabAtkins: right now, dir=auto is a weird beast that doesn't have a css equivalent |
| 18:44 | <TabAtkins> | rniwa: Ah, kk. |
| 18:44 | <TabAtkins> | rniwa: Ah, kk. |
| 18:44 | <TabAtkins> | We don't really like 'direction', though. |
| 18:44 | <TabAtkins> | I'm not opposed to it, but 'direction' was a mistake. |
| 18:45 | <TabAtkins> | We don't really like 'direction', though. |
| 18:45 | <TabAtkins> | I'm not opposed to it, but 'direction' was a mistake. |
| 18:45 | <TabAtkins> | And it's possible that the CSSWG will object to further extending it. |
| 18:45 | <TabAtkins> | But perhaps not. |
| 18:45 | <TabAtkins> | I dunno. |
| 18:45 | <TabAtkins> | But perhaps not. |
| 18:45 | <TabAtkins> | I dunno. |
| 18:47 | <zcorpan> | i suspect that browsers that implement dir="" by mapping it to 'direction' today would want to use a css value when implementing dir=auto |
| 18:47 | <zcorpan> | i suspect that browsers that implement dir="" by mapping it to 'direction' today would want to use a css value when implementing dir=auto |
| 18:57 | <rniwa> | zcorpan: right. |
| 18:57 | <rniwa> | zcorpan: right now, we have lots of code that deals with dir=auto :( |
| 18:57 | <rniwa> | zcorpan: because the computed value still needs to be left/right |
| 18:57 | <rniwa> | zcorpan: right. |
| 18:57 | <rniwa> | zcorpan: right now, we have lots of code that deals with dir=auto :( |
| 18:57 | <rniwa> | zcorpan: because the computed value still needs to be left/right |
| 18:57 | <zcorpan> | ugh |
| 18:57 | <rniwa> | and we need to sort of re-implement style resolution mechanism just for dir=auto |
| 18:58 | <zcorpan> | ugh |
| 18:58 | <rniwa> | and we need to sort of re-implement style resolution mechanism just for dir=auto |
| 18:58 | <rniwa> | direction supports inherit, etc... |
| 18:58 | <rniwa> | it's really annoying from implementor's point of view |
| 18:58 | <rniwa> | direction supports inherit, etc... |
| 18:58 | <rniwa> | it's really annoying from implementor's point of view |
| 18:59 | <zcorpan> | in that case i think we should add auto as a css value and drop the complexity |
| 18:59 | <zcorpan> | in that case i think we should add auto as a css value and drop the complexity |
| 19:00 | <zcorpan> | even if the css wg doesn't want to spec it :-P |
| 19:00 | <zcorpan> | but that's just imho |
| 19:00 | <zcorpan> | but that's just imho |
| 19:01 | <TabAtkins> | Sure, that's all a good argument. |
| 19:01 | <TabAtkins> | Sure, that's all a good argument. |
| 19:03 | <rniwa> | zcorpan, TabAtkins: okay. |
| 19:03 | <rniwa> | i guess we can prefix and add -webkit-auto for now |
| 19:04 | <rniwa> | zcorpan, TabAtkins: okay. |
| 19:04 | <rniwa> | i guess we can prefix and add -webkit-auto for now |
| 19:04 | <zcorpan> | nooooooo :-) |
| 19:04 | <zcorpan> | call it auto :-) |
| 19:04 | <Ms2ger> | Call it -o-auto |
| 19:04 | <rniwa> | Ms2ger: LOL |
| 19:04 | <zcorpan> | nooooooo :-) |
| 19:04 | <zcorpan> | call it auto :-) |
| 19:04 | <Ms2ger> | Call it -o-auto |
| 19:04 | <rniwa> | Ms2ger: LOL |
| 19:05 | <Ms2ger> | Or -proprietary-do-not-ever-use-this-in-production-code-auto |
| 19:05 | <gsnedders> | Nah, implement -webkit-webkit-auto. All the cool kids use -webkit- prefixes. |
| 19:05 | <Ms2ger> | Or -proprietary-do-not-ever-use-this-in-production-code-auto |
| 19:05 | <gsnedders> | Nah, implement -webkit-webkit-auto. All the cool kids use -webkit- prefixes. |
| 19:05 | <rniwa> | Ms2ger: I think direciton: auto will be useful. |
| 19:06 | <rniwa> | Ms2ger: I think direciton: auto will be useful. |
| 19:06 | <rniwa> | Ms2ger: since browsers already support dir=auto pretty well (so not much according to bidi experts but reasonably well) |
| 19:06 | <rniwa> | Ms2ger: it's probably fine to just add auto |
| 19:06 | <rniwa> | Ms2ger: since browsers already support dir=auto pretty well (so not much according to bidi experts but reasonably well) |
| 19:06 | <rniwa> | Ms2ger: it's probably fine to just add auto |
| 19:06 | <rniwa> | zcorpan: can someone add that to CSS3 writing mode spec? |
| 19:07 | <rniwa> | zcorpan: can someone add that to CSS3 writing mode spec? |
| 19:07 | <rniwa> | i'm more than happy to file a bug but.. |
| 19:07 | <Ms2ger> | Yeah, suggest it on the list, the Cabal^WWG will get to it in 2035 |
| 19:07 | <rniwa> | i'm more than happy to file a bug but.. |
| 19:07 | <Ms2ger> | Yeah, suggest it on the list, the Cabal^WWG will get to it in 2035 |
| 19:07 | <rniwa> | Ms2ger: unfortunately i've been kicked out of www-style due to some mail deamon issue |
| 19:07 | <Ms2ger> | I heard |
| 19:07 | <rniwa> | and i'm reluctant to go through all the troubles to get back on it :( |
| 19:08 | <rniwa> | Ms2ger: unfortunately i've been kicked out of www-style due to some mail deamon issue |
| 19:08 | <Ms2ger> | I heard |
| 19:08 | <rniwa> | and i'm reluctant to go through all the troubles to get back on it :( |
| 19:08 | <Ms2ger> | MikeSmith, can't you fix that? |
| 19:08 | <Ms2ger> | MikeSmith, can't you fix that? |
| 19:10 | <rniwa> | filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=16456 |
| 19:10 | <rniwa> | filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=16456 |
| 19:13 | <zcorpan> | rniwa: thanks. i don't know who the someone is, though :-) |
| 19:13 | <zcorpan> | rniwa: thanks. i don't know who the someone is, though :-) |
| 19:16 | <rniwa> | zcorpan: seems like it's fantasai |
| 19:17 | <rniwa> | zcorpan: seems like it's fantasai |
| 19:18 | <TabAtkins> | Yes, fantasai is the one to bug about Writing Modes. |
| 19:18 | <TabAtkins> | Yes, fantasai is the one to bug about Writing Modes. |
| 20:05 | <smaug____> | aklein: finally I found the bug which caused failures in your or rafaels testTreeMirror.html |
| 20:05 | <smaug____> | aklein: now both test.html and testTreeMirror.html pass |
| 20:05 | <smaug____> | (except I have the change to make filtering case-sensitive) |
| 20:05 | <smaug____> | aklein: finally I found the bug which caused failures in your or rafaels testTreeMirror.html |
| 20:05 | <smaug____> | aklein: now both test.html and testTreeMirror.html pass |
| 20:05 | <smaug____> | (except I have the change to make filtering case-sensitive) |
| 20:10 | <annevk> | does the spec say attribute filtering is case-insensitive, because I would definitely consider that a bug? |
| 20:10 | <annevk> | does the spec say attribute filtering is case-insensitive, because I would definitely consider that a bug? |
| 20:14 | <smaug____> | annevk: no |
| 20:14 | <smaug____> | annevk: that is a bug in webkit |
| 20:15 | <smaug____> | annevk: no |
| 20:15 | <smaug____> | annevk: that is a bug in webkit |
| 20:15 | <smaug____> | well, I say it is a bug, aklein disagrees :) |
| 20:15 | <smaug____> | well, I say it is a bug, aklein disagrees :) |
| 20:18 | <annevk> | interesting |
| 20:18 | <annevk> | well as long as nobody files a bug on the spec, it's a bug in WebKit |
| 20:18 | <annevk> | but DOM APIs are generally case-sensitive, with a couple of exceptions |
| 20:18 | <annevk> | well as long as nobody files a bug on the spec, it's a bug in WebKit |
| 20:18 | <annevk> | but DOM APIs are generally case-sensitive, with a couple of exceptions |
| 20:18 | <smaug____> | exactly |
| 20:18 | <annevk> | so it seems better to stick to that here |
| 20:19 | <smaug____> | exactly |
| 20:19 | <annevk> | so it seems better to stick to that here |
| 20:19 | <smaug____> | and old DOMAttrModified requires case sensitive filtering (in the listener) |
| 20:19 | <smaug____> | and old DOMAttrModified requires case sensitive filtering (in the listener) |
| 20:20 | <annevk> | does the case-insensitiveness depend on the node's namespace? |
| 20:20 | <annevk> | though even it seems wrong |
| 20:20 | <annevk> | does the case-insensitiveness depend on the node's namespace? |
| 20:20 | <annevk> | though even it seems wrong |
| 20:21 | <smaug____> | annevk: it depends on ownerdocument, I believe |
| 20:21 | <annevk> | e.g. if you have <html:p TEST="" test=""/> you would not be able to distinguish between the two attributes |
| 20:21 | <smaug____> | in HTML doc, case-insensitive |
| 20:21 | <smaug____> | annevk: it depends on ownerdocument, I believe |
| 20:21 | <smaug____> | it doesn't really make sense to me |
| 20:21 | <annevk> | is there an open bug in WebKit on that? |
| 20:21 | <annevk> | e.g. if you have <html:p TEST="" test=""/> you would not be able to distinguish between the two attributes |
| 20:21 | <smaug____> | in HTML doc, case-insensitive |
| 20:21 | <smaug____> | it doesn't really make sense to me |
| 20:21 | <annevk> | is there an open bug in WebKit on that? |
| 20:21 | <smaug____> | haven't filed |
| 20:22 | <smaug____> | haven't filed |
| 20:22 | <annevk> | if you do, let me know, I'll add my +1 |
| 20:22 | <annevk> | if you do, let me know, I'll add my +1 |
| 20:56 | <aklein> | back from lunch, I see that the case sensitivity issue has been mostly settled :) |
| 20:56 | <aklein> | back from lunch, I see that the case sensitivity issue has been mostly settled :) |
| 20:56 | <aklein> | annevk: but I wanted to clarify how WebKit's impl works, because I think there's a misunderstanding |
| 20:57 | <aklein> | annevk: but I wanted to clarify how WebKit's impl works, because I think there's a misunderstanding |
| 20:57 | <aklein> | it's only case-insensitive if the element with the attribute is an HTML element in an HTML document |
| 20:57 | <aklein> | if it's an XML document, then the filter is case-sensitive |
| 20:57 | <aklein> | it's only case-insensitive if the element with the attribute is an HTML element in an HTML document |
| 20:57 | <aklein> | if it's an XML document, then the filter is case-sensitive |
| 20:58 | <aklein> | anyway, just wanted to throw that out there, I don't think I care enough to argue much further (and it's easy to "fix" in webkit, the implementation is clearly easier if it's always case-sensitive) |
| 20:58 | <aklein> | anyway, just wanted to throw that out there, I don't think I care enough to argue much further (and it's easy to "fix" in webkit, the implementation is clearly easier if it's always case-sensitive) |
| 21:00 | <annevk> | I would personally prefer if we do not introduce more of it given that HTML actually generates a case-sensitive DOM |
| 21:00 | <annevk> | I would personally prefer if we do not introduce more of it given that HTML actually generates a case-sensitive DOM |
| 21:00 | <annevk> | the parser actively lowercases names when creating nodes and attributes |
| 21:01 | <annevk> | the parser actively lowercases names when creating nodes and attributes |
| 21:01 | <annevk> | that setAttribute() and such behave similarly is a legacy aspect of our predecessors not really knowing what they were doing :pdf |
| 21:01 | <annevk> | that setAttribute() and such behave similarly is a legacy aspect of our predecessors not really knowing what they were doing :pdf |
| 21:01 | <annevk> | oops, meant :p there |
| 21:02 | <annevk> | oops, meant :p there |
| 21:02 | <aklein> | ok, that's was smaug____'s argument as well, so I'll defer to y'all. |
| 21:03 | <rniwa> | aklein, annevk: I support making it case sensitive |
| 21:03 | <rniwa> | it's cheaper to compare that way :) |
| 21:04 | <rniwa> | aklein, annevk: I support making it case sensitive |
| 21:04 | <rniwa> | it's cheaper to compare that way :) |
| 21:04 | <annevk> | making rniwa's day by nanosecond perf improvements; yay |
| 21:05 | <annevk> | making rniwa's day by nanosecond perf improvements; yay |
| 21:05 | <rniwa> | annevk: yeah, I don't like case insensitive comparison period. |
| 21:05 | <rniwa> | it's confusing and has surprising effects |
| 21:05 | <rniwa> | annevk: yeah, I don't like case insensitive comparison period. |
| 21:05 | <rniwa> | it's confusing and has surprising effects |
| 21:07 | <rafaelw_> | annevk: so my concern is that webdevs will do observe(node, { attributeFilter: 'HREF' ]) |
| 21:07 | <rafaelw_> | and never get any indication why that does nothing. |
| 21:08 | <rafaelw_> | annevk: so my concern is that webdevs will do observe(node, { attributeFilter: 'HREF' ]) |
| 21:08 | <rafaelw_> | and never get any indication why that does nothing. |
| 21:08 | <Ms2ger> | We can always warn about that :) |
| 21:08 | <rafaelw_> | which is especially confusion because they would have markup that has <A HREF='FOO'> |
| 21:08 | <Ms2ger> | We can always warn about that :) |
| 21:08 | <rafaelw_> | which is especially confusion because they would have markup that has <A HREF='FOO'> |
| 21:08 | <rafaelw_> | or do anchor.setAttribute('FOO', 'bar'); |
| 21:08 | <rafaelw_> | and anchor.getAttribute('FOO') // returns 'bar' |
| 21:09 | <rafaelw_> | or do anchor.setAttribute('FOO', 'bar'); |
| 21:09 | <annevk> | rafaelw_: I thought you argued earlier those kind of developers would use a library |
| 21:09 | <rafaelw_> | and anchor.getAttribute('FOO') // returns 'bar' |
| 21:09 | <annevk> | rafaelw_: I thought you argued earlier those kind of developers would use a library |
| 21:09 | <annevk> | rafaelw_: we cannot both have this be a low-level and high-level API at the same time |
| 21:09 | <rafaelw_> | and node.matchesSelector('[HREF]') |
| 21:09 | <rafaelw_> | and that will work. |
| 21:09 | <rafaelw_> | meaning, everything else they do seems to work, but this doesn.t |
| 21:09 | <annevk> | rafaelw_: we cannot both have this be a low-level and high-level API at the same time |
| 21:09 | <rafaelw_> | and node.matchesSelector('[HREF]') |
| 21:09 | <rafaelw_> | and that will work. |
| 21:09 | <rafaelw_> | meaning, everything else they do seems to work, but this doesn.t |
| 21:09 | <rafaelw_> | ms2ger, i don't see how we'll warn. |
| 21:10 | <rafaelw_> | ms2ger, i don't see how we'll warn. |
| 21:10 | <rafaelw_> | annevk: i don't think the library can do anything. |
| 21:10 | <Ms2ger> | In the console when you call observe? |
| 21:10 | <rafaelw_> | annevk: i don't think the library can do anything. |
| 21:10 | <annevk> | a library can lowercase |
| 21:10 | <Ms2ger> | In the console when you call observe? |
| 21:10 | <annevk> | a library can lowercase |
| 21:10 | <rniwa> | rafaelw_: but attributeFilter isn't a selector list, right? |
| 21:11 | <rniwa> | rafaelw_: but attributeFilter isn't a selector list, right? |
| 21:11 | <rafaelw_> | ok, then by that logic, why not just either lowercase all attributes in attributeFilter or throw an error if there are upper case? |
| 21:11 | <annevk> | I think it's unfortunate we made querySelector case-insensitive |
| 21:11 | <rafaelw_> | ok, then by that logic, why not just either lowercase all attributes in attributeFilter or throw an error if there are upper case? |
| 21:11 | <rniwa> | annevk: yeah |
| 21:11 | <annevk> | I think that was mostly because we had not figured out the new world HTML DOM |
| 21:11 | <annevk> | I think it's unfortunate we made querySelector case-insensitive |
| 21:11 | <rniwa> | annevk: yeah |
| 21:11 | <annevk> | I think that was mostly because we had not figured out the new world HTML DOM |
| 21:11 | <annevk> | (which is the same as the "XML DOM" plus some quirks) |
| 21:12 | <annevk> | (which is the same as the "XML DOM" plus some quirks) |
| 21:12 | <zcorpan> | rafaelw_: what if you want to observe 'viewBox' on <svg> in an html doc? |
| 21:12 | <zcorpan> | rafaelw_: what if you want to observe 'viewBox' on <svg> in an html doc? |
| 21:12 | <annevk> | zcorpan: if we do it we'd do isHTMLDocument && ele.namespaceURI == HTMLNS |
| 21:13 | <annevk> | zcorpan: if we do it we'd do isHTMLDocument && ele.namespaceURI == HTMLNS |
| 21:13 | <zcorpan> | annevk: ah yeah |
| 21:13 | <zcorpan> | annevk: ah yeah |
| 21:13 | <rniwa> | annevk, zcorpan, rafaelw_: we could do case-insensitive comparison for html attributes inside a html document |
| 21:13 | <rniwa> | annevk, zcorpan, rafaelw_: we could do case-insensitive comparison for html attributes inside a html document |
| 21:13 | <rniwa> | but i'd rather not |
| 21:13 | <rniwa> | it complicates the api |
| 21:14 | <rniwa> | but i'd rather not |
| 21:14 | <rniwa> | it complicates the api |
| 21:14 | <rniwa> | given that all attribute names and element names are converted into lower-case equivalent, i don't see why case-insensitive comparison is useful today. |
| 21:14 | <rniwa> | given that all attribute names and element names are converted into lower-case equivalent, i don't see why case-insensitive comparison is useful today. |
| 21:14 | <zcorpan> | case-sensitive sounds good to me, everyone uses lowercase anyway |
| 21:15 | <zcorpan> | case-sensitive sounds good to me, everyone uses lowercase anyway |
| 21:15 | <annevk> | and there's actually problems with some of the case-insensitive stuff today |
| 21:15 | <annevk> | while the HTML parser only does ASCII |
| 21:15 | <annevk> | and there's actually problems with some of the case-insensitive stuff today |
| 21:15 | <annevk> | while the HTML parser only does ASCII |
| 21:15 | <annevk> | setAttribute also lowercases characters outside ASCII |
| 21:15 | <annevk> | similarly Selectors are not doing ASCII case-insensitive |
| 21:16 | <annevk> | setAttribute also lowercases characters outside ASCII |
| 21:16 | <annevk> | similarly Selectors are not doing ASCII case-insensitive |
| 21:16 | <zcorpan> | maybe if somebody uses data-fooBar=baz and then observes 'data-fooBar', that won't work and might be confusing |
| 21:16 | <annevk> | I think we can still fix that however |
| 21:16 | <rafaelw_> | annevk: so i'd likely handle this exactly as you suggest in the library: lower-case the attributes. |
| 21:16 | <zcorpan> | maybe if somebody uses data-fooBar=baz and then observes 'data-fooBar', that won't work and might be confusing |
| 21:16 | <annevk> | I think we can still fix that however |
| 21:16 | <rafaelw_> | annevk: so i'd likely handle this exactly as you suggest in the library: lower-case the attributes. |
| 21:16 | <rafaelw_> | this will have the effect of simply not supporting SVG documents or elements. |
| 21:16 | <zcorpan> | annevk: that seems like bugs in setAttribute and selectors |
| 21:17 | <rafaelw_> | this will have the effect of simply not supporting SVG documents or elements. |
| 21:17 | <zcorpan> | annevk: that seems like bugs in setAttribute and selectors |
| 21:17 | <rafaelw_> | ms2ger: warning at observe() doesn't work. |
| 21:18 | <rafaelw_> | ms2ger: warning at observe() doesn't work. |
| 21:18 | <rafaelw_> | at that point, you don't know what elements will ultimatley have mutations. |
| 21:18 | <annevk> | zcorpan: yeah I haven't had time to research that and file the appropriate bugs yet |
| 21:18 | <annevk> | maybe tomorrow |
| 21:18 | <rafaelw_> | a document can be mixed with XML and html elements. |
| 21:18 | <annevk> | because it really stinks |
| 21:18 | <rafaelw_> | at that point, you don't know what elements will ultimatley have mutations. |
| 21:18 | <annevk> | zcorpan: yeah I haven't had time to research that and file the appropriate bugs yet |
| 21:18 | <annevk> | maybe tomorrow |
| 21:18 | <rafaelw_> | a document can be mixed with XML and html elements. |
| 21:18 | <annevk> | because it really stinks |
| 21:18 | <zcorpan> | rafaelw_: we can easily support svg by checking the namespace of the element |
| 21:19 | <zcorpan> | rafaelw_: we can easily support svg by checking the namespace of the element |
| 21:19 | <rafaelw_> | support *in what*? |
| 21:19 | <annevk> | if this turns out to be a common source of problems, I think we can still make it insensitive then |
| 21:19 | <annevk> | and otherwise libraries can just lowercase, because all attributes will be lowercase anyway |
| 21:19 | <rafaelw_> | support *in what*? |
| 21:19 | <annevk> | if this turns out to be a common source of problems, I think we can still make it insensitive then |
| 21:19 | <annevk> | and otherwise libraries can just lowercase, because all attributes will be lowercase anyway |
| 21:19 | <zcorpan> | rafaelw_: observe(node, { attributeFilter: 'HREF' ]) |
| 21:20 | <zcorpan> | rafaelw_: observe(node, { attributeFilter: 'HREF' ]) |
| 21:20 | <zcorpan> | rafaelw_: if we decide to go for case-insensitive there |
| 21:20 | <zcorpan> | rafaelw_: if we decide to go for case-insensitive there |
| 21:20 | <rafaelw_> | annevk: expect XML elements, right? |
| 21:20 | <rafaelw_> | s/expect/except/ |
| 21:21 | <rafaelw_> | annevk: expect XML elements, right? |
| 21:21 | <rafaelw_> | s/expect/except/ |
| 21:21 | <rafaelw_> | zcorpan: I don't understand what you are proposing. |
| 21:21 | <rafaelw_> | zcorpan: I don't understand what you are proposing. |
| 21:21 | <zcorpan> | hold on lemme read the spec |
| 21:22 | <zcorpan> | hold on lemme read the spec |
| 21:22 | <rniwa> | odd. i thought qualified attribute names preserve the case but apparently not :( |
| 21:22 | <rniwa> | at least on webkit & firefox |
| 21:22 | <Hixie> | if someone calls addHitRegion() with arguments that make no sense, what exception should we throw? |
| 21:22 | <Hixie> | a new one? |
| 21:22 | <annevk> | rafaelw_: yeah, I guess it would not work for SVG or some such, so you probably need to use a map |
| 21:23 | <rniwa> | odd. i thought qualified attribute names preserve the case but apparently not :( |
| 21:23 | <rniwa> | at least on webkit & firefox |
| 21:23 | <Hixie> | if someone calls addHitRegion() with arguments that make no sense, what exception should we throw? |
| 21:23 | <Hixie> | a new one? |
| 21:23 | <Hixie> | i don't see one for "your arguments are illogical" |
| 21:23 | <annevk> | rafaelw_: yeah, I guess it would not work for SVG or some such, so you probably need to use a map |
| 21:23 | <Hixie> | i don't see one for "your arguments are illogical" |
| 21:23 | <rniwa> | all attributes on html elements are turned into lower-case equivalents |
| 21:23 | Hixie | considers creating a new SpockUnhappyException |
| 21:23 | <rafaelw_> | "use a map"? |
| 21:23 | <annevk> | viewbox->viewBox |
| 21:23 | Hixie | considers creating a new SpockUnhappyException |
| 21:23 | <rafaelw_> | "use a map"? |
| 21:23 | <annevk> | viewbox->viewBox |
| 21:23 | <Hixie> | or rather, SpockUnimpressedError |
| 21:23 | <annevk> | :) |
| 21:24 | <Hixie> | or rather, SpockUnimpressedError |
| 21:24 | <annevk> | :) |
| 21:24 | <Hixie> | annevk: any suggestions? |
| 21:24 | <Hixie> | NotSupportedError? |
| 21:24 | <Hixie> | annevk: any suggestions? |
| 21:24 | <annevk> | I think minting a cool new one is fine |
| 21:24 | <annevk> | but yeah, NotSupportedError works |
| 21:24 | <Ms2ger> | Could use SyntaxError |
| 21:24 | <Hixie> | NotSupportedError? |
| 21:24 | <annevk> | I think minting a cool new one is fine |
| 21:24 | <annevk> | but yeah, NotSupportedError works |
| 21:24 | <Ms2ger> | Could use SyntaxError |
| 21:24 | <Hixie> | SyntaxError seems wrong since there's no syntax here really |
| 21:24 | <Hixie> | it's the semantics that are wrong |
| 21:25 | <Hixie> | SyntaxError seems wrong since there's no syntax here really |
| 21:25 | <Hixie> | it's the semantics that are wrong |
| 21:25 | <Hixie> | i'll use NotSupportedError unless you mint me a better one |
| 21:26 | <Hixie> | i'll use NotSupportedError unless you mint me a better one |
| 21:28 | <zcorpan> | rafaelw_: in http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-mutationobserver-observe if target is in the html namespace and target's node document is an html document, ascii-lowercase the attributeFilter names |
| 21:28 | <zcorpan> | rafaelw_: in http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-mutationobserver-observe if target is in the html namespace and target's node document is an html document, ascii-lowercase the attributeFilter names |
| 21:29 | <Hixie> | heycam: why does the algorithm for converting a JS value to an IDL dictionary not take into account default values? |
| 21:30 | <rafaelw_> | zcorpan: and what do you do if the observation is configured with subtree: true? |
| 21:31 | <rafaelw_> | zcorpan: and what do you do if the observation is configured with subtree: true? |
| 21:31 | <rafaelw_> | i.e. you directly observe the root of an HTML document that contains some SVG elements? |
| 21:32 | <rafaelw_> | i.e. you directly observe the root of an HTML document that contains some SVG elements? |
| 21:32 | <rafaelw_> | (and use subtree observation) |
| 21:32 | <zcorpan> | rafaelw_: ah, that wouldn't work, would it. it'd need to lowercase in http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-mo-queue-attributes instead |
| 21:32 | <rafaelw_> | (and use subtree observation) |
| 21:32 | <zcorpan> | rafaelw_: ah, that wouldn't work, would it. it'd need to lowercase in http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-mo-queue-attributes instead |
| 21:32 | <zcorpan> | rafaelw_: but then i think it is better to always be case-sensitive |
| 21:32 | <rafaelw_> | correct. that's more or less the behavior currrently in webkit. |
| 21:33 | <zcorpan> | rafaelw_: but then i think it is better to always be case-sensitive |
| 21:33 | <rafaelw_> | correct. that's more or less the behavior currrently in webkit. |
| 21:40 | <rafaelw_> | i don't really understand this idea that HTML is generally case-sensitive. what developer-visible behavior would suggest that? |
| 21:40 | <rafaelw_> | i don't really understand this idea that HTML is generally case-sensitive. what developer-visible behavior would suggest that? |
| 21:42 | <Hixie> | XML, the DOM, and CSS are generally case-sensitive, HTML isn't |
| 21:42 | <Hixie> | URLs, too |
| 21:42 | <Hixie> | (are case-sensitive) |
| 21:42 | <Hixie> | XML, the DOM, and CSS are generally case-sensitive, HTML isn't |
| 21:42 | <Hixie> | URLs, too |
| 21:42 | <Hixie> | (are case-sensitive) |
| 21:42 | <Hixie> | (HTML is a mess though) |
| 21:43 | <Hixie> | (HTML is a mess though) |
| 21:43 | <rafaelw_> | Hixie, right. Not sure if you're following the Mutation Observers discussion. The question is whether attributeFilter should match case-insensitively against HTML elements in HTML documents. |
| 21:43 | <Hixie> | oh, the element names are case-sensitive, sure |
| 21:43 | <Hixie> | they're always lowercase, specifically |
| 21:43 | <Hixie> | but that's not HTML |
| 21:43 | <Hixie> | that's the DOM |
| 21:43 | <rafaelw_> | Hixie, right. Not sure if you're following the Mutation Observers discussion. The question is whether attributeFilter should match case-insensitively against HTML elements in HTML documents. |
| 21:43 | <Hixie> | oh, the element names are case-sensitive, sure |
| 21:43 | <Hixie> | they're always lowercase, specifically |
| 21:43 | <Hixie> | but that's not HTML |
| 21:43 | <Hixie> | that's the DOM |
| 21:43 | <rafaelw_> | the issue is attribute names |
| 21:43 | <Hixie> | same with attribute names |
| 21:43 | <Hixie> | HTML attribute names are always lowercase, SVG's are mixed |
| 21:44 | <rafaelw_> | the issue is attribute names |
| 21:44 | <Hixie> | same with attribute names |
| 21:44 | <Hixie> | HTML attribute names are always lowercase, SVG's are mixed |
| 21:44 | <Hixie> | they're all case-sensitive though in the DOM |
| 21:44 | <Hixie> | they're all case-sensitive though in the DOM |
| 21:44 | <Hixie> | i don't see why you'd be case-insensitive there, that's not HTML |
| 21:45 | <Hixie> | i don't see why you'd be case-insensitive there, that's not HTML |
| 21:49 | <zcorpan> | Hixie: getAttribute, setAttribute, removeAttribute, hasAttribute all case-fold to lowercase for html elements in html docs |
| 21:49 | <rafaelw_> | I understand that's how the DOM is spec'd. It seems to me that the behavior of HTML appears to case-insensitive. |
| 21:49 | <zcorpan> | Hixie: getAttribute, setAttribute, removeAttribute, hasAttribute all case-fold to lowercase for html elements in html docs |
| 21:49 | <rafaelw_> | I understand that's how the DOM is spec'd. It seems to me that the behavior of HTML appears to case-insensitive. |
| 21:49 | <Hixie> | zcorpan: yeah but they're wacked |
| 21:49 | <zcorpan> | Hixie: that's a different argument :-) |
| 21:49 | <rafaelw_> | hixie: what's not wacked? |
| 21:49 | <Hixie> | rafaelw_: there are apis that are historically case-insensitive, i'll grant you |
| 21:50 | <Hixie> | zcorpan: yeah but they're wacked |
| 21:50 | <zcorpan> | Hixie: that's a different argument :-) |
| 21:50 | <rafaelw_> | hixie: what's not wacked? |
| 21:50 | <Hixie> | rafaelw_: there are apis that are historically case-insensitive, i'll grant you |
| 21:50 | <rafaelw_> | i.e. if i'm a web-developer, what API would suggest to me that HTML APIS are case-sensitive |
| 21:50 | <Hixie> | the main reason i wouldn't go there as a spec author is that it is a huge pain to maintain apis that are sometimes case-sensitive |
| 21:50 | <Hixie> | people like zcorpan find bugs in those apis for months |
| 21:50 | <rafaelw_> | i.e. if i'm a web-developer, what API would suggest to me that HTML APIS are case-sensitive |
| 21:50 | <Hixie> | the main reason i wouldn't go there as a spec author is that it is a huge pain to maintain apis that are sometimes case-sensitive |
| 21:50 | <Hixie> | people like zcorpan find bugs in those apis for months |
| 21:50 | <zcorpan> | why does http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-element-getelementsbytagname seems confused about localName and qualifiedName |
| 21:51 | <zcorpan> | why does http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-element-getelementsbytagname seems confused about localName and qualifiedName |
| 21:51 | <zcorpan> | er |
| 21:51 | <Hixie> | case in point ^ |
| 21:51 | <zcorpan> | s/why does// |
| 21:51 | <zcorpan> | er |
| 21:51 | <Hixie> | case in point ^ |
| 21:51 | <zcorpan> | s/why does// |
| 21:56 | <rafaelw_> | Hixie: getElementsByTagName is your example to my question above? |
| 21:57 | <rafaelw_> | Hixie: getElementsByTagName is your example to my question above? |
| 21:57 | <Hixie> | no, it's my example of zcorpan finding bugs for months in apis that try to be clever |
| 21:58 | <Hixie> | no, it's my example of zcorpan finding bugs for months in apis that try to be clever |
| 22:00 | <rafaelw_> | sorry if i'm being difficult. i'm trying to understand the objection to being case-insensitive in the common case (HTML elements in HTML document). |
| 22:01 | <rafaelw_> | sorry if i'm being difficult. i'm trying to understand the objection to being case-insensitive in the common case (HTML elements in HTML document). |
| 22:01 | <rafaelw_> | I'm not clear if the argument is that it's bad behavior, if it's prone to produce bugs? |
| 22:01 | <rafaelw_> | I'm not clear if the argument is that it's bad behavior, if it's prone to produce bugs? |
| 22:01 | <Hixie> | i don't really object, as spec writer you do what you think is best :-) |
| 22:01 | <Hixie> | i'm just saying that from one spec writer to another, your life will be easier if you make it case-sensitive |
| 22:02 | <Hixie> | i don't really object, as spec writer you do what you think is best :-) |
| 22:02 | <Hixie> | i'm just saying that from one spec writer to another, your life will be easier if you make it case-sensitive |
| 22:02 | <rafaelw_> | Ok. I get that. I'm fine having my life be more difficult if it results in a better API. that seems like my job. |
| 22:02 | <Hixie> | the underlying infrastructure is case-sensitive, so any case-insensitive logic has to be layered on top of that |
| 22:02 | <rafaelw_> | Ok. I get that. I'm fine having my life be more difficult if it results in a better API. that seems like my job. |
| 22:02 | <Hixie> | the underlying infrastructure is case-sensitive, so any case-insensitive logic has to be layered on top of that |
| 22:03 | <rafaelw_> | it's already implemented in webkit. it's possible there are bugs, but the implementation seems simple enough (and doesn't have a perf cost in the common case). |
| 22:03 | <rafaelw_> | it's already implemented in webkit. it's possible there are bugs, but the implementation seems simple enough (and doesn't have a perf cost in the common case). |
| 22:03 | <zcorpan> | this should be pretty simple to get right i think |
| 22:03 | <smaug____> | I don't see any reason for case-insensitive filters |
| 22:04 | <zcorpan> | this should be pretty simple to get right i think |
| 22:04 | <smaug____> | I don't see any reason for case-insensitive filters |
| 22:04 | <smaug____> | this is new API |
| 22:04 | <smaug____> | and even with the old mutation events one needs to use case-sensitive comparisons |
| 22:04 | <smaug____> | this is new API |
| 22:04 | <smaug____> | and even with the old mutation events one needs to use case-sensitive comparisons |
| 22:04 | <rafaelw_> | the reason is that it'll be surprising that it's *not* case sensitive. it will silently fail. |
| 22:04 | <smaug____> | (when filtering attributes in DOMAttrModified listener) |
| 22:05 | <rafaelw_> | the reason is that it'll be surprising that it's *not* case sensitive. it will silently fail. |
| 22:05 | <smaug____> | (when filtering attributes in DOMAttrModified listener) |
| 22:05 | <smaug____> | why would anyone use uppercase attr names as filters when dealing with HTML doc? |
| 22:05 | <smaug____> | why would anyone use uppercase attr names as filters when dealing with HTML doc? |
| 22:05 | <smaug____> | it the API clearly says that it is not case sensitive |
| 22:06 | <smaug____> | it the API clearly says that it is not case sensitive |
| 22:06 | <zcorpan> | smaug____: they might use an attribute data-fooBar="" in the markup and observe for "data-fooBar" |
| 22:06 | <smaug____> | DOMAttrModified isn't case-insensitive |
| 22:06 | <zcorpan> | smaug____: they might use an attribute data-fooBar="" in the markup and observe for "data-fooBar" |
| 22:06 | <smaug____> | DOMAttrModified isn't case-insensitive |
| 22:06 | <smaug____> | zcorpan: that is just a bug |
| 22:07 | <smaug____> | zcorpan: that is just a bug |
| 22:07 | <Hixie> | is anyone arguing that the api should be case-insensitive for svg? |
| 22:07 | <Hixie> | or mathml? |
| 22:07 | <rafaelw_> | nope. |
| 22:07 | <Hixie> | if not, why not? it seems like most arguments for html would apply to those too |
| 22:07 | <Hixie> | is anyone arguing that the api should be case-insensitive for svg? |
| 22:07 | <Hixie> | or mathml? |
| 22:07 | <rafaelw_> | nope. |
| 22:07 | <Hixie> | if not, why not? it seems like most arguments for html would apply to those too |
| 22:07 | <Hixie> | (other than consistency with the wacked api entry points) |
| 22:07 | <zcorpan> | smaug____: still, it's probably a surprise to an author who does it and doesn't know the details of html/dom case sensitivity |
| 22:07 | <Hixie> | (but they're already inconsistent with others) |
| 22:08 | <Hixie> | (other than consistency with the wacked api entry points) |
| 22:08 | <zcorpan> | smaug____: still, it's probably a surprise to an author who does it and doesn't know the details of html/dom case sensitivity |
| 22:08 | <rafaelw_> | can we just stop for a second. |
| 22:08 | <Hixie> | (but they're already inconsistent with others) |
| 22:08 | <rafaelw_> | can we just stop for a second. |
| 22:08 | <rafaelw_> | every keeps saying "wacked" API. |
| 22:08 | <rniwa> | rafaelw_, smaug____, zcorpan: my expectation is that anyone who's good enough to use new mutation observer api would know that all html attributes are converted into lowercase names |
| 22:08 | <rafaelw_> | can someone give me an example of NON-wacked api? |
| 22:08 | <Hixie> | on the web? is that a trick question? :-) |
| 22:08 | <rniwa> | and if they don't, then they're good enough to write tests to figure it out themselves |
| 22:08 | <rafaelw_> | every keeps saying "wacked" API. |
| 22:08 | <rniwa> | rafaelw_, smaug____, zcorpan: my expectation is that anyone who's good enough to use new mutation observer api would know that all html attributes are converted into lowercase names |
| 22:08 | <rafaelw_> | can someone give me an example of NON-wacked api? |
| 22:08 | <Hixie> | on the web? is that a trick question? :-) |
| 22:08 | <rniwa> | and if they don't, then they're good enough to write tests to figure it out themselves |
| 22:08 | <smaug____> | rniwa: indeed |
| 22:08 | <rafaelw_> | i'm trying to make the point that webdevs expectation is that HTML DOM apis are case-insensitive. |
| 22:09 | <smaug____> | rniwa: indeed |
| 22:09 | <smaug____> | rafaelw_: they are not |
| 22:09 | <rafaelw_> | i'm trying to make the point that webdevs expectation is that HTML DOM apis are case-insensitive. |
| 22:09 | <smaug____> | rafaelw_: they are not |
| 22:09 | <rafaelw_> | querySelector behaves to be |
| 22:09 | <rafaelw_> | setAttribute |
| 22:09 | <smaug____> | some APIs convert parameter to lowercase or uppercase |
| 22:09 | <rafaelw_> | hasAttribute |
| 22:09 | <rniwa> | i guess i've lived in pure XML world too long |
| 22:09 | <Hixie> | Element.namespaceURI, .prefix, .localName all return the internal case |
| 22:09 | <rafaelw_> | querySelector behaves to be |
| 22:09 | <rafaelw_> | setAttribute |
| 22:09 | <smaug____> | some APIs convert parameter to lowercase or uppercase |
| 22:09 | <rafaelw_> | hasAttribute |
| 22:09 | <rniwa> | i guess i've lived in pure XML world too long |
| 22:09 | <Hixie> | Element.namespaceURI, .prefix, .localName all return the internal case |
| 22:09 | <smaug____> | MutationObserver is a new API |
| 22:09 | <Hixie> | .className and getElementsByClassName() are case-sensitive |
| 22:09 | <zcorpan> | Hixie: nobody uses those |
| 22:09 | <Hixie> | speak for yourself |
| 22:10 | <smaug____> | MutationObserver is a new API |
| 22:10 | <Hixie> | .className and getElementsByClassName() are case-sensitive |
| 22:10 | <zcorpan> | Hixie: nobody uses those |
| 22:10 | <Hixie> | speak for yourself |
| 22:10 | <rniwa> | smaug____, Hixie, zcorpan: i think it makes sense for it be case insensitive if we're going to support simple selectors in the future |
| 22:10 | <rafaelw_> | yes. but for all of those, the DOM has forced as case for the storage of the names |
| 22:10 | <Hixie> | setAttributeNS() seems to be case-sensitive too |
| 22:10 | <zcorpan> | no, i speak for web developers at large, not for myself or for you :-) |
| 22:10 | <rafaelw_> | so the effect appears to be that they are case-insensitive. |
| 22:10 | <Hixie> | rafaelw_: ? |
| 22:10 | <rniwa> | smaug____, Hixie, zcorpan: i think it makes sense for it be case insensitive if we're going to support simple selectors in the future |
| 22:10 | <rafaelw_> | yes. but for all of those, the DOM has forced as case for the storage of the names |
| 22:10 | <Hixie> | setAttributeNS() seems to be case-sensitive too |
| 22:10 | <zcorpan> | no, i speak for web developers at large, not for myself or for you :-) |
| 22:10 | <rafaelw_> | so the effect appears to be that they are case-insensitive. |
| 22:10 | <Hixie> | rafaelw_: ? |
| 22:11 | <rafaelw_> | div = document.createElement('div'); |
| 22:11 | <zcorpan> | className and getElementsByClassName are case-sensitive in selectors as well, so authors are used to that |
| 22:11 | <Hixie> | rafaelw_: createElementNS() doesn't lowercase anything |
| 22:11 | <rafaelw_> | div.tagName; // 'DIV" |
| 22:11 | <rafaelw_> | div = document.createElement('div'); |
| 22:11 | <zcorpan> | className and getElementsByClassName are case-sensitive in selectors as well, so authors are used to that |
| 22:11 | <Hixie> | rafaelw_: createElementNS() doesn't lowercase anything |
| 22:11 | <rafaelw_> | div.tagName; // 'DIV" |
| 22:11 | <rafaelw_> | no one uses createElementNS |
| 22:11 | <Hixie> | rafaelw_: div.localName; // 'div' |
| 22:11 | <rniwa> | Hixie: btw, i've just realized that all attributes on an html element (even ones with namespace) will be have lowercase names. |
| 22:11 | <Hixie> | rafaelw_: no one uses mutation observers either |
| 22:11 | <rniwa> | Hixie: and i think that's rather unintuitive... |
| 22:12 | <rafaelw_> | no one uses createElementNS |
| 22:12 | <Hixie> | rafaelw_: div.localName; // 'div' |
| 22:12 | <rniwa> | Hixie: btw, i've just realized that all attributes on an html element (even ones with namespace) will be have lowercase names. |
| 22:12 | <Hixie> | rafaelw_: no one uses mutation observers either |
| 22:12 | <rniwa> | Hixie: and i think that's rather unintuitive... |
| 22:12 | <Hixie> | rniwa: text/html HTML elements don't have namespaces |
| 22:12 | <rafaelw_> | I never knew there was a 'localName' |
| 22:12 | <Hixie> | rniwa: text/html HTML elements don't have namespaces |
| 22:12 | <rafaelw_> | I never knew there was a 'localName' |
| 22:12 | <Hixie> | rafaelw_: you asked for apis that aren't wacked. i'm letting you know that dom core has plenty of apis that are case-sensitive. whether you know about them or not doesn't change the api... |
| 22:12 | smaug____ | uses localName all the time |
| 22:12 | <zcorpan> | Hixie: we could make localName preserve case precisely because nobody used it |
| 22:13 | <Hixie> | rafaelw_: you asked for apis that aren't wacked. i'm letting you know that dom core has plenty of apis that are case-sensitive. whether you know about them or not doesn't change the api... |
| 22:13 | smaug____ | uses localName all the time |
| 22:13 | <zcorpan> | Hixie: we could make localName preserve case precisely because nobody used it |
| 22:13 | <zcorpan> | Hixie: if people had used it, we would be forced to make it return uppercase |
| 22:13 | <zcorpan> | Hixie: if people had used it, we would be forced to make it return uppercase |
| 22:13 | <Hixie> | zcorpan: and we did it because it's a better thing to do, right? |
| 22:13 | <zcorpan> | Hixie: yeah |
| 22:13 | <Hixie> | zcorpan: i rest my case :-) |
| 22:13 | <zcorpan> | since otherwise it's not possible to get the real case of an element |
| 22:13 | <Hixie> | zcorpan: and we did it because it's a better thing to do, right? |
| 22:13 | <zcorpan> | Hixie: yeah |
| 22:13 | <Hixie> | zcorpan: i rest my case :-) |
| 22:13 | <zcorpan> | since otherwise it's not possible to get the real case of an element |
| 22:14 | <Hixie> | if we make mutation observers canonicalise case for filters of HTML elements, there'd be no way to catch changes to attributes that aren't lowercase |
| 22:14 | <Hixie> | if we make mutation observers canonicalise case for filters of HTML elements, there'd be no way to catch changes to attributes that aren't lowercase |
| 22:14 | <zcorpan> | right |
| 22:15 | <zcorpan> | right |
| 22:15 | <Hixie> | anyway i think this is up to rafaelw_ to decide. there are arguments on both sides. |
| 22:15 | <Hixie> | personally i think clever apis tend to cost more than they're worth on the long run |
| 22:15 | <Hixie> | anyway i think this is up to rafaelw_ to decide. there are arguments on both sides. |
| 22:15 | <Hixie> | personally i think clever apis tend to cost more than they're worth on the long run |
| 22:15 | <Hixie> | but despite that i'm always making "clever" apis |
| 22:15 | <smaug____> | (why is it up to rafaelw_ to decide ? ) |
| 22:15 | <Hixie> | smaug____: isn't he writing the spec? |
| 22:16 | <Hixie> | but despite that i'm always making "clever" apis |
| 22:16 | <smaug____> | (why is it up to rafaelw_ to decide ? ) |
| 22:16 | <Hixie> | smaug____: isn't he writing the spec? |
| 22:16 | <Hixie> | so i can certainly understand the attraction here |
| 22:16 | <smaug____> | no |
| 22:16 | <Hixie> | smaug____: oh. who is? |
| 22:16 | <Hixie> | so i can certainly understand the attraction here |
| 22:16 | <smaug____> | no |
| 22:16 | <Hixie> | smaug____: oh. who is? |
| 22:16 | <zcorpan> | it's part of dom4 |
| 22:16 | <rniwa> | Hixie: i think aklein wrote some draft and then annevk merged it into dom 4 |
| 22:16 | <Hixie> | well imho it's up to whoever is writing the spec, whoever that is :-) |
| 22:17 | <zcorpan> | it's part of dom4 |
| 22:17 | <rniwa> | Hixie: i think aklein wrote some draft and then annevk merged it into dom 4 |
| 22:17 | <Hixie> | well imho it's up to whoever is writing the spec, whoever that is :-) |
| 22:17 | <rniwa> | Hixie: AryehGregor and annevk's call then :) |
| 22:17 | <Hixie> | (and then up to the implementors to decide if that makes sense, of course) |
| 22:17 | <rniwa> | also Ms2ger's |
| 22:17 | <rniwa> | Hixie: AryehGregor and annevk's call then :) |
| 22:17 | <Hixie> | (and then up to the implementors to decide if that makes sense, of course) |
| 22:17 | <rniwa> | also Ms2ger's |
| 22:17 | <Hixie> | should be one person's call as far as the spec goes |
| 22:18 | <Hixie> | should be one person's call as far as the spec goes |
| 22:18 | <Hixie> | having co-editors means blame gets split, which reduces accountability |
| 22:18 | <Hixie> | having co-editors means blame gets split, which reduces accountability |
| 22:21 | <smaug_____> | nice, this laptop suddenly decided to ask PUK |
| 22:21 | <smaug_____> | nice, this laptop suddenly decided to ask PUK |
| 22:21 | <smaug_____> | Hixie: anne has been updating the spec, and aklein wrote some of it, and I designed large part of it with rafaelw_ and aklein |
| 22:22 | <smaug_____> | Hixie: anne has been updating the spec, and aklein wrote some of it, and I designed large part of it with rafaelw_ and aklein |
| 22:24 | <rafaelw_> | i don't really care to die on this hill. it just seems like it's convenient for us and makes life harder for webdevs. |
| 22:24 | <rafaelw_> | i'm fine letting anne make the call. |
| 22:24 | <rafaelw_> | i don't really care to die on this hill. it just seems like it's convenient for us and makes life harder for webdevs. |
| 22:24 | <rafaelw_> | i'm fine letting anne make the call. |
| 22:25 | <rafaelw_> | FWIW, for libraries (like mutation observers), if the behavior is always case-sensitive, then the sane thing to do is to simply lower-case the attributeFilter if the doc is HTML |
| 22:26 | <rafaelw_> | FWIW, for libraries (like mutation observers), if the behavior is always case-sensitive, then the sane thing to do is to simply lower-case the attributeFilter if the doc is HTML |
| 22:26 | <rafaelw_> | which will fail to handle the case of SVG or MATHML elements in an HTML document. |
| 22:27 | <zcorpan> | rafaelw_: yeah that's a good argument to let browsers do the case folding |
| 22:27 | <zcorpan> | rafaelw_: yeah that's a good argument to let browsers do the case folding |
| 22:28 | <Hixie> | rafaelw_: honestly i don't understand why any authors would ever pass in uppercase attribute names here |
| 22:28 | <Hixie> | rafaelw_: (why would a library wrap this api? is the api not usable directly?) |
| 22:28 | <Hixie> | rafaelw_: honestly i don't understand why any authors would ever pass in uppercase attribute names here |
| 22:28 | <Hixie> | rafaelw_: (why would a library wrap this api? is the api not usable directly?) |
| 22:28 | <smaug_____> | if one really needs to handle attrs case-insentively, it is always possible to filter records in the callback |
| 22:28 | <rafaelw_> | my experience of webdevs is that they think that all of HTML is case-insensitive. |
| 22:28 | <smaug_____> | insensitively |
| 22:28 | <TabAtkins> | That is my experience as a webdev. |
| 22:29 | <smaug_____> | if one really needs to handle attrs case-insentively, it is always possible to filter records in the callback |
| 22:29 | <rafaelw_> | my experience of webdevs is that they think that all of HTML is case-insensitive. |
| 22:29 | <smaug_____> | insensitively |
| 22:29 | <TabAtkins> | That is my experience as a webdev. |
| 22:29 | <Hixie> | we should transition them away from that viewpoint, since that viewpoint doesn't match reality and will just cause them bugs |
| 22:29 | <Hixie> | we should transition them away from that viewpoint, since that viewpoint doesn't match reality and will just cause them bugs |
| 22:29 | <rafaelw_> | hixie: http://code.google.com/p/mutation-summary/ |
| 22:30 | <rafaelw_> | hixie: http://code.google.com/p/mutation-summary/ |
| 22:31 | <Hixie> | rafaelw_: do you lowercase the inputs in that api? |
| 22:31 | <rafaelw_> | smaug: to do that, you'd have to take the input attributeFilter, wrap it, and output an attributeFilter that had every permutation of lower-vs-upper-case. |
| 22:32 | <Hixie> | rafaelw_: do you lowercase the inputs in that api? |
| 22:32 | <rafaelw_> | smaug: to do that, you'd have to take the input attributeFilter, wrap it, and output an attributeFilter that had every permutation of lower-vs-upper-case. |
| 22:32 | <rafaelw_> | not yet. i'm saying, i'll probably make that change if we make this one. |
| 22:32 | <rafaelw_> | not yet. i'm saying, i'll probably make that change if we make this one. |
| 22:32 | <Hixie> | lame |
| 22:32 | <Hixie> | :-P |
| 22:33 | <Hixie> | lame |
| 22:33 | <Hixie> | :-P |
| 22:33 | <rafaelw_> | i think our leverage to "push" webdevs to do anything next to nothing. |
| 22:33 | <rafaelw_> | i think our leverage to "push" webdevs to do anything next to nothing. |
| 22:33 | <smaug_____> | rafaelw_: why. JS filter could work just like your C++ filter |
| 22:34 | <smaug_____> | rafaelw_: why. JS filter could work just like your C++ filter |
| 22:34 | <smaug_____> | keep too lists, case-sensitive and lowercase |
| 22:34 | <smaug_____> | attributes in HTML are lowercase |
| 22:34 | <smaug_____> | keep too lists, case-sensitive and lowercase |
| 22:34 | <smaug_____> | attributes in HTML are lowercase |
| 22:34 | <smaug_____> | so filtering would be fast |
| 22:34 | <rniwa> | +1 to Hixie's idea of transitioning them to the new view point |
| 22:35 | <smaug_____> | so filtering would be fast |
| 22:35 | <rniwa> | +1 to Hixie's idea of transitioning them to the new view point |
| 22:36 | <rafaelw_> | smaug: that's true, actually. |
| 22:36 | <rafaelw_> | that would probably work. |
| 22:36 | <rafaelw_> | smaug: that's true, actually. |
| 22:36 | <rafaelw_> | that would probably work. |
| 22:37 | <rniwa> | btw, i think changing the spec later to support insensitive comparison is a fairly safe change to make |
| 22:37 | <rniwa> | btw, i think changing the spec later to support insensitive comparison is a fairly safe change to make |
| 22:37 | <rniwa> | so if enough people complain when this api becomes more widely known |
| 22:37 | <rniwa> | then we should be able to change |
| 22:37 | <rniwa> | so if enough people complain when this api becomes more widely known |
| 22:37 | <rniwa> | then we should be able to change |
| 22:39 | <smaug____> | rafaelw_: btw, do you remember if the spec for innerHTML has been updated to support MutationObserver |
| 22:39 | <smaug____> | rafaelw_: btw, do you remember if the spec for innerHTML has been updated to support MutationObserver |
| 22:39 | <rniwa> | smaug____: it doesn't support now? |
| 22:40 | <rniwa> | smaug____: it doesn't support now? |
| 22:40 | <smaug____> | rniwa: the batching part might need some tweaking |
| 22:40 | <smaug____> | rniwa: the batching part might need some tweaking |
| 22:40 | <smaug____> | I mean that all the removed nodes end up to .removedNodes, and new nodes to .addedNodes |
| 22:41 | <smaug____> | I mean that all the removed nodes end up to .removedNodes, and new nodes to .addedNodes |
| 22:41 | <aklein> | smaug____: looks like it uses "replace all" |
| 22:41 | <aklein> | http://html5.org/specs/dom-parsing.html#innerhtml |
| 22:41 | <rniwa> | smaug____: that sounds reasonable to me. |
| 22:41 | <aklein> | smaug____: looks like it uses "replace all" |
| 22:41 | <aklein> | http://html5.org/specs/dom-parsing.html#innerhtml |
| 22:41 | <rniwa> | smaug____: that sounds reasonable to me. |
| 22:41 | <aklein> | smaug____: so it should work |
| 22:41 | <rniwa> | smaug____: why do we want a different behavior here? |
| 22:42 | <aklein> | smaug____: so it should work |
| 22:42 | <rniwa> | smaug____: why do we want a different behavior here? |
| 22:42 | <smaug____> | aklein: ah, good. (replace all was broken in DOM4 still yesterday :) ) |
| 22:42 | <smaug____> | aklein: ah, good. (replace all was broken in DOM4 still yesterday :) ) |
| 22:42 | <smaug____> | rniwa: what different behavior |
| 22:43 | <smaug____> | rniwa: what different behavior |
| 22:45 | <rniwa> | smaug____: so i just got confused by your question. |
| 22:45 | <rniwa> | |
| 22:45 | <rniwa> | smaug____: i thought you were proposing to do something special for innerHTML |
| 22:45 | <rniwa> | smaug____: as it's not the case, we're on the same page here |
| 22:46 | <rniwa> | smaug____: so i just got confused by your question. |
| 22:46 | <rniwa> | smaug____: i thought you were proposing to do something special for innerHTML |
| 22:46 | <rniwa> | smaug____: as it's not the case, we're on the same page here |
| 22:46 | <smaug____> | good :) |
| 22:46 | <smaug____> | good :) |
| 22:49 | <rafaelw_> | smaug: |
| 22:49 | <rafaelw_> | smaug: |
| 22:50 | <rniwa> | smaug____, Hixie: odd, i thought there was a way to obtain a fully qualified name of a html element but i can't find any api for that :\ |
| 22:50 | <rafaelw_> | hixie: annevk: ok. i yield. smaug_'s suggestion is a good one. i'll just support this at the library level. |
| 22:50 | <rniwa> | smaug____, Hixie: odd, i thought there was a way to obtain a fully qualified name of a html element but i can't find any api for that :\ |
| 22:50 | <rafaelw_> | hixie: annevk: ok. i yield. smaug_'s suggestion is a good one. i'll just support this at the library level. |
| 22:53 | <Hixie> | rafaelw_: i'm not arguing specifically for either side, i think both sides have good arguments, fwiw |
| 22:53 | <Hixie> | rafaelw_: i'm not arguing specifically for either side, i think both sides have good arguments, fwiw |
| 22:53 | <Hixie> | rafaelw_: i'm just being devil's advocate |
| 22:53 | <Hixie> | rafaelw_: so that we can fully explore the issue :-) |
| 22:54 | <Hixie> | rafaelw_: i'm just being devil's advocate |
| 22:54 | <Hixie> | rafaelw_: so that we can fully explore the issue :-) |
| 22:54 | <Hixie> | rafaelw_: as i said earlier, i think this is the kind of thing we should just leave to the editor (then to be sanity-checked by implementors, of course) |
| 22:54 | <Hixie> | rafaelw_: as i said earlier, i think this is the kind of thing we should just leave to the editor (then to be sanity-checked by implementors, of course) |
| 22:54 | <rafaelw_> | hixie: that's the discussion we've been having. |
| 22:55 | <rafaelw_> | hixie: that's the discussion we've been having. |
| 22:55 | <rafaelw_> | annevk is the editor. adamk, myself & smaug are the implementors. |
| 22:55 | <Hixie> | right, but i'm not :-) |
| 22:55 | <rafaelw_> | ah. i see. |
| 22:55 | <rafaelw_> | annevk is the editor. adamk, myself & smaug are the implementors. |
| 22:55 | <Hixie> | right, but i'm not :-) |
| 22:55 | <rafaelw_> | ah. i see. |
| 22:55 | <rafaelw_> | anyhow. i prefer having consistent behavior in this case, to having my preferred behavior. |
| 22:56 | <rafaelw_> | anyhow. i prefer having consistent behavior in this case, to having my preferred behavior. |
| 22:56 | <Hixie> | there's so many different behaviours here already that anything we do will be consistent with _something_. :-) |
| 22:56 | <Hixie> | there's so many different behaviours here already that anything we do will be consistent with _something_. :-) |