| 00:00 | <Philip`> | (One of the main advantages of canvas over SVG is that it's much easier to write code to render data since you don't have to convert it all into a DOM) |
| 00:02 | <Hixie> | yeah |
| 00:02 | <Hixie> | the problem is that the AT wants a tree |
| 00:03 | <Hixie> | which suggests using the DOM |
| 00:05 | <Philip`> | Could it equally suggest something like a JSON object? (with some specially-designed vocabulary so it exposes the data needed for AT with minimal overhead) |
| 00:06 | Philip` | doesn't automatically equate "tree" with "DOM" |
| 00:07 | <gsnedders> | I do. Whenever I want a tree data structure, I map my data to the DOM. |
| 00:08 | <Hixie> | Philip`: specifically, the AT wants a tree with AT annotations and so on, which is why it suggests the DOM (which already has all those built in, though not positions for the canvas) |
| 00:08 | <Hixie> | Philip`: certainly it's no the only solution, or maybe even the best |
| 00:09 | <Hixie> | Philip`: the idea of describing it as a JS object and then sending the object to the AT each time the canvas changes is interesting... |
| 00:09 | <Hixie> | hmm... what would it looks like. you'd have a bunch of nested arrays, each of which was a level of the hierarchy |
| 00:10 | <Hixie> | each would have a path associated with it, presumably, and a role |
| 00:10 | <Hixie> | and either a list of descendants, or a string, and you'd have to somehow give the precise position of each glyph in that string |
| 00:10 | <annevk> | yeah and only <canvas> authored by superhumans will use it |
| 00:11 | <Hixie> | we could provide APIs to automatically generate much of the information so it wouldn't be hard to build... |
| 00:12 | <Philip`> | Nobody in reality is going to maintain a DOM equivalent of their canvas-based code as a fallback for non-canvas-supporting graphical users, so they're only ever going to bother with the extra work when they're being forced to add a11y support, so if a non-zero number of people are forced to support a11y then it seems beneficial to provide an efficient a11y-specific API for them |
| 00:15 | <Hixie> | has anyone ever written an accessible version of asteroids? |
| 00:16 | <Hixie> | http://www.kevs3d.co.uk/dev/asteroids/ is one of the samples that was listed on the wiki page as an inaccessible canvas |
| 00:16 | <Hixie> | and i'm curious to see what an accessible version would be like |
| 00:17 | <nimbu> | isnt canvas essentially just like video but animated pixels? |
| 00:17 | <nimbu> | or pixel hacking |
| 00:18 | <nimbu> | i dont understand why/how accessibility can be added |
| 00:18 | <nimbu> | i looked at http://game-accessibility.com/ |
| 00:18 | <nimbu> | but didnt find anything useful |
| 00:18 | <nimbu> | given a lot of canvas seems to be used for retro games |
| 00:20 | <Yuhong> | FYI on the IE DOM: http://news.ycombinator.com/item?id=3233935 |
| 00:25 | <TabAtkins_> | nimbu: Canvas can theoretically be used for anything, so some of them are possible/appropriate to make accessible. |
| 00:25 | <TabAtkins_> | (I think that most, or maybe all, of these are bad uses of canvas.) |
| 00:25 | <nimbu> | yeah precisely. |
| 00:25 | <nimbu> | why would you optimize for bad usecases? :/ |
| 00:26 | <Hixie> | bbl |
| 00:26 | <TabAtkins_> | nimbu: I don't think we should. That's why I've stopped paying attention to public-html. |
| 00:26 | <TabAtkins_> | Since it's almost entirely confused a11y arguments. |
| 00:26 | <Philip`> | nimbu: Because accessibility is a core principle of the web, and canvas is part of the web, so canvas must support accessibility |
| 00:27 | <nimbu> | Philip`: how are images and videos supporting accessibility? |
| 00:27 | <nimbu> | i would think canvas belongs there |
| 00:27 | <Philip`> | nimbu: With longdesc |
| 00:27 | <Philip`> | (and alt) |
| 00:27 | <nimbu> | yeah there is nothing about making animated gifs accessible |
| 00:27 | <Philip`> | and subtitles etc for videos |
| 00:27 | <Philip`> | You put a description of the animated GIF in its longdesc |
| 00:28 | <Philip`> | (though of course HTML5 doesn't support longdesc (unless the HTML WG changed that yet?)) |
| 00:28 | <Yuhong> | By jbeda, which now works for Google too. |
| 00:29 | <nimbu> | in my view i dont see how anything more is required specifically for canvas. |
| 00:30 | <AryehGregor> | Hixie, you should never have included author conformance requirements in the spec. Would have saved you practically all this grief. |
| 00:30 | <AryehGregor> | UA processing only, that's the way to go. |
| 00:30 | <Philip`> | Wouldn't that just be shifting the grief to someone else? |
| 00:31 | <Philip`> | and if those someones handle it more poorly, then it makes the web worse for authors |
| 00:31 | <nimbu> | it is like saying we should optimize for web devs who use tables for layouts |
| 00:31 | <AryehGregor> | Only if someone bothers to write authoring conformance requirements for markup. Why does that have to be anything official anyway? Let people write their own private lint programs that match their own preferences. |
| 00:32 | <AryehGregor> | nimbu, how many hours of implementer time do you think have been spent optimizing for that case? :) |
| 00:32 | <AryehGregor> | I bet lots. |
| 00:32 | <nimbu> | :/ |
| 00:36 | <Philip`> | If authoring conformance didn't exist, it would be necessary to invent it |
| 00:36 | <Philip`> | People don't like working without rules from authorities |
| 00:37 | <TabAtkins_> | There really is a distinction between what we are forced to support for compat and what we want to encourage people to write. |
| 00:40 | <zewt> | authoring conformance should be determined by the rules for implementations |
| 00:40 | <zewt> | the idea that something must be supported by implementations with a specific behavior, yet is non-conforming, has always felt a bit nonsensical to me |
| 00:42 | <TabAtkins_> | I don't understand that position. :/ |
| 00:46 | <zewt> | i don't understand the position that something is fully defined, required to be supported, and not to be used |
| 00:46 | <TabAtkins_> | Mistakes were made, shrug your shoulders and move on? |
| 00:46 | <TabAtkins_> | Also: "required to be supported" is potentially time-variable. |
| 00:47 | <TabAtkins_> | If you want to attempt to drive it back to "not", you have to get people to stop using it in new things. |
| 00:47 | <zewt> | conformance isn't just "we didn't mean to allow this", though |
| 00:48 | <TabAtkins_> | I don't understand. |
| 00:50 | <zewt> | ugh. hard for me to do a google search right now, because the idiotic animated front page is lagging text entry on my laptop by several seconds |
| 00:51 | <zewt> | whoever is doing that crap needs to be shot out of a cannon |
| 01:01 | <zewt> | TabAtkins_: there's certainly no expectation that browsers will ever change to reject pages with no <title>, for example |
| 01:02 | <TabAtkins_> | Sure. And yet, there's good reason to include a <title>. |
| 01:03 | <TabAtkins_> | In general, the author requirements arent' meaningless - there are good reasons to prefer one solution, even if other solutions are required to be supported. |
| 01:03 | <TabAtkins_> | Pushing people toward those better solutions is a positive. |
| 01:09 | <zewt> | i'm not against making good practice recommendations, it's just the normative "must" that feels a bit too strong |
| 01:09 | <TabAtkins_> | In practice it's a recommendation, since it only actually shows up when you run it through a validator. |
| 01:10 | <zewt> | so, "should" :) |
| 01:10 | <TabAtkins_> | Meh, no reason to split hairs on it. Might as well pretend it's a requirement so you don't have people lawyering over it. |
| 01:13 | <gsnedders> | TabAtkins_: See public-html, it's typically been full of lawyering ove rit |
| 01:13 | <gsnedders> | *over it |
| 01:14 | <TabAtkins_> | gsnedders: I mean authors. ^_^ |
| 01:35 | <Hixie> | AryehGregor: the grief doesn't come from having authoring conformance criteria, it comes from having a system that prefers people with time than people with good opinions. |
| 01:36 | <Hixie> | AryehGregor: (notice how the whatwg system doesn't waste my time in the same way even though the same issues are discussed) |
| 01:36 | <Taggnostr> | livedom.validator.nu just froze my firefox |
| 01:37 | <Taggnostr> | is the author of livedom in this channel? |
| 01:44 | <TabAtkins_> | I presume it's a clone of Hixie's live dom viewer, so yes. |
| 01:44 | <TabAtkins_> | Taggnostr: ^^^ |
| 01:45 | <Taggnostr> | it freezes if I enter a single & after the doctype (the doctype is probably unrelated though) |
| 01:46 | <TabAtkins_> | Whoops, indeed it does freeze. |
| 01:46 | <TabAtkins_> | Freezes Chrome too. |
| 01:46 | <TabAtkins_> | hsivonen: Is this something you ahve control over? |
| 01:47 | <smaug____> | hsivonen will be asleep still few hours |
| 02:00 | <Taggnostr> | uhm, maybe I found a bug in the HTML5 standard too |
| 03:24 | <kennyluck> | I actually think all other specifications should start to have authoring conformance. For example, If browser vendors don't want authors to use localStorage and it is not likely to be maintained well, it should be made non-conforming. |
| 05:08 | <llrcombs> | kennyluck: it appears that browser vendors are using localStorage, though |
| 07:20 | zcorpan | gives Hixie a cookie :-) |
| 07:22 | <MikeSmith> | so I've been reminded that Jetty has built-in WebSocket support |
| 07:23 | <MikeSmith> | so I reckon I can install Jetty on w3c-test.org, for those who care to write the server parts in Java |
| 07:31 | <zcorpan> | MikeSmith: filed |
| 07:32 | <MikeSmith> | thanks |
| 07:51 | <hsivonen> | See the last paragraph of http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04355.html |
| 07:53 | <hsivonen> | TabAtkins_: that livedom.validator.nu freeze is interesting. thanks |
| 07:53 | <annevk> | hsivonen: that email, wow |
| 07:54 | <MikeSmith> | hahaha |
| 07:54 | <MikeSmith> | who is this joker? |
| 07:55 | <MikeSmith> | hsivonen: he clearly has *real* implementors in mind |
| 07:55 | <MikeSmith> | not browser makers |
| 07:55 | <hsivonen> | MikeSmith: he is the Designated Expert |
| 07:55 | <MikeSmith> | oh geez |
| 07:56 | <Hixie> | did you explain to him you were describing reality? |
| 07:56 | <MikeSmith> | I guess I should shut up |
| 07:57 | <MikeSmith> | It's *a* reality |
| 07:57 | <MikeSmith> | there are many other possible realities |
| 07:57 | <hsivonen> | Hixie: no. I expected Alexey and Julian would know that I'm interested in reality |
| 07:57 | <Hixie> | um |
| 07:57 | <Hixie> | well that was silly |
| 07:57 | <Hixie> | :-P |
| 07:58 | <hsivonen> | in fairness, what I suggested was a synthesis of Gecko, IE and WebKit behavior |
| 07:58 | <hsivonen> | so what I expect to become reality in Gecko--not quite the current reality |
| 07:59 | <hsivonen> | as in, becomes reality once I get around to implementing the BOM precedence change annevk suggested |
| 08:02 | <MikeSmith> | btw, fitting that the IETF mail-archive server turns "This seems naïve" into "This seems naÃve." |
| 08:03 | <annevk> | no Unicode man |
| 08:03 | <annevk> | us-ascii!!!! |
| 08:03 | <zcorpan> | also funny that he thinks utf-8-only for new formats is ridicolous |
| 08:05 | <zcorpan> | s/o/u/ |
| 08:05 | <annevk> | I think that comment might have only been about the bits before the text on new types |
| 08:06 | <annevk> | happy to see he thinks text/css, text/html, etc. ridiculous though |
| 08:07 | <zcorpan> | well i can agree text/html is ridiculous |
| 08:09 | <Hixie> | who wouldn't |
| 08:15 | <hsivonen> | MikeSmith: that "naÃve" thing is awesome. |
| 08:16 | <MikeSmith> | yeah man |
| 08:16 | <MikeSmith> | in a number of ways |
| 08:16 | <annevk> | we're still discussing StreamBuilder? |
| 08:16 | <annevk> | ugh |
| 08:16 | <annevk> | I wonder if I'll ever get a reply to my feedback then... |
| 09:18 | <annevk> | iso-2022-cn is quite the mess |
| 09:29 | <bga> | http://groups.google.com/group/jsmentors/browse_thread/thread/910bc55b2cc9be54 |
| 09:29 | <bga> | i wonder too if there is valid way |
| 09:30 | <bga> | everyone hate same origin policy |
| 10:02 | zcorpan | tries switching default search engine to ddg |
| 10:19 | <annevk> | oh hey steve faulkner, having fun making shit up? cf https://twitter.com/#!/stevefaulkner/status/172624731651059713 |
| 10:20 | <hsivonen> | how annoying. now my apps-discuss posts don't show up in the archive but I didn't get confirmation email, either |
| 10:20 | <annevk> | prolly just takes a while |
| 10:21 | <annevk> | IETF lists are a lot slower than W3C lists from what I remember |
| 10:21 | <annevk> | takes a while to degrade all that Unicode going around these days |
| 10:21 | <hsivonen> | yeah. in the archive now |
| 10:22 | <jgraham> | annevk: Happily he links to his source, so anyone who bothers to check will realise that he utterly missed the point |
| 10:22 | <annevk> | guess so |
| 10:25 | <hsivonen> | I like it how steve uses "self-selected" disparagingly of #whatwg regulars. as if the WAI isn't self-selected. |
| 10:27 | <annevk> | hsivonen: are you going to defined the 16-bit code units? |
| 10:28 | <annevk> | hsivonen: apparently there are some actual problems with ECMAScript: http://code.google.com/p/v8/issues/detail?id=761 |
| 10:28 | <zcorpan> | didn't know steve is the new lastweekinhtml5 |
| 10:28 | <zcorpan> | hi steve! |
| 10:31 | <hsivonen> | annevk: s/defined/defend/ ? |
| 10:31 | <annevk> | yeah oops |
| 10:31 | <hsivonen> | annevk: I guess I should in due course, but please go ahead and do so before I get to it |
| 10:31 | <annevk> | sunny in Oslo |
| 10:31 | <annevk> | yay |
| 10:32 | <annevk> | I'm not sure I know enough about grapheme clusters |
| 10:33 | <annevk> | I guess I can read http://unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries |
| 10:33 | <hsivonen> | zcorpan: Mr. Last Week never commented on any accessibility topic |
| 10:33 | <annevk> | I didn't even know stuff like g̈ existed |
| 10:33 | <annevk> | pretty wild |
| 10:34 | <annevk> | a ̈ test |
| 10:34 | <jgraham> | hsivonen: Surely your're not saying the MLW hated a11y?! |
| 10:35 | <jgraham> | s/your/you/ |
| 10:35 | <annevk> | better start packing |
| 10:39 | <zcorpan> | hsivonen: what a missed opportunity! |
| 11:50 | <kennyluck> | What happened to lastweekinhtml5 by the way? The blog, I mean. |
| 12:00 | <niloy> | anyone knows about html tag highlighting plugin for gedit? |
| 12:03 | <ruby_on_tails> | is there a way to make the speech regognition feature continuous ? |
| 12:03 | <ruby_on_tails> | i dont want it to work only when the user stops speaking |
| 12:05 | <beverloo> | Not right now. A new Speech JavaScript API is being developed (somewhere -- probably a new CG) to aid in that |
| 12:05 | <ruby_on_tails> | CG means ? |
| 12:05 | <beverloo> | community group |
| 12:05 | <beverloo> | it's a new concept within the w3c |
| 12:06 | <ruby_on_tails> | any way i could read more about it ? |
| 12:07 | <beverloo> | This is an early draft: http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/att-1696/speechapi.html |
| 12:09 | <ruby_on_tails> | beverloo: hmm thanks |
| 12:26 | <annevk5> | so I wonder if the limit for freenode is reached at Schiphol |
| 12:26 | <annevk5> | cannot connect |
| 12:26 | <annevk5> | but can connect to other IRC servers |
| 12:26 | <annevk5> | maybe because W3C and Opera are not on the default ports? |
| 12:28 | <annevk5> | any opinions on instead of having "Participate:" have a dedicated "Feedback" section that is also part of the table of contents? |
| 12:28 | <annevk5> | so that it becomes more visible in drafts how you can give feedback |
| 12:29 | <annevk5> | apparently it's not really read currently |
| 12:29 | <annevk5> | or not all the time anyway |
| 12:39 | <kennyluck> | I like "Participate:" better |
| 12:39 | <kennyluck> | but well, you have a point. |
| 12:41 | <zcorpan> | have both! |
| 12:51 | <annevk5> | kennyluck: me too |
| 12:51 | <annevk5> | and if it's only Marcos' that messes up, it might be okay |
| 12:51 | <annevk5> | maybe rename "Participate:" to "Send feedback:" ? |
| 12:52 | <annevk5> | I updated specification-data with the mutation observer stuff |
| 12:52 | <annevk5> | also expanded the events introduction |
| 12:52 | <annevk5> | and emailed www-dom about it |
| 12:52 | <annevk5> | http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#events |
| 12:52 | <annevk5> | will be back in four hours from some hotel in Oslo :) |
| 12:55 | <zcorpan> | annevk5: change "www-dom⊙wo (archives)" to "Send feedback to www-dom⊙wo (archives)" |
| 13:00 | <annevk5> | zcorpan: that could work |
| 13:00 | <annevk5> | zcorpan: and then "or file a bug" or some such |
| 13:02 | <zcorpan> | yep |
| 13:38 | <zcorpan> | annevk5: "And finally, and only if event's bubbles attribute value is true" - bubbles should be <code>d |
| 14:34 | <zewt> | (isn't "and only if" always implied?) |
| 15:31 | <kennyluck> | just in case you hadn't noticed http://www.ipetitions.com/petition/html-version-of-ecmascript-5-now |
| 15:34 | <Philip`> | Do the unofficial HTML copies of ES5 not count? |
| 15:38 | <kennyluck> | I would hope they release ES5 errata and ES6 drafts in HTML too. |
| 15:50 | <Velmont> | Hmm. I don't like that errors like this_requires_one_arg() -> throws so widely different things. |
| 15:54 | <jgraham> | Should throw TypeError |
| 15:56 | <Velmont> | jgraham: OK, that's what I made the test expect. But as I'm currently testing firefox nightly it throws it's own NS_LONG_TYPE_ERROR in many places, but not in that one, there it throws its own NS_ERROR_XPC_NOT_ENOUGH_ARGS (what's with the long scary names? :P) |
| 15:56 | <Velmont> | (I made NS_LONG_TYPE_ERROR up, it's called something else like that) |
| 15:57 | <jgraham> | Yeah Firefox really likes throwing NS_WE_MADE_THIS_ERR_UP_ERROR |
| 15:57 | <jgraham> | Blame smaug____ |
| 15:57 | <jgraham> | Or Ms2ger |
| 15:57 | <jgraham> | Or sicking |
| 15:57 | <jgraham> | Or someone |
| 15:57 | zcorpan | blames jgraham |
| 15:58 | Velmont | blames the world |
| 15:58 | <Velmont> | *cutting wrists and cries* |
| 15:58 | <jgraham> | Well specifically someone that isn't me. And does work on DOM in Mozilla |
| 15:58 | <jgraham> | Velmont: You should talk to gsnedders. You could listen to emo music together |
| 15:59 | <Velmont> | jgraham: That coincidented nicely with my mplayer -playlist shuffle putting on some emo music, btw. It must be a sign. |
| 15:59 | <smaug____> | jgraham: no no |
| 15:59 | <smaug____> | jgraham: blame Netscape |
| 16:00 | <jgraham> | smaug____: Dude, you have had almost a decade and a half to purge Netscape from the codebase |
| 16:00 | <Velmont> | smaug____: IndexedDB and friends wasn't thought about even when Netscape existed. òÓ |
| 16:00 | <Velmont> | How can it come from the past and mess with your new code? :P |
| 16:00 | smaug____ | just just looking at code from 1999 |
| 16:00 | <jgraham> | It can't possibly be that hard to throw TypeError rather than NS_WE_DIED_YEARS_AGO_ERROR |
| 16:01 | <smaug____> | oh, if it is about indexeddb, blame sicking :) |
| 16:02 | <sicking> | the reason we don't throw TypeError in indexedDB impl in Firefox is because we can't throw that from C++ |
| 16:02 | <sicking> | so blame mrbkap, bholley or jst |
| 16:04 | <Velmont> | Weird limitation. |
| 16:05 | <Velmont> | But it's possible to throw all-caps with namespace baked in errors? |
| 16:05 | <smaug____> | "can't" is too strong. It is just annoyingly hard |
| 16:05 | <smaug____> | comparing to some other exceptions |
| 16:06 | <Velmont> | Well, mozilla is getting undeservingly much red from my tests on stuff like that :P |
| 16:39 | <gsnedders> | jgraham: I am not emo. |
| 16:39 | <gsnedders> | … |
| 16:39 | gsnedders | should stop getting annoyed at jgraham's accusations |
| 16:59 | <AryehGregor> | sicking, it should be the WebIDL implementation throwing TypeError for not enough arguments, not IndexedDB. |
| 17:02 | <Ms2ger`> | jgraham, did you know we have a special exception when you pass 0 as a pointer argument? |
| 17:04 | <AryehGregor> | Ms2ger`, SIGSEGV? |
| 17:31 | <sicking> | AryehGregor: indeed. We just don't have a webidl layer implemented yet |
| 17:31 | <sicking> | AryehGregor: that's exactly my point |
| 17:32 | <rniwa> | AryehGregor: yt? |
| 17:33 | <AryehGregor> | rniwa, yes. |
| 17:33 | <AryehGregor> | Although things seem quiet on the editing front for the last couple of months, so mostly I'm doing CSS transforms/transitions stuff now. |
| 17:34 | <rniwa> | AryehGregor: yeah... I need to give you back some feedback :( |
| 17:34 | <AryehGregor> | rniwa, please do. |
| 17:34 | <rniwa> | AryehGregor: my plan was to add a hook to run your ref. impl. against our tests |
| 17:34 | <rniwa> | AryehGregor: but I haven't gotten around to it |
| 17:34 | <AryehGregor> | Okay. |
| 17:34 | <rniwa> | AryehGregor: btw, we should start talking about table editing / control selection as well |
| 17:35 | <AryehGregor> | Is anyone implementing the stuff I've already specced? |
| 17:35 | <rniwa> | AryehGregor: in particular, we've been getting a lot of complaints about webkit not supporting control selection :( |
| 17:35 | <rniwa> | AryehGregor: not that I'm aware of |
| 17:35 | <AryehGregor> | I admit that I'm not so enthusiastic about spending more time on the editing spec when I spent over six months on it and no one seems to be implementing it. |
| 17:37 | <rniwa> | AryehGregor: well, we're going to do it eventually |
| 17:38 | <AryehGregor> | Right. |
| 17:38 | <rniwa> | AryehGregor: it's just that I'm basically the one person working on editing |
| 17:38 | <rniwa> | AryehGregor: in webkit at the moment |
| 17:38 | <AryehGregor> | Right, I know. |
| 17:38 | <rniwa> | AryehGregor: so it's gonna take forever |
| 17:38 | <AryehGregor> | And ehsan in Mozilla, and nobody at any other engine. |
| 17:38 | <rniwa> | AryehGregor: just like removing Apple-style-span took 2 years |
| 17:38 | <rniwa> | AryehGregor: we'll be super lucky if we can implement your spec in the next 2-3 years :( |
| 17:38 | <AryehGregor> | If I get more into Gecko coding working for Mozilla, maybe I can try implementing some parts of the editing spec. |
| 17:39 | <rniwa> | AryehGregor: sorry to tell you this, but very few people are enthusiastic about editing. |
| 17:39 | <AryehGregor> | The HTML parser took what, like five or more years for everyone to implement? |
| 17:39 | <rniwa> | despite the fact almost everyone uses the feature daily |
| 17:39 | <AryehGregor> | And it's a lot more important, and probably a lot simpler. |
| 17:39 | <rniwa> | AryehGregor: yeah |
| 17:39 | <rniwa> | AryehGregor: we were lucky because our old parser code was really bad |
| 17:39 | <AryehGregor> | Everyone's was really bad, I think. :) |
| 17:39 | <rniwa> | AryehGregor: so eseidel & abarth decided to rewrite from scratch |
| 17:40 | <AryehGregor> | I think everyone did that. |
| 17:40 | <rniwa> | AryehGregor: had we been spending more time on parser code, and tried to incrementally converge |
| 17:40 | <rniwa> | AryehGregor: we wouldn't have finished yet :( |
| 17:40 | <hober> | rniwa: it's not just you working on editing in webkit; we've got enrica too. so there's 2 of you! :) |
| 17:41 | <rniwa> | hober: right, but enrica does other stuff too |
| 17:42 | <rniwa> | hober: i've been getting a lot of pressure to work on non-editing stuff as well |
| 17:42 | <rniwa> | hober: but i've been sneakingly avoiding that :P |
| 17:42 | <hober> | heh |
| 17:42 | <rniwa> | hober: because from PR point of view, editing isn't the most shiny new feature |
| 17:42 | <rniwa> | hober: it sorta works. |
| 17:42 | <hober> | it might not be shiny, but it's super important |
| 17:42 | <rniwa> | hober: and only people who work on editors care. (i.e. developers of tinyMCE, CKEditor, etc...) |
| 17:43 | <AryehGregor> | IMO, there's a lot of low-hanging fruit. |
| 17:43 | <rniwa> | hober: right. people get super upset whenever I introduce a regression |
| 17:43 | <AryehGregor> | If I were working on editing, the first thing I'd do is try to match the spec (= roughly IE/Opera) on linebreaks. |
| 17:43 | <hober> | *nod* |
| 17:43 | <AryehGregor> | That's probably the most blatant incompatibility between browsers. |
| 17:43 | <rniwa> | AryehGregor: oh yeah... |
| 17:43 | <rniwa> | AryehGregor: what do we do with line breaks? |
| 17:43 | <AryehGregor> | <p> vs. <div> vs. <br>. |
| 17:43 | <rniwa> | AryehGregor: can we add new switch? |
| 17:43 | <AryehGregor> | I specced <p>, basically. |
| 17:43 | <AryehGregor> | I could, if people are going to implement it . . . |
| 17:44 | <rniwa> | AryehGregor: did you add new toggling switch per ojan's suggestion? |
| 17:44 | <rniwa> | AryehGregor: on the condition that each editing host gets execCommand method? |
| 17:44 | <AryehGregor> | It's on my list of things to do, but again, I've mostly put aside editing work for now. |
| 17:44 | <rniwa> | AryehGregor: okay. |
| 17:44 | <AryehGregor> | I'll probably return to it sometime. |
| 17:44 | <rniwa> | AryehGregor: ping me when you've done that. |
| 17:44 | <rniwa> | AryehGregor: I think that's the most logical thing to do |
| 17:44 | <AryehGregor> | You're probably CCd on the relevant bugs. |
| 17:45 | <rniwa> | AryehGregor: as far as I know, there are a lot of legacy content that relies on the fact webkit produces div on line break :( |
| 17:45 | <AryehGregor> | Web content or WebKit-only content? |
| 17:45 | <rniwa> | AryehGregor: both |
| 17:45 | <rniwa> | AryehGregor: the latter is more serious. |
| 17:45 | <AryehGregor> | You could always have a different default for web users and other users. |
| 17:45 | <rniwa> | AryehGregor: because Microsoft Outlook & Apple Mail both use WebKit |
| 17:46 | <AryehGregor> | Outlook uses WebKit? o_O |
| 17:46 | <rniwa> | AryehGregor: and we can't regress them :( |
| 17:46 | <rniwa> | AryehGregor: yeah on Mac |
| 17:46 | <AryehGregor> | Oh, makes sense. |
| 17:46 | <AryehGregor> | They can't very well use Trident on Mac. |
| 17:46 | <rniwa> | AryehGregor: yeah ever since they discontinued IE for Mac |
| 17:46 | <rniwa> | AryehGregor: although I don't think they used Trident on Mac |
| 17:46 | <AryehGregor> | They used Tasman. |
| 17:46 | <rniwa> | AryehGregor: they wrote the engine from scratch for Mac |
| 17:47 | <hober> | yup |
| 17:47 | <AryehGregor> | ehsan, do you think we could default styleWithCSS to false without breaking too much stuff? I think authors just set styleWithCSS to false unconditionally at the start of all their scripts, in practice . . . |
| 17:47 | <AryehGregor> | That would be a nice compat win. |
| 17:48 | AryehGregor | might ask to spend some time working on Gecko editing stuff after he's done with all this CSS stuff, if he feels like doing coding instead of spec work |
| 17:48 | <AryehGregor> | Fortunately, there's almost no such thing as Gecko-specific content, so Gecko is often free to change to match other browsers. |
| 17:48 | <AryehGregor> | Unlike IE and WebKit. |
| 17:48 | <rniwa> | AryehGregor: that'll be nice. |
| 17:49 | <rniwa> | AryehGregor: although leaving default to true seems okay as long as there's an API to toggle it. |
| 17:49 | <AryehGregor> | Two biggest changes I would make: output <p> instead of <br>, and default styleWithCSS to false. |
| 17:49 | <AryehGregor> | Yeah, that's not a big deal because authors just force it to false. |
| 17:49 | <AryehGregor> | But they shouldn't have to. |
| 17:49 | <rniwa> | AryehGregor: we might consider something like |
| 17:49 | <AryehGregor> | So it's an easy fix. |
| 17:49 | <rniwa> | AryehGregor: turning on standard compliant mode when we see HTML5 style DOCTYPE |
| 17:50 | <rniwa> | AryehGregor: and fallback to legacy behavior elsewhere |
| 17:50 | <AryehGregor> | More quirks, in other words? |
| 17:50 | <AryehGregor> | Quirks are bad. |
| 17:51 | <AryehGregor> | Doesn't WebKit editing code already have different codepaths in some places for Apple Mail? |
| 17:51 | <rniwa> | AryehGregor: well, we don't. |
| 17:51 | <rniwa> | AryehGregor: we just look for specific classes and elements :( |
| 17:51 | <rniwa> | sigh.... |
| 17:51 | <AryehGregor> | :/ |
| 17:52 | <rniwa> | AryehGregor: you can add <blockquote type="cite"> and webkit treats them differently than a regular blockquote :( |
| 17:52 | <AryehGregor> | Ouch. |
| 17:53 | <rniwa> | AryehGregor: but that's just a secret between you and me. don't tell anyone, and we should be okay :) |
| 17:53 | <rniwa> | or hopefully so. |
| 17:53 | <rniwa> | AryehGregor: anyways, https://bugs.webkit.org/show_bug.cgi?id=12250 is the control selection bug I was talking about |
| 17:54 | <rniwa> | AryehGregor: it seems like authors expect image, etc... to be re-sizable in contenteditable regions |
| 17:54 | <AryehGregor> | Yeah. |
| 17:54 | <AryehGregor> | That's more of a QoI issue than a spec issue, though. |
| 17:54 | <rniwa> | AryehGregor: maybe. |
| 17:54 | <AryehGregor> | I mean, I can add a line to the spec saying UAs have to let users resize them. |
| 17:54 | <rniwa> | AryehGregor: but they expect this to work |
| 17:54 | <AryehGregor> | I have a bug open about that. |
| 17:54 | <rniwa> | AryehGregor: so you should probably say something about it. |
| 17:54 | <rniwa> | AryehGregor: yeah |
| 17:54 | <rniwa> | AryehGregor: maybe also move it around by dragging it? |
| 17:55 | <AryehGregor> | But precise interop isn't necessary as long as UAs provide some way to resize, so there's not much for the spec to say. |
| 17:55 | <AryehGregor> | There's a spec bug for that too. |
| 17:55 | <rniwa> | AryehGregor: right. |
| 17:55 | <rniwa> | AryehGregor: but I'm thinking that there should probably be some event firing to let authors know of the resize, etc... |
| 17:55 | <AryehGregor> | It's not like a switch to change the default block type, where the spec needs to say how authors call it. |
| 17:55 | <AryehGregor> | Maybe . . . do existing UAs do that? |
| 17:55 | <rniwa> | AryehGregor: in the case of resizing tables, things are a lot of trickier |
| 17:56 | <rniwa> | AryehGregor: because width of a row can be specified by td, or tr |
| 17:56 | <AryehGregor> | You can do foo { resize: both } on existing stuff already. http://dev.w3.org/csswg/css3-ui/#resize |
| 17:56 | <AryehGregor> | Table width is a nightmare. |
| 17:56 | <rniwa> | I mean height* |
| 17:56 | <rniwa> | AryehGregor: yeah. |
| 17:56 | <rniwa> | AryehGregor: but we need to support it at some point |
| 17:56 | <AryehGregor> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=13795#c4 |
| 17:57 | <rniwa> | AryehGregor: things get awfully tricky when we have rowspan and colspan :( |
| 17:57 | <AryehGregor> | Tables are a nightmare period. |
| 17:58 | <rniwa> | AryehGregor: I know. |
| 17:58 | <rniwa> | AryehGregor: but people DO use them :( |
| 17:58 | <AryehGregor> | rniwa, if there's something you want to implement in the near future and it's blocked on there not being a spec, tell me and I can spend some time working on that. E.g., if you actually plan to implement a switch that lets authors have <p> instead of <div> for newlines but aren't doing it because there's no spec, I'll write the spec today. |
| 17:58 | <rniwa> | AryehGregor: and enterprise folks LOVE them |
| 17:58 | <rniwa> | AryehGregor: I'd like to implement that one soon |
| 17:59 | <rniwa> | AryehGregor: because that's probably the only sane way for us to switch |
| 17:59 | <rniwa> | AryehGregor: at least in the near future |
| 17:59 | <AryehGregor> | I can spend some time on it, then. |
| 17:59 | <rniwa> | AryehGregor: that'll be great! |
| 17:59 | <AryehGregor> | Most of the work will be writing tests. |
| 17:59 | <rniwa> | AryehGregor: also before/after edit command events |
| 17:59 | <rniwa> | AryehGregor: they appear to be useful even today. |
| 17:59 | <rniwa> | if we can let authors override the default behavior |
| 17:59 | <AryehGregor> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=15527 https://www.w3.org/Bugs/Public/show_bug.cgi?id=13118 |
| 18:00 | <rniwa> | AryehGregor: because then authors can selectively override the default behavior using my UndoManager API |
| 18:00 | <AryehGregor> | rniwa, here's my plan for edit events: https://www.w3.org/Bugs/Public/show_bug.cgi?id=13118#c23 |
| 18:00 | <AryehGregor> | Does that look good to you? |
| 18:00 | <rniwa> | AryehGregor: that should give us a nice bridge between the current broken world and the new interop world :) |
| 18:00 | <AryehGregor> | No one ever gave feedback, so I got discouraged and forgot about it. |
| 18:01 | <rniwa> | AryehGregor: ah, oops. I wasn't aware of this bug :( |
| 18:01 | <rniwa> | despite of the fact i'm cc-ed :( |
| 18:04 | <AryehGregor> | Tell me if you like my scheme for implementing those events. |
| 18:05 | <rniwa> | AryehGregor: yeah, your proposal seems reasonable. |
| 18:05 | <AryehGregor> | Okay. |
| 18:10 | rniwa | comments on the bug enthusiatically |
| 18:12 | <AryehGregor> | :) |
| 18:14 | <rniwa> | AryehGregor: hm... wait so you don't think we should fire those events for script-initiated execCommands? |
| 18:14 | <rniwa> | AryehGregor: why not? |
| 18:14 | <rniwa> | AryehGregor: beforeInput/input events are fired synchronously at least in webkit |
| 18:15 | AryehGregor | refreshes his memory |
| 18:15 | <AryehGregor> | Ack, synchronous events are evil. |
| 18:15 | <AryehGregor> | What triggers them synchronously? |
| 18:15 | <AryehGregor> | We're trying to get rid of mutation events exactly because they're synchronous . . . |
| 18:16 | <AryehGregor> | If you want to synchronously hook into execCommand, you could always write a wrapper for it. |
| 18:16 | <rniwa> | AryehGregor: beforeInput/input |
| 18:16 | <rniwa> | AryehGregor: they're okay |
| 18:16 | <AryehGregor> | If you want to hook into other scripts' calls too, you can overwrite the method on the prototype . . . |
| 18:16 | <rniwa> | AryehGregor: because beforeInput/input won't fire as a side effect of something else :) |
| 18:17 | <rniwa> | AryehGregor: the only function that could fire these events is execCommand |
| 18:17 | <AryehGregor> | What if you call execCommand() from the handler? |
| 18:17 | <AryehGregor> | Everything has to be re-entrant? |
| 18:17 | <rniwa> | AryehGregor: but you can do that today. |
| 18:17 | <rniwa> | AryehGregor: blur, focusout, etc... all fire synchronously. |
| 18:17 | AryehGregor | tests blur |
| 18:18 | <roc> | they are synchronous, and it's a real nightmare |
| 18:19 | <AryehGregor> | Hmm, onfocus is sync in every browser but IE. |
| 18:19 | <AryehGregor> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cinput%20value%3D%22some%20text%22%20onfocus%3D%22w('b')%22%3E%0A%3Cscript%3E%0Aw(%22a%22)%3B%0Adocument.querySelector(%22input%22).focus()%3B%0Aw(%22c%22)%3B%0A%3C%2Fscript%3E |
| 18:19 | <rniwa> | AryehGregor: yeah, it's pretty annoying. |
| 18:19 | <rniwa> | AryehGregor: beforeunload as well if you have img, iframe, etc... :( |
| 18:20 | <rniwa> | AryehGregor: so we can't get away with these sync events. |
| 18:20 | <AryehGregor> | IE seems to make focus async, at least in that test. |
| 18:20 | <AryehGregor> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=16091 |
| 18:20 | <rniwa> | AryehGregor: on the other hand, we might be able to make execCommand not re-entrant, for example |
| 18:21 | <AryehGregor> | Do DOM or HTML even define such a thing as synchronous events? |
| 18:21 | <rniwa> | AryehGregor: so that if you try to call execCommand inside another execCommand or in some event handler trigged by another execCommand, we can throw |
| 18:21 | <AryehGregor> | DOM I'm pretty sure doesn't. |
| 18:21 | <rniwa> | AryehGregor: DOM |
| 18:21 | AryehGregor | looks |
| 18:21 | <rniwa> | AryehGregor: at least DOM 3 |
| 18:21 | <AryehGregor> | Well, no one uses DOM 3. |
| 18:22 | <rniwa> | AryehGregor: the problem is that if we don't fire them synchronously, we'll never be able to propagate events to ancestors' event listeners |
| 18:22 | <rniwa> | AryehGregor: unless we store the vector of ancestors :( |
| 18:22 | <rniwa> | AryehGregor: which will be a huge memory bloat |
| 18:22 | <AryehGregor> | Why not? |
| 18:22 | <Ms2ger`> | You have to do that, no? |
| 18:22 | <rniwa> | AryehGregor: because once the node is removed |
| 18:22 | <rniwa> | AryehGregor: the node doesn't have a parent anymore |
| 18:22 | <rniwa> | AryehGregor: and we wouldn't know to which node the event should be propagated |
| 18:22 | <AryehGregor> | Why not just not fire at ancestors if the node is removed before the event runs? |
| 18:23 | <rniwa> | AryehGregor: but then you'll never receive that event |
| 18:23 | <rniwa> | AryehGregor: unless you've attached EL on the node you're removing |
| 18:23 | <AryehGregor> | How likely is it that the node will be removed from its parent between the event being fired and running? |
| 18:23 | <AryehGregor> | Also: it's an array of a few pointers for every event fired. Why should it be such memory bloat? |
| 18:24 | <AryehGregor> | How many events get fired anyway? |
| 18:24 | <rniwa> | AryehGregor: we fire events very often |
| 18:25 | <rniwa> | AryehGregor: we have lots of optimizations to minimize the number of events to fire |
| 18:25 | <rniwa> | AryehGregor: and the cost per event dispatches |
| 18:25 | <AryehGregor> | Hmm. |
| 18:25 | <TabAtkins_> | Hm. Can someone explain why attributes in WebIDL end up on the prototype of an object rather than the object itself? |
| 18:25 | <Ms2ger`> | I'm sure someone wan |
| 18:25 | <Ms2ger`> | can* |
| 18:25 | <AryehGregor> | TabAtkins_, "why" in what sense? |
| 18:25 | <AryehGregor> | "Why" as in "what part of the spec says that", or "why does the spec say that", or "why did browsers implement it that way originally", or . . . ? |
| 18:26 | <AryehGregor> | The spec says it because that's what browsers do, and browsers do it because whatever crazy person thought up JS apparently thought a prototype-based object model was cool. |
| 18:26 | <TabAtkins_> | Context is recent discussion about moving the CSSStyleDeclaration from explicitly listing attributes to using a getter, because the former puts the properties on the prototype while the latter puts them on the object. |
| 18:26 | <AryehGregor> | (which actually it kind of is) |
| 18:26 | <AryehGregor> | The latter doesn't put them on the object. It just invokes the getter on the prototype. |
| 18:27 | <TabAtkins_> | Prototype-based OO is cool. But I don't understand the reasoning behind object properties living on the prototype. |
| 18:27 | <AryehGregor> | If you want them on the object for some reason, you can use [Unforgeable]. |
| 18:27 | <TabAtkins_> | Oh, then Boris is wrong. |
| 18:27 | <TabAtkins_> | kk |
| 18:27 | AryehGregor | is very hesitant to ever say Boris is wrong :) |
| 18:27 | <TabAtkins_> | (That's a very rare event.) |
| 18:27 | AryehGregor | looks at the thread |
| 18:27 | <Ms2ger`> | ^ |
| 18:27 | <rniwa> | AryehGregor, TabAtkins_: but we Do want them on prototype no? |
| 18:27 | <AryehGregor> | Probably Boris is right. |
| 18:27 | <rniwa> | otherwise, it'll be troublesome to do expandos on them |
| 18:28 | <TabAtkins_> | rniwa: I don't know! Why would we? I don't understand the reasoning. |
| 18:28 | <rniwa> | TabAtkins_: so if I wanted to create a new class that inherits from an object with those attributes |
| 18:28 | <rniwa> | TabAtkins_: then I'll have to manually copy all attributes |
| 18:28 | <rniwa> | TabAtkins_: if they were not in prototype, no? |
| 18:28 | <Ms2ger`> | Philip`, https://www.w3.org/Bugs/Public/show_bug.cgi?id=15925 is for you |
| 18:29 | <TabAtkins_> | Depends on how you're doing your inheritance. ^_^ |
| 18:29 | <TabAtkins_> | Are you chaining from the prototype, or using an exemplar object? |
| 18:29 | <rniwa> | TabAtkins_: sure. but the most common approach is by using prototype chain. |
| 18:29 | <TabAtkins_> | I think I recall that WebIDL is defined to use prototype chaining, so okay. |
| 18:30 | <AryehGregor> | WebIDL for ES doesn't normally put any own properties on the objects themselves, only on the interface, IIRC. |
| 18:30 | <AryehGregor> | Except for [Unforgeable] and maybe some other cases. |
| 18:30 | AryehGregor | is looking at getters now |
| 18:30 | <rniwa> | AryehGregor: right. |
| 18:30 | <TabAtkins_> | Where "interface" means "prototype object", yeah. |
| 18:31 | <TabAtkins_> | <3 "latest editor's draft" links. |
| 18:31 | <rniwa> | AryehGregor, AryehGregor: I think some JS engines optimize attributes on prototype |
| 18:31 | <rniwa> | ugh.. I mean AryehGregor & TabAtkins_ |
| 18:31 | <AryehGregor> | Er, right. |
| 18:31 | <TabAtkins_> | Urgh, what is squatting my ordinary name? |
| 18:31 | <rniwa> | TabAtkins_, AryehGregor: because all objects that share the same prototype can then share some data structure internally |
| 18:32 | rniwa | needs to learn more about JS engines |
| 18:32 | <rniwa> | we just need to summon some ES5 gurus here. |
| 18:32 | <rniwa> | arv: ? |
| 18:33 | <Ms2ger`> | gsnedders? |
| 18:33 | <TabAtkins> | Ah, that's better. |
| 18:33 | <AryehGregor> | http://dev.w3.org/2006/webapi/WebIDL/#indexed-and-named-properties |
| 18:34 | <AryehGregor> | http://dev.w3.org/2006/webapi/WebIDL/#getownproperty |
| 18:35 | <AryehGregor> | Okay, yeah |
| 18:35 | <AryehGregor> | . |
| 18:35 | <AryehGregor> | So if you have a getter, the properties all become own properties. |
| 18:35 | AryehGregor | isn't sure why |
| 18:35 | <AryehGregor> | Except if you have [NamedPropertiesObject]. |
| 18:35 | <rniwa> | :( |
| 18:35 | <AryehGregor> | But that's cautioned against. |
| 18:36 | <rniwa> | AryehGregor: why do we have all those exotic things :( |
| 18:36 | <AryehGregor> | Also, that doesn't work if you have a setter. |
| 18:36 | <TabAtkins> | Okay, time to email public-script-coord and see what's up. |
| 18:36 | <AryehGregor> | rniwa, "Please leave your sense of logic at the door, thanks!" |
| 18:36 | <rniwa> | AryehGregor: we should rename that to DeprecatedNamedPrope rtiesObject |
| 18:36 | <rniwa> | AryehGregor: so that people won't use it |
| 18:37 | <rniwa> | AryehGregor: anyway, comment posted on https://www.w3.org/Bugs/Public/show_bug.cgi?id=13118 |
| 18:37 | <AryehGregor> | Okay. |
| 18:37 | <rniwa> | AryehGregor: not firing events for script-initiated execCommand may not be as bad as I initially thought due to interop with mutation observer API |
| 18:37 | <rniwa> | but I think it's still nice to fire them. |
| 18:38 | rniwa | sends emails to TinyMCE CKEditor developers |
| 18:39 | <Ms2ger`> | I wonder if CK has already committed my patch to stop using element.all |
| 18:41 | <rniwa> | AryehGregor: one question |
| 18:41 | <AryehGregor> | Okay. |
| 18:41 | <rniwa> | AryehGregor: is the plan to add new property on the event object to expose execCommand name? |
| 18:41 | <hsivonen> | rniwa: WebKit's old HTML parser as nowhere near as bad as Gecko's old HTML parser |
| 18:41 | <rniwa> | hsivonen: LOL |
| 18:41 | <hsivonen> | There should be a band called The Designated Experts |
| 18:41 | <AryehGregor> | rniwa, sure, I guess. |
| 18:41 | <Ms2ger`> | ^truth |
| 18:41 | <AryehGregor> | And value. |
| 18:42 | <rniwa> | AryehGregor: yeah |
| 18:42 | <hsivonen> | and The Unpaired Surrogates |
| 18:42 | <rniwa> | AryehGregor: so something like event.editingAction and event.editingActionValue? |
| 18:42 | <AryehGregor> | Yeah, I'll come up with names. |
| 18:42 | <Ms2ger`> | I'd let hsivonen come up with names :) |
| 18:42 | <hsivonen> | s/as nowhere/was nowhere/ |
| 18:47 | <annevk> | The Grapheme Clusterfuck |
| 18:47 | <annevk> | The Adoption Agency |
| 18:48 | <rniwa> | AryehGregor: thanks. |
| 18:48 | <arv> | rniwa: back, reading backlog |
| 18:51 | <arv> | rniwa: What was the question? |
| 18:51 | <rniwa> | AryehGregor: CSS resize property is insufficient for https://bugs.webkit.org/show_bug.cgi?id=12250 |
| 18:52 | <AryehGregor> | rniwa, why? |
| 18:52 | <rniwa> | AryehGregor: it only changes the apparent size |
| 18:52 | <rniwa> | AryehGregor: not width and height property/content attribute |
| 18:52 | <AryehGregor> | It adds style="width: x; height: x". |
| 18:52 | <AryehGregor> | In browsers I tested in. |
| 18:52 | <rniwa> | arv: the question is why WebIDL defines attributes on prototype instead on objects |
| 18:52 | <AryehGregor> | That's how browsers work, and how JS works . . . |
| 18:53 | <rniwa> | arv: my answer was that it's needed for inheritance |
| 18:53 | <rniwa> | arv: but thought you might a better answer for TabAtkins |
| 18:53 | <AryehGregor> | Not strictly. It also defines [Unforgeable]. |
| 18:53 | <rniwa> | AryehGregor: yeah... |
| 18:53 | <AryehGregor> | That still works with inheritance, I think. |
| 18:53 | <arv> | rniwa: The main reason to use getters and setters on the [[Prototype]] is to allow inheritance |
| 18:53 | <rniwa> | arv: okay. so I was telling a lie :P |
| 18:53 | <rniwa> | I wasn't* |
| 18:54 | <arv> | rniwa: also, if these were data properties they could not have side effects so for example innerHTML could not be asked for lazily |
| 18:54 | <rniwa> | AryehGregor: ah, you're right. I was not checking the right element :( |
| 18:54 | <rniwa> | sorry about the noise. |
| 18:54 | <AryehGregor> | arv, they could be accessor properties but still be on the object itself. |
| 18:54 | <rniwa> | AryehGregor: I guess the only thing is that it needs to be undoable. |
| 18:55 | <AryehGregor> | Sure. |
| 18:55 | <arv> | AryehGregor: Yes, that would still be valid when it comes to following the rules of js semantics |
| 18:55 | <AryehGregor> | I believe that's how [Unforgeable] properties work in practice. |
| 18:55 | <arv> | AryehGregor: but it would be ineffiecient and not as useful |
| 18:56 | <AryehGregor> | Unless you don't want authors to be able to mess with the prototype, which is occasionally the case. |
| 18:56 | <AryehGregor> | Like for certain Window properties. |
| 18:56 | <rniwa> | AryehGregor: do you know how I can make resize property work with img? |
| 18:56 | <arv> | AryehGregor: well, host object can break any logic reasoning so anything is doable. The goal of using getters and setters on the prototype for webidl attributes was to make webidl more sane |
| 18:56 | <rniwa> | AryehGregor: I've tried some but doesn't seem to wokr |
| 18:57 | <rniwa> | it's possible that we have a bug there |
| 18:57 | <AryehGregor> | rniwa, resize properties is not very well defined. |
| 18:57 | <AryehGregor> | This says it shouldn't apply to a regular img: http://dev.w3.org/csswg/css3-ui/#resize |
| 18:57 | <AryehGregor> | But I think the spec is wrong. |
| 18:57 | <AryehGregor> | I posted to www-style about it at some point, but it never changed. |
| 18:58 | <AryehGregor> | http://lists.w3.org/Archives/Public/www-style/2011Aug/0565.html |
| 18:58 | <TabAtkins> | arv: The interesting issue is that using the getter/setter/etc stuff in WebIDL establishes own properties, rather than prototype properties. |
| 18:58 | <TabAtkins> | And the flag that switches it to non-own properties is marked as being used only for legacy. |
| 18:58 | <arv> | TabAtkins: That can't be right |
| 18:58 | <TabAtkins> | I'm asking public-script-coord about it now. |
| 18:58 | <TabAtkins> | arv: We just looked it up. ^_^ |
| 18:59 | <arv> | TabAtkins: looking at webidl specs now |
| 18:59 | <TabAtkins> | http://dev.w3.org/2006/webapi/WebIDL/#indexed-and-named-properties\ |
| 18:59 | <arv> | TabAtkins: ah, indexed and named properties are not the same |
| 18:59 | <AryehGregor> | getter/setter = indexed/named properties, more or less. |
| 18:59 | <arv> | TabAtkins: those require proxy like behavior |
| 19:00 | <Ms2ger`> | TabAtkins, the legacy thing is for the global scope polluter only |
| 19:00 | <arv> | AryehGregor: not at all |
| 19:00 | <AryehGregor> | No? |
| 19:00 | <arv> | AryehGregor: indexed/named properties == Proxy |
| 19:00 | <AryehGregor> | I mean WebIDL's getter/setter qualifiers, of course, not ES getter/setter. |
| 19:00 | <arv> | AryehGregor: sorry, different terminalogy |
| 19:00 | <TabAtkins> | arv: I thought the best way to fix CSSStyleDeclaration from being a set list of properties (which is obviously going to be forever incomplete) would be to use getter/setter to establish named properties. |
| 19:01 | <arv> | TabAtkins: What does IE do? |
| 19:01 | <AryehGregor> | TabAtkins, why not just add the properties individually to the prototype object, though? |
| 19:01 | <rniwa> | AryehGregor: hm... but <img src="blah.png" style="overflow:auto;resize:both;"> should still be resizable, no? |
| 19:02 | <TabAtkins> | arv: Everyone but us puts the properties on the prototype. We mark them as own properties. |
| 19:02 | <TabAtkins> | AryehGregor: I don't understand. |
| 19:02 | <AryehGregor> | rniwa, I don't see why not. overflow should make no difference for things that have intrinsic widths. |
| 19:02 | <AryehGregor> | TabAtkins, I mean, what's wrong with the status quo? |
| 19:02 | <rniwa> | AryehGregor: yeah, okay. so I think this is a webkit bu |
| 19:02 | <rniwa> | bug* |
| 19:02 | <TabAtkins> | It's clearly incomplete, and basically required to be, forever? |
| 19:02 | <rniwa> | AryehGregor: http://simple-rte.rniwa.com/?editor=%3Cimg%20src%3D%22https%3A//rniwa.com/wp-content/latex/5f7/5f70c79d395af9fe2eb98c8b362d0bed-ffffff-000000-0.png%22%20style%3D%22overflow%3Aauto%3Bresize%3Aboth%3B%22%3E&designmode=false&script=document.getElementById%28%27editor%27%29.focus%28%29%3B |
| 19:13 | <arv> | TabAtkins: IE has ES getters/setters for all known properties on CSSStyleDeclarationPrototype |
| 19:13 | <arv> | TabAtkins: this seems to be the only sane thing to me |
| 19:14 | <Ms2ger`> | arv, that's what the spec currently says, IIRC |
| 19:14 | <AryehGregor> | Which means in WebIDL terms, they're just regular attributes on the interface. |
| 19:14 | <AryehGregor> | Which is what the spec says, yeah. |
| 19:14 | <arv> | Ms2ger`: good |
| 19:14 | <TabAtkins> | Using ES getters and setters is definitely the correct behavior (so you can do lazy generation), and the spec currently requires them to be on the prototype. |
| 19:14 | <AryehGregor> | Attributes in WebIDL are always accessor properties, not data properties, AFAIK. |
| 19:14 | <Ms2ger`> | Yes |
| 19:14 | <TabAtkins> | But they're currently not spec-compliant if they support more than the 2.1 properties explicitly listed in CSSOM. |
| 19:14 | <TabAtkins> | Which I'd like to fix, for obvious reasons. |
| 19:15 | <AryehGregor> | TabAtkins, well, by that logic nobody is spec-compliant if they support any feature that's not in some particular spec. |
| 19:15 | <arv> | OK. It is unclear to me what the problem is then (except of course that the JSC and V8 bindings in WebKit are broken) |
| 19:15 | <TabAtkins> | The problem is that the IDL in the CSSOM is broken. |
| 19:15 | <TabAtkins> | And I'm trying to fix it. |
| 19:15 | <AryehGregor> | How so? |
| 19:15 | <TabAtkins> | AryehGregor: It has only a small list of properties on the interface, missing all the CSS3 properties. |
| 19:16 | <arv> | TabAtkins: Why is adding a webidl attribute for every css property not the right way to do this? |
| 19:16 | <TabAtkins> | I assumed that the best way to fix this was to use IDL getter/setter, and define the list of named properties to be the CSS properties that the impl supports (suitably converted from dashes to camel-case). |
| 19:16 | <TabAtkins> | arv: Because the list will change continuously, and it's silly to change CSSOM every time we publish a new CSS spec. |
| 19:16 | <TabAtkins> | When this is a mechanical addition. |
| 19:16 | <AryehGregor> | You could also say that any other supported CSS properties have to be regular IDL attributes too. |
| 19:16 | <Ms2ger`> | TabAtkins, indeed |
| 19:17 | <Ms2ger`> | TabAtkins, so use partial interfaces :) |
| 19:17 | <TabAtkins> | Ms2ger`: Requiring every spec to apply diffs to the interface for a mechanical addition is almost as silly. |
| 19:17 | <AryehGregor> | I.e., if a spec defines foo-bar, say that it implies "partial interface CSSStyleDeclarationValue { attribute DOMString fooBar; };" with behavior as defined by CSSOM. |
| 19:17 | <AryehGregor> | You don't have to require the other specs to actually spell out the partial interfaces. |
| 19:17 | <TabAtkins> | AryehGregor: Hm, I guess that would work. |
| 19:17 | <Ms2ger`> | That works too |
| 19:18 | <AryehGregor> | FWIW, many other specs will realistically have to spell out behavior anyway. |
| 19:18 | <Ms2ger`> | But every spec needs to define CSSOM stuff anyway |
| 19:18 | <AryehGregor> | Because lots of properties have non-obvious serialization. |
| 19:18 | <TabAtkins> | We'll have to start defining serialization, but I have hope that for most cases we can do that mechanically too. |
| 19:18 | <TabAtkins> | Anne already attempted that. |
| 19:18 | <arv> | TabAtkins: it will change all the time. That is fine. Just like Ms2ger` said, use partial or supplemental interfaces. If you defined a new CSS property you have to add some idl |
| 19:18 | <AryehGregor> | You have to define an order for computed values, at least. |
| 19:19 | <AryehGregor> | Like, browsers disagree on whether the computed style of textShadow gets serialized with the color first or last. |
| 19:19 | <TabAtkins> | AryehGregor: Yeah, that was already handled by Anne's attempt - the order is whatever order appears in the grammar. |
| 19:19 | <AryehGregor> | Which means the order in the grammar is now retroactively significant when it previously wasn't. |
| 19:19 | <TabAtkins> | That's not implemented yet, but it's an example of how it coudl be handled generally, without every spec needing to define it. |
| 19:19 | <AryehGregor> | http://dev.w3.org/csswg/css3-text/#text-shadow |
| 19:19 | <AryehGregor> | The "Value" puts the lengths first, and the "Computed value" puts the color first. |
| 19:19 | <TabAtkins> | AryehGregor: Not necessarily. We can always legacy-define things if necessary for compat. |
| 19:19 | <AryehGregor> | Yay for consistency. |
| 19:20 | <AryehGregor> | That's probably why browsers disagree. |
| 19:20 | <TabAtkins> | Heh, yeah. |
| 19:20 | <AryehGregor> | Anyway, PLEASE PLEASE PLEASE someone define precise algorithmic serialization rules for everything in CSSOM. |
| 19:20 | <AryehGregor> | It's a trainwreck. |
| 19:20 | <TabAtkins> | Yes. Absolutely. |
| 19:20 | <AryehGregor> | Browsers do ridiculously different things. |
| 19:20 | <AryehGregor> | Like every one serializes colors differently. |
| 19:20 | <TabAtkins> | I'm not sure if that's part of Glen's current effort, but it'll be a very-soon thing. |
| 19:21 | <AryehGregor> | IE mostly uses rgba(), everyone else uses rgb() if alpha is 1. |
| 19:21 | <AryehGregor> | Gecko serializes transparent as "transparent" instead of "rgba(0, 0, 0, 0)". |
| 19:21 | <Ms2ger`> | And if it isn't, let's have AryehGregor edit another spec ;) |
| 19:21 | <TabAtkins> | AryehGregor: IE uses named colors if you specified them as such. ;_; |
| 19:21 | <AryehGregor> | Except maybe only if you specify it as "transparent". |
| 19:21 | <AryehGregor> | Right. |
| 19:21 | <TabAtkins> | Ms2ger`: Nah, I can probably handle that. |
| 19:21 | <AryehGregor> | Will you write tests too? :) |
| 19:21 | <TabAtkins> | I'll be "done" with Flexbox and Images in the near future. |
| 19:21 | <Ms2ger`> | TabAtkins, in upper case? Or was that something else... |
| 19:21 | <TabAtkins> | AryehGregor: Yes! |
| 19:21 | <AryehGregor> | Exhaustive tests? |
| 19:22 | <TabAtkins> | Ms2ger`: Don't know - I think I lowercased everything defensively last time I wrote code to handle it. |
| 19:22 | <TabAtkins> | AryehGregor: Why not? |
| 19:22 | <AryehGregor> | Please do. |
| 19:22 | AryehGregor | is looking forward. |
| 19:22 | <Ms2ger`> | Because those barely exist for CSS |
| 19:22 | <AryehGregor> | Tests barely exist for CSS period. Except some reftests for 2.1. |
| 19:22 | <TabAtkins> | Ms2ger`: Tests barely exist for CSS outside of 2.1. :/ |
| 19:22 | <AryehGregor> | Well, quite a few reftests for 2.1. |
| 19:22 | <AryehGregor> | To be fair. |
| 19:22 | <Ms2ger`> | s/outside of 2.1// |
| 19:22 | <AryehGregor> | How good is test coverage for 2.1? |
| 19:22 | <Ms2ger`> | Mostly manual tests for CSS2.1 |
| 19:22 | <TabAtkins> | Hey, a 30k testsuite isn't nothing. |
| 19:22 | <Ms2ger`> | Bad |
| 19:23 | <TabAtkins> | They are mostly manual, but still. |
| 19:23 | <AryehGregor> | Ugh, manual. Good grief. |
| 19:23 | <TabAtkins> | Yeah. |
| 19:23 | <TabAtkins> | It takes about 10 hours to run it. |
| 19:23 | <AryehGregor> | They're not being converted to reftests? |
| 19:23 | TabAtkins | has done it several times. |
| 19:23 | <Ms2ger`> | 3 days, last I heard |
| 19:23 | <TabAtkins> | Ms2ger`: 10 hours spread over 3 days. You probably last heard that from me. ^_^ |
| 19:23 | TabAtkins | can't run tests continuously for 10 hours. |
| 19:23 | <Ms2ger`> | From MS, actually :) |
| 19:24 | <TabAtkins> | I know that when I was compiling the Chrome implementation report, it was 10 hours over 3 days. |
| 19:24 | <TabAtkins> | And it was horrible. |
| 19:24 | <Ms2ger`> | I wrote references for some MS tests a while ago, but I guess I should get them into the official test suite somehow... |
| 19:24 | <TabAtkins> | AryehGregor: No one putting in much time currently. dbaron has a partially-completed effort that does most of them. |
| 19:25 | <AryehGregor> | Yay. |
| 19:25 | <Velmont> | Aaagh, too much backlog. |
| 19:26 | <TabAtkins> | I think it basically reftests all the tests against each other, so he could generate refs for tests that all render the same. |
| 19:26 | <Ms2ger`> | https://bitbucket.org/ms2ger/css-tests/overview if anybody cares |
| 19:26 | <Ms2ger`> | TabAtkins, I thought that was Opera |
| 19:26 | <TabAtkins> | Ms2ger`: Could be, I dunno. Been a while. |
| 19:29 | <AryehGregor> | If I do say so myself, there are some pretty decent tests now for CSS Transforms. |
| 19:29 | <AryehGregor> | Although probably lots more reftests could be added. |
| 19:29 | <Ms2ger`> | AryehGregor, you don't have family members interested in spec work, do you? :) |
| 19:30 | <AryehGregor> | Probably not. Sorry. |
| 19:30 | <Philip`> | What about your evil twin, Roger G. Heyra? |
| 19:30 | <AryehGregor> | I mean, my brother works in web development-related stuff and might be interested in a job, so if you really want, you could contact him. I don't think he's actually very interested in spec work, though. |
| 19:32 | <Ms2ger`> | Just saying it would be nice to have another competent editor/tester around :) |
| 19:34 | <AryehGregor> | Okay, so when DOM4 talks a |
| 19:34 | <AryehGregor> | Okay, so when DOM4 talks about dispatching an event, that's synchronous, right? |
| 19:34 | <Ms2ger`> | Yes |
| 19:34 | <AryehGregor> | So if specs want it to be async, they have to say to queue a task to fire the event? |
| 19:34 | <Ms2ger`> | Yes |
| 19:34 | <AryehGregor> | Okay. |
| 19:34 | <AryehGregor> | Then I was just confused. |
| 19:34 | <AryehGregor> | So lots of events are really synchronous, I guess? |
| 19:35 | <Ms2ger`> | I wouldn't guess so |
| 19:35 | <AryehGregor> | Hmm, this doesn't reference DOM4: http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#fire-a-simple-event |
| 19:36 | <AryehGregor> | Or it does, but they're not linked. |
| 19:36 | <Ms2ger`> | Ueah |
| 19:36 | <jgraham> | I got bored and started skimming, but if you didn't figure it out yet, attributes are on prototypes because it allows feature detection |
| 19:37 | <jgraham> | Not because it makes logical sense |
| 19:37 | <AryehGregor> | jgraham, usually you can get an instance pretty easily. |
| 19:37 | <jgraham> | (e.g. you can feature detect XHR stuff without having to construct an XHR object) |
| 19:37 | <Ms2ger`> | "In the contexts of events, the terms fire and dispatch are used as defined in the DOM Core specification |
| 19:37 | <AryehGregor> | Also, this way you can fiddle with the value on the prototype. |
| 19:38 | <Ms2ger`> | (2.1.4 Scripting) |
| 19:38 | <jgraham> | AryehGregor: XHR is an example where it is a huge pain |
| 19:38 | <AryehGregor> | Makes sense. |
| 19:38 | <Ms2ger`> | Heh |
| 19:38 | <Ms2ger`> | [DOMCORE] |
| 19:38 | <Ms2ger`> | Web DOM Core, A. van Kesteren. W3C. |
| 19:38 | <jgraham> | If it helps, I argued several times that it didn't make logical sense, but the feature detection argument seems more compelling |
| 19:39 | <AryehGregor> | It also allows polyfills, right? |
| 19:39 | <AryehGregor> | Plus, it matches what non-WebKit browsers do. |
| 19:39 | <jgraham> | AryehGregor: In other backscroll related news, opera are absoutely interested in the editing spec |
| 19:39 | <AryehGregor> | That's good. |
| 19:39 | <AryehGregor> | Everyone seems to be interested. |
| 19:39 | <AryehGregor> | Just no one seems to be implementing it. :) |
| 19:39 | <jgraham> | (It's not what Opera does, right?) |
| 19:39 | <AryehGregor> | What isn't? |
| 19:39 | <jgraham> | attributes on prototypes |
| 19:39 | <AryehGregor> | Is it? |
| 19:39 | <AryehGregor> | I don't remember. |
| 19:40 | <AryehGregor> | It's what IE and Gecko do, generally. |
| 19:40 | <jgraham> | I thought we put them on the objects |
| 19:40 | <jgraham> | because I suggested that we copy Gecko at some point before there was a spec, but we decided not to |
| 19:41 | <jgraham> | AryehGregor: well we aren't rewriting our DocumentEdit right now, but it's not exactly a secret that our implementation doesn't have wonderful site-compat, so I imagine we will make good sometime |
| 19:43 | <AryehGregor> | jgraham, hmm -- now I think I remember. I think "style" in document.head is true, but Object.hasOwnProperty(document.head, "style") is false, and nothing in the prototype chain has an own property with that name either. |
| 19:43 | <AryehGregor> | So . . . :) |
| 19:44 | <Ms2ger`> | The new Object.* APIs generally don't work too well with host objects, iirc |
| 19:45 | <AryehGregor> | Yeah, actually, that seems to be everyone's behavior . . . ? |
| 19:45 | AryehGregor | is confused by that |
| 19:45 | <AryehGregor> | Oh, am I calling it wrong? |
| 19:45 | <AryehGregor> | Yeah, hasOwnProperty() is on the prototype, not Object itself. |
| 19:45 | <AryehGregor> | Oops. |
| 19:46 | <AryehGregor> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cscript%3E%0Aw(%22style%22%20in%20document.head)%0Avar%20obj%20%3D%20document.head%3B%0Ado%20%7B%0Aw(obj.hasOwnProperty(%22style%22))%3B%0Aobj%20%3D%20Object.getPrototypeOf(obj)%3B%0A%7D%20while%20(obj)%3B%0A%3C%2Fscript%3E |
| 19:46 | <AryehGregor> | IE looks to be right here. |
| 19:46 | <AryehGregor> | Opera and WebKit just put it straight on the object. |
| 19:46 | <AryehGregor> | Gecko puts it on two different prototype objects in the chain. |
| 19:46 | <Hixie> | anyone have access to an AT other than VO? |
| 19:46 | <Ms2ger`> | Gecko is weird |
| 19:46 | <Hixie> | i'm trying to find if you can actually select system text labels or move the cursor through them |
| 19:47 | <Ms2ger`> | But it will be all fancy in a couple of months |
| 19:47 | <Hixie> | or if you can only select the entire label and have the UA read it and magnify it |
| 19:48 | <AryehGregor> | So if I want special attributes like .editAction and .editActionValue on my input events, I have to make a new interface that inherits from Event, right? |
| 19:49 | <annevk> | yes |
| 19:49 | <annevk> | InputEvent or some such |
| 19:49 | <annevk> | or reuse one of the existing interfaces |
| 19:49 | <annevk> | if one is suitable |
| 19:49 | <AryehGregor> | It's UIEvent in Gecko, seemingly. |
| 19:50 | <AryehGregor> | So input events on input/textarea would be Event, but contenteditable input events would be EditingInputEvent or something? |
| 19:50 | <AryehGregor> | But they'd have the same name? |
| 19:50 | <annevk> | if you want |
| 19:50 | <AryehGregor> | I'm not sure if that's the best way to do it. |
| 19:51 | <annevk> | you can upgrade the input on input/textarea |
| 19:51 | <annevk> | events are flexible, any string can be used with any interface |
| 19:52 | <annevk> | only requirement is that the interface inherits from Event |
| 19:52 | <AryehGregor> | We probably don't want the extra fields on input/textarea events. |
| 19:52 | <AryehGregor> | Okay, I'll do it that way, I guess. |
| 19:53 | AryehGregor | looks at the editing spec for the first time in forever |
| 19:55 | <AryehGregor> | The last time I changed anything editing-related (excluding selections) seems to be November 9. |
| 19:57 | <Hixie> | jeez, voiceover makes no sense to me |
| 19:57 | <Ms2ger`> | Close your eyes ;) |
| 19:58 | <annevk> | btw |
| 19:58 | <annevk> | on Facebook |
| 19:58 | <annevk> | http://a8.sphotos.ak.fbcdn.net/hphotos-ak-ash4/425243_10150563377962688_607047687_9171920_420903654_n.jpg |
| 19:58 | <AryehGregor> | annevk, so people can do "new HashChangeEvent('input')" and that creates a HashChangeEvent with type "input"? That seems very confusing. |
| 19:58 | <annevk> | yeah they can |
| 19:58 | <Hixie> | ok my conclusion is "voice over doesn't let you move your cursor through text labels" |
| 19:58 | <Hixie> | in the OS |
| 19:58 | <AryehGregor> | Okay, if that's what we want. |
| 20:02 | <arv> | annevk: Why do we have DOMStringList again? |
| 20:03 | <Ms2ger`> | Blame DOM3 |
| 20:03 | <annevk> | source code says |
| 20:03 | <annevk> | HTMLPropertiesCollection.names |
| 20:03 | <annevk> | DataTranser.types |
| 20:03 | <annevk> | Clipboard.types |
| 20:03 | <annevk> | Document.styleSheetSets |
| 20:03 | <annevk> | IndexedDB APIs |
| 20:03 | <annevk> | I think that's all |
| 20:03 | <annevk> | but it's been a while since I surveyed |
| 20:03 | <arv> | I saw that we (WebKit) changed from Array of Strings to DOMStringList and it made things a lot worse since now it is no longer a plain old array |
| 20:03 | <annevk> | oh never do that if it can be avoided |
| 20:03 | <arv> | For dataTransfer.types |
| 20:04 | <AryehGregor> | rniwa, do we want to fire beforeInput/input on unsupported commands too? |
| 20:04 | <AryehGregor> | I guess we should fire beforeInput but not input, probably . . . |
| 20:04 | <rniwa> | AryehGregor: I think so |
| 20:04 | <AryehGregor> | So you can cancel the beforeInput event to avoid throwing NotSupportedErr. |
| 20:04 | <rniwa> | AryehGregor: well but if you're talking about user-definied ones, i'm not so sure |
| 20:05 | <AryehGregor> | I mean, if the author does document.execCommand("sakfdsajda"), does that fire beforeInput before it throws NotSupportedErr? |
| 20:05 | <annevk> | arv: anyway above is the whole list, if that can somehow be changed we can drop it, though I can add a big fat warning in the spec to not use it maybe |
| 20:05 | <annevk> | arv: so that new specs adopt DOMString[] instead |
| 20:06 | <arv> | annevk: Can WebIDL be specced in such a way that it maps DOMStringList to a JS Array? |
| 20:06 | <arv> | annevk: I'm fine with DOMString[] too |
| 20:06 | <annevk> | arv: heycam might know that |
| 20:06 | <Ms2ger`> | typedef DOMString[] DOMStringList; |
| 20:07 | <annevk> | arv: but array does not have contains() |
| 20:07 | <arv> | We should really minimize DOMStringList and other list like interfaces that adds nothing over Array |
| 20:07 | <arv> | We can add contains to Array. |
| 20:07 | <arv> | I'll make sure it is in ES |
| 20:07 | <arv> | I'll make sure it is in ES6 |
| 20:08 | <Ms2ger`> | indexOf != -1 |
| 20:09 | <arv> | or !~indexOf(i) ;-) |
| 20:10 | <Ms2ger`> | r- |
| 20:12 | <Philip`> | 1+indexOf |
| 20:14 | <AryehGregor> | rniwa, wait, does beforeInput actually exist for inputs/textareas? |
| 20:14 | <AryehGregor> | It seems like it doesn't . . . |
| 20:17 | <annevk> | seeking review for |
| 20:17 | <annevk> | <p class=warning>Although <code>DOMStringList</code> has been used |
| 20:17 | <annevk> | historically, new specifications ought to avoid it and use arrays instead. |
| 20:17 | <annevk> | Ms2ger`: arv: ^^ |
| 20:17 | <arv> | annevk: LGTM |
| 20:17 | <Ms2ger`> | wfm |
| 20:19 | <AryehGregor> | rniwa, if the beforeinput event handler removes the editing host from its parent, should the input event still fire? |
| 20:19 | <TabAtkins> | annevk: q+ c+ |
| 20:19 | <AryehGregor> | I'm thinking yes. |
| 20:20 | <annevk> | http://dvcs.w3.org/hg/domcore/rev/d9074e2139ee |
| 20:20 | <TabAtkins> | Damn, getCSSCanvasContext doesn't seem to work for "experimental-webgl". ;_; It just fails silently and returns undefined instead of a context. |
| 20:21 | <AryehGregor> | rniwa, also, what if multiple beforeInput events are fired and only some are canceled? |
| 20:21 | <AryehGregor> | Should canceling any one of them cancel the action? |
| 20:21 | <AryehGregor> | Or should it cause that editing host to not be affected? |
| 20:21 | <AryehGregor> | Probably the latter. |
| 20:22 | <ojan> | AryehGregor: currently beforeInput doesn't exist in any browser or spec |
| 20:22 | <AryehGregor> | Hmm. |
| 20:22 | <AryehGregor> | I guess I'll add it for contenteditable before anyone's specced it for anything else. :) |
| 20:22 | <Ms2ger`> | TabAtkins, CSS? |
| 20:24 | <TabAtkins> | Ms2ger`: Proprietary webkit function introduced in 2008 to achieve similar results to -moz-element(). |
| 20:25 | <TabAtkins> | You use it with -webkit-canvas() so you can use a canvas as an image. |
| 20:25 | <Ms2ger`> | Ah |
| 20:30 | <AryehGregor> | rniwa, do we want to fire events for miscellaneous commands? copy/cut/paste/undo/redo/selectAll should have their own events. I'm not sure if it's useful to fire events for styleWithCSS/useCSS. |
| 20:30 | AryehGregor | decides not to fire events for now |
| 20:32 | <AryehGregor> | Seems WebKit doesn't fire events. |
| 20:54 | <AryehGregor> | Hixie, what tool do you use to check IDL validity? |
| 20:54 | <AryehGregor> | You mentioned one. |
| 20:55 | <rniwa> | AryehGregor: hm... what do you mean by multiple beforeInput events are fired? |
| 20:55 | <AryehGregor> | rniwa, it's a corner case, so I don't think it's worth worrying about right now. |
| 20:55 | <rniwa> | AryehGregor: are they all initiated by the same user action? or are they fired on different editing host? |
| 20:55 | <AryehGregor> | But if you have two editing hosts and the selection spans both of them and you do something like bold, it will fire beforeInput at both per the spec I just wrote. |
| 20:55 | <rniwa> | AryehGregor: not firing for selectAll, styleWithCSS, etc... make sense. |
| 20:55 | <AryehGregor> | (which is a WIP here: http://aryeh.name/tmp/editing/editing.html#methods-to-query-and-execute-commands ) |
| 20:55 | <rniwa> | AryehGregor: yeah... |
| 20:56 | <rniwa> | AryehGregor: I think canceling any of that should cancel the entire action |
| 20:56 | <rniwa> | AryehGregor: makes the behavior simple |
| 20:56 | <AryehGregor> | I think it should cancel it only for that editing host, probably. But it's a corner case, so it doesn't matter much for now. |
| 20:57 | <rniwa> | AryehGregor: maybe but that'll make the implementation more complicated |
| 20:58 | <AryehGregor> | For now I just say it works unless all the events are canceled. |
| 20:58 | <rniwa> | AryehGregor: e.g. what if you had an event handler on the common ancestor of those two editing hosts |
| 20:58 | <rniwa> | AryehGregor: then we'll get two events and you have to cancel both |
| 20:58 | <AryehGregor> | That's confusing no matter what, I think. |
| 20:58 | <AryehGregor> | Unless we always fire the events at the document and not the editing host. |
| 20:58 | <AryehGregor> | Would that be better? |
| 20:58 | <AryehGregor> | Then it's just one event. |
| 20:58 | <AryehGregor> | Makes things simpler. |
| 20:58 | <AryehGregor> | But that doesn't match WebKit. |
| 20:58 | <AryehGregor> | I think ojan preferred firing at the editing host. |
| 20:58 | <rniwa> | AryehGregor: i've started to think that maybe we shouldn't allow multiple editing hosts to be modifed at once |
| 20:59 | <AryehGregor> | It's a lot more intuitive to put the input handler on the editing host itself. |
| 20:59 | <AryehGregor> | Why not? |
| 20:59 | <rniwa> | AryehGregor: it seems odd |
| 20:59 | <rniwa> | AryehGregor: in most cases, only way you'd have non-editable content in an editing host is to have a non-editable widget, etc... |
| 20:59 | <AryehGregor> | Having multiple editing hosts seems odd. :) |
| 20:59 | <rniwa> | AryehGregor: right. |
| 20:59 | <rniwa> | AryehGregor: so why don't we simplify the implementation in that case |
| 21:00 | <rniwa> | AryehGregor: and only modify the editing host of selection start, for example, |
| 21:00 | <AryehGregor> | I think some UAs do that. |
| 21:00 | <AryehGregor> | It wouldn't simplify my spec at all, though. |
| 21:00 | <rniwa> | AryehGregor: modifying multiple editing host at once is like having multi-range selection |
| 21:00 | <AryehGregor> | So I don't see the value in it personally. |
| 21:00 | <AryehGregor> | Not really. |
| 21:00 | <rniwa> | AryehGregor: hm... |
| 21:00 | <AryehGregor> | My spec currently only cares if a node is editable or not. |
| 21:00 | <rniwa> | AryehGregor: I'll think about it more but I think we should try to keep it simple as possible |
| 21:00 | <AryehGregor> | It doesn't care what editing host it's in. |
| 21:01 | <AryehGregor> | So it's more complicated to restrict effects to only one editing host. |
| 21:01 | <AryehGregor> | Not simpler. |
| 21:01 | <rniwa> | AryehGregor: possible. |
| 21:01 | <rniwa> | AryehGregor: I need to read code and think harder |
| 21:01 | <AryehGregor> | We might want to only fire the event at the first editing host, though. |
| 21:01 | <AryehGregor> | Or something like that. |
| 21:01 | <AryehGregor> | I'm not sure. |
| 21:01 | <rniwa> | AryehGregor: but you're right thta it probably doesn't matter in practice |
| 21:01 | <rniwa> | since virtually nobody does something like that |
| 21:02 | <rniwa> | especially because selection shouldn't be able to cross editing boundary by default |
| 21:02 | <AryehGregor> | Or fire it at the first editing host, then only fire at the second if the first wasn't handled. |
| 21:02 | <AryehGregor> | Or I dunno. |
| 21:02 | <AryehGregor> | But it's a corner case. |
| 21:02 | <rniwa> | AryehGregor: come to think of... why can we have multiple editing hosts at once? |
| 21:02 | <AryehGregor> | Because maybe there are two unrelated widgets on the page that both want to be editable. |
| 21:02 | <rniwa> | AryehGregor: I swear webkit doesn't allow you to put selection ends in different editing hosts |
| 21:03 | <rniwa> | AryehGregor: yeah but then you can't place selection ends at both of those ends |
| 21:03 | <AryehGregor> | The user maybe can't. |
| 21:03 | AryehGregor | tests |
| 21:03 | <rniwa> | AryehGregor: you can only put selection in either |
| 21:03 | <AryehGregor> | Scripts can. |
| 21:03 | <rniwa> | AryehGregor: don't think so |
| 21:03 | <rniwa> | AryehGregor: we'll normalize to avoid that |
| 21:04 | <rniwa> | AryehGregor: add range like that |
| 21:04 | <AryehGregor> | It doesn't seem possible for the user to create such a selection, no. |
| 21:04 | <rniwa> | AryehGregor: and you should get a normalized selection |
| 21:04 | <AryehGregor> | In WebKit. |
| 21:04 | <rniwa> | AryehGregor: right. |
| 21:04 | <rniwa> | AryehGregor: I'd argue that it's the desirable behavior |
| 21:04 | <rniwa> | AryehGregor: I don't think other browsers let create selection that crosses multiple editing boundaries either |
| 21:04 | <rniwa> | AryehGregor: users* create |
| 21:05 | <AryehGregor> | Yeah, WebKit seems to not allow such selections. |
| 21:05 | <rniwa> | AryehGregor: I suspect Gecko will let scripts do that |
| 21:05 | <AryehGregor> | I think in Gecko it's possible even for users. |
| 21:05 | <AryehGregor> | At least if they're inline. |
| 21:05 | <rniwa> | but that's because they don't normalize programmatically set selection |
| 21:05 | <AryehGregor> | Maybe not for blocks. |
| 21:05 | <rniwa> | AryehGregor: really? that's surprising |
| 21:05 | <AryehGregor> | It's probably a bug. |
| 21:05 | <rniwa> | AryehGregor: okay |
| 21:05 | <rniwa> | AryehGregor: maybe you should check with ehsan |
| 21:05 | <AryehGregor> | No, maybe not. |
| 21:05 | <AryehGregor> | Scripts can create such selections, but it seems users can't. |
| 21:06 | <AryehGregor> | Oh, wait. |
| 21:06 | <AryehGregor> | I can get a selection in both Gecko and WebKit that contains multiple editing hosts. |
| 21:06 | <AryehGregor> | Select some non-editable content before the first, drag to non-editable content after the second. |
| 21:07 | <AryehGregor> | In Gecko, if you start to drag in non-editable content, it looks like you can drag to the middle of an editing host too. |
| 21:07 | <AryehGregor> | But then hitting keys does nothing. |
| 21:07 | <AryehGregor> | Okay, so this is complicated. |
| 21:07 | <AryehGregor> | Feh. |
| 21:08 | <AryehGregor> | I'll spec it as firing an event at only the first editing host that intersects the selection. |
| 21:08 | <rniwa> | AryehGregor: that's probably a bug |
| 21:08 | <AryehGregor> | Hmm, what about nested editing hosts? |
| 21:08 | <AryehGregor> | Yeah, bugs in browser editing support. Big surprise. :) |
| 21:08 | <rniwa> | AryehGregor: wait |
| 21:08 | <rniwa> | AryehGregor: but if ends at at some non-editable locartions |
| 21:09 | <rniwa> | AryehGregor: I don't think we'll modify the contents |
| 21:09 | <AryehGregor> | Right. |
| 21:09 | <rniwa> | AryehGregor: so we shouldn't fire anything |
| 21:09 | <AryehGregor> | The spec doesn't currently work that way, I don't think. |
| 21:09 | <AryehGregor> | That could be changed. |
| 21:09 | <rniwa> | AryehGregor: oh, the spec should definitely change then. |
| 21:09 | <AryehGregor> | I mean, I know it doesn't work that way. |
| 21:09 | <AryehGregor> | Can do. |
| 21:09 | <rniwa> | AryehGregor: I don't think we want to modify contents when the selection is on non-editable region |
| 21:10 | <rniwa> | AryehGregor: even when it happens to include some editable region |
| 21:10 | <rniwa> | AryehGregor: if webkit ever exhibits such a behavior, then it's a bug |
| 21:10 | <rniwa> | not intentional |
| 21:10 | <AryehGregor> | That's reasonable. |
| 21:10 | <AryehGregor> | I think browsers vary somewhat, but at least some do behave that way. |
| 21:10 | <rniwa> | AryehGregor: yeah |
| 21:10 | <rniwa> | AryehGregor: I think most of us get some corner cases wrong |
| 21:10 | <rniwa> | just like any other thing we implement :( |
| 21:10 | <rniwa> | but I think none of us really intended to support editing multiple hosts at once |
| 21:11 | <AryehGregor> | I can't think of use-cases offhand. |
| 21:13 | <jgraham> | AryehGregor: I think if yousearch for IDL checker or something, that's the tool that Hixie uses |
| 21:14 | <jgraham> | http://www.w3.org/2009/07/webidl-check |
| 21:14 | <Ms2ger`> | Is that the one in Haskell? |
| 21:15 | <rniwa> | AryehGregor: neithe can I |
| 21:15 | <jgraham> | Hard to tell, the code doesn't seem to exist |
| 21:16 | <AryehGregor> | rniwa, what if non-editable content is nested inside editable content and the selection starts or ends in the nested non-editable content? |
| 21:18 | <jgraham> | Ah, dom to the rescue |
| 21:18 | <jgraham> | Seems to be witten in c |
| 21:18 | <rniwa> | AryehGregor: then we shouldn't do anything either. |
| 21:19 | <AryehGregor> | Hmm. |
| 21:19 | <AryehGregor> | Okay. |
| 21:19 | <rniwa> | AryehGregor: so no events should be fired |
| 21:19 | <AryehGregor> | I'll say the command isn't enabled in that case. |
| 21:19 | <jgraham> | http://hackage.haskell.org/package/webidl seems to be the haskell one |
| 21:19 | <AryehGregor> | And return false from execCommand() before firing events if the command isn't supported or enabled. |
| 21:19 | <AryehGregor> | For now. |
| 21:20 | <AryehGregor> | So a command that's expected to possibly change the selected content should be enabled if the active range is not null, and its start and end node are both editable or editing hosts, and there is some editing host that's an inclusive ancestor of the start and end nodes. |
| 21:25 | <ojan> | AryehGregor, rniwa: what was wrong with my proposal to fire it on the root editing host? |
| 21:25 | <rniwa> | ojan: that's okay |
| 21:25 | <rniwa> | ojan: we were talking about the edge case |
| 21:25 | <rniwa> | ojan: where we have multiple editing hosts to work with |
| 21:25 | <AryehGregor> | Do we want the root editing host, or the deepst? |
| 21:25 | <AryehGregor> | deepest? |
| 21:25 | <AryehGregor> | Either one works. |
| 21:25 | <rniwa> | ojan: but turned out that wasn't possible |
| 21:25 | <AryehGregor> | Should these events bubble? |
| 21:25 | <rniwa> | ojan: i.e. if you select multiple editing hosts programatically |
| 21:25 | <rniwa> | ojan: but we don't allow that |
| 21:26 | <rniwa> | ojan: root makes sense |
| 21:26 | <AryehGregor> | If they bubble, we want to fire it at the deepest, not the root. |
| 21:26 | <rniwa> | AryehGregor: ^ |
| 21:26 | <AryehGregor> | That way it will bubble to the root anyway. |
| 21:26 | <rniwa> | AryehGregor: wait... whatever the editing host is defined to be I guess |
| 21:26 | <ojan> | AryehGregor: that makes sense to me... |
| 21:26 | <AryehGregor> | Like: <div contenteditable>foo<span contenteditable>[bar]</span>baz</div> |
| 21:26 | <AryehGregor> | Fire it at the span and let it bubble to the div. |
| 21:26 | <rniwa> | AryehGregor: don't think that makese sense |
| 21:27 | <AryehGregor> | Why not? |
| 21:27 | <rniwa> | AryehGregor: because span isn't an editing host in that case |
| 21:27 | <ojan> | AryehGregor: i think the way you should figure out the deepest editing host though is to find the deepest editing host that contains the entire selection |
| 21:27 | <rniwa> | AryehGregor: since the entire div is editable |
| 21:27 | <AryehGregor> | It is by my definition. |
| 21:27 | <AryehGregor> | ojan, right. |
| 21:27 | <AryehGregor> | That's what I'm doing. |
| 21:27 | <rniwa> | <div contenteditable>foo<span contenteditable="false"><span contenteditable>[bar]</span>baz</span></div> |
| 21:27 | <AryehGregor> | rniwa, well, you can add an extra <span contenteditable=false> if you want, but in my definitions the span is an editing host too. |
| 21:27 | <ojan> | AryehGregor: so there's no issue of dealing with selections that cross editing hosts |
| 21:27 | <rniwa> | AryehGregor: this is a better example |
| 21:27 | <rniwa> | AryehGregor: in this case, you're right that we should be firing the event at span |
| 21:27 | <rniwa> | AryehGregor: because that's the enclosing editing host of the selection |
| 21:28 | <AryehGregor> | In the other case I'd also say fire at the span, but it makes no big difference. |
| 21:28 | <AryehGregor> | Currently in my spec, <div contenteditable><span contenteditable>foo</span></div> isn't the same as <div contenteditable><span>foo</span></div>. |
| 21:28 | <AryehGregor> | Although it's mostly the same. |
| 21:28 | <ojan> | <div contentEditable><div id=this-is-the-right-editing-host contentEditable><span contentEditable>ba[r</span><span contentEditable>baz</span></div></div> |
| 21:29 | <AryehGregor> | Where's the end of the selection? |
| 21:29 | <AryehGregor> | In "baz"? |
| 21:29 | <AryehGregor> | If so, right, I agree. |
| 21:29 | <ojan> | woops...left it out :) |
| 21:29 | <ojan> | yeah |
| 21:29 | <ojan> | AryehGregor: ok...that makes sense to me then. |
| 21:29 | <AryehGregor> | "Let affected editing host be the editing host that is an inclusive ancestor of the active range's start node and end node, and is not the ancestor of any editing host that is an inclusive ancestor of the active range's start node and end node." |
| 21:30 | <ojan> | AryehGregor: yeah, i think that works |
| 21:30 | <ojan> | AryehGregor: a little hard to parse that english...but i think it's correct |
| 21:30 | <ojan> | and unambiguous |
| 21:30 | AryehGregor | considered "not the ancestor of any other such editing host", but decided to be more explicit |
| 21:31 | <AryehGregor> | Okay, here's my WIP now: http://aryeh.name/tmp/editing/editing.html#methods-to-query-and-execute-commands |
| 21:31 | <AryehGregor> | Subject to change without notice for now. |
| 21:32 | <AryehGregor> | The interesting part is the execCommand() definition and the stuff before it, you can stop reading when you get to queryCommandEnabled(). |
| 21:34 | <ojan> | AryehGregor: that all looks good to me...except... |
| 21:34 | <ojan> | AryehGregor: I think the spec needs to handle the case of JS modifying the DOM during the beforeInput event |
| 21:35 | <ojan> | AryehGregor: e.g the affected editing host can change |
| 21:35 | <AryehGregor> | Hmm, right. |
| 21:36 | <AryehGregor> | Maybe we need to bail out in that case. |
| 21:36 | <AryehGregor> | Like if the beforeInput handler does getSelection().removeAllRanges(), that will break everything. |
| 21:36 | <ojan> | AryehGregor: right, it depends |
| 21:36 | <AryehGregor> | Perhaps just add another check for enabled after the beforeInput event. |
| 21:36 | <ojan> | AryehGregor: so...as long as step 6 doesn't make any assumptions |
| 21:36 | <ojan> | AryehGregor: and step 7 recomputed the affected editing host, i think we're fine |
| 21:37 | <AryehGregor> | If there's still an affected editing host but it changes due to the beforeInput handler, do we want to fire the input event at the old one or the new one? |
| 21:37 | <ojan> | AryehGregor: my intuition is the new one |
| 21:37 | <AryehGregor> | I'm worried about step 7 recomputing the affected editing host, because there might be a bug in the action that makes the selection disappear or something. |
| 21:37 | <AryehGregor> | I'd prefer to be robust against that. |
| 21:37 | <ojan> | i see |
| 21:38 | <ojan> | AryehGregor: you could recompute it as step 5b |
| 21:39 | <ojan> | AryehGregor: sorry...step 5.4 |
| 21:39 | <ojan> | AryehGregor: i think that would address all the issues as long as each command action is robust against different DOM states, which is needs to be anyways |
| 21:46 | <AryehGregor> | ojan, I was thinking I'd repeat the the "If command is not enabled" check as 5.4, then recompute affected editing host as 5.5, then use that. |
| 21:46 | <AryehGregor> | So if beforeinput changes the affected editing host, that's fine, and the input event will be fired there. |
| 21:47 | <AryehGregor> | But if it makes the command no longer enabled, the command won't execute. |
| 21:47 | AryehGregor | edits |
| 21:47 | AryehGregor | has to go in a few minutes |
| 21:52 | <rniwa> | AryehGregor: I think your spec should change to treat <div contenteditable><span contenteditable>foo</span></div> identically to <div contenteditable><span>foo</span></div> |
| 21:52 | <AryehGregor> | Okay, refresh and tell me if you like it. |
| 21:52 | <rniwa> | AryehGregor: that's how browsers work as far as I know. |
| 21:53 | <AryehGregor> | rniwa, browsers behave completely randomly whenever you nest anything with contenteditable other than inherit. |
| 21:53 | <AryehGregor> | I had some use-case for treating it differently. |
| 21:53 | <rniwa> | AryehGregor: sure we have lots of bugs |
| 21:53 | <AryehGregor> | I mean, there's no use-case for treating it the same, because you could always just remove the contenteditable attribute. |
| 21:53 | <rniwa> | AryehGregor: but I don't think we want to re-define the editing host that way |
| 21:53 | <rniwa> | AryehGregor: but that's not how UAs behave today though |
| 21:54 | <AryehGregor> | Most of this isn't how they behave today. :) |
| 21:54 | <rniwa> | AryehGregor: contenteditable attribute is ignored if it's already in the editable region |
| 21:54 | <rniwa> | AryehGregor: I mean... we can't implement this. |
| 21:54 | <AryehGregor> | Anything with contenteditable=true will not have its attributes changed or be removed from its parent. |
| 21:54 | <rniwa> | AryehGregor: there's no sane way for webkit to distinguish those two cases |
| 21:54 | <AryehGregor> | Because really you just use a CSS property, right? |
| 21:54 | <rniwa> | AryehGregor: right. |
| 21:54 | <AryehGregor> | And the computed value isn't going to be different. |
| 21:54 | <AryehGregor> | Fair enough. |
| 21:54 | <rniwa> | AryehGregor: so I don't think we can do this. |
| 21:54 | <AryehGregor> | Feel free to file a bug. |
| 21:55 | <AryehGregor> | Although, IIRC there are other problems that you using a CSS property causes, right? Like you can't handle :read-write properly? |
| 21:55 | <rniwa> | AryehGregor: right. but we can't get rid of the CSS property at the moment. |
| 21:55 | <rniwa> | AryehGregor: we might be able to do eventually but not now |
| 21:55 | <AryehGregor> | The behavior you suggest is probably more logical anyway, though, because you'd expect contenteditable=inherit to work the same as specifying contenteditable=true or false depending on what the parent is. |
| 21:55 | <AryehGregor> | Well, you can't implement the spec right now in general, only eventually. :) |
| 21:56 | <rniwa> | AryehGregor: right. |
| 21:56 | <AryehGregor> | If you file a bug, I'll look at it later. It's a corner case anyway. |
| 21:56 | <rniwa> | AryehGregor: okay. |
| 21:56 | <rniwa> | AryehGregor: btw, you should rename "issue" to "bug" |
| 21:56 | <rniwa> | AryehGregor: or put both |
| 21:56 | <AryehGregor> | Yeah, maybe. |
| 21:57 | <AryehGregor> | File a bug on that too. :) |
| 21:57 | <rniwa> | I was looking for "bug" for a while :( |
| 21:57 | <AryehGregor> | I have to go now. |
| 21:57 | <AryehGregor> | :( |
| 21:57 | <rniwa> | AryehGregor: k, ttyl |
| 22:00 | <rniwa> | AryehGregor: filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=16095 |
| 22:00 | <AryehGregor> | Thanks. |
| 22:03 | <AryehGregor> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=13118#c26 |
| 22:03 | <AryehGregor> | And I'm off. |
| 22:04 | <heycam> | arv, I don't think DOMStringList can really be a plain JS array due to the lack of methods that annevk mentions, and also because then the object that has the DOMStringList property cannot "watch" it for changes |
| 22:05 | <heycam> | arv, the spec that defines DOMStringList can use the [ArrayClass] extended attribute on the interface to make it inherit from Array.prototype, so that you can easily use Array methods though |
| 22:05 | <heycam> | TabAtkins, did you get all your Web IDL questions earlier answered? (saw a bunch of highlights in my scrollback) |
| 22:06 | <TabAtkins> | heycam: I ended with a question sent to public-script-coord. Answer there, please? |
| 22:06 | <heycam> | TabAtkins, ok |
| 22:10 | <Hixie> | AryehGregor: what jgraham said |
| 22:25 | <annevk> | fyi: I gave glenn write access to https://bitbucket.org/ms2ger/specification-data |
| 23:30 | <rniwa> | annevk5: hi |
| 23:31 | <rniwa> | annevk5: what do you feel about disallowing mutation events inside the shadow DOM? |
| 23:31 | <rniwa> | annevk: ^ |
| 23:32 | <smaug____> | sounds ok to me |
| 23:32 | <rniwa> | smaug____: great. |
| 23:32 | <smaug____> | (which ever shadow dom spec ends up being implemented) |
| 23:33 | <rniwa> | smaug____: well we're talking about thi on https://bugs.webkit.org/show_bug.cgi?id=79278 |
| 23:33 | <rniwa> | smaug____: I think dglazkov likes the idea |
| 23:33 | <rniwa> | smaug____: so as long as people from other vendors want them to fire there, we should spec it so that only new mutation observer API can be used inside the shadow DOM |
| 23:34 | <smaug____> | sounds ok. Ofc "there" is still not defined :) |
| 23:34 | <TabAtkins> | rniwa: Mutation events carry too much unwipeable info about the shadow, so yeah, they shouldn't escape the shadow. |
| 23:34 | <TabAtkins> | And shutting down mutation listeners entirely inside of shadow sounds totally fine. |
| 23:35 | <rniwa> | TabAtkins: great. |
| 23:35 | <smaug____> | I guess the idea is to not have mutation events at all in shadow dom |
| 23:35 | <rniwa> | TabAtkins: we're going to do the both |
| 23:35 | <smaug____> | which is what I prefer |
| 23:35 | <TabAtkins> | (I don't think the outer page should ever want to know about mutations inside of shadows anyway.) |
| 23:35 | <rniwa> | TabAtkins: so there won't be any mutation event in the shadow DOM |
| 23:35 | <rniwa> | mutation events need to die anyway |
| 23:35 | <TabAtkins> | smaug____: Within a shadow, mutation observers can be useful I guess. |
| 23:36 | <smaug____> | mutationobservers sure, but they are limited to shadow tree |
| 23:36 | <TabAtkins> | Yes, okay, so we're agreeing. ^_^ |
| 23:36 | <smaug____> | yes :) |
| 23:36 | <TabAtkins> | Also: should I eat another whole box of Thin Mints? (yes)/(hell yes) |
| 23:36 | <smaug____> | whatever the shadow dom will be, mutation events shouldn't fire there |
| 23:37 | <rniwa> | smaug____: is your email address at welho.com? |
| 23:37 | <smaug____> | uh, no, please |
| 23:37 | <smaug____> | it is one of my email addresses |
| 23:37 | <rniwa> | smaug____: okay, which one should I use to cc you on public-webapps? |
| 23:37 | <smaug____> | I prefer Olli⊙pf |
| 23:37 | <rniwa> | smaug____: okay, will do. |
| 23:37 | <TabAtkins> | I keep forgetting that you're Olli, smaug____ . |
| 23:38 | <TabAtkins> | Damn lack of Real Names. |
| 23:38 | <smaug____> | TabAtkins: you've been here too few years :) |
| 23:38 | <TabAtkins> | It's taken me a while to remember that Zewt is Glen. |
| 23:38 | <rniwa> | smaug____: okay, I sent an email out to public-webapps |
| 23:38 | <rniwa> | smaug____: but it seems like we're already on an agreement here :D |
| 23:38 | <rniwa> | smaug____: disallowing mutation events in shadow DOM may even encourage people to start using new mutation observer API |
| 23:38 | <rniwa> | smaug____: which is a win-win for us |
| 23:39 | smaug____ | should finalize his mutationobserver patch next week |
| 23:39 | <smaug____> | and sorry, I've been really busy with other stuff |
| 23:42 | <smaug____> | rniwa: do you happen to have fuzz tester for mutation observer? |
| 23:43 | <TabAtkins> | We're not fuzzing it yet (I think), but apparently it's quite easy to add. |
| 23:44 | <smaug____> | not fuzzing yet? expect some instability then :) |
| 23:44 | <TabAtkins> | Oh, definitely. |
| 23:44 | <TabAtkins> | We should be fuzzing, like, 5000% more. |
| 23:44 | <TabAtkins> | Fuzz ALL the things. |
| 23:44 | <smaug____> | yeah |
| 23:45 | <smaug____> | writing good fuzzers is not easy |
| 23:47 | <TabAtkins> | We apparently have a pretty nice fuzzing infrastructure that our security people put together. |
| 23:47 | <TabAtkins> | You feed it a bunch of wide-sprectrum representative tests, it mutates them into fuzz tests. |
| 23:55 | <rniwa> | smaug____: we have been. |
| 23:55 | <rniwa> | smaug____: aklein will probably know. |
| 23:56 | <smaug____> | ok, I'll send some email |
| 23:56 | <rniwa> | smaug____: we have an automated fuzz testing infrastructure that automatically mutates existing tests and generate crazy js tests |
| 23:56 | <rniwa> | smaug____: don't think we save results though |
| 23:56 | <rniwa> | so not sure if we can share those with you guys |
| 23:56 | <smaug____> | ah, ok |
| 23:57 | <rniwa> | smaug____: but it's probably worth shooting an email anyway |
| 23:57 | <rniwa> | smaug____: we might come up with some way to do it |
| 23:58 | <rniwa> | dglazkov: yt? |
