| 05:21 | <MikeSmith> | Hixie: which API was that? (for creating new custom <input type=> values) |
| 05:32 | <Hixie> | MikeSmith: which, the web controls one or the web components one? |
| 05:33 | <MikeSmith> | Hixie: I mean the web controls one |
| 05:33 | <Hixie> | http://www.whatwg.org/specs/web-controls/current-work/ |
| 05:34 | <Hixie> | (defunct now, aria basically made it moot. unfortunately, aria solved the problem in a far less compelling way.) |
| 05:34 | MikeSmith | looks |
| 05:34 | <MikeSmith> | wow |
| 05:35 | <MikeSmith> | dunno if I ever saw this spec before |
| 05:35 | <MikeSmith> | if I did I forgot |
| 05:36 | <Hixie> | it would have solved the custom controls problem and the accessibility problem in one fell swoop while simultaneously preventing the conflicting state problem that ARIA brought us |
| 05:36 | <Hixie> | you can tell how old that spec is, it still uses respec-style formatting for interface members :-) |
| 05:36 | <MikeSmith> | heh |
| 05:37 | <Hixie> | bed time, bb in a few hours :-) |
| 05:38 | <MikeSmith> | nn |
| 07:21 | <dekiss> | Good morning GGO BUILD THE WEEEEEEEEEEEEB!!! |
| 09:28 | <ondras> | Domenic_: ? |
| 09:36 | <ondras> | well, probably anyone else can answer |
| 09:36 | <ondras> | is "catch" a wise name for a promise's method? is "catch" generally a suitable JS function name, being a reserved word? |
| 12:28 | <MikeSmith> | can anybody figure out what https://www.w3.org/Bugs/Public/show_bug.cgi?id=24111 is asking for? |
| 12:34 | <jgraham> | MikeSmith: Yeah. They want li {color:green} type rules to also turn the marker green |
| 12:34 | <MikeSmith> | ah |
| 12:34 | <ondras> | which somewhat makes sense if you ask me |
| 12:34 | <ondras> | a pseudoclass would be also reasonable |
| 12:34 | <MikeSmith> | that's what he means by "inherit" |
| 12:35 | <MikeSmith> | I guess |
| 12:35 | <ondras> | yeah |
| 12:36 | <jgraham> | It might make sense, but presumably it isn't backward compatible |
| 12:36 | <MikeSmith> | oh, "CKEditor Project Lead" |
| 12:36 | <MikeSmith> | anyway it's a CSS issue issn't it? |
| 12:36 | <ondras> | that's why he mentioned a special property for turning this feature on |
| 12:36 | <jgraham> | Yes |
| 12:40 | <MikeSmith> | doesn't CKEditor has some problems? like doing some kind of stupid stuff and they refuse to fix it? |
| 12:41 | <ondras> | even if they did, is that relevant for considering a feature request? :) |
| 12:43 | <MikeSmith> | well I'm not considering it anyway |
| 12:55 | <Ms2ger> | Wasn't it CKEditor that used element.all? |
| 12:56 | <gsnedders> | Ms2ger: Amongst other things |
| 12:56 | <gsnedders> | CKEditor does lots of evil stuff, from memory |
| 12:57 | jgraham | cries |
| 12:58 | <jgraham> | I hate the web |
| 12:58 | <jgraham> | Well specifically |
| 12:58 | <jgraham> | I hate that thing where you develop something that works fine in one browser |
| 12:58 | <jgraham> | and fails in all others |
| 12:58 | <jgraham> | Without so much as an error on the console |
| 13:03 | <Ms2ger> | Sounds like the web alright |
| 13:05 | <gsnedders> | WEB 3.0! |
| 13:05 | <jgraham> | Oh |
| 13:05 | <jgraham> | It was all my fault |
| 13:05 | <jgraham> | Come back web, all is forgiven |
| 13:20 | <zcorpan> | jgraham: that doesn't appear to be what they want. li {color:green} already makes the marker green. They want <li><font color=green>foo</font> to make the marker green |
| 13:20 | <odinho> | lol |
| 13:20 | <odinho> | crazy |
| 13:22 | <jgraham> | zcorpan: Oh |
| 13:25 | <annevk> | ondras: catch is no longer reserved |
| 13:34 | <jgraham> | http://hoppipolla.co.uk/410/workers.html |
| 13:34 | <jgraham> | based on an adaptation of Ms2ger's test runner and a script to create reports from JSON |
| 13:34 | <jgraham> | Not finished yet obviously, but better than editing a wiki page I think |
| 13:35 | <MikeSmith> | hell yeah |
| 13:35 | <MikeSmith> | this is great |
| 13:36 | <Ms2ger> | Mine had neat colours ;) |
| 13:37 | <jgraham> | Ms2ger: Funny, I wa just going to say that someone should do the visual design |
| 13:37 | <jgraham> | Because it turns out that a) I suck at it and b) I get to trying to do it and want to scoop my own eyes out |
| 13:37 | <jgraham> | https://github.com/w3c/web-platform-tests/commit/4f68f6e66ab2ec1b62a2d8c035e845f35707346d is the code (jgraham/runner branch in web-platform-tests) |
| 13:38 | <Ms2ger> | The one thing that would be nice is having lines between the tests |
| 13:38 | <Ms2ger> | s/tests/test files/ |
| 13:38 | <MikeSmith> | I think it's fine as-is |
| 13:38 | <jgraham> | Yeah, sure there are simple things I could do that would make it not obviously terrible |
| 13:38 | <MikeSmith> | reading test results should be hard and challenging |
| 13:38 | <jgraham> | Heh |
| 13:39 | jgraham | will go into the office now |
| 13:40 | <Ms2ger> | Isn't it, like, afternoon there? |
| 13:40 | <annevk> | he missed mozlunch |
| 13:41 | <annevk> | not many people around |
| 13:41 | <Ms2ger> | <meta charset="utf8"></meta> |
| 13:41 | <annevk> | so close |
| 13:44 | <annevk> | Ah, I already analyzed gbk vs gb18030 before! |
| 13:44 | <annevk> | hsivonen: http://lists.w3.org/Archives/Public/www-archive/2012Apr/0030.html |
| 13:44 | <ondras> | annevk: ah, I guess I need to update my version of google chrome compiler then... |
| 13:44 | <annevk> | It seems I just draw conclusions that were wrong for gb18030 UTFness. |
| 13:46 | <annevk> | In fact, if I use Firefox' gb18030 table I think that will make gb18030 a UTF and we can still use it for gbk (and just make gbk an alias for gb18030) |
| 13:50 | <gsnedders> | Isn't taht what some browser already does? |
| 13:54 | <annevk> | Presto had something close to that |
| 13:54 | <annevk> | But still had a flag, as seen in the Encoding Standard |
| 13:54 | <annevk> | However, in Presto gb18030 was not a UTF |
| 13:55 | <gsnedders> | What stops it from being a UTF in Presto/Chrome? |
| 13:56 | <annevk> | In Chrome gb18030 is a UTF. |
| 13:56 | <annevk> | In Presto a bunch of two-byte sequences does not map to PUA |
| 13:59 | <darobin> | given how often people will have to do template.content.cloneNode(true), with the likelihood of getting it wrong, I wonder if we shouldn't have a template.instance() method that just sugars that |
| 14:01 | <Ms2ger> | jgraham, want to send me the results for workers so I can test changes? |
| 14:06 | <reggna> | So, how do I remove a TextTrack from a TextTrackList? |
| 14:08 | <annevk> | reggna: looks like you don't |
| 14:08 | <reggna> | Yea, I can't find anything either. |
| 14:09 | <reggna> | There's an event though. |
| 14:09 | <annevk> | reggna: well if you remove e.g. the corresponding <track> element |
| 14:09 | <annevk> | reggna: but if they're all internal to the resource I don't think you can manipulate them |
| 14:19 | <reggna> | I'm a bit saddened over this. |
| 14:19 | <reggna> | But thanks for the quick answer, annevk. : ) |
| 14:19 | <annevk> | reggna: if you have a use case, file a bug |
| 14:19 | <annevk> | reggna: best way to get a new feature |
| 14:20 | <reggna> | Yea, my use case is "this would be very convenient for my test case". : P |
| 14:21 | <reggna> | So not that valid, unfortunately. |
| 14:30 | <annevk> | hah |
| 14:48 | <jgraham> | Ms2ger: Specially ofr you I have amde it really ugly so that someone is forced to improve the style |
| 14:49 | <jgraham> | Ms2ger: Do you want the json files? |
| 14:49 | <Ms2ger> | jgraham, whatever the input to report.py is |
| 14:52 | <jgraham> | Ms2ger: http://hoppipolla.co.uk/410/workers/ |
| 14:53 | <Ms2ger> | Thanks |
| 15:07 | <Ms2ger> | Uh: https://github.com/w3c/web-platform-tests/blob/76e0d1ba75c95f95cb6e24c42f84c15ca18c39ef/workers/WorkerGlobalScope_removeEventListener.htm#L45 |
| 15:09 | <annevk> | IE10 doesn't support overrideMimeType?! |
| 15:09 | <annevk> | Bah |
| 15:11 | <Ms2ger> | jgraham, r? https://pastebin.mozilla.org/3789796 |
| 15:15 | <jgraham> | Ms2ger: Fancy merging that with the change I just pushed? |
| 15:15 | <jgraham> | (We have some of the same bugfixes at least) |
| 15:16 | <Ms2ger> | cellspacing=0? |
| 15:16 | <jgraham> | :p |
| 15:16 | <jgraham> | I was on a train and couldn't remember the right kind of CSS |
| 15:18 | <Ms2ger> | Did you also forget to add report.css? |
| 15:19 | <jgraham> | Probably :) |
| 15:20 | <jgraham> | Added |
| 15:20 | <Ms2ger> | Ta |
| 15:27 | <Ms2ger> | jgraham, how about now? https://pastebin.mozilla.org/3789871 |
| 15:31 | <jgraham> | Ms2ger: Would be nice to add the style to the stylesheet. |
| 15:31 | <jgraham> | Not sure about the use of multiple <tbody>, but I guess it works |
| 15:32 | <jgraham> | Something has crashed so I can't scroll and see the rest of the patch. Or switch applications |
| 15:32 | <Ms2ger> | What do you mean about adding style to the stylesheet? |
| 15:33 | <jgraham> | Oh, I misread |
| 15:33 | <jgraham> | And I can scroll by mouse |
| 15:34 | <jgraham> | s/mpouse/keyboard/ |
| 15:34 | <jgraham> | Sure, that looks fine |
| 15:34 | <jgraham> | please push |
| 15:36 | Ms2ger | pushes |
| 15:39 | <Ms2ger> | Oh, tobie's fellowship is ending? |
| 15:39 | <jgraham> | Yup |
| 15:39 | <jgraham> | Although I don't know what the cpntext is |
| 15:43 | <tobie> | Ms2ger: yup, in two weeks. |
| 15:45 | <gsnedders> | tobie: And I presume nobody will properly take over what you were doing? :( |
| 15:48 | <tobie> | gsnedders: well, unfortunately, no W3C member(s) stepped up to continue funding this effort further so far, so answer is "no" for the time being. :( |
| 15:50 | <Ms2ger> | Someone talk to dbaron? :) |
| 15:56 | <annevk> | The W3C should reshuffle its Staff a bit |
| 15:56 | <annevk> | plenty of people there... |
| 16:03 | <jgraham> | Dammit |
| 16:03 | <jgraham> | Now I want to post the example implementation report thing to webapps and public-test-infra |
| 17:10 | <MikeSmith> | this window.find() opening up a "find in page" control, I seem to remember reading about it in bugzilla or a mailing list recently but I can't remember where |
| 17:39 | <jgraham> | MikeSmith: webapps, I think? |
| 17:45 | <MikeSmith> | jgraham: ok |
| 17:48 | <MikeSmith> | this whole standards-discussion stuff is so time consuming |
| 17:49 | <MikeSmith> | I think we should all skip it and just unilaterally mint stuff in the browser engines that we all ship for iOS |
| 17:51 | <annevk> | zewt: but what if there's an IO error |
| 17:51 | <annevk> | zewt: if you're saying it should just stop reading at that point, I think we're in agreement |
| 17:52 | <annevk> | zewt: which is why I said we need an underlying model |
| 17:52 | MikeSmith | re-finds the "browser search api" thread |
| 17:53 | <zewt> | annevk: not sure what you mean |
| 17:53 | <zewt> | if there's a *real* IO error (user ejects the DVD holding the file the blob points to), yeah, there's an error |
| 17:53 | <annevk> | zewt: uhuh |
| 17:53 | <zewt> | but I don't think calling close() should cause any new IO errors to be called on fetches already in progress |
| 17:53 | <annevk> | zewt: that's what we were talking about |
| 17:54 | <annevk> | zewt: we were talking beyond close() |
| 17:54 | <zewt> | no, we're talking about close() |
| 17:54 | <annevk> | no |
| 17:54 | <jgraham> | maybe? |
| 17:55 | <zewt> | uh, the whole subthread is about "you can close() a Blob ... shouldn't affect the running operation" |
| 17:55 | <annevk> | yeah, but sicking specifically asked about IO errors to see if we can apply that to what should happen for close() |
| 17:55 | <annevk> | I said I had no idea what happened for IO errors (crash) |
| 17:56 | <zewt> | well I'm saying that close() shouldn't cause IO errors for stuff already in progress before you called close |
| 17:57 | <annevk> | -_- |
| 17:57 | <zewt> | ... |
| 17:57 | <annevk> | I mean that much was already established early on |
| 17:57 | <annevk> | That's not really the interesting bit |
| 17:58 | <annevk> | Anyway, euc-kr |
| 17:58 | <zewt> | the only thing that was established early on is "this is underspecified" |
| 17:58 | <zewt> | (and also anyway, time to get back to my actual work...) |
| 18:24 | <Domenic_> | So <dialog> is still show()/close()? |
| 18:25 | <annevk> | Domenic_: yes |
| 18:26 | <Domenic_> | despite the web dev feedback that that was crazy-sauce? |
| 18:30 | <annevk> | Domenic_: feedback where? I remember you discussed it here with Hixie and he ended up reaching the conclusion that there was no good alternative |
| 18:30 | <Domenic_> | annevk: http://updates.html5rocks.com/2013/09/dialog-element-Modals-made-easy#disqus_thread |
| 18:31 | <jgraham> | Domenic_: There is an open bug on the issue |
| 18:32 | <jgraham> | Why would you assume it will be ignored? |
| 18:32 | <annevk> | Domenic_: see end of http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Sep/0230.html |
| 18:32 | <Domenic_> | jgraham: I guess because Chrome keeps on chugging away at implementation. |
| 18:32 | <annevk> | jgraham: well it's filed against W3C HTML |
| 18:32 | <annevk> | jgraham: the one filed against WHATWG HTML is marked WFM |
| 18:32 | <annevk> | with a reference to that email I just mentioned |
| 18:32 | <jgraham> | annevk: Fair point. Sucks to have them fork the spec |
| 18:33 | <Domenic_> | jgraham: also because of the thread annevk just linked to |
| 18:34 | <jgraham> | Domenic_: That is a reasonable answer |
| 18:34 | <annevk> | Domenic_: that does not mean ignored though |
| 18:34 | <jgraham> | Anyway I think Hixie is wrong and it should be show/hide |
| 18:35 | <jgraham> | But this is way down the list of problems on the platform |
| 18:35 | <jgraham> | (well actually I think it should be open/close, but it seemed like there might be a more reasonable reason to avoid "open") |
| 18:36 | <annevk> | open="" and open() don't go together |
| 18:42 | <annevk> | Domenic_: as in, it seems to have been considered and no real viable alternative was proposed that was obviously better |
| 19:03 | <Hixie> | i definitely considered the open/close/show/hide thing. did a ton of research for it to figure out what to change it to. was surprised by the result, which was that the spec already matched most platforms. |
| 21:02 | <rdebeasi> | From the perspective of an author, many existing JS frameworks implement show/hide rather than show/close for similar behavior. |
| 21:45 | <Hixie> | rdebeasi: i actually looked for data to support that, but couldn't find any that isn't listed in that e-mail. if you do have data i missed, please do reply to that e-mail giving the new data :-) |
| 21:45 | <Hixie> | (though it might be too late by now) |
| 21:48 | <rdebeasi> | Sure, will do! It certainly couldn't hurt. |
| 21:59 | <annevk> | https://twitter.com/WTFMarketing/status/412616169850281984 :-) |
| 22:44 | <zcorpan> | now i have 100 tests on \u00E5 in the query of a url |
| 22:45 | <zcorpan> | someone: pls review |
| 22:50 | <zcorpan> | hmm, in 5 different encodings, so i guess 500 tests |
| 22:55 | <annevk> | zcorpan: should this really be in the HTML directory? |
| 22:55 | <zcorpan> | annevk: http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#resolving-urls is in the html spec |
| 22:56 | <zcorpan> | annevk: i guess the css tests don't belong, but oh well |
| 22:57 | <annevk> | not a big fan of how Hixie deals with URLs |
| 22:57 | <annevk> | hmm |
| 22:58 | annevk | files https://www.w3.org/Bugs/Public/show_bug.cgi?id=24119 |
| 22:59 | Hixie | isn't a big fan of it either |
| 23:02 | <annevk> | Sorry, no concrete suggestions yet |
| 23:02 | <Hixie> | did the parse error thing change? |
| 23:02 | <annevk> | Maybe in half a decade or so |
| 23:02 | <Hixie> | i seem to recall asking you about it when i wrote it |
| 23:02 | <annevk> | No, that's always been this way |
| 23:03 | <Hixie> | huh |
| 23:03 | <Hixie> | k |
| 23:03 | <Hixie> | btw you should say in the paragraph that dfns "URL parser" that it could return failure |
| 23:04 | <zcorpan> | annevk: btw some things don't use utf-8 that maybe could, like workers, EventSource |
| 23:04 | <zcorpan> | i also noticed that blink doesn't do XMLDocument#load |
| 23:05 | <annevk> | you mean new Worker? |
| 23:05 | <zcorpan> | right |
| 23:05 | <annevk> | workers themselves should already be utf-8-only |
| 23:05 | <Hixie> | (fixed, btw) |
| 23:05 | <annevk> | ta |
| 23:05 | <Hixie> | annevk: any idea on https://www.w3.org/Bugs/Public/show_bug.cgi?id=23892 ? |
| 23:05 | <annevk> | Hixie: I would not expect me to convince TC39 anytime soon |
| 23:06 | <annevk> | Hixie: the way they operate would make it largely my task to get the work done since nobody else is really keen on doing it |
| 23:06 | <annevk> | Hixie: and given other issues I can't say it's much of a priority |
| 23:06 | <zcorpan> | annevk: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23822 https://www.w3.org/Bugs/Public/show_bug.cgi?id=23823 |
| 23:07 | <annevk> | Whereas I think getting Map/Set support there would be good |
| 23:08 | <annevk> | zcorpan: the output of http://damowmow.com/playground/tests/urls/001.html is weird |
| 23:08 | <annevk> | zcorpan: in Gecko anyway |
| 23:08 | <annevk> | zcorpan: seems buggy for ws: |
| 23:08 | <Hixie> | annevk: should i just define it in HTML then? |
| 23:08 | <annevk> | Hixie: I guess for now :/ |
| 23:09 | <Hixie> | k |
| 23:09 | <Hixie> | any idea what it should say? |
| 23:09 | <zcorpan> | annevk: ws.url in gecko just returns what was passed to teh constructor |
| 23:09 | <annevk> | ouch |
| 23:10 | <annevk> | Hixie: I think you create a new Map and then copy [[MapData]] or some such |
| 23:10 | <annevk> | Hixie: prolly similar for Set |
| 23:10 | <Hixie> | k |
| 23:10 | <annevk> | Hixie: [[SetData]] |
| 23:10 | <zcorpan> | annevk: the smile isn't encode-able in the document's encoding so gecko uses utf-8 while blink uses the <form> way and i guess IE would replace it with a ? and the spec requires %3F |
| 23:11 | <zcorpan> | iirc |
| 23:11 | <hober> | Hixie annevk: note https://bugs.webkit.org/show_bug.cgi?id=120654 |
| 23:12 | <annevk> | omg no prefix used by olliej |
| 23:12 | <annevk> | (see #jslang for context) |
| 23:12 | <annevk> | (see also es-discuss for context) |
| 23:13 | <annevk> | zcorpan: hmm |
| 23:13 | <Hixie> | hober: thanks |
| 23:16 | <annevk> | zcorpan: yeah, need to look at that shit again at some point and see if we can always use the <form> way rather than the <form> way and ? |
| 23:16 | <annevk> | zcorpan: I reopened the bugs on the grounds that encoding override is for certain legacy APIs only, not even XMLHttpRequest uses it |
| 23:17 | <zcorpan> | annevk: ok |
| 23:17 | <Hixie> | boo, giving me more work |
| 23:18 | <Hixie> | doesn't this all mean that if you take a <Script src=""> and stick it into new Worker() you'll get a different URL? |
| 23:18 | <Hixie> | that seems bad |
| 23:20 | <annevk> | not using utf-8 is bad |
| 23:20 | <Hixie> | zcorpan: i fixed https://www.w3.org/Bugs/Public/show_bug.cgi?id=24088 (script error in worker); let me know if it's not compatible enough |
| 23:20 | <zcorpan> | you usually can't take an existing .js file and stick it into new Worker anyway |
| 23:20 | <annevk> | especially not if it's not utf-8 |
| 23:20 | <Hixie> | (not that i can really see how someone would be depending on a worker failing to run in a particular way, but you never know) |
| 23:21 | <annevk> | I think the problem is that currently you need to override to use utf-8 with your setup |
| 23:21 | <annevk> | whereas that could have been the default |
| 23:21 | <annevk> | and therefore less work |
| 23:22 | <zcorpan> | Hixie: LGTM, thanks |
| 23:24 | <Hixie> | dglazkov: ping https://www.w3.org/Bugs/Public/show_bug.cgi?id=24106 |
| 23:25 | <Hixie> | annevk: so i don't really understand why we'd want one place to not do this when literally dozens of other places in HTML do do it |
| 23:26 | <Hixie> | annevk: i understand that we don't like it, but being inconsistent seems far worse than having this sketchy behaviour |
| 23:26 | <annevk> | we are already inconsistent |
| 23:26 | <annevk> | and every new API should not do it |
| 23:26 | <Hixie> | why? |
| 23:27 | <annevk> | meaning there's a few exceptions in the end, such as <a> and location |
| 23:27 | <Hixie> | it's not a "few exceptions" |
| 23:27 | <Hixie> | there's literally dozens of them |
| 23:27 | <Hixie> | just in HTML |
| 23:27 | <annevk> | there's nothing outside of HTML that needs this; note that this is only about the query parameter |
| 23:27 | <annevk> | and only if you're not using utf-8 or utf-16 |
| 23:28 | <annevk> | as I explained in an email somewhere it's already a very large footgun to not use utf-8 |
| 23:29 | <annevk> | on top of all that the query parameter handling is a bug and inconsistent with how URLs are used elsewhere, and given that we're already inconsistent I don't see a reason to propagate it further |
| 23:30 | <annevk> | if all our APIs did this, mkay, but XMLHttpRequest does not, CSS does not, SVG does not |
| 23:30 | <annevk> | so making the query encoding override thing the exception is better, because it means we have less places in the long to test for this weirdness |
| 23:30 | <Hixie> | html. base. link. style. script. a href="" and ping="". cite="". img src and srcset. iframe. frame. embed. object. applet. video. track. source. src="" on <input type=image>, icon="". microdata's use of the aforementioned. window.open. location.*. pushState() and replaceState(). showModalDialog(). register*Handler(). external.AddSearchProvider(). drag and drop's use of some of the aforementioned. |
| 23:31 | <Hixie> | that's just the ones i could find in the HTML spec, i'm sure i missed some. |
| 23:32 | <Hixie> | video poster="" |
| 23:32 | <Hixie> | audio. |
| 23:33 | <zcorpan> | hmm i haven't tested window.open, location, pushState, replaceState |
| 23:33 | <Hixie> | WebSocket is a new protocol, so using UTF-8 there makes sense. CSS is a separate language, so using UTF-8 there makes sense (is that really implemented?). SVG does everything different anyway (and does it really do this differently?). |
| 23:33 | <Hixie> | and similarly inside Workers it makes sense to say the context is utf-8. |
| 23:34 | <Hixie> | but the others, i don't see why we'd be inconsistent. |
| 23:34 | <Hixie> | e.g. EventSource and Worker constructors. |
| 23:34 | <annevk> | I would expect those to work similar to XHR |
| 23:34 | <Hixie> | yeah, XHR being different makes no sense to me |
| 23:35 | <annevk> | also, many of the new contexts above could use utf-8 |
| 23:35 | <Hixie> | i think inconsistency is far more of a problem than poor design decisions |
| 23:35 | <Hixie> | with a consistent quirky interface, you learn the quirk and then you laugh about it while working around it |
| 23:36 | <Hixie> | with an inconsistent interface, you spend all your time cursing that you can never guess what's going to happen |
| 23:37 | <annevk> | that's what happens when you don't use utf-8 |
| 23:37 | <annevk> | not just for urls |
| 23:37 | <annevk> | i don't really see the big deal, non-utf-8 is already broken |
| 23:38 | <Hixie> | indeed, i don't really see the big deal either, non-utf-8 is already broken :-) |
| 23:39 | <Hixie> | so let's at least keep it consistent :-) |
| 23:40 | <annevk> | it's already not consistent and given we'll forever add more APIs that take URLs, it seems better to keep it contained |
| 23:40 | <annevk> | about consistent quirks... |
| 23:40 | <annevk> | <script id=x>w(document.querySelector("#X") !== document.getElementById("X"))</script> |
| 23:40 | <zcorpan> | blink uses document's encoding for XHR. gecko uses utf-8 for EventSource |
| 23:41 | <Hixie> | annevk: "contained" = "inconsistent". it's better to keep it uniform than have a small subset of things that are different. |
| 23:41 | <Hixie> | annevk: especially when the ones that are different are the most used ones, like <a href>. |
| 23:42 | <Hixie> | not sure what the relevance of that id=x example is; the presence of things in the web platform that are inconsistent isn't an argument for adding more. |
| 23:44 | <annevk> | Hixie: I guess if you think we can still get it uniform I might be up for trying that |
| 23:45 | <annevk> | Hixie: would be interesting to hear what others have to say about it |
| 23:47 | <zcorpan> | seems like it should be possible |
| 23:50 | <annevk> | though if we decide that e.g. CSS should be sane, you get these silly crossover APIs... oh well |
| 23:50 | <annevk> | it'll be messy either way |
| 23:57 | <zcorpan> | if we want consistent we can make css use the style sheet's encoding |