| 01:35 | <AryehGregor> | Whee, I just got WebKit to make a Range whose end offset is greater than the length of its end node. |
| 01:36 | <AryehGregor> | While IE makes a Range whose start and end node don't have a common ancestor. |
| 01:36 | <AryehGregor> | Nice. |
| 01:37 | <AryehGregor> | data:text/html,<!doctype html><body><script>var text = document.createTextNode("Abcdef"); var range = document.createRange(); range.setStart(text, 0); range.setEnd(text, 2); text.splitText(1); document.body.textContent = range.startContainer.data + range.startOffset + range.endContainer.data + range.endOffset;</script> |
| 01:37 | <AryehGregor> | Chrome 11 dev: A0A2 |
| 01:38 | <AryehGregor> | IE 9: A0bcdef2 |
| 01:52 | <roc> | nice testcase |
| 01:53 | <roc> | I wonder if you can trigger interesting bugs in Webkit by using that range |
| 01:53 | <AryehGregor> | Gecko just doesn't special-case splitText(), so it does A0A1. |
| 01:53 | <AryehGregor> | Which is bad overall, IMO, so I'm speccing WebKit's behavior here (but with corner cases correctly handled :) ). |
| 01:53 | <AryehGregor> | Yeah, I was wondering that too. |
| 01:54 | <AryehGregor> | Or in IE. |
| 01:54 | <roc> | so what do you think the correct answer is? |
| 01:54 | <AryehGregor> | In this case, I think Gecko is right. |
| 01:54 | <roc> | oh I see |
| 01:54 | <AryehGregor> | But in the normal case, where the text node isn't detached, it should be A0bcdef1. |
| 01:54 | <AryehGregor> | Because that's logically what the range is. |
| 01:54 | <roc> | yeah |
| 14:15 | <karlcow> | MikeSmith: is it the most recent? http://sideshowbarker.github.com/console-spec/ |
| 14:16 | <karlcow> | still no editor for it? |
| 14:27 | <MikeSmith> | karlcow: yeah, that is the latest |
| 14:27 | <MikeSmith> | and no editor |
| 14:27 | <MikeSmith> | other than me |
| 14:27 | <karlcow> | MikeSmith: thanks |
| 15:33 | <funkie> | question. |
| 15:35 | <funkie> | I have my header set up and whatnot |
| 15:35 | <funkie> | using header and nav, |
| 15:35 | <funkie> | where the content goes, can I use a <section> tag? |
| 15:36 | <funkie> | it's not a complicated website, and the section tag here will be used to store and have all the info about the company in the different links of the website |
| 15:36 | <funkie> | is this correct use? |
| 15:36 | <funkie> | (I got direceted here by HTML5 for web designers by Jeremy keith |
| 15:36 | <funkie> | ) |
| 15:37 | <jgraham> | Roughly speaking a <section> is a grouping of content under a <hx> heading |
| 15:38 | <jgraham> | So if each bit of content has a <hx> then <section> is indeed right |
| 15:39 | <funkie> | hx is header right? |
| 15:42 | <jgraham> | <h1> or <h2> or whatever |
| 16:14 | <karlcow> | html5 nytimes. Checked. http://www.nytimes.com/2011/03/27/business/27unboxed.html?_r=1&src=tptw&pagewanted=print |
| 17:39 | <foolip_> | huh, Hixie isn't here? |
| 17:47 | <karlcow> | Google has a limited notion of browser support http://www.google.com/support/profiles/bin/answer.py?answer=1151309 |
| 18:25 | <hsivonen> | karlcow: :-( At least this time the outdated icon is the Firefox icon--not the Opera icon |
| 18:26 | <zewt> | it's pretty gross to see Google doing the exclusive-list-of-supported-browsers thing ... they should be setting a better example |
| 18:26 | <nimbupani> | ha google is a big monster now. |
| 18:26 | <nimbupani> | so many different teams in so many different directions. |
| 18:27 | <karlcow> | zewt, it is because the last paragraph about Interoperability and Open Web has been cut. It was after the 60 words limit. |
| 18:28 | <zewt> | heh, know what made me lose hope in sanity-of-google? |
| 18:28 | <zewt> | "Change background image" |
| 18:28 | <karlcow> | :) |
| 18:28 | <zewt> | clearly this is the single most important feature in all of Google |
| 19:57 | <foolip_> | Hixie, do you intend to write a CP for ISSUE-147? |
| 20:43 | <Hixie> | foolip_: if you could write one that would save me a lot of time, but if you don't i expect i'll get around to it at some point |
| 21:25 | <smaug____> | AryehGregor: are you proposing to change DOM Range |
| 21:25 | <smaug____> | or behavior of selection? |
| 21:25 | <AryehGregor> | smaug____, it would be pretty weird if the behavior of selections didn't follow from ranges, wouldn't it? |
| 21:25 | <AryehGregor> | I'm suggesting we change ranges, and selections will follow. |
| 21:26 | <AryehGregor> | (It's a change to DOM Range either way, if by "DOM Range" you mean the new version Ms2ger wrote and that I'm working on, and not the old DOM Level 2 Range spec) |
| 21:26 | <smaug____> | AryehGregor: I'm not sure I follow <p>{Foo<i>bar</i>} case |
| 21:26 | <AryehGregor> | Which part? |
| 21:26 | <smaug____> | why would you move nodes nodes one by one |
| 21:26 | <AryehGregor> | How else can you move them? |
| 21:27 | <smaug____> | extract all to documentfragment |
| 21:27 | <AryehGregor> | Interesting. |
| 21:27 | <AryehGregor> | That would destroy the range no matter what we do. But you're just saying we can manually reconstruct it afterwards easily enough, right? |
| 21:27 | <smaug____> | and then insert the documenfragment to the right place |
| 21:28 | <smaug____> | destroy the range? |
| 21:28 | <smaug____> | why |
| 21:28 | <AryehGregor> | I mean, collapse it. |
| 21:29 | <smaug____> | hmm |
| 21:29 | <smaug____> | should <b> end up in the range |
| 21:29 | <smaug____> | or outside it |
| 21:29 | <AryehGregor> | Probably outside, if we assume that when the user starts typing it should replace the selection and should be bold. |
| 21:29 | <smaug____> | right |
| 21:30 | <AryehGregor> | Anyway, there are other cases where I need to mutate things. Like for instance, if you bold here: <b>fo[o</b>bar] I change it to: <b>fo[obar]</b> preserving the original element. |
| 21:30 | <AryehGregor> | (Gecko does this too, IIRC, at least in some cases.) |
| 21:31 | <smaug____> | it would be, IMO, just a bit strange to special this in DOM Range |
| 21:31 | <smaug____> | but need to think about it some more |
| 21:31 | <AryehGregor> | You mean, to special-case it when a node is being moved to a more or less adjacent position? |
| 21:31 | <smaug____> | yes |
| 21:32 | <AryehGregor> | It actually seems very logical to me that you don't want to treat it like a totally different node in that case. It naturally satisfies all of my execCommand() selection-mutation needs without any need for extra prose in the execCommand() spec. |
| 21:32 | <smaug____> | selection is different thing than just pure DOM range |
| 21:32 | <AryehGregor> | How so? Selections are specced as just a list of Ranges. |
| 21:32 | <smaug____> | DOM Range spec may be bad, but at least it is quite consistent |
| 21:33 | <smaug____> | sure, once user has done a selection, it shows up as a range |
| 21:33 | <smaug____> | user, script, whatever |
| 21:34 | <AryehGregor> | But? |
| 21:35 | <smaug____> | browsers may modify ranges the way they need |
| 21:35 | <AryehGregor> | What do you mean? |
| 21:35 | <AryehGregor> | I know WebKit and Opera don't allow all Ranges to be part of Selections, but that's not what the spec says or what IE/Gecko do. |
| 21:35 | <smaug____> | I mean, in case of selection and execCommand, browsers could just handle range the way you want DOM range to work always |
| 21:36 | <smaug____> | but as I said, I need to think about this some more |
| 21:37 | <AryehGregor> | Why would you want ranges to work differently in other cases? Are there applications of Range where the current model is more useful? |
| 21:37 | <AryehGregor> | (Actually, I'm not sure offhand what applications there are of Ranges at all, beyond editing-related stuff.) |
| 21:38 | <smaug____> | copy-paste at least |
| 21:38 | <smaug____> | d&d |
| 21:38 | <AryehGregor> | Is the current model more useful there, or are you just mentioning use-cases? |
| 21:38 | <smaug____> | although those are close to editing |
| 21:39 | <AryehGregor> | Copy-paste is definitely Selection-related. |
| 21:39 | <AryehGregor> | Anyway, I wouldn't be totally against special-casing Selections here, but I don't see why we'd want to. |
| 21:40 | <smaug____> | I'm just worried about adding a bit strange special case to DOM Range, which otherwise is pretty consistently defined |
| 21:41 | <smaug____> | AryehGregor: but as I said, need to think this some more |
| 21:41 | <AryehGregor> | There are already some special cases for other DOM mutations, like insertData() and deleteData() (which behave differently from setting the data attribute). |
| 21:41 | <AryehGregor> | But anyway, go ahead and think about it. |
| 21:42 | <AryehGregor> | I'm happy to hear feedback. |
| 21:51 | <smaug____> | AryehGregor: what do you mean with insertdeleteData() and data setting? what is the special case there? |
| 21:52 | <smaug____> | I may have forgotten something about DOM Ranges :) |
| 21:52 | <AryehGregor> | Well, you could argue it's not actually a special case, I guess. |
| 21:52 | <AryehGregor> | But, e.g., node.appendData("foo") behaves differently from node.data += "foo" with respect to Range mutation. |
| 21:52 | <AryehGregor> | The DOM Level 2 Range is very vague about it. |
| 21:53 | <AryehGregor> | The spec I've written so far to precisely define how CharacterData nodes should behave when their data is changed is probably about as long as it would take to define my proposed scheme for node insertions/deletions. |
| 21:54 | <smaug____> | oh, but node.data += "foo" replaces the whole value with new one |
| 21:54 | <AryehGregor> | Yeah, so you could say it's not logically a special case, but in the spec it has to be a special case. |
| 21:54 | <AryehGregor> | At least if you're precise. |
| 21:55 | <smaug____> | I would expect node.data += work differently to appendData |
| 21:55 | <smaug____> | I wonder what browsers do |
| 21:55 | <AryehGregor> | It works differently. |
| 21:55 | <AryehGregor> | (I'm writing tests for it right now to go with my spec text, should be ready by tomorrow sometime) |
| 21:56 | <AryehGregor> | My current philosophy is that we should match what's the most logical even if it's more complicated, but you seem to be not entirely happy with that for Ranges. |
| 21:56 | <AryehGregor> | What do you feel about splitText()? |
| 21:56 | <AryehGregor> | If you have a text node like "Ab[cd]ef" and do splitText(3), what happens to the range? |
| 21:57 | <AryehGregor> | "Ab[c]" "def" is what the preexisting specs would suggest, and what Gecko and Opera do. But "Ab[c" "d]ef" would make more sense, and is what WebKit does. |
| 21:57 | <smaug____> | I don't know what is not logical in DOM Range |
| 21:58 | <smaug____> | oh, there Ab[c is the right one |
| 21:58 | <AryehGregor> | By "logical" I mean "what people would expect in the specific case", not "obeys some kind of consistent internal logic". |
| 21:58 | <AryehGregor> | Well, that means we have to special-case splitText(). On general principle, you'd say that some data was deleted from the first node and an unrelated new node was inserted, so the end of the range is lost, right? |
| 21:58 | <AryehGregor> | (which is what Gecko does right now) |
| 21:59 | <smaug____> | right |
| 21:59 | <smaug____> | what is the special case? |
| 21:59 | <AryehGregor> | http://aryeh.name/tmp/dom-range.html#range-behavior-under-document-mutation |
| 21:59 | <AryehGregor> | There's no way to do it that I see except to say "When splitText() is run, take these special steps." |
| 21:59 | <smaug____> | just a second... I want to test data += handling in gecko |
| 22:00 | <AryehGregor> | Setting data just resets the offset to 0 in all cases that I tested. |
| 22:00 | <AryehGregor> | In both Gecko and WebKit. |
| 22:00 | <smaug____> | good |
| 22:00 | <smaug____> | that is what I was expecting |
| 22:00 | <AryehGregor> | In Opera it sets start offsets to 0 and end offsets to the new data's length, and in IE it does somewhat weird stuff. |
| 22:00 | <AryehGregor> | (like in some cases changing the start/end nodes of the range) |
| 22:01 | <AryehGregor> | Relatedly, if you have something like {Foobar} (start/end containers are the parent of the text node, not the text node itself) and do splitText(3), all browsers produce {Foo}bar. |
| 22:01 | <smaug____> | surprising that Webkit resets offsets in that case, but it follows some other logic with insertNode ... |
| 22:02 | <roc> | it would be kinda cool if += behaved like append() but expressing that in WebIDL would not be easy |
| 22:02 | <AryehGregor> | I.e., they keep the boundary point offset intact, so it's now logically in the middle of the split string, instead of advancing it by one. |
| 22:02 | <smaug____> | well, += is part of JS |
| 22:03 | <AryehGregor> | It was surprising to me as an author that document.innerHTML += stuff; would actually wipe out everything in the document and recreate it from scratch, instead of appending to it in-place. |
| 22:04 | <AryehGregor> | Can built-in stuff override the semantics of += separately from =? Like how in C++ you can overload different assignment operators differently? |
| 22:04 | <smaug____> | I don't think it is possible to override += |
| 22:04 | <smaug____> | otherwise that would have been done in browsers |
| 22:04 | <smaug____> | innerHTML += shows up in *many* performance tests |
| 22:05 | <AryehGregor> | Well, you could get ES changed to allow it, right? |
| 22:06 | <smaug____> | innerHTML += may have other problems too, since you really need to reparse the whole result, I think |
| 22:07 | <roc> | probably the easiest way to "fix" += would be to have a special case for setting .data based on whether the old value is a prefix of the new value |
| 22:07 | <roc> | ditto for innerHTML |
| 22:07 | <AryehGregor> | Is that actually true? The contents of innerHTML are serialized from a DOM, so they're going to have all end tags closed and so on. |
| 22:07 | <roc> | but that could trip people up too |
| 22:07 | <AryehGregor> | Interesting. You could also special-case suffixing that way. |
| 22:07 | <AryehGregor> | Not insertData(), though. |
| 22:07 | <AryehGregor> | (currently the spec special-cases setting data to the exact same thing, matching WebKit but seemingly no one else) |
| 22:08 | <AryehGregor> | (but if implementers would prefer fewer special cases in Range for whatever reason, I could simplify it) |
| 22:08 | <smaug____> | what does the spec say about that? |
| 22:08 | <AryehGregor> | About what? |
| 22:08 | <smaug____> | setting .data to the exact same thing |
| 22:08 | <roc> | I mean if you just write "foo.data = str;" it might be bad for that to behave differently if "str" is accidentally an extension of the old value |
| 22:08 | <AryehGregor> | The spec I just wrote in the last three hours or so says that setting .data to the exact same thing shouldn't change any Ranges. |
| 22:08 | <smaug____> | um |
| 22:08 | <AryehGregor> | There's no spec for it before that, I don't think. |
| 22:09 | <smaug____> | that is possible |
| 22:09 | <AryehGregor> | DOM Level 2 Range doesn't say how you should handle it. You could conjecture that setting data should be like removing all the data and then adding the new data. |
| 22:10 | <AryehGregor> | But you could also conjecture that setting it to the current content should be special-cased. |
| 22:10 | <AryehGregor> | It doesn't say. |
| 22:11 | <smaug____> | have you specced insertNode? |
| 22:11 | <AryehGregor> | No, not yet. |
| 22:11 | <smaug____> | just curious |
| 22:11 | <AryehGregor> | Are there any tricky bits in it? |
| 22:11 | <smaug____> | since Acid3 allows two different behaviors for it |
| 22:11 | <AryehGregor> | Interesting. |
| 22:11 | <smaug____> | the one DOM 2 Range specs |
| 22:11 | <smaug____> | and then one Webkit implements |
| 22:11 | <AryehGregor> | Heh. |
| 22:11 | <AryehGregor> | Well, if I spec it, I'll write tests that only allow one behavior. :) |
| 22:12 | <smaug____> | (and after Acid3 Opera change their behavior from spec to webkit) |
| 22:12 | <smaug____> | s/change/changed/ |
| 22:12 | <AryehGregor> | What's the difference? |
| 22:12 | <smaug____> | IIRC, whether or not change collapsed range |
| 22:13 | <smaug____> | (I think Opera changed their behavior because for some time Acid3 didn't allow what the spec says) |
| 22:29 | <foolip_> | Hixie, if I write it, it will be a zero-edit proposal, is that what you wanted as well? |
| 22:33 | <Hixie> | foolip_: i don't know what i want since i'm still trying to understand the issue (see the e-mails i cited in my mail to sam that i'm waiting for replies on), and i haven't done the testing to see what browsers do |
| 22:33 | <Hixie> | foolip_: but a no-change proposal is certainly a subset of what i'd propose |
| 22:33 | <Hixie> | foolip_: so it works for me |
| 22:34 | <foolip_> | Hixie, ok, I'll write/send it tomorrow morning |
| 22:34 | <Hixie> | thanks dude |
| 22:34 | <Hixie> | much appreciated |
| 22:34 | <foolip_> | np, I just don't want to implement something weird for which I don't understand the use case |