| 00:15 | <zcorpan> | Hixie: +partial interface <a href=#document>Document</a> { |
| 00:15 | <zcorpan> | + readonly attribute <code><a href=#document>Document</a></code> <a href=#htmldocument title=HTMLDocument>HTMLDocument</a>; |
| 00:15 | <zcorpan> | Hixie: that doesn't make sense |
| 00:15 | <Hixie> | nonetheless it is what i intended, I believe |
| 00:15 | <Hixie> | see the bug in question for more details |
| 00:15 | <zcorpan> | Hixie: don't you want that on Window ? |
| 00:15 | <Hixie> | oh, right |
| 00:16 | <Hixie> | oops |
| 00:16 | <Hixie> | good point |
| 00:16 | <zcorpan> | now sleep |
| 00:16 | <Hixie> | also i made it return the document instead of the interface! |
| 00:16 | <Hixie> | man i suck |
| 00:17 | <zcorpan> | heh |
| 00:37 | <Hixie> | abarth: http://www.w3.org/Bugs/Public/show_bug.cgi?id=13776 makes my head hurt |
| 00:37 | <Hixie> | er |
| 00:37 | <Hixie> | s/abarth: // |
| 00:43 | <Hixie> | OH MY GOD BROWSERS MAKE NO SENSE |
| 00:43 | <Hixie> | <form> <img name=y><img name=y> </form> form.y == HTMLCollection with length 2, containing two images |
| 00:44 | <Hixie> | <form> <img name=y><img name=y><input name=y> </form> form.y == the <input> element. |
| 00:44 | <Hixie> | WHAT IS THIS I DON'T EVEN |
| 00:55 | <sicking> | Hixie: do they all do the same thing? |
| 00:56 | <sicking> | Hixie: with a lot of edge cases around this I wouldn't expect them to |
| 01:01 | <Hixie> | sicking: yeah, more or less |
| 01:02 | <sicking> | that's awesome |
| 01:10 | <jarek> | Hi |
| 01:10 | <jarek> | the {url} is defined in CSS as follows: |
| 01:10 | <jarek> | ([!#$%&*-~]|{nonascii}|{escape})* |
| 01:11 | <jarek> | what does exactly [!#$%&*-~] sequence mean? One char from !,#,$,%,&,*,-,~ ? |
| 01:11 | <jarek> | is so, it doesn't make sense to me |
| 01:26 | <Hixie> | sicking: for extra amusement, <form> <img name=y><img name=y><input name=y type=image> </form> form.y == HTMLCollection with length 2, containing the two <img>s |
| 01:26 | <Hixie> | jarek__: it means one char from ,#,$,%,& or any char from * to ~ |
| 01:26 | <sicking> | Hixie: yeah, the old type=image bug that we inherited from ancient netscape days is hilarious |
| 01:26 | <Hixie> | yeah |
| 01:27 | <sicking> | i suspect it annoys websites as much as it annoys us |
| 01:27 | <Hixie> | also, <form><input name=x></form> form.x == the input; now change form.x.name to 'y' and form.x STILL returns the input |
| 01:27 | <sicking> | but there's just too much old content depending on it to change it |
| 01:27 | <Hixie> | yeah |
| 01:27 | <sicking> | Hixie: the latter might have just changed in Firefox |
| 01:27 | <sicking> | Hixie: try nigtlies |
| 01:28 | <sicking> | Hixie: <3 proxies |
| 01:28 | <sicking> | Hixie: i suspect the web doesn't depend on that |
| 01:28 | <Hixie> | seems to me it still does it |
| 01:28 | <sicking> | Hixie: in general, behavior around mutations is much less depended on since old content didn't do it |
| 01:29 | <Hixie> | so do all the other browsers |
| 01:29 | <Hixie> | my understanding is that this one is required by compat |
| 01:29 | <sicking> | Hixie: ooh, form.x, not form.elements.x |
| 01:29 | <Hixie> | the html spec has required it for some time and that's not the kind of craziness i put in without good reason ;-) |
| 01:29 | <Hixie> | yeah, none of this is .elements. |
| 01:29 | <Hixie> | .elements is somewhat better behaved |
| 01:29 | <Hixie> | at least in non-webkit |
| 01:29 | <jarek__> | Hixie: thanks |
| 02:49 | <annevk> | Hixie, pong |
| 02:54 | <annevk> | heycam|away, I meant exceptions "thrown by" Web IDL |
| 03:20 | <Hixie> | annevk: XMLDocument thing, see bugmail |
| 03:22 | <MikeSmith> | hmm, http://validator.nu/?doc=https%3A%2F%2Fdvcs.w3.org%2Fhg%2Fwebperf%2Fraw-file%2Ftip%2Fspecs%2FPageVisibility%2FOverview.html&showsource=yes |
| 03:23 | <annevk> | I see, we've been trying to avoid such a dependency |
| 03:23 | <MikeSmith> | «The encoding "utf-8" is not the preferred name of the character encoding in use. The preferred name is utf-8.» |
| 03:26 | <annevk> | Maybe HTML should simply define createDocument() as well then |
| 03:26 | <annevk> | if it's for creating XMLDocument |
| 03:27 | annevk | sighs |
| 03:27 | <MikeSmith> | Content-Type: text/html; charset="UTF-8" |
| 03:28 | <Hixie> | annevk: you should be fine |
| 03:28 | <Hixie> | annevk: no dependency |
| 03:28 | <Hixie> | annevk: just put interface XMLDocument : Document { } after you define Document |
| 03:28 | <Hixie> | annevk: and made createDocument() return an XMLDocument |
| 03:29 | <Hixie> | annevk: that's all |
| 03:29 | <annevk> | aah |
| 03:29 | <annevk> | you made it partial |
| 03:29 | <annevk> | sweet |
| 03:29 | <Hixie> | yup |
| 03:29 | <annevk> | thanks Hixie |
| 03:29 | <Hixie> | np |
| 03:53 | <annevk> | Hixie, http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-domimplementation-createdocument |
| 03:58 | <ojan> | annevk: i have yet to respond to the e4x thread, but just fyi, i disagree with alex that quasi's are the right solution to this |
| 03:59 | <ojan> | annevk: we should either move forward with an html-ified e4x variant or with your earlier array based proposal |
| 03:59 | <ojan> | i'll try and compose a proper email response tomorrow |
| 03:59 | <ojan> | too many threads going on at once to get any coding done :( |
| 04:01 | <annevk> | yay another supporter :) |
| 04:02 | <annevk> | though qfox might have a point that convincing TC39 is beyond the realm of possibility |
| 04:36 | <annevk> | http://stackoverflow.com/questions/6905167/javascript-parser-for-rdf-json-from-webvtt seems like this WebVTT thing is taking off |
| 05:23 | <rniwa> | annevk: yt? |
| 05:24 | <annevk> | yeah, just about to go though |
| 05:24 | <annevk> | back in an hour or so |
| 05:24 | <rniwa> | k |
| 05:25 | <rniwa> | Hixie: yt? |
| 05:41 | <annevk> | rniwa, back |
| 05:41 | annevk | is bad with estimates |
| 05:42 | <rniwa> | hi |
| 05:43 | <rniwa> | annevk: did you see my email about restoring selection? |
| 05:43 | <annevk> | hadn't read it yet |
| 05:43 | <rniwa> | ok |
| 05:44 | <rniwa> | so the thing is that there's a slight difference in the way selection is restored on Mac and IE/Firefox |
| 05:44 | <rniwa> | when undoing deletion |
| 05:45 | <rniwa> | annevk: say you have "hello world" and deleted "world" from the end by repeatedly pressing the backspace key |
| 05:45 | <rniwa> | until you get "hello" |
| 05:45 | <rniwa> | then you undo this on IE/Firefox, you'll get "hello world" with the caret collapsed at the end of "world" |
| 05:46 | <rniwa> | however on Mac's NSTextView, notepad, and WebKit, you'll see "world" being selected. |
| 05:46 | <annevk> | also in Opera |
| 05:46 | <rniwa> | annevk: oh you select the deleted contents? |
| 05:47 | <annevk> | i just tried and it seems like it |
| 05:47 | <rniwa> | I see. |
| 05:47 | <annevk> | not sure if we should standardize one way or the other though |
| 05:47 | <rniwa> | hm... but I think we might want to match the platform convetion |
| 05:47 | <rniwa> | at least for WebKit, we always try to match NSTextView's behavior whenever possible |
| 05:48 | <rniwa> | given that the feature already works as expected, I'm not sure people would like us to change the behavior. |
| 05:48 | <rniwa> | on the other hand, this gives us a lot of headache with respect to automatic transactions |
| 05:48 | <rniwa> | because when an author creates a DOM transaction group with a bunch of automatic transactions |
| 05:49 | <rniwa> | there's no way for us to delete whether a given DOM transaction is deleting stuff, inserting stuff, or replacing stuff |
| 05:49 | <rniwa> | since just deleting contents may involve inserting new brs, replacing p's and div's to fix up paragraphs :( |
| 05:49 | <othermaciej> | for user actions, it is almost certainly the right thing to follow platform convention |
| 05:49 | <othermaciej> | for programmatically initiated commands, it is a tradeoff |
| 05:49 | <rniwa> | othermaciej: hi maciej! |
| 05:50 | <rniwa> | othermaciej: I think the point of automatic transaction is to replace browser's native editing support |
| 05:50 | <othermaciej> | on the one hand, for a programmatically initiated command, the following JS code may make assumptions about the specific change that was made |
| 05:50 | <rniwa> | othermaciej: or add a custom editing action |
| 05:50 | <annevk> | hey othermaciej, long time! |
| 05:50 | <othermaciej> | on the other hand, ideally you want such code to follow platform conventions |
| 05:50 | <othermaciej> | hello annevk |
| 05:50 | <othermaciej> | I'm here every day, I just usually don't have much to say |
| 05:51 | <rniwa> | othermaciej: yeah, it's quite a dillema :( |
| 05:51 | <annevk> | rniwa, I don't think I really know about this to give useful input, other than that for user initiated actions, we usually don't require much in the spec |
| 05:51 | <rniwa> | annevk: yeah... I should probably talk to AryehGregor about this as well |
| 05:51 | <othermaciej> | if you programatically trigger an undo, it really should do the same thing as a user-level undo command would |
| 05:51 | <rniwa> | but then his spec doesn't really deal with undo/redo at the moment |
| 05:52 | <rniwa> | othermaciej: right. otherwise, it'll be way too confusing |
| 05:52 | <rniwa> | othermaciej: but it seems like the only way to restore selection properly |
| 05:53 | <rniwa> | othermaciej: is if author provided us of some information such as whether a DOM transaction deletes contents or not |
| 05:53 | <rniwa> | othermaciej: or use some heuristics to determine if a given DOM transaction looks like deleting contents |
| 05:53 | <rniwa> | I'd like to avoid the latter because that'll make things unpredictable |
| 05:54 | <othermaciej> | rniwa: are there special cases other than a series of backspace actions? |
| 05:54 | <rniwa> | since selection behavior is quite visible to scripts |
| 05:54 | <rniwa> | othermaciej: well you can insert text then delete |
| 05:54 | <othermaciej> | rniwa: cause if so, the only special case is deleting immediately behind the caret |
| 05:54 | <rniwa> | othermaciej: or you can delete then insert |
| 05:54 | <othermaciej> | does insert then delete collapse into a single undo transaction in normal editing? |
| 05:54 | <rniwa> | othermaciej: yeah but that's almost impossible to detect if the author was to implement it themselves |
| 05:54 | <rniwa> | othermaciej: yes |
| 05:55 | <rniwa> | othermaciej: at least on WebKit & Gecko |
| 05:55 | <othermaciej> | how about paste followed by backspace? |
| 05:55 | <rniwa> | othermaciej: also on MS Word, WordPad and NSTextView but NOT on notepad |
| 05:55 | rniwa | checks |
| 05:55 | <rniwa> | othermaciej: paste is treated a separate action |
| 05:55 | <zewt> | well, notepad doesn't even have multi-level undo, and its single-level undo is horrid ... safe to ignore it, i think |
| 05:56 | <rniwa> | othermaciej: so undoing paste+deletion will only undoes the deletion |
| 05:56 | <rniwa> | zewt: good point |
| 05:56 | <othermaciej> | rniwa: hmm, so typing a single character is observably different from a one-char paste |
| 05:56 | <rniwa> | othermaciej: yeah |
| 05:56 | <rniwa> | othermaciej: copy & paste (including drag & drop) are very special beasts |
| 05:56 | <zewt> | i don't think windows really has any strong platform-specific undo conventions, most of the platform core stuff has very weak undo |
| 05:57 | <zewt> | (eg. win32 text boxes also don't have multi-level undo) |
| 05:57 | <rniwa> | zewt: RichTextEdit has multi-level undo |
| 05:57 | <othermaciej> | rniwa: it sounds like, to capture this behavior correctly, you need an indication of author intent |
| 05:57 | <rniwa> | zewt: that's what WordPad uses as far as I know. |
| 05:57 | <rniwa> | othermaciej: yeah |
| 05:57 | <othermaciej> | rniwa: specifically, actions in response to "typing" are a special case |
| 05:58 | <othermaciej> | and you can't tell from the DOM change alone whether it is "typing" |
| 05:58 | <zewt> | (of course, undo particulars are still UA-specific at least, so an undo API should still be able to handle existing browser undo behavior) |
| 05:58 | <rniwa> | othermaciej: right |
| 05:58 | <zewt> | (eg. regardless of whether that behavior comes from the UA or the OS) |
| 05:59 | <rniwa> | zewt: yeah, I think we need to have some granularity on how undo/redo is done |
| 05:59 | <zewt> | personally i'd be happy if this fixes undo cursor positions and nothing else, that's the #1 thing that drives me crazy about rich text editors in browsers by a *huge* margin |
| 05:59 | <rniwa> | othermaciej: so maybe isTyping boolean? |
| 06:00 | <rniwa> | othermaciej, annevk: another headache I have is the fact that some automatic transaction may not want to mess with selection at all |
| 06:00 | <othermaciej> | rniwa: I suppose one implicit way to do it is to look at the event being processed, though key events can sometimes trigger non-typing actions (even for keys that would normally just enter text) |
| 06:00 | <rniwa> | othermaciej: not sure if that works because authors can do whatever they please to do |
| 06:01 | <rniwa> | othermaciej: e.g. they can decide to insert stuff when delete key is pressed |
| 06:01 | <zewt> | also in theory you could implement a touchscreen keyboard (where mouse events might want to behave like keystrokes) |
| 06:02 | <rniwa> | zewt: yeah |
| 06:02 | <rniwa> | othermaciej: another thing to consider is that authors may want to emulate typing commands without actually receiving user inputs |
| 06:03 | <rniwa> | also... another problem is that even if authors hinted us that some DOM transaction is deleting stuff or is a typing command |
| 06:03 | <rniwa> | it might be still hard for us to detect exactly what has been deleted |
| 06:04 | <rniwa> | since deleting a line break for example may end up fixing up the entire paragraph by inserting div's, p's, br's :( |
| 06:04 | <annevk> | Man, the way WebVTT is defined makes for a terrible read |
| 06:05 | <zewt> | havn't really followed this, but the basic idea is being able to coalesce edit transactions, right? |
| 06:05 | <zewt> | three delete-character edits coalescing into a single action, etc |
| 06:05 | <rniwa> | zewt: if author wishes to, yes |
| 06:05 | <rniwa> | zewt: the key issue is that how we restore selection in those cases |
| 06:06 | <rniwa> | zewt: in the case of non-typing commands, it's quite simple |
| 06:06 | <rniwa> | zewt: you just remember what the selection looked like before an automatic transaction |
| 06:06 | <rniwa> | zewt: and restore exactly that |
| 06:06 | <zewt> | btw. how can you delete a character when you have a selection? that normally turns backspace actions into delete-the-whole-selection |
| 06:07 | <rniwa> | when the DOM transaction is undone |
| 06:07 | <rniwa> | zewt: well selection can be either collapsed or uncollapsed |
| 06:07 | <rniwa> | it doesn't really matter |
| 06:08 | <rniwa> | zewt: the problem is when something is deleted and that deletion is undone |
| 06:08 | <rniwa> | zewt: in that case WebKit and Opera currently select the contents that have been added back to the document |
| 06:09 | <rniwa> | zewt: but when authors implement some automatic transactions, there is no good way for us to tell what has been deleted |
| 06:09 | <rniwa> | zewt: or worse, whether the command was deleting something at all |
| 06:09 | <rniwa> | s/something/anything/ |
| 06:10 | <zewt> | yeah i see what you mean |
| 06:10 | <zewt> | is the coalescing of transactions under the browser's control? |
| 06:10 | <rniwa> | zewt: it's under author's control 'til it's added to an UndoManager |
| 06:10 | <zewt> | eg. control-backspace two words in firefox is one undo transaction, two in webkit (chrome at least) |
| 06:11 | <zewt> | er, two undos |
| 06:11 | <zewt> | er no that was right (tired/late) |
| 06:11 | <rniwa> | zewt: really? that's surprising to me |
| 06:11 | <rniwa> | zewt: I thought we treat those as one undo item |
| 06:11 | <zewt> | don't know if that's chrome-specific behavior |
| 06:11 | <zewt> | (would have to load a vm to try in safari) |
| 06:11 | <rniwa> | interesting... |
| 06:12 | <rniwa> | zewt: it's webkit behavior probably copied from Mac |
| 06:12 | <Hixie> | rniwa: here now |
| 06:13 | <zewt> | rniwa: even more fun is multi-selects in firefox, where a single user action might delete noncontiguous text D: |
| 06:13 | <zewt> | (guess the same thing could happen in other browsers, if there's hidden text about) |
| 06:14 | <rniwa> | zewt: that, i'm not too worried about because only gecko supports multi-range selection at the moment |
| 06:14 | <rniwa> | zewt: so gecko can do whatever it wants to do |
| 06:15 | <zewt> | i want to see stats on how many people have ever used that :) |
| 06:15 | <zewt> | (manual distinct selections with control-click) |
| 06:15 | <rniwa> | Hixie: hi Hixie, so now that undomanager & dom transaction stuff are getting some traction, I want to propose more crazy ideas LOL |
| 06:15 | <zewt> | probably in the vicinity of: 0 |
| 06:15 | <rniwa> | Hixie: namely I want to fix the way key binding works on the web |
| 06:15 | <zewt> | gooood luck |
| 06:16 | <Hixie> | rniwa: have browsers implemented the last set of improvements to key bindings yet? |
| 06:16 | <rniwa> | zewt: yeah, ehsan told me that there are some gecko users that really love that multi-rage stuff |
| 06:16 | <rniwa> | Hixie: which one? |
| 06:16 | <Hixie> | rniwa: <command>, the new accesskey="", accessKey, accessKeyLabel, etc |
| 06:16 | <rniwa> | Hixie: yes, that's exactly what i'm about to tell you |
| 06:17 | <rniwa> | Hixie: not sure if we had already talked about it on whatwg and elsewhere |
| 06:17 | <rniwa> | Hixie: but we'd like to be able to support ctrl, alt, cmd, and other modifiers |
| 06:17 | <rniwa> | Hixie: in accessKey |
| 06:17 | <zewt> | i'm surprised that opera *way* stepped back the number of keys it eats ... that was endless headaches trying to implement keyboard shortcuts |
| 06:17 | rniwa | is almost certain there is some bug about this |
| 06:17 | <Hixie> | rniwa: baby steps, we have to get the basics implemented first ;-) |
| 06:18 | <rniwa> | Hixie: yeah, but it's good to think about modifier keys first so that we don't get stuck with the basic ones |
| 06:18 | <Hixie> | rniwa: it's already planned |
| 06:18 | <rniwa> | Hixie: great. |
| 06:18 | <rniwa> | Hixie: anyway, on top of that, I want to die command element to editing commands |
| 06:18 | <rniwa> | Hixie: and provide a way to define an editing command easily using command elements |
| 06:19 | <rniwa> | Hixie: so that authors can add new editing command like this: <command name="InsertDate" onapply="insertAtSelection(formattedDate())" isautomatic="true" accessKey="accel+d"> |
| 06:19 | <Hixie> | rniwa: (namely, http://www.w3.org/Bugs/Public/show_bug.cgi?id=13958 is for modifiers, and http://www.w3.org/Bugs/Public/show_bug.cgi?id=13576 is for specific labeled keys) |
| 06:19 | <rniwa> | Hixie: right. this is more stuff on top of that |
| 06:20 | <Hixie> | rniwa: (i expect to support modifiers via something like accesskey="ctrl+a command+a" or something once we've established whether the multiple key thing works at all |
| 06:20 | <Hixie> | rniwa: (hence the way it's specced so far, with all the room for expansion) |
| 06:20 | <Hixie> | rniwa: i don't really understand your proposal for editing commands, but the general idea seems sound |
| 06:20 | <Hixie> | rniwa: i expect we'll add that once browsers actually support <menu>, <command>, etc |
| 06:20 | <rniwa> | Hixie: so basically it lets you register you execCommand |
| 06:21 | <Hixie> | yeah |
| 06:21 | <rniwa> | new* |
| 06:21 | <rniwa> | Hixie: but I don't quite get what menu does |
| 06:21 | <rniwa> | given that we don't have any ways to define a toolbar |
| 06:21 | <rniwa> | why do we just support menu? |
| 06:21 | <Hixie> | <menu type=toolbar> is how you define a toolbar |
| 06:22 | <Hixie> | and <menu type=context> defines a context menu |
| 06:22 | <rniwa> | hm... |
| 06:22 | <Hixie> | see the spec :-) |
| 06:22 | <rniwa> | I must have missed it when I skimmed through the spec |
| 06:25 | <rniwa> | Hixie: ok, I might look into implementing that for WebKit then |
| 06:26 | <Hixie> | that'd be great. i've got a ton of improvements in that area that are just waiting for solid implementations of the stuff there so far |
| 06:26 | <Hixie> | one big open question is styling of the toolbars; i think we should have some sort of pseudo-element or something, but i dunno exactly how that would work |
| 06:26 | <Hixie> | (not an issue for menus since those should just match the platform conventions) |
| 06:27 | <rniwa> | Hixie: what do we need pseudo-elements for? |
| 06:28 | <Hixie> | well e.g. for <menu type=toolbar> <a href="/">Home</a> <input type=button value=Save> <command type=checkbox label="Enable Spellcheck"> </menu> |
| 06:28 | <Hixie> | how do you style the three buttons to fit your site? |
| 06:28 | <Hixie> | the usual :link, <input> and <command> styles obviously don't apply |
| 06:28 | <rniwa> | Hixie: can't you just do menu > * {~~} ? |
| 06:29 | <Hixie> | rniwa: not really, the elements involved have such different ways of being represented |
| 06:29 | <Hixie> | rniwa: e.g. <a> has contents, but <input> has a value |
| 06:29 | <Hixie> | rniwa: usual CSS doesn't really work here |
| 06:30 | <Hixie> | rniwa: also, <menu type=toolbar> <hr> <button></button> <hr><hr> <button></button> FOO </menu> only has one separator and shouldn't say "FOO", CSS can't really represent that |
| 06:30 | <Hixie> | rniwa: so you really want to construct the menu, per the spec, and then style the constructed menu, not the DOM directly |
| 06:30 | <Hixie> | rniwa: hence, pseudo-elements |
| 06:30 | <Hixie> | rniwa: but it's not exactly clear how it'd work |
| 06:31 | <rniwa> | hm... |
| 06:32 | <rniwa> | Hixie: why don't we restrict things that can appear in menu more? |
| 06:32 | <Hixie> | rniwa: how do you mean? |
| 06:32 | <rniwa> | e.g. only commands and hr can appear inside menu |
| 06:32 | <Hixie> | rniwa: that would be lame |
| 06:32 | <Hixie> | rniwa: e.g. how would you do a command that follows a link? |
| 06:33 | <Hixie> | rniwa: also, the fallback story is terrible |
| 06:33 | <Hixie> | rniwa: we have HTML elements with the semantics we want, it seems to make sense to use them |
| 06:33 | <Hixie> | rniwa: in any case, it still wouldn't really solve our problem |
| 06:34 | <Hixie> | rniwa: even with just <command> and <hr>, you still have the separator-collapsing logic to handle, and <command> doesn't render as anything (it's display:none) so styling it isn't helpful |
| 06:34 | <rniwa> | Hixie: that's one thing I don't like about the current spec |
| 06:35 | <rniwa> | Hixie: why can't we just make command element take contents? |
| 06:35 | <rniwa> | Hixie: then you can wrap whatever you want inside command elements |
| 06:35 | <Hixie> | rniwa: three reasons |
| 06:35 | <rniwa> | Hixie: and whatever algorithm we use to generate toolbars and menus can just look at command elements |
| 06:36 | <Hixie> | rniwa: 1. on the long term that will make pages really verbose (<command></command>) which is bad for authoring |
| 06:36 | <Hixie> | rniwa: 2. it doesn't make the algorithms any simpler, really. |
| 06:36 | <Hixie> | rniwa: 3. it means authors would have to implement everything twice to get fallback (once in <command> and once the old way) |
| 06:36 | <Hixie> | more reasons: 4. it would mean having to define what happens to the fallback elements for purposes of form submission |
| 06:37 | <Hixie> | also, the idea long term is to have <command> be able to refer to other elements, e.g. <a href="/" id=home>Home</a> with somewhere else <command ref=home> |
| 06:37 | <Hixie> | so that you only have to disable things or update thinsg once (e.g. only have to update the a.href here once) even if the command is in many menus and toolbars and so on |
| 06:38 | <Hixie> | that's really the only reason <command> exists at all |
| 06:38 | <rniwa> | Hixie: if we're adding ref/for to command, it seems more natural to make it wrap the elements that it refers to. |
| 06:38 | <Hixie> | that and being able to define commands that _don't_ have legacy fallback (which is useful if, e.g., your context menu is completely redundant with some "real" buttons) |
| 06:39 | <Hixie> | no i mean being able to reference the command from multiple places |
| 06:39 | <rniwa> | Hixie: you can define a fallback-less command by omitting the contents, right? |
| 06:39 | <Hixie> | yeah but that's way too verbose |
| 06:39 | <rniwa> | hm... |
| 06:39 | <rniwa> | i disagree > way too verbose |
| 06:40 | <Hixie> | you don't think littering the DOM with </command> end tags is verbose? o_O |
| 06:40 | <rniwa> | no |
| 06:40 | <rniwa> | I think that's much better than having to add random ref/for attributes |
| 06:40 | <rniwa> | I hate having to add id's just so that I can refer from elsewhere |
| 06:40 | <Hixie> | i don't understand how they are related |
| 06:43 | <rniwa> | okay let's take the example in 4.11.4.1 Introduction |
| 06:43 | <rniwa> | http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html |
| 06:43 | <rniwa> | Hixie: what if I wanted to attach an icon to <button type="button" onclick="fnew()">New...</button> ? |
| 06:43 | <rniwa> | Hixie: how do I do that under the current spec? |
| 06:44 | <Hixie> | you can't, <button> doesn't have icons. |
| 06:44 | <rniwa> | Hixie: right but I want it to have an icon when it's shown in the menu |
| 06:44 | <rniwa> | Hixie: so I'd end up adding a command element anyway to work-around this limiation |
| 06:44 | <Hixie> | oh actually no |
| 06:45 | <Hixie> | the spec does define a way to give an icon |
| 06:45 | <Hixie> | you just put an <img> inside the <button> |
| 06:45 | <rniwa> | :( |
| 06:45 | <Hixie> | see http://www.whatwg.org/specs/web-apps/current-work/#using-the-a-element-to-define-a-command |
| 06:45 | <Hixie> | (the <button> section basically copies the <a> section) |
| 06:46 | <rniwa> | Hixie: ok, what if I wanted to disable <li><a href="help.html">Help</a></li> ? |
| 06:46 | <Hixie> | rniwa: how would you do that irrespective of menus? |
| 06:47 | <rniwa> | Hixie: well, if it were a menu item |
| 06:47 | <rniwa> | Hixie: then I can always disable it regardless of what it does at least on Windows |
| 06:47 | <rniwa> | to begin with, a link in a context menu shouldn't show up as a link |
| 06:47 | <rniwa> | it should look like any other menu item |
| 06:47 | <Hixie> | exactly |
| 06:47 | <Hixie> | which the spec requires |
| 06:47 | <rniwa> | but I should still be able to disable that |
| 06:47 | <Hixie> | (whence, for toolbars, the styling issue) |
| 06:48 | <Hixie> | why? |
| 06:48 | <Hixie> | what's the use case for disabling a link? |
| 06:48 | <rniwa> | because maybe help doesn't exist for some content |
| 06:48 | <rniwa> | and I don't want users to click that |
| 06:48 | <Hixie> | if there's a use case for disabling a link, we should fix that with <a>, it's not menu-specific |
| 06:48 | <rniwa> | I mean these are just examples |
| 06:49 | <rniwa> | but I feel like the current spec is way too complicated to be adopted |
| 06:49 | <Hixie> | (if help doesn't exist, the right UI is to remove the item from the menu altogether, which you would do by adding a hidden="" attribute) |
| 06:49 | <rniwa> | due to all the fallback consideration |
| 06:49 | <Hixie> | i don't understand what is complicated here |
| 06:49 | <Hixie> | it's really simple |
| 06:50 | <Hixie> | certain elements implement this "command" concept. menus just collect all their commands and render them. |
| 06:50 | <Hixie> | where's the problem? |
| 06:50 | <Hixie> | the fallback just falls out of the design |
| 06:50 | <Hixie> | and doesn't get in the way once it's no longer needed |
| 06:50 | <Hixie> | it's essentially free |
| 06:50 | <Hixie> | plus, in the future, we reuse all the infrastructure to get <command ref=""> essentially for free again |
| 06:50 | <rniwa> | as an author, I don't care about fallbacks |
| 06:51 | <rniwa> | I just want to be able to do everything using command element |
| 06:51 | <Hixie> | and you can, if you want to |
| 06:51 | <Hixie> | meanwhile, authors who _do_ care about fallback, can still do it |
| 06:51 | <rniwa> | hm... |
| 06:51 | <Hixie> | and authors who have links and buttons in parts of their app that do the same as commands in their menus, in the future, once we add <command ref>, get all the indirection magic for free |
| 06:51 | <Hixie> | so they don't have to disable every last menu item that does the same thing |
| 06:52 | <Hixie> | they just disable it once and boom, all the menus and toolbars update |
| 06:54 | <rniwa> | now I see some command-element-only example in the spec |
| 06:54 | <rniwa> | I guess this might work |
| 06:54 | <rniwa> | <command ref> thing definitely sounds useful |
| 06:55 | <rniwa> | alright, let me look into implementing this thing then |
| 06:55 | <Hixie> | cool |
| 06:56 | <rniwa> | then I'll know whether I like or hate the spec :) |
| 06:56 | <Hixie> | :-) |
| 06:57 | <rniwa> | Hixie: btw, I don't quite get what you're seeing in http://www.w3.org/Bugs/Public/show_bug.cgi?id=14337 |
| 06:57 | <rniwa> | Hixie: are you referring to DOM changes made by scripts or IE? |
| 07:19 | <Hixie> | both |
| 07:20 | <Hixie> | e.g. do changes from a setInterval() |
| 07:20 | <Hixie> | they get undone |
| 07:20 | <Hixie> | if you undo immediately after the drag |
| 07:20 | <Hixie> | i'm not sure we really want this behaviour; i specced it just cos i was speccing whatever IE did |
| 07:20 | <Hixie> | it's probably better to call it a bug |
| 08:07 | <annevk> | Glenn Adams... |
| 09:27 | <zcorpan> | Hixie: so i think it's still not right. :-) |
| 09:27 | <zcorpan> | Hixie: + readonly attribute <code><a href=#document>Document</a></code> <a href=#htmldocument title=HTMLDocument>HTMLDocument</a>; |
| 09:27 | <zcorpan> | Hixie: the Document interface object is not an instance of Document |
| 09:27 | <zcorpan> | Hixie: so the return type should be something else |
| 09:29 | <annevk> | what does interface Document {} expose then? |
| 09:36 | <zcorpan> | annevk: i don't understand the question |
| 09:37 | <annevk> | I get what you mean now, I think |
| 09:40 | <annevk> | I guess it needs to be defined in terms of http://dev.w3.org/2006/webapi/WebIDL/#dfn-relevant-namespace-object and below |
| 09:43 | <zcorpan> | "Interface objects are always function objects." - i guess s/Document/Function/ then |
| 09:51 | <danbri> | http://www.downforeveryone.com/www.whatwg.org/ |
| 09:52 | <danbri> | 'Hey, it's not just you! http://www.whatwg.org/ looks down from here. ' |
| 11:30 | <annevk> | why does WebVTT require decimal separators? |
| 11:32 | <annevk> | I mean milliseconds |
| 11:34 | <Lachy> | Huh? Why shouldn't it? Milliseconds give the required precision. |
| 11:39 | <annevk> | if they happen to zero |
| 11:40 | <annevk> | I guess it does not matter much |
| 12:07 | <annevk> | I don't really get these WebVTT settings |
| 12:09 | <annevk> | e.g. some line ending in "00:13.000 X A:start" has that A:start to discarded with the current parsing algorithm |
| 12:09 | <annevk> | seems wrong |
| 13:10 | <zcorpan> | annevk: why does it seem wrong? that's the same as css decl, basically |
| 13:13 | <annevk> | I'm more confused by e.g. D:vertical followed by two spaces |
| 13:13 | <annevk> | and that followed by A:start or some such |
| 13:14 | <annevk> | afaict "setting will be set to the second "space" |
| 13:14 | <annevk> | or maybe even the first |
| 13:14 | <annevk> | which seems highly undesirable |
| 13:15 | <annevk> | there's some skip.spaces step missing after you consumed a setting |
| 13:15 | zcorpan | hasn't looked at settings parsing yet |
| 13:17 | <zcorpan> | also D: vertical fails to parse |
| 13:18 | <annevk> | yeah it does in my validator |
| 13:18 | <annevk> | I guess I should upload something so people can teach me how to write code |
| 13:18 | zcorpan | isn't a fan of single-letter settings |
| 13:19 | <annevk> | guess I'll continue tomorrow |
| 13:20 | <annevk> | will upload something so people can leave comments |
| 13:22 | <annevk> | http://quuz.org/webvtt/ |
| 13:22 | <annevk> | http://quuz.org/webvtt/parser.js |
| 13:23 | <annevk> | zcorpan, ^^ |
| 13:25 | <zcorpan> | found a bug :-) |
| 13:25 | <zcorpan> | space after signature should be allowed |
| 13:25 | <divya> | zcorpan knows how to crush dreams |
| 13:26 | <zcorpan> | :S |
| 13:26 | <divya> | :)) |
| 13:26 | <annevk> | I wonder what's wrong with my SIGNATURE code |
| 13:28 | <zcorpan> | 00::51.000 and 00:0:51.000 validate |
| 13:28 | <annevk> | yeah I noticed that too |
| 13:31 | <annevk> | fixed that bug |
| 13:32 | <zcorpan> | the sig check seems bogus |
| 13:35 | <annevk> | needs to be && |
| 13:35 | <zcorpan> | you could do line.match(/^WEBVTT(( |\t).*)?/) or some such |
| 13:35 | <annevk> | also fixed |
| 13:36 | <annevk> | could also replace || with && |
| 13:36 | <annevk> | there's no requirements for anything after that tab or space |
| 13:37 | <annevk> | although I guess "WEBVTT TEST" should maybe not be valid even though it should be processed |
| 13:39 | <zcorpan> | it's valid |
| 13:40 | <hsivonen> | Opera Reader is very cool. however, I'd like to have "tap edge for page turn" in addition to swiping |
| 13:40 | <annevk> | zcorpan, not per the syntax section |
| 13:40 | <hsivonen> | swiping a lot isn't very ergonomic |
| 13:40 | <zcorpan> | annevk: yes it is :) |
| 13:41 | <annevk> | oh right |
| 13:41 | <annevk> | bah |
| 13:41 | <zcorpan> | hsivonen: send an email to h&kon :-) |
| 13:41 | <annevk> | don't really think it should be valid though |
| 13:41 | <annevk> | makes no sense |
| 13:41 | <zcorpan> | doesn't manifest do the same thing? |
| 13:41 | <hsivonen> | zcorpan: I'll see if there's a www-style thread I could send email to first |
| 13:42 | <annevk> | zcorpan, dunno, never wrote a validator for that one |
| 13:42 | <hsivonen> | Also, Opera Reader really needs some kind of easy-to-use way of forcing the paged mode on legacy sites |
| 13:44 | <zcorpan> | i suspect that forcing paged mode on legacy sites would often break in more horrible ways than fit-to-width |
| 14:10 | <hsivonen> | zcorpan: I guess sites that would break horrible wouldn't be very printer-friendly either |
| 14:10 | <hsivonen> | maybe the Web isn't printer-friendly in general |
| 14:34 | <Ms2ger> | annevk5, thanks for fixing XMLDocument in DOMPS |
| 14:40 | <annevk> | Ms2ger, hey no worries |
| 14:41 | <annevk> | Ms2ger, I was wondering though, should that really be XMLDocument? |
| 14:41 | <annevk> | Ms2ger, in that Document == XMLDocument bug people suggested only createDocument should return XMLDocument |
| 14:41 | <Ms2ger> | I dunno, I just defined what Gecko did |
| 14:41 | <Ms2ger> | It probably doesn't matter |
| 14:43 | <smaug____> | createDocument doesn't always return XMLDocument |
| 14:43 | <Ms2ger> | In Gecko |
| 14:43 | <smaug____> | yes, in Gecko |
| 14:43 | <smaug____> | and I think Acid3 even had some tests for that |
| 14:44 | <smaug____> | at least ACID3 is the reason why Gecko's createDocument behaves the way it does |
| 14:44 | <annevk> | I doubt Acid3 has the DocumentType nonsense |
| 14:44 | <smaug____> | IIRC it does had |
| 14:44 | <annevk> | Ms2ger, guess we'll sort it out later then |
| 14:45 | <Ms2ger> | It had a lot of nonsense, that much is clear |
| 14:45 | <annevk> | trololol |
| 14:47 | gsnedders | is wondering whether E4H is really a good idea at all |
| 14:47 | <gsnedders> | E4X is too far one way, E4H is too far the other |
| 14:47 | <annevk> | it's H4E man |
| 14:47 | <gsnedders> | w/e |
| 14:47 | <annevk> | for extra confusion |
| 14:48 | <gsnedders> | I care about the semantics of the proposal. |
| 14:48 | <annevk> | the proposal had virtually no details though |
| 17:36 | <Hixie> | zcorpan: Function is not a function object (possibly confusingly) |
| 17:37 | <Hixie> | zcorpan: Function is just a [Callback=FunctionOnly, NoInterfaceObject] callback interface with one member that takes any any arguments and returns any |
| 17:39 | <linclark> | does anyone know what the current thinking on the time element is? |
| 17:39 | <linclark> | I'm looking at this bug: http://www.w3.org/Bugs/Public/show_bug.cgi?id=13240 |
| 17:41 | <hsivonen> | linclark: I expect different people to have different current thinking |
| 17:43 | <linclark> | hsivonen: right, but are there any discussions that are more current |
| 17:43 | <linclark> | I'm asking because we're working on implementing a theme_time function in Drupal |
| 18:01 | <franksalim> | Hixie: that is...quotable...and it reminds me of the "a monad is just a monoid in the category of endofunctors, what's the problem?" joke about Haskell...probably because you said "is just a" and then gave a precise and complicated definition. :) |
| 18:02 | <dglazkov> | good morning, Whatwg! |
| 18:02 | <hsivonen> | linclark: I'm not aware of more current discussions, but my mailing list reading isn't up to date |
| 18:02 | <hsivonen> | dglazkov: good evening |
| 18:04 | <linclark> | hsivonen: ok, thanks... as long as it ends up being one of the proposed alternatives, it shouldn't take long for us to update |
| 18:07 | <jarek> | Hello |
| 18:07 | <jarek> | why MEDIA_SYM CSS token is defined like this: |
| 18:07 | <jarek> | @{M}{E}{D}{I}{A} |
| 18:08 | <jarek> | while CHARSET_SYM token is defined this way: |
| 18:08 | <jarek> | "@charset " |
| 18:08 | <jarek> | does it mean that "@cha\rset 'utf-8'" is not a valid charset declaration? |
| 18:09 | <jarek> | while something like "@med\ia" would be valid? |
| 18:11 | <jarek> | yup, W3C validator fails on @cha\rset "UTF-8"; |
| 18:16 | <jarek> | this seems to be rather inconsistent, what is the reason behind not allowing the escapes inside "@charset" or "url("? " or "~="? |
| 18:21 | <jarek> | validator marks @med\ia as error as well, I don't get it |
| 18:21 | <zewt> | "In fact, it's possible to implement ES functionality with better performance then the native implementations." |
| 18:21 | <zewt> | do people realize how silly they sound when they make claims like that |
| 18:22 | <jarek> | ahh... it accepts only hex escapes |
| 18:22 | <zewt> | there's no such thing as faster than native, sorry, next |
| 18:30 | <Hixie> | franksalim: heh |
| 18:31 | <Hixie> | jarek: @charset is special |
| 18:31 | <Hixie> | jarek: because we don't want people to have to run a complicated css parser just to get the character encoding which they need to know in order to create a css parser :-) |
| 18:31 | <Hixie> | bbiab |
| 22:20 | <rniwa> | Hixie: yt? |
| 22:20 | <rniwa> | or anyone else familiar with microdata? |
| 22:29 | <Hixie> | rniwa: here |
| 22:30 | <rniwa> | Hixie: I was a bit confused about DOMSettableTokenList |
| 22:30 | <rniwa> | Hixie: I just filed a bug saying that section 2.8.1 (http://www.whatwg.org/specs/web-apps/current-work/multipage/common-dom-interfaces.html#reflect) |
| 22:30 | <rniwa> | Hixie: should probably define IDL attributes in terms of content attribute |
| 22:30 | <rniwa> | instead of defining in terms of types of IDL attributes |
| 22:31 | <Hixie> | why? |
| 22:31 | <Hixie> | and what does that have to do with DOMSettableTokenList :-) |
| 22:32 | <rniwa> | Hixie: e.g. if an idl attribute is reflecting a content attribute of the type "unordered set of unique space-separated tokens" then its type will be http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#domsettabletokenlistt or something like |
| 22:32 | <rniwa> | Hixie: because I usually look for the type of content type. |
| 22:33 | <rniwa> | Hixie: when an IDL attribute reflects a content attribute |
| 22:33 | <rniwa> | I usually know the type of content attribute |
| 22:33 | <rniwa> | but not necessarily of the type of idl attribute |
| 22:33 | <rniwa> | anyway, it's not that important though |
| 22:33 | <Hixie> | content attributes don't have a type |
| 22:33 | <Hixie> | well, i mean, they're all strings |
| 22:34 | <Hixie> | or am i misunderstanding...? |
| 22:35 | <rniwa> | Hixie: well but they do have different kinds like space separted tokens, etc... |
| 22:35 | <rniwa> | separated* |
| 22:35 | <Hixie> | oh you mean the conformance requirements for what's allowed in them? |
| 22:35 | <Hixie> | i guess |
| 22:35 | <Hixie> | not sure how you'd use those to define UA requirements |
| 22:35 | <rniwa> | Hixie: sort of |
| 22:36 | <rniwa> | I want a way to lookup the type of idl attribute given a description of content attribute |
| 22:36 | <Hixie> | there's not a 1:1 mapping |
| 22:36 | <rniwa> | hm... |
| 22:36 | <rniwa> | that explains it but also sucks :( |
| 22:38 | <Hixie> | welcome to the web |
| 22:39 | <Hixie> | what are you looking up that makes it easier for you to look things up based on the content attribute than the idl type? |
| 22:39 | <rniwa> | Hixie: i was looking at microdata API |
| 22:39 | <rniwa> | Hixie: and in particular itemProp idl attribute |
| 22:42 | <jgraham> | zewt: I assume they meant "faster than C++", which could be true |
| 22:42 | <jgraham> | Depending on where the bottlenecks are |
| 22:45 | <rniwa> | jgraham: talking about some JS engine performance? |
| 22:45 | <Hixie> | rniwa: i don't understand why that was easier to do using the content attribute than the idl type |
| 22:45 | <Hixie> | abarth: yt? |
| 22:45 | <abarth> | hi |
| 22:45 | <rniwa> | Hixie: yeah, I guess my comment was useless given the definitions aren't bijective |
| 22:45 | <Hixie> | abarth: the origin spec doesn't have special dispensation for cases where urls with a domain part that are supported by the UA might have per-url origin |
| 22:45 | <rniwa> | Hixie: thought they were bijective |
| 22:45 | <Hixie> | abarth: e.g. an NNTP post |
| 22:45 | <Hixie> | rniwa: k |
| 22:46 | <rniwa> | Hixie: sorry about the noise |
| 22:46 | <Hixie> | rniwa: (one example is that class="" and itemprop="" (className and itemProp) have roughly the same definition, but reflect very differently) |
| 22:46 | <abarth> | Hixie: i see |
| 22:46 | <Hixie> | rniwa: (and indeed className and classList both reflect class="") |
| 22:46 | <Hixie> | rniwa: (in different ways) |
| 22:46 | <rniwa> | :( |
| 22:47 | <Hixie> | abarth: third bullet point of http://www.whatwg.org/specs/web-apps/current-work/#origin |
| 22:47 | rniwa | is annoyed by the complexity |
| 22:47 | <Hixie> | abarth: er, third <li> i should say |
| 22:47 | <Hixie> | rniwa: dude if you think that's bad, wait til you hear about HTMLFormElement's named property access |
| 22:47 | <Hixie> | rniwa: (see my public g+ post) |
| 22:48 | <rniwa> | Hixie: yes, I know the badness in that area |
| 22:48 | <rniwa> | Hixie: I've worked on fixing selectionStart/selectionEnd in input/textarea :( |
| 22:48 | <abarth> | Hixie: i guess it boils down to the notion of "support" |
| 22:48 | <rniwa> | they are the worst properties :( |
| 22:48 | <abarth> | <t>If the implementation doesn't support the protocol given by |
| 22:48 | <abarth> | uri-scheme, then return generate a fresh globally unique identifier |
| 22:48 | <abarth> | and return that value.</t> |
| 22:48 | <Hixie> | abarth: it has to not be a fresh one, it has to be teh same one each time |
| 22:48 | <rniwa> | although input.type is pretty bad-ass too |
| 22:49 | <Hixie> | abarth: so e.g. different documents that are in one multipart/something e-mail all get the same origin, but not the same origin as other e-mails on that same IMAP server |
| 22:49 | <Hixie> | rniwa: i mean specifically the named property access stuff on <form> |
| 22:49 | <rniwa> | Hixie: oh, I haven't looked at that one in particular |
| 22:50 | <abarth> | ok |
| 22:50 | <Hixie> | rniwa: it makes the reflection stuff look positively mundane |
| 22:50 | <jgraham> | rniwa: Yeah |
| 22:50 | <abarth> | that's just a question of when you run the algorithm |
| 22:50 | <Hixie> | abarth: how so? |
| 22:50 | <abarth> | you just need to run it once for the whole multi-part package |
| 22:50 | <abarth> | rather than once for each part of the package |
| 22:51 | <Hixie> | abarth: each part has a differnet url |
| 22:51 | <Hixie> | abarth: so clearly it has to be run for each part |
| 22:51 | <abarth> | won't they be different origins if you're treating the whole URL as the origin? |
| 22:51 | <abarth> | maybe i misunderstood |
| 22:52 | <Hixie> | say you have a scheme foo://example.org/document1/part1 |
| 22:52 | <Hixie> | and everything in foo://example.org/document1/* has to have the same unique origin |
| 22:52 | <abarth> | but if you use all of foo://example.org/document1/part1 as the origin, that won't be the case |
| 22:53 | <Hixie> | right |
| 22:53 | <abarth> | so, you want the ability to do something implementation-defined on a per-scheme basis? |
| 22:53 | <abarth> | e.g., be able to return whatever you want as the origin? |
| 22:54 | <Hixie> | well you have me rapidly wanting to not care about news readers and e-mail clients at this point, but previously, i just wanted something equivalent to the third <li> in the HTML spec |
| 22:54 | <rniwa> | jgraham: yeah, I think dynamic optimization can beat optimizing compilers in many cases |
| 22:54 | <Hixie> | "If url identifies a resource that is its own trust domain (e.g. it identifies an e-mail on an IMAP server or a post on an NNTP server) then return a globally unique identifier specific to the resource identified by url, so that if this algorithm is invoked again for URLs that identify the same resource, the same identifier will be returned." |
| 22:54 | <abarth> | IMHO, we shouldn't worry about these cases |
| 22:55 | <Hixie> | ok |
| 22:55 | <abarth> | i think there's code in Gecko that does something like that |
| 22:55 | <abarth> | but I don't think other UAs have anything like that |
| 22:55 | <Hixie> | well yeah, other UAs don't have newsreaders or e-mail clients |
| 22:56 | <jgraham> | (cough) |
| 22:57 | <Hixie> | jgraham: how do you handle origins in your newsreaders or e-mail clients? |
| 22:58 | <jgraham> | No idea :) |
| 22:58 | <jgraham> | But I could probably ask if you are interested |
| 23:05 | <Hixie> | jgraham: well, i'm stripping the text that made them work like in Firefox from HTML and deferring to [ORIGIN]. |
| 23:05 | <Hixie> | jgraham: so if that affects you, let abarth know :-) |
| 23:47 | <rniwa> | AryehGregor: yt? |