| 00:41 | <MikeSmith> | have to pipe all of Mark Watson's e-mail public-html messages to "lynx -stdin -force_html" in order to figure out which parts are where he's quoting somebody and which parts he's saying himself |
| 00:45 | <MikeSmith> | well, need to do it for other messages to the list |
| 00:45 | <MikeSmith> | it's just that Mark's messages are ones that I actually want to read |
| 03:43 | <kennyluck> | "In this case, it seems entirely reasonable for other browsers (e.g., Firefox) to want to implement this feature. By putting it on navigator, we invite them to implement it as well." |
| 03:44 | <zewt> | netscape navigator? heh |
| 04:27 | <mrofsucof> | Hi... If a page gets opened in a hidden iframe by an anchor getting clicked, does its style become visited? |
| 06:44 | <MikeSmith> | "Zed Shaw out-Crockfords Crockford" |
| 07:01 | <hsivonen> | MikeSmith: that's a good way to put it |
| 07:02 | <hsivonen> | so I generated a public key pair using msys ssh and then copied the .pub file's line to .ssh/authorized_keys on the server |
| 07:02 | <hsivonen> | doesn't let me log in |
| 07:02 | <hsivonen> | where do I need to look? |
| 07:03 | <hsivonen> | Permission denied (publickey). |
| 07:03 | <MikeSmith> | hsivonen: you did ssh -v -v on the client? |
| 07:03 | <hsivonen> | no |
| 07:04 | <MikeSmith> | when I have problems I find that usually gives some worthwhile troubleshooting info |
| 07:04 | <MikeSmith> | hsivonen: also, you know it won't work if you don't have the perms set your .ssh directory on the serve |
| 07:04 | <MikeSmith> | and files in there |
| 07:05 | <MikeSmith> | all need to be 600 |
| 07:06 | <hsivonen> | the other keys there work |
| 07:07 | <rniwa> | sigh... why are we keep changing microdata API spec :( |
| 07:07 | <Ms2ger> | rniwa, because it's bogus :) |
| 07:08 | <hsivonen> | MikeSmith: the troubleshooting info just looks like the server didn't accept the key |
| 07:08 | <MikeSmith> | ok |
| 07:08 | <hsivonen> | MikeSmith: that, or the client offered the private key as the public key |
| 07:08 | <MikeSmith> | eh? |
| 07:09 | <hsivonen> | which would be terrible default config |
| 07:09 | <MikeSmith> | that would be weird |
| 07:09 | <hsivonen> | Offering public key: /home/Henri/.ssh/id_rsa |
| 07:09 | <hsivonen> | I hope that means really offering .pub |
| 07:16 | <hsivonen> | ssh-add -l says could not open connection to your authentication agent |
| 07:16 | <hsivonen> | the client side seems right |
| 07:17 | <MikeSmith> | hsivonen: you did eval `ssh-agent` already I guess |
| 07:17 | <hsivonen> | do I need to somehow make the server refresh authorized_keys changes? I don't remember having to do that before |
| 07:17 | <MikeSmith> | no |
| 07:17 | <MikeSmith> | you definitely don't need to do that |
| 07:19 | <hsivonen> | MikeSmith: I don't know what to do with the output of ssh-agent |
| 07:19 | <MikeSmith> | you need to eval it |
| 07:20 | <annevk> | rniwa: it changed? |
| 07:20 | <MikeSmith> | but anyway if you got that wrong you would still be able to ssh to that host |
| 07:20 | <rniwa> | annevk: yeah, it was clarification |
| 07:20 | <rniwa> | annevk: but nonetheless affected us |
| 07:20 | <MikeSmith> | hsivonen: the agent only affects forwarding once your on the remote host, right? |
| 07:20 | <Ms2ger> | I know that bz filed half a dozen bugs on it too |
| 07:20 | <rniwa> | annevk: elements with propitem="" should not be listed in the list :( |
| 07:20 | <hsivonen> | MikeSmith: now ssh-add -l says the agent has no identities |
| 07:20 | <rniwa> | annevk: anyway, i'm going to ask the contributor who has been implementing microdata API in webkit |
| 07:20 | <hsivonen> | MikeSmith: I have no clue what the agent does |
| 07:20 | <rniwa> | annevk: to submit our tests to w3c |
| 07:21 | <rniwa> | annevk: since we already have a quite few that are really good :) |
| 07:21 | <annevk> | I think Opera has submitted a bunch of tests already |
| 07:21 | <Ms2ger> | Yeah |
| 07:21 | <Ms2ger> | And David improved them when he implemented it in Gecko |
| 07:21 | <MikeSmith> | hsivonen: "eval $(ssh-agent) && ssh-add" |
| 07:21 | <annevk> | http://w3c-test.org/html/tests/submission/Opera/microdata/001.html |
| 07:21 | <annevk> | oh I see |
| 07:21 | <annevk> | Opera fails tests too now :/ |
| 07:22 | <rniwa> | annevk: oh nice! |
| 07:22 | <rniwa> | annevk: we should import those. |
| 07:23 | <hsivonen> | MikeSmith: thanks, but permission still denied |
| 07:24 | <hsivonen> | MikeSmith: and the client debug output suggests it was offering the right key anyway |
| 07:24 | <MikeSmith> | ok |
| 07:24 | <Ms2ger> | rniwa, review appreciated :) |
| 07:24 | <hsivonen> | aargh. why do things that usually just work have to fail mysteriously? |
| 07:26 | <rniwa> | Ms2ger: review which? |
| 07:26 | <Ms2ger> | The test |
| 07:26 | <rniwa> | Ms2ger: opera's? |
| 07:26 | <rniwa> | Ms2ger: I've asked the contributor to import 001.html |
| 07:26 | <Ms2ger> | Yeah |
| 07:26 | <rniwa> | Ms2ger: so presumably he's going to run it and verify that it works in webkit :) |
| 07:28 | <MikeSmith> | hsivonen: does the "ssh -v -v" output ever get to the point of saying "debug2: we sent a publickey packet, wait for reply" |
| 07:29 | <hsivonen> | MikeSmith: yes |
| 07:29 | <MikeSmith> | hsivonen: but not to "debug1: Server accepts key: ..." |
| 07:29 | <hsivonen> | MikeSmith: no |
| 07:29 | <MikeSmith> | that sucks |
| 07:30 | <MikeSmith> | so yeah, it seems like the client side is fine |
| 07:30 | <hsivonen> | MikeSmith: next it proceeds to trying id_dsa which doesn't exist |
| 07:30 | <hsivonen> | MikeSmith: yeah |
| 07:30 | <hsivonen> | MikeSmith: the server side is OK with keys from Ubuntu's OpenSSH, Mac OS X's OpenSSH and irssiconnectbot |
| 07:31 | <rniwa> | Ms2ger, annevk: arkos is the one who has been implementing microdata API in webkit. |
| 07:31 | <Ms2ger> | Hi arkos! |
| 07:31 | <MikeSmith> | hsivonen: I guess you don't have root on the server? Can't tail /var/log/auth.log ? |
| 07:31 | <rniwa> | Ms2ger, annevk: he's from Motorola and has been writing excellent patches :D |
| 07:32 | <arkos> | Ms2ger: hi |
| 07:32 | <rniwa> | arkos: Ms2ger works on Mozilla |
| 07:32 | <rniwa> | arkos: and annevk works on Opera |
| 07:32 | <arkos> | rniwa: ok |
| 07:33 | <rniwa> | arkos: both them are very active in standard bodies :) |
| 07:34 | <arkos> | rniwa: ok.. gr8 |
| 07:34 | <rniwa> | Ms2ger, annevk: speaking of which, our microdata API is near completion |
| 07:35 | <rniwa> | arkos just submitted one last feature we were missing: propertynodelist |
| 07:35 | <Ms2ger> | Opera did it first :) |
| 07:35 | <rniwa> | submitted a patch for* |
| 07:35 | <rniwa> | Ms2ger: i know! |
| 07:35 | <rniwa> | Ms2ger: it's nice to have two implementations, right? |
| 07:35 | <Ms2ger> | And we did it second :) |
| 07:35 | <asmodai> | annevk et al: would making math on wikipedia a user option also be a step in the right direction? |
| 07:35 | <rniwa> | Ms2ger: oh, Mozilla has already implemented it? |
| 07:35 | <Ms2ger> | Yes |
| 07:35 | <rniwa> | Ms2ger: nice! |
| 07:35 | <Ms2ger> | Ever since last week or so |
| 07:36 | <rniwa> | Ms2ger: cool. i wasn't aware of this :\ |
| 07:36 | <Ms2ger> | You can still beat IE ;) |
| 07:37 | <arkos> | Ms2ger: you are right :) |
| 07:37 | <rniwa> | Ms2ger: oh well, arkos is new to webkit |
| 07:38 | <rniwa> | Ms2ger: and he has been single-handedly writing code to support microdata API as his first contribution to webkit |
| 07:38 | <rniwa> | Ms2ger: so we can't complain :) |
| 07:38 | <Ms2ger> | You're always welcome to join Mozilla too, of course :) |
| 07:38 | <rniwa> | Ms2ger: LOL |
| 07:38 | <Ms2ger> | We could use people like that :) |
| 07:39 | <annevk> | "WebGL generates a WebGLContextEvent event" |
| 07:39 | <annevk> | euh |
| 07:39 | <MikeSmith> | hsivonen: you're sure you're logging in with the right username? I mean, with the username for that host set in your .ssh/config or set with "ssh -l foo" on the command line? |
| 07:39 | <annevk> | asmodai: what does that mean? |
| 07:39 | <MikeSmith> | hsivonen: because if you don't have the right username, it won't tell you |
| 07:40 | <MikeSmith> | I think it will just give you the same unhelpful "Permission denied (publickey)." message |
| 07:40 | <annevk> | ooh |
| 07:41 | <annevk> | some of the event language in WebGL is quite good |
| 07:45 | <arkos> | Ms2ger, annevk, rniwa nice talking to you guys.. hopefully our implementation gets enabled soon... |
| 07:46 | <annevk> | oh Google won the Java fight? |
| 07:46 | <annevk> | arkos: yeah, good luck :) |
| 07:46 | <rniwa> | annevk: yeah we did :D |
| 07:46 | <annevk> | rniwa: missed that, cool |
| 08:06 | <rniwa> | Ms2ger: is PropertyNodeList a live node list? |
| 08:07 | <rniwa> | annevk, Ms2ger: it's not vacuously obvious from the spec :\ |
| 08:07 | <rniwa> | i'd assume it's not live since it doesn't explicitly say it's live |
| 08:09 | <rniwa> | Hixie: ? |
| 08:11 | <annevk> | "The namedItem(name) method must return a PropertyNodeList object representing a live view of the HTMLPropertiesCollection object" |
| 08:12 | <rniwa> | annevk: does that mean PropertyNodeList itself is live? |
| 08:12 | <annevk> | it represents a live view |
| 08:12 | <rniwa> | annevk: i thought it just mean that HTMLPropertiesCollection itself is live. |
| 08:12 | <annevk> | not sure what else that could possibly mean |
| 08:13 | <rniwa> | annevk: oh yeah, i guess i agree with you on my second reading. |
| 08:13 | <rniwa> | guess i need more tea :\ |
| 08:13 | <rniwa> | annevk: thanks for the response. |
| 08:17 | <annevk> | http://rogerandmike.com/post/24006177542/html5-the-next-big-thing-for-content "How far will pendulum go????" |
| 08:17 | <annevk> | what am I reading? |
| 08:20 | <Velmont> | hahaha, that's hilarious :D |
| 08:20 | <Velmont> | HTML 5 represents new life for the world wide web, but it will almost certainly not be a smooth transition from HTML 4. |
| 08:21 | <Velmont> | and this one: HTML 5 is still in its infancy. Important functionality – such as that needed for commerce – has not yet been enabled. Even though it is not ready to replace HTML 4 on wired PCs, HTML 5 enables new and wonderful experiences on mobile devices. |
| 08:21 | <annevk> | i am as high as kite |
| 08:22 | <Velmont> | I suspect most content creators will not rush into HTML 5 because it only supports a narrow set of use cases and platforms. |
| 08:22 | <MikeSmith> | unlock tantric HyperNet pendulum awareness now! with Roger and Mike! |
| 08:24 | MikeSmith | adds "HyperNet" and "pendulum" to the DB for http://logopoeia.com/wisdom/ |
| 08:25 | <annevk> | "Adopt the rule of pseudo-atomic instability as your guide." |
| 08:27 | <jgraham> | I think you're being unfair. That was much better than most other examples of machine generated spam |
| 08:41 | <MikeSmith> | hahaha "the unarguable rule of bio-pendulum-pseudo-time instability follows directly from vibro-tantric law." |
| 08:45 | <rafaelw_> | hsivonen: yt? |
| 08:46 | <rniwa> | "(there is no standard HTML 5 for Android)" !? |
| 08:47 | <rafaelw_> | rniwa: holy moly: isn't it 2am there? |
| 08:47 | <rniwa> | rafaelw_: yeah. |
| 08:47 | <rafaelw_> | yikes =-). |
| 08:47 | <rniwa> | rafaelw_: are you in Europe or something? |
| 08:47 | <rafaelw_> | Israel. |
| 08:48 | <rafaelw_> | PST + 10 |
| 08:48 | <rniwa> | rafaelw_: ah, that's right. |
| 08:48 | <rniwa> | rafaelw_: Tel-Aviv? |
| 08:48 | <rafaelw_> | yup. coming up on noon here. |
| 08:48 | <rniwa> | cool. |
| 08:48 | <hsivonen> | rafaelw_: yes |
| 08:48 | <rafaelw_> | hi there. |
| 08:48 | <rafaelw_> | curious where you're standing on Document.parse() at the moment. |
| 08:49 | <rafaelw_> | Hixie is clearly worried about encouraging innerHTML-like patterns. Do you share that worry? |
| 08:50 | <hsivonen> | rafaelw_: I can see Hixie's point. I also see that Document.parse() is polyfillable (by compiling the Validator.nu parser into JS using GWT, for example) while E4H isn't polyfillable |
| 08:50 | <annevk> | hsivonen: http://qfox.nl/weblog/247 |
| 08:51 | <hsivonen> | rafaelw_: so I agree that what Hixie proposes would be better in principle, but I think it has political and practical downsides that will be a problem in terms of time to market and deployability |
| 08:51 | <rafaelw_> | Is there any reason to see them as mutually exclusive? |
| 08:51 | <hsivonen> | rafaelw_: nothing other than more total implementation work |
| 08:52 | <rafaelw_> | Document.parse() strikes me as fixing a practical current problem in a way which is consistent with the oddness of the current HTML parser. |
| 08:52 | <Ms2ger> | And bigger API surface, I guess |
| 08:53 | <rafaelw_> | E4H strikes me as a longer-term, but potentially larger impact feature -- which is akin to designing a new HTML parser. |
| 08:53 | <hsivonen> | rafaelw_: I agree on both counts |
| 08:53 | <rafaelw_> | I.e. Has behavior which is very different from the current parser. |
| 08:53 | <rafaelw_> | what about the script exectuability issue? |
| 08:55 | <hsivonen> | rafaelw_: does jQuery specifically make them executable or is that an accidental side effect of impl details? |
| 08:55 | <rafaelw_> | i don't happen to know the design history, but i'd be surprised if it wasn't intentional. |
| 08:55 | <hsivonen> | rafaelw_: I would prefer to make scripts executable but if the jQuery behavior is intentional, it's probably best to go with executability |
| 08:55 | <hsivonen> | *prefer to make *un*executable |
| 08:55 | <rafaelw_> | right. |
| 08:55 | <asmodai> | annevk: It was something we were discussing on #cldr yesterday |
| 08:56 | <hsivonen> | rafaelw_: so yeah, I guess I can live with making them executable |
| 08:56 | <asmodai> | annevk: in order to encourage uptake on MathML. I am not sure if I can get wikimedia/wikipedia crazy enough to switch 100% to presentation mathml and ditch the other stuff |
| 08:56 | <hsivonen> | rafaelw_: it will be a huge footgun when used with anything other than one HTML script element at a time |
| 08:56 | <rafaelw_> | i'll ask Yehuda on the thread to clarify. I strongly suspect it's intentional. |
| 08:56 | <asmodai> | annevk: So allowing people to turn on mathml usage might already help a bit |
| 08:56 | <asmodai> | annevk: via some user preference thing on the wiki |
| 08:56 | <annevk> | asmodai: ah yeah |
| 08:57 | <hsivonen> | rafaelw_: ok |
| 08:57 | <asmodai> | The Unicode folks are eager to adoptation of mathml as well, since it will allow more use of the math code blocks |
| 08:57 | <rafaelw_> | hsivonen: any idea when Document.parse() might land in Gecko? |
| 08:58 | <annevk> | Is parse() really the best we can come up? How many parser APIs do we need? |
| 08:58 | <hsivonen> | rafaelw_: not in June or July |
| 08:58 | <asmodai> | parse all the documents! |
| 08:58 | <annevk> | DOMParser / innerHTML / outerHTML / insertAdjacentHTML() |
| 08:58 | <jgraham> | annevk: Depends if you count normal document loading as an API :) |
| 08:59 | <Ms2ger> | createContextualFragment |
| 08:59 | <jgraham> | createContextualFragment |
| 08:59 | <jgraham> | dammit |
| 08:59 | <Ms2ger> | Yay, Gecko naming stuff |
| 08:59 | <annevk> | I'd rather we investigate this a bit more before we start shipping yet another one |
| 08:59 | <annevk> | it's already quite the mess |
| 09:00 | <rafaelw_> | annevk: Can you clarify what exactly you're objecting to. |
| 09:00 | <rafaelw_> | Is it just adding a different API call? New behavior? |
| 09:00 | <annevk> | adding a new API of which we are not even sure it's the best solution, but we're doing it for some short-term progress |
| 09:01 | <annevk> | at least that's the impression I get |
| 09:01 | <annevk> | and it's not even clear to me if we get short-term progress, because it will take a long time for IE to get there |
| 09:02 | <rafaelw_> | Well, I think Hixie has confused the issue a bit by raising the prospect of a fairly radical new approach. |
| 09:02 | <rafaelw_> | In my view the basic question is creating the ability for the *existing* html parser to be able to contruct dom from markup without a context element. |
| 09:03 | <rafaelw_> | There are two manifestations of this: (1) Imperative, e.g. Document.parse(), and (2) Declarative. e.g. <template> |
| 09:04 | <jgraham> | Ms2ger: (I find whenever you think "WTF were people at Netscape/Mozilla thinking" it helps to reread http://www.mozillazine.org/articles/article177.html Then everything becomes clear) |
| 09:04 | <rafaelw_> | Both are patterns that are already widely is in use and very poorly supported, resulting in lots of developer contortions and hacks. |
| 09:04 | <jgraham> | (+working on early gecko) |
| 09:05 | <rafaelw_> | If we want to essentially design a new HTML parser, I think that'd be grand, but it's a much bigger project whose motivations are fairly different. |
| 09:05 | <Ms2ger> | "Design patterns were an important part of our modeling processes." |
| 09:05 | <Ms2ger> | That's his fault? |
| 09:05 | <annevk> | it's not exactly a new HTML parser; it's a way to represent Node objects in JavaScript |
| 09:06 | <Ms2ger> | Where does that guy live? |
| 09:06 | <rafaelw_> | i think that's the motivation. i think the design is a new parser. |
| 09:06 | <rafaelw_> | in hixie's world, that parser lives in ECMAScript. |
| 09:07 | <rafaelw_> | at least conceptually: where parser == "a process for converting a character stream into a DOM structure" |
| 09:07 | <jgraham> | annevk: document.write into a DOM-created document |
| 09:07 | <annevk> | sure |
| 09:07 | <annevk> | jgraham: XMLHttpRequest + data URLs |
| 09:07 | <hsivonen> | Ms2ger: I think it would be unfair to blame it all on rickg, but as I understand it, the Patterns came to Netscape from Digital Style |
| 09:08 | <hsivonen> | Ms2ger: so blame the Digital Style team more broadly |
| 09:09 | <annevk> | rafaelw_: I can see your point from the perspective of accomplishing that task; but if you look at the use cases and how they are best addressed it becomes a little less clear I think |
| 09:10 | <hsivonen> | rafaelw_: I think this is mainly about getting DOM literals in JS in an expedient way that doesn't involve TC39 changing the language |
| 09:10 | <annevk> | rafaelw_: that combined with Document.parse() being unlike anything we have for HTML parsing thus far, I'd rather have some stronger agreement that it is the way to go |
| 09:10 | <hsivonen> | rafaelw_: might be worthwhile to at least ping TC39 before proceeding to rout around them |
| 09:11 | <hsivonen> | sad things happen when groups route around TC39 |
| 09:11 | <hsivonen> | see arraybuffer endianness |
| 09:11 | <annevk> | TC39 will echo quasi |
| 09:11 | <rafaelw_> | annevk, hsivonen: you see adding Document.parse() as routing around TC39? |
| 09:12 | <hsivonen> | rafaelw_: yes |
| 09:12 | <jgraham> | Alterntaive point of view: sad things happen when we wait too long for TC39 to get their shit together - see arraybuffers |
| 09:12 | <rafaelw_> | how so? |
| 09:12 | <hsivonen> | rafaelw_: we wouldn't need Document.parse() for its main use case if TC39 gave us E4H |
| 09:13 | <jgraham> | (we should have got clueful people making a binary API several years before the web GL people finally needed one) |
| 09:13 | <hsivonen> | jgraham: indeed |
| 09:13 | <annevk> | othermaciej submitted proposals to no avail |
| 09:14 | <rafaelw_> | How bad is it add Document.parse() in a world where we eventually get E4H (or something like it)? |
| 09:14 | <hsivonen> | rafaelw_: not too bad, IMO, though it might lessen the chance of E4H happening eventually |
| 09:14 | <jgraham> | To me it doesn't seem that bad |
| 09:15 | <rafaelw_> | Why would it lessen the chance of E4H? |
| 09:15 | <hsivonen> | rafaelw_: less need for a clean solution if as "almost there" solution already exists |
| 09:15 | <jgraham> | We already have N ways of doing something nearly the same so N+1, with the 1 designed toi better fit the actual use cases doesn't seem like it can be much worse |
| 09:15 | <annevk> | given how we still try to remove cruft from the platform I'd say that redundant APIs are bad |
| 09:16 | <jgraham> | Plus I expect E4H to be harder than people expect |
| 09:16 | <hsivonen> | annevk: if <template> parsing happens with the same parser states, Document.parse() is super-cheap if <template> happens anyway |
| 09:16 | <annevk> | hsivonen: it's not cheap to just throw tons of APIs at developers and let them choose |
| 09:16 | <hsivonen> | though I intend to fight <template> happening the way currently proposed with wormholes to other DOMs |
| 09:16 | <rafaelw_> | annevk: Document.parse() can still be DocumentFragment.innerHTML (I think mainly Henri's preference that it be Document.parse()). |
| 09:17 | <rafaelw_> | It doesn't strike me as redudant at all. It seems like adding a clearly need missing bit of innerHTML. |
| 09:17 | <jgraham> | I also have a strong preference for .parse fwiw |
| 09:17 | <hsivonen> | rafaelw_: I indeed prefer Document.parse() over DocumentFragment.innerHTML |
| 09:17 | <rafaelw_> | i agree with the Document.parse() decision. |
| 09:18 | <rafaelw_> | i'm just pointing out that the new API call is making it look more redudant than it is. The feature really lives in the parser logic. Not in the API call. |
| 09:18 | <annevk> | there's a ton of parser logic that is not exposed |
| 09:20 | <jgraham> | I think the anti-cruft argument is pretty silly if platform libraries are having to implement the feature themselves but in a more unpleasant way |
| 09:21 | <jgraham> | That seems to be the case here |
| 09:21 | <annevk> | because we don't have a sane way to create a Node objects |
| 09:21 | <rafaelw_> | Also, it just seems wrong to me to avoid giving developers something that will clearly help them because we're worried that doing so creates complacence for doing something larger. |
| 09:22 | <rafaelw_> | FWIW, I see the valid of E4H or similar as totally orthogonal to parsing without a context element. |
| 09:22 | <rafaelw_> | s/valid/value |
| 09:23 | <annevk> | I don't see the problem with taking some time to find out what the actual options are |
| 09:23 | <rafaelw_> | do you mean seeing whether TC39 is open to E4H? |
| 09:24 | <jgraham> | The TC39 release cycle is so crazy-long that I am very skeptical of solutions that put them on the critical path |
| 09:24 | <annevk> | you do realize that it'll take at least two years and probably up to five before developers can use any solution here without a supporting library? |
| 09:25 | <annevk> | it's not like a few months will matter |
| 09:25 | <jgraham> | But the ES committee works in cycles of a few years |
| 09:26 | <annevk> | sure, but if they're behind it (or something else) that can be prototyped and shipped |
| 09:26 | <annevk> | just as browsers have always shipped JavaScript stuff before the standard was done |
| 09:26 | <rafaelw_> | FWIW, i think we should stop accommodating the slow-update-cycle UAs by thinking in terms of years. The web is going to loose that way. |
| 09:26 | <jgraham> | Usually what happens is that browsers ship one thing then the committee change it and everyone has to implement something else |
| 09:27 | <annevk> | rafaelw_: as long as IE has market share that's the reality, no? |
| 09:27 | <annevk> | jgraham: yeah we should stop catering to that nonsense... |
| 09:27 | <rafaelw_> | IE is moving slowly towards shorter half-life. we should be creating more not less pressure in this direction. |
| 09:30 | <annevk> | no disagreement there |
| 09:31 | <annevk> | I'd still like us to evaluate our options though before adding more API surface |
| 09:31 | <rafaelw_> | Can we find a way to make the "evaluating our options" finite? |
| 09:32 | <rafaelw_> | I'm worried that we're stacking a very real helpful proposal up against and huge unknown. |
| 09:33 | <rafaelw_> | Do we have any indication that the JS folks will be friendly to something like E4H? Surely this idea has been floated by Brenden or Dave Herman already in some form? |
| 09:33 | <annevk> | Last time they thought quasis were better |
| 09:34 | <rafaelw_> | And you think they'll react differently now? |
| 09:34 | <annevk> | but quasis don't have compile-time checking or a definition |
| 09:34 | <rafaelw_> | or can be convinced? |
| 09:34 | <annevk> | I don't know |
| 09:35 | <annevk> | if E4H works for browsers and developers we should just do that imo, irrespective of whether it receives TC39 blessing |
| 09:37 | <annevk> | rafaelw_: in one of those threads I pointed to previous discussion I believe; in the thread where Hixie made his proposal |
| 09:42 | <rniwa> | annevk, jgraham, hsivonen, rafaelw_: it appears to me that we should at least continue the discussion on the parsing algorithm for template element regardless of what we decide to do with Document.parse |
| 09:44 | <rafaelw_> | rniwa: couldn't agree more =-) |
| 09:44 | <rniwa> | From API perspective, template element avoids some of objection from Hixie and others in that it doesn't introduce new string-literal-to-DOM API to scripts. |
| 09:44 | <rniwa> | in fact, if we just add template element & avoid adding Document.parse, it'll encourage authors to use declarative model |
| 09:44 | <annevk> | yeah the only thing controversial with <template> seems to be what happens to the elements |
| 09:44 | <rniwa> | instead of imperative model they're currently stuck with. |
| 09:45 | <rniwa> | annevk: yeah. :\ |
| 09:45 | <annevk> | controversial thing* |
| 09:45 | <rniwa> | children vs. fragment. |
| 09:45 | <rafaelw_> | annevk: yup. |
| 09:45 | <rafaelw_> | henri: any chance you're willing to be challenged on the children vs fragment issue here? |
| 09:45 | <rniwa> | annevk: i have increasingly convinced that putting it in fragment makes sense to avoid many problems |
| 09:46 | <rniwa> | but then what should template.innerHTML, etc... should do? |
| 09:46 | <rniwa> | e.g. what happens if you added children to a temple element? |
| 09:46 | <rafaelw_> | if <template> were to land, Document.parse() could be polyfilled in about 5 lines. |
| 09:46 | <rafaelw_> | and it doesn't remove any pressure around HTML literals in JS. |
| 09:46 | <rniwa> | rafaelw_: how so? |
| 09:47 | <rafaelw_> | Document.parse = function(markup) { |
| 09:47 | <rniwa> | rafaelw_: will you wrap markup in "<template>"? |
| 09:47 | <rafaelw_> | var t = document.createElement('template'): |
| 09:47 | <rafaelw_> | t.innerHTML = markup; |
| 09:47 | <annevk> | rniwa: fragment makes sense to me too and I think innerHTML and such should just operate on the normal DOM, not the fragment |
| 09:47 | <rafaelw_> | return t.cotent; } |
| 09:47 | <rniwa> | rafaelw_: there, you're assuming that innerHTML works on fragment. |
| 09:47 | <rafaelw_> | nope. i'm assuming innerHTML works on <template> |
| 09:48 | <rniwa> | rafaelw_: but as annevk just replied, a saner behavior might be to work on the real children. |
| 09:48 | <rniwa> | rafaelw_: oh oops, you're right but you're assming that it'll sync fragment on demand. |
| 09:48 | <jgraham> | innerHTML not working in the expected way on template would be insane |
| 09:48 | <annevk> | "the expected way" lol |
| 09:49 | <hsivonen> | jgraham: isn't that the current spec situation? stuff goes on the other side of the wormhole |
| 09:49 | <rafaelw_> | annevk: i'm not clear on what you are suggesting. what would this do? |
| 09:49 | <jgraham> | i.e. if <template>foo</template> != template.innerHTML = "foo" there will be rioting on the streets |
| 09:49 | <rniwa> | annevk: +1 to that LOL |
| 09:49 | <rafaelw_> | document.createElement('div').innerHTML = "<template><div>Hello</div></template>"; |
| 09:49 | <rniwa> | jgraham: so you think that setting innerHTML should update the fragment as well? |
| 09:49 | <annevk> | jgraham: but that's kind of the point of <template>... |
| 09:49 | <annevk> | jgraham: that you can't see it's children |
| 09:50 | <rniwa> | jgraham: but then it's kind of weird in that |
| 09:50 | <rniwa> | jgraham: this innerHTML will replace fragment |
| 09:50 | <jgraham> | The invariant should be just what I said |
| 09:50 | <rniwa> | and don't insert "real" children :\ |
| 09:50 | <annevk> | <template>foo</template> you want <template>.firstChild to be null |
| 09:50 | <annevk> | if innerHTML is suddenly magic, riot on some other set of streets |
| 09:50 | <rniwa> | annevk: i think jgraham is suggesting that we sitll do that but then update fragment. |
| 09:51 | <annevk> | rniwa: and getting innerHTML does what? |
| 09:51 | <rniwa> | annevk: which seems like a good idea at the beginning 'til we start thinking about appendChild |
| 09:51 | <rniwa> | jgraham: consider while (~) t.appendChild(~); |
| 09:51 | <rafaelw_> | I see the design goal of <template> is that it's contents are *not* in the document.. for all purposes *except* serialization. |
| 09:51 | <rniwa> | jgraham: in this case, every call to appendChild should either replace the fragment or add new child to fragment... |
| 09:52 | <jgraham> | Well I have no idea what should happen if you do appendChild and you are using magic documents |
| 09:52 | <annevk> | rafaelw_: why would you serialize it? |
| 09:52 | <jgraham> | Breaking that is marginally less surprising than breaking innerHTML though |
| 09:52 | <rniwa> | jgraham: agreed. |
| 09:52 | <annevk> | jgraham: define "breaking" |
| 09:52 | <rniwa> | jgraham: but we need to come up with some sane behavior there as well. |
| 09:53 | <jgraham> | annevk: I already did |
| 09:53 | <rniwa> | annevk: i.e. replace fragment. |
| 09:53 | <rafaelw_> | annevk: it's serialzed in the page which is sent to the client. |
| 09:53 | <rniwa> | annevk: or whatever the content template is. |
| 09:53 | <annevk> | jgraham: I think what you are suggesting is breaking innerHTML |
| 09:53 | <annevk> | jgraham: because it would be a special code path for <template> |
| 09:53 | <rniwa> | annevk: it doesn't, if we keep children of template element as real children |
| 09:54 | <rniwa> | annevk: so i think jgraham is indirectly pointing at keeping them as real children. |
| 09:54 | <jgraham> | annevk: Whether it needs a special codepath is pretty irrelevent |
| 09:54 | <annevk> | but that breaks getElementsByTagName() etc. and requires parent chain checks besides Windowness checks for <img> |
| 09:54 | <annevk> | rniwa: ^^ |
| 09:54 | <rniwa> | annevk: right. |
| 09:54 | <rniwa> | annevk: the question is which breakage is saner :\ |
| 09:54 | <jgraham> | It only needs a special codepath if parsing <template> in general needs a special codepath |
| 09:55 | <rniwa> | annevk: it's sort of a trade off here. |
| 09:55 | <rafaelw_> | annevk: can you define "breaks getElementsByTagName" |
| 09:55 | <annevk> | <template><div></div></template> you don't want to see that <div> during normal DOM traversal I think |
| 09:55 | <rniwa> | annevk: on one hand, putting template in a fragment will let us get away with problems in getElement(s)by*, querySelector, script loading, etc.... |
| 09:55 | <rafaelw_> | i think that getElementsByTagName, querySelector, getElementById *have to* not match template contents. |
| 09:55 | <rniwa> | annevk: but on the other hand, it breaks innerHTML, appendChild, etc... on template element |
| 09:56 | <Ms2ger> | rafaelw_, otoh, that breaks XHTML |
| 09:56 | <rafaelw_> | we discussed the XHTML the W3C F2F |
| 09:56 | <annevk> | got to go |
| 09:56 | <rniwa> | annevk: ttyl/ |
| 09:56 | <rafaelw_> | the consensus was that we need to leave it to XML to "fix" the breakage if they care to. |
| 09:57 | <rafaelw_> | Ms2ger: ^^ |
| 09:57 | <rafaelw_> | I.e. the goal here is to create behavior which is fundamentally incompatible with the XML parser. If XML wants to add this to the parser, they can do that. |
| 09:58 | <rafaelw_> | bye anne. ;-) |
| 09:58 | <jgraham> | The goal seems to be to create behaviour that is fondamentally incompatible with the DOM :) |
| 09:58 | <jgraham> | *fundamentally |
| 09:58 | <Ms2ger> | Another question |
| 09:58 | <Ms2ger> | <template><div></div></template> |
| 09:59 | <Ms2ger> | What's div.parentNode? |
| 09:59 | <rafaelw_> | i know it seems that way, but what's being proposed is formally supporting exactly what *literally* every dynamic webapp is already doing. |
| 09:59 | <Ms2ger> | http://xkcd.com/725/ |
| 09:59 | <jgraham> | I understand that there are use cases here |
| 10:00 | <jgraham> | But it seems to be non-trivial to solve them in a clean way at this level |
| 10:00 | <rafaelw_> | Ms2ger: ;-). I actually thought about that when i wrote the word "literally" and decided to use it. |
| 10:01 | <rafaelw_> | The number of webapps which construct DOM without some form of templating is effectively 0. |
| 10:03 | <jgraham> | I even wrote *literally* the worst templating system in the world once |
| 10:03 | <rniwa> | i think we need to decide whether we're putting contents of the template in a fragment or not. |
| 10:03 | <Ms2ger> | jgraham, oh, I didn't know you were involved with DOM1? |
| 10:03 | <rniwa> | almost everyone agrees that we want template element. |
| 10:04 | <jgraham> | Hah |
| 10:04 | <rniwa> | everyone is* agreeing* |
| 10:04 | <rniwa> | it's the matter of deciding what exactly template element is. |
| 10:04 | <Ms2ger> | Literally everyone? :) |
| 10:04 | <rniwa> | Ms2ger: no. |
| 10:05 | <rniwa> | Ms2ger: because there is always a non-zero probably that someone would come and disagree with us. |
| 10:05 | <rniwa> | Ms2ger: i would not risk myself being wrong by saying "literally" there. |
| 10:05 | <Ms2ger> | Smart man :) |
| 10:05 | <rniwa> | :) |
| 10:05 | <rniwa> | indeed i'm extremely risk adverse. |
| 10:06 | <rniwa> | averse* |
| 10:06 | Ms2ger | would still like an answer to his parentNode question |
| 10:06 | <rniwa> | Ms2ger: i think it'll be a document fragment |
| 10:06 | <Ms2ger> | ?! |
| 10:06 | <jgraham> | Ms2ger: That seems to be the crux of the issue |
| 10:06 | <rniwa> | Ms2ger: if we decide to put contents of template element in a fragment |
| 10:07 | <rniwa> | Ms2ger: if we don't, and keep them as real children of template element, then it'l be the template element. |
| 10:07 | <rafaelw_> | ms2ger: the divs parent node would be the template element's "content" DocumentFragment. |
| 10:07 | <rniwa> | rafaelw_: if we decide to go with that route. |
| 10:07 | <Ms2ger> | Anyway, I object to anything where node.parentNode.childNodes doesn't include node |
| 10:07 | <rniwa> | Ms2ger: that works in both cases. |
| 10:08 | <jgraham> | I think that invariant holds |
| 10:08 | <rniwa> | Ms2ger: if parentNode is a document fragment, then the document fragment's childNodes will certainly include the node. |
| 10:08 | <Ms2ger> | jgraham, not in Gecko, and it's horrible |
| 10:08 | <jgraham> | In the fragment case the weirdness is that the <template> element has no children |
| 10:08 | <rniwa> | Ms2ger: !? |
| 10:08 | <Ms2ger> | XBL |
| 10:08 | <jgraham> | Ms2ger: I point, and I laugh |
| 10:08 | Ms2ger | patpats jgraham |
| 10:09 | <rniwa> | Ms2ger: i'd just say "scumbag XBL" and stop there. |
| 10:09 | <rafaelw_> | Wait. Surely you jest. |
| 10:09 | <Philip`> | I like the phrase "Security will be present by the beginning of the year or so." (from http://www.mozillazine.org/articles/article177.html) |
| 10:09 | <Ms2ger> | In our implementation? I don't think that'll work :) |
| 10:09 | <rniwa> | jgraham: yeah, and what should happen when you assign something to innerHTML |
| 10:10 | <rafaelw_> | "node.parentNode.childNodes doesn't include node" isn't true with DF's in gecko> |
| 10:10 | <rafaelw_> | ? |
| 10:10 | <rniwa> | jgraham: or add or remove children to the template element :\ |
| 10:10 | <Velmont> | Philip`: Yeah, that was weird, and funny |
| 10:10 | <jgraham> | rniwa: One could of course make appendChild and various other methods throw in the case that the parent is a template |
| 10:10 | <Ms2ger> | rafaelw_, dunno about DF's, but it can be that way if node is the root of an XBL tree |
| 10:10 | <Ms2ger> | Or something |
| 10:11 | <rniwa> | jgraham: i guess, that's an acceptable solution. |
| 10:11 | <rniwa> | jgraham: but then there are LOTs of APIs that do this :\ |
| 10:11 | <rniwa> | jgraham: e.g. you can create a Range inside the template (not in its fragment) |
| 10:11 | <jgraham> | Well the other option is just to let it work, but be slightly weird |
| 10:12 | <rniwa> | jgraham: and call one of those fancy manipulation APIs |
| 10:12 | <jgraham> | True |
| 10:12 | <rniwa> | jgraham: it's also not entirely clear what should outerHTML should do :( |
| 10:13 | <rafaelw_> | What if we made <template> behave kind of like <script> and have it's contents be "refected" by a text node which is it's first child node. |
| 10:13 | <rafaelw_> | ? |
| 10:13 | <rniwa> | scumbag DOM APIs. we should just kill all of them and start fresh. |
| 10:13 | <Ms2ger> | rniwa, dash? |
| 10:13 | <jgraham> | rafaelw_: I think I suggested that before and there were problems |
| 10:13 | <jgraham> | I'm not sure what they were though |
| 10:13 | <rniwa> | Ms2ger: i'd call it CleanDOM 1.0. there is no script and no css. pure semantic HTML. that's it. |
| 10:14 | <rniwa> | Ms2ger: in fact, there's not even DOM! |
| 10:14 | <Ms2ger> | It's XHTML2? :) |
| 10:14 | <rafaelw_> | yeah. you did. i didn't like it at the time, but given the worry about breaking the existing assumptions, it's starting to look more appealing. |
| 10:15 | <rniwa> | rafaelw_: what should happen if someone tried to add non-text node to template? |
| 10:15 | <Ms2ger> | Also |
| 10:15 | <rafaelw_> | hmm... but then there's the problem of sub-templates. |
| 10:15 | <rafaelw_> | <sigh> |
| 10:15 | <rniwa> | rafaelw_: yeah, i was about to say that :\ |
| 10:15 | <Ms2ger> | We've just got replaceChild() and friends specced right, please don't mess with them :) |
| 10:15 | <rniwa> | rafaelw_: i think that was one big reason you didn't want the text-based template |
| 10:16 | <rniwa> | Ms2ger: are you sure it's spec'ed "right"? i bet there are few bugs, etc... hanging there :P |
| 10:16 | <Ms2ger> | rniwa, in WebKit? Yes ;) |
| 10:16 | <rafaelw_> | Ms2ger: doesn't lifting template contents into a documentfragment meet that requirement? |
| 10:16 | <rniwa> | Ms2ger: LOL |
| 10:16 | <Ms2ger> | rniwa, (seriously) |
| 10:17 | <Ms2ger> | rafaelw_, haven't thought much about it |
| 10:17 | <rniwa> | Ms2ger: i know. i'm painfully aware of that. |
| 10:17 | <rniwa> | Ms2ger: haven't gotten cycle to fix them :( |
| 10:17 | <Ms2ger> | rafaelw_, it seems weird, but maybe it's the best approach |
| 10:17 | <rniwa> | Ms2ger: maybe you can convince ojan to work on it :) |
| 10:17 | <Ms2ger> | rniwa, anything my tests don't catch? :) |
| 10:17 | <rafaelw_> | the current proposal is that it messes with parsing and serialization, but nothing else. |
| 10:18 | <Ms2ger> | That's even worse, I can't even punt that to annevk :( |
| 10:18 | <rniwa> | rafaelw_: i think we need to define what innerHTML, appendChild, etc... on template element should do. |
| 10:18 | <rniwa> | it appears that there are some tricky issues there. |
| 10:19 | <Ms2ger> | Hmm |
| 10:19 | rniwa | wonders if hsivonen is still around. |
| 10:19 | <Ms2ger> | el.innerHTML = '<template><div></div></template>' |
| 10:19 | <Ms2ger> | el.appendChild(document.createElement('template')).appendChild(document.createElement('div')) |
| 10:20 | <Velmont> | I kinda find it strange that something that is not concrete but an "idea" (a template) is in the HTML at all. It makes for this problem of having to hide it. |
| 10:20 | <rniwa> | Ms2ger: if we put the template's content in a fragment, then the latter won't "work". |
| 10:20 | <rniwa> | Ms2ger: well, i guess we can make it work if we spec appendChild to work on fragment instead. |
| 10:20 | <rniwa> | Ms2ger: but that's kind of weird :\ |
| 10:20 | <Velmont> | <script>var mytmpl=<div class=whatever></div>;</script> / <template id=mytmpl><div class=whatever></div></template> |
| 10:20 | <Ms2ger> | rniwa, I'll murder you slowly and painfully if you do that :) |
| 10:21 | <rafaelw_> | i think it's desireable that the latter doesnt' "work". |
| 10:21 | <Ms2ger> | Velmont, hmm, I see what you did there :) |
| 10:21 | <rniwa> | Ms2ger: i don't think i'll suggest anything as insane as that :) |
| 10:21 | <rniwa> | rafaelw_: throws an exception? |
| 10:21 | <Velmont> | Ms2ger: .. hmm, what did I do`? :P |
| 10:21 | <Ms2ger> | E4H? :) |
| 10:21 | <Velmont> | yeah! |
| 10:22 | <rniwa> | i've started to think that throwing exceptions as jgraham suggested might be the sanest solution |
| 10:22 | <rniwa> | if we go with the fragment approach. |
| 10:22 | Ms2ger | broke something when updating testharness.js |
| 10:22 | <rniwa> | rafaelw_, Ms2ger: but then we still have to deal with innerHTML, and innerHTMl and appendChild behaving differently is also kind of weird. |
| 10:22 | <rafaelw_> | i'm not sure that makes sense. |
| 10:22 | <jgraham> | Ms2ger: Updating in which direction? |
| 10:22 | <rafaelw_> | scripts don't throw if you append element children. |
| 10:22 | <jgraham> | (push or pull) |
| 10:22 | <Velmont> | jgraham: possibly the wrong one... |
| 10:22 | <Ms2ger> | jgraham, importing the new version |
| 10:23 | <jgraham> | Ms2ger: OK |
| 10:23 | <Ms2ger> | pull from w3.org, push to m.o |
| 10:23 | <rniwa> | rafaelw_: so what happens when you append children via appendChild to a template element? |
| 10:23 | <rniwa> | rafaelw_: will it just silently fail? |
| 10:23 | <Ms2ger> | rafaelw_, rniwa, img elements don't throw either |
| 10:23 | <Ms2ger> | Just put them in the DOM? |
| 10:23 | <rafaelw_> | probably the same thing. |
| 10:23 | <Velmont> | Ms2ger: I put big warnings when I updated operas version, -- but noone bugged me about it. So went fine for us, I believe. |
| 10:23 | <rafaelw_> | they append and live as children, but that just doesn't accomplish anything very interesting. |
| 10:24 | <Ms2ger> | Velmont, might be some of the changes to threport.js I sneaked in |
| 10:24 | <rniwa> | Ms2ger, rafaelw_: so document.createElement('template').appendChild(e) will insert e as the "real |
| 10:24 | <rafaelw_> | yup |
| 10:24 | <rniwa> | " child of the template element? |
| 10:24 | <Ms2ger> | .childNodes will be [e] |
| 10:24 | <rafaelw_> | yes. |
| 10:24 | <rniwa> | ok |
| 10:24 | <rniwa> | but then it's weird that innerHTML works on fragment then. |
| 10:25 | <rafaelw_> | i think script is the precedent here. |
| 10:25 | <rafaelw_> | yes. but again the "weirdness" *is* the design goal. |
| 10:25 | <Ms2ger> | innerHTML on fragment? |
| 10:25 | <rniwa> | Ms2ger: innerHTMl on template |
| 10:25 | <jgraham> | BTW pliniss wants to update testharnessreport.js on the W3C server to extract metadata from tests that you add with syntax like test(function() {}, "My foo test", {help:"http://spec/link";}) |
| 10:25 | <jgraham> | Does that seem OK to others? |
| 10:26 | <Ms2ger> | *Linss |
| 10:26 | <rniwa> | i've started to think that if we eventually want Document.parse, etc... |
| 10:26 | <jgraham> | Oops |
| 10:26 | <Ms2ger> | But that seems correct |
| 10:26 | <rniwa> | then template.innerHTML should probably work like tempalte.appendChild as well |
| 10:26 | <jgraham> | plinss |
| 10:26 | <Ms2ger> | s/correct/sane/ |
| 10:26 | <rniwa> | meaning that it doesn't do anything interesting. |
| 10:26 | <rafaelw_> | rniwa: what would |
| 10:26 | <rniwa> | because if we expose parse on DocumentFragment, for example, |
| 10:26 | <Ms2ger> | I think that special-casing template.innerHTML would be weird |
| 10:27 | <rafaelw_> | myDiv.innerHTML = "<template><div>Foo</div></template>" |
| 10:27 | <jgraham> | Good, doog. Maybe I will put his patch somewhere it can get proper review |
| 10:27 | <rafaelw_> | do? |
| 10:27 | <rniwa> | then we can just do template.content.parse(~) |
| 10:27 | <jgraham> | WTF |
| 10:27 | <Ms2ger> | Doog? |
| 10:27 | <jgraham> | Did I just type good backwards? |
| 10:27 | <Velmont> | jgraham: hmm. yea. Not doing test(function() {}, { desc: 'My foo test', help: 'http://spec'; }) though? |
| 10:27 | <Ms2ger> | You did |
| 10:27 | <jgraham> | That is... |
| 10:27 | <Ms2ger> | Velmont, eh, more typing :) |
| 10:27 | <rniwa> | rafaelw_: that should work. it'll create template with content fragment generated with "<div>foo</div"> |
| 10:28 | <Velmont> | Ms2ger: I'm just asking the question man! :P |
| 10:28 | <rniwa> | rafaelw_: i'm talking about document.createElement('template').innerHTML = ~ |
| 10:28 | <jgraham> | Velmont: Since titles are non-optional (sort of) that doesn't seem like a big win |
| 10:28 | <rniwa> | and suggesting that it should behave like document.createElement('template').appendChild(~) |
| 10:28 | <Velmont> | jgraham: Yeah. |
| 10:28 | <rniwa> | in that it'll just add it to the real DOM, and not to the content fragment it has. |
| 10:28 | <jgraham> | (although I have found myself writing things like async_test(undefined, {timeout:4000}) when I wanted to use document.title as the test title |
| 10:28 | <jgraham> | ) |
| 10:29 | <rafaelw_> | hmm... I gotta go, but i'll look forward to hearing why. =-). |
| 10:29 | <rafaelw_> | bye all. |
| 10:29 | <jgraham> | bye |
| 10:29 | <rniwa> | rafaelw_: bye. |
| 10:29 | <Ms2ger> | See you |
| 10:29 | <Velmont> | jgraham: Exposing all the variables then? |
| 10:29 | <Ms2ger> | jgraham, though, how much metadata does he want to put there? |
| 10:30 | <rniwa> | Ms2ger, jgraham: i'm increasingly convinced that if we keep innerHTML, appendChild, etc... to be regular DOM API and let them mutate "real" DOM |
| 10:30 | <rniwa> | then fragment approach might be quite sane. |
| 10:30 | <jgraham> | Ms2ger: I think he wants it to be possible to put all the things that the CSS WG already use |
| 10:30 | <Velmont> | (the full object). -- Although that kinda punts the standardization issue to somewhere else. |
| 10:31 | <jgraham> | Let me put the patch somewhere |
| 10:31 | Ms2ger | isn't entirely sure what Velmont is saying |
| 10:31 | jgraham | neither |
| 10:31 | <Velmont> | oh man |
| 10:32 | <Velmont> | Ms2ger: If the full object is exposed to testharnessreport.js you could write test(..., { ohmanfancyproprietarystuff: 'infoz' }) and the report could use that information. But I guess we'd want to have people use the same properties for common stuff that we all really want. |
| 10:32 | <Velmont> | And not call it like operas_special_spec_link='http://the-spec/bla'; |
| 10:33 | <Velmont> | But I guess it's all theorethical, because the web won't use it, mostly us few selected test writers :P |
| 10:34 | <rniwa> | good night guys ;) |
| 10:34 | <Ms2ger> | gn |
| 10:34 | <Velmont> | Hm. Doesn't make sense, just ignore my last sentences :P |
| 10:34 | <Ms2ger> | OK :) |
| 10:44 | <jgraham> | https://github.com/jgraham/testharness.js/commit/dc0ded17117ac14705a1f9aa0f6466b8aae3c845 |
| 10:52 | <MikeSmith> | jgraham: is that something you think is going to be generally useful, or is yet another thing that only the CSS WG is ever likely to actually use? |
| 10:53 | <jgraham> | MikeSmith: I have no idea. I mean, my experience is that test metadata sounds like a great idea and actually doesn't work very well |
| 10:53 | <jgraham> | But maybe my experience is wrong |
| 10:54 | <MikeSmith> | I guess it doesn't hurt to have it as an option for anybody to make use of it |
| 10:54 | <MikeSmith> | as long at it doesn't creep into becoming a requirement at least |
| 10:54 | <jgraham> | That is basically my feeling |
| 10:55 | <jgraham> | I would rather people spend time writing tests than spend time trying to work out what all the required metadata is, and what the right values are |
| 11:03 | <annevk> | <template> is basically XML Data Islands |
| 11:04 | <annevk> | but Opera did it first of course |
| 11:04 | <MikeSmith> | jgraham: I see you got a open pull request from tobie there to add a readme file |
| 11:05 | <MikeSmith> | Opera Awesome Islands |
| 11:05 | <Ms2ger> | Duplicating the docs? :/ |
| 11:05 | <jgraham> | MikeSmith: Yeah I guess I should fix that |
| 11:06 | <MikeSmith> | would be good to have some kind of readme |
| 11:06 | <jgraham> | Going from git to hg is a bit of a pain :( |
| 11:06 | <MikeSmith> | ah yeah |
| 11:06 | <MikeSmith> | Ms2ger: there's docs? |
| 11:06 | <Ms2ger> | In testharness.js |
| 11:06 | <Ms2ger> | That's what he copied |
| 11:06 | <MikeSmith> | oh |
| 11:06 | <MikeSmith> | hmm |
| 11:07 | <jgraham> | Right, I am not that sure about duplicating the docs |
| 11:07 | <MikeSmith> | that's not so good |
| 11:07 | <MikeSmith> | I don't think the docs should be duplicating |
| 11:07 | <MikeSmith> | the readme can just say "docs are in the source of testharness.js" |
| 11:28 | <jgraham> | Time to add a readme file: 2 minutes. Time to try and work out how to remove the one line change that accidentially made it into the local commit at the same time: 15 minutes. Mercurial: where mistakes should be punished by making you learn an entire new revision control system to fix them. |
| 11:29 | <Ms2ger> | hg revert foo/bar |
| 11:29 | <jgraham> | That adds an extra commit |
| 11:30 | <Ms2ger> | Oh, why'd you commit before checking if it was right? |
| 11:31 | <jgraham> | Because in git you only commit the things that you asked to commit. In hg it commits all changes. |
| 11:31 | <Ms2ger> | Yeah, that's really annoying in git :) |
| 11:31 | <jgraham> | Well you can always use -a |
| 11:32 | <Ms2ger> | Right |
| 11:32 | <jgraham> | Also, if you make a mistake and want to fix it you can use the same tools as you use for other operations |
| 11:32 | <Ms2ger> | Every time I'm forced to use git, I end up doing commit, cursing, and commit -a |
| 11:33 | <Ms2ger> | Fortunately that isn't often :) |
| 11:36 | <MikeSmith> | jgraham: "asseertions" |
| 11:36 | <MikeSmith> | anyway, thanks for adding it |
| 11:37 | <jgraham> | They're like assertions but eith more eeeee! |
| 11:37 | <MikeSmith> | hah |
| 11:37 | <jgraham> | eith is also like with but with more eeeee! |
| 11:37 | <MikeSmith> | a-seer-tions |
| 11:44 | Ms2ger | puts e cowboy hat on MikeeeSmith's head |
| 12:03 | <AryehGregor> | jgraham, I think you can do hg qimport tip tmp; hg qpop; $EDITOR .hg/patches/tmp; hg qpush; hg qfinish tip |
| 12:03 | <AryehGregor> | Or something. |
| 12:04 | <AryehGregor> | No, that's not right. |
| 12:04 | <AryehGregor> | hg qimport tip -n tmp; hg qpop; $EDITOR .hg/patches/tmp; hg qpush; hg qfinish tmp |
| 12:04 | <AryehGregor> | Something like that. |
| 12:04 | <AryehGregor> | Which, yes, is ludicrous and broken. |
| 12:04 | <AryehGregor> | It's hg, what do you expect. |
| 12:04 | <AryehGregor> | To be fair, git's commit -a is weird. svn also defaults to it. |
| 12:05 | <AryehGregor> | hg rollback works here, too. |
| 12:05 | <AryehGregor> | That's probably the most sensible, if you haven't done anything else in between. |
| 12:06 | <jgraham> | Yeah, hg rollback would have worked in this case |
| 12:06 | <jgraham> | But yeah, I ended up using mq, which is sort of absurd |
| 13:09 | <annevk> | WebKit has so many CORS bugs... |
| 13:10 | <annevk> | e.g. http://trac.webkit.org/browser/trunk/Source/WebCore/loader/CrossOriginAccessControl.cpp#L142 has no checks for duplicate Access-Control-Allow-Origin headers |
| 13:10 | <annevk> | then a little further on it does some kind of origin-based check rather than a string equality check |
| 13:12 | <jgraham> | annevk: Is there a testsuite? |
| 13:14 | <annevk> | yeah |
| 13:15 | <jgraham> | Sucks if they are ignoring it |
| 13:53 | <MikeSmith> | "Moving the Stable Web Forward" |
| 13:55 | <smaug____> | Stable o_O |
| 14:00 | <karlcow> | You need a lot of horses power for these browsers these days |
| 14:14 | <Velmont> | jgraham: I'm bitten by those hg bugs/annoyances all the time as well. |
| 14:17 | <Ms2ger> | "features" is the word you're looking for :) |
| 14:21 | <jgraham> | Hmm, so gecko and webkit don't seem to execute scripts in documents create by DOMImplementation.createHTMLDocument() |
| 14:21 | <Ms2ger> | I'll believe that |
| 14:22 | <jgraham> | Well your spec doesn't seem to agree with your beliefs :) |
| 14:22 | <Ms2ger> | I'll believe that too :) |
| 14:24 | <Ms2ger> | Actually |
| 14:24 | <Ms2ger> | jgraham, surely this falls under the "no defaultView" condition? |
| 14:25 | <jgraham> | ooh, maybe |
| 14:25 | <jgraham> | Where's that? |
| 14:26 | <Ms2ger> | http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#concept-n-script |
| 14:27 | <jgraham> | Yes, that makes sense |
| 14:27 | <jgraham> | So this should parse as if scripting is disabled also |
| 16:20 | <scott_gonzalez> | TabAtkins: I haven't been following <template> too closely. What's the confusion about qSA? |
| 16:22 | <Ms2ger> | <!doctype html><template><div></div></template> |
| 16:22 | <Ms2ger> | What's document.querySelectorAll("div")? |
| 16:22 | <scott_gonzalez> | empty set |
| 16:22 | <scott_gonzalez> | That is definitely what's expected by developers. |
| 16:22 | <Ms2ger> | By literally all developers? |
| 16:23 | <scott_gonzalez> | I want to say "yes", but I obviously do not have empirical data on that. |
| 16:23 | <scott_gonzalez> | Everyone uses <script type="x"> or <textarea> or whatever to ensure that behavior today. |
| 16:24 | <scott_gonzalez> | If it's not expected, then why use <template>? |
| 16:24 | <scott_gonzalez> | <div style="display: none;" id="my-tempalte"> |
| 16:25 | <scott_gonzalez> | document.parse( document.getElementById( "my-template" ) ) |
| 16:26 | <Ms2ger> | You're parsing an element..? |
| 16:27 | <scott_gonzalez> | sorry, .innerHTML |
| 16:27 | <scott_gonzalez> | Or I gues just clone it. |
| 16:27 | <scott_gonzalez> | The point is that everyone today is making sure their template contents are not actually part of the DOM. |
| 16:28 | <scott_gonzalez> | If anyone has some weird case where they want it to be, why would they use <template>? |
| 16:28 | <Hixie> | TabAtkins: ok, i added the definition of :hover to the HTML spec. |
| 16:29 | <Ms2ger> | Anyway, I'm probably convinced that it shouldn't match, but I wouldn't say everyone definitely agrees with me :) |
| 17:23 | <[tm]> | public-html is going to be a historical gem |
| 17:24 | <[tm]> | who was it earlier here taking about abnormal psychology? |
| 17:30 | <TabAtkins> | rafaelw_: I got bored reading scrollback, so this may have been discussed after I stopped reading, but the goal of the "<template> contents are shoved into a separate document" is solely so that stray queries against the doc don't accidentally return their contents. |
| 17:30 | <TabAtkins> | For all other purposes, ideally they'd be treated like normal contents in the normal DOM. |
| 17:31 | <TabAtkins> | If we gain the correct qSA behavior for free, but have to manually handle a bunch of manipulation APIs like .innerHTML, it may not be worth it, and we should swap and just manually handle qSA and friends. |
| 17:32 | <TabAtkins> | Where "manually" means some form of "generically, for all things that query against the document looking for nodes". |
| 17:40 | <Hixie> | TabAtkins: the only reason i am aware of for parsing into another doc's docfrag is to neuter the content |
| 17:42 | <TabAtkins> | What do you mean by "parsing into another doc's docfrag"? |
| 17:42 | <Hixie> | another Document's DocumentFragment |
| 17:43 | <TabAtkins> | It's the "parsing into" that I'm unclear about. Which APIs are you talking about? |
| 17:43 | <Hixie> | <template> parsing |
| 17:43 | <Hixie> | no api |
| 17:44 | <TabAtkins> | I still don't know what you're talking about. ;_; |
| 17:44 | <TabAtkins> | You're using words in combinations that I'm not quite sure about. |
| 17:44 | <Hixie> | heh |
| 17:44 | <Hixie> | sorry :-) |
| 17:44 | <Hixie> | when you have an HTML doc |
| 17:44 | <Hixie> | with a <template> |
| 17:44 | <Hixie> | the contents of that element are parsed by the HTML parser into a separate document's documentfragment object |
| 17:44 | <Hixie> | instead of into the document of the parser |
| 17:45 | <Hixie> | the goal of this is to neuter the dom |
| 17:45 | <Hixie> | of the template |
| 17:45 | <TabAtkins> | Yeah. |
| 17:45 | <Hixie> | so not "solely so that stray queries against the doc don't accidentally return their contents" :-) |
| 17:46 | <TabAtkins> | By "neuter" you presumably mean preventing image loads, etc.? |
| 17:46 | <Hixie> | right |
| 17:46 | <TabAtkins> | That doens't require a new doc though, afaict. |
| 17:46 | <Hixie> | well, i mean, we could always spec new magic |
| 17:46 | <Hixie> | but this is pretty magical stuff already so personally i'd rather just reuse what we have already |
| 17:47 | <TabAtkins> | Oh, we already have neutered documents? |
| 17:47 | <Hixie> | sure, e.g. createDocument(), XMLHttpRequest docs |
| 17:47 | <TabAtkins> | Hm, okay. |
| 17:56 | <[tm]> | if loonie number two says, "loonie number one is not batshit insane, you are", does that cancel out the looniness? |
| 17:56 | <TabAtkins> | No, it squares it. |
| 17:56 | <TabAtkins> | Also, what's the thread with all the looniness? |
| 18:01 | <[tm]> | TabAtkins: public-html-stridency |
| 18:02 | <TabAtkins> | ...that's not a real email thread. |
| 18:13 | <rniwa> | Hixie: there was some discussion about what should happen when you call appendChild, removeChild, etc... on the template element itself |
| 18:13 | <rniwa> | (not it's content fragment) |
| 18:13 | <rniwa> | Hixie: or assign/retreive values to/from innerHTML of the template element. |
| 18:16 | <TabAtkins> | Yeah, DOM manipulation on the <template> seems like it should work, particularly .innerHTML. |
| 18:16 | <TabAtkins> | Though I wouldn't be *too* sad if it didn't (and you had to descend into its doc first), it just seems weird. |
| 18:20 | <jgraham> | I would be very upset if innerHTML doesn't work but am pretty unbothered what happens with appendChild and friends |
| 18:20 | <jgraham> | (you can already do things like append children to a void element which makes equally little sense) |
| 18:25 | <rniwa> | TabAtkins, jgraham: on the other hand, innerHTML and appendChild behaving differently is also confusing |
| 18:25 | <TabAtkins> | Yeah. |
| 18:25 | <rniwa> | i would be personally more annoyed with that than innerHTML not replacing the content fragment. |
| 18:25 | <rniwa> | if we added innerHTML on the content fragment, we can just do |
| 18:26 | <rniwa> | templateElement.content.innerHTML = ~ |
| 18:26 | <rniwa> | jgraham: not sure if you're okay with that idea. |
| 18:26 | <Ms2ger> | Are we back there? :) |
| 18:26 | <rniwa> | Ms2ger: all the way! |
| 18:31 | <jgraham> | I wonder if you could just make <template> an ElementProxy or something that forwarded all method calls to template.content |
| 18:31 | <jgraham> | (with some exceptions of course) |
| 18:32 | <TabAtkins> | That makes sense to me. |
| 18:34 | <hober> | sicking: i've attempted to add some signal to the issue-204 thread; if you find the time, I'd be very grateful for a followup to http://lists.w3.org/Archives/Public/public-html/2012Jun/0066.html |
| 18:35 | <sicking> | hober: sorry, won't have time for a bit. Last day before vacation today and i have a lot to finish up before heading out :( |
| 18:35 | <sicking> | like packing :) |
| 18:36 | <Ms2ger> | That doesn't make sense to me :) |
| 18:37 | <Ms2ger> | hober, you know, if you have a finite amount of signal and an infinite amount of noise, the s:n ratio remains zero :) |
| 18:37 | <hober> | sicking: that's fine :) |
| 18:37 | <hober> | Ms2ger: indeed. |
| 19:01 | <Velmont> | hober: I liked the summary, made me not feel guilty for only reading the headlines :] |
| 19:15 | <TabAtkins> | Anyone ever been to the Dublin Web Summit? |
| 19:15 | <TabAtkins> | Got invited to speak there, wondering if it's worth a trip to Europe. |
| 19:15 | <TabAtkins> | Then again, that'll be my first time to Ireland, which is pretty attractive all by itself. |
| 19:19 | <jgraham> | No idea about the conference, but Ireland is worth a visit (irrespective of your taste for Guinness) |
| 19:19 | <TabAtkins> | Gradually making myself like the taste of stouts. |
| 19:19 | <TabAtkins> | (I have a problem with bitter flavors that I'm training myself out of.) |
| 19:19 | <Ms2ger> | Oh, ojan? |
| 19:20 | <ojan> | i'm here |
| 19:20 | <ojan> | what's up? |
| 19:20 | <Ms2ger> | rniwa volunteered you to fix some of his bugs ;) |
| 19:20 | <ojan> | lol...not likely :) |
| 19:20 | <ojan> | Ms2ger: which bugs? |
| 19:21 | <rniwa> | ojan: appendChild, etc.... |
| 19:21 | <rniwa> | ojan: we don't match the spec exactly |
| 19:21 | <ojan> | i'm certainly happy to review patches fixing bugs in that area :) |
| 19:22 | <Ms2ger> | Well played |
| 19:22 | <Ms2ger> | You know this game, sir |
| 19:24 | <rniwa> | ojan: LOL. |
| 19:24 | <rniwa> | we've got to find someone who's motivated enough to fix these :\ |
| 19:24 | <rniwa> | ojan: maybe we can find some friendly Motorola contributor to do it. |
| 19:24 | <Ms2ger> | Hah |
| 19:24 | <rniwa> | ojan: they're big on fixing compatibility problems :D |
| 19:24 | <Ms2ger> | MD first |
| 19:25 | <zewt> | TabAtkins: i've never cared for beer, and i have a basic issue with the idea of drinks that i have to teach myself to like |
| 19:25 | <ojan> | seriously though...i do want to see us fix these issues |
| 19:25 | <TabAtkins> | zewt: That's a silly position, unless you've never started liking anything at all that you disliked as a child. |
| 19:25 | <ojan> | i just have too much on my plate to fix everythign i want to see fixed :) |
| 19:25 | <zewt> | pretty sure my dislike for beer doesn't come from not liking it as a child :) |
| 19:25 | <ojan> | oh...we have a new eng who might want to do this.... |
| 19:26 | <ojan> | Ms2ger, rniwa: are there bugs filed? |
| 19:26 | <TabAtkins> | For example, sharp chedder or a good blue cheese are hard to like initially, but very delicious once you train yourself. |
| 19:26 | <rniwa> | ojan: maybe. |
| 19:26 | <TabAtkins> | Beer was the last of the alcoholic trinity that I was able to enjoy, though. |
| 19:26 | <rniwa> | ojan: one thing we need to do is to figure out figure out all the bugs in our code first. |
| 19:26 | <TabAtkins> | Once you get over the hump, there are a *lot* of delicious ones. |
| 19:26 | <rniwa> | ojan: i don't think bugs filed for all of them. |
| 19:27 | <Ms2ger> | ojan, I've got tests! ;) |
| 19:28 | <ojan> | Ms2ger, rniwa: well...if you CC me on bugs, i'll run them by the new guy and see if he wants to take a stab |
| 19:28 | <zewt> | ojan: heh, there's no better way to learn the way around a codebase than fixing bugs |
| 19:29 | <Ms2ger> | ojan, and even better, rniwa can make them run on your bots :) |
| 19:30 | <rniwa> | Ms2ger: sounds like a good idea :) |
| 19:30 | <rniwa> | Ms2ger: we're still discussing about how to import W3C tests into our repository |
| 19:30 | <rniwa> | Ms2ger: and we haven't had a good resolution on it :\ |
| 19:31 | Ms2ger | pulls up Chrome |
| 19:35 | <Ms2ger> | Inserting an element before a doctype |
| 19:35 | <Ms2ger> | Known? |
| 19:37 | <Ms2ger> | "Add inputmode attribute support, as per XHTML Basic 1.1" |
| 19:45 | <Ms2ger> | rniwa, what does Node::inDocument() mean? |
| 19:46 | <rniwa> | Ms2ger: means that the node is still attached to the document. |
| 19:46 | <rniwa> | Ms2ger: Node::document() returns the owner document |
| 19:46 | <Ms2ger> | Mm |
| 19:47 | <Ms2ger> | And it's always true for documents? |
| 19:47 | <rniwa> | Ms2ger: think so |
| 19:48 | <rniwa> | Ms2ger: see ConstructionType |
| 19:48 | <rniwa> | Ms2ger: in Node.h |
| 19:48 | <rniwa> | Ms2ger: CreateDocument = CreateContainer | InDocumentFlag |
| 19:49 | <Ms2ger> | Whoa, you have an implementation of Notation |
| 19:50 | <jgraham> | Notation? |
| 19:50 | <rniwa> | Ms2ger: yeah... |
| 19:51 | <Ms2ger> | jgraham, http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-5431D1B9 |
| 19:51 | <jgraham> | Oh My |
| 19:51 | <Ms2ger> | The file claims it's never instantiated, though |
| 19:54 | <Ms2ger> | rniwa, HTML DOM? |
| 19:54 | <rniwa> | jgraham: i know, right? |
| 19:54 | <rniwa> | Ms2ger: i don't even know who added that code. |
| 19:55 | <rniwa> | Ms2ger: it prepares my involvement to webkit |
| 19:55 | <Ms2ger> | No, for the insertBefore bugs |
| 20:03 | <rniwa> | JQUERY HAS ANSWERED |
| 20:03 | <rniwa> | SCRIPTING IS INTENTIONAL :D |
| 20:06 | <hober> | Velmont: :) |
| 20:12 | <Ms2ger> | Heh |
| 20:23 | <Ms2ger> | ojan, rniwa, enjoy :) |
| 21:17 | <Hixie> | rniwa: i think it would be exactly the kind of crazy confusing behaviour the Web is famous for for things like appendChild and innerHTML to do the "useful" thing instead of being consistent with what they do everywhere else |
| 21:23 | <jgraham> | Hixie: No more so than the HTML parser doing the "useful" thing |
| 21:30 | <Hixie> | except we don't really have an alternative for the parser |
| 21:30 | <Hixie> | plus the parser has plenty of precedent for doing different things for different tags |
| 21:30 | <rniwa> | Hixie: i agree with you too. |
| 21:31 | <rniwa> | Hixie: i think it's probably saner for those APIs not to work on content fragment |
| 21:39 | <annevk> | so we need at least 3 specifications to define :hover? |
| 21:39 | <annevk> | brilliant |
| 21:40 | <annevk> | no implementor is going to find that out :/ |
| 21:40 | <zewt> | show all three specs on the same page; hover an icon to pick which to see |
| 21:42 | <annevk> | the most important spec of those, hit testing, doesn't exist of course |
| 21:43 | <Hixie> | annevk: i don't want to put it in html, but since they won't put it in selectors... (same with :active and the others) |
| 21:47 | <annevk> | my cynical opinion of non-tree selectors defined by the CSS WG is that it's syntax plus some fluff words to give a rough hint of how things are supposed to work without actually defining how they work |
| 21:47 | <annevk> | which seems rather pointless |
| 21:49 | <Hixie> | yeah i don't really understand the reluctance |
| 21:51 | <annevk> | oh I do, it's the idea that CSS is unrelated to everything else and therefore the specifications must be alien of that too |
| 21:53 | <hober> | it's crazy |
| 21:53 | <annevk> | yes |
| 21:54 | <gsnedders> | How long till someone writes a "CSS applied to DOM" spec? |
| 21:54 | <Hixie> | annevk: that's what i don't understand |
| 21:56 | <annevk> | Hixie: it's the mindset of some relatively influential people within the CSS WG |
| 21:56 | <annevk> | Hixie: I don't think it makes sense, but they seem kind of fixed on that |
| 21:56 | <TabAtkins> | Uh, what? |
| 21:57 | <annevk> | Hixie: I gave up arguing on this though |
| 21:57 | <annevk> | (and then later left the WG entirely) |
| 21:58 | <TabAtkins> | CSS defines how :hover works generically. HTML defines a special additional case that causes :hover to match, based on stuff that only exists in HTML. |
| 21:58 | <TabAtkins> | Don't bullshit, anne. ^_^ |
| 21:59 | <annevk> | that's exactly what I was just saying... |
| 21:59 | <annevk> | well plus that hit testing is not defined |
| 21:59 | <annevk> | anyway, bedtime |
| 22:00 | <TabAtkins> | I'd love to define hit-testing, but I don't know what actually needs to be defined. |
| 22:00 | <TabAtkins> | Like, at what level are we missing stuff? |
| 22:03 | <TabAtkins> | Hixie: The reluctance to put @label-related stuff into Selectors is that CSS applies to more than HTML, so if there are things that are specific to the host language, they should be defined by the host language. |
| 22:04 | <TabAtkins> | And, as long as the host spec is being actively editted, like HTML is, that's fine. |
| 22:04 | <TabAtkins> | If that wasn't true, we'd include it in the CSS spec just to have it defined somewhere. |
| 22:05 | <TabAtkins> | But seriously, if someone can explain to me what's actually needed for hit-testing, I'll write the spec for it. |
| 22:10 | <rniwa> | TabAtkins: the problem with hit-testing is that a lot of it will be necessarily platform dependent |
| 22:10 | <rniwa> | TabAtkins: e.g. hit testing for editing can't be spec'ed one way or other because each platform uses different conventions with respect to bidiretional text for example. |
| 22:11 | <TabAtkins> | Is it? I mean, you have a coordinate, and a formatted page. Defining which element that coordinate hits shouldn't be difficult, I would assume. |
| 22:11 | <Hixie> | TabAtkins: i agree with anne that there's no point being generic. selectors should just give up and realise there is only one host language really. |
| 22:11 | <dglazkov> | YO |
| 22:11 | <rniwa> | TabAtkins: it is, unfortunately. |
| 22:11 | <TabAtkins> | Hixie: But there isn't. SVG is a valid second host language. |
| 22:11 | <Hixie> | TabAtkins: it's the same language. |
| 22:11 | <TabAtkins> | rniwa: Okay, then I don't understand. ^_^ I'll need some more details at some point. |
| 22:11 | <rniwa> | TabAtkins: hit-testing on element might work |
| 22:11 | <Hixie> | TabAtkins: "html+svg+math+xml+css+dom+js+..." |
| 22:11 | <rniwa> | TabAtkins: but definitely not when you have text |
| 22:12 | <rniwa> | TabAtkins: presumably, you want to spec hit-testing on text as well right? |
| 22:12 | <rniwa> | it's kind of odd to have a spec that only specifies hit-testing on elements without text :\ |
| 22:12 | <TabAtkins> | rniwa: For the purposes of CSS, no. I dunno if it's useful to specify text hit-testing. |
| 22:12 | <rniwa> | TabAtkins: ok. |
| 22:12 | shepazu | writes all his web pages in MathML with inline HTML and SVG |
| 22:12 | <rniwa> | TabAtkins: how about things like first-lettter? |
| 22:13 | <TabAtkins> | rniwa: ::first-letter is exactly the same as any other element for this purpose. |
| 22:13 | <rniwa> | TabAtkins: and how about inline elements that are intersparsed because of UBA? |
| 22:14 | <TabAtkins> | rniwa: Their boxes still have definite positions given by the layout algorithm already. |
| 22:14 | <TabAtkins> | (iirc, it's somewhat handwavey on that point, though) |
| 22:14 | <rniwa> | TabAtkins: hm... i guess. |
| 22:14 | <rniwa> | TabAtkins: oh yeah, i guess it works as long as you don't define what happens to selection |
| 22:14 | <TabAtkins> | By the time you're doing hit-testing, you've already done layout and positioning, and just have a bunch of elements with geometry. |
| 22:15 | <TabAtkins> | Yeah, doing selection requires specifying it on text instead of elements. |
| 22:15 | <rniwa> | okay, that makes sense :) |
| 22:15 | <rniwa> | when I hear the word hit-testing, I automatically assume it involves text |
| 22:15 | <rniwa> | because that's what browsers do. |
| 22:15 | <jamesr_> | defining hit-testing with transforms would be great |
| 22:16 | <TabAtkins> | The two algorithms are pretty disjoint - you'd first hit-test against geometry to see which element was hit, then do it against text to see where in the element's text was hit. |
| 22:16 | <jamesr_> | that's a non-trivial, non-interoperable thing completely unrelated to text |
| 22:16 | <rniwa> | jamesr: yeah, but that'll be hard to spec & implement :\ |
| 22:16 | <TabAtkins> | jamesr_: Interesting that it's non-trivial. The definition is pretty trivial when you work directly with geometry. |
| 22:16 | <rniwa> | TabAtkins: not in webkit but you could create a conceptual boundary like that, yes |
| 22:17 | <TabAtkins> | rniwa: Yeah, I have no idea what sort of division would be most useful for browsers. |
| 22:17 | <rniwa> | TabAtkins: i think it's okay as long as the spec isn't algorithmic |
| 22:17 | <TabAtkins> | rniwa: Surely hit-testing for :hover and mousein/out events and such doesn't care about text? |
| 22:18 | <Hixie> | well, if you have inlines they involve text, right? |
| 22:18 | <Hixie> | their position i mean |
| 22:18 | <TabAtkins> | Hixie: No, they involve the layout boxes generated by the text. |
| 22:18 | <TabAtkins> | The geometry of the text itself is irrelevant. |
| 22:18 | <Hixie> | i guess i don't really understand the question |
| 22:18 | <TabAtkins> | Me too, I think. |
| 22:19 | <Hixie> | seems like the geometry of the text is what affects where the inlines will end up, but *shrug* |
| 22:19 | <TabAtkins> | See: "I don't know what actually needs to be defined". |
| 22:19 | <Hixie> | we'll have to ask anne tomorrow :-) |
| 22:19 | <TabAtkins> | Geometry of the text is completely UA specific. |
| 22:19 | <TabAtkins> | Based on the text layout engine. |
| 22:20 | <rniwa> | define what you all mean by "geometry of text" |
| 22:20 | <rniwa> | anyways, CSSOM appears to expose CaretPosition or something |
| 22:21 | <rniwa> | that is potentially text related |
| 22:21 | <jamesr_> | TabAtkins, intersection! subdivision! not-rectangularity |
| 22:21 | <Hixie> | surely the TrueType spec defines what the text geometry needs to be |
| 22:21 | <jamesr_> | TabAtkins, 3d transforms are non-interoperable today |
| 22:21 | <jamesr_> | (or last i checked) |
| 22:23 | <TabAtkins> | jamesr_: Bah, that's all efficiency. Conceptually it's: take a bunch of elements, get their hittable geometry, transform as appropriate, sort by descending z-order, then find the first that contains the given point. |
| 22:23 | <jamesr_> | sort what by descending z-order? there is no global sort order for elements |
| 22:23 | <TabAtkins> | Hixie: Tell that to the engines and their slightly non-interop text behavior for bunches of things. |
| 22:23 | <TabAtkins> | Yes there is. |
| 22:23 | <jamesr_> | only if you subdivide |
| 22:24 | <TabAtkins> | Oh, with 3d transforms involved, yeah. |
| 22:24 | <jamesr_> | right. http://greggman.com/downloads/examples/intersecting-elements-3d-css.html |
| 22:24 | <Hixie> | TabAtkins: "slightly" doesn't mean there's no interop, it just means interop is defined to be within certain error margins. |
| 22:24 | <Hixie> | TabAtkins: that's pretty common on the web |
| 22:25 | <jamesr_> | without 3d it's pretty simple and probably fairly easy to spec |
| 22:25 | <TabAtkins> | Hixie: I'm not going to be the one to define that, particularly with things like synthetic bolding and the like. |
| 22:25 | <TabAtkins> | I'm willing to say "lay out the text, and give us the bounding box". |
| 22:25 | <Hixie> | TabAtkins: clearly i'm not volunteering for that either :-) |
| 22:25 | <TabAtkins> | jamesr_: Yeah, should be. |
| 22:26 | <jamesr_> | interestingly, i found out that in IE some invisible elements are invisible to hit-testing |
| 22:26 | <TabAtkins> | Hm? You mean like visibility:hidden? |
| 22:26 | <TabAtkins> | Or like "color:transparent; background:transparent;"? |
| 22:26 | <jamesr_> | setting background-color: grey changed whether an element got clicks or not |
| 22:26 | <jamesr_> | latter |
| 22:26 | <TabAtkins> | lolwut |
| 22:27 | <TabAtkins> | I assume they're optimizing away the draw, and it accidentally skips the "add to hit-test structure" too. |
| 22:27 | <jamesr_> | i was wondering if it was a clickjack defense |
| 22:27 | <TabAtkins> | Ooh, maybe. |
| 22:27 | <jamesr_> | behavior was different for <div> vs <canvas> |
| 22:29 | <Hixie> | IE has done this for ages |
| 22:29 | <Hixie> | i wrote a spec for it once (as best i could) |
| 22:29 | <Hixie> | it was terrifyingly complicated |
| 22:30 | <smaug____> | yeah, it is IEism from IE4 or so |
| 22:30 | <TabAtkins> | Bleh. |
| 22:35 | <smaug____> | TabAtkins: FYI, https://bugzilla.mozilla.org/show_bug.cgi?id=102695 |
| 22:50 | <TabAtkins> | smaug____: Thanks! |
| 23:02 | <jamesr_> | Hixie, any idea where that spec you wrote is these days? |
| 23:03 | <jamesr_> | i'm morbidly curious |